Файл: Анализ и оценка средств реализации объектно-ориентированных методов анализа и проектирования экономической информационной системы..pdf

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

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

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

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

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

2.2.Пакеты в языке UML.

Пакет — механизм организации компонентов модели в упорядоченное множество на основе принципа декомпозиции модели сложной системы и предоставляющий возможность вложения пакетов друг в друга [15].

Пакет — это ведущий метод организации модели в Unified Method Language. Пакет обладает всем множеством включенных в него компонентов. Про соответствующие компоненты пакета принято говорить о их принадлежности к данному пакету. При этом отдельный компонент может иметь принадлежность только к одному пакету. Допускается вложенность одних пакетов в другие.

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

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

Рисунок 2. Графическое изображение пакетов в языке UML

Имя пакета может предваряться строкой текста, содержащей ключевое слово, ранее определенное в UML, и имеющее название стереотипа.

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

К типовым отношениям между пакетами относится отношение вложенности. Данное отношение изображается с помощью помещения одного прямоугольника внутрь другого, обозначающего более общий пакет (Рисунок 3).

Рисунок 3. Графическое изображение вложенности пакетов друг в друга

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

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

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

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

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

Рисунок 5. Изображение модели системы в виде пакетов моделей анализа и проектирования

Подсистема — это группировка компонентов модели, которые определяют простейшее поведение физической системы. В процессе группировки компоненты подразделяются на спецификацию поведения и его реализацию. Графическим изображением подсистемы также является прямоугольник, но в отличии от пакета он разделен на три секции (рисунок 6). В верхнем, меньшем, прямоугольнике отображается символ, указывающий на подсистему. Уникальное имя подсистемы, вместе с необязательным стереотипом, вписывается внутрь большого прямоугольника. При наличии текста внутри большого прямоугольника имя подсистемы может быть вписано рядом со специальным символом, указывающим на подсистему. [15]

Рисунок 6. Графическое изображение подсистемы в языке UML

2.3.Канонические диаграммы языка UML.

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

Диаграмма — изображение комплекса компонентов модели, имеющий вид связного графа, вершины и ребра которого имеют строго определенную семантику.

Нотация канонических диаграмм — основополагающий метод создания моделей с применением языка UML.

В UML представлены следующие разновидности канонических диаграмм:

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

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

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

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

Диаграмм классов — это логическая модель, дающая представления о статических аспектах структуры системы.

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

Основная функция диаграмм состояний и диаграмм деятельности — моделирование реакции системы.

Диаграммы компонентов и развертывания используются для изображения физических элементов системы. На этом основании их относят к физической модели сложной системы. [2]

Обобщенная модель сложной системы определенная с помощью нотаций UML может быть представлена в виде комплекса данных диаграмм (Рисунок 7).

Рисунок 7. Интегрированная модель сложной системы в нотации UML

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

Стереотип — новый тип компонента модели, расширяющий семантику метамодели. Для стереотипов обязательно создаваться на основе существующих классов, имеющих описание в метамодели UML.

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

Помеченное значение — явное представление свойства в качестве пары «имя — значение». Внутри помеченного значения имя определяется как «тег».

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

Ограничение — это логическое условие, вводящие ограничение для семантики определенного элемента модели.

Спецификации ограничений вводятся, как правило, самим разработчиком. На диаграммах ограничения обозначаются в виде строки текста, ограниченного фигурными скобками. Формальная запись ограничений проводится с помощью специального языка объектных ограничений, который входит в состав UML. [15]

2.4.CASE-средства объектно-ориентированного анализа и проектирования.

Для реализации процесса проектирования информационных систем с использованием объектно-ориентированной парадигмы применяются CASE-средства (Computer Aided Software Engneering). В частности, к подобным средствам реализации систем с применением языка UML относятся: IBM Rational Rose, Borland Together, Sparx Systems Enterprise Architect. [16]

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

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

• Rational Rose Modeler — данная версия предоставляет возможность проведения анализа бизнес-процессов и проектирования информационной системы. Отсутствует возможность генерации кода.
• Rational Rose Professional — данная версия предоставляет возможность как прямого, так и обратного проектирования на выбранном языке программирования. Поставляется в определенной заказчиком конфигурации с поддержкой определенного языка программирования. В результате использования данного инструментария разработчик получает каркасный код на выбранном языке программирования.
• Rational Rose RealTime — данная версия позволяет получить исполняемый код в реальном масштабе времени; предоставляет возможность прямого и обратного проектирования на C и C++. Предоставляет разработчикам скомпилированный исполняемый файл.
• Rational Rose Enterprise — данная версия предоставляет функционал всех иных редакций.

В зависимости от конфигурации поставки Rational Rose может содержать различное количество диаграмм.

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

• Прямое и обратное проектирование с применением таких языков программирования как ADA, Java, C, C++, Basic
• поддержка следующих технологий: COM, DDL, XML
• Генерация схем баз данных Oracle и SQL

Данное программное обеспечение обладает открытым API, дающим возможность самостоятельной разработки модулей для иных языков программирования. Кроме того, на рынке предоставлено значительное число готовых модулей с поддержкой языков программирования и RAD-систем, таких как Delphi, Jbuilder, SmallTalk и т. д.