АрхитектураИС_Семестр3_МетодПособие8-9

21

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

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

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

содержит самые важные его характеристики: имя, атрибуты и операции.

Спецификация класса может содержать и другие детали, на-

пример видимость атрибутов и

операций или указание на то, что

класс является абстрактным. Многие такие детали можно визуализировать в виде графических или

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

22

бута с указанными типами и три открытые операции с параметрами.

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

и объекты, как показано на рис. 1.17.

На этом рисунке показан один классCustomer (Клиент) и три

этого контракта и обязуется точно следовать объявленной семантике интерфейса. UML позволяет моделировать обе эти категории, интерфейсы и их реализации, как показано на рис. 1.18: в данном случае один компонент spellingwizard.dll реализует два интерфейса lUnknown и ISpelling. Почти все строительные блоки UML характеризуются дихотомией «интерфейс/реализация». Например, прецеденты реализуются кооперациями, а операции - методами.

23

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

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

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

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

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

ре класса Overflow.

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

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

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

25

структурные и поведенческие аспекты, но и использование, функциональность, производительность, гибкость, возможности повторного применения, полноту, экономические и технологические ограничения и компромиссы, а также эстетические вопросы [1, c 47].

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

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

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

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

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

26

намические - с помощью диаграмм взаимодействия, состояний и действий.

Рис. 1.20. Моделирование системной архитектуры

Вид с точки зрения развертывания(Deployment view) охватывает узлы, формирующие топологию аппаратных средств системы, на которой она выполняется. В первую очередь он связан с распределением, поставкой и установкой частей, составляющих физическую систему. Его статические аспекты описываются диаграммами развертывания, а динамические - диаграммами взаимодействия, состояний и действий.

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

Выводы

27

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

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

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

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

Контрольные вопросы

1.Дайте краткую характеристику языку UML.

2.Перечислите основные диаграммыUML, дайте их краткую характери-

стику.

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

4.Укажите основное назначение поведенческих сущностей UML. В чем их отличия от структурных сущностей?

5. Для чего используются группирующие и аннотационные сущности

UML?

6.Перечислите, дайте определения и приведите примеры графических изо-

28

бражений основных отношений UML.

7.Укажите основные правила синтаксиса языка UML.

8.Перечислите принятые в ООП типы видимости. Как они обозначаются в

UML?

9.Какие механизмы расширения имеет UML?

10.Что дает использование стереотипов?

11.Какими видами может быть описана архитектура системы?

Упражнения

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

2.Бронирование авиабилетов реализуется посредством системы управления авиаперевозками пассажиров. Каким образом это выразить средствами UML?

3.Преподаватель и студент являясь физическими лицами(соответственно имеют имя, фамилию, адрес и т.д.) вступают в процессе обучение в определенные отношения (студент учится у преподавателя). Каким образом этот факт представить посредством диаграммы классов UML?

4.Структура класса «физическое лицо» содержит атрибут «адрес» и соответ-

ственно зависит от его структуры. Каким образом это выразить средствами

UML?

5.Постройте диаграмму объектов на которой показаны студенты Иванов, Петров, Сидоров и представлена подробная спецификация класса «студент».

6.Приведите модель класса «программный стек» (введите соответствующие данному понятию функции) с использованием механизмов расширения.

29

2. КЛАССЫ

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

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

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

Введение Моделирование системы предполагает идентификацию сущно-

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

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

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

30

например, где труба вмонтирована в пол и в каком месте крыши открывается вентиляция.

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

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

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

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

2.1. Термины и понятия

Классом (Class) называется описание совокупности объектов с

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