Александров Д. В., Грачев И. В., Фадин Д. Н

Д.В. Александров, И.В. Грачев, Д.Н. Фадин

CASE-технологии

Учебное пособие

«В печать»

Составители: Д.В. Александров

И.В. Грачев

Д.Н. Фадин

Зав. кафедрой А.В. Костров

Редактор

Корректор

Начальник РИО Е.П. Викулова

Директор РИК Ю.К. Жулев

Проректор ВлГУ по ИТ В.А. Немонтов

Владимир 2006

Государственное образовательное учреждение
высшего профессионального образования

Владимирский государственный университет

Кафедра информационных систем и информационного менеджмента

Д.В. Александров, И.В. Грачев, Д.Н. Фадин

CASE-ТЕХНОЛОГИИ

Учебное пособие

Владимир 2006

Д.В. Александров, И.В. Грачев, Д.Н. Фадин

CASE-ТЕХНОЛОГИИ

Учебное пособие

Владимир 2006

УДК 681.518 (076)

ББК 32.988-5 я7

А 46

Рецензенты

Доктор технических наук, профессор

Владимирского государственного педагогического университета

Н.Г. Наянзин

Кафедра информационных систем и информационного менеджмента

Владимирского государственного университета,

зав. кафедрой доктор технических наук, профессор

А.В. Костров

Печатается по решению редакционно-издательского совета

Владимирского государственного университета

Александров Д. В., Грачев И. В., Фадин Д. Н.

A46 CASE -технологии: учеб. пособие; Владим. гос. ун-т. – Владимир: Ред.-издат. комплекс, 2006. – 64 с.

Рассматриваются особенности моделирования бизнес-процессов и программного обеспечения информационных систем на основе технологии RUP (Rational Unified Process)с использованием CASE -средств Rational Rose (Rational Software Corporation), Enterprise Architect (Sparx Systems) и ArcStyler Tool Suite (iO-Software). В частности, уделяется внимание изучению особенностей стандарта UML 2 при построении комплексных моделей информационных систем и бизнес-процессов, подлежащих последующей автоматизации.

Предназначено для студентов специальности 230201 – «Информационные системы и технологии» при выполнении курсовой работы и лабораторных занятий по курсу «CASE-технологии», магистрантов направления 230200 – «Информационные системы» при выполнении курсовой работы по курсу «Распределенные информационные системы», а также при выполнении практических занятий по дисциплинам «Администрирование в распределенных автоматизированных системах» и «Информационный менеджмент». Пособие предназначено также для аспирантов специальности 051301 – системный анализ, управление и обработка информации (промышленность) при выполнении практических и лабораторных занятий по дисциплинам «Информационные технологии в науке и образовании» и «Распределенные информационные системы». Рекомендуется преподавателям при проведении занятий со студентами, магистрантами и аспирантами.

Ил. 33. Библиогр.: 11 назв.

УДК 681.518 (076)

ББК 32.988-5 я7

ПРЕДИСЛОВИЕ

CASE -технология (Computer Aided Software Engineering) представляет собой методологию проектирования ИС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей.

Под термином CASE -средства понимаются программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного программного обеспечения и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE -средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС [1].

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

В настоящем учебном пособии рассматривается технология Rational Unified Process и унифицированный язык моделирования UML 2.

1. Основы языка UML

1.1. Назначение и структура языка UML

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

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

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

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

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

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

· Семантика языка UML. Представляет собой некоторую метамодель, которая определяет абстрактный синтаксис и семантику понятий объектного моделирования на языке UML.

· Нотация языка UML. Представляет собой графическую нотацию для визуального представления семантики языка UML.

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

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

Таким образом, язык UML предназначен, прежде всего, для решения следующих основных задач:

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

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

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

· Интегрировать в себя новейшие и наилучшие достижения практики ООАП.

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

В терминах языка UML 2 все представления о модели сложной системы фиксируются на следующих видах диаграмм (рис. 1.1):

Структурные диаграммы:

Ø Диаграмма классов (class diagram)

Ø Диаграмма объектов (object diagram)

Ø Диаграммы реализации (implementation diagrams):

§ Диаграмма компонентов (component diagram)

§ Диаграмма развертывания (deployment diagram)

Ø Композитная структурная диаграмма (composite structure diagram)

Ø Диаграмма пакетов (package diagram)

Диаграммы поведения (behavior diagrams):

Ø Диаграммы взаимодействия (interaction diagrams):

§ Диаграмма последовательностей (sequence diagram)

§ Диаграмма коммуникации (communication diagram)

§ Обзорная диаграмма взаимодействия (interaction overview diagram)

