НА ПРОЕКТНЫХ СТАДИЯХ СОЗДАНИЯ ПО АС

 

10.1. Введение

 

Унифицированный язык программирования (Unified Modeling Language–UML) это язык для спецификации, визуализации, проектирования и документирования программных систем, а так же бизнес-моделей и других не программных систем. Он представляет собой объединение инженерных приемов, которые ранее успешно применялись при моделировании больших и сложных систем.

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

Различают спецификации трех видов:

- словесные спецификации на естественном языке;

- модельные спецификации;

- формальные спецификации.

Словесные спецификации на естественном языке, вызывают массу проблем, поскольку создаются разными специалистами на «их языке».

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

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

Такие картинки с подписями наглядны и интуитивно по­нятны, причем почти однозначно понимаются любыми заинтересован­ными лицами, так что могут использоваться в качестве средства общения между людьми. UML позволяет создавать такие простые и понятные кар­тинки (модели), описывающие систему с разных сторон, которые можно показать заказчику и обсудить с ним, т. е. служит средством коммуника­ции в команде. Посмотрите на рисунок ниже (рис. 10.1). Все ведь понятно, правда?

Перейдем к проектированию. Да, UML позволяет строить модели программных систем (вообще говоря — ЛЮБЫХ систем). По этим моде­лям потом может производиться генерация каркасного кода проектируе­мых приложений. Более того, возможен процесс, который часто называ­ют «реверс-инжинирингом», — т. е. создание UML-модели из существу­ющего кода приложения. Не будем сейчас обсуждать качество получающегося кода или моделей при реверс-инжиниринге. Пока оно весьма далеко от идеала, но ведь технологии и инструменты постоянно совершенствуются, так что можно надеяться, что когда-нибудь мы смо­жем создавать приложения визуально, не прибегая к языку программиро­вания, а пользуясь лишь UML...

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

 

Рис. 10.1. Простой пример диаграммы на языке UML

 

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

Теперь о том, для чего UML использовать нельзя, вернее, чем он не является.

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

 Во-вторых, UML не яв­ляется спецификацией какого бы то ни было инструмента моделирова­ния, хотя такие инструменты (и в больших количествах) имеются. Напри­мер, TAUG2, BorlandTogether, IBMRationalRose, Dia. Каким образом то или иное CASE-средство реализует UML-моделирование, никак не регламентируется и определяется самими разработчиками этих инструментов.

 И, наконец, в-третьих, UML не яв­ляется моделью какого-либо процесса разработки ПО. UML можно использовать независи­мо от того, какая методологию разработки ПО используется.

Формальное описание самого языка UML 2.0 основывается на некоторой общей иерархической структуре модельных представлений, состоящей из четырех уровней:

- мета-метамодель (МЗ);

- метамодель (М2);

- модель (Ml);

- объекты или экземпляру (МО).

Уровень мета-метамодели образует исходную, формально-логическую осно­ву для всех возможных метамодельных представлений. Главное предназна­чение этого уровня состоит в том, чтобы определить язык для спецификации метамодели. Мета-метамодель определяет модель языка UML 2.0 на самом высоком уровне абстракции и является наиболее компактным ее описанием. С другой стороны, мета-метамодель может специфицировать несколько метамоделей.Этим достигается потенциальная гибкость включения дополнительных понятий. Этот уровеньнаиболее тесно связан с теорией формальных языков. Примерами понятий этого уров­ня служат метакласс, метаатрибут, метаоперация.

Метамодель является экземпляром или конкретизацией мета-метамодели. Главная задача этого уровня — определить язык для спецификации моделей. Данный уровень является более конструктивным, чем предыдущий, посколь­ку обладает более развитой семантикой базовых понятий. Все основные по­нятия языка UML 2.0 — это понятия уровня метамодели. Примерами таких понятий являются класс, атрибут, операция, компонент, ассоциация и многие другие. Рассмотрению семантики и графической нотации понятий уровня метамодели собственно и посвящена настоящая лекция.

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

Конкретизация понятий модели происходит на уровне объектов или экземпля­ров. При этом совокупность объектов рассматривается как отдельный экземп­ляр модели времени выполнения, поскольку содержит конкретную информа­цию относительно того, чему в действительности соответствуют те или иные понятия модели. Примером объекта может служить следующая запись в проек­тируемой базе данных: " Игорь Греков, 40 лет, модельер, ул. Системная, 1-2, 123-4567". Рассмотренную 4-уровневую структуру модельных представлений языка UML 2.0 можно проиллюстрировать следующим образом (рис. 10.2).

 

 

Рис. 10.2. Иллюстрация 4-уровневой структуры модельных представлений языка UML 2.0

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

В UML используется четыре вида элементов нотации:

• фигуры,

• линии,

• значки,

• надписи.

Разберем все по порядку. Фигуры используются «плоские» — прямо­угольники, эллипсы, ромбы и т. д. Но есть одно исключение — как мы увидим далее, на диаграмме развертывания для обозначения узлов инфраструктуры применяется «трехмерное» изображение параллелепипеда. Это единственное исключение из правил. Внутри любой фигуры могут помещаться другие элементы нотации.

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

Значки в UML используются весьма умеренно. Как и фигуры, они «плоские», но не могут содержать другие фигуры и значки внутри себя.

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

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

Кстати об инструментах рисования. Мы уже упоминали, что такое ПО существует в виде пакетов, к которым можно от­нести:

• IBM Rational Rose;

• Borland Together;

• Gentleware Poseidon;

• Microsoft Visio;

• Telelogic TAU G2.

 

10.2. Виды диаграмм UML

 

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

1) диаграммы структуры (StructureDiagrams):

 - диаграмма классов (Classdiagram);

 - диаграмма композитной структуры (CompositeStructurediagram);

             - диаграмма пакетов (Packagediagram);

         - диаграмма объектов (ObjectDiagram);

         - диаграмма компонентов (Componentdiagram);

         - диаграмма развертывания (Deploymentdiagram);

2) диаграммы поведения (BehaviorDiagrams):

         - диаграмма вариантов использования (UseCasediagram);

         - диаграмма деятельности (Activitydiagram);

         - диаграмма конечного автомата (StateMachinediagram);

    3) диаграммы взаимодействия (InteractionDiagrams):        

         - диаграмма последовательности (Sequencediagram);

         - диаграмма коммуникации (Communicationdiagram);

         - диаграмма обзора взаимодействия (InteractionOverviewdiagram);

         - временная диаграмма (Timingdiagram).

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

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

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

 

