Лекция 6. Объектно-ориентированный анализ и проектирование

**Первый учебный вопрос. Общая характеристика и структура унифицированного языка моделирования UML.** UML – это унифицированный графический язык моделирования для описания, визуализации, проектирования и документирования ОО систем. UML призван поддерживать процесс моделирования ПС на основе ОО подхода, организовывать взаимосвязь концептуальных и программных понятий, отражать проблемы масштабирования сложных систем. Модели на UML используются на всех этапах жизненного цикла ПС, начиная с бизнес-анализа и заканчивая сопровождением системы. Разные организации могут применять UML по своему усмотрению в зависимости от своих проблемных областей и используемых технологий. На Рисунке 1 представлена структура языка UML.  UML представляет собой графическую нотацию которая предназначена для моделирования и описания всех процессов протекающих в процессе разработки. Основу UML представляют диаграммы, которые различаются по типам и предназначены для моделирования различных аспектов разработки. Все диаграммы можно условно разделить на поведенческие и структурные. Поведенческие диаграммы отображают процессы, протекающие в моделируемой среде. Структурные диаграммы отображают элементы, из которых состоит система. При этом одни и те же типы диаграмм могут использоваться как для моделирования бизнес-процессов, так и для непосредственного проектирования архитектуры. **Второй учебный вопрос. Способы применения UML: режимы использования диаграмм и опции режимов использования.** Существует три основных режима использования UML диаграмм: 1) режим эскиза; 2) режим проектирования; 3) режим языка программирования. У режимов есть две опции: прямой (диаграммы до кода) и обратный (диаграммы на основании кода) инжиниринг. Ниже разбираются способы использования UML–диаграмм: *Моделирование.* Графические средства UML можно и нужно использовать безотносительно ко всему остальному. Даже рисование диаграмм карандашом на бумаге позволяет упорядочить мысли и зафиксировать для себя существенную информацию о моделируемом приложении или иной системе. Обмен информацией. Сообщество людей, применяющих и понимающих UML, стремительно растет. Если вы будете использовать UML, то вас будут понимать другие, и вы будете понимать других специалистов. *Спецификация систем.* Это важнейший способ использования UML. И хотя не во всех случаях UML оказывается абсолютно адекватным средством спецификации, по мере развития языка все меньше будет оставаться таких исключений, где UML неприменим. *Повторное использование архитектурных решений* — ключ к повышению эффективности. К сожалению, модели UML пока что повторно используются в весьма ограниченных масштабах. Генерация кода. Генерировать код нужно и можно, но возможности имеющихся инструментов не стоит переоценивать. *Имитационное моделирование. *Возможности построения моделей UML, из которых путем вычислительных экспериментов можно было бы извлекать информацию о моделируемом объекте, пока что уступают возможностям специализированных систем, сконструированных для этих целей. *Верификация моделей. *Было бы замечательно, если бы по модели можно было бы делать формальные заключения об ее свойствах: модель непротиворечива, согласована, эффективна и т. п. Кое-что UML позволяет проверить, но, конечно, очень мало. Здесь уместно привести аналогию с традиционными системами программирования: они позволяют быстро и надежно избавиться от синтаксических ошибок, но с логическими ошибками дело обстоит гораздо хуже. **Третий учебный вопрос. Группа OMG и стандартизация UML** UML – это стандартная нотация для моделирования объектно-ориентированных систем. Она официально поддерживается Object Management Group (OMG) и компаниями, которые входят в эту группу, то есть, другими словами, большинством тех, кто занимается бизнесом в области объектно-ориентированного программного обеспечения. UML предназначен для спецификации, конструирования, визуализации и документирования артефактов сложных систем программного обеспечения. Во-первых, важно отметить, что этот язык является сплавом концепций методов Буча, OMT и OOSE. В результате такого подхода был создан единый, общий и широко используемый язык моделирования для пользователей этих и других методов. Во-вторых, UML дает возможность охватить практически все то, что может быть сделано с помощью существующих методов. Так, например, авторы UML принимали во внимание моделирование параллельных распределенных систем с тем, чтобы обеспечить возможность адекватного использования UML в этой области. В-третьих, в центре внимания разработчиков UML было создание стандартного языка, а не стандартного процесса моделирования. Хотя UML должен быть применимым в контексте любого процесса, опыт показал, что для различных организаций и областей приложений требуются различные процессы. Например, процесс разработки программного обеспечения сложных систем реального времени в авионике, от которых зависят жизни людей, значительно отличается от разработки программного обеспечения для других целей. Поэтому усилия были прежде всего сосредоточены на общей метамодели (унифицирующей семантику), а во-вторых, на общей нотации (обеспечивающей воспринимаемое человеком воплощение этой семантики). Авторы UML поддерживают процесс разработки, который управляется случаями использования (use-case), является архитектуро-центрическим, итерационным и пошаговым. ***ДИАГРАММЫ В UML.*** В рамках языка UML все представления о модели сложной системы фиксируются в виде специальных графических конструкций, получивших название диаграмм. Определены следующие виды канонических диаграмм: 1. Диаграмма вариантов использования. 2. Диаграмма классов. 3. Диаграмма состояний. 4. Диаграмма деятельности. 5. Диаграмма последовательности. 6. Диаграмма кооперации. 7. Диаграмма компонентов. 8. Диаграмма развертывания. Каждая из этих диаграмм детализирует и конкретизирует различные представления о модели сложной системы в терминах языка UML. Далее приводится детальная характеристика каждой из указанных диаграмм. **Четвертый учебный вопрос. Диаграмма вариантов использования (use case diagram). ** Рассматриваемая диаграмма UML отражает взаимосвязи сценариев использования и ролей, их исполняющих. Такая детализация позволяет построить модель системы на концептуальном уровне. «Визуальное моделирование в UML можно представить, как некоторый процесс поуровневого спуска от наиболее обшей и абстрактной концептуальной модели исходной системы к логической, а затем и к физической модели соответствующей программной системы. Для достижения этих целей вначале строится модель в форме диаграммы вариантов использования (use case diagram), которая описывает функциональное назначение системы. Диаграмма вариантов использования является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки. Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру.  Рисунок 2 – Диаграммы вариантов использования Актер представляет собой любую внешнюю по отношению к моделируемой системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей или решения частных задач. Стандартным графическим обозначением актера на диаграммах является фигурка «человечка», под которой записывается конкретное имя актера. Интерфейс (interface) служит для спецификации параметров модели, которые видимы извне без указания их внутренней структуры. Применительно к диаграммам вариантов использования, интерфейсы определяют совокупность операций, которые обеспечивают необходимый набор сервисов или функциональности для актеров. Примечания (notes) в языке UML предназначены для включения в модель произвольной текстовой информации, имеющей непосредственное отношение к контексту разрабатываемого проекта. Между компонентами диаграммы вариантов использования могут существовать различные отношения, которые описывают взаимодействие экземпляров одних актеров и вариантов использования с экземплярами других актеров и вариантов. **Пятый учебный вопрос. Диаграмма классов (class diagram)** Указанный тип диаграммы UML представляет классы объектов программного продукта, их взаимосвязи, атрибуты, а также операции над ними. Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений. Пример диаграммы классов учебного центра представлен на Рисунке 3:  Диаграмма классов представляет собой некоторый граф, вершинами которого являются элементы типа «классификатор», которые связаны различными типами структурных отношений. Следует заметить, что диаграмма классов может также содержать интерфейсы, пакеты, отношения и даже отдельные экземпляры, такие как объекты и связи. Когда говорят о данной диаграмме, имеют в виду статическую структурную модель проектируемой системы. Поэтому диаграмму классов принято считать графическим представленном таких структурных взаимосвязей логической модели системы, которые не зависят или инвариантны от времени. Класс (class) в языке UML служит для обозначения множества объектов, которые обладают одинаковой структурой, поведением и отношениями с объектами из других классов. Графически класс изображается в виде прямоугольника, который дополнительно может быть разделен горизонтальными линиями на разделы или секции. В этих разделах могут указываться имя класса, атрибуты (переменные) и операции (методы). Кроме внутреннего устройства или структуры классов на соответствующей диаграмме указываются различные отношения между классами: 2. 1. Отношение зависимости. В общем случае указывает некоторое семантическое отношение между двумя элементами модели или двумя множествами таких элементов, которое не является отношением ассоциации, обобщения или реализации 2. Отношение ассоциации. Соответствует наличию некоторого отношения между классами. Данное отношение обозначается сплошной линией с дополнительными специальными символами, которые характеризуют отдельные свойства конкретной ассоциации. 3. Отношение агрегации. Имеет место между несколькими классами в том случае, если один из классов представляет собой некоторую сущность, включающую в себя в качестве составных частей другие сущности. Данное отношение имеет фундаментальное значение для описания структуры сложных систем, поскольку применяется для представления системных взаимосвязей типа «часть-целое». Раскрывая внутреннюю структуру системы, отношение агрегации показывает, из каких компонентов состоит система и как они связаны между собой. 4. Отношение обобщения. Является частным случаем отношения агрегации. Это отношение служит для выделения специальной формы отношения «часть-целое», при которой составляющие части в некотором смысле находятся внутри целого. Специфика взаимосвязи между ними заключается в том, что части не могут выступать в отрыве от целого, т.е. с уничтожением целого уничтожаются и все его составные части. Объект (object) является отдельным экземпляром класса, который создается на этапе выполнения программы. Он имеет свое собственное имя и конкретные значения атрибутов. Для графического изображения объектов используется такой же символ прямоугольника, что и для классов. Отличия проявляются при указании имен объектов, которые в случае объектов обязательно подчеркиваются. При этом запись имени объекта представляет собой строку текста «имя объекта: имя класса», разделенную двоеточием. **Шестой учебный вопрос. Диаграмма состояний (statechart diagram)** Данный тип диаграмм используется с целью пояснения аспектов функционирования сложноорганизованных систем. Главное предназначение этой диаграммы — описать возможные последовательности состояний и переходов, которые в совокупности характеризуют поведение элемента модели в течение его жизненного цикла. Диаграмма состояний представляет динамическое поведение сущностей, на основе спецификации их реакции на восприятие некоторых конкретных событий. Диаграмма состояний по существу является графом специального вида, который представляет некоторый автомат. Вершинами этого графа являются состояния и некоторые другие типы элементов автомата, которые изображаются соответствующими графическими символами. Дуги графа служат для обозначения переходов из состояния в состояние. Автомат (state machine) в языке UML представляет собой некоторый формализм для моделирования поведения элементов модели и системы в целом. Автомат описывает поведение отдельного объекта в форме последовательности состояний, которые охватывают все этапы его жизненного цикла, начиная от создания объекта и заканчивая его уничтожением. Каждая диаграмма состояний представляет некоторый автомат. Пример, визуализирующий диаграмму состояний изображён ниже на Рисунке 4.  В языке UML под состоянием понимается абстрактный метакласс, используемый для моделирования отдельной ситуации, в течение которой имеет место выполнение некоторого условия. Состояние может быть задано в виде набора конкретных значений атрибутов класса или объекта, при этом изменение их отдельных значений будет отражать изменение состояния моделируемого класса или объекта. Состояние на диаграмме изображается прямоугольником со скругленными вершинами **Седьмой учебный вопрос. Диаграмма деятельности (activity diagram) ** Диаграмма UML, демонстрирующая активности, чьи состояния визуализируются на диаграмме состояний. Для моделирования процесса выполнения операций в языке UML используются так называемые диаграммы деятельности. Каждое состояние на диаграмме деятельности соответствует выполнению некоторой элементарной операции, а переход в следующее состояние срабатывает только при завершении этой, операции в предыдущем состоянии. Графически диаграмма деятельности представляется в форме графа деятельности, вершинами которого являются состояния действия, а дугами — переходы от одного состояния действия к другому. В контексте языка UML деятельность (activity) представляет собой некоторую совокупность отдельных вычислений, выполняемых автоматом. При этом отдельные элементарные вычисления могут приводить к некоторому результату или действию (action). На диаграмме деятельности отображается логика или последовательность перехода от одной деятельности к другой, при этом внимание фиксируется на результате деятельности. Сам же результат может привести к изменению состояния системы или возвращению некоторого значения. Пример диаграммы деятельности представлен на Рисунке 5:  При построении диаграммы деятельности используются переходы, которые срабатывают сразу после завершения деятельности или выполнения соответствующего действия. Этот переход переводит деятельность в последующее состояние сразу, как только закончится действие в предыдущем состоянии. На диаграмме такой переход изображается сплошной линией со стрелкой. Диаграммы деятельности могут быть использованы не только для спецификации алгоритмов вычислений или потоков управления в программных системах. Не менее важная область их применения связана с моделированием бизнес-процессов. Для моделирования этих особенностей в языке UML используется специальная конструкция, получившее название дорожки (swimlanes). При этом все состояния действия на диаграмме деятельности делятся на отдельные группы, которые отделяются друг от друга вертикальными линиями. Две соседние линии и образуют дорожку, а группа состояний между этими линиями выполняется отдельным подразделением (отделом, группой, отделением, филиалом) компании. **Восьмой учебный вопрос. Диаграмма последовательности (sequence diagram)** Для моделирования взаимодействия объектов во времени, т.е., для представления временных особенностей передачи и приема сообщений между объектами используется диаграмма последовательности. Данный тип диаграмм применяется экспертами для иллюстрации жизненного цикла конкретного объекта информационной системы, применяя тайм-лайн оси набора объектов этой же системы, а также взаимосвязь актёров, работающих с программным продуктом в рамках некоего события или прецедента. На диаграмме последовательности изображаются исключительно те объекты, которые непосредственно участвуют во взаимодействии и не показываются возможные статические ассоциации с другими объектами. Для диаграммы последовательности ключевым моментом является именно динамика взаимодействия объектов во времени. Сообщение (message) представляет собой законченный фрагмент информации, который отправляется одним объектом другому. При этом прием сообщения инициирует выполнение определенных действий, направленных на решение отдельной задачи тем объектом, которому это сообщение отправлено. Визуализация диаграммы последовательности изображены на Рисунке 6:  **Девятый учебный вопрос. Диаграмма кооперации (collaboration diagram)** На данном типе диаграмм UML иллюстрируются взаимосвязи между элементами составной структуры и ролями кооперации. Диаграмма кооперации предназначена для спецификации структурных аспектов взаимодействия. Главная особенность диаграммы кооперации заключается в возможности графически представить не только последовательность взаимодействия, но и все структурные отношения между объектами, участвующими в этом взаимодействии. Прежде всего, на диаграмме кооперации в виде прямоугольников изображаются участвующие во взаимодействии объекты, содержащие имя объекта, его класс и, возможно, значения атрибутов. Далее, как и на диаграмме классов, указываются ассоциации между объектами в виде различных соединительных линий. При этом можно явно указать имена ассоциации и ролей, которые играют объекты в данной ассоциации. Дополнительно могут быть изображены динамические связи — потоки сообщений. Они представляются также в виде соединительных линий между объектами, над которыми располагается стрелка с указанием направления, имени сообщения и порядкового номера в общей последовательности инициализации сообщений. UML-диаграмма кооперации визуализирована на Рисунке 7:  **Десятый учебный вопрос. Диаграмма компонентов (component diagram)** Диаграмма компонентов – это нединамическая диаграмма устройства системы, демонстрирующая декомпозицию программного продукта на отдельные компоненты и их взаимосвязи и взаимозависимости друг с другом. Диаграмма компонентов описывает особенности физического представления системы. Диаграмма компонентов позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный, бинарный и исполняемый код. Во многих средах разработки модуль или компонент соответствует файлу. Пунктирные стрелки, соединяющие модули, показывают отношения взаимозависимости, аналогичные тем, которые имеют место при компиляции исходных текстов программ. Демонстрация диаграммы компонентов приведена на Рисунке 8:  **Одинадцатый учебный вопрос. Диаграмма развертывания (deployment diagram) ** Диаграмма развёртывания демонстрирует внутренние качества программного продукта, группирову его элементов по узлам и связи этих элементов – пути перемещения данных между техническими узлами. Диаграмма развертывания - диаграмма, на которой представлены узлы выполнения программных компонентов реального времени, а также процессов и объектов. Диаграмма развертывания применяется для представления общей конфигурации и топологии распределенной программной системы и содержит распределение компонентов по отдельным узлам системы. Кроме того, диаграмма развертывания показывает наличие физических соединений — маршрутов передачи информации между аппаратными устройствами, задействованными в реализации системы. Диаграмма развертывания предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения (runtime). При этом представляются только компоненты-экземпляры программы, являющиеся исполнимыми файлами или динамическими библиотеками. Те компоненты, которые не используются на этапе исполнения, на диаграмме развертывания не показываются. Так, компоненты с исходными текстами программ могут присутствовать только на диаграмме компонентов. На диаграмме развертывания они не указываются. Пример UML-диаграммы развёртывания, демонстрирующий все узлы выполнения компонентов программы, изображён ниже на Рисунке 9:  Выше были представлены определения базовых конструкций языка UML и нотация графических элементов, используемых при построении моделей программных систем и бизнес-процессов.