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

 Между актером и прецедентом может существовать ассоциативная связь, связь может быть как от Актера к прецеденту так и наоборот. Направление свзяи показывает кто является ее инициатором (актер или прецедент).

 

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

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

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

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

· точка зрения спецификации — диаграмма классов применяется при проектировании информационных систем;

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

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

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

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

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

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

Стереотип класса – это элемент расширения словаря UML, который обозначает отличительные особенности в использовании класса.

Диаграммы классов создаются для следующих целей:

· Для моделирования данных.

· Для представления архитектуры ПС.

· Для моделирования навигации экранов.

· Для моделирования логики программных компонент.

· Для моделирования логики обработки данных.

 

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

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

Этот тип диаграмм включает в себя:

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

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

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

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

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

 

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

 

42. Диаграмма кооперации (сотрудничества)

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

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

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

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

43. Диаграмма компонентов

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

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

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

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

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

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

спецификации исполняемого варианта программной системы;

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

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

 

44. Диаграмма взаимодействия (см. Вопрос 40)

 

 45. Диаграмма развертывания

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

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

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

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

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

· определить распределение компонентов системы по ее физическим узлам;

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

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

 

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

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

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

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

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

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

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

· в каждый момент времени автомат может находиться только в одном из своих состояний.

· время нахождения автомата в том или ином состоянии, а также время достижения того или иного состояния никак не специфицируются;

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

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

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

 

47. CASE-средства объектно-ориентированного моделирования.

Rational Rose — CASE-средство фирмы Rational Software Corporation (США) — предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разра­ботанная ими универсальная нотация для моделирования объек­тов является в настоя­щее время общепринятым стандартом в области объектно-ориентированного анализа и проек­тирования.

Конкретный вариант Rational Rose определяется язы­ком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант — Rational Rose/C++ — позволяет разрабатывать проектную докумен­тацию в виде диаграмм и спецификаций, а также генерировать про­граммные коды на C++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.

ERwin Process Modeler (ранее называвшийся AllFusion Process Modeler, ещё ранее BPwin) — программный продукт в области реализации средств CASE-технологий. Позволяет проводить описание, анализ и моделирование бизнес-процессов. Занимает одно из лидирующих мест в своём сегменте рынка. В настоящее время выпускается компанией Computer Associates. Включает три стандартные методологии: IDEF0 (функциональное моделирование), DFD (моделирование потоков данных) и IDEF3 (моделирование потоков работ). Эти методологии по-своему уникальны. Каждая из них может быть выполнена отдельно с помощью BPwin, но их совокупность заключённая в модель даёт аналитику полную картину предметной области клиента.

48. Технология RUP.

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

· Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков.

· Концентрация на выполнении требований заказчиков к исполняемой программе (анализ и построение модели прецедентов (вариантов использования)).

· Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.

· Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.

· Постоянное обеспечение качества на всех этапах разработки проекта (продукта).

· Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.

 Жизненный цикл разработки

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

Начало (Inception)

· Формируются видение и границы проекта.

· Создается экономическое обоснование (business case).

· Определяются основные требования, ограничения и ключевая функциональность продукта.

· Создается базовая версия модели прецедентов.

· Оцениваются риски.