Рис. 10.3.  Классификация канонических диаграмм языка UML 2.0

 

 

В качестве самостоятельных модельных представлений в языке UML 2.0 ис­пользуются следующие канонические диаграммы:

□ диаграмма вариантов использования (usecasediagram) —- диаграмма кон­цептуального уровня, которая служит для представления актеров и вари­антов использования системы, а также отношений между ними;

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

□ диаграмма композитной структуры (compositestructurediagram) — диа­грамма, которая изображает внутреннюю структуру классификаторов, та­ких как класс, компонент или кооперация, включая точки взаимодействие классификатора с другими частями системы;

□ диаграмма пакетов (packagediagram) — диаграмма логического уровня, которая служит для представления организации элементов модели по па­кетам, а также зависимостей между пакетами, включая импорт пакетов yi слияние пакетов;

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

□ диаграмма последовательности (sequencediagram) — диаграмма, которая служит для представления взаимодействия элементов модели в форме по­следовательности сообщений и соответствующих событий на линиях жиз­ни объектов;

□ диаграмма деятельности (activitydiagram) — диаграмма, которая изо­бражает поведение объекта или системы с использованием моделей потока данных и потока управления;

□ диаграмма коммуникации (communicationdiagram) — диаграмма, которая служит для представления взаимодействия между линиями жизни объек­тов в форме элементов внутренней структуры системы и передаваемых между ними сообщений;

□ диаграмма обзора взаимодействия (interactionoverviewdiagram) — вари­ант диаграммы деятельности, которая служит для представления только взаимодействия потока управления в некоторой агрегированной форме;

□ временная диаграмма (timingdiagram) — диаграмма взаимодействия, ко­торая служит для представления изменения состояния или условий линии жизни отдельных экземпляров классификаторов во времени;

□ диаграмма конечного автомата (statemachinediagram) — диаграмма, ко­торая служит для представления дискретного поведения, моделируемого посредством переходов в системах с конечным числом состояний. В част­ности, она может представлять последовательность состояний, через которые объект или система проходят в течение жизни, реагируя на различные события;

□ диаграмма компонентов (componentdiagram) — диаграмма физического уровня, которая служит для представления программных компонентов и зависимостей между ними;

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

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

Каждая из канонических диаграмм детализирует и конкретизирует различные представления о модели сложной системы в терминах языка UML 2.0.

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

 

Рис. 10.4. Интегрированная модель сложной системы в нотации UML 2.0

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

Рассмотрим такие виды диаграмм:

• диаграмма прецедентов;

• диаграмма классов;

• диаграмма объектов;

• диаграмма последовательностей;

• диаграмма взаимодействия;

• диаграмма состояний;

• диаграмма активности;

• диаграмма развертывания.

 

Лекция 12

10.3. Диаграмма прецедентов (вариантов использования) - (usecasediagram)

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

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

Можно задать вопрос: а почему эк­тор, а не актер? Причина, почему говорят именно так, проста — эктор образовано от словаaction, что в переводе означает действие. Дослов­ный же перевод слова «эктор» — действующее лицо — слишком длинный и неудобный для употребления.

Графически эктор изображается либо «человечком», подобным тем, которые мы рисовали в детстве, изображая членов своей семьи, либо сим­волом класса с соответствующим стереотипом, или в виде пиктограммы.Это показано на рисунке 10.5.Все формы представления имеют один и тот же смысл и могут использо­ваться в диаграммах. «Стереотипированная» форма чаще применяется для представления системных экторов или в случаях, когда эктор имеет свойства и их нужно отобразить. Пиктограмма используется в тех случаях, когда, по мнению самого разработчика, надо более наглядно отразить характер выполняемой эктором роли.

 

Рис. 10.5. Варианты символов графического обозначения эктора:

а – в виде «проволочного человечка»; б – в виде прямоугольника;

в- в виде пиктограммы

В оп­ределении эктора было применено слово «прецедент». Что же это такое? Этот вопрос заин­тересует нас еще больше, если вспомнить, что сейчас мы говорим о диа­грамме прецедентов.

Наиболее кратко - прецедент (usecase) — описание отдельного аспекта поведения сис­темы с точки зрения пользователя.

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

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

Прецеденты обозначаются в виде эллипса, внутри которого указано его название (рис. 10.6).

 

Рис. 10.6 Изображение прецедента

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

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

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

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

А вот еще один пример диаграммы прецедентов, описывающей учебу в институте (рис. 10.9).

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

 

 

Рис. 10.7. Простой пример диаграммы прецедентов (использование студентом библиотеки)

 

 

Рис. 10.8. Диаграмма прецедентов для системы продажи товаров в интернет-магазине

 

 

Рис. 10.9. Более сложный пример диаграммы прецедентов

(учеба в институте)

 

Между элементами диаграммы прецедентов могут существовать различные взаимосвязи или отношения.

Под отношением (relationship) в языке UML 2.0 понимается произ­вольная семантическая взаимосвязь между отдельными элементами модели.

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

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

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

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

Рис. 10.10. Пример графического представления отношения ненаправленной ассоциации между актером и вариантом использования

Если же, по мнению разработчика, направление взаимодействия между ак­тером и вариантом использования имеет значение, то такое отношение может быть представлено в форме направленной ассоциации (рис. 10.11). При этом направление ассоциации указывается в форме простой стрелки в форме буквы " V».

Рис. 10.11. Пример графического представления отношения направленной ассоциации между эктором и вариантом использования

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

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

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

Графически данное отношение обозначается как отношение зависимости в форме пунктирной линии с “У”-образной стрелкой, направленной от зависимого варианта использования к независимому варианту использования. Зависимый вариант использования часто называют также базовым или включающим, а независимый — включаемым вариантом использования. При этом линия со стрелкой обязательно помечается ключевым словом“include” записанным в форме стереотипа (рис. 10.12).

 

Рис. 10.12. Пример графического изображения отношения включения между вариантами использования

 

Отношение расширения ( extend ) определяет взаимосвязь одного вариантаиспользования с некоторым другим вариантом использо­вания, функциональность или поведение которого задействуется первым не всегда, а только при выполнении некоторых дополни­тельных условий.

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

Графически данное отношение обозначается как отношение зависимости в форме пунктирной линии с «У»-образной стрелкой, направленной от зави­симого варианта использования к независимому варианту использования и соединенной с ним в так называемой точке расширения (extensionpoint).

 При этом зависимый вариант использования в отношении расширения назы­вается также расширяющим, а независимый — базовым или расширяемым вариантом использования. Линия со стрелкой обязательно помечается ключе­вым словом«extend», которое записывается в форме стереотипа (рис.10.13).

Рис. 10.13. Пример графического изображения отношения расширения между вариантами использования

 

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

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

Рис. 10.14. Графическое изображение отношения расширения с условием выполнения в форме произвольного текста

 

Более строго точку расширения можно специфицировать следующим обра­зом. К соответствующему отношению расширения присоединяется примеча­ние, которое содержит запись условия в форме ограничения, заключенного в фигурные скобки. Ниже строки с условием после ключевого слова extensionpoint и двоеточия записывается имя точки расширения. Имя дан­ной точки расширения также должно быть указано и в базовом варианте ис­пользования после ключевого словаextensionpoint (рис.10.15).

 

Рис.10.15. Графическое изображение отношения расширения с условием выполнения в форме структурированного текста.

 

Данный фрагмент диаграммы вариантов использования может быть интер­претирован следующим образом. Вариант использования " Оформление Зака­за в интернет-магазине" имеет точку расширения " Скидка". Данныйвариант использования расширяется в этой точке расширения вариантом использования «Представление бонусной скидки постоянному покупателю» всякий раз, когда выполнение базового варианта использования доходит до места, на которое ссылается точка расширения «Скидка» и клиент имеет бонусную карточку.

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

В изображенном на рис. 10.16 фрагменте диаграммы прецедентов использования отношение обобщения специфицирует то, что вариант использования " Опла­та товара по кредитной карточке" является специальным случаем варианта использования " Оплата выбранного в интернет-магазине товара". При этом вариант использования Б, который является потомком, наследует все свойства поведения своего родителя, т.е. варианта использования А.

Рис. 10.16. Пример графического изображения отношения обобщения между вариантами использования

 

Между экторами также может существовать отношение обобщения. Данное отношение является направленным и указывает на факт специализации од­них экторов относительно других.

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

Графически данное отношение также обозначается стрелкой обобщения, которая указывает на родительского эктора (рис. 10.17).

 

Рис. 10.17. Пример графического изображения отношений обобщения между экторами

 

Подводя итоги, можно выделить такие цели создания диаграмм пре­цедентов:

- определение границы и контекста моделируемой предметной об­ласти на ранних этапах проектирования;

- формирование общих требований к поведению проектируемой системы;

     - разработка концептуальной модели системы для ее последующейдетализации;

     - подготовка документации для взаимодействия с заказчиками и пользователями системы.

Лекция 13

10.4. Диаграмма классов (classdiagram)

Центральное место при проектировании программной системы занимает раз­работка ее логической модели в виде диаграммы классов. Важность диаграм­мы классов основывается на том обстоятельстве, что данная диаграмма являет­ся основой для автоматической генерации программного кода во всех извест­ных CASE-средствах, которые обладают подобной возможностью.

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

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

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

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

Разработка диаграммы классов преследует следующие цели:

- определить сущности предметной области и представить их в форме клас­сов с соответствующими атрибутами и операциями;

- определить взаимосвязи между сущностями предметной области и пред­ставить их в форме типовых отношений между классами;

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

- подготовить документацию для последующей разработки программного кода.

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

Классификатор (classifier) — специальное понятие, предназначенное для классификации экземпляров, которые имеют общие харак­теристики.

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

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

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

Характеристика (feature)— понятие, предназначенное для специ­фикации особенностей структуры и поведения экземпляров клас­сификаторов.

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

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

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

10.4.1. Класс

Класс ( class ) – элемент модели, который описывает множество объектов, имеющих одинаковые спецификации характеристик, ограничений и семантики.

В языке UML2.0 класс служит графическим представлением и формальным описанием свойств однотипных объектов, которые обладают одинаковойструктурой, поведением и отношениями с объектами из других классов. Цель класса заключается в спецификации классификации объектов и в специфика­ции характеристик, которые отражают структуру и поведение этих объектов.

Для графического изображения класса в языке UML2.0 используется символ классификатора — прямоугольник, при этом ключевое словоclassв угло­вых скобках выше его имени не указывается (см. рис. 10.18).

т т

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

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

Обязательным элементом при обозначении класса является его имя, которое всегда записывается в верхней секции прямоугольника класса. При этом класс может обозначаться прямоугольником без дополнительных секций с указанием только имени класса (рис. 10.18, а), что характерно для начальных этапов разработки диаграммы. По мере дальнейшей разработки диаграм­мы классов их обозначения дополняются секциями атрибутов и операций (рис. 10.18, б). Если секция атрибутов или операций является пустой, то в языке UML2.0 допускается ее вовсе не указывать (рис. 10.18, в).

 

а                          б                         в                          г Рис. 10.18. Варианты графического изображения класса на диаграмме классов: а — в виде прямоугольника; б— в виде прямоугольника с секциями; в — без секции атрибутов класса; г — активный класс

 

Дополнительно класс может быть специфицирован как активный или пас­сивный.

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

Пассивный класс (passiveclass)— класс, каждый экземпляр кото­рого выполняется в контексте некоторого другого объекта.

Объект активного класса после своего создания начинает исполнять поведение своего класса и не прекратит его до тех пор, пока либо не будет законче­но выполнение этого поведения, либо данный объект будет уничтожен неко­торым другим объектом. Активный класс в языке UML2.0 изображается прямоугольником класса с дополнительным вертикальным отрезком на каж­дой его стороне (рис. 10.18, г).

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

          а                                       б                                        в

Рис. 10.19. Примеры графического изображения конкретных классов:

а – для класса линия указаны атрибуты; б – для класса окно указаны операции; в – для класса счет указано исключение

 

Спецификация отдельных элементов класса подчиняется достаточно строгим правилам. Рассмотрим некоторые из этих правил.

10.4.1.1 Имя класса

Имя класса (classпате) — строка текста, предназначенная для идентификации класса на диаграмме классов.

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

10.4.1.2. Атрибуты класса

Атрибут (attribute) класса служит для представления отдельнойструктурной характеристикиили свойства, которое является общим для всех объектов данного класса.

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