§ Временн а я диаграмма (timing diagram)

Ø Диаграмма видов деятельности (activity diagram)

Ø Диаграмма прецедентов (use case diagram)

Ø Диаграмма состояний (state machine diagram)

Рис. 1.1. Иерархия диаграмм языка UML

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

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

1.2. Особенности изображения диаграмм языка UML

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

В языке UML используется четыре основных вида графических конструкций:

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

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

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

Рис. 1.2. Основные элементы структурных диаграмм языка UML

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

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

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

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

· Вся информация о сущностях должна быть явно представлена на диаграммах.

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

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

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

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

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

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

1.3. Диаграмма прецедентов (use case diagram)

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

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

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

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

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

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

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

Рис. 1.3. Элементы диаграммы прецедентов

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

так, как определит сам разработчик (рис. 1.3).

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

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

1.3.1. Особенности построения диаграмм прецедентов

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

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

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

Рис. 1.4. Пример диаграммы прецедентов

1.3.2. Рекомендации по разработке диаграмм прецедентов

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

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

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

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

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

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

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

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

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

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

1.4. Диаграмма классов (class diagram)

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

Рис. 1.5. Элементы диаграммы классов

Имеется 2 вида основных статических отношений:

· ассоциации (человек может сделать покупку в магазине);

· подтипы (корпоративный клиент, является разновидностью клиента).

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

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

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

В общем случае кратность указывает верхнюю и нижнюю границу количества объектов, которые могут участвовать в отношении. Часто используемые варианты кратности:

· 1 – означает, что в ассоциации участвует один, и только один экземпляр класса, с которым связана ассоциация;

· * - в ассоциации может участвовать неограниченное число экземпляров класса;

· 0..1 - в ассоциации участвует либо один, либо ни одного экземпляра класса;

· 0..N - в ассоциации участвует от 0 до N экземпляров класса.

Стрелками в ассоциации обозначается направление навигации, таким образом, если в ассоциации присутствует стрелка, то она из симметричной преобразуется в одностороннюю (см. рис. 1.9).

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

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

Атрибуты являются элементами класса, определяющими его сущность. В синтаксисе UML описание атрибута выглядит следующим образом: <видимость><имя>:<тип>=<значение по умолчанию>.

В примере диаграммы классов, представленном на рис. 1.6.1, атрибутами являются: имя, адрес, лимитКредита и др.

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

· видимость - принимает одно из трех значений: «+» общедоступная (public), «#» защищенная (protected) либо «-» закрытая (private);

· имя – строка символов;

· список параметров – содержит собой перечисленные через запятую параметры, которые описываются также как и атрибуты;

· выражение, возвращающее значение типа – содержит перечисленные через запятую значения типов;

· строка свойств – указывает свойства, которые имеются у данной операции.

1.4.1. Рекомендации по построению диаграмм классов

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

1.5. Диаграмма видов деятельности

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

Рис. 1.7. Элементы диаграммы видов деятельности

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

пользователем (в том числе и видов деятельности). Действия могут иметь входы и выходы, называемые контактами (Pin), которые связываются ребрами потоков объектов. Контакты являются разновидностью узлов объектов, поэтому они временно сохраняют значения данных в потоке. В простейшем случае для начала выполнения действия требуется наличие всех его входных данных.

Вид деятельности (Activity) — это спецификация поведения системы в виде координируемой последовательности действий.

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

Раздел (ActivityPartition) представляет собой средство группировки действий в соответствии с некоторым признаком. Действие может входить одновременно в несколько разделов. Раздел может содержать несколько подразделов. Особым видом разделов являются т.н. внешние разделы, используемые для представления сущностей, внешних по отношению к системе. Внешние разделы помечаются стереотипом <<external>>. Наиболее часто разделы применяются на этапе определения требований для моделирования подразделений организационной структуры или отдельных исполнителей в бизнес-моделях. Так, в примере на рис. 1.8 разделы «Отдел заказов», «Бухгалтерия» и «Покупатель» отражают исполнителей бизнес-процесса обработки заказа.

Рис. 1.8. Пример диаграммы видов деятельности

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

В диаграммах видов деятельности имеется три вида узлов (условные обозначения приведены на рис. 1.9):

§ Узлы действия оперируют получаемыми управляющими воздействиями и значениями данных и предоставляют управление и данные другим действиям.

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

§ Объектные узлы временно удерживают маркеры данных, которые ожидают продолжения движения по графу.

Узлы связываются направленными ребрами двух типов.

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

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

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

Ветвление (DecisionNode) дает возможность показать ветвление управляющих потоков, он имеет единственный вход и несколько выходов со сторожевыми условиями. Так как может выполниться только один из выходных переходов, то сторожевые условия должны взаимно исключать друг друга. Сторожевые условия изображаются в квадратных скобках около линии перехода. Если в качестве сторожевого условия используется [иначе], то это означает, что переход с данной меткой срабатывает в том случае, если все другие переходы для данного ветвления являются ложными. Слияние (MergeNode) имеет несколько входов и единственный выход. Данный блок означает окончание условного поведения, которое было начато соответствующим ветвлением.

Рис. 1.9. Узлы диаграммы видов деятельности

Параллельное поведение изображается при помощи разделений (ForkNode) и объединений (JoinNode). Последовательность выполнения параллельных действий является произвольной.

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

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

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

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

Рис. 1.10. Структура пакетов для моделирования видов деятельности

Пакет фундаментальных видов деятельности (FundamentalActivities) содержит абстрактную концепцию вида деятельности. Отсюда отношения зависимости разводятся по двум направлениям: одно направление используется, в первую очередь, для моделирования программного обеспечения (структурированные виды деятельности), а второе — для моделирования общих процессов (базовые, промежуточные и полные виды деятельности). В диаграммах структурированных видов деятельности (пакет StructuredActivities) вводятся ограничения на вложенность управляющих конструкций, а также конструкции, предназначенные для моделирования условных значений, переменных, обработки исключений и т.д. Определение потоков управления и данных находится в пакете базовых видов деятельности (BasicActivities). В диаграммах промежуточных и полных видов деятельности (IntermediateActivities и CompleteActivities) вводятся явный параллелизм, разделы, основанная на потоках обработка исключительных ситуаций и ряд конструкций для избирательного управления потоками. Эти ветви являются ортогональными, так что их конструкции можно комбинировать. Так, на одной диаграмме могут совмещаться элементы из пакетов структурных и промежуточных видов деятельности, что позволяет одновременно использовать и явный параллелизм, и структурированные условные выражения.

1.6. Диаграммы взаимодействия

Диаграммы взаимодействия (interaction diagrams) представляют собой модели, которые необходимы для описания поведения взаимодействующих групп объектов.

Рис. 1.11. Элементы временной диаграммы

В языке UML существует четыре вида диаграмм взаимодействия: диаграмма последовательностей, диаграмма коммуникации, обзорная диаграмма взаимодействия и временн а я диаграмма (в пособии не рассматривается – рис. 1.11).

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

1.6.1. Диаграмма последовательностей

Диаграмма последовательностей (sequence diagram) отражает поток событий, происходящих при реализации некоторого прецедента, на этой диаграмме изображаются актеры, объекты, а также принимаемые и посылаемые ими сообщения (рис. 1.12).

Рис. 1.12. Пример диаграммы

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

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

Объект (Object) – это экземпляр класса, конкретная сущность или образец, он может инициировать некоторые события, которые могут влиять на систему. На диаграмме последовательностей все объекты расположены последовательно в верхней части диаграммы, за исключением объектов, создаваемых в результате тех или иных сообщений (примером последнего является объект Payment на рис. 1.14). От каждого объекта вниз отходит штриховая линия, называемая линией жизни (Lifeline) объекта. На ней показывают все, что происходит с объектом с момента его создания и до разрушения. Частным случаем объекта может быть актер, он используется в том случае, когда необходимо показать связь участников и прецедентов.

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

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

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

Управляющая информация может быть представлена в виде условия, которое указывает, когда сообщение может быть передано, либо при помощи маркера итерации, который показывает, что сообщение посылается множество раз. Такая итерация указывается в следующем виде: *[условие итерации].

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

· вызов процедуры или другого потока управления (рис.1.14а);

· поток управления (рис. 1.14б) показывает направление потока управления и последовательности шагов;

· асинхронное стимулирующее воздействие (рис.1.14в)

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

Рис. 1.14. Виды стрелок сообщений

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

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

Комбинированный фрагмент (CombinedFragment) представляет собой выражение над фрагментами взаимодействия, состоящее из оператора и операндов – фрагментов взаимодействия. С каждым операндом может быть связано сторожевое условие. В языке UML над фрагментами взаимодействий определены следующие основные операторы:

· alt – выполняется не более одного операнда, для которого сторожевое условие истинно;

· opt – необходимость выполнения единственного операнда определяется его сторожевым условием;

· break – единственный операнд выполняется вместо всех остальных сообщений в объемлющем фрагменте взаимодействия в случае, если его сторожевое условие истинно;

· loop – циклическое выполнение единственного операнда, минимальное и максимальное количество итераций указывается в операнде;

· par – параллельное выполнение операндов при сохранении последовательности сообщений в каждом из них;

· strict – строго последовательное выполнение операндов;

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

· critical – критический участок, операнды выполняются без перекрытия во времени с любыми другими сообщениями, которые относятся к тем же линиям жизни, которые задействованы в операндах;

· neg – единственный операнд представляет неправильную последовательность сообщений;

· assert – операнды представляют собой единственные допустимые продолжения взаимодействия;

· ignore {} – определяет множество сообщений, которые не показаны в данном фрагменте и могут быть проигнорированы при выполнении взаимодействия;

· consider {} – определяет множество сообщений, которые должны быть приняты во внимание в данном фрагменте, все остальные сообщения игнорируются.

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

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

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

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

1.6.2. Диаграмма коммуникации

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

Рис. 1.15. Пример диаграммы коммуникации

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

1.6.3. Обзорная диаграмма взаимодействия

Обзорная диаграмма взаимодействия (interaction overview diagram) отражает потоки управления, возникающие при реализации некоторого прецедента (см. рис. 1.16).

Рис. 1.16. Пример обзорной диаграммы взаимодействия

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

Обзорная диаграмма взаимодействия позволяет альтернативным способом представить следующие виды комбинированных фрагментов взаимодействия: фрагменты alt и opt заменяются узлом разветвления и парным ему узлом слияния; фрагмент par заменяется узлом разделения и парным ему узлом объединения; фрагмент loop представляется в виде простого цикла. В силу этого в рассматриваемых диаграммах условные и параллельные потоки управления должны быть строго вложенными.

Рис. 1.17. Элементы обзорной диаграммы взаимодействия

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

1.7. Диаграмма состояний

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

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

Рассмотрим основные элементы диаграммы состояний (рис. 1.19).

Рис. 1.18. Пример диаграммы состояний

Рис. 1.19. Пример диаграммы состояний

Состояние (State) отображает одно из возможных состояний, в котором может находиться объект (см. рис. 1.19).

Кроме имени в элементе State может содержаться также краткое описание состояния и деятельности, осуществляемой в этом состоянии.

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

· входное воздействие – поведение, которое наступает при переходе объекта в данное состояние. Входное действие не прерывается и всегда выполняется до конца;

· деятельность – поведение, которое реализует объект, находящийся в данном состоянии;

· выходное действие – действие, которое выполняется при выходе объекта из текущего состояния.

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

Переход (Transition) объекта из одного состояния в другое отображается направленной стрелкой. Синтаксис метки перехода состоит из трех частей, каждая из которых является необязательной: Событие:[Сторожевое условие]/Действие.

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

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

Конечное состояние (Stop) – состояние, в котором объект пребывает непосредственно перед его уничтожением. Это необязательный элемент, причем количество таких элементов на диаграмме не ограничено.

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

2. ПРОЕКТИРОВАНИЕ системы ПО технологии RUP [*]

В ходе работы над языком UML А. Джекобсоном были проанализированы распространенные в 1990х годах технологии разработки сложных программных систем, результатом чего явилась концепция унифицированного процесса разработки ПО Rational Unified Process** (RUP), поддерживающего объектно-ориентированную технологию.

Технология RUP обладает следующими основными особенностями:

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

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

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

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

Производитель компьютеров предлагает возможность приобретения своей продукции через Internet. Клиент может выбрать компьютер на Web-странице производителя. Компьютеры подразделяются на серверы, настольные и портативные. Заказчик может выбрать любую конфигурацию. Компоненты конфигурации представляются как список. Для каждой конфигурации предоставляется цена.

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

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

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

1) Процесс управления проектом;

2) Процесс моделирования производства;

3) Процесс управления требованиями;

4) Процесс анализа и проектирования;

5) Процесс реализации;

6) Процесс тестирования;

7) Процесс управления конфигурацией и изменениями;

8) Процесс управления средой;

9) Процесс распространения.

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

2.1. Технологический процесс управления требованиями

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

2.1.1. Выявление требований

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

Выявленные требования представлены в табл. 2.1.

2.1.2. Выявление актеров и прецедентов

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

2.1.3. Построение диаграммы прецедентов

Диаграмма прецедентов приписывает прецеденты к актерам; она также позволяет установить отношения между прецедентами, если таковые существуют. Диаграмма прецедентов представлена на рис. 2.1.

2.1.4. Составление документа описания прецедентов

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

1) Краткое описание;

2) Участвующие актеры;

3) Предусловия, необходимые для инициирования прецедента;

4) Детализированное описание потока событий, которое включает:

- основной поток событий;

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

Таблица 2.1

Распределение требований по актерам и прецедентам

Поиск по сайту: