5.Концептуальная модель uml. Сущности языка. (Новикова)

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

Язык UML основывается на понимании общих принципов моделирования сложных систем и особенностей процесса объектно-ориентированного анализа и проектирования.

Концептуальная модель языка UML включает в себя следующие части:

– основные строительные блоки языка;

– правила их сочетания;

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

В UML имеется четыре типа сущностей:

1. Структурные:

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

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

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

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

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

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

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

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

2. Поведенческие сущности (Behavioral things) являются динамическими составляющими модели UML. Это глаголы языка: они описывают поведение модели во времени и пространстве. Существуют всего два основных типа поведенческих сущностей.

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

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

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

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

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

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

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

Деятельность - это спецификация исполняемого поведения.

6. Концептуальная модель UML. Типы отношений. Диаграммы.

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

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

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

• сущности;

• отношения;

• диаграммы.

В языке UML определены четыре типа отношений:

• зависимость;

• ассоциация;

• обобщение;

• реализация.

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

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

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

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

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

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

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

• диаграммы классов;

• диаграммы объектов;

• диаграммы прецедентов;

• диаграммы последовательностей;

• диаграммы кооперации;

• диаграммы состояний;

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

• диаграммы компонентов;

• диаграммы развертывания.

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

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

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

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

На диаграммах состояний (Statechart diagrams) представлен автомат, включающий в себя состояния, переходы, события и виды действий. Диаграммы состояний относятся к динамическому виду системы; особенно они важны при моделировании поведения интерфейса, класса или кооперации. Они акцентируют внимание на поведении объекта, зависящем от последовательности событий, что очень полезно для моделирования реактивных систем.

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

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

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

7. Концептуальная модель UML. Общие механизмы языка (спецификации, дополнения, принятые деления, механизмы расширения). (Концептуальная модель UML. СМ ВЫШЕ)

Работу с UML существенно облегчает последовательное использование общих механизмов, перечисленных ниже:

• спецификации (Specifications);

• дополнения (Adornments);

• принятые деления (Common divisions);

• механизмы расширения (Extensibility mechanisms).

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

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

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

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

2) Принятые деления. При моделировании объектно-ориентированных систем реальность членится с учетом по крайней мере двух подходов.

Прежде всего, существует разделение на классы и объекты. Класс – это абстракция, объект – конкретная материализация этой абстракции.

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

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

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

• стереотипы;

• помеченные значения;

• ограничения.

Стереотип (Stereotype) расширяет словарь UML, позволяя на основе существующих блоков языка создавать новые, специфичные для решения конкретной проблемы. Например, работая с такими языками программирования, как Java или C++, часто приходится моделировать исключения (Exceptions) – они являются обыкновенными классами, хотя и рассматриваются особым образом. Обычно требуется, чтобы исключения можно было возбуждать и перехватывать, и ничего больше. Если пометить исключения соответствующим стереотипом, то с ними можно будет обращаться как с обычными строительными блоками языка.

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

Ограничения (Constraints) расширяют семантику строительных блоков UML, позволяя определять новые или изменять существующие правила. Вы можете, например, ограничить класс EventQueue так, чтобы все события добавлялись в очередь по порядку.

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

8. Артефакты начальной фазы УП.

Начальная фаза (Inception) - заключается в определении бизнес-целей проекта. Определение целей и рамок проекта.

Артефакты, которые разрабатываются на начальной фазе:

• Видение проекта (описываются общие задачи проекта, ограничения, требования).

• Модель прецедентов (функциональные требования системы).

• Дополнительная спецификация (описываются другие типы требований).

• Словарь терминов (содержит ключевую терминологию по данной предметной области).

• Перечень рисков и план управления ими (описываются все виды рисков (экономические, технологические и т.д.) и преодоление их(план)).

• План итераций (описывается, что предстоит сделать на итерациях проекта).

• Перечень документации (перечень документов, которые будут разрабатываться в данном проекте(обязательные).

9.Классификация требований к ПО (модель FURPS+).

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

1) Functionality (функциональные требования, возможности системы и т.д.);

2) Usability (удобство использования, справочная документация и т.д.);

3) Reliability (надежность, частота сбоев, возможность восстановления, предсказуемость поведения);

4) Performance (производительность, время отклика, точность и т.д.);

5) Supportability (возможность поддержки, конфигурирования);

6) Управление системой;

7) Требования к интерфейсам;

8) Проектные ограничения;

9) Юридические вопросы;

10) Требования к реализации.

10. Артефакты фазы развития.

1) Модель предметной области. Представляет собой визуализацию понятия предметной области;

2) Модель проектирования. Набор диаграмм, описывающих логику проектного решения;

3) Описание программной архитектуры. Документ, в котором рассмотрены основные архитектурные моменты и способы их реализации;

4) Модель данных. Включает схему БД и стратегию отображения объектов;

5) Модель тестирования. Описывает задачи и способы тестирования;

6) Модель реализации (Исх. код, БД, и т.д.);

7) Проектный интерфейс пользователя.

10. Модель прецедентов. Описание прецедентов.

Модель прецедентов - формализует функциональные требования к системе.

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

Развернутый формат описания прецедента:

1) Название прецедента;

2) Основной исполнитель;

3) Заинтересованные лица и их требования;

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

5) Результаты – описывает какие условия обязательно должны выполняться в случаях успешного завершения сценария результаты должны удовлетворять всем заинтересованным лицам;

6) Основной успешный сценарий – описывается типичная последовательность действий приводящая к успешному завершению сценарию и удовлетворяет интересы всех заинтересованных лиц;

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

10. Диаграмма прецедентов. Взаимосвязи прецедентов.

Диаграмма прецедентов включает в себя:

- Прецеденты;

- Исполнители (актеры);

- Ассоциации/зависимости;

- Примечания.

Прецедент - задача, выполняемая в течении одного сеанса.

Исполнитель - сущность, обладающая поведением, которая взаимодействует с системой, находясь вне её рамок.

Существуют следующие виды исполнителей:

- Основной исполнитель;

- Вспомогательный исполнитель;

- Offstage, закулисный исполнитель.

Диаграмма прецедентов отображает границы системы, внешние для системы понятия и способы использования системы.

Актеры и прецеденты могут соединятся только отношениями ассоциации.

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

1) Не следует моделировать связи между исполнителями;

2) Не следует соединять непосредственно два прецедента (кроме отношений включения, расширения, обобщения);

3) Каждый прецедент должен быть инициирован актером;

4) БД рассматривается как слой, находящийся под диаграммой.

Взаимосвязи прецедентов:

1) Обобщение.

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

2) Включение

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

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

3) Расширение

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

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

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

10. Модель предметной области.

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

Модель предметной области — это визуальное представление концептуальных классов или объектов реального мира в терминах предметной области.

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

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

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

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

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

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

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

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

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

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

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

Преимущества и недостатки:

+ ясно отображает последовательность и временной порядок сообщений

+ богатый набор обозначений

- занимает много места

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

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

Исполнитель – экземпляр участника процесса

Линия жизни показывает время, в течение которого объект существует в Системе.