Архив / Лекции ТССА / лекции ТСиСА / Лекции МЭСИ

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

По данным исследовательской компании International Data Corporation, среди инструментальных средств, которые можно отнести к этой категории, лидирующее положение занимает пакет

Rational Rose. Прибыль от продажи Rational Rose за 1998 г. пре-

вышает суммарную прибыль от продажи продуктов четырех ближайших конкурентов: STERLING, SELECT, Platinum, AONIX www.rational. com/products/rose/prodinfo/2000ds.jtmpl.

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

Система ARIS как крупное интегрированное средство моделирования имеет уникальные возможности для моделирования и анализа систем. Моделирование в ARIS может выполняться как “сверху вниз”, так и “снизу вверх”. Для конкретных разработок количество используемых типов моделей и методик может быть ограничено с помощью специальных фильтров. Система позволяет контролировать процесс моделирования и выполнять расширенный анализ системы: определение целей и критических факторов, оценку рисков и конкурентов и др. Система ARIS предоставляет аналитикам возможность интегрированного “управления всеми ресурсами”, необходимыми для использования на всех уровнях анализа при разработке ИСУП любой сложности.

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

Моделирование на UML

UML	(Unified Modeling Language) с 1997 года является стан-
дартом	OMG в области визуального объектно-ориентированного моде-

лирования и широко используется на практике, будучи реализован в рамках многих CASE-средств.

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

Прямые родители UML (языки графического описания):

•Booch – автор Грэйди Буч (Grady Booch). Очень выразителен, что особенно важно на этапах проектирования и конструирования модели.

•OOSE (Object-Oriented Software Engineering) – автор Айвар Джекобсон (Ivat Jacobson). Великолепно приспособлен для анализа и формулирования требований, а также высокоуровневого проектирования.

• OMT (Object-Modeling Technique) – автор Джэймс Рамбо

(James Rumbaugh). OMT-2 особенно полезен для анализа и разработки информационных систем, ориентированных на обработку больших объемов данных.

Краткое описание структуры UML

I Сущности

UML – это язык для описания сущностей:

•структурных,

•поведенческих,

•группирующих и

•аннотационных .

Эти 4 основных вида сущностей позволяют моделировать огромное количество систем. Перечислим их:

•Структурные сущности – статические части модели, соответствующие концептуальным или физическим элементам системы. Су-

ществительные. Основных - 7:

oКласс (Class) – описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой. Реализует один или несколько интерфейсов. Может принимать участие в нескольких кооперациях. Символ – прямоугольник с именем, атрибутами, методами. Использование

– в диаграммах классов.

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

oКооперация (Collaboration) – совокупность ролей и пр., которые, работая совместно, производят некоторый кооперативный эффект, не сводящийся к простой сумме слагаемых (определяет взаимодействие). Имеет как структурный, так и поведенческий аспект. Являются реализацией образцов поведения, формирующих систему. Символ – пунктирный овал. Использование – в диаграммах классов.

oПрецедент (Use case) – описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для определенного актера (Actor). Применяется для структурирования поведенческих сущностей модели. Реализуются посредством кооперации. Символ – овал. Использование – в диаграммах прецедентов.

oАктивный класс (Active class) – разновидность класса.

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

o Компонент (Component) – разновидность класса. Является физически заменяемой частью системы, которая соответствует некоторому набору интерфейсов и обеспечивает его реализацию. Как правило, представляет физическую упаковку логических элементов (классов, интерфейсов, коопераций). Символ – прямоугольник с вкладками.

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

•Поведенческие сущности – динамические составляющие модели. Для их структурирования используются прецеденты. Семантиче-

ски связаны с классами, кооперациями и объектами. Глаголы.

Основных типов - 2:

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

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

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

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

•Аннотационные сущности – пояснительные части модели. Символ

– прямоугольник с загнутым краем. Имеется 1 базовая аннотационная сущность:

o Примечание (Note) – комментарии для дополнительного описания, разъяснения или замечания к любому элементу модели. Вариации примечаний:

Требования.

II Отношения

Отношения – связующие строительные блоки моделей.

В языке UML определены 4 типы отношений (подробно см. в следующем разделе):

•Зависимость (Dependency) – семантическое отношение между двумя сущностями, при котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой. Символ – пунктирная линия (часто со стрелкой), которая может содержать метку.

