Структура UML 1 страница

В структуре универсального языка моделирования выделяют две основные составляющие:

• метамодель;

• правила построения диаграмм.

Метамодель представляет собой описание общей структуры языка, основных понятий объектно‑ориентированного проектирования (класс, объект, событие, ассоциация, автомат, наследование и пр.), а также методов расширения ядра UML. Описания используемых терминов в общем совпадают с определениями, приводимыми в этой книге, поэтому мы не будем подробно на них останавливаться.

Примечание.

Описание метамодели приводится на естественном человеческом языке с применением конструкций самого языка UML, что однако не создает трудностей при ее изучении.

Наличие метамодели придает языку UML строгость и выгодно отличает его от других методик.

Основной интерес для проектировщика представляют правила построения UML‑диаграмм, основными разновидностями которых являются диаграммы:

Qпрецедентов, или вариантов использования (use case diagram);

Qклассов (class diagram);

Qсостояний (statechart diagram);

Qактивности, или деятельности (activity diagram);

• взаимодействия (interaction diagrams), к которым относятся диаграммы последовательности (sequence diagram) и кооперации, или сотрудничества (collaboration diagram);

• компонентов (component diagram);

• развертывания (deployment diagram).

Именно диаграммы в нотации UML служат удобным средством передачи информации об особенностях построения информационной системы между участниками проекта. Часто задание на проектирование рядовому программисту представляется именно в виде набора UML‑диаграмм.

Примечание.

Юридически к категории программы для ЭВМ относится не только код на каком‑либо языке программирования и исполняемый машинный код, но и все материалы, полученные в ходе разработки программ, в первую очередь это касается документированных решений, применяемых при проектировании системы и написанных как на естественном человеческом языке, так и на языке UML. Это еще один аргумент в пользу активного использования UML при разработках информационных систем, так как в случае возникновения спора UML‑диаграммы могут стать удобными доказательствами необходимого по закону признака оригинальности программы для ЭВМ.

При проектировании информационной системы, как правило, составляется множество диаграмм одного и того же вида: множество диаграмм прецедентов, несколько диаграмм классов, множество диаграмм активности.

Не обязательно всегда составлять все диаграммы. Язык UML создан для облегчения процесса разработки, а не для утомительного документирования всех шагов разработки. Некоторые из диаграмм могут отсутствовать.

Последовательность построения диаграмм также свободна.

Среди всех диаграмм следует выделить диаграмму классов, так как на ее основе возможна автоматическая генерация части программного кода будущей информационной системы с описаниями классов и объектов (предварительное объявление в разделе типов и переменных), а также заголовки методов объектов, реализацию которых необходимо писать вручную. То же можно сказать в отношении диаграмм последовательности и кооперации, которые являются взаимно обратимыми, то есть их можно автоматически преобразовать друг в друга. Такие возможности предоставляют системы автоматизированного проектирования, наиболее удачной и известной из которых является системы Rational Rose фирмы Rational Software.

Примечание.

При построении UML‑диаграмм общепринято использование языка объектных ограничений (Object Constraint Language, ОСL), разработанного фирмой IBM. Язык OCL похож на SQL, но создан специально для навигации и получения данных от объектов. Ввиду ограниченности объема книги мы его рассматривать не будем.

Диаграмма прецедентов.

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

Конечный пользователь, в роли которого может выступать человек (например, покупатель или оператор) или техническое устройство (например, мобильный телефон), изображается в виде стилизованной фигурки человека (рис. 3.1).

Рис. 3.1. Графическое изображение конечного пользователя.

Если же в качестве пользователя выступает сама система, что возможно, например, при предоставлении каких‑либо функций определенному классу, вместо пользователя рекомендуется применять соответствующее обозначение класса.

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

Рис. 3.2. Графическое изображение прецедента.

Для пояснения содержания диаграмм используют примечания, обозначаемые на диаграммах в виде листа бумаги с загнутым углом (рис. 3.3).

Рис. 3.3. Графическое изображение примечания.

