Отношения между компонентами и артефактами

Введение

 

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

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

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

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

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

 

 

Лабораторная работа №1.

Сущности и связи UML в Visual Studio.

Диаграмма использования

Цель лабораторной работы: Данный раздел посвящен описанию структурных сущностей, возмож­ным отношениям между ними, использующихся для описания структурных аспектов архитекту­ры ИС.

Теоретическое введение

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

Спецификация

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

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

Спецификация — это декларативное описание того, как нечто устроено или работает.

Необходимо принимать во внимание три толкования спецификаций.

1. То, которое имеет в виду действующее лицо, являющееся источником спецификации (например, заказчик).

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

3. То, которое объективно обусловлено природой специфицируемого объекта.

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

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

Визуализация

Особенности человеческого восприятия таковы, что текст с картинками воспринимается легче, чем просто текст. А картинки с текстом — еще легче. Модели UML допускают представление в форме картинок, причем эти картинки наглядны, интуитивно понятны, практически однозначно интерпретируются и легко составляются.

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

Проектирование

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

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

Документирование

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

XMI (XML Metadata Interchange) — внешний формат данных, основанный на языке XML (схема и набор правил использования тэгов), предназначенное для сериализации моделей и обмена ими.

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

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

Во-вторых, UML не является спецификацией инструмента (хотя инструменты подразумеваются и имеются, например, Rational Rose, Borland Together, Telelogic Rhapsody, Visual Paradigm, Microsoft Visio, Enterprise Architect, StarUML, и др.). Сам язык никоим образом не навязывает то, как его нужно поддерживать инструментальными средствами. Решение всех вопросов, связанных с реализацией UML на компьютере полностью отдано на откуп разработчикам инструментов.

В-третьих, UML не является моделью процесса разработки приложений (хотя модель процесса разработки необходима и имеется множество различных моделей, предложенных разными авторами). Конечно, у авторов UML есть собственная модель процесса — Rational Unified Process (RUP), которую они не могли не иметь в голове, разрабатывая язык, но, тем не менее, ими сделано все для того, чтобы устранить прямое влияние RUP на UML и сделать UML пригодным для использования в любой модели процесса или даже без оной.

UML-модели помогают понимать, обсуждать и разрабатывать системы программного обеспечения. Visual Studio Ultimate предоставляет шаблоны для пяти часто используемых UML-схем: активности, классов, компонентов, последовательностей и вариантов использования. Кроме того, можно создавать схемы слоев, которые помогают определить структуру системы.

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

Сами сущности и отношения модели являются экземплярами метаклассов метамодели.

Сущности

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

- структурные;

- поведенческие;

- группирующие;

- аннотационные.

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

Объект (object) — сущность, обладающая уникальностью и инкапсулирующая в себе состояние и поведение.

Класс (class) — описание множества объектов с общими атрибутами, определяющими состояние, и операциями, определяющими поведение.

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

Другими словами, интерфейс — это абстрактный класс (class), в кото­ром все составляющие (feature) — атрибуты (attribute) и операции (op­eration) — абстрактны. Отсюда прямо следует, что интерфейс не может иметь прямых (непосредственных) экземпляров (instance).

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

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

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

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

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

Действующее лицо (actor) — сущность, находящаяся вне моделируемой системы и непосредственно взаимодействующая с ней.

Компонент (component) — модульная часть системы с четко определенным набором требуемых и предоставляемых интерфейсов.

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

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

Стандартом UML для компонентов предусмотрены стереотипы, приве­денные в следующей таблице.

Таблица 1.1 Стандартные стереотипы компонент

Стереотип	Описание
«buildComponent»	компонент, служащий для разработки приложения
«entity»	постоянно хранимый информационный компонент, представляющий не­которое понятие предметной области
«service»	функциональный компонент, не меняющий своего состояния, и возвра­щающий запрашиваемые значения без побочных эффектов
«subsystem»	единица иерархической декомпозиции большой системы

 

Артефакт (artifact) — элемент информации, который используется или порождается в процессе разработки программного обеспечения. Другими словами, артефакт — это физическая единица реализации, получаемая из элемента модели (например, класса или компонента).

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

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

Таблица 1.2 Стандартные стереотипы артефактов

Стереотип	Описание
«file»	файл любого типа, хранимый в файловой системе
«document»	артефакт, представляющий файл (документ), который не является ни файлом исходных текстов, ни исполняемым файлом
«executable»	выполнимая программа любого вида. Подразумевается по умолча­нию, если никакой стереотип не указан
«library»	статическая или динамическая библиотека
«script»	файл, содержащий текст, допускающий интерпретацию соответ­ствующими программными средствами
«source»	Файл с исходным кодом программы

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

Артефакт является аналогом компонента в смысле сборочного про­граммирования. Причем не любой артефакт, а только некоторые из его стереотипов, а именно «executable» и «library».

Узел (node) — вычислительный ресурс, на котором размещаются и при необходимости выполняются артефакты.

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

На узле размещаются и при необходимости выполняются (или исполь­зуются иным образом) артефакты.

В UML предусмотрено два стереотипа для узлов «executionEnvi- ronment» и «device».

Узел со стереотипом «executionEnvironment» позволяет модели­ровать аппаратно-программную платформу, на которой происходит выполнение приложения, т.е. размещенных на узле артефактов. При­мерами среды выполнения являются: операционная система, система управления базами данных и т. д.

Узел со стереотипом «device» чаще моделирует аппаратную плат­форму. Примером может служить сервер приложений (application server).

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

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

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

Действие (action) — примитивное атомарное вычисление.

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

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

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

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

Группирующая сущность в UML одна — пакет — зато универсальная.

Пакет (package) — группа элементов модели (в том числе пакетов).

Аннотационная сущность тоже одна — примечание (comment) — зато в нее можно поместить все что угодно, так как содержание примечания UML не ограничивает.

В таблице 1.3 приведена стандартная нотация в минимальном варианте для упомянутых сущностей.

 

Таблица 1.3. Нотация основных сущностей

Название	Графическая нотация
Артефакт
Вариант использования
Действующее лицо
Деятельность и действие
Интерфейс
Класс
Компонент
Кооперация
Объект
Пакет
Примечание
Состояние
Узел

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

Отношения

В UML используются четыре основных типа отношений:

- зависимость (dependency);

- ассоциация (association);

- обобщение (generalization);

- реализация (realization).

Зависимость — это наиболее общий тип отношения между двумя сущностями.

Отношение зависимости указывает на то, что изменение независимой сущности каким-то образом влияет на зависимую сущность.

Графически отношение зависимости изображается в виде пунктирной линии со стрелкой (1), направленной от зависимой сущности (2) к независимой (3) (рис.1.1). Как правило, семантика конкретной зависимости уточняется в модели с помощью дополнительной информации. Например, зависимость со стереотипом «use» означает, что зависимая сущность использует (скажем, вызывает операцию) независимую сущность.

Рис.1.1. Отношение зависимости

Ассоциация — это наиболее часто используемый тип отношения между сущностями.

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

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

Рис. 1.2. Отношение ассоциации

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

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

Рис.1.3. Отношение обобщения

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

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

Например, класс является реализацией интерфейса. Графически реализация изображается в виде пунктирной линии с треугольной незакрашенной стрелкой на конце (1), направленной от реализующей сущности (2) к реализуемой (3) (рис. 1.4).

Рис.1.4. Отношение реализации

Перечисленные типы отношений являются основными, различные их вариации и дополнительные отношения рассмотрим на примере следующих отншений:

• между интерфейсами и компонентами;

• между компонентами и артефактами;

• между артефактами;

• между артефактами и узлами;

• между узлами.

Рассмотрим эти отношения по порядку.

1.2.1. Отношения между компонентами и интерфей­сами

Исходя из определения компонента (см. 1.1.2), можно выделить две ро­ли, которые играют интерфейсы по отношению к компонентам. А именно, интерфейс может быть обеспеченным (provided) и требуемым

(required).

Однако нельзя забывать, что сам по себе интерфейс — это просто опи­сание контракта, а обеспеченным или требуемым он становиться в за­висимости от того, как этот интерфейс используется:

• если компонент реализует интерфейс — то для данного компо­нента это обеспеченный интерфейс и данный факт показывается с помощью отношения реализации;

• если компонент вызывает операции интерфейса — то для данно­го компонента это требуемый интерфейс и данный факт показы­вается с помощью отношения зависимости со стереотипом

«use».

Возможные отношения между интерфейсами и компонентами пред­ставлены на рис. 1.5.

 

 

Рис. 1.5. Нотация отношений между компонентами и интерфейсами

 

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

Рис. 1.6. Нотация отношения между компонентами

Отношения между компонентами и артефактами

Самым важным аспектом использования понятия артефакта в UML яв­ляется то, что артефакт может участвовать в отношении манифестации.

Манифестация (manifest) — это отношение, связывающее элемент мо­дели (например, компонент) и его физическую реализацию в виде ар­тефакта.

Манифестацию графически изображают отношением зависимости со стереотипом «manifest», направленную от артефакта к реализуемой сущности (в нашем случае - компоненту).

Рис. 1.7 Нотация отношения между компонентом и артефактом

 

В общем случае, отношение манифестации — это отношение типа "многие ко многим", один элемент модели может быть реализован многими артефактами, и один артефакт может участ­вовать в реализации многих элементов модели.

 

1234567Следующая ⇒

Поделиться:

Воспользуйтесь поиском по сайту: