Проектирование информационной системы

· Связи может даваться имя, выражаемое грамматическим оборотом глагола и помещаемое возле линии связи. Имя каждой связи между двумя данными сущностями должно быть уникальным, но имена связей в модели не обязаны быть уникальными. Имя связи всегда формируется с точки зрения родителя, так что предложение может быть образовано соединением имени сущности-родителя, имени связи, выражения степени и имени сущности-потомка.

· Последним шагом моделирования является идентификация атрибутов.

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

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

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

24. Объектно-ориентированная методология проектирования

Объектное моделирование

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

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

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

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

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

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

Если вы приняли объектно-ориентированный взгляд на мир, то придется ответить на ряд вопросов (см. главу 2). Какая структура должна быть у хорошей объектно-ориентированной архитектуры? Какие артефакты должны быть созданы в процессе работы над проектом? Кто должен создавать их? И наконец, как оценить результат?

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

25. Таксономия диаграмм языка унифицированного моделирования UML. Взаимодействие между диаграммами UML

Таксономмия (от др.-греч. фЬойт-- строй, порядок и ньмпт-- закон)-- учение о принципах и практике классификации и систематизации.

Диаграммы языка UML

Диаграммы языка UML делятся на две группы:

1) Структурные диаграмы;

2) Диаграммы поведения.

К структурным диаграммам языка UML относятся следующие диаграммы:

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

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

• Диаграммы компонентов (component diagram ) - используются при моделировании компонентной структуры распределенных приложений; внутри каждая компонента может быть реализована с помощью множества классов;

• Диаграммы развёртывания (deployment diagram ) - предназначены для моделирования аппаратной части системы, с которой ПО непосредственно связано (размещено или взаимодействует);

• Диаграммы композитных стурктур (Composite structure diagram) - используются для моделирования составных структурных элементов моделей - коопераций, композитных компонент и т.д.;

• Диаграммы пакетов (package diagram ) - служат для разбиения объемных моделей на составные части, а также (традиционно) для группировки классов моделируемого ПО, когда их слишком много.

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

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

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

• Диаграмма прецедентов использования (use case diagram ) [вариантов использования, случаев использования] - предназначены для определения («вытягивание») требований из пользователей, заказчика и экспертов предметной области;

• Диаграмма деятельности (activity diagram ) [активности]- используются для спецификации бизнес-процессов, которые должно автоматизировать разрабатываемое ПО, а также для задания сложных алгоритмов;

• Диаграмма конечных автоматов (state machine diagram ) [состояний] - применяются для задания поведения реактивных систем;

• Диаграмма взаимодействий (interaction diagrams )

o Диаграмма последовательностей (sequence diagram ) - используются для моделирования временных аспектов внутренних и внешних протоколов ПО;

o Диаграмма коммуникаций (communication diagram ) - являются аналогом диаграмм последовательностей, но по-другому изображаются (в привычной, графовой, манере);

o Диаграмма обзора взаимодействий (interaction overview diagram ) - служат для организации иерархии диаграмм последовательностей;

o Диаграмма синхронизации (timing diagram ) [временные] - являются разновидностью диаграмм последовательностей и позволяют в наглядной форме показывать внутреннюю динамику взаимодействия некоторого набора компонент системы.

Последовательность построения и использования UML диаграмм при проектировании информационных систем

Взаимодействие (Interaction) - это поведение, суть которого заключается в обмене сообщениями (Messages) между объектами в рамках конкретного контекста для достижения определенной цели (см. главу 15). С помощью взаимодействия южно описать как отдельную операцию, так и поведение совокупности объектов. взаимодействие предполагает ряд других элементов, таких как сообщения, последовательности действий (поведение, инициированное сообщением) и связи (между объектами). Графически сообщения изображаются в виде стрелки, над которой почти всегда пишется имя соответствующей операции, как показано на рис. 2.8.

Рис. 2. Взаимодействие между диаграммами UML

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

Инструменты моделирования с использованием UML: Borland Together, Gentleware Poseidon, Sun Java Studio Enterprise, Enterprise Architect, IBM Rational Rose, Dia, Start UML, Telelogic TAU G2, MS Visio, MS Visual Studio и др.

26. Структурные диаграммы UML. Диаграмма пакетов. Диаграмма классов.

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

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

· Виды:

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

1)Диаграмма классов -

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

3)Композитной/составной структуры

o Диаграмма кооперации (UML2.0)

4)Диаграмма развёртывания

5)Диаграмма объектов

6)Диаграмма пакетов

7)Диаграмма профилей (UML2.2)

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

· Диаграммы пакетов (package diagram ) - служат для разбиения объемных моделей на составные части, а также (традиционно) для группировки классов моделируемого ПО, когда их слишком много.

Рис. 8.1 Диаграмма классов

Общие свойства

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

Содержание

Диаграммы классов обычно содержат следующие сущности:

· классы (см. главы 4 и 9);

· интерфейсы (см. главу 11);

· кооперации (см. главу 27);

· отношения зависимости, обобщения и ассоциации (см. главы 5 и 10).

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

Также в диаграммах классов могут присутствовать пакеты (см. главу 12) или подсистемы (см. главу 31), применяемые для группирования элементов модели в более крупные блоки. Иногда в эти диаграммы помещают экземпляры (см. главу 13), особенно если требуется визуализировать их тип (возможно, динамический).

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

Типичные примеры применения

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

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

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

· для моделирования логической схемы базы данных. Логическую схему можно представлять себе как чертеж концептуального проекта базы данных. Во многих сферах деятельности требуется хранить устойчивую (persistent) информацию (см. главу 23) в реляционной или объектно-ориентированной базе данных. Моделировать схемы (см. главу 29) также можно с помощью диаграмм классов.

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

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

· Импортирование пакета

· Слияние пакета

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

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

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

27. Структурные диаграммы UML. Диаграмма компонентов. Диаграмма развертывания

Диаграммы языка UML делятся на две группы:

1) Структурные диаграммы;

2) Диаграммы поведения.

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

К структурным диаграммам языка UML относятся следующие диаграммы:

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

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

• Диаграммы компонентов (component diagram) - используются при моделировании компонентной структуры распределенных приложений; внутри каждая компонента может быть реализована с помощью множества классов;

• Диаграммы развёртывания (deployment diagram) - предназначены для моделирования аппаратной части системы, с которой ПО непосредственно связано (размещено или взаимодействует);

• Диаграммы композитных стурктур (Composite structure diagram) - используются для моделирования составных структурных элементов моделей - коопераций, композитных компонент и т.д.;

• Диаграммы пакетов (package diagram ) - служат для разбиения объемных моделей на составные части, а также (традиционно) для группировки классов моделируемого ПО, когда их слишком много.

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

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

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

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

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

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

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

28. Структурные диаграммы UML. Диаграмма объектов. Диаграмма композитных структур

Диаграммы языка UML делятся на две группы:

1) Структурные диаграммы;

2) Диаграммы поведения.

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

К структурным диаграммам языка UML относятся следующие диаграммы:

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

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

• Диаграммы компонентов (component diagram) - используются при моделировании компонентной структуры распределенных приложений; внутри каждая компонента может быть реализована с помощью множества классов;

• Диаграммы развёртывания (deployment diagram) - предназначены для моделирования аппаратной части системы, с которой ПО непосредственно связано (размещено или взаимодействует);

• Диаграммы композитных стурктур (Composite structure diagram) - используются для моделирования составных структурных элементов моделей - коопераций, композитных компонент и т.д.;

• Диаграммы пакетов (package diagram ) - служат для разбиения объемных моделей на составные части, а также (традиционно) для группировки классов моделируемого ПО, когда их слишком много.

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

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

§ Отношение зависимости (dependency relationship);

§ Отношение ассоциации (association relationship);

§ Отношение обобщения (generalization relationship).

Диаграмма композитной/составной структуры(Composite structure diagram)-- статическая структурная диаграмма, демонстрирует внутреннюю структуру классов и, по возможности, взаимодействие элементов (частей) внутренней структуры класса.

Подвидом диаграмм композитной структуры являются диаграммы кооперации (Collaboration diagram, введены в UML2.0), которые показывают роли и взаимодействие классов в рамках кооперации. Кооперации удобны при моделировании шаблонов проектирования.

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

29. Диаграммы прецедентов использования

Диаграмма прецедентов использования приписывает прецеденты использования к действующим лицам. Она также позволяет пользователю установить отношения между прецедентами использования, конечно, если такие отношения существуют. На рис. 3.3 показана диаграмма, демонстрирующая связи между прецедентами использования, показанных на рис. 3.2, и действующими лицами. На рис. 3.4 показана та же самая модель, содержащая прецеденты использования, связанные с субъектом. Несмотря на то, что расположение действующих лиц и прецедентов использования на диаграмме произвольно, при моделировании субъектов действующих лиц необходимо заключить в прямоугольную рамку. Обратите внимание на то, что одно и то же действующее лицо может быть изображено несколько раз.

