Файл: Инфрам.pdf

215
Объектно-ориентированные подходы описывают поведение объек- тов и их взаимодействие между собой. Хотя порой при этом выполняет- ся моделирование структуры объектов, но, на самом деле, это не являет- ся необходимым или даже желательным. Задачей аналитика является нахождение объектов, которые существуют наибольшее время, м моде- лирование поведения системы вокруг этих объектов. Такой подход по- зволяет получить ясное представление о повелении системы. Другая задача состоит в том, чтобы повторно использовать существующие сис- темные элементы, таким образом достигается значительное совершен- ствование последних.
При проектировании программных систем моделирование использу- ется для решения следующих задач [7, 21, 23]:
1) визуализация системы;
2) определение структуры и поведения системы;
3) получение шаблона, позволяющего сконструировать систему;
4) документирования принимаемых решений, используя полученные модели.
Для решения этих задач при описании поведения проектируемого программного продукта в настоящее время получил широкое распро- странение унифицированный язык моделирования UML (Unified Mod- eling Language) [6]. Этот язык создавался, как попытка объединить вме- сте объектно-ориентированные подходы, получившие наибольшую поддержку и признание, и именно подход Буча, ОМТ (техника объект- ного моделирования) и Обжектори (Objectory), предложенный Якобсо- ном. В середине 90-х годов 20 века Буч, Румбах и Якобсон стали вместе работать в компании Rational. Здесь они разработали единый, общий и ныне широко используемый язык моделирования. С момента своего появления UML неоднократно подвергался доработке и изменениям. В настоящее время используется версия UML 2.0, выпущенная в 2003 го- ду [17].
UML предполагает разработку нескольких моделей, совокупность которых описывает разрабатываемую систему [17, 25, 26]. Каждая мо- дель относится к соответствующему этапу разработки системы и имеет собственное предназначение. При этом каждая из моделей состоит из одной или нескольких UML-диаграмм, которые можно классифициро- вать следующим образом: структурные диаграммы; диаграммы поведения; диаграммы взаимодействия.
На рис. 5.21 представлены все типы диаграмм, существующих в но- тации UML 2.3 и доступных для использования в практике разработки программных систем. Часто бывает достаточно использовать из пере- численных лишь небольшой набор диаграмм для моделирования систе- мы.

216
Рис. 5.21. Типы диаграмм в нотации UML 2.3
Диаграмма классов (Class diagram) – статическая структурная диа- грамма, описывающая структуру системы, она демонстрирует классы системы, их атрибуты, методы и зависимости между классами.
Существуют разные точки зрения на построение диаграмм классов в зависимости от целей их применения: концептуальная точка зрения – диаграмма классов описывает модель предметной области, в ней присутствуют только классы прикладных объектов; точка зрения спецификации – диаграмма классов применяется при проектировании информационных систем; точка зрения реализации – диаграмма классов содержит классы, ис- пользуемые непосредственно в программном коде (при использова- нии объектно-ориентированных языков программирования).
Диаграмма компонентов (Component diagram) – статическая струк- турная диаграмма, показывает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами.
В качестве физических компонент могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т. п.
Диаграмма композитной/составной структуры (Composite structure diagram) — статическая структурная диаграмма, демонстрирует внут- реннюю структуру классов и, по возможности, взаимодействие элемен- тов (частей) внутренней структуры класса. Подвидом диаграмм компо- зитной структуры являются диаграммы кооперации (Collaboration diagram, введены в UML 2.0), которые показывают роли и взаимодейст- вие классов в рамках кооперации. Кооперации удобны при моделирова- нии шаблонов проектирования.
Диаграмма развёртывания (Deployment diagram) — служит для мо- делирования работающих узлов (аппаратных средств, англ. node) и ар-