Текст примечания записывается внутри этого листа. Примечание соединяется пунктирной линией с тем элементом диаграммы, к которому оно относится.

Примечание.

Используемые на диаграммах обозначения являются общими для всех видов диаграмм.

Еще одним наиболее часто используемым на диаграммах прецедентов элементом является интерфейс.

Интерфейс – это совокупность операций, предоставляемых классом или компонентом. Интерфейс описывает поведение класса или компонента, видимое извне. Интерфейс определяет только описание (спецификации) операций класса или компонента, но он никогда не определяет физические реализации операций.

Интерфейс представляет собой сущность, которая дает пользователю возможность совершить определенное действие, получить информацию. Пользователю интерфейс может быть доступен в качестве датчика, обращения к базе данных, кнопки, бланка заявления – то есть устройства или операции. Графически интерфейс обозначается небольшим кружком, рядом с которым указывается его наименование (рис. 3.4).

Рис. 3.4. Графическое изображение интерфейса.

В нотации UML английские имена интерфейсов принято начинать с буквы I.

Примечание.

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

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

Ниже перечислены определенные в нотации UML виды отношений между компонентами на диаграммах прецедентов.

• Отношение ассоциации (association relationship) устанавливает роль пользователя в системе. Обозначается сплошной линией между пользователем и прецедентом (рис. 3.5, а).

• Отношение расширения (extend relationship) определяет взаимосвязь прецедента с прецедентом, возможности которого он может использовать. Графически обозначается пунктирной стрелкой с пометкой «extend» от дополняющего прецедента к расширяемому. Случай, изображенный на рис. 3.5, б, говорит, что при определенных условиях прецедент B может быть дополнен прецедентом A. На практике это может означать, например, дополнительные (помимо обычных) меры к идентификации личности человека.

• Отношение обобщения (generalization relationship) показывает, что компонент (пользователь или прецедент) является частным случаем другого компонента. Графически обозначается непрерывной стрелкой от общего к частному (рис. 3.5, в).

• Отношение включения (include relationship) указывает на включение прецедента в другой прецедент в качестве его составной части. Один и тот же прецедент может быть включен в несколько более крупных прецедентов. Графически данное отношение обозначается пунктирной линией со стрелкой, направленной от базового прецедента к включаемому с пометкой «include» (рис. 3.5, г).

Рис. 3.5. Графическое изображение отношений на диаграммах прецедентов.

Цифры над стрелкой (см. рис. 3.5, а) обозначают кратность (multiplicity) отношения и показывают количество возможных компонентов данного отношения. Случай на рисунке означает, что один и тот же пользователь может задействовать систему данным образом любое количество (обозначается «звездочкой») раз.

Проиллюстрируем изложенное на примере действий дежурного врача при поступлении пациента в больницу через приемный покой. Дежурный врач организует прием пациента, что подразумевает оформление истории болезни, проведение анализов, первичный осмотр, оповещает родственников пострадавшего. В случае тяжелого состояния пациента он направляется в реанимацию. Если состояние пациента безнадежно, от родственников испрашивается согласие на трансплантацию органов. Разрабатываемая информационная система должна автоматизировать выдачу направлений на анализы, предоставляя пакет документов для оформления согласия родственников. Истории болезни в организации ведутся в бумажной форме (результаты анализов в историю болезни вклеиваются). На рис. 3.6 представлен возможный вариант диаграммы прецедентов для данного случая.

Рис. 3.6. Прием пациента в больницу.

Диаграмма прецедентов в таком виде наглядно представляет первичные требования заказчика – в данном случае медицинского учреждения. Совокупность таких диаграмм в идеале должна полностью описывать требования к функциональности системы. На практике требования могут изменяться. Графическое представление требований к системе значительно сокращает сроки их согласования между заказчиком и разработчиками.

Примечание.

На диаграммах прецедентов не указывается, в какой последовательности выполняются операции. Данная информация может содержаться на диаграммах активности, взаимодействия и состояний.

Пакеты.

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

Рис. 3.7. Графическое изображение пакета.

