Проектирование информационных систем. Раздел 5. Индустриальное проектирование информационных систем. Объектно-ориентированная Case-технология проектир

1.3. Унифицированный язык моделирования

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

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

Внастоящее время различают три поколения языков визуального моделирования. И если первое поколение образовывали 10 языков, то с 1989 по 1994 год численность второго поколения уже превысила 50 языков. Среди наиболее популярных языков второго поколения выделяют язык Бу-

ча (G. Booch), язык Рамбо (J. Rumbaugh), язык Джекобсона (I. Jacobson),

язык Коада-Йордана (Coad-Yourdon), язык Шлеера-Меллора (Shlaer-Mellor)

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

Так, среди преимуществ языка визуального моделирования, разработанного Бучем, отмечаются предоставляемые разработчику высокие выразительные возможности, которые особенно важны на этапах проектирования и конструирования модели. Язык ОМТ (Object Modeling Technique), автором которого является Джеймс Рамбо, предназначался для анализа и разработки информационных систем, ориентированных на обработку больших объемов данных.

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

хгодов, когда Грейди Буч (компания Rational Software), Айвар Джекобсон (компания Objectory) и Джеймс Рамбо (компания General Electric) предприняли попытку объединить свои методы, уже получившие мировое признание как наиболее перспективные в данной области. Разработчики поставили своей целью создать новый унифицированный язык моделирования.

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

Unified Modeling Language (UML), создававшийся в 1994–1997 годах.

11

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

ПрисозданииUML разработчикиставилиследующиезадачи[2, с. 119]:

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

•предусмотреть механизмы расширяемости и специализации для развития базовых концепций;

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

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

•стимулировать рост рынка объектно-ориентированных инструментальных средств;

•интегрировать лучший практический опыт.

Вянваре 1997 года выходит версия 1. 0 языка. UML 1. 0 оказался хорошо определенным, выразительным, мощным языком, применимым для решения большого количества разнообразных задач. В январе 1997 года он был представлен Группе по управлению объектами (Object Management Group, QMG) на конкурс по созданию стандартного языка моделирования.

Виюне 1998 года вышла версия UML 1. 2, а осенью 1998 – UML 1. 3. В настоящее время создана версия UML 2. 0.

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

1)диаграмма прецедентов использования (use-case diagram), которая отражает функциональность ИС в виде совокупности выполняющихся последовательностей транзакций;

2)диаграмма классов объектов (class diagram), которая отображает структуру совокупности взаимосвязанных классов объектов аналогично диаграмме «сущность – связь» функционально-ориентированного подхода;

3)диаграммы состояний (statechart diagram), каждая изкоторых отображаетдинамикусостоянийобъектоводногоклассаисвязанныхснимисобытий;

12

4)диаграммы взаимодействия объектов (interaction diagram), каждая из которых отображает динамическое взаимодействие объектов в рамках одного прецедента использования;

5)диаграммы деятельности (activity diagram), которые отображают потоки работ во взаимосвязанных прецедентах использования;

6)диаграммы пакетов (package diagram), которые отображают распределение объектов по функциональным или обеспечивающим системам;

7)диаграмма компонентов (component diagram), которая отображает физические модули программного кода;

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

13

Контрольные вопросы

1.Какие ключевые принципы лежат в основе объектноориентированного подхода?

2.Дайте общую характеристику класса.

3.Чем отличается объект от класса?

4.В чем суть принципа многомодельности?

5.Поясните принцип абстрагирования.

6.Как можно представить модель сложной системы с точки зрения

UML?

7.В чем суть принципа иерархической организации?

8.Поясните понятие полиморфизма.

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

10.Выделите достоинства и недостатки объектно-ориентированного подхода к проектированию информационных систем.

11.Почему функциональный анализ может представлять собой основу для объектно-ориентированного проектирования?

12.Приведите примеры взаимосвязи между функциональноориентированным и объектно-ориентированным подходами к проектированию информационных систем.

13.Какая необходимость привела к созданию языка визуального моделирования третьего поколения?

14.Поясните назначение UML.

15.Какие диаграммы включают в себя объектно-ориентированные модели в соответствии с нотациями UML?

14

Глава 2. СТАТИЧЕСКИЕ МОДЕЛИ ОБЪЕКТНООРИЕНТИРОВАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ

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

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

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

Диаграмма прецедентов использования (use-case diagram) относит-

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

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

15

Прецеденты использования

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

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

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

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

Рисунок 2 – Эквивалентные прецеденты использования

В литературе прецеденты использования также называют вариантами использования.

Актеры

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

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

16

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

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

Выделяют три группы актеров (2):

•пользователи системы;

•другие системы, взаимодействующие с данной системой;

•время.

Время становится актером, если от него зависит запуск каких-либо событий в системе.

В литературе можно встретить перевод термина «actor» как «действующее лицо» или «актор».

Абстрактные актеры и прецеденты

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

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

Рисунок 3 – Пример абстрактного прецедента

17

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

Рисунок 4 – Пример абстрактного актера

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

Имена абстрактных актеров и прецедентов пишутся курсивом.

На практике абстрактные актеры приводятся на диаграмме прецедентов нечасто. Еще реже применяются абстрактные прецеденты.

Отношения в диаграммах прецедентов использования

Язык UML определяет несколько типов отношений для описания взаимодействия различных элементов диаграммы. Основными типами используемых отношений диаграммы прецедентов являются следующие:

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

•отношение расширения (extend relationship);

•отношение включения (include relationship);

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

Отношение ассоциации – одно из фундаментальных отношений

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

Его формальное определение выглядит следующим образом.

18

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

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

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

Рисунок 5 – Направленные и ненаправленные ассоциации

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

19

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

Рисунок 6 – Кратность отношения ассоциации

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

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

Его формальное определение выглядит следующим образом.

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

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

Рисунок 7 – Пример использования отношения расширения

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

20