Атрибуты класса записываются во второй сверху секции прямоугольника класса, которую называют секцией атрибутов. При этом все спецификации атрибутов выравниваются слева. Следует показывать полные спецификации атрибутов, когда это необходимо, и скрывать их в других случаях. Каждому атрибуту класса в языке UML2.0 соответствует отдельная строка текста, ко­торая в нотации БНФ имеет следующий формат:

 

˂ атрибут˃:: =[˂ видимость˃ ]['/'] < имя> [': ' < тип атрибута> ]

[' ['< кратность> ' ] ' ] [' = ' значение по умолчанию> ]

['{'< модификатор атрибута> [', ' < модификатор атрибута> ] * '}' ].

Здесь:

□ < видимость>:: = . Другими словами, видимость (visibility) может принимать одно из 4-х возможных значений и отобра­жаться либо посредством специального символа, либо соответствующего ключевого слова.

□ ' / ' означает, что атрибут является производным(derive). Значение произ­водного атрибута может быть вычислено на основе значений других атрибутов этого или других классов. Поэтому данный атрибут называют иногда вычислимым;

□ < имя> (name) представляет собой строку текста, которая используется в качестве идентификатора соответствующего атрибута и поэтому должна быть уникальной в пределах данного класса. Имя атрибута является един­ственным обязательным элементом в обозначении атрибута, должно на­чинаться со строчной (малой) буквы и, как правило, не должно содержать пробелов;

□ < тип атрибута> (attributetype) есть имя классификатора, который являет­ся типом данного атрибута. Тип атрибута представляет собой имя некото­рого типа данных, определенного или в пакете типы данных языка UML 2.0, или самим разработчиком. В общем случае тип атрибута записывается строкой текста, имеющей осмысленное значение в пределах пакета или модели, к которому относится рассматри­ваемый класс. Типу атрибута должно предшествовать двоеточие;

□ < кратность> (multiplicity) атрибута характеризует общее количество конкретных значений для атрибута, которые могут быть заданы для объ­ектов данного класса. Более подробно семантика кратности рассматри­вается далее;

□ < значение по умолчания» (default) — некоторое выражение, которое слу­жит для задания начального значения или значений данного атрибута в момент создания отдельного экземпляра соответствующего класса. Конкретное значение по умолчанию должно соответствовать типу данного атрибута;

□ < модификатор атрибута> (attributemodifier) представляет собой текстовое выражение, которое придает дополнительную семантику данному атрибуту. При этом набор возможных модификаторов атрибутов в языке UML 2.0 фиксирован и может быть представлен в следующем виде (БНФ):

< модификатор атрибута>:: = 'readonly' | 'union' | 'subsets' < имя атрибута> | 'redefines'< имя атрибута> | 'ordered' | 'unique' |< ограничение атрибута>

Назначение указанных модификаторов описываются в табл. 10.2.2.1.

 

10.4.1.3 Вид видимости

Вид видимости является типом перечисления, который определяет значения в форме литералов для определения видимости элементов в модели.

Видви­димости является перечислением следующих значений литералов:

- public (общедоступный). Общедоступный элемент является видимым всеми элементами, который имеют доступ к содержимому пространства имен, который им владеет;

- private(закрытый). Закрытый элемент является видимым только внутри пространства имен, который им владеет;

- protected(защищенный). Защищенный элемент является видимым для элементов, которые имеют отношение обобщения с пространством имен, который им владеет;

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

 

Табл. 10.2.2.1.модификаторов

 

□ Модификатор атрибута	Назначение модификатора
readonly	Атрибут является атрибутом только для чтения
union	Атрибут является производным объединением его подмножеств
subsets< имя атрибута>	Атрибут является собственным подмножеством атрибута с именем< имя атрибута>
redefines< имя атрибута>	Атрибут переопределяет некоторый наследуемый атрибут с именем< имя атрибута >
ordered	Значения атрибута являются упорядоченными. Этот порядок означает, что существует отображение из множества положительных целых чисел в элементы этой коллекции значений. Если атрибут не является многозначным, то значение дляordered не имеет семантического эффекта. При отсутствии этого мо­дификатора атрибут специфицируется как неупоря­доченный, и никаких предположений нельзя сде­лать относительно порядка его возможных значений
unique	Значения многозначного атрибута не могут иметь дуб­ликатов, т. е. повторяться. Предполагается, что крат­ность соответствующего атрибута должна быть боль­ше 1. Если атрибут не является многозначным, то значениеunique не имеет семантического эффекта
< ограничение атрибута>	Выражение, которое специфицирует некоторое ог­раничение, применяемое к данному атрибуту

 

 

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

Вместо литерала видимости в языке UML2.0 допускается записывать соответствующий символ видимости:

+ — общедоступный;

- — закрытый;

# —защищенной;

—пакетный.

10.4.1.4. Операция класса

Операция( operation )класса служит для представления отдельной характеристики поведения, которая является общей для всех объектов данного класса.

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

Лекция 14

10.4.2. Отношения между классам

 

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

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

 

10.4.2.1. Ассоциация

Ассоциация (association)— произвольное отношение или взаимо­связь между классами.

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

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

Имя ассоциации(associationname) является необязательным элементом ее обозначения. Если оно задано, то записывается с прописной (большой) буквы полужирным шрифтом и располагается рядом с символом ассоциации, но не слишком близко к ее концу, чтобы не перепутать с именем этого конца.

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

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

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

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

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

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

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

В качестве примера бинарной ассоциации рассмотрим отношение между двумя классами — классом компания и классом сотрудник (рис. 10.20). Они связаны между собой бинарной ассоциацией с именем работает, которое указано на рисунке рядом с линией ассоциации. Для данного отношения оп­ределен порядок чтения ассоциации, а именно: Сотрудник Работаетв Ком­пании. Навигация для концов данной ассоциации не специфицирована. Спе­циальные строки свойств для концов ассоциации здесь отсутствуют.

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

 

Имя ассоциации Символ направления чтения Рис. 10.20. Графическое изображение ненаправленной бинарной ассоциации между классами

 

С другой стороны, любому трудоустроенному сотруднику будет всегда соот­ветствовать единственная компания. Это означает, что в рамках рассматри­ваемой модели недопустимо одновременная работа сотрудников в несколь­ких компаниях. Заметим, что если вместо кратности 1..*записать символ *, то изменится семантика этого элемента модели. А именно, поскольку по­следний символ эквивалентен кратности о..*, то для данной модели это означало бы, что отдельные компании могут совсем не иметь сотрудников в своем штате.

Более общий случай представляет собой п-арноя ассоциация, которая связывает некоторым отношением ассоциации более двух классов. В качестве значения N может выступать произвольное натуральное число больше 1. Каждый экземпляр реализации n-арной ассоциации представляет собой n-арный кортеж, состоя­щий в точности из n объектов соответствующих классов. Частным случаем п-арной ассоциации является тернарная ассоциация, которая связывает соот­ветствующим отношением в точности три класса (п = 3). Бинарная ассоциа­ция также является частным случаем n-арной ассоциации (n= 2), хотя и име­ет свое собственное обозначение. Концы n-арной ассоциации для п  3 являются собственностью этой ассоциации.

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

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

 

 

Рис. 10.21. Графическое изображение 4-арной ассоциации

Отдельным экземпляром ассоциации игра может служить, например, кортеж < динамо, зенит, 17 июля, 2005>. В рассматриваемой модели вполне воз­можно, что 2 футбольные команды не провели в конкретном сезоне между собой ни одной встречи, на что указывают соответствующие кратности концов ассоциации. Все состоявшиеся игры могут быть упорядочены по годам и дате, на что указывает строка свойства (ordered) у соответствующих концов ассоциации.

10.4.2.2. Обобщение

Обобщение (generalization) — таксономическое отношение между более общим классификатором (родителем или предком) и более специальным классификатором (дочерним или потомком).

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

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

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

Для изображенного справа отношения обобщения (рис. 10.22, б) класс квадрат наследует от класса прямоугольник все атрибуты. Дополнительный атрибут id класса квадрат переопределяет атрибут имя классаПрямоугольник, а атри­бут высота классаКвадрат имеет по умолчанию значение 7, вместо значения 5 в родительском классе. Атрибут ширина в классе квадрат является произ­водным, поскольку его значение всегда равно значению атрибутавысота. Хо­тя атрибуты цвет Заливки и площадь в классе квадрат не указаны, они также принадлежат этому классу. Их спецификация полностью идентична описа­нию в родительском классе, что следует из семантики отношения обобщения.

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

 

Рис. 10.22. Графическое изображение отношения обобщения в языке UML2.0: а — свернутое представление классов; б — развернутое представление классов

Например, класс Геометрическая фигура (курсив обозначает абстрактный класс) может выступать в качестве родительского класса для классов-потомков, соответствующих конкретным геометрическим фигурам, таким как прямоугольник, Окружность, Эллипс и др. Данный факт может быть пред­ставлен графически в форме следующей диаграммы классов (рис. 10.23).

 

Рис. 10.23. Пример графического изображения отношения обобщения для нескольких классов-потомков

 

10.4.2.3. Агрегация

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

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

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

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

Графически отношение агрегации изображается сплошной линией, один из концов которой представляет собой незакрашенный внутри (пустой) ромб качестве дополнительного обозначения терминала на агрегированном кон­це линии ассоциации. Ромб агрегации по форме должен быть меньше, чем ромб в качестве нотации ассоциации. Этот ромб указывает на тот из классов, который представляет собой " класс-целое" или класс-контейнер. Остальные классы являются его " частями" (рис. 10.24).

Рис. 10.24 Графическое изображение отношения агрегации

 

Если существует две или более агрегации для одного агрегата, они могут быть изображены в форме дерева посредством слияния концов агрегации в отдельный сегмент. Любые дополнительные обозначения для этого отдель­ного сегмента применяются ко всем концам этой агрегации. Примером отношения агрегации может служить известное каждому из читателей разде­ление персонального компьютера на составные части: системный блок, мо­нитор, клавиатуру и мышь. Используя обозначения языка UML2.0, компонентный состав ПК можно представить в виде соответствующей диаграм­мы классов (рис. 10.25), которая в данном случае иллюстрирует отношение агрегации.

 

Рис. 10.25. Диаграмма классов для иллюстрации отношения агрегации на примере ПК

10.4.2.4. Композиция

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

Отношение композиции является частным случаем отношения агрегации. При этом она является сильной формой агрегации, которая требует, чтобы экземпляр-часть был включен не более чем в один агрегат или композит. Ес­ли композит удаляется, все его части обычно удаляются вместе с ним. В язы­ке UML2.0 объект-часть при необходимости может быть удален из компози­та до того, как сам композит будет уничтожен.

Графически отношение композиции изображается сплошной линией, один из концов которой представляет собой ромб, который имеет заливку («черный ромб»). Этот ромб указывает на тот из классов, который представляет собой класс-композит. Остальные классы являются его «частями» (рис. 10.26).

 

 

Рис. 10.26. Графическое изображение отношения композиции

 

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

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

 

 

Рис. 10.27. Диаграмма классов для иллюстрации отношения композиции

на примере класса-композита Окно программы

Лекция 15

10.4.2.5. Зависимость

 

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

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

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

 

Рис. 10.28. Графическое изображение отношения зависимости на

диаграмме классов

10.4.26. Реализация

Реализация (realization) — специализированное отношение зависи­мости между двумя элементами модели, один из которых представ­ляет некоторую спецификацию (поставщик), а другой представляет его реализацию (клиент).

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

Рис. 10.29. Графическое изображение отношения реализации на диаграмме классов

10.4.3. Интерфейс

Интерфейс, (interface) — вид класса, который представляет собой объявление множества общедоступных характеристик и обязан­ностей.

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

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

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

На диаграмме классов интерфейс изображается в виде маленького круга, ря­дом с которым записывается его имя. В качестве имени может быть сущест­вительное, которое характеризует соответствующую информацию или сервис (например, Датчик температуры, Форма ввода, Видеокамера). С учетом языка реализации модели имя интерфейса, как и имена других классов, рекоменду­ется записывать на английском. В этом случае оно должно начинаться с заглавной буквы I, например, ITemperatureSensor, ISecurelnformation.

Множество интерфейсов, реализуемых классификатором, являются его пре­доставляемыми интерфейсами (providedinterface), описывающие обязанно­сти или сервисы, которые экземпляры этого классификатора имеют перед своими клиентами. Соответствующее отношение между классом и предос­тавляемым им интерфейсом представляется отношением реализации интер­фейса от класса к интерфейсу. Реализация интерфейса является специализи­рованным отношением реализации между классом и интерфейсом. Это отношение означает, что реализующий класс согласуется с контрактом, спе­цифицированным этим интерфейсом. Оно изображается представлением ин­терфейса в форме круга или шара, помеченного именем интерфейса, присое­диненного непрерывной линией к классу, который реализует этот интерфейс (рис. 10.30, справа).

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

Рис. 10.30.Пример графического изображения требуемого (слева) и предоставляемого (справа) интерфейса

В данном примере IДатчик является предоставляемым интерфейсом для Бесконтактного Датчикаи требуемым интерфейсом для Сигнала Тревоги.

Нотация предоставляемого и требуемого интерфейса в форме круга и по­лукруга получила свое собственное жаргонное название — " леденец на палочке¹¹, которое стало своеобразной визитной карточкой нововведений языка UML 2.0.

Как классификатор, интерфейс может быть также изображен с использованием символа прямоугольника с ключевым словом «interface», записанным форме стереотипа. В случае, когда интерфейс представляется с использованием нотации прямоугольника, отношения зависимости реализации и ис- пользования интерфейса обозначаются стрелками соответствующей зависимости (рис. 10.31).

 

Рис. 10.31. Пример альтернативной нотации для графического изображения интерфейса для ситуации, изображенной на рис. 10.30

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

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

10.4.4. Шаблон

 

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

Шаблон (template) — классификатор, который в своем описании] имеет несколько формальных параметров.

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

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

 

10.4.5. Примеры диаграмм классов

 

Рис. 10.32. Генеалогическое дерево бытовой техники

 

 

Рис. 10.33. Автоматизация работы вуза

 

Рис. 10.34. Диаграмма классов путешествия

В качестве другого примера рассмотрим диаграмму классов для системы продажи товаров в интернет-магазине. Вообще говоря, подобная диаграмма классов может быть построена и представлена различным образом, что отражает субъективный характер разработчика на отдельные аспекты реализации мо­дели. Один из возможных вариантов диаграммы классов для данного примера изображен на рис. 10.35.

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

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

 

 

Рис. 10.35. Диаграмма классов системы продажи товаров в

интернет-магазине

 

10.5. Диаграмма объектов (objectdiagram)

 

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

10.5.1. Объект

Объект (object) является отдельным экземпляром класса, который создается на этапе реализации модели или выполнения программы.

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

Имя объекта представляет собой строку текста, записанную в следующем виде (БНФ):

        

< имя-объекта>:: = [< собственное-имя-объекта> ] | [: < имя-класса> [', '< имя-класса> ] *].

В записи имени объекта < собственное-имя-объекта> и < имя-класса> не мо­гут отсутствовать одновременно, а вся запись имени объекта подчеркивается. Если указано< собственное-имя-объекта>, то оно должно начинаться со строчной буквы. При наличии< имени-класса>, ему всегда должно предшест­вовать двоеточие.

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

- о: С — для объекта специфицировано собственное имя объекта и имя класса;

- о — для объекта специфицировано только собственное имя объекта;

- : С— для объекта специфицировано только имя класса.

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

а                                      б                                     в Рис.10.36. Примеры графических изображений объектов на диаграммах структуры: a — полная спецификация имени объекта; б — имя класса отсутствует; в — отсутствует имя объекта

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

Рис. 10.37. Описание объекта с указанием атрибута

Приведем простейший пример диаграммы объектов (рис. 10.38).

Рис. 10.38. Диаграмма объекта - фирма

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

Другой пример (рис. 10.39).Эта диаграмма тоже понятна в общих чертах даже без дополнитель­ных объяснений. Здесь мы видим взаимосвязь объектов — организацион­ных единиц в некоторой кампании.

Рис. 10.39. Взаимосвязь объектов — организацион­ных единиц в некоторой кампании

Лекция 16

10.6. Диаграмма последовательностей (sequencediagram)

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

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

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

Приведем пример диаграммы последователь­ностей (рис. 10.40):

Рис. 10.40. Диаграмма последовательностей для записи студента на семинар

Смысл диаграммы вполне понятен: студент хочет записаться на некий семинар, предлагаемый в рамках некоторого учебного курса. Cэтой целью проводится проверка подготовленности студента.Для этого за­прашивается список (история) семинаров курса, уже пройденных студен­том (перейти к следующему семинару можно, лишь проработав материал предыдущих занятий). После получе­ния истории семинаров объект класса «Семинар» получает статус подго­товленности, на основе которой студенту сообщается результат (статус) его попытки записи на семинар. Кстати, обратите внимание на вызов ме­тодов. Как видите, все просто!

В общем случае сообщение на диаграмме последовательности изображается в форме линии от передатчика сообщения к приемнику сообщения. Форма этой линии и стрелки зависит от сорта и вида сообщения (см. рис. 10.41).

Рис. 10.41. Графическое изображение различных видов сообщений между объектами на диаграмме последовательности

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

Сорт сообщения является перечислением следующих значений:

- ' synchcall' — синхронное сообщение, которое соответствует синхронному вызову операции. Синхронные сообщения обычно представляют вызовы методов и изображаются сплошной линией с закрашенной стрелкой (рис. 10.41, а). Синхронные сообщения приостанавливают поток выполнения до тех пор, пока не будет получен ответ;

- 'asynchcall' — асинхронное сообщение, которое соответствует асинхронному вызову операции. Асинхронные сообщения изображают сплошной линией с открытой стрелкой в форме буквы " V" (рис.10.41, б). Асинхронные сообщения не ждут ответа, не приостанавливают поток выполнения – сразу после их посылки происходит немедленный переход к следующему шагу, и последовательность продолжается;

- 'asynchsignal'— асинхронный сигнал, который соответствует некоторому асинхронному действию. Асинхронные сигналы также изображай сплошной линией с открытой стрелкой в форме буквы " V" (рис. 10.41, б).

Сообщение также может быть ответным(reply) от вызова метода. Такоесообщение изображается пунктирной линией с открытой стрелкой в форме |буквы " V" (рис. 10.41, в). Сообщение создания объекта(objectcreation) также сражается пунктирной линией с открытой стрелкой в форме буквы " V" (рис. 10.41 в).

Вид сообщения является перечислением следующих значений:

- 'complete' —- полное сообщение, для которого существует событие пере­дачи и событие приема. Семантикой полного сообщения является траек­тория: < Событие передачи, Событие приема>. Сообщения этого вида изо­бражаются рассмотренным ранее образом в зависимости от сорта сообщения;

-'lost' — потерянное сообщение, для которого существует событие пере­дачи и отсутствует событие приема. Оно интерпретируется как сообще­ние, которое никогда не достигнет своего места назначения. Семантикой этого сообщения является траектория: < событие передачи». Потерянные сообщения изображаются в форме небольшого черного круга на конце стрелки сообщения (рис. 7.3, г);

- 'found'— найденное сообщение, для которого существует событие приема и отсутствует событие передачи. Оно интерпретируется как со­общение, инициатор которого находится за пределами области описа­ния. Семантикой найденного сообщения является траектория: < событие приема>. Это может быть, например, шум или другая деятельность, ко­торую нет необходимости описывать детально. Найденные сообщения изображаются в форме небольшого черного круга на начальном конце сообщения (рис. 7.3, д);

 'unknown' — неизвестное сообщение, для которого отсутствуют событие передачи и событие приема. Эти сообщения не должны представляться надиаграмме последовательности.

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

А вот еще парочка обозначений. Первое из них — это анонимный экстор, которого изображают, если нужно показать использование объектов системы некоей внешней сущностью или абстрактным пользователем. Второе — это рефлексивное сообщение. Помните, что такое рефлексия? Правильно, самосозерцание! Тут, в принципе, происходит нечто подоб­ное: объект посылает сообщение самому себе. Так рисуют, если нужно по­казать действие, выполняемое самим объектом (или внутри него), либо то, что объект сам себя вводит в некоторое состояние (рис. 10.43).

 

 

Рис. 10.42.

 

Рис. 10.43.

И еще одно – можно легко представить ситуацию посылки сообщения в зависимости от истинности некоторого условия. Например, если цена приглянувшейся нам в магазине вещи меньше ста удобных единиц, мы вполне можем приобрести ее за наличные. Покупку на сум­му от 100 до 1000 долларов можно оплатить кредитной картой, а чтобы купить нечто, стоящее дороже 1000 у. е., придется брать кредит. А как изобразить такие ситуации (< ветвления) на диаграмме последовательнос­тей? Да легко (рис. 10.44)!

 

Рис. 10.44.

Впрочем, ветвление — конструкция для диаграмм последовательно­стей непопулярная и используется она в них очень редко. Считается, что ветвления более присущи диаграммам деятельностей.

Рассмотрим полный пример диаграммы последовательностей (см. рис. 10.45).

10.7. Диаграмма кооперации (collaborationdiagram)

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

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

Следует отметить, что использование диаграммы последовательнос­тей или диаграммы взаимодействия — личный выбор каждого проекти­ровщика и зависит от индивидуального стиля проектирования. Мы, на­пример, чаще отдаем предпочтение диаграмме последовательностей. На обозначениях, применяемых на диаграмме взаимодействия, думаем, не стоит останавливаться подробно. Здесь все стандартно: объекты обозна­чаются

 

Рис. 10.45. Пример диаграммы последовательностей

 

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

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

}

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

Рис. 10.46. Диаграмма кооперации работы персонала библиотеки

Другой пример связан с описанием процесса управления учебными курсами (см. рис. 10.47).

 

10.8. Диаграмма состояний (statechartdiagram)

 

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

 

Рис. 10.47. Диаграмма кооперации с описанием процесса управления учебными курсами

Еще один пример диаграммы кооперации для описания работы мобильного телефона (см. рис. 10.48).

 

Рис. 10.48. Диаграмма кооперации с описанием процесса управления мобильным телефоном

 

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

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

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

Приведем простейший пример диаграммы состояний (см. рис. 10.49).

Рис. 10.49. Диаграмма состояний диска DVD-RW

 

На рис. 10.50 приведен более сложный пример составного состояния. Одно из этих состояний содержит также параллельные подсостояния.

 

 

Рис. 10.50. Диаграмма состояний прохождения академического курса студентом

 

Лекция 17

10.9. Диаграмма деятельности (активности, activitydiagram)

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

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

Без объяснений рассмотрим следующий пример диаграммы активности (см. рис. 10.51).

 

 

Рис. 10.51. Диаграмма активности деятельности утром

 

На рис. 10.52 приведен более сложный пример диаграммы активности.

Рис. 10.52. Диаграмма активности при выполнении заказа по интернету

 

Обратим внимание, что на рис. 10.50 и 10.51 начало и конец изображаются разными символами. Начало изображается закрашенным кружком, а конец – в виде символа, напоминающего кошачий глаз (см. рис. 10.53).

Рис. 10.53

Без пояснений понятен также смысл символа, предшествующего принятию душа и пению и следующего за ними (см. рис. 10.51).Он означает распарал­леливание, а затем опять слияние воедино (синхронизацию) потоков уп­равления. Таким образом, операции «пение» и «душ» выполняютсяодновременно. Но­тация проста: несколько потоков управления сливаются в один или один поток разделяется на несколько (см. рис. 10.54).

Рис. 10.54

На диаграмме деятельности можно не только показать параллельно выполняемые действия, но и указать состояния объектов. Также есть возможность показывать распределение ролей и т.д. Рассмотрим еще один пример (см. рис. 10.55).

Рис. 10.55. Диаграмма деятельности работы с веб-приложением

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

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

Аналогия с дорожками действительно очень удачна. Именно таково официальное название элемента нотации UML, позволяющего указать распределение ролей на диаграмме активностей. Только дорожки это не бе­говые, а плавательные — они так и называются: swimlanes. Более формаль­но, дорожка — часть области диаграммы деятельности, на которой отобра­жаются только те деятельности, за которые отвечает конкретный объект.Предназначены они для разбиения диаграммы в соответствии с распреде­лением ответственности за действия. Имя дорожки может означать роль или объект, которому она соответствует. При использовании дорожек нота­ция слегка изменяется. Вот как, к примеру, выглядит диаграмма из преды­дущего примера, перерисованная с использованием дорожек (рис. 10.56).

 

Рис. 10.56.

Кстати, дорожки могут быть не только вертикальными, но и, если вам как автору так удобнее, горизонтальными. Изображаются горизон­тальные дорожки аналогично — просто поверните «обычные» дорожки на 90 градусов против часовой стрелки!

Есть еще один нюанс нотации диаграмм активностей, о котором мы пока не говорили: это так называемая траектория объекта, или поток объ­екта (objectflow). Суть его состоит в том, что на диаграмме деятельности можно изобразить и объекты, относящиеся к деятельности. С помощью символа зависимости (пунктирная стрелка, помните? ) эти объекты можно соотнести с той деятельностью или переходом, где они создаются, изменя­ются или уничтожаются. Представим такую ситуацию из повседневной жизни: вы приходите в какой-нибудь фастфуд и заказываете гамбургер с колой. Что, знакомо? Во время приготовления завтрака повар создает но­вый объект — гамбургер. Пока вы нетерпеливо выпиваете колу, официант перемещает этот объект (подает ваш заказ). Естественно, во время завтрака вы уничтожаете этот объект. Вот как это выглядит на диаграмме (рис. 10.57).

 

Рис. 10.57.

На этом можно было бы и закончить наш разговор о нотации диа­грамм активностей и их отличиях от блок-схем. Если бы не одно НО. Мы говорили, что деятельность — это протяженное по времени состав­ное действие. Составное! То есть составленное из более простых дейст­вий. Вот эти-то самые простые (атомарные) действия, а вернее, после­довательность их выполнения, частенько изображают внутри деятель­ности в виде маленькой диаграммы активностей. Это слегка напоминает матрешку — одна (а часто и не одна) диаграмма внутри другой. Мы не будем долго говорить об этом: нашей целью было просто обратить внимание читателя на подобную возможность «вложенных» диаграмм. Мы просто покажем пример (см. рис. 10.58).

 

Рис. 10.58.

 

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

10.10. Диаграмма развертывания (deploymentdiagram)

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

Такие диаграммы есть смысл строить только для аппаратно-программных систем, тогда как UML позволяет строить модели любых систем, не обязательно компьютерных.

Какую пользу можно извлечь из диаграмм развертывания? Во-первых, графическое представление ИТ-инфраструктуры может помочь бо­лее рационально распределить компоненты системы по узлам сети, от чего, как известно, зависит в том числе и производительность системы. Во-вторых, такая диаграмма может помочь решить множество вспомогатель­ных задач, связанных, например, с обеспечением безопасности.

Диаграмма развертывания показывает топологию системы и распре­деление компонентов системы по ее узлам, а также соединения — марш­руты передачи информации между аппаратными узлами. Это единствен­ная диаграмма, на которой применяются «трехмерные» обозначения: узлы системы обозначаются кубиками. Все остальные обозначения в UML — плоские фигуры. Но приведем пример (рис. 10.59):

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

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

 

 

Рис. 10.59. Пример диаграммы развертывания

 

 

Рис. 10.60. Диаграмма развертывания инфраструктуры учебного

 заведения

 

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

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

 

Вопросы к экзамену по курсу

«Проектирование АСОИУ»

Бакалавры

 

1. Общая постановка и формализация оптимизационной задачи разбиения ИЛМ проектируемой АСОИУ на модули обработки данных.

2. Постановка и формализация задачи разбиения ИЛМ проектируемой АСОИУ на модули обработки данных с минимальным числом информационных связей между ними.

3. Постановка и формализация задачи разбиения ИЛМ проектируемой АСОИУ на модули обработки данных с минимальным временем обмена информацией между оперативной памятью управляющей ЭВМ и базой данных.

4. Постановка общей задачи синтеза информационного обеспечения АСОИУ модульного типа. Формализация задачи определения числа и состава информационных массивов.

5. Постановка общей задачи синтеза информационного обеспечения АСОИУ модульного типа. Формализация задачи выбора оптимальных методов организации массивов и размещения модулей и массивов во внешней памяти ЭВМ. Формализация задачи определения величины блока данных.

6. Формализация общей задачи синтеза структуры АС.

7. Первая частная задача синтеза оптимальной структуры АСОИУ. Привести пример решения задач.

8. Вторая частная задача синтеза оптимальной структуры АСОИУ. Привести пример решения задач.

9. Третья частная задача синтеза оптимальной структуры АСОИУ. Привести пример решения задач.

10. Обобщенная математическая модель определения рациональной структуры распределенной АСОИУ.

11. Математическая модель оценки и обеспечения надежности сложного программного комплекса.

12. Классификация технической документации АСОИУ. Структура предпроектной документации.

13. Структура и требования ГОСТов к проектной документации разрабатываемой АСОИУ по общесистемным вопросам.

14. Структура и требования ГОСТов к проектной документации разрабатываемой АСОИУ по организационному обеспечению.

15. Структура и требования ГОСТов к проектной документации разрабатываемой АСОИУ по информационному обеспечению.

16. Структура и требования ГОСТов к проектной документации разрабатываемой АСОИУ по программному обеспечению.

17. Требования ГОСТов к выполнению схем алгоритмов, программ, данных и систем.

18. Постановка и агрегированная модель распределения ограниченных финансовых ресурсов проектной организации между затратами на НИР и ОКР.

19. Модель оценки технического уровня предстоящей разработки.

20. Модель распределения ресурсов по этапам выполнения разработки.

21. Общая постановка и формализация задачи оптимального формирования тематического плана работы проектной организации.

22. Двухуровневое распределение ресурсов между разработками методом динамического программирования

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

24. Модель определения начала выполнения новой разработки

25. Модели определения периодичности контроля процесса выполнения разработок.

26. Основные понятия языка UML.

 

ГРАФИК ЗАЩИТ КУРСОВЫХ ПРОЕКТОВ

СТУДЕНТАМИ ГРУПП 30-307Б И 30-308Б

 

Дата, время защиты, аудитория	Группа	Фамилия, имя студента
28.05.2014 с 14-00 ауд.207/3	30-307Б 30-307Б 30-307Б 30-308Б 30-308Б 30-308Б	Деревянкин Д.Е. Баландин А.А. Потапов К.Е. Данилов Е.В. Макагонов Д.В. Корнюхин Р.А.
29.05.2014 с 14-00 ауд.207/3	30-307Б 30-307Б 30-307Б 30-308Б 30-307Б 30-307Б	Казанцева Н.Д. Жильцова М.М. Диденко А.А. Гусев И.А. Кириллов С.И. Толмачев Н.Е.
02.06.2014 с 14-00 ауд.207/3	30-307Б 30-307Б 30-307Б 30-307Б 30-307Б	Герасимов С.И. Выдуйкин И.С. Черных А.Г. Вендин А.С. Ярошевич А.Б.

 

 

Зав. Кафедрой 302                               Хахулин Г.Ф.

 

⇐ Предыдущая24252627282930313233

Поделиться: