Примечание 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.
Примечание 80
Следует заметить, что внешний вид панели инструментов определяется не только выбором и не только видом разрабатываемой диаграммы, но и выбором графической нотации для изображения самих элементов этих диаграмм. В Rational Rose реализованы три таких нотации: UML, ОМТ и Booch. Речь идет о том, что одна и та же диаграмма может быть представлена различным образом, для этого достаточно выбрать желаемое представление через пункт меню View (Вид). При этом никаких дополнительных действий выполнять не требуется – диаграмма преобразуется в выбранную нотацию автоматически. Однако, рассматривая Rational Rose в контексте только языка UML, мы оставим без внимания особенности двух других нотаций, которые отражают эволюционный аспект этого средства.
