Учебное_пособие_ТИПиС и Глоссарий. Учебное пособие для студентов очной и заочной форм обучения представляет собой подборку материала по курсу Теория информационных систем и процессов

• Название: Учебное пособие для студентов очной и заочной форм обучения представляет собой подборку материала по курсу Теория информационных систем и процессов
• Дата: 29.12.2022
• Размер: 5.1 Mb.
• Имя файла: Учебное_пособие_ТИПиС и Глоссарий.doc
• Тип: Учебное пособие; #869193
• страница: 13 из 44

3.2. Объектная методика моделирования информационных систем и процессов

3.2.1. UML – язык объектного моделирования

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

В настоящее время благодаря усилиям концерна Object Management Group (OMG) создан единый стандарт языка объектного моделирования – Unified Modelling Language (UML).

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

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

Рассмотрим основные элементы нормативной системы языка UML.

Сущности

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

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

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

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

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

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



Рис. 3.31. - Графическое изображение класса и экземпляра.

Признак видимости может принимать одно из трех значений:

• 
  + – открытый (public) – может использовать любой класс/объект;
  
• 
  # – защищенный (protected) – может использовать потомок класса;
  
• 
  - – закрытый (private) – может использовать только данный класс.
  

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

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

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

Рис. 3.32. - Графическое изображение интерфейса, кооперации и прецедента.


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

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

Рис. 3.33. - Графическое изображение компонента и узла.


Поведенческие сущности (Behavioral things) представляют собой символы динамических составляющих объектной модели.

Взаимодействие (Interaction) – обмен сообщениями между объектами для достижения определенной цели (рис. 3.34).

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

Активность (Activity) – алгоритм поведения, определяющий последовательность процессов, осуществляемых объектом или происходящих с объектом на протяжении его жизненного цикла (рис. 3.34).


Рис. 3.34. - Графическое изображение сообщения, состояния и активности.



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

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

Рис. 3.35. - Графическое изображение пакета.


Аннотационные сущности (Summary things) представляют собой пояснительные символы объектной модели.

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

Рис. 3.36. - Графическое изображение примечания.


Отношения

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

Обобщение(Generalization) – отношение (потомок-родитель), при котором специализированный элемент (потомок) может быть подставлен вместо обобщенного элемента (родителя) (рис. 3.37). Потомок наследует структуру и поведение своего родителя.

Ассоциация(Association) – отношение связи (соединения) между объектами (рис. 3.37). На графическом изображении ассоциации могут присутствовать дополнительные обозначения кратности, ролей или меток.

Агрегирование – разновидность ассоциации, т.е. ассоциация между целым и его частями (рис. 3.37).

Композиция - такое отношение агрегирования, при котором часть является неотъемлемой составляющей целого (рис. 3.37).


Рис. 4.7. - Графическое изображение обобщения, ассоциации, агрегирования и композиции.

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

Реализация(Realization) – отношение между элементами, при котором один элемент определяет «контракт», а другой гарантирует его выполнение (см. рис. 3.38). Используется между интерфейсами и реализующими их классами или компонентами, а также между прецедентами и реализующими их кооперациями.

Рис. 3.38. - Графическое изображение зависимости и реализации.


Диаграммы

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

Диаграмма вариантов использования/прецедентов (Use case diagram) – диаграмма поведения, показывающая функции моделируемой системы и ее связи с другими системами, т.е., в случае разработки программного обеспечения, требования пользователей. Диаграмма состоит из множества прецедентов, классов (акторов: пользователей или любых других внешних систем) и отношений между ними (рис. 3.39).

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

Рис. 3.39. - Диаграмма вариантов использования.


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

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

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

Диаграмма классов(Class diagram) – структурная диаграмма, показывающая структуру классов предметной области. Диаграмма состоит из классов, интерфейсов, коопераций и отношений между ними (рис. 3.40). Абстрактные классы, от которых не производятся экземпляры, помечаются курсивом.



Рис. 3.40. - Диаграмма классов.

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

Диаграмма объектов(Object diagram) – структурная диаграмма, показывающая объектную модель системы, состоящую из множества экземпляров классов (объектов) и отношений между ними.

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

(Collaboration diagram), подчеркивающей структурную организацию объектов, посылающих и принимающих сообщения (рис. 3.42).

Рис. 3.41. - Диаграмма последовательности.




Рис. 3.42. - Диаграмма кооперации.


Сообщения: 1 – открыть сейф; 2 – деньги в первый мешок; 3 – деньги во второй мешок; 4 – деньги в третий мешок.
Диаграмма состояний(Statechart diagram) – диаграмма поведения, показывает поведение одного объекта в нескольких вариантах использования. Диаграмма представляет автомат, включающий в себя состояния, переходы, события и виды действий. Данная диаграмма акцентирует внимание на поведении объекта, зависящем от последовательности событий, и особенно важна при описании поведения классов, интерфейсов и коопераций.

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

Рис. 3.43. - Диаграмма деятельности (активности).


Диаграмма компонентов (Component diagram)– диаграмма, показывающая организацию совокупности компонент (файлов) и их зависимости.

Диаграмма развертывания (Deployment diagram)– диаграмма, показывающая узлы и отношения между ними (физическое размещение компонент в аппаратных средствах).

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

• 
  спецификаций (specifications) – текстовых описаний синтаксиса и семантики соответствующих элементов модели (диаграммы);
  
• 
  принятых делений (common divisions) – в соответствии с дихотомией «класс/объект» и дихотомией «интерфейс/реализация»;
  
• 
  механизмов расширения (extensibility mechanisms) – обеспечивающих расширение синтаксиса и семантики языка.
  

Предусмотрены следующие механизмы расширения языка:

• 
  стереотипы (stereotypes), позволяющие расширять словарь языка и представлять на основе существующих элементов новые специфичные для конкретных проблем элементы модели;
  
• 
  помеченные значения (tagged values), позволяющие расширять свойства элементов языка и представлять новые атрибуты и новую информацию в спецификацию элемента;
  
• 
  ограничения (constraint), позволяющие расширять семантику элементов языка и определить новые или изменить старые правила.
  

UML не зависит от процесса его использования или метода моделирования. Однако, лучше всего он поддерживает Рациональный Унифицированный Процесс (Rational Unified Process – RUP) изготовления программных продуктов.

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

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

Консорциум OMG начал разрабатывать UML 2.0, чтобы преодолеть существенные недостатки ранних версий. В число проблем, которые пытаются решить архитекторы стандарта UML 2.0, входит проблема разбухания ранних версий и недостатки в определении семантики. В процессе работы над новым стандартом возникла необходимость включить в него поддержку разработки на базе моделей (Model-DrivenDevelopment – MDD) и, в частности, подхода к такой разработке с позиций архитектуры на базе моделей (Model-DrivenArchitecture – MDA). В результате стандартизации языка моделирования общественными усилиями был разработан очень громоздкий и сложный вариант стандарта. По мнению экспертов: «Кажется, конечный результат полностью противоречит благим намерениям, породившим радикальный пересмотр стандарта. Многочисленные концепции моделирования, плохо определенная семантика и облегченные механизмы расширения UML 2.0 затрудняют его изучение и применение в MDD» ... «Язык UML 2.0 в некоторых отношениях превосходит предыдущие версии, но его громоздкость и сложность могут создать проблемы для пользователей, разработчиков инструментальных средств и рабочих групп OMG, развивающих этот стандарт».