217 тефактов, развёрнутых на них. В UML 2 на узлах разворачиваются ар- тефакты (англ. artifact), в то время как в UML 1 на узлах разворачива- лись компоненты. Между артефактом и логическим элементом (компо- нентом), который он реализует, устанавливается зависимость манифе- стации.
Диаграмма объектов (Object diagram) — демонстрирует полный или частичный снимок моделируемой системы в заданный момент времени.
На диаграмме объектов отображаются экземпляры классов (объекты) системы с указанием текущих значений их атрибутов и связей между объектами.
Диаграмма пакетов (Package diagram) — структурная диаграмма, основным содержанием которой являются пакеты и отношения между ними. Жёсткого разделения между разными структурными диаграмма- ми не проводится, поэтому данное название предлагается исключитель- но для удобства и не имеет семантического значения (пакеты и диа- граммы пакетов могут присутствовать на других структурных диаграм- мах). Диаграммы пакетов служат, в первую очередь, для организации элементов в группы по какому-либо признаку с целью упрощения структуры и организации работы с моделью системы.
Диаграмма деятельности (Activity diagram) — диаграмма, на кото- рой показано разложение некоторой деятельности на её составные час- ти. Под деятельностью (англ. activity) понимается спецификация испол- няемого поведения в виде координированного последовательного и па- раллельного выполнения подчинённых элементов — вложенных видов деятельности и отдельных действий (англ. action), соединённых между собой потоками, которые идут от выходов одного узла ко входам друго- го.
Диаграмма автомата (State Machine diagram, диаграмма конечного автомата, диаграмма состояний) — диаграмма, на которой представлен конечный автомат с простыми состояниями, переходами и композит- ными состояниями.
Конечный автомат (англ. State machine) — спецификация последова- тельности состояний, через которые проходит объект или взаимодейст- вие в ответ на события своей жизни, а также ответные действия объекта на эти события. Конечный автомат прикреплён к исходному элементу
(классу, кооперации или методу) и служит для определения поведения его экземпляров.
Диаграмма прецедентов (Use case diagram, диаграмма вариантов ис- пользования) — диаграмма, на которой отражены отношения, сущест- вующие между акторами и прецедентами.
Основная задача — представлять собой единое средство, дающее возможность заказчику, конечному пользователю и разработчику со- вместно обсуждать функциональность и поведение системы.
Диаграмма коммуникации (Communication diagram, в UML 1.x — диаграмма кооперации, collaboration diagram) — диаграмма, на которой изображаются взаимодействия между частями композитной структуры или ролями кооперации. В отличие от диаграммы последовательности,

