Uml диаграмма компонентов описание. Основные диаграммы языка UML
Особенности изображения диаграмм языка UML
Для диаграмм языка UML существуют три типа визуальных графических обозначений, которые важны с точки зрения заключенной в них информации:
· Геометрические фигуры на плоскости, играющие роль вершин графов соответствующих диаграмм. При этом сами геометрические фигуры выступают в роли графических примитивов языка UML, а форма этих фигур (прямоугольник, эллипс) должна строго соответствовать изображению отдельных элементов языка UML (класс, вариант использования, состояние, деятельность). Графические примитивы языка UML имеют фиксированную семантику, переопределять которую пользователям не допускается. Графические примитивы должны иметь собственные имена, а, возможно, и другой текст, который содержится внутри границ соответствующих геометрических фигур или, как исключение, вблизи этих фигур.
· Графические взаимосвязи, которые представляются различными линиями на плоскости. Взаимосвязи в языке UML обобщают понятие дуг и ребер из теории графов, но имеют менее формальный характер и более развитую семантику.
· Специальные графические символы, изображаемые вблизи от тех или иных визуальных элементов диаграмм и имеющие характер дополнительной спецификации (украшений).
Все диаграммы в языке UML изображаются с использованием фигур на плоскости. Отдельные элементы – с помощью геометрических фигур, которые могут иметь различную высоту и ширину с целью размещения внутри них других конструкций языка UML. Наиболее часто внутри таких символов помещаются строки текста, которые уточняют семантику или фиксируют отдельные свойства соответствующих элементов языка UML. Информация, содержащаяся внутри фигур, имеет значение для конкретной модели проектируемой системы, поскольку регламентирует реализацию соответствующих элементов в программном коде.
Пути представляют собой последовательности из отрезков линий, соединяющих отдельные графические символы. При этом концевые точки отрезков линий должны обязательно соприкасаться с геометрическими фигурами, служащими для обозначения вершин диаграмм, как принято в теории графов. С концептуальной точки зрения путям в языке UML придается особое значение, поскольку это простые топологические сущности. Отдельные части пути или сегменты могут не существовать вне содержащего их пути. Пути всегда соприкасаются с другими графическими символами на обеих границах соответствующих отрезков линий, т.е. пути не могут обрываться на диаграмме линией, которая не соприкасается ни с одним графическим символом. Как отмечалось выше, пути могут иметь в качестве окончания или терминатора специальную графическую фигуру – значок, который изображается на одном из концов линий.
Дополнительные значки или украшения представляют собой графические фигуры фиксированного размера и формы. Они не могут увеличивать свои размеры, чтобы разместить внутри себя дополнительные символы. Значки размещаются как внутри других графических конструкций, так и вне их. Примерами значков могут служить окончания связей элементов диаграмм или графические обозначения кванторов видимости атрибутов и операций классов.
Диаграмма кооперации
Диаграммы кооперации предназначены для описания динамических аспектов моделируемой системы. Обычно они применяются для того, чтобы:
· показать набор взаимодействующих объектов в реальном окружении "с высоты птичьего полета";
· распределить функциональность между классами, основываясь на результатах изучения динамических аспектов системы;
· описать логику выполнения сложных операций, особенно в тех случаях, когда один объект взаимодействует еще с несколькими объектами;
· изучить роли, выполняемые объектами внутри системы, а также отношения между объектами, в которые они вовлекаются, выполняя эти роли.
Говоря о диаграммах кооперации, часто упоминают два "уровня" таких диаграмм:
· уровень экземпляров
(примеров, Instance-Level): отображает взаимодействия между объектами (экземплярами классов); такая диаграмма
обычно создается, чтобы исследовать внутреннее устройство
объектно-ориентированной системы.
· уровень спецификации
(Specification-Level): используется для изучения ролей, исполняемых в системе основными классами.
Она показывает взаимодействие между объектами, которое осуществляется путем посылки и приема сообщений.
Диаграмма компонентов
Компоненты связываются через зависимости, когда соединяется требуемый интерфейс одного компонента с имеющимся интерфейсом другого компонента. Таким образом иллюстрируются отношения клиент-источник между двумя компонентами.
Зависимость показывает, что один компонент предоставляет сервис, необходимый другому компоненту. Зависимость изображается стрелкой от интерфейса или порта клиента к импортируемому интерфейсу.
Основной тип сущностей на диаграмме компонентов ‒ это сами компоненты 1, а также интерфейсы 2, посредством которых указывается взаимосвязь между компонентами. На диаграмме компонентов применяются следующие отношения:
· реализации между компонентами и интерфейсами (компонент реализует интерфейс);
· зависимости между компонентами и интерфейсами (компонент использует интерфейс) 3.
Диаграмма развертывания
Диаграмма развертывания предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения (runtime). При этом представляются только компоненты-экземпляры программы, являющиеся исполняемыми файлами или динамическими библиотеками. Те компоненты, которые не используются на этапе исполнения, на диаграмме развертывания не показываются. Так, компоненты с исходными текстами программ могут присутствовать только на диаграмме компонентов. На диаграмме развертывания они не указываются.
Диаграмма развертывания содержит графические изображения процессоров, устройств, процессов и связей между ними. В отличие от диаграмм логического представления, диаграмма развертывания является единой для системы в целом, поскольку должна всецело отражать особенности ее реализации. Разработка диаграммы развертывания, как правило, является последним этапом спецификации модели программной системы.
При разработке диаграммы развертывания преследуют следующие цели:
· определить распределение компонентов системы по ее физическим узлам;
· показать физические связи между всеми узлами реализации системы на этапе ее исполнения;
· выявить узкие места системы и реконфигурировать ее топологию для достижения требуемой производительности.
Все рассмотренные ранее диаграммы отражали концептуальные аспекты построения модели системы и относились к логическому уровню представления. Особенность логического представления заключается в том, что оно оперирует понятиями, которые не имеют самостоятельного материального воплощения. Другими словами, различные элементы логического представления, такие как классы, ассоциации, состояния, сообщения, не существуют материально или физически. Они лишь отражают наше понимание структуры физической системы или аспекты ее поведения.
Основное назначение логического представления состоит в анализе структурных и функциональных отношений между элементами модели системы. Однако для создания конкретной физической системы необходимо некоторым образом реализовать все элементы логического представления в конкретные материальные сущности. Для описания таких реальных сущностей предназначен другой аспект модельного представления, а именно физическое представление модели.
Чтобы пояснить отличие логического и физического представлений, рассмотрим в общих чертах процесс разработки некоторой программной системы. Ее исходным логическим представлением могут служить структурные схемы алгоритмов и процедур, описания интерфейсов и концептуальные схемы баз данных. Однако для реализации этой системы необходимо разработать исходный текст программы на некотором языке программирования (C++, Pascal, Basic/VBA, Java). При этом уже в тексте программы предполагается такая организация программного кода, которая предполагает его разбиение на отдельные модули.
Тем не менее исходные тексты программы еще не являются окончательной реализацией проекта, хотя и служат фрагментом его физического представления. Очевидно, программная система может считаться реализованной в том случае, когда она будет способна выполнять функции своего целевого предназначения. А это возможно, только если программный код системы будет реализован в форме исполняемых модулей, библиотек классов и процедур, стандартных графических интерфейсов, файлах баз данных. Именно эти компоненты являются необходимыми элементами физического представления системы.
Таким образом, полный проект программной системы представляет собой совокупность моделей логического и физического представлений, которые должны быть согласованы между собой. В языке UML для физического представления моделей систем используются так называемые диаграммы реализации (implementation diagrams), которые включают в себя две отдельные канонические диаграммы: диаграмму компонентов и диаграмму развертывания. Особенности построения первой из них рассматриваются в этой главе, а второй – в следующей.
Диаграмма компонентов, в отличие от ранее рассмотренных диаграмм, описывает особенности физического представления системы. Диаграмма компонентов позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный, бинарный и исполняемый код. Во многих средах разработки модуль или компонент соответствует файлу. Пунктирные стрелки, соединяющие модули, показывают отношения взаимозависимости, аналогичные тем, которые имеют место при компиляции исходных текстов программ. .Основными графическими элементами диаграммы компонентов являются компоненты, интерфейсы и зависимости между ними.
Диаграмма компонентов разрабатывается для следующих целей:
Спецификации исполнимого варианта программной системы.
Обеспечения многократного использования отдельных фрагментов программного кода.
Представления концептуальной и физической схем баз данных.
В разработке диаграмм компонентов участвуют как системные аналитики и архитекторы, так и программисты. Диаграмма компонентов обеспечивает согласованный переход от логического представления к конкретной реализации проекта в форме программного кода. Одни компоненты могут существовать только на этапе компиляции программного кода, другие – на этапе его исполнения. Диаграмма компонентов отражает общие зависимости между компонентами, рассматривая последние в качестве классификаторов.
Для представления физических сущностей в языке UML применяется специальный термин – компонент (component). Компонент реализует некоторый набор интерфейсов и служит для общего обозначения элементов физического представления модели. Для графического представления компонента может использоваться специальный символ – прямоугольник со вставленными слева двумя более мелкими прямоугольниками (рис. 10.1). Внутри объемлющего прямоугольника записывается имя компонента и, возможно, некоторая дополнительная информация. Изображение этого символа может незначительно варьироваться в зависимости от характера ассоциируемой с компонентом информации.
В метамодели языка UML компонент является потомком классификатора. Он предоставляет организацию в рамках физического пакета ассоциированным с ним элементам модели. Как классификатор, компонент может иметь также свои собственные свойства, такие как атрибуты и операции.
Рис. 10.1.
Графическое изображение компонента в языке UML
Так, в первом случае (рис. 10.1, а) с компонентом уровня экземпляра связывается только его имя, а во втором (рис. 10.1, б) – дополнительно имя пакета и помеченное значение.
Имя компонента подчиняется общим правилам именования элементов модели в языке UML и может состоять из любого числа букв, цифр и некоторых знаков препинания. Отдельный компонент может быть представлен на уровне типа или на уровне экземпляра. Хотя его графическое изображение в обоих случаях одинаковое, правила записи имени компонента несколько отличаются. Если компонент представляется на уровне типа, то в качестве его имени записывается только имя типа с заглавной буквы.
Если же компонент представляется на уровне экземпляра, то в качестве его имени записывается <имя компонента ":" имя типаХ При этом вся строка имени подчеркивается.
В качестве простых имен принято использовать имена исполняемых файлов (с указанием расширения ехе после точки-разделителя), имена динамических библиотек (расширение dll), имена Web-страниц (расширение html), имена текстовых файлов (расширения txt или doc) или файлов справки (hip), имена файлов баз данных (DB) или имена файлов с исходными текстами программ (расширения h, cpp для языка C++, расширение Java для языка Java), скрипты (pi, asp) и др.
Поскольку конкретная реализация логического представления модели системы зависит от используемого программного инструментария, то и имена компонентов будут определяться особенностями синтаксиса соответствующего языка программирования.
В отдельных случаях к простому имени компонента может быть добавлена информация об имени объемлющего пакета и о конкретной версии реализации данного компонента (рис. 10.1, б). Необходимо заметить, что в этом случае номер версии записывается как помеченное значение в фигурных скобках. В других случаях символ компонента может быть разделен на секции, чтобы явно указать имена реализованных в нем интерфейсов. Такое обозначение компонента называется расширенным и рассматривается ниже в этой главе.
Поскольку компонент как элемент физической реализации модели представляет отдельный модуль кода, иногда его комментируют с указанием дополнительных графических символов, иллюстрирующих конкретные особенности его реализации. Строго.говоря, эти дополнительные обозначения для примечаний не специфицированы в языке UML. Однако их применение упрощает понимание диаграммы компонентов, существенно повышая наглядность физического представления. Некоторые из таких общепринятых обозначений для компонентов изображены ниже (рис. 10.2).
В языке UML выделяют три вида компонентов.
Во-первых, компоненты развертывания, которые обеспечивают непосредственное выполнение системой своих функций. Такими компонентами могут быть динамически подключаемые библиотеки с расширением dll (рис. 10.2, а), Web-страницы на языке разметки гипертекста с расширением html (рис. 10.2, б) и файлы справки с расширением Ыр (рис. 10.2, в).
Во-вторых, компоненты-рабочие продукты. Как правило – это файлы с исходными текстами программ, например, с расширениями h или срр для языка C++ (рис. 10.2, г).
В-третьих, компоненты исполнения, представляющие исполнимые модули – файлы с расширением ехе. Они обозначаются обычным образом.
Рис. 10.2.
Варианты графического изображения компонентов на диаграмме компонентов
Эти элементы иногда называют артефактами, подчеркивая при этом их законченное информационное содержание, зависящее от конкретной технологии реализации соответствующих компонентов. Более того, разработчики могут для этой цели использовать самостоятельные обозначения, поскольку в языке UML нет строгой нотации для графического представления примечаний.
Другой способ спецификации различных видов компонентов – явное указание стереотипа компонента перед его именем. В языке UML для компонентов определены следующие стереотипы:
Библиотека (library) – определяет первую разновидность компонента, который представляется в форме динамической или статической библиотеки.
Таблица (table) – также определяет первую разновидность компонента, который представляется в форме таблицы базы данных.
Файл (file) – определяет вторую разновидность компонента, который представляется в виде файлов с исходными текстами программ.
Документ (document) – определяет вторую разновидность компонента, . который представляется в форме документа.
Исполнимый (executable) – определяет третий вид компонента, который может исполняться в узле.
Следующим элементом диаграммы компонентов являются интерфейсы. Последние уже неоднократно рассматривались ранее, поэтому здесь будут отмечены те их, особенности, которые характерны для представления на диаграммах компонентов. Напомним, что в общем случае интерфейс графически изображается окружностью, которая соединяется с компонентом отрезком линии без стрелок (рис. 10.3, а). При этом имя интерфейса, которое обязательно должно начинаться с заглавной буквы "I", записывается рядом с окружностью. Семантически линия означает реализацию интерфейса, а наличие интерфейсов у компонента означает, что данный компонент реализует соответствующий набор интерфейсов.
Рис. 10.3.
Графическое изображение интерфейсов на диаграмме компонентов
Другим способом представления интерфейса на диаграмме компонентов является его изображение в виде прямоугольника класса со стереотипом «интерфейс» и возможными секциями атрибутов и операций (рис. 10.3, б). Как правило, этот вариант обозначения используется для представления внутренней структуры интерфейса, которая может быть важна для реализации.
При разработке программных систем интерфейсы обеспечивают не только совместимость различных версий, но и возможность вносить существенные изменения в одни части программы, не изменяя другие ее части. Таким образом, назначение интерфейсов существенно шире, чем спецификация взаимодействия с пользователями системы (актерами).
В общем случае отношение зависимости также было рассмотрено ранее (см. главу 5). Напомним, что зависимость не является ассоциацией, а служит для представления только факта наличия такой связи, когда изменение одного элемента модели оказывает влияние или приводит к изменению другого элемента модели. Отношение зависимости на диаграмме компонентов изображается пунктирной линией со стрелкой, направленной от клиента (зависимого элемента) к источнику (независимому элементу).
Зависимости могут отражать связи модулей программы на этапе компиляции и генерации объектного кода. В другом случае зависимость может отражать наличие в независимом компоненте описаний классов, которые используются в зависимом компоненте для создания соответствующих объектов. Применительно к диаграмме компонентов зависимости могут связывать компоненты и импортируемые этим компонентом интерфейсы, а также различные виды компонентов между собой.
В первом случае рисуют стрелку от компонента-клиента к импортируемому интерфейсу (рис. 10.4). Наличие такой стрелки означает, что компонент не реализует соответствующий интерфейс, а использует его в процессе своего выполнения. Причем на этой же диаграмме может присутствовать и другой компонент, который реализует этот интерфейс. Так, например, изображенный ниже фрагмент диаграммы компонентов представляет информацию о том, что компонент с именем «main.exe» зависит от импортируемого интерфейса I Dialog, который, в свою очередь, реализуется компонентом с именем «image.java». Для второго компонента этот же интерфейс является экспортируемым.
Рис. 10.4.
Фрагмент диаграммы компонентов с отношением зависимости
Заметим, что изобразить второй компонент с именем «image.java» в форме варианта примечания нельзя именно в силу того факта, что этот компонент реализует интерфейс.
Другим случаем отношения зависимости на диаграмме компонентов является отношение между различными видами компонентов (рис. 10.5). Наличие подобной зависимости означает, что внесение изменений в исходные тексты программ или динамические библиотеки приводит к изменениям самого компонента. При этом характер изменений может быть отмечен дополнительно.
Рис. 10.5.
Графическое изображение отношения зависимости между компонентами
Наконец, на диаграмме компонентов могут быть представлены отношения зависимости между компонентами и реализованными в них классами. Эта информация имеет важное значение для обеспечения согласования логического и физического представлений модели системы. Разумеется, изменения в структуре описаний классов могут привести к изменению компонента. Ниже приводится фрагмент зависимости подобного рода, когда некоторый компонент зависит от соответствующих классов.
Рис. 10.6.
Графическое изображение зависимости между компонентом и классами
Следует заметить, что в данном случае из диаграммы компонентов не следует, что классы реализованы этим компонентом. Если требуется подчеркнуть, что некоторый компонент реализует отдельные классы, то для обозначения компонента используется расширенный символ прямоугольника. При этом прямоугольник компонента делится на две секции горизонтальной линией. Верхняя секция служит для записи имени компонента, а нижняя секция – для указания дополнительной информации (рис. 10.7).
Рис. 10.7.
Графическое изображение компонента с дополнительной информацией о реализуемых им классах
Внутри символа компонента могут изображаться другие элементы графической нотации, такие как классы (компонент уровня типа) или объекты (компонент уровня экземпляра). В этом случае символ компонента изображается таким образом, чтобы вместить эти дополнительные символы. Так, например, изображенный ниже компонент (рис. 10.8) является экземпляром и реализует три отдельных объекта.
Рис. 10.8.
Графическое изображение компонента уровня экземпляра, реализующего отдельные объекты
Объекты, которые находятся в отдельном компоненте-экземпляре, изображаются вложенными в символ данного компонента. Подобная вложенность означает, что выполнение компонента влечет выполнение соответствующих объектов. Другими словами, существование компонента в течение времени исполнения программы обеспечивает существование, а возможно, и доступ всех вложенных в него объектов. Что касается доступа к этим объектам, то он может быть дополнительно специфицирован с помощью квантификаторов видимости, подобно видимости пакетов. Содержательный смысл видимости может отличаться для различных видов пакетов.
Так, для компонентов с исходным текстом программы видимость может означать возможность внесения изменений в соответствующие тексты программ с их последующей перекомпиляцией. Для компонентов с исполняемым кодом программы видимость может характеризовать возможность запуска на исполнение соответствующего компонента или вызова реализованных в нем операций или методов.
Разработка диаграммы компонентов предполагает использование информации как о логическом представлении модели системы, так и об особенностях ее физической реализации. До начала разработки необходимо принять решения о выборе вычислительных платформ и операционных систем, на которых предполагается реализовывать систему, а также о выборе конкретных баз данных и языков программирования.
После этого можно приступать к общей структуризации диаграммы компонентов. В первую очередь, необходимо решить, из каких физических частей (файлов) будет состоять программная система. На этом этапе следует обратить внимание на такую реализацию системы, которая обеспечивала бы не только возможность повторного использования кода за счет рациональной декомпозиции компонентов, но и создание объектов только при их необходимости.
Речь идет о том, что общая производительность программной системы существенно зависит от рационального использования ею вычислительных ресурсов. Для этой цели необходимо большую часть описаний классов, их операций и методов вынести в динамические библиотеки, оставив в исполняемых компонентах только самые необходимые для инициализации программы фрагменты программного кода.
После общей структуризации физического представления системы необходимо дополнить модель интерфейсами и схемами базы данных. При разработке интерфейсов следует обращать внимание на согласование (стыковку) различных частей программной системы. Включение в модель схемы базы данных предполагает спецификацию отдельных таблиц и установление информационных связей между таблицами.
Наконец, завершающий этап построения диаграммы компонентов связан с установлением и нанесением на диаграмму взаимосвязей между компонентами, а также отношений реализации. Эти отношения должны иллюстрировать все важнейшие аспекты физической реализации системы, начиная с особенностей компиляции исходных текстов программ и заканчивая исполнением отдельных частей программы на этапе ее выполнения. Для этой цели можно использовать различные виды графического изображения компонентов.
При разработке диаграммы компонентов следует придерживаться общих принципов создания моделей на языке UML. В частности, в первую очередь необходимо использовать уже имеющиеся в языке UML компоненты и стереотипы. Для большинства типовых проектов этого набора элементов может оказаться достаточно для представления компонентов и зависимостей между ними.
Если же проект содержит некоторые физические элементы, описание которых отсутствует в языке UML, то следует воспользоваться механизмом расширения. В частности, использовать дополнительные стереотипы для отдельных нетиповых компонентов или помеченные значения для уточнения их отдельных характеристик.
В заключение следует обратить внимание, что диаграмма компонентов, как правило, разрабатывается совместно с диаграммой развертывания, на которой представляется информация о физическом размещении компонентов программной системы по ее отдельным узлам. Особенности построения диаграммы развертывания будут рассмотрены в следующей главе.
Примечания:
Примечание 7
В рассмотренном выше примере использовалась одна из принятых нотаций в некоторых языках программирования (например, в Object Pascal) для обозначения принадлежности метода тому или иному классу. В соответствии с этой нотацией, вначале указывается имя класса, в котором определен метод, а затем через точку имя самого метода. Если метод определен в некотором подклассе, то должна быть указана вся цепочка классов, начиная с наиболее общего из них. При этом характерным признаком метода является пара скобок, которые используются для указания списка аргументов или формальных параметров данного метода.
Примечание 72
Применительно к бизнес-системам программные компоненты следует понимать в более широком смысле, чтобы иметь возможность моделирования бизнес-процессов. В этом случае в качестве компонентов рассматриваются отдельные организационные подразделения (отделы, службы) или документы, которые реально существуют в системе.
Примечание 73
Изображение компонента ведет свое происхождение от обозначения модуля программы, применявшегося некоторое время для отображения особенностей инкапсуляции данных и процедур. Так, верхний маленький прямоугольник концептуально ассоциируется с данными, которые реализует этот компонент (ранее он изображался в форме овала). Нижний маленький прямоугольник ассоциируется с операциями или методами, реализуемыми компонентом. В простых случаях имена данных и методов записывались явно в этих маленьких прямоугольниках, однако в языке UML они не указываются.
Примечание 74
Хотя правила именования объектов в языке UML требуют подчеркивания имени отдельных экземпляров, применительно к компонентам в литературе подчеркивание их имени часто опускают. В этом случае запись имени компонента со строчной буквы будет характеризовать компонент уровня экземпляра.
Примечание 75
Характер использования интерфейсов отдельными компонентами может отличаться. Поэтому различают два способа связи интерфейса и компонента. Если компонент реализует некоторый интерфейс, то такой интерфейс называют экспортируемым, поскольку этот компонент предоставляет его в качестве сервиса другим компонентам. Если же компонент использует некоторый интерфейс, который реализуется другим компонентом, то такой интерфейс для первого компонента называется импортируемым. Особенность импортируемого интерфейса состоит в том, что на диаграмме компонентов это отношение изображается с помощью зависимости.
Цель работы:
изучение диаграмм пакетов, диаграммы компонентов и диаграммы размещения,
изучение их применения в процессе проектирования.
Диаграммы пакетов (package diagrams)
Один из важнейших вопросов методологии создания программного обеспечения - как разбить большую систему на небольшие подсистемы? Именно с этой точки зрения изменения, связанные с переходом от структурного подхода к объектно-ориентированному, являются наиболее заметными. Одна из идей заключается в группировке классов в компоненты более высокого уровня. В UML такой механизм группировки носит название пакетов (package).
Диаграммой пакетов является диаграмма, содержащая пакеты классов и зависимости между ними. Строго говоря, пакеты и зависимости являются элементами диаграммы классов, т. е. диаграмма пакетов - это всего лишь форма диаграммы классов. Однако на практике причины построения таких диаграмм различны.
Зависимость между двумя элементами имеет место в том случае, если изменения в определении одного элемента могут повлечь за собой изменение в другом. Что касается классов, то причины зависимостей могут быть самыми разными: один класс посылает сообщение другому; один класс включает часть данных другого класса; один класс ссылается на другой как на параметр операции. Если класс меняет свой интерфейс, то любое сообщение, которое он посылает, может стать неправильным.
В идеальном случае только изменения в интерфейсе класса должны воздействовать на другие классы. Искусство проектирования больших систем включает в себя минимизацию зависимостей, которая снижает воздействие изменений и требует меньше усилий на их внесение.
На рис. 14.1 мы имеем дело с классами предметной области, моделирующими деятельность организации и сгруппированными в два пакета: «Клиенты» и «Заказы».
Рис. 14.1.
Классы предметной области, моделирующие деятельность организации
«Приложение сбора заказов» имеет зависимости с обоими пакетами предметной области. «Пользовательский интерфейс сбора заказов» имеет зависимости с «Приложением сбора заказов» и «Библиотекой GUI».
Зависимость между двумя пакетами существует в том случае, если имеется какая-либо зависимость между любыми двумя классами в пакетах. Например, если любой класс в пакете «Список рассылки» зависит от какого-либо класса в пакете «Клиенты», то между соответствующими пакетами существует зависимость.
Пакеты являются жизненно необходимым средством для больших проектов. Их следует использовать в тех случаях, когда диаграмма классов, охватывающая всю систему в целом и размещенная на единственном листе бумаги формата А4, становится трудночитаемой.
Пакеты не дают ответа на вопрос, каким образом можно уменьшить количество зависимостей в разрабатываемой системе, однако они помогают выделить эти зависимости. Сведение к минимуму количества зависимостей позволяет снизить связанность компонентов системы. Но эвристический подход к этому процессу далек от идеала.
Пакеты особенно полезны при тестировании. Каждый пакет при тестировании может содержать один или несколько тестовых классов, с помощью которых проверяется поведение пакета.
Диаграммы компонентов (component diagrams)
Компоненты на диаграмме компонентов представляют собой физические модули программного кода (рис. 14.2). Обычно они в точности соответствуют пакетам на диаграмме пакетов (см. рис. 14.1); таким образом, диаграмма компонентов отражает выполнение каждого пакета в системе.
Рис. 14.2.
Зависимости между компонентами должны совпадать с зависимостями между пакетами. Эти зависимости показывают, каким образом одни компоненты взаимодействуют с другими. Направление данной зависимости показывает уровень осведомленности о коммуникации. Если на панелях инструментов диаграмм размещения отсутствуют некоторые значки, то их можно настроить вызвав диалоговое окно View/Toolbar/Configure/Toolbars/Component Diagrams
Таблица 14.1.
Описание кнопок панели инструментов диаграмм компонентов Rational Rose
Кнопка
Описание
Название
Выбор элемента модели
Select tool
Ввод текста
Text Box
Комментарий
Note
Связь комментария с элементом
Anchor Note to Item
Компонент
Component
Пакет
Package
Зависимость
Dependency
Тело задания
Task Body
Спецификация задания
Task Specification
Тело пакета
Package Body
Спецификация пакета
Package Specification
Главная программа
Main Program
Спецификация подпрограммы
Subprogram Specification
Тело попдпрограммы
Subprogram Body
Диаграммы размещения (deployment diagrams)
Диаграмма размещения отражает физические взаимосвязи между программными и аппаратными компонентами системы. Она является хорошим средством для того, чтобы показать маршруты перемещения объектов и компонентов в распределенной системе.
Каждый узел на диаграмме размещения представляет собой некоторый тип вычислительного устройства - в большинстве случаев часть аппаратуры. Эта аппаратура может быть простым устройством или датчиком, а может быть и большим компьютером.
На рис. 14.3 изображен персональный компьютер (ПК), связанный с UNIX-сервером посредством протокола TCP/IP. Соединения между узлами показывают коммуникационные каналы, с помощью которых осуществляются системные взаимодействия.
Рис. 14.3.
На практике данные диаграммы применяются не слишком часто. В целом эти диаграммы полезно применять, чтобы выделить особенные физические характеристики данной системы. По мере распространения распределенных систем важность данных диаграмм возрастает.
Таблица 14.2.
Описание кнопок панели инструментов диаграмм размещения Rational Rosee
Примеры
Проводить сравнение диаграмм пакетов, компонентов и размещения в общем случае бессмысленно, так как эти диаграммы не существуют сами по себе, а являются интерпретацией некоторой диаграммы классов, для которой и уместно проводить сравнение с другими диаграммами классов.
Диаграммы пакетов содержат один тип элементов - пакет и один тип связей - зависимость, поэтому численная оценка для диаграммы пакетов не столь важна, как для диаграммы классов.
На рис. 14.4 изображена диаграмма пакетов подсистемы «Служба занятости в рамках вуза» системы «Дистанционное обучение». Численная оценка для нее равна:
Рис.
14.4. Диаграмма пакетов
Диаграммы компонентов и размещения строятся и используются на этапе реализации и сопровождения, когда базовая архитектура системы уже обычно определена; поэтому они однозначно получаются из диаграммы классов и для них достаточно привести по одному примеру.
Рис. 14.5
. Диаграмма компонентов
На рис. 14.5 изображена диаграмма компонентов, построенная на основе диаграммы пакетов, изображенной на рис. 14.4. На рис. 14.6 изображена диаграмма размещения подсистемы «Служба занятости в рамках вуза». Оценка для данной диаграммы компонентов равна:
Оценка для диаграммы размещения равна:
Рис. 14.6.
Диаграмма размещения
Упражнения
Упражнение 1.
Создание диаграммы размещения системы регистрации
Распределенная конфигурация системы моделируется с помощью диаграммы размещения. Ее основные элементы:
узел (node) - вычислительный ресурс (процессор или другое устройство (дисковая память, контроллеры различных устройств и т.д.). Для узла можно задать выполняющиеся на нем процессы;
соединение (connection) - канал взаимодействия узлов (сеть).
Пример: сетевая конфигурация системы регистрации (без процессов) (рис. 14.7).
Ри
с.
14.7.
Сетевая конфигурация системы регистрации
Распределение процессов по узлам сети производится с учетом следующих факторов:
надежность оборудования и коммуникаций. Пример: распределение процессов по узлам (рис. 14.8).
Рис.
14.8.
Сетевая конфигурация системы регистрации с распределением
Для того чтобы открыть диаграмму размещения, надо дважды щелкнуть мышью по представлению Deployment View (представлению размещения) в браузере. Для того чтобы поместить на диаграмму процессор:
На панели инструментов диаграммы нажмите кнопку Processor.
Щелкните по диаграмме размещения в том месте, куда хотите поместить процессор.
Введите имя процессора.
В спецификациях процессора можно ввести информацию о его стереотипе, характеристиках и планировании. Стереотипы применяются для классификации процессоров (например, компьютеров под управлением UNIX или ПК). Характеристики процессора - это его физическое описание. Оно может, в частности, включать скорость процессора и объем памяти.
Поле планирования (scheduling) процессора содержит описание того, как осуществляется планирование его процессов
Preemptive (с приоритетом).
Высокоприоритетные процессы имеют преимущество перед низкоприоритетными.
Non preemptive (без приоритета).
У процессов не имеется приоритета. Текущий процесс выполняется до его завершения, после чего начинается следующий.
Cyclic (циклический).
Управление передается между процессами по кругу. Каждому процессу дается определенное время на его выполнение, затем управление переходит к следующему процессу.
Executive (исполнительный).
Существует некоторый вычислительный алгоритм, который и управляет планированием процессов.
Manual
(вручную).
Процессы планируются пользователем.
Для того чтобы назначить процессору стереотип.
Перейдите на вкладку General.
Введите стереотип в поле Stereotype.
Для введения характеристик и планирования процессора
Откройте окно спецификации процессора.
Перейдите на вкладку Detail.
Введите характеристики в поле характеристик.
Укажите один из типов планирования.
Для того чтобы показать планирование на диаграмме:
Выберите пункт Show Scheduling в открывшемся меню.
Для того чтобы добавить связь на диаграмму:
На панели инструментов нажмите кнопку Connection.
Щелкните по узлу диаграммы.
Проведите линию связи к другому узлу.
Для того чтобы назначить связи стереотипа:
Откройте окно спецификации связи.
Перейдите на вкладку General.
Введите стереотип в поле Stereotype (Стереотип).
Для того чтобы добавить процесс:
Щелкните правой кнопкой мыши по процессору в браузере.
В чем отличие диаграмм пакетов от диаграмм классов?
В чем смысл зависимости между элементами диаграммы пакетов?
Что такое интерфейс класса?
По каким признакам классы группируются в пакеты?
Какие виды элементов модели представлены на диаграмме компонентов?
Как связаны между собой диаграммы пакетов и диаграммы компонентов?
Что показывает диаграмма размещения?
Какие сущности.отображаются на диаграммах-размещения?
10. В каких случаях необходимо применение диаграмм размещения?
Аннотация:
Назначение диаграммы компонентов, ее основные элементы. Особенности физического представления программных систем. Компоненты программных систем, их разновидности. Интерфейсы, их реализация компонентами. Использование диаграммы компонентов для проектирования зависимостей между компонентами. Рекомендации по построению диаграммы компонентов.
Диаграмма компонентов и особенности ее построения
Все рассмотренные ранее диаграммы отражали концептуальные и логические аспекты построения модели системы. Особенность логического представления заключается в том, что оно оперирует понятиями, которые не имеют материального воплощения. Другими словами, различные элементы логического представления, такие как классы, ассоциации, состояния, сообщения, не существуют материально или физически. Они лишь отражают понимание статической структуры той или иной системы или динамические аспекты ее поведения.
Для создания конкретной физической системы необходимо реализовать все элементы логического представления в конкретные материальные сущности. Для описания таких реальных сущностей предназначен другой аспект модельного представления, а именно – физическое представление
модели. В контексте языка UML
это означает совокупность связанных физических сущностей, включая программное и аппаратное обеспечение, а также персонал, которые организованы для выполнения специальных задач.
Физическая система
( physical system
) - реально существующий прототип модели системы.
С тем чтобы пояснить отличие логического и физического представлений, необходимо в общих чертах рассмотреть процесс разработки программной системы. Ее исходным логическим представлением могут служить структурные схемы алгоритмов и процедур, описания интерфейсов и концептуальные схемы баз
данных. Однако для реализации этой системы необходимо разработать исходный текст программы на языке программирования. При этом уже в тексте программы предполагается организация программного кода, определяемая синтаксисом языка программирования и предполагающая разбиение
исходного кода на отдельные модули.
Однако исходные тексты программы еще не являются окончательной реализацией проекта, хотя и служат фрагментом его физического представления. Программная система может считаться реализованной в том случае, когда она будет способна выполнять функции своего целевого предназначения. А это возможно, только если программный код системы будет реализован в форме исполняемых модулей, библиотек классов и процедур, стандартных графических интерфейсов, файлов баз данных. Именно эти компоненты являются базовыми элементами физического представления системы в нотации языка UML
.
Полный проект программной системы представляет собой совокупность моделей логического и физического представлений, которые должны быть согласованы между собой. В языке UML
для физического представления моделей систем используются так называемые диаграммы реализации, которые включают в себя две отдельные канонические диаграммы
: диаграмму компонентов и диаграмму развертывания
.
Диаграмма
компонентов
, в отличие от ранее рассмотренных диаграмм, описывает особенности физического представления системы. Диаграмма
компонентов
позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами
, в роли которых может выступать исходный, бинарный и исполняемый код
. Во многих средах разработки модуль
или компонент
соответствует файлу. Пунктирные стрелки, соединяющие модули
, показывают отношения взаимозависимости, аналогичные тем, которые имеют место
при компиляции исходных текстов программ. Основными графическими элементами диаграммы компонентов
являются компоненты
, интерфейсы
и зависимости между ними.
В разработке диаграмм компонентов
участвуют как системные аналитики и архитекторы, так и программисты. Диаграмма
компонентов
обеспечивает согласованный переход от логического представления к конкретной реализации проекта в форме программного кода. Одни компоненты
могут существовать только на этапе компиляции программного кода, другие – на этапе его исполнения. Диаграмма
компонентов
отражает общие зависимости между компонентами
, рассматривая последние в качестве отношений между ними.
Компоненты
Для представления физических сущностей в языке UML
применяется специальный термин – компонент
.
Компонент
(component) - физически существующая часть системы, которая обеспечивает реализацию классов и отношений, а также функционального поведения моделируемой программной системы.
Компонент
предназначен для представления физической организации ассоциированных с ним элементов модели. Дополнительно компонент
может иметь текстовый стереотип и помеченные значения
, а некоторые компоненты
– собственное графическое представление
. Компонентом
может быть исполняемый код
отдельного модуля
, командные файлы или файлы, содержащие интерпретируемые скрипты.
Компонент
служит для общего обозначения элементов физического представления модели и может реализовывать некоторый набор интерфейсов
. Для графического представления компонента
используется специальный символ
– прямоугольник
со вставленными слева двумя более мелкими прямоугольниками (рис. 12.1) . Внутри объемлющего прямоугольника записывается имя компонента
и, возможно, дополнительная информация
. Этот символ является базовым обозначением компонента
в языке UML
.
Рис.
12.1.
Графическое изображение компонента
ведет свое происхождение от обозначения модуля
программы, применявшегося некоторое время для отображения особенностей инкапсуляции данных
и процедур.
Модуль
(module) - часть программной системы, требующая памяти для своего хранения и процессора для исполнения.
В этом случае верхний маленький прямоугольник
концептуально ассоциировался с данными, которые реализует этот компонент
(иногда он изображается в форме овала). Нижний маленький прямоугольник
ассоциировался с операциями или методами, реализуемыми компонентом
. В простых случаях имена данных и методов записывались явно в маленьких прямоугольниках, однако в языке UML
они не указываются.
Имя компонента
подчиняется общим правилам именования элементов модели в языке UML
и может состоять из любого числа букв, цифр и знаков препинания. Отдельный компонент
может быть представлен на уровне типа или экземпляра. И хотя его графическое изображение в обоих случаях одинаково, правила записи имени компонента
несколько отличаются.
Если компонент
представляется на уровне типа, то записывается только имя типа с заглавной буквы в форме: <Имя типа>. Если же компонент
представляется на уровне экземпляра, то его имя записывается в форме: <имя компонента
‘:" Имя типа>. При этом вся строка имени подчеркивается. Так, в первом случае (рис. 12.1, а) для компонента
уровня типов указывается имя типа, а во втором (рис. 12.1, б) для компонента
уровня экземпляра – собственное имя компонента
и имя типа.
Правила именования объектов в языке UML
требуют подчеркивания имени отдельных экземпляров, но применительно к компонентам
подчеркивание их имени часто опускают. В этом случае запись
имени компонента
со строчной буквы характеризует компонент
уровня примеров.
В качестве собственных имен компонентов
принято использовать имена исполняемых файлов, динамических библиотек, Web-страниц, текстовых файлов или файлов справки, файлов баз данных или файлов с исходными текстами программ, файлов скриптов и другие.
В отдельных случаях к простому имени компонента
может быть добавлена информация
об имени объемлющего пакета и о конкретной версии реализации данного компонента
. Необходимо заметить, что в этом случае номер версии записывается как помеченное значение
в фигурных скобках. В других случаях символ компонента
может быть разделен на секции, чтобы явно указать имена реализованных в нем классов или интерфейсов
. Такое обозначение компонента
называется расширенным
.
Поскольку компонент
как элемент модели может иметь различную физическую реализацию, иногда его изображают в форме специального графического символа, иллюстрирующего конкретные особенности реализации. Строго говоря, эти дополнительные обозначения не специфицированы в нотации языка UML
. Однако, удовлетворяя общим механизмам расширения языка UML
, они упрощают понимание диаграммы компонентов
, существенно повышая наглядность графического представления.
Для более наглядного изображения компонентов
были предложены и стали общепринятыми следующие графические стереотипы:
Во-первых, стереотипы для компонентов
развертывания, которые обеспечивают непосредственное выполнение системой своих функций. Такими компонентами
могут быть динамически подключаемые библиотеки компонентов
. Более того, разработчики могут для этой цели использовать самостоятельные обозначения, поскольку в языке UML
нет строгой нотации для графического представления артефактов.
Другой способ спецификации различных видов компонентов
- указание текстового стереотипа компонента
перед его именем. В языке UML
для компонентов
определены следующие стереотипы:
<> (файл) – определяет наиболее общую разновидность компонента
, который представляется в виде произвольного физического файла.
<> (исполнимый) – определяет разновидность компонента-файла, который является исполнимым файлом и может выполняться на компьютерной платформе.
<> (документ) – определяет разновидность компонента-файла, который представляется в форме документа произвольного содержания, не являющегося исполнимым файлом или файлом с исходным текстом программы.
<> (библиотека) – определяет разновидность компонента-файла, который представляется в форме динамической или статической библиотеки.
<> (источник) – определяет разновидность компонента-файла, представляющего собой файл с исходным текстом программы, который после компиляции может быть преобразован в исполнимый файл.
<
> (таблица) – определяет разновидность компонента
, который представляется в форме таблицы базы данных.
Отдельными разработчиками предлагались собственные графические стереотипы для изображения тех или иных типов компонентов
, однако, за небольшим исключением они не нашли широкого применения. В свою очередь
ряд инструментальных CASE-средств также содержат дополнительный набор графических стереотипов для обозначения компонентов
.
В настоящее время язык UML - это стандартная нотация визуального моделирования программных систем, принятая консорциумом Object Managing Group (OMG) осенью 1997 г., которая поддерживается многими объектно-ориентированными CASE-продуктами.
Стандарт UML предлагает следующий набор диаграмм для моделирования:
· диаграмма вариантов использования (use case diagram) – для моделирования бизнес-процессов организации или предприятия и определения требований к создаваемой информационной системе;
· диаграмма классов (class diagram) – для моделирования статической структуры классов системы и связей между ними;
· диаграмма поведения системы (behavior diagrams);
· диаграмма взаимодействия (interaction diagrams);
· диаграмма последовательности (sequence diagrams) – для моделирования процесса обмена сообщениями между объектами в рамках одного варианта использования;
· диаграмма кооперации (collaboration diagram) – для моделирования процесса обмена сообщениями между объектами в рамках одного варианта использования;
· диаграмма состояний (statechart diagram) – для моделирования поведения объектов системы при переходе из одного состояния в другое;
· диаграмма видов деятельности (activity diagram) – для моделирования поведения системы в рамках различных вариантов использования, или моделирования деятельностей;
· диаграмма развертывания (deployment diagram) – для моделирования физической архитектуры спроектированной информационной системы.
На рис. 1.1 представлена интегрированная модель информационной системы, включающая основные диаграммы, которые должны быть разработаны в данном курсовом проекте.
Рис. 1. Интегрированная модель информационной системы в нотации языка UML
4.2. Диаграмма вариантов использования
Вариант использования представляет собой последовательность действий, выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (актером). Вариант использования описывает типичное взаимодействие между пользователем и системой. В простейшем случае вариант использования определяется в процессе обсуждения с пользователем тех функций, которые он хотел бы реализоватьв данной информационной системе. На языке UML вариант использования изображают следующим образом:
Рис.2. Вариант использования
Актер (actor) – это роль, которую пользователь играет по отношению к системе. Актеры представляют собой роли, а не конкретных людей или наименования работ. Несмотря на то, что на диаграммах вариантов использования они изображаются в виде стилизованных человеческих фигурок, актер может также быть внешней информационной системой, которой необходима некоторая информация от данной системы. Показывать на диаграмме актеров следует только в том случае, когда им действительно необходимы некоторые варианты использования. На языке UML актеры представляют в виде фигур:
Рис.3. Действующее лицо (актер)
Актеры делятся на три основных типа:
· пользователи;
· системы;
· другие системы, взаимодействующие с данной;
Время становится актером, если от него зависит запуск каких-либо событий в системе.
4.2.1. Связи между вариантами использования и актерами
В языке UML на диаграммах вариантов использования поддерживается несколько типов связей между элементами диаграммы:
· коммуникация (communication),
· включение (include),
· расширение (extend),
· обобщение (generalization).
Связь коммуникации
– это связь между вариантом использования и актером. На языке UML связи коммуникации показывают с помощью однонаправленной ассоциации (сплошной линии).
Рис.4. Пример связи коммуникации
Связь включения
применяется в тех ситуациях, когда имеется какой-либо фрагмент поведения системы, который повторяется более чем в одном варианте использования. С помощью таких связей обычно моделируют многократно используемую функцию.
Связь расширения
применяется при описании изменений в нормальном поведении системы. Она позволяет одному варианту использования при необходимости использовать функциональные возможности другого варианта использования.
Рис.5. Пример связи включения и расширения
Связь обобщения
показывает, что у нескольких актеров или классов имеются общие свойства.
Рис.6. Пример связи обобщения
4.3.
Диаграммы взаимодействия (interaction diagrams)
описывают поведение взаимодействующих групп объектов. Как правило, диаграмма взаимодействия охватывает поведение объектов в рамках только одного варианта использования. На такой диаграмме отображается ряд объектов и те сообщения, которыми они обмениваются между собой.
Сообщение (message)
– это средство, с помощью которого объект-отправитель запрашивает у объекта получателя выполнение одной из его операций.
Информационное (informative) сообщение
– это сообщение, снабжающее объект-получатель некоторой информацией для обновления его состояния.
Сообщение-запрос (interrogative)
– это сообщение, запрашивающее выдачу некоторой информации об объекте-получателе.
Императивное (imperative) сообщение
– это сообщение, запрашивающее у объекта-получателя выполнение некоторых действий.
Существует два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagrams) и диаграммы кооперац (collaboration diagrams).
Диаграмма последовательности
отражает поток событий, происходящих в рамках одного варианта использования.
Все действующие лица (актеры, классы или объекты), участвующие в данном сценарии (варианте использования), показываются в верхней части диаграммы. Стрелки соответствуют сообщениям, передаваемым между актером и объектом или между объектами для выполнения требуемых функций.
На диаграмме последовательности объект изображается в виде прямоугольника, от которого вниз проведена пунктирная вертикальная линия. Эта линия называется линией жизни (lifeline) объекта
. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия.
Каждое сообщение представляется в виде стрелки между линиями жизни двух объектов. Сообщения появляются в том порядке, как они показаны на странице сверху вниз. Каждое сообщение помечается как минимум именем сообщения. При желании можно добавить также аргументы и некоторую управляющую информацию. Можно показать самоделегирование (self-delegation) – сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни.
Диаграммы кооперации
отображают поток событий в рамках конкретного сценария (варианта использования). Сообщения упорядочены по времени, хотя диаграммы кооперации больше внимания заостряют на связях между объектами. На диаграмме кооперации представлена вся та информация, которая есть и на диаграмме последовательности, но диаграмма кооперации по-другому описывает поток событий. Из нее легче понять связи, существующие между объектами.
На диаграмме кооперации так же, как и на диаграмме последовательности, стрелки обозначают сообщения, обмен которыми осуществляется в рамках данного варианта использования. Их временная последовательность указывается путем нумерации сообщений.
Рис. 8. Пример диаграммы кооперации
4.4. Диаграмма классов
4.4.1. Общие сведения
Диаграмма классов
определяет типы классов системы и различного рода статические связи, которые существуют между ними. На диаграммах классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами.
Диаграмма классов в языке UML - это граф, узлами которого являются элементы статической структуры проекта (классы, интерфейсы), а дугами - отношения между узлами (ассоциации, наследование, зависимости).
На диаграмме классов изображаются следующие элементы:
· Пакет (package) - набор элементов модели, логически связанных между собой;
· Класс (class) - описание общих свойств группы сходных объектов;
· Интерфейс (interface) - абстрактный класс, задающий набор операций, которые объект произвольного класса, связанного с данным интерфейсом, предоставляет другим объектам.
4.4.2. Класс
Класс
- это группа сущностей (объектов), обладающих сходными свойствами, а именно, данными и поведением. Отдельный представитель некоторого класса называется объектом класса или просто объектом.
Под поведением объекта в UML понимаются любые правила взаимодействия объекта с внешним миром и с данными самого объекта.
На диаграммах класс изображается в виде прямоугольника со сплошной границей, разделенного горизонтальными линиями на 3 секции:
Верхняя секция (секция имени) содержит имя класса и другие общие свойства (в частности, стереотип).
В средней секции содержится список атрибутов
В нижней - список операций класса, отражающих его поведение (действия, выполняемые классом).
Любая из секций атрибутов и операций может не изображаться (а также обе сразу). Для отсутствующей секции не нужно рисовать разделительную линию и как-либо указывать на наличие или отсутствие элементов в ней.
На усмотрение конкретной реализации могут быть введены дополнительные секции, например, исключения (Exceptions).
Рис. 9. Пример диаграммы классов
4.4.2.1.Стереотипы классов
Стереотипы классов – это механизм, позволяющий разделять классы на категории.
В языке UML определены три основных стереотипа классов:
Boundary (граница);
Entity (сущность);
Control (управление).
4.4.2.2.Граничные классы
Граничными классами (boundary classes) называются такие классы, которые расположены на границе системы и всей окружающей среды. Это экранные формы, отчеты, интерфейсы с аппаратурой (такой как принтеры или сканеры) и интерфейсы с другими системами.
Чтобы найти граничные классы, надо исследовать диаграммы вариантов использования. Каждому взаимодействию между действующим лицом и вариантом использования должен соответствовать, по крайней мере, один граничный класс. Именно такой класс позволяет действующему лицу взаимодействовать с системой.
4.4.2.3.Классы-сущности
Классы-сущности (entity classes) содержат хранимую информацию. Они имеют наибольшее значение для пользователя, и потому в их названиях часто используют термины из предметной области. Обычно для каждого класса-сущности создают таблицу в базе данных.
4.4.2.4.Управляющие классы
Управляющие классы (control classes) отвечают за координацию действий других классов. Обычно у каждого варианта использования имеется один управляющий класс, контролирующий последовательность событий этого варианта использования. Управляющий класс отвечает за координацию, но сам не несет в себе никакой функциональности, так как остальные классы не посылают ему большого количества сообщений. Вместо этого он сам посылает множество сообщений. Управляющий класс просто делегирует ответственность другим классам, по этой причине его часто называют классом-менеджером.
В системе могут быть и другие управляющие классы, общие для нескольких вариантов использования. Например, может быть класс SecurityManager (менеджер безопасности), отвечающий за контроль событий, связанных с безопасностью. Класс TransactionManager (менеджер транзакций) занимается координацией сообщений, относящихся к транзакциям с базой данных. Могут быть и другие менеджеры для работы с другими элементами функционирования системы, такими как разделение ресурсов, распределенная обработка данных или обработка ошибок.
Помимо упомянутых выше стереотипов можно создавать и свои собственные.
4.4.2.5.Атрибуты
Атрибут – это элемент информации, связанный с классом. Атрибуты хранят инкапсулированные данные класса.
Так как атрибуты содержатся внутри класса, они скрыты от других классов. В связи с этим может понадобиться указать, какие классы имеют право читать и изменять атрибуты. Это свойство называется видимостью атрибута (attribute visibility).
У атрибута можно определить четыре возможных значения этого параметра:
Public (общий, открытый). Это значение видимости предполагает, что атрибут будет виден всеми остальными классами. Любой класс может просмотреть или изменить значение атрибута. В соответствии с нотацией UML общему атрибуту предшествует знак « + ».
Private (закрытый, секретный). Соответствующий атрибут не виден никаким другим классом. Закрытый атрибут обозначается знаком « – » в соответствии с нотацией UML.
Protected (защищенный). Такой атрибут доступен только самому классу и его потомкам. Нотация UML для защищенного атрибута – это знак « # ».
Package or Implementation (пакетный). Предполагает, что данный атрибут является общим, но только в пределах его пакета. Этот тип видимости не обозначается никаким специальным значком.
С помощью закрытости или защищенности удается избежать ситуации, когда значение атрибута изменяется всеми классами системы. Вместо этого логика изменения атрибута будет заключена в том же классе, что и сам этот атрибут. Задаваемые параметры видимости повлияют на генерируемый код.
4.4.2.6.Операции
Операции реализуют связанное с классом поведение. Операция включает три части – имя, параметры и тип возвращаемого значения.
Параметры – это аргументы, получаемые операцией «на входе». Тип возвращаемого значения относится к результату действия операции.
На диаграмме классов можно показывать как имена операций, так и имена операций вместе с их параметрами и типом возвращаемого значения. Чтобы уменьшить загруженность диаграммы, полезно бывает на некоторых из них показывать только имена операций, а на других их полную сигнатуру.
В языке UML операции имеют следующую нотацию:
Имя Операции (аргумент: тип данных аргумента, аргумент2:тип данных аргумента2,...): тип возвращаемого значения
Следует рассмотреть четыре различных типа операций:
Операции реализации;
Операции управления;
Операции доступа;
Вспомогательные операции.
Операции реализации
Операции реализации (implementor operations) реализуют некоторые бизнес-функции. Такие операции можно найти, исследуя диаграммы взаимодействия. Диаграммы этого типа фокусируются на бизнес-функциях, и каждое сообщение диаграммы, скорее всего, можно соотнести с операцией реализации.
Каждая операция реализации должна быть легко прослеживаема до соответствующего требования. Это достигается на различных этапах моделирования. Операция выводится из сообщения на диаграмме взаимодействия, сообщения исходят из подробного описания потока событий, который создается на основе варианта использования, а последний – на основе требований. Возможность проследить всю эту цепочку позволяет гарантировать, что каждое требование будет реализовано в коде, а каждый фрагмент кода реализует какое-то требование.
Операции управления
Операции управления (manager operations) управляют созданием и уничтожением объектов. В эту категорию попадают конструкторы и деструкторы классов.
Операции доступа
Атрибуты обычно бывают закрытыми или защищенными. Тем не менее, другие классы иногда должны просматривать или изменять их значения. Для этого существуют операции доступа (access operations). Такой подход дает возможность безопасно инкапсулировать атрибуты внутри класса, защитив их от других классов, но все же позволяет осуществить к ним контролируемый доступ. Создание операций Get и Set (получения и изменения значения) для каждого атрибута класса является стандартом.
Вспомогательные операции
Вспомогательными (helper operations) называются такие операции класса, которые необходимы ему для выполнения его ответственностей, но о которых другие классы не должны ничего знать. Это закрытые и защищенные операции класса.
Чтобы идентифицировать операции, выполните следующие действия:
1. Изучите диаграммы последовательности и кооперативные диаграммы. Большая часть сообщений на этих диаграммах является операциями реализации. Рефлексивные сообщения будут вспомогательными операциями.
2. Рассмотрите управляющие операции. Может потребоваться добавить конструкторы и деструкторы.
3. Рассмотрите операции доступа. Для каждого атрибута класса, с которым должны будут работать другие классы, надо создать операции Get и Set.
4.4.2.7.Связи
Связь представляет собой семантическую взаимосвязь между классами. Она дает классу возможность узнавать об атрибутах, операциях и связях другого класса. Иными словами, чтобы один класс мог послать сообщение другому на диаграмме последовательности или кооперативной диаграмме, между ними должна существовать связь.
Существуют четыре типа связей, которые могут быть установлены между классами: ассоциации, зависимости, агрегации и обобщения.
Связь ассоциация
Ассоциация (association) – это семантическая связь между классами. Их рисуют на диаграмме классов в виде обыкновенной линии.
Рис. 10. Связь ассоциация
Ассоциации могут быть двунаправленными, как в примере, или однонаправленными. На языке UML двунаправленные ассоциации рисуют в виде простой линии без стрелок или со стрелками с обеих ее сторон. На однонаправленной ассоциации изображают только одну стрелку, показывающую ее направление.
Направление ассоциации можно определить, изучая диаграммы последовательности и кооперативные диаграммы. Если все сообщения на них отправляются только одним классом и принимаются только другим классом, но не наоборот, между этими классами имеет место однонаправленная связь. Если хотя бы одно сообщение отправляется в обратную сторону, ассоциация должна быть двунаправленной.
Ассоциации могут быть рефлексивными. Рефлексивная ассоциация предполагает, что один экземпляр класса взаимодействует с другими экземплярами этого же класса.
Связь зависимость
Связи зависимости (dependency) также отражают связь между классами, но они всегда однонаправлены и показывают, что один класс зависит от определений, сделанных в другом. Например, класс A использует методы класса B. Тогда при изменении класса B необходимо произвести соответствующие изменения в классе A.
Зависимость изображается пунктирной линией, проведенной между двумя элементами диаграммы, и считается, что элемент, привязанный к концу стрелки, зависит от элемента, привязанного к началу этой стрелки.
Рис. 11. Связь зависимость
При генерации кода для этих классов к ним не будут добавляться новые атрибуты. Однако, будут созданы специфические для языка операторы, необходимые для поддержки связи.
Связь агрегация
Агрегации (aggregations) представляют собой более тесную форму ассоциации. Агрегация – это связь между целым и его частью. Например, у вас может быть класс Автомобиль, а также классы Двигатель, Покрышки и классы для других частей автомобиля. В результате объект класса Автомобиль будет состоять из объекта класса Двигатель, четырех объектов Покрышек и т. д. Агрегации визуализируют в виде линии с ромбиком у класса, являющегося целым:
Рис. 11. Связь агрегация
В дополнение к простой агрегации UML вводит более сильную разновидность агрегации, называемую композицией. Согласно композиции, объект-часть может принадлежать только единственному целому, и, кроме того, как правило, жизненный цикл частей совпадает с циклом целого: они живут и умирают вместе с ним. Любое удаление целого распространяется на его части.
Такое каскадное удаление нередко рассматривается как часть определения агрегации, однако оно всегда подразумевается в том случае, когда множественность роли составляет 1..1; например, если необходимо удалить Клиента, то это удаление должно распространиться и на Заказы (и, в свою очередь, на Строки заказа).
Компоненты связываются через зависимости, когда соединяется требуемый интерфейс одного компонента с имеющимся интерфейсом другого компонента. Таким образом иллюстрируются отношения клиент-источник между двумя компонентами.
Диаграмма развертывания содержит графические изображения процессоров, устройств, процессов и связей между ними. В отличие от диаграмм логического представления, диаграмма развертывания является единой для системы в целом, поскольку должна всецело отражать особенности ее реализации. Разработка диаграммы развертывания, как правило, является последним этапом спецификации модели программной системы.
