Материал: 4970

56

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

В качестве стандартного унифицированного языка моделирования систем, в том числе и программных, в 1997 г. консорциумом Object Managing Group (OMG) был принят язык UML (Unified Modeling Language). Первоначальная вер-

сия языка UML была опубликована в июне 1996 г. в результате совместных усилий авторов: Грейди Буч (компания Rational Software Corporation), Айвар Джекобсон (Objectory) и Джеймс Рамбо (General Electric). При создании языка UML преследовались следующие цели [1]:

1)моделировать системы целиком, от концепции до исполняемого артефакта

спомощью объектно-ориентированных методов;

2)решить проблему масштабируемости, которая присуща сложным системам, предназначенным для выполнения задач в распределённых системах;

3)создать такой язык моделирования, который может использоваться не только людьми, но и компьютерами.

Язык UML представляет собой универсальное средство для анализа и моделирования объектов, позволяющее документировать процесс проектирования объектно-ориентированных систем. На UML можно содержательно описывать сущности информационной системы и соответствующие им классы, объекты и компоненты программных систем. Язык UML, с одной стороны, позволяет документировать весь процесс анализа и разработки, с другой стороны, упрощает написание программного кода, так как вся нотация (способ изложения и описания моделей) в UML ведётся на языке, приближённом к объектноориентированному языку C++.

Визуализация, специфицирование, конструирование и документирование объектно-ориентированных систем – это и есть назначение языка UML [1]. В настоящем пособии будет использована нотация языка UML версии 1.3.

В качестве CASE-средств визуального проектирования, в которых применяется нотация UML, можно упомянуть такие, как AllFusion Component Modeler

(ранее: Paradigm Plus); Oracle Designer (входит в Oracle9i Developer Suite); IBM Rational Software Modeler и IBM Rational Software Architect.

AllFusion Component Modeler – программный комплекс для автоматизированного проектирования, визуализации, генерации исходного кода и поддержки информационных систем.

57

Oracle Designer – программный комплекс для автоматизированного проектирования программных систем и баз данных, реализующее технологию CASE и собственную методологию Oracle "CDM". Позволяет команде разработчиков полностью выполнить проект, начиная с анализа бизнес-процессов через моделирование до генерации кода и получения прототипа, а в дальнейшем и окончательного продукта.

IBM Rational Software Modeler − программный комплекс для автоматизированного визуального моделирования и проектирования, который позволяет пользователям документировать эти различные представления системы и доводить их до сведения заинтересованных лиц.

IBM Rational Software Architect − средство проектирования архитектурных и компонентных решений при разработке программного обеспечения.

2.3.2.Основные группы элементов языка UML

Косновным группам языка UML относятся:

1)описание составляющих единиц – словарь языка;

2)совокупность графических объектов в виде диаграмм;

3)описание дополнительных понятий, позволяющих расширить смысл основных понятий языка.

Словарь языка UML включает три вида строительных блоков:

1)сущности – абстракции, являющиеся основными элементами модели программной системы;

2)отношения – средства отображения связей между сущностями;

3)диаграммы – группируют представляющие интерес на конкретной стадии проектирования совокупности сущностей и отношений для описания статического и динамического состояний проектируемой системы.

Виды сущностей языка UML:

1)структурные сущности;

2)поведенческие сущности;

3)аннотационные сущности.

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

58

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

Вязыке UML применяются семь разновидностей структурных сущностей − класс; интерфейс; кооперация; прецедент (вариант использования); активные классы; компоненты и узлы. Исходя из целей настоящего пособия, мы ограничимся рассмотрением пяти видов структурных сущностей − класс; интерфейс; прецедент (вариант использования); компоненты и узлы, так как сущность кооперация является обобщающей для группы прецедентов, а сущность активный класс является частным случаем для классов.

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

Интерфейсом называется возможная реализация одной из форм поведения элементов системы (классов), для которых возможна полиморфная реакция. Сущность «интерфейс» отражает виртуальные компоненты классов (см. п. 2.2.6 настоящего пособия).

Вкачестве примера рассмотрим класс «Окно», определяющий способ и форму некоторого малого окна, появляющегося на фоне главного окна программы.

Вэтом случае интерфейсом класса «Окно» будут являться координаты левого верхнего и правого нижнего углов окна, цвет фона окна, рамка и цвет рамки окна. Прецедентом будет являться действие «перерисовать окно». Активным классом, который вызывает изменения состояния окна при перерисовке и саму перерисовку, будет являться класс «главное окно программы».

Компоненты и узлы

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

Поведенческие сущности – предназначены для описания взаимодействия и алгоритма поведения объектов. Под взаимодействием объектов следует понимать обмен сообщениями между объектами. Алгоритм поведения – описание последовательности смены состояний объекта (иначе «автомат»).

59

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

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

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

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

Типы диаграмм в UML:

1)диаграмма вариантов использования ( use case diagram );

2)диаграмма классов (class diagram);

3)диаграмма объектов (object diagram);

4)диаграмма последовательности (sequence diagram);

5)диаграмма кооперации (collaboration diagram) ;

6)диаграмма состояний (statechart diagram);

7)диаграмма деятельности (activity diagram);

8)диаграмма компонентов (component diagram);

9)диаграмма развёртывания (deployment diagram).

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

60

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

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

2.3.3. Диаграммы вариантов использования

Варианты использования и их диаграммы применяются для визуализации функциональных возможностей системы (системы в целом, подсистемы или класса). С помощью диаграмм вариантов использования заказчики и менеджеры проекта получают общее представление о системе и смогут принять решение по данной стадии проекта (выяснении функциональных требований и соответствии модели данным требованиям). Диаграмма вариантов использования описывает функционирование системы с точки зрения внешнего наблюдателя. При этом описывается, что система делает, но без детализации того, как это происходит. Каждая такая диаграмма соответствует определённому, безальтернативному перечню действий в анализируемой предметной области при условии достижения конкретного результата. Диаграмма строится на основании словесного описания последовательности выполняемых действий сценария. Сценарий – это один из примеров того, что происходит в системе. Пример сценария приведён в Приложении А. Описание сценария должно соответствовать схеме: «роль–действие– результат». Сценарий является изложением последовательности действий, выполняемых исполнителями, описанием предварительных состояний исполнителей и условий выполнения таких действий, а также описанием результатов действий и состояний исполнителей после свершившихся действий. Такое изложение должно подчиняться правилу логической целостности и неразрывности происходящих событий. При этом, учитывая особенности итерационного, последовательно и постепенно уточняющего новые факты и операции, способа построения модели предметной области, совершенно нет никакой необходимости пытаться за один раз и в одном изложении описать всё происходящее. Самый пер-