Задания, лекции / Червенчук

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

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

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

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

‒ для моделирования баз данных больше подходят инструменты

Erwin, Power Designer и Rational Rose;

‒ для моделирования компонентов разрабатываемых приложений –

Oracle Designer, Power Designer и Rational Rose;

‒ для моделирования бизнес-процессов – BPwin, ARIS иRational Rose. Таким образом, средство Rational Rose и, соответственно, язык UML, являясь универсальным средством моделирования, позволяет решить все типовые задачи моделирования информационных систем. Данное издание будет посвящено возможностям языка UML для разработки информаци-

онных систем.

11

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

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

Использование UML позволяет решить все три названные проблемы: понятная всем модель облегчает общение.

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

UML – язык специфицирования

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

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

13

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

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

UML – язык конструирования

UML непосредственно не является языком программирования, но на основе моделей, созданных с его помощью, могут быть достаточно легко написаны программные модули на любом объектно ориентированном языке программирования. UML-модель можно отобразить на такие языки, как Java, C++, Visual Basic, и даже на таблицы реляционной базы данных или устойчивые объекты объектно ориентированной базы данных. Те элементы, которые предпочтительно передавать графически, представляются визуальными средствами UML, те же, которые лучше представить в текстовом виде, выражаются с помощью языка программирования.

Такое отображение UML-модели на язык программирования позволяет осуществлять прямое проектирование: генерацию исходного кода из модели UML в какой-то конкретный язык программирования. Можно использовать и обратное преобразование: построить модель по уже имеющемуся модулю исходного кода. Обратное проектирование предполагает как непосредственное участие человека «преобразование вручную», так и использование инструментальных средств. Совместное использование прямой разработки и обратного проектирования позволяет работать как в графическом, так и в текстовом представлении, если инструментальные программы обеспечивают согласованность между обоими представлениями. Подобные инструментальные средства могут быть встроены в UML-системы, а могут выпускаться третьими фирмами. Например, фирма Ensemble Tools выпускает инструментальную программу Rose Delphi Link, позволяющую автоматизировать переход как прямой, так и обратный между брэндовой UML-системой Rational Rose и популярной средой разработки программных средств Delphi.

Кроме того, модели UML можно непосредственно верифицировать и исполнять.

14

UML – язык документирования

При разработке программных средств, кроме непосредственного написания исходного кода программ, разрабатываются:

‒общие требования к системе;

‒архитектура системы;

‒проект;

‒проектные планы;

‒тесты;

‒прототипы;

‒версии и др.

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

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

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

‒информационные системы масштаба предприятия;

‒распределенные Web-системы;

‒телекоммуникации;

‒транспорт;

‒банковские и финансовые услуги;

‒оборонная промышленность, авиация и космонавтика;

‒розничная торговля;

‒наука;

‒медицинская электроника.

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

15

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

1.1.СТРОИТЕЛЬНЫЕ БЛОКИ UML

ВUML используется три вида строительных блоков:

– сущности;

– отношения;

– диаграммы.

Сущности – это абстракции, являющиеся базовыми элементами моде-

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

В UML используется четыре типа сущностей: структурные; поведенческие; группирующие; аннотационные.

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

Класс (Class) – это описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой.

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

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

16

Интерфейс (Interface) – это совокупность операций, которые определяют сервис (набор услуг), предоставляемый классом или компонентом. Таким образом, интерфейс описывает видимое извне поведение элемента. Интерфейс специфицирует, прежде всего, поведение класса или компонента; он определяет только прототипы операций (сигнатуры), не их реализацию. Собственно реализа-

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

Кооперация (Collaboration) определяет взаимо-

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

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

Прецедент, или вариант использования (Use case) – это описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-то определенного актера (Actor). Прецедент применяется для описания поведения системы. Прецеденты, также как и интерфей-

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

Активным классом (Active class) называется класс, объекты которого вовлечены в один или несколько процессов, или нитей (Threads), и поэтому могут инициировать управляющее воздействие. Активный класс во многом подобен обычному классу, за исключением того, что его объекты

17

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

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

Компонент (Component) – это физическая заменяемая часть системы, которая соответствует некоторому набору интерфейсов и обеспечи-

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

можно встретить различные виды устанавливаемых компонентов, такие как СОМ+ или Java Beans, а также компоненты, возникающие в процессе разработки, например файлы проекта, исходного кода на языке программирования. Таким образом, компонент представляет собой продукт трансляции (физическую упаковку) абстрактных элементов, таких как классы, интерфейсы и кооперации. Графически компонент изображается в виде прямоугольника с вкладками, содержащего обычно только имя, как показано на рис. 1.6.

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

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

18

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

Рассмотренные структурные элементы, естественно, не описывают все возможные информационные артефакты, однако UML, являясь языком открытым, предоставляет возможности расширения, позволяющие определять новые специфические элементы на базе имеющихся с помощью стереотипов. На рис. 1.8 приводятся стереотипы класса: актер (рис. 1.8, а), сигнал (рис. 1.8, б), таблица реляционной БД (рис. 1.8, в).

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

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

Взаимодействие (Interaction) – это поведение, суть

которого заключается в обмене сообщениями (Messages) между объектами в рамках конкретного контекста

для достижения определенной цели. С помощью взаимодействия можно описать как отдельную операцию, так и поведение со-

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

19

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

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

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

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

Группирующие сущности являются организующими частями модели UML. Это блоки, на которые можно разложить модель. Есть только одна базовая группирующая сущность, а именно пакет.

Пакеты (Packages) представляют собой универ- сальный механизм организации элементов в группы.

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

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

Пакеты – это основные группирующие сущности, с помощью которых можно организовать модель UML. Существуют также вариации пакетов, например каркасы (Frameworks), модели и подсистемы.

20