218 на диаграмме коммуникации явно указываются отношения между эле- ментами (объектами), а время как отдельное измерение не используется
(применяются порядковые номера вызовов).
Диаграмма последовательности (Sequence diagram) — диаграмма, на которой изображено упорядоченное во времени взаимодействие объ- ектов. В частности, на ней изображаются участвующие во взаимодейст- вии объекты и последовательность сообщений, которыми они обмени- ваются.
Диаграмма сотрудничества — Этот тип диаграмм позволяет опи- сать взаимодействия объектов, абстрагируясь от последовательности передачи сообщений. На этом типе диаграмм в компактном виде отра- жаются все принимаемые и передаваемые сообщения конкретного объ- екта и типы этих сообщений.
По причине того, что диаграммы Sequence и Collaboration являются разными взглядами на одни и те же процессы, Rational Rose позволяет создавать из Sequence диаграммы диаграмму Collaboration и наоборот, а также производит автоматическую синхронизацию этих диаграмм.
Диаграмма обзора взаимодействия (Interaction overview diagram) — разновидность диаграммы деятельности, включающая фрагменты диа- граммы последовательности и конструкции потока управления.
Этот тип диаграмм включает в себя диаграммы Sequence diagram
(диаграммы последовательностей действий) и Collaboration diagram
(диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.
Диаграмма синхронизации (Timing diagram) — альтернативное пред- ставление диаграммы последовательности, явным образом показываю- щее изменения состояния на линии жизни с заданной шкалой времени.
Может быть полезна в приложениях реального времени.
Спецификация разрабатываемой системы при использовании UML объединяет несколько моделей: логическую, использования, процессов, развертывания.
Модель использования содержит описание функций программной системы с точки зрения пользователя.
Логическая модель описывает ключевые понятия моделируемой про- граммной системы (классы, интерфейсы и т. п.), т.е. средства, обеспечи- вающие ее функциональность.
Модель реализации определяет реальную организацию программных модулей в среде разработки.
Модель процессов отображает организацию вычислений и позволяет оценить производительность, масштабируемость и надежность про- граммной системы.
Модель развертывания показывает, каким образом программные компоненты размещаются на конкретном оборудовании.
Все вместе перечисленные модели, каждая из которых характеризует определенную сторону проектируемой системы, составляют относи- тельно полную модель разрабатываемого продукта.

219
На этапе постановки задачи и требований к системе используют диа- граммы прецедентов, диаграммы деятельностей для расшифровки со- держания прецедентов, диаграммы состояний для моделирования объ- ектов со сложными состояниями, диаграммы классов для выявления концептуальных сущностей предметной области задачи и диаграммы последовательностей действий.
5.3.2. Определение прецедентов использования
Для описания функциональных требований к системе используется моделирование прецедентов. Разработку спецификаций программной системы начинают с анализа требований к функциональности, указан- ных в техническом задании. В процессе анализа выявляют внешних пользователей разрабатываемой программной системы и перечень от- дельных аспектов ее поведения в процессе взаимодействия с конкрет- ными пользователями (отдельные физические лица, взаимодействую- щие системы, источники и потребители информации различной физиче- ской природы). Функциональные требования к системе документируют- ся во время разработки с помощью модели прецедентов использования, которая иллюстрирует планируемые функции системы (прецеденты использовании) их окружение (актеры) и связи между ними [14].
Прецеденты – это подробные процедурные описания вариантов ис- пользования системы всеми заинтересованными лицами, а также внеш- ними системами, т.е. всеми кто (или что) может рассматриваться как актеры (actors) – иначе действующие лица. По сути прецеденты – это своего рода алгоритмы работы с системой с точки зрения внешнего ми- ра. Прецеденты являются основой функциональных требований к сис- теме. Они позволяют описывать границы проектируемой системы, ее интерфейс, а затем выступают в качестве основы для тестирования сис- темы заказчиком с помощью приемочных тестов.
Актеры не являются частью системы – они представляют любые объекты, взаимодействующие с системой (пользователи, датчики, дру- гие системы и др.). Актер может: только вводить информацию в систему; только получать информацию от системы; вводить и получать информацию от системы.
Актеры выявляются на основании изучения предметной области, для которой предназначена разрабатываемая система, а также по результа- там общения с заказчиком системы и экспертами. Для определения ак- теров в системе можно использовать следующие вопросы:
Кто заинтересован в данных требованиях?
Где будет применяться данная система?
Кто выигрывает от использования системы?
Кто обеспечивает систему информацией и применяет эту информа- цию, а также удаляет ее?
Кто занимается поддержкой системы?
Использует ли система внешние ресурсы?

220
Выполняет ли один человек несколько ролей?
Выполняют ли несколько людей одну и ту же роль?
Взаимодействует ли система с уже действующими системами?
Модель прецедентов использования – это диалог между актерами и системой. Прецеденты использования представляют функциональность системы, т.е. то, какие возможности система предоставляет актерам.
Набор прецедентов использования системы охватывает все способы ее применения.
Прецедент использования – это последовательность выполняемых
системой транзакций, приводящих к измеримому результату, важному
для конкретного актера.
Для определения прецедентов использования в системе можно ис- пользовать следующие вопросы:
Какую задачу выполняет каждый актер?
Будет ли актер создавать, сохранять, изменять удалять или считы- вать информацию из системы?
В каком из прецедентов использования будет создаваться, сохра- няться, изменяться, удаляться, или считываться эта информация?
Потребуется ли актеру уведомлять систему о внезапных внешних изменениях?
Необходимо ли оповещать актеров о наступлении каких-либо собы- тий в системе?
Какой прецедент использования будет поддерживать систему?
Могут ли все функциональные требования быть выполнены с помо- щью прецедентов использования?
В зависимости от цели выполнения конкретной задачи различают следующие варианты диаграмм использования: основные, обеспечивающие выполнение функций проектируемой системы; вспомогательные, обеспечивающие выполнение настроек системы и ее обслуживание; дополнительные, служащие для удобства пользователя (реализуются в том случае, если не требуют серьезных затрат каких-либо ресурсов ни при разработке, ни при эксплуатации).
В качестве примера рассмотрим построение диаграмм вариантов ис- пользования для проведения анализа функциональных требований и пользователей системы тестирования, которая является модулем обу- чающей системы.
Система тестирования прежде всего требуется следующим заинтере- сованным лицам: обучаемому (студенту); составителю тестов (преподавателю); преподавателю, принимающему экзамен; сотруднику деканата, осуществляющему контроль за успеваемо- стью; администратору сети и баз данных учебного заведения.

221
На начальном этапе создания системы можно ограничиться только двумя важными для разработчика системы ролями действующих лиц: студент (тестируемый); администратор (он же преподаватель, он же составитель тестов).
Соответственно основные прецеденты (варианты использования) для системы тестирования следующие.
Прецедент для студента:
П1 – пройти тестирование.
Прецеденты для администратора:
П2 – создать (изменить) тест;
П3 – просмотреть результаты тестирования;
П4 – добавить (изменить) пользователей и др.
Каждый вариант использования можно описать кратко или подроб- но. Краткая форма содержит название варианта использования, его цель, действующих лиц, тип варианта использования (основной, вспо- могательный, дополнительный) и его краткое описание. Для примера составим краткое описание варианта использования для прецедента П1 в форме следующей таблицы (табл. 5.1).
Табл. 5.1