Файл: Учебник Рекомендовано Федеральным государственным учреждением.pdf

скрывает реализацию, которая обеспечивает это поведение. Инкап­
суляция достигается с помощью информационной закрытости.
Обычно скрываются структура объектов и реализация их методов.
Модульность — это свойство системы, связанное с возможно­
стью ее декомпозиции на ряд модулей. Модули служат физиче­
скими контейнерами, в которых объявляются классы и объекты логической обработки. Общая цель декомпозиции на модули — уменьшение сложности программного обеспечения за счет вы­
деления модулей, которые проектируются и изменяются незави­
симо друг от друга. Изменение реализации модулей должно про­
водиться без знания реализации других модулей и без влияния на их поведение.
Иерархия (иерархическая организация) — это формирование из абстракций иерархической структуры, т.е. расположение их по уровням. Основными видами иерархических структур примени­
тельно к сложным системам являются:
— структура классов (один класс использует структурную или функциональную часть соответственно одного или нескольких других классов);
— структура объектов (агрегация, например структура типа
«запись»).
Важное качество объектного подхода — согласованность моделей деятельности организации и моделей проектируемой информаци­
онной системы от стадии формирования требований до стадии реализации. По объектным моделям может быть прослежено ото­
бражение реальных сущностей моделируемой предметной области
(организации) в объекты и классы информационной системы.
Объектно-ориентированный подход обладает следующими преимуществами.
1. Объектная декомпозиция дает возможность создавать моде­
ли меньшего размера путем использования общих механизмов, обеспечивающих необходимую экономию выразительных средств.
Использование объектного подхода существенно повышает уро­
вень унификации разработки и пригодность для повторного ис­
пользования, что ведет к созданию среды разработки и переходу к сборочному созданию моделей.
2. Объектная декомпозиция позволяет избежать создания слож­
ных моделей, так как она предполагает эволюционный путь раз­
вития модели на базе относительно небольших подсистем.
3. Объектная модель естественна, поскольку ориентирована на человеческое восприятие мира.
К недостаткам объектно-ориентированного подхода относятся высокие начальные затраты. Этот подход не дает немедленной отдачи. Эффект от его применения сказывается после разработки двух—трех проектов и накопления повторно используемых ком­

понентов. Диаграммы, отражающие специфику объектного под­
хода, менее наглядны.
4.3.2. UML — язык универсального моделирования
Большинство существующих методов объектно-ориентиро­
ванного подхода включают язык моделирования и описание про­
цесса моделирования. В качестве языка моделирования в объект­
ном подходе используется унифицированный язык моделирования
UML, который содержит стандартный набор диаграмм для моде­
лирования. В настоящее время UML является общепринятым стандартом документирования процесса создания информацион­
ных систем и их программного обеспечения.
Разработка универсального языка моделирования UML нача­
лась с середины 1990-х годов на базе нескольких объектно-ориен- тированных методов и нотаций описания информационных си­
стем. Причиной, побудившей к созданию универсального языка описания программного обеспечения, явилась постоянно возрас­
тающая сложность проектируемых информационных систем, которая в свою очередь диктуется усложнением решаемых задач.
Когда количество объектов информационной системы не превы­
шает 7 — 8 (психологический барьер, за которым человек не в со­
стоянии оперировать информацией без дополнительных записей), сложности, возникающие при проектировании системы, преодо­
лимы и без специальных средств. Такую информационную систе­
му (для одного рабочего места или для небольшой компании) способен создать один человек. Когда же число объектов, состоя­
ний и переходов между ними доходит до нескольких тысяч, а то и миллионов, то ни один специалист, каким бы опытным и обра­
зованным он не был, не в состоянии охватить всю систему в целом.
Такие информационные системы создаются группами разработ­
чиков с разделением функциональных ролей. Тогда становится необходимым инструмент общения, каковым является UML.
Конструктивное использование языка UML основывается на понимании общих принципов моделирования сложных систем и особенностей процесса объектно-ориентированного анализа и проектирования, абстрагирования, многомодельности, иерархи­
ческого построения моделей сложных систем. Эти принципы уже упоминались выше.
Принцип абстрагирования заключается в выделении существен­
ных аспектов системы и отвлечении их от несущественных.
Принцип многомодельности представляет собой утверждение о том, что никакая единственная модель не может с достаточной степенью адекватности описывать различные аспекты сложной системы. Применительно к методологии объектно-ориентиро­
113