Рис. 3.4 Диаграмма прецедентов использования, описывающая субъекты системы управления магазином видеокассет

Модели, показанные на рис. 3.3 и 3.4, демонстрируют, что действующее лицо Сотрудник непосредственно связано со всеми прецедентами использования. Действующее лицо Клиент может достичь своих целей лишь с помощью действующего лица Сотрудник, поэтому между ними существует зависимость (dependency). Прямая связь между действующим лицом Клиент и прецедентом использования Списание денег со счета означает, что клиент должен ввести PIN-код и подтвердить оплату с помощью сканирующего устройства.

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

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

Динамика каждого прецедента использования должна быть описана с помощью других моделей UML и/или с помощью спецификации потока событий (flow of events document), т.е. текстового документа, определяющего, что должна делать система, когда действующее лицо инициирует прецедент использования. Структура спецификации прецедента использования (use case document) может варьироваться, однако типичное описание должно содержать следующую информацию (Quatrani, 2000).

Краткое описание.

Участвующие действующие лица.

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

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

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

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

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

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

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

Диаграммы деятельности

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

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

Потоки могут разветвляться (branch) в зависимости от условий и сливаться (merge). В результате возникают альтернативные потоки вычислений (alternative computation thread). Условие ветвления обозначается ромбом. Выход из условия ветвления управляется событием, например Да или Нет, или сторожевым условием (guard condition), например [светло-зеленый], [высокий рейтинг].

Кроме того, потоки могут разделяться (fork) и воссоединяться (rejoin). В результате возникают параллельные потоки вычислений (concurrent computation threads). Разделение и воссоединение потоков представляется в виде жирной линии. Диаграмма деятельности, в которой отсутствуют параллельные процессы, похожа на обычную блок-схему (в этом разделе параллельное функционирование системы не рассматривается).

Для того чтобы нарисовать диаграмму, демонстрирующую работу магазина видеокассет, достаточно соединить действия, идентифицированные на рис. 3.5, соответствующими потоками, как показано на рис. 3.6. Начальным является действие Вывести на экран информацию о транзакции. Рекурсивный поток (recursive flow), связанный с этим действием, отражает тот факт, что изображение дисплея постоянно обновляется, пока вычисления не перейдут в следующий узел.

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

Необходимость проверки условия Есть ли проблемы с оплатой? объясняется возможной нехваткой денег у заказчика. Если проблем нет, то транзакция подтверждается и процесс переходит к заключительному действию. В противном случае следует проверить рейтинг заказчика. В зависимости от рейтинга транзакция отменяется (если выполняется сторожевое условие [Плохой]), допускается частичная оплата (если выполняется сторожевое условие [Хороший]) или допускается прокат без оплаты (если выполняется сторожевое условие [Отличный]).

Рис. 3.6 Диаграмма активности

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

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

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

На рисунке мы видим пример простой диаграммы состояний конечного автомата:

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

Например в состоянии новорожденный, объект выполняет условие "несовершеннолетний" и находиится в ожидании исполнения 18 летия.

Переход(transition)- объединение между двумя состояниями. Объект переходит из одного состояния в другое(при выполнении определнных условий).

Разделение показывает переход до того же самого состояния(при условии, что произойдет что то значимое, но при этом состояние не изменится)

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

Дальнейшие подробности:

Конечный автомат это график состояний и переходов между ними, который описывает реакцию объекта( точнее: реакцию экземпляра классификатора)на произошедшее событие. Состояние конечного автомата может присоединятся к классификатору(например: прецедент, класс),к сотрудничеству или к методу.Элемент, к которому присоединяется состояние автомата, называет владелец (owner) состояния автомата. В целом конечный автомат состояний это в собственно сложное состояние(coposite state), который рекурсивно декомпонован на субсостояния. Самое нижнее состояние( на рисунке диаграммы) не имеет субсостоянии.

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

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

Переход (transition) это отношение в конечном автомате между двумя состояниями. Объект в первом состоянии перейдет в другое состояние тогда, когда произойдет определенное событие(event) и будут исполнены определенные условия(guards), причем в это время произойдет определнный определенное действие(action, activity,effect). Переход между состояниями нельзя приостановить, то есть он протекает непрерывно.Говорят, что переход это огонь(transition is fire). Переход может иметь как несколько исходных состояний, так и несколько целевых состояний

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

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

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

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

- Окно Ввода Заказа посылает Заказу сообщение "приготовиться";

- Заказ посылает данное сообщение каждой Строке заказа в данном Заказе;

- Каждая Строка заказа проверяет состояние определенного Запаса товара: Если данная проверка удовлетворяется (результат -- true), то Строка заказа удаляет соответствующее количество товара из Запаса.

В противном случае количество Запаса снижается до уровня повторного заказа, и Запас запрашивает новую поставку товара.

Существуют два вида диаграмм взаимодействия:

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

-кооперативные диаграммы(collaboration diagrams).

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

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

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

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

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

31. Последовательность проектирования информационной системы средствами UML

Основные типы UML-диаграмм, используемые в проектировании информационных систем. Взаимосвязи между диаграммами. Поддержка UML итеративного процесса проектирования ИС. Этапы проектирования ИС: моделирование бизнес-прецедентов, разработка модели бизнес-объектов, разработка концептуальной модели данных, разработка требований к системе, анализ требований и предварительное проектирование системы, разработка моделей базы данных и приложений, проектирование физической реализации системы.

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

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

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

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

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

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

Диаграммы видов деятельности (диаграммы деятельностей, activity diagrams) - модель бизнес-процесса или поведения системы в рамках прецедента.

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

Диаграммы состояний (statechart diagrams) - модель динамического поведения системы и ее компонентов при переходе из одного состояния в другое.

Диаграммы классов (class diagrams) - логическая модель базовой структуры системы, отражает статическую структуру системы и связи между ее элементами.

Диаграммы базы данных (database diagrams) - модель структуры базы данных, отображает таблицы, столбцы, ограничения и т.п.

Диаграммы компонентов (component diagrams) - модель иерархии подсистем, отражает физическое размещение баз данных, приложений и интерфейсов ИС.

Диаграммы развертывания (диаграммы размещения, deployment diagrams) - модель физической архитектуры системы, отображает аппаратную конфигурацию ИС.

Нарис. 12.1показаны отношения между различными видами диаграмм UML. Указатели стрелок можно интерпретировать как отношение «является источником входных данных для...» (например, диаграмма прецедентов является источником данных для диаграмм видов деятельности и последовательности). Приведенная схема является наглядной иллюстрацией итеративного характера разработки моделей с использованием UML.

Рис. 12.1 Взаимосвязи между диаграммами UML

Ниже приводятся описания последовательных этапов проектирования ИС с использованием UML.

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

Модель бизнес-прецедентов описывает бизнес-процессы с точки зрения внешнего пользователя, т.е. отражает взгляд на деятельность организации извне.

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

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

Прецедент - законченная последовательность действий, инициированная внешним объектом (личностью или системой), которая взаимодействует с ИС и получает в результате некоторое сообщение от ИС. На диаграмме представляется овалом с надписью, отражающей содержание действия.

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

Ассоциация - связь между двумя элементами модели. На диаграмме представляется линией.

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

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

Для иллюстрации этапов разработки проекта использованы адаптированные материалы проекта ИС медицинского центра [рис. 12.1]. Назначение ИС - автоматизация ведения и использования клинических записей о пациентах. В настоящее время эта работа производится вручную персоналом центра. Нарис. 12.2представлена общая модель деятельности центра в виде диаграммы прецедентов. Прецедент «Обслуживание пациента» реализуется через множество других, более ограниченных прецедентов (рис. 12.3), отражающих детализацию представления функционирования центра.

Рис. 12.2 Общая диаграмма деятельности медицинского центра по обслуживанию пациента

Рис. 12.3 Модель бизнес-прецедентов, составляющих обслуживание пациента

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

прецедент должен описывать, ЧТО нужно делать, а не КАК;

прецедент должен описывать действия с точки зрения ИСПОЛНИТЕЛЯ;

прецедент должен возвращать исполнителю некоторое СООБЩЕНИЕ;

последовательность действий внутри прецедента должна представлять собой одну НЕДЕЛИМУЮ цепочку.

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

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

Рис. 12.4 Диаграмма видов деятельности для прецедента «Оказание медицинской помощи»

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

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

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

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

Размещено на Allbest.ru