Компоненты, относящиеся к определенному пакету, могут быть доступны вне пакета, если указать имя компонента и его принадлежность определенному пакету через двойное двоеточие, например:

Имя_Пакета::Имя_Компонента

Эта запись означает, что пакет образует собственное пространство имен.

Как правило, элементы модели, входящие в пакет, логически связаны между собой.

Если количество классов в системе достаточно велико, иногда прибегают к построению диаграмм пакетов, разбивая систему на части на более высоком уровне, чем диаграммы классов.

Диаграмма классов.

Под классом в языке UML понимается множество объектов, обладающих одинаковой структурой, свойствами, отношениями с другими объектами.

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

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

Рис. 3.8. Графическое изображение класса.

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

Свойства класса определяют состояние экземпляров класса (объектов). В общем виде формат записи свойства можно представить в виде строки:

видимость имя_свойства [кратность]: тип_свойства = значение_по_умолчанию

Ниже перечислены аргументы этой строки.

• видимость – видимость свойства для других классов. Допустимые значения:

– public (или знак +) – свойство класса доступно любому другому классу;

– protected (или знак #) – свойство класса доступно только экземплярам этого класса и потомкам данного класса;

– private (или знак –) – свойство класса доступно только экземплярам этого класса.

Отсутствие указания на категорию доступа означает, что видимость не указывается.

Примечание.

Как уже отмечалось, диаграмма классов может использоваться для автоматической генерации программного кода на выбранном языке программирования. Следует иметь в виду, что в разных языках значения видимости свойства (атрибута), задаваемые по умолчанию, разные.

• тип_свойства – тип свойства. Этот тип выбирается, исходя из языка реализации проекта (С++, Delphi, Java и других).

• кратность – диапазон принимаемых свойством значений с учетом типа. Так, если в качестве кратности свойства имя_клиента указан диапазон 1..5 и тип String, то это свойство может принимать, например, следующие значения: Иван Петров, Уильям Джефферсон Клинтон, Мехти Асадулла оглы Мамедов, то есть значения, содержащие не более 5 слов. Если же в качестве кратности свойства доход указан диапазон 0..* и тип Currency, значение этого свойства может принимать любое положительное значение в денежном формате.

• значение_по_умолчанию – начальное значение свойства, которое в последующем можно изменить программно. Если в строке определения свойства вместо одного знака равенства (=) указать два (==), то значение по умолчанию программно изменить будет нельзя.

Например, следующая запись для свойства класса Менеджер означает, что по умолчанию всем сотрудникам, замещающим эту должность, первоначально устанавливается заработная плата 700 долларов.

Заработная плата [0..*]: Currency = 700 $

Примечание.

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

Методы класса служат для обработки свойств класса и характеризуют поведение экземпляров класса.

Формат записи метода выглядит так:

видимость имя_метода (список параметров): тип_значения {строка‑свойство}

Ниже перечислены аргументы этой строки.

• видимость – этот аргумент определяется аналогично видимости свойств.

• имя_метода – идентификатор метода.

• список параметров – перечень разделенных запятой формальных параметров.

Наличие круглых скобок обязательно. Каждый из формальных параметров может быть представлен в следующем виде:

вид_параметра имя_параметра: тип_параметра = значение_по_умолчанию

Здесь:

– вид_параметра – входной (передаваемый методу), выходной (возвращаемый методом) или универсальный (значение параметра может изменяться методом) параметр (обозначается соответственно in, out или inout);

– тип_параметра – тип параметра, определяемый языком реализации класса.

• тип_значения – тип значения. Определяется языком реализации класса.

• строка‑свойство – значения свойств, которые могут относиться к данному параметру. Метод, не изменяющий состояние объекта, обозначается строкой‑свойством {query}. Строка‑свойство {concurrency = sequential} указывает на необходимость обращения к методу во время вызова другого метода, строка‑свойство {concurrency = concurrent} – на возможность параллельного вызова методов. Строка‑свойство {concurrency = guarded} обращает внимание на необходимость принятия дополнительных мер по контролю исключительных ситуаций.

• Имя и тип метода с областью действия на весь класс подчеркивается. Например, изменение фона одного окна программы автоматически изменяет цвет фона всех окон системы, как это имеет место при щелчке правой кнопкой мыши на свободном участке рабочего стола и изменении вида окон Windows на вкладке Оформление окна Свойства: Экран. По умолчанию областью действия метода определяется экземпляр класса (объект). В данном случае изменение цвета фона окна (формы) затронет только это окно.

• Абстрактные методы, то есть методы, не задействованные в данном классе, выделяются курсивом или помечаются строкой‑свойством {abstract}.

Примером обозначения метода «открыть» класса File служить запись:

+ open ()

Этот метод не возвращает никакого результата своего выполнения.

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

издать приказ (сотрудник): приказ по форме 1‑А {"отпуск"}

В нотации UML между компонентами диаграммы классов могут существовать различные отношения.

• Отношение зависимости (dependency relationship) указывает на общую взаимосвязь компонентов диаграммы. Графически эта связь изображается пунктирной стрелкой от зависимого класса к независимому (рис. 3.9).

Рис. 3.9. Графическое изображение отношения зависимости.

Ключевое слово (стереотип) над стрелкой означает, что свойства класса Кредит, в частности сумма кредита, выдаваемая банком заемщику, может быть определена, исходя из характеристик заемщика (свойств класса Клиент): ежемесячного дохода, возраста и других. Ключевое слово является необязательным элементом. Помимо значения «derive», оно может принимать следующие значения:

– «access» – указывает на доступность свойств и методов независимого класса для зависимого;

– «import» – открытые свойства и методы независимого класса (источника) становятся частью зависимого класса, как если бы они были объявлены непосредственно в нем;

– «bind» – класс может использовать другой класс в качестве шаблона;

– «refine» – зависимый класс уточняет класс‑источник в силу исторических причин.

• Отношение ассоциации (association relationship) устанавливает некоторую связь между классами системы. Графически это отношение обозначается сплошной линией между классами (рис. 3.10).

Рис. 3.10. Графическое изображение отношения ассоциации.

Пример на рисунке означает, что клиент делает покупки. При этом любой покупатель может купить любой товар или не купить никакой, и любой товар может быть продан любому покупателю или не быть купленным никем.

Отношение ассоциации может связывать большее количество классов (N‑арная ассоциация). На диаграмме классов такая ассоциация изображается ромбом (рис. 3.11).

Рис. 3.11. N‑арная ассоциация.

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

Частными случаями отношений ассоциации являются исключающая ассоциация, агрегация и композиция:

– исключающая ассоциация (xor‑association) указывает на возможность связи определенного класса только с одним из нескольких классов (рис. 3.12);

– отношение агрегации означает включение нескольких классов в другой класс (графически отношение агрегации показано на рис. 3.13 и означает, что в состав класса Сервиз в качестве самостоятельных единиц могут входить тарелки и другие столовые приборы);

Примечание.

Не все языки программирования поддерживают такие конструкции.

Рис. 3.12. Графическое изображение исключающей ассоциации.

Рис. 3.13. Графическое изображение отношения агрегации.

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

Рис. 3.14. Графическое изображение отношения композиции.

• Отношение обобщения (generalization relationship) показывает, что компонент (пользователь или прецедент) является частным случаем другого компонента. Графически это отношение обозначается непрерывной стрелкой от частного к общему (рис. 3.15). Отношениями обобщения иллюстрируется наследование классов.

Рис. 3.15. Графическое изображение отношения обобщения.

В приведенном примере класс Рыбные консервы наследует свойства и методы более общего класса Товар. Язык UML является средством документирования и иллюстрирования удачных идей и решений в области проектирования информационных систем. Так, диаграмма, представленная на рис. 3.16, выражает идею множественного наследования, реализованную в некоторых языках программирования.

Рис. 3.16. Множественное наследование.

Классы Рыбные консервы и Тушенка наследуют свойства и методы более общих классов Товар и Консервы, в то же время они наследуют соответственно свойства и методы классов Рыба и Мясо (последние принято называть «примесными классами»). Такое решение может значительно упростить процесс разработки информационной системы, сделать ее более устойчивой к вносимым изменениям за счет сокращения избыточности и локализации общих структур.

Примечание.

Множественное наследование классов реализовано далеко не во всех языках программирования. В языке С++ наследование поддерживается, в языке Object Pascal – нет. Отказ от поддержания множественного наследования обусловлен возможностью возникновения ситуации, когда два или несколько классов, имея единого предка, по‑разному реализуют одноименный метод, поэтому при множественном наследовании возникнет проблема выбора той или иной реализации метода (рис. 3.17), которую придется разрешать «вручную» (как это делается в С++).

Рис. 3.17. Проблема множественного наследования классов.

• Отношение обобщения может содержать поясняющий его идентификатор:

– {complete} – на диаграмме показаны все классы‑потомки;

– {incomplete} – на диаграмме указаны не все классы‑потомки;

– {disjoint} – множественное наследование не допускается;

– {overlapping} – множественное наследование допускается.

Помимо классов на диаграммах классов могут присутствовать интерфейсы, объекты (экземпляры классов) и параметризированные классы (метаклассы, шаблоны).

Интерфейс на диаграмме классов показывается прямоугольником с двумя секциями (рис. 3.18, а). В первой записывается имя интерфейса, ключевое слово «interface» и служебная информация. Вторая секция предназначена для записи методов интерфейса.

Рис. 3.18. Графическое изображение интерфейса и объекта на диаграмме классов.

Под объектом в языке UML понимается отдельный экземпляр, или пример, класса, структура и поведение которого полностью определяется порождающим этот объект классом. Объекты показываются прямоугольниками, как и классы, при этом имя объекта подчеркивается и содержит указание на класс объекта (рис. 3.18, б).

Параметризированный класс (метакласс, шаблон) представляет собой семейство классов, каждый член которого может отличаться от других каким‑либо параметром, указываемым в пунктирной рамке в правом верхнем углу изображения класса (рис. 3.19, а).

Рис. 3.19. Графическое изображение метакласса.

В примере на рис. 3.19, б метакласс может служить основой для создания классов Счет в рублях, Счет в долларах США, Счет в евро или Мультивалютный счет.

Диаграмма состояний.

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

Для моделирования динамики информационной системы служат диаграммы состояний, деятельности, последовательности и кооперации, каждая из которых показывает будущую систему в своем ракурсе.

Диаграмма состояний описывает процесс изменения одного класса, а точнее – одного экземпляра класса. На диаграмме отражаются состояния и переходы между состояниями объекта под воздействием внешних факторов.

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

Начальное состояние изображается черным кружком, конечное – черным кружком в белом кольце. На диаграмме, показанной на рис. 3.20, объект из начального состояния переходит в некоторое другое состояние, в котором выполняется действие 1, а затем – в конечное состояние.

Рис. 3.20. Простейшая диаграмма состояний.

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

Внутренние действия состояния описываются в следующем формате:

метка / действие

Здесь аргумент метка представляет собой одно из следующих ключевых слов:

• entry – действие выполняется в момент перехода объекта в данное состояние;

• exit – действие выполняется в момент выхода объекта из данного состояния;

• do – действие выполняется во время нахождения объекта в данном состоянии;

• include – обращение к подсостоянию (substate) данного состояния объекта.

Составное состояние (composite state), или суперсостояние, – это такое состояние объекта, которое включает в себя несколько подсостояний. Использование подсостояний удобно, например, когда на диаграмме требуется показать состояния объекта в зависимости от одного из его свойств. При этом другие свойства объекта также могут изменяться, и если такие состояния и переходы между ними показывать в качестве самостоятельных состояний, то диаграмма будет перегружена обозначениями, затрудняющими восприятие смысла диаграммы – демонстрации переходов между состояниями в зависимости от конкретного свойства. Два варианта графического изображения составного состояния показаны на рис. 3.21.

Дата добавления: 2014-11-25