Задания, лекции / Червенчук

Аннотационные сущности – пояснительные части модели UML. Аннотационные сущности – это не что иное,

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

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

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

В языке UML определены четыре базовых типа отношений: зависимость; ассоциация; обобщение; реализация.

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

Зависимость (Dependency) – это семантиче-

ское отношение между двумя сущностями, при котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой. Графи-

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

симыми элементами.

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

21

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

Обобщение (Generalization) – это отношение

«специализация/обобщение», при котором объект специализированного элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (родителя или предка). Таким образом,

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

Реализация (Realization) – это семантическое отношение между классификаторами, при котором один классификатор определяет «контракт», а другой гарантирует его выполнение. Отношения реали-

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

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

На рис. 1.17 показаны базовые типы отношений UML. Абстрактный класс Персона включает общие атрибуты для студентов и преподавателей, которые наследуют их. Класс Персона в качестве атрибута использует экземпляр структуры TAdress, поэтому между данными классами существует отношение зависимости. Аналогично отношения зависимости ставятся между классом Преподаватель и перечислениями Т_Уч степень (ученая степень) и Т_Уч звание (ученое звание).

22

Обобщение

Рис. 1.17. Типы отношений UML

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

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

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

23

которые составляют архитектуру программной системы. Таким образом,

вUML выделяют девять типов диаграмм:

‒классов;

‒объектов;

‒прецедентов;

‒последовательностей;

‒кооперации;

‒состояний;

‒деятельности;

‒компонентов;

‒развертывания.

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

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

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

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

24

На диаграммах состояний (Statechart diagrams) представлен автомат,

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

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

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

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

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

понентов – диаграмма WEB-приложения.

1.2. ПРАВИЛА ЯЗЫКА UML

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

25

В языке UML имеются семантические правила, позволяющие корректно

иоднозначно определять:

‒имена, которые можно давать сущностям, отношениями диаграммам;

‒областьдействия(контекст, вкоторомимяимеетнекотороезначение);

‒видимость (когда имена видимы и могут использоваться другими элементами);

‒целостность (как элементы должны правильно и согласованно соотноситься друг с другом);

‒выполнение (что значит выполнить или имитировать некоторую динамическую модель).

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

‒содержат скрытые элементы (ряд элементов не показывают, чтобы упростить восприятие);

‒неполные (отдельные элементы пропущены);

‒несогласованные (целостность модели не гарантируется). Появление не слишком хорошо оформленных моделей является обыч-

ным делом в процессе разработки, пока не все детали системы прояснились в полной мере.

1.3. ОБЩИЕ МЕХАНИЗМЫ ЯЗЫКА UML

Разработка упрощается и ведется более эффективно, если придерживаться некоторых соглашений. Следуя определенным архитектурным образцам, можно оформить проект в том или ином стиле. Данный принцип применим и в отношении UML-проектов. Работу с этим языком существенно облегчает последовательное использование общих механизмов, перечисленных ниже:

‒спецификации (Specifications);

‒дополнения (Adornments);

‒принятые деления (Common divisions);

‒механизмы расширения (Extensibility mechanisms).

26

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

иоперации классов) и, наконец, уделить внимание деталям модели (определить свойства атрибутов и операций, параметры операций). Возможен

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

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

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

27

Спецификация класса может содержать описание свойств атрибутов

иопераций, например, видимость или указание на то, что класс является абстрактным. Подобные детали можно визуализировать в виде графических или текстовых дополнений основного изображения. Так, на рис. 1.18 показан класс, в обозначение которого включены сведения о том, что он имеет три открытых (знак «+») атрибута с указанными типами и три открытые операции с параметрами.

Принятые деления. Весь моделируемый средствами объектно ориентированного анализа мир можно разделить с одной стороны на классы

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

Врамках первого деления класс – это абстракция, объект – конкретная материализация этой абстракции. В языке UML можно моделировать как классы, так и объекты. Имя объекта подчеркивается.

На рис. 1.19 показан один класс Customer (Клиент) и три объекта: Jan (явно определенный как объект данно-

го класса), Customer (анонимный объект класса Customer) и Elyse (без явного указания принадлежности к классу). Дихотомия «класс/объект» присуща не только классам. Так, имеются прецеденты и экземпляры прецедентов (сценарии), компоненты и экземпляры компонентов, узлы и экземпляры узлов и т. д. В графическом представлении для экземпляра сущности принято использовать тот же символ, что и для самой сущности, а название объекта подчеркивать.

контракта и обязуется точно следовать требованиям интерфейса.

UML позволяет моделировать интерфейсы и реализующие их элементы, как показано на рис. 1.20: в данном случае один компонент Spellingwizard.dll реализует два интерфейса IUnknown и ISpelling. Дихотомия

28

«интерфейс/реализация» присуща и другим элементам. Например, прецеденты реализуются кооперациями, а операции – методами.

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

Механизмы расширения UML включают:

‒стереотипы;

‒помеченные значения;

‒ограничения.

Стереотип (Stereotype) расширяет словарь UML, позволяя на основе существующих блоков языка создавать новые, специфичные для решения конкретной задачи. Например, работая с современными языками программирования, часто приходится моделировать исключения (Exceptions) – они являются разновидностями классов и рассматриваются особым образом. Обычно требуется, чтобы исключения можно было возбуждать и перехватывать. Если пометить исключения соответствующим стереотипом, то с ними можно будет обращаться как с обычными строительными блоками языка; на рис. 1.21 это продемонстрировано на примере класса

Overflow.

Рис. 1.21. Механизмы расширения

Помеченное значение (Tagged value) расширяет свойства строительных блоков UML, позволяя включать новую информацию в спецификацию элемента. Например, при работе с продуктом, имеющим различные

29

компоновки, необходимо отслеживать версию и автора какой-нибудь важной абстракции. Ни версия, ни автор не являются первичными концепциями UML, но их можно добавить к любому блоку, такому, например, как класс, задавая для него новые помеченные значения. На рис. 1.21 показано, как это можно сделать, на примере класса EventQueue.

Ограничения (Constraints) расширяют семантику строительных блоков UML, позволяя определять новые или изменять существующие правила. Вы можете, например, ограничить класс EventQueue так, чтобы все события добавлялись в очередь по порядку. На рис. 1.21 показано, как можно определить ограничение, которое явно постулирует это правило для операции add.

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

1.4. АРХИТЕКТУРА ПРОГРАММНОЙ СИСТЕМЫ

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

Архитектура – это совокупность существенных решений касательно:

‒организации программной системы;

‒выбора структурных элементов, составляющих систему, и их интерфейсов;

‒ поведения этих элементов, специфицированного в кооперациях с другими элементами;

30