ванного анализа это означает, что достаточно полная модель сложной системы допускает некоторое число взаимосвязанных представлений, каждое из которых адекватно отражает некоторый аспект поведения или структуры системы.
Принцип иерархического построения предписывает рассма­
тривать процесс построения модели на разных уровнях абстраги­
рования или детализации в рамках фиксированных представлений.
При этом исходная, или первоначальная, модель сложной системы имеет наиболее общее представление (метапредставление). Такая модель строится на начальном этапе проектирования и может не содержать многих деталей и аспектов моделируемой системы.
Концептуальная модель UML включает в себя три составные ча­
сти: основные строительные блоки языка, правила их сочетания и некоторые общие для всего языка механизмы.
UML — это язык, состоящий из словаря и правил, позволя­
ющих комбинировать входящие в него слова и получать осмыс­
ленные конструкции. В языке моделирования словарь и правила ориентированы на концептуальное и физическое представление системы. Словарь языка UML включает три вида строительных блоков: сущности, отношения, диаграммы.
Сущности — это абстракции, являющиеся основными элемента­
ми модели. Отношения связывают различные сущности. Диаграммы группируют представляющие интерес совокупности сущностей.
С помощью языка UML можно построить структурные модели и модели поведения.
Структуру сущностей или компонентов некоторой системы, включая их классы, интерфейсы, атрибуты и отношения, описы­
вают структурные модели.
Модели поведения описывают поведение или функциониро­
вание объектов системы, включая их методы, взаимодействие и сотрудничество между ними, а также процесс изменения состоя­
ний отдельных компонентов и системы в целом. В рамках языка
UML все представления о модели сложной системы фиксируются в виде специальных графических конструкций, получивших на­
звание диаграмм. В терминах языка UML определены следующие виды диаграмм:
— диаграмма вариантов использования (use case diagram) — для моделирования бизнес-процессов организации (требований к системе);
— диаграмма классов (class diagram) — для моделирования ста­
тической структуры классов системы и связей между ними;
— диаграммы поведения системы (behavior diagrams):
1) диаграмма состояний (statechart diagram) — для моделирова­
ния поведения объектов системы при переходе из одного состоя­
ния в другое;
114

2) диаграмма деятельности (activity diagram) — для моделиро­
вания поведения системы в рамках различных вариантов исполь­
зования или моделирования деятельности;
3) диаграммы взаимодействия (interaction diagrams) — для моде­
лирования процесса обмена сообщениями между объектами — диаграмма последовательности (sequence diagram), диаграмма кооперации (collaboration diagram);
— диаграммы реализации (implementation diagrams):
1) диаграмма компонентов (component diagram) — для модели­
рования иерархии компонентов (подсистем) системы;
2) диаграмма развертывания (deployment diagram) — для моде­
лирования физической архитектуры системы.
Создание диаграмм аналогично созданию проекта в строитель­
стве — можно обойтись и без него, если, например, строить сарай на дачном участке. Но выстроить большое здание гораздо сложнее.
Без использования проекта будет неопределенным конечный ре­
зультат. Информационная система, описанная UML-диаграммами, показывает разработчику результат, который необходимо достичь в процессе проектирования.
4.3.3. Диаграммы вариантов использования
Разработку спецификаций информационной системы начина­
ют с анализа требований к функциональности, указанных в тех­
ническом задании. В процессе этого анализа выявляют внешних пользователей разрабатываемого программного обеспечения ИС и перечень отдельных аспектов его поведения в процессе взаимо­
действия с конкретными пользователями. Аспекты поведения программного обеспечения были названы «вариантами исполь­
зования», или «прецедентами» (use cases).
Вариант использования представляет собой последовательность действий, выполняемых системой в ответ на событие, иниции­
руемое некоторым внешним объектом (действующим лицом), в качестве которого могут выступать не только люди, но и другие системы и устройства. Вариант использования описывает типич­
ное взаимодействие между пользователем и системой.
Каждый вариант использования связан с некоторой целью, имеющей самостоятельное значение. Например, для текстового редактора «Формирование оглавления» — это вариант использо­
вания, а «Связывание заголовков со специальными стилями» — операция, которую необходимо выполнить, чтобы стало возмож­
но автоматическое построение оглавления.
В зависимости от цели выполнения процедуры различают сле­
дующие варианты использования:
115

— основные (базовые) — обеспечивают требуемую функцио­
нальность разрабатываемого ПО;
— вспомогательные — обеспечивают выполнение необходимых настроек системы и ее обслуживание (например, архивирование информации и т. п.);
— дополнительные — обеспечивают дополнительные удобства для пользователя (как правило, реализуются в том случае, если не требуют серьезных затрат каких-либо ресурсов ни при разработке, ни при эксплуатации).
Следует отметить, что одним из требований языка UML яв­
ляется самодостаточность диаграмм для представления инфор­
мации о моделях проектируемых систем. Однако изобразитель­
ных средств языка UML явно не хватает для того, чтобы учесть на диаграммах вариантов использования особенности функцио­
нального поведения сложной системы. С этой целью рекомен­
дуется дополнять этот тип диаграмм текстовыми сценариями, которые уточняют или детализируют последовательность дей­
ствий, совершаемых системой при выполнении ее вариантов использования.
В контексте языка UML сценарий используется для дополни­
тельной иллюстрации взаимодействия актеров и вариантов ис­
пользования. Предлагаются различные способы представления или написания подобных сценариев. Один из таких шаблонов рассматривается ниже и может быть рекомендован для примене­
ния на начальных этапах концептуального моделирования. В за­
висимости от уровня абстракции вариант использования может описываться кратко или более подробно. Краткая форма описания содержит название варианта использования, его цель, действу­
ющих лиц, тип варианта использования (основная, второстепен­
ная или дополнительная) и его краткое описание. Ниже приво­
дится шаблон для написания сценария отдельного варианта ис­
пользования (табл. 4.2).
Т а б л и ц а 4.2
Имя варианта
использования
Типичный ход
событий,
приводящий к
успешному
выполнению
варианта
использования
Исключение 1
Примечание 1
Актеры
Исключение 2
Примечание 2
Цель
Исключение 3
Примечание 3
Краткое описание
Тип
Ссылки на другие
варианты исполь­
зования
Исключение п
Примечание п
116

л
о
*
а
б
в
Рис. 4.15. Основные условные обозначения диаграмм вариантов
использования:
а —
действующее лицо;
б —
вариант использования;
в —
связь
При написании сценариев вариантов использования важно понимать, что текст сценария должен дополнять или уточнять диаграмму вариантов использования, но не заменять ее полно­
стью. В противном случае будут потеряны достоинства визуаль­
ного представления моделей.
Диаграммы вариантов использования позволяют наглядно представить ожидаемое поведение системы. Основными поня­
тиями диаграмм вариантов использования являются: действующее лицо, вариант использования и связь.
Условные обозначения, применяемые при изображении диа­
грамм вариантов использования, приведены на рис. 4.15.
Действующее лицо (актер) — внешняя по отношению к раз­
рабатываемой системе сущность, которая взаимодействует с ней в целях получения или предоставления какой-либо информации.
Как уже упоминалось выше, действующими лицами могут быть пользователи, другое ПО или какие-либо технические средства, взаимодействующее с системой.
Вариант использования в сценарии — некоторая очевидная для действующего лица процедура, решающая его конкретную задачу. Все варианты использования так или иначе связаны с требованиями к функциональности разрабатываемой системы и могут сильно различаться по объему выполняемой работы.
Связь — взаимодействие действующих лиц и соответствующих вариантов использования.
Варианты использования также могут быть связаны между со­
бой. При этом фиксируют связи использования и расширения.
Использование (uses/include) подразумевает, что существует некоторый фрагмент поведения разрабатываемого ПО, который повторяется в нескольких вариантах использования. Этот фраг­
мент оформляют как отдельный вариант использования и указы­
вают связь с ним типа «использование».
Расширение (extends) применяют, если имеются два подобных варианта использования, различающиеся наличием в одном из них некоторых дополнительных действий. В этом случае дополнитель­
117
I