Модели объектно-ориентированных программных систем.

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

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

· в ходе анализа - для указания ролей и обязанностей сущностей, которые обес­печивают поведение системы;

· в ходе проектирования - для фиксации структуры классов, которые формиру­ют системную архитектуру.

Обозначение класса показано на рисунке.

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

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

Видимость Имя [Множественность]: Тип = НачальнЗначение {Характеристики}

В языке UML определены три уровня видимости.

Определены три характеристики свойств.

Общий синтаксис представления операции имеет вид

Видимость Имя (Список Параметров): ВозвращаемыйТип {Характеристики}

Элемент Направление может принимать одно из следующих значений:

Допустимо применение следующих характеристик операций:

Отношения в диаграммах классов

Отношения, используемые в диаграммах классов, показаны на рисунке.

Ассоциации отображают структурные отношения между экземплярами классов, то есть соединения между объектами. Каждая ассоциация может иметь метку — имя, которое описывает природу отношения. Имени можно придать направление — достаточно добавить треугольник направления, который указывает направление, заданное для чтения имени.

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

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

Зависимость является отношением использования между клиентом (зависимым элементом) и поставщиком (независимым элементом). Обычно операции кли­ента:

· вызывают операции поставщика;

· имеют сигнатуры, в которых возвращаемое значение или аргументы принадле­жат классу поставщика.

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

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

Динамические модели обеспечивают представление поведения систем. «Дина­мизм» этих моделей состоит в том, что в них отражается изменение состояний в про­цессе работы системы (в зависимости от времени). Средства языка UML для соз­дания динамических моделей многочисленны и разнообразны. Эти средства ориентированы не только на собственно программные системы, но и на отображение требований заказчика к поведению таких систем.

Для моделирования поведения системы используют:

· автоматы;

· взаимодействия.

Автомат (State machine) описывает поведение в терминах последовательности со­стояний, через которые проходит объект в течение своей жизни. Взаимодействие (Interaction) описывает поведение в терминах обмена сообщениями между объек­тами.

Таким образом, автомат задает поведение системы как цельной, единой сущности; моделирует жизненный цикл единого объекта. В силу этого автоматный подход удобно применять для формализации динамики отдельного трудного для понима­ния блока системы.

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

Автоматы отображают с помощью:

· Диаграмм схем состояний;

· Диаграмм деятельности.

Взаимодействия отображают с помощью:

· диаграмм сотрудничества (кооперации);

· диаграмм последовательности.

Диаграммы схем состояний

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

· набор состояний системы;

· события, которые вызывают переход из одного состояния в другое;

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

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

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

Диаграммы деятельности

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

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

Переходы между вершинами — состояниями действий — изображаются в виде стре­лок. Переходы выполняются по окончании действий.

Кроме того, в диаграммах деятельности используются вспомогательные вер­шины:

· решение (ромбик с одной входящей и несколькими исходящими стрелками);

· объединение (ромбик с несколькими входящими и одной исходящей стрелкой);

· линейка синхронизации — разделение (жирная горизонтальная линия с одной входящей и несколькими исходящими стрелками);

· линейка синхронизации — слияние (жирная горизонтальная линия с несколь­кими входящими и одной исходящей стрелкой);

· начальное состояние (черный кружок);

· конечное состояние (незакрашенный кружок, в котором размещен черный кру­жок меньшего размера).

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

Вершина «объединение» отмечает точку слияния альтернативных потоков дей­ствий.

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

Диаграммы взаимодействия

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

Диаграммы сотрудничества

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

Обозначение объекта показано на рисунке.

Имя объекта подчеркивается и показывается всегда, свойства указываются выборочно.

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

Сообщение — это спецификация передачи информации между объектами в ожи­дании того, что будет обеспечена требуемая деятельность. Прием сообщения рас­сматривается как событие.

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

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

Графически диаграмма последовательности — разновидность таблицы, которая показывает объекты, размещенные вдоль оси X, и сообщения, упорядоченные по времени вдоль оси Y.

От диаграмм сотрудничества диаграммы последовательности отличают две важ­ные характеристики.

Первая характеристика — линия жизни объекта.

Линия жизни объекта — это вертикальная пунктирная линия, которая обозначает период существования объекта. Большинство объектов существуют на протяже­нии всего взаимодействия, их линии жизни тянутся от вершины до основания диа­граммы. Впрочем, объекты могут создаваться в ходе взаимодействия. Их линии жизни начинаются с момента приема сообщения «create». Кроме того, объекты могут уничтожаться в ходе взаимодействия. Их линии жизни заканчиваются с момента приема сообщения «destroy».

Вторая характеристика — фокус управления.

Фокус управления — это высокий тонкий прямоугольник, отображающий период времени, в течение которого объект выполняет действие (свою или подчиненную процедуру). Вершина прямоугольника отмечает начало действия, а основание — его" завершение. Момент завершения может маркироваться сообщением возврата, которое показывается пунктирной стрелкой; Можно показать вложение фокуса управления (например, рекурсивный вызов собственной операции). Для этого вто­рой фокус управления рисуется немного правее первого.

Диаграммы Use Case

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

Вершинами в диаграмме Use Case являются актеры и элементы.

Актер — это роль объекта вне системы, который прямо взаимодействует с ее час­тью — конкретным элементом (элементом Use Case). Различают актеров и пользо­вателей. Пользователь — это физический объект, который использует систему. Он может играть несколько ролей и поэтому может моделироваться несколькими ак­терами. Справедливо и обратное — актером могут быть разные пользователи. Например, для коммерческого летательного аппарата можно выделить двух акте­ров: пилота и кассира.

Элемент Use Case — это описание последовательности действий (или нескольких последовательностей), которые выполняются системой и производят для отдель­ного актера видимый результат.

Один актер может использовать несколько элементов Use Case, и наоборот, один элемент Use Case может иметь несколько актеров, использующих его. Каждый эле­мент Use Case задает определенный путь использования системы. Набор всех эле­ментов Use Case определяет полные функциональные возможности системы.

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

Между актерами допустимо отношение обобщения, означающее, что экземпляр потомка может взаимодействовать с такими же разновидностями эк­земпляров элементов Use Case, что и экземпляр родителя.

Между элементами Use Case определены отношение обобщения и две разновид­ности отношения зависимости — включения и расширения. Отношение обобщения фиксирует, что потомок наследует поведение родителя. Кроме того, потомок может дополнить или переопределить поведение родителя. Элемент Use Case, являющийся потомком, может замещать элемент Use Case, являющийся родителем, в любом месте диаграммы.

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

Отношение расширения между элементами Use Case означает, что базовый элемент Use Case неявно включает поведение другого элемента Use Case в точке, которая определяется косвенно расширяющим элементом Use Case. Базовый элемент Use Case может быть автономен, но при определенных условиях его поведение может расширяться поведением из другого элемента Use Case. Базовый элемент Use Case может расширяться только в определенных точках — точках расширения. Отношение расширения применяется для моделирования выбираемого поведения системы. Таким способом можно отделить обязательное поведение от необязатель­ного поведения.

???????????????????????????????????????????????????????????????????7???????????7