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

‒составления из этих структурных и поведенческих элементов все более и более крупных подсистем;

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

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

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

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

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

31

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

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

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

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

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

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

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

32

ВЫВОДЫ

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

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

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

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

КОНТРОЛЬНЫЕ ВОПРОСЫ

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

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

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

33

4. Укажите основное назначение поведенческих сущностей UML.

Вчем их отличия от структурных сущностей?

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

UML?

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

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

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

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

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

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

УПРАЖНЕНИЯ

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

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

ми UML?

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

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

4.Структура класса «физическое лицо» содержит атрибут «адрес» и соответственно зависит от его структуры. Каким образом это выразить средствами UML?

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

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

34

лефон и т. д. При этом конкретные клиенты будут рассматриваться как отдельные экземпляры класса «Клиент», одним из которых является, например, «ОмГТУ».

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

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

2.1. ТЕРМИНЫ И ПОНЯТИЯ

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

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

имя

атрибуты

операции

Рис. 2.1. Классы

36

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

Рис. 2.2. Простые и составные имена

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

2.2. АТРИБУТЫ

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

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

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

37

гие свойства (видимость, область действия, значение по умолчанию и т. д.

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

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

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

38

операции

Рис. 2.6. Операции и их сигнатуры

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

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

Менеджер доступа

<<constructor>> new()

стереотип <<constructor>> new(p : Policy) <<process>> Обслужить(z:Zapros)

<<query>> IsActive(z : Zapros) <<helper>> ValidateZapros(z : Zapros)

Рис. 2.7. Использование стереотипов для описания свойств класса

Использование стереотипов в списках позволяет представить большие списки атрибутов более наглядно.

2.4. ОБЯЗАННОСТИ

Обязанности (Responsibilities) класса – это своего рода контракт, которому он должен подчиняться. Определение класса предполагает, что все его объекты имеют одинаковую структуру и поведение. Выражаясь абст-

39

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

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

Рекомендуется начинать моделирование классов с определения обязанностей сущностей, которые входят в словарь системы. На этом этапе особенно полезны будут такие методики, как применение CRC-карточек

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

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

Графически обязанности изображают в особом разделе в нижней части пиктограммы класса (рис. 2.8).

Менеджер доступа

Обязанности

–определить права пользователя на доступ к данным

–обработать зависящий от пользователя запрос

Рис. 2.8. Обязанности

Обязанности оформляются в виде произвольно составленного текста. Как правило, каждая обязанность излагается в одном предложении.

2.5. ДОПОЛНИТЕЛЬНЫЕ СВОЙСТВА

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

40