•Ассоциация (Association) – структурное отношение, описывающее совокупность связей; связь – это соединение между объектами. Символ – прямая линия (иногда завершающаяся стрелкой или содержащей метку), рядом с которой могут присутствовать дополнительные обозначения (например, кратность и имена ролей).

•Обобщение (Generalization) – отношение «специализация/обобщение», при котором объект специализированного элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (предка). Символ – линия с незакрашенной стрелкой, указывающей на родителя.

•Реализация (Realization) - семантическое отношение между классификаторами, при котором один классификатор определяет «контракт», а другой гарантирует его выполнение. Символ – пунктирная линия с незакрашенной стрелкой.

IIIДиаграммы

•Диаграмма в UML – графическое представление набора элементов, изображаемое часто в виде графа с вершинами-сущностями и ребрами-отношениями. Служат для визуализации системы с

разных точек зрения.

•Диаграмма – ОДНА из проекций системы.

Вязыке UML выделяют 9 типов диаграмм. Рассмотрим наиболее употребительные

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

Диаграммы классов — ключевой тип диаграмм Rational Rose.

•

•Диаграммы прецедентов. Элементы: прецеденты, актеры и отноше-

ния. Статический вид системы с точки зрения прецедентов использования [тавтология, как проще?]. Особенно важны при организации и моделировании поведения системы.

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

•

•Диаграммы действий.

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

•

•Другие диаграммы (оставим на предметы, связанные с проектированием)

Применение UML в жизненном цикле проектов

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

Стадия анализа требований Цели стадии анализа требований состоят в том, чтобы

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

•определить область деятельности системы и

• определить требования пользователя.

На данной стадии система рассматривается с точки зрения конечного пользователя как «черный ящик», составляется представление, что система будет делать, не рассматривая, как она это будет делать.

На данной стадии с помощью UML создается модель прецедентов системы. Она позволяет:

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

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

план разработки системы.

Стадия системного проектирования.

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

Стадия позволяет выделить

•вычислительные ресурсы, устройства, использующиеся ими, и соединения между ними,

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

приложений.

Посредством диаграммы компонент производится разделение программной системы на исполняемые компоненты. На основании построенных диаграмм производится выбор технологии и средств разработки.

Стадия детального проектирования.

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

ны способы решения задач, выполняемых системой. Эта стадия полностью описывает

•функции,

•классы системы

•графический интерфейс с пользователем. На данной стадии разрабатываются

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

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

активности) - разрабатывается модель поведения объектов в системе.

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

устанавливаются зависимости между классами, производится разделение системы на модули и выделение клас-

сов, реализуемых в данных модулях.

При разработке систем, использующих реляционные базы данных,

на основании диаграммы классов создается физическая модель базы данных для хранения данных объектов постоянных классов. Все ре-

шения, связанные с построением объектно-ориентированной модели программной системы здесь должны быть завершены.

Стадия реализации

В течение стадии реализации, модели, созданные на стадиях проектирования системы, переводятся в исходный код 3GL или 4GL языков программирования и разрабатывается база данных системы. Средства автоматической кодогенерации позволяют перевести модели на языке UML в исходный код выбранного языка программирования. CASE-средства, поддерживающие UML (Rational Rose, Paradigm Plus, Select Enterprise, Microsoft Visual Modeler for Visual Basic и

др.), дают возможность работать со множеством языков программирования, таких как C++, Java, Delphi, и т.д., а также осуществлять генерацию базы данных на большинстве из существующих SQLсерверов. Модели, разработанные в UML, позволяют значительно упростить процесс кодирования и направить усилия программистов непосредственно на реализацию системы.

Стадия тестирования

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

Стадия внедрения.

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

Тезисы внедрения и сопровождения:

1)реальные системы часто меняются с течением времени

2)к программной системе появляются новые требования

3)система требует модификации.

4)Объектный подход позволяет легко включать в систему новые

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

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

Поэтому, в отличие от структурных методологий, ориентированных на функциональность системы, объектные технологии, ориенти-

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

UML поддерживает все стадии жизненного цикла проекта, его применения достаточно для полной поддержки разработки приложе-

ния. Особенность UML (в отличие от диаграмм IDEF0) в том, что он

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