Александр Леоненков - Самоучитель UML

Примечание 65

Дополнить диаграмму последовательности для этого примера временными ограничениями предлагается выполнить самостоятельно в качестве упражнения.

Примечание 66

В прямоугольнике объекта имя объекта, имя роли с символом Т или имя класса могут отсутствовать. Однако двоеточие всегда должно стоять перед именем класса, а косая черточка – перед именем роли. Следует еще раз акцентировать внимание на том обстоятельстве, что применительно к объектам вся запись должна быть подчеркнута, а имя объекта должно быть записано со строчной буквы.

Примечание 67

Отличие между процессом и нитью заключается в степени использования ресурсов. Говоря о процессе, имеют в виду ресурсоемкий поток управления, т. е. процесс полностью монополизирует ресурсы системы. Нить может использовать лишь небольшую часть ресурсов системы. Примером может служить выполнение некоторой программы в своем адресном пространстве или в фоновом режиме.

Примечание 68

Поскольку на данной диаграмме отсутствуют сообщения, то она не является, строго говоря, диаграммой кооперации. Скорее это специальный случай диаграммы классов, который иногда называют диаграммой объектов. В случае N-арной связи эта связь изображается аналогично N-арной ассоциации с использованием символа ромба.

Примечание 69

Заметим, что сами номера последовательности сообщений с одинаковым префиксом образуют отношение упорядоченности и, соответственно, неявно указывают на предшествующие сообщения. Таким предшествующим сообщением будет сообщение с номером, самая правая цифра которого на единицу меньше, чем у рассматриваемого сообщения. Например, сообщение с номером «3.1.4.6» имеет в качестве предшествующего сообщение с номером «3.1.4.5».

Примечание 70

Заметим, что условие записывается так же, как и итерация, но без звездочки. Это можно понимать как некоторую одношаговую итерацию. При этом предполагается, что итерация выполняется последовательно. Если необходимо отметить возможность параллельного выполнения итерации, в языке UML используется символ «*||». Итерация не распространяется на вложенные уровни данного потока или нити. Каждый уровень должен иметь свое собственное представление для итеративного повторения процедурной последовательности.

Примечание 71

На диаграмме кооперации при записи сообщений также могут использоваться стереотипы, рассмотренные ранее при построении диаграммы последовательности (см. главу 8). Их семантика и синтаксис остаются без изменения, поскольку определены в нотации языка UML

Примечание 72

Применительно к бизнес-системам программные компоненты следует понимать в более широком смысле, чтобы иметь возможность моделирования бизнес-процессов. В этом случае в качестве компонентов рассматриваются отдельные организационные подразделения (отделы, службы) или документы, которые реально существуют в системе.

Примечание 73

Изображение компонента ведет свое происхождение от обозначения модуля программы, применявшегося некоторое время для отображения особенностей инкапсуляции данных и процедур. Так, верхний маленький прямоугольник концептуально ассоциируется с данными, которые реализует этот компонент (ранее он изображался в форме овала). Нижний маленький прямоугольник ассоциируется с операциями или методами, реализуемыми компонентом. В простых случаях имена данных и методов записывались явно в этих маленьких прямоугольниках, однако в языке UML они не указываются.

Примечание 74

Хотя правила именования объектов в языке UML требуют подчеркивания имени отдельных экземпляров, применительно к компонентам в литературе подчеркивание их имени часто опускают. В этом случае запись имени компонента со строчной буквы будет характеризовать компонент уровня экземпляра.

Примечание 75

Характер использования интерфейсов отдельными компонентами может отличаться. Поэтому различают два способа связи интерфейса и компонента. Если компонент реализует некоторый интерфейс, то такой интерфейс называют экспортируемым, поскольку этот компонент предоставляет его в качестве сервиса другим компонентам. Если же компонент использует некоторый интерфейс, который реализуется другим компонентом, то такой интерфейс для первого компонента называется импортируемым. Особенность импортируемого интерфейса состоит в том, что на диаграмме компонентов это отношение изображается с помощью зависимости.

Примечание 76

Возможность включения людей (персонала) в понятие узла позволяет создавать средствами языка UML модели самых различных систем, включая бизнес-процессы и технические комплексы. Действительно, реализация бизнес-логики предприятия требует рассматривать в качестве узлов системы организационные подразделения, состоящие из персонала. Автоматизация управления техническими комплексами также требует рассмотрения в качестве самостоятельного элемента человека-оператора, способного принимать решения в нештатных ситуациях и нести ответственность за возможные последствия этих решений.

Примечание 77

Говоря о дополнительных графических изображениях для узлов диаграммы развертывания, прежде всего имеют в виду наглядность их представления. Например, процессор можно изобразить как в виде общего узла (рис. 11.1), так и в форме изображения внешнего вида компьютера. Соответственно, консоль может быть изображена в виде клавиатуры. В любом из этих случаев разработчик должен обладать, в дополнение к основным, еще и художественными способностями.

Примечание 78

Среди причин, сдерживающих применение CASE-средств и определяющих контраст их популярности среди западных и отечественных разработчиков программ, следует отметить, в первую очередь, масштабность проектов и различие в технологиях создания программ. G одной стороны, необходимость автоматизации анализа и проектирования программных систем на базе CASE-тех-нологии начинает осознаваться только тогда, когда проект является достаточно сложным и масштабным. В противном случае для написания программ вполне достаточно обычных инструментов разработчика. С другой стороны, реализация масштабных проектов под силу группе программистов, а обеспечение групповой работы над проектом требует дополнительных средств для обеспечения совместимости его составных частей.

Примечание 79

Конечно, рассмотреть в одной главе возможности такого средства, как Rational Rose 2000, просто невозможно, и автор не ставил перед собой такую задачу. Цель нашего знакомства с этим инструментарием – осветить основные особенности реализации языка UML на уровне разработки отдельных диаграмм. Поэтому далее описываются лишь основные правила и рекомендации, необходимые для разработки визуальных моделей в форме канонических диаграмм языка UML, реализованные уже в Rational Rose 98 и, соответственно, в Rational Rose 98J/2000.