Введение в системный анализ Нотация UML. Часть 1 © geekbrains.ru На этом уроке 1. Познакомимся с основами объектно-ориентированного анализа. 2. Поговорим про области применения языка UML. 3. Получим представление о принципах моделирования информационных систем на языке UML. 4. Разберём, что такое классы и отношения между ними. 5. Выясним, для чего нужны диаграммы последовательностей. 6. Рассмотрим основные средства для моделирования на языке UML. Оглавление Понятие объектно-ориентированного анализа Основные принципы объектной модели Язык UML Определение Применение UML Из чего состоит UML Структурные диаграммы Поведенческие диаграммы Унифицированный процесс разработки (Unified Process) Основные принципы моделирования Классы и отношения между ними Отношения между классами Диаграммы последовательностей Типы сообщений Правила построения диаграмм последовательностей Фреймы взаимодействия Практическое задание Глоссарий Используемые источники © geekbrains.ru 1 Понятие объектно-ориентированного анализа Объектно-ориентированный (далее — ОО) анализ — метод анализа, который исследует требования к системе с точки зрения классов и объектов, относящихся к словарю предметной области. Определение дано в соответствии с трудами Г. Буча. Анализ заключается в создании моделей, отображающих основные требования и характеристики целевой системы. Аналитическое моделирование имеет стратегическое значение при разработке информационных систем. В книге «Объектно-ориентированный анализ и проектирование» (1991 г.), ставшей одной из основополагающих, Майкл Блаха и Джеймс Рамбо определяют ОО-подход как метод, при котором мы рассматриваем систему как набор отдельных объектов, включающих в себя одновременно структуру данных и «поведение» (операции). Важно! Это основное отличие от функционального (структурного) подхода к программированию, когда данные и операции слабо связаны. Основные элементы теперь классы и объекты, а не алгоритмы (см. рисунок 1 ниже). Переход к объектно-ориентированному подходу стал необходимым условием для проектирования больших сложных систем, в том числе благодаря возможности построения абстрактных классов. Рисунок 1. Различие структурного и объектно-ориентированного подходов Авторы выделяют стадии моделирования, на которых применяется ОО-подход: 1. Анализ. На этой стадии объекты относятся к области применения, а не к информационным системам. Модель не зависит от конкретного внедряемого решения. 2. Дизайн системы. Определяется высокоуровневая архитектура решения, целевая система разбивается на подсистемы, определяются требования к производительности. © geekbrains.ru 2 3. Дизайн объектов. В качестве основы используется аналитическая модель. На этой стадии добавляются детали внедряемого решения, определяются структура данных и алгоритмы поведения объектов. 4. Внедрение. На этом этапе модель приводится в соответствие с конкретным языком программирования, выбранной БД и инфраструктурой. Модели OO-анализа в дальнейшем преобразуются в объектно-ориентированный проект. Г. Буч даёт следующее определение объектно-ориентированного проектирования (дизайна): это методология проектирования, соединяющая в себе процесс объектной декомпозиции и приёмы представления логической (структуры классов) и физической (архитектура модулей и процессов), а также статической и динамической моделей проектируемой системы. Цель ОО-проектирования — правильное и эффективное структурирование сложной системы для последующей разработки. Одна из основных задач, решаемых на этапе ОО-анализа и ранних стадиях проектирования, — выявление ключевых сущностей (абстракций), то есть классов и объектов, присущих предметной области. Для этого сначала необходимо сформировать логический каркас системы: выделить классы, а затем описать атрибуты (свойства) этих классов, связи и взаимодействия между ними. Сущности определяют границы решаемой проблемы. От того, насколько качественно проведён первичный анализ, зависит дальнейшая консистентность модели и в конечном счёте реализация. Конечно, не все объекты, существующие в информационной системе, имеют свои аналоги в реальном мире. При проектировании появляется достаточно много вспомогательных объектов, которые создают среду для объектов бизнес-логики и служат для обозначения части системы, моделирующей предметную область или задачу. Необходимо чётко понимать, чем объект отличается от класса. Объект (или экземпляр класса) обладает состоянием, поведением и идентичностью, а структуру и поведение схожих объектов определяет общий для них класс. Совет. Получив документ с требованиями, для начала выделите в нём все существительные. Выпишите их и подумайте, какие из них могут быть рассмотрены как классы. Далее посмотрите на глаголы: они помогут выстроить связи между сущностями. Более подробно о понятии объекта и о том, как выделять сущности, читайте у основоположников. Вы найдёте ссылку на материал в «Используемых источниках» — Буч, Румба, Блаха [2, 7]. Основные принципы объектной модели 1. Абстрагирование — способ выделить набор значимых характеристик объекта, исключая из рассмотрения незначимые. 2. Инкапсуляция — свойство системы, позволяющее объединить данные и методы, работающие с ними, в классе и скрыть детали реализации от пользователя. © geekbrains.ru 3 3. Полиморфизм — свойство системы использовать объекты с одинаковым интерфейсом без информации о типе и внутренней структуре объекта. 4. Наследование — свойство системы, позволяющее описать новый класс на основе уже существующего с частично или полностью заимствующейся функциональностью. Класс, от которого производится наследование, называется базовым или родительским. Новый класс — потомком, наследником или производным классом. Далее мы ещё поговорим о классах и отношениях между ними. Язык UML Определение Гради Буч (Grady Booch), Ивар Якобсон (Ivar Jacobson), Джим Оделл (Jim Odell), Джим Рамбо (Jim Rumbaugh) впервые описали ОО-подход и структурировали то, к чему естественным путём пришла разработка. Благодаря им возник UML. Унифицированный язык моделирования (Unified Modeling Language) — язык визуального моделирования (чаще всего для ОО-анализа). Основная идея UML — возможность моделировать программное обеспечение и другие системы как наборы взаимодействующих объектов. К конференции OOPSLA ’95 Гради Буч и Джим Рамбо, работавшие в Rational Software, подготовили первое публичное описание их совместного метода — версию 0.8 документации по унифицированному методу (Unified Method). UML как стандарт был создан группой управления объектами (OMG), а проект спецификации UML 1.0 был предложен OMG в январе 1997 года. UML распространяется абсолютно свободно на сайте OMG. В настоящее время действует версия UML 2.0. OMG постоянно прилагает усилия для создания отраслевого стандарта. Рисунок 2. Соотношение ОО-подхода и UML © geekbrains.ru 4 UML — это язык, первичным же остаётся процесс ОО-анализа и моделирования. Используя доступные на рынке CASE-средства, позволяющие работать на языке UML, вы создаёте модели. UML служит для «сверки часов», чтобы разные аналитики понимали друг друга. Наиболее удобные и часто используемые инструменты моделирования на UML: ● Draw.io; ● Visual Paradigm (доступна бесплатно Community edition); ● Gliffy (плагин к Confluence); ● MS Visio. Применение UML 1. Эскизное моделирование. В процессе разработки с помощью UML очень удобно делать наброски отдельных элементов системы. С помощью эскизов можно облегчить обмен идеями и вариантами с другими членами команды. Команда обсуждает не всю систему или проект, а только самые важные моменты или разделы проекта, которые необходимо визуализировать до начала разработки. Сила эскизов в избирательности передачи информации, а не в полноте описания. 2. Язык UML как средство проектирования нацелен на полноту. Задача заключается в построении детальной модели для программиста. Такая модель должна быть достаточно полной в части заложенных проектных решений, а программист должен иметь возможность следовать им прямо и не особо задумываясь. Детальное проектирование может быть использовано только для части системы или проекта, если это необходимо. При разработке моделей необходимо учитывать: a. выбранный инструментарий: контроль версий, репозиторий объектов, связь между диаграммами; b. глубину проработки модели и её полноту; цель — минимизировать программирование, свести его к простым действиям. 3. Ещё более глубоких знаний и больших усилий требуют проекты, в которых UML используется в качестве языка программирования. Существуют инструменты, позволяющие на основе диаграмм скомпилировать исполняемый код (программу), например Visual Paradigm. Часто в этом контексте упоминают термин MDA (Model Driven Architecture — архитектура, управляемая моделью). Этот стандарт находится под управлением группы OMG, как и сам UML. MDA разделяет процесс разработки на две основные части. Сначала аналитики создают PIM (Platform Independent Model — модель, не зависящая от платформы). PIM — это модель UML, не зависящая от какой-то конкретной технологии. Затем инструменты могут превратить PIM в PSM (Platform Specific Model — модель, зависящая от платформы). PSM — это модель системы, нацеленная на определённую среду выполнения. Другие инструменты берут PSM и генерируют код для этой платформы. В качестве PSM можно использовать UML, но это не обязательно. © geekbrains.ru 5 На практике, несмотря на достаточно развитые инструменты, перейти к этому процессу очень сложно. Нужно гарантировать полноту и непротиворечивость модели, на что, безусловно, нужно много временных ресурсов. Гораздо проще отделить непосредственно программирование от моделирования. Аналогичные идеи можно проследить в графических языках программирования. Всё время возникает достаточно много ограничений, которые не позволяют повсеместно применять подобный подход. Из чего состоит UML Язык UML в своём нынешнем состоянии определяет нотацию и метамодель. Нотация представляет собой совокупность графических элементов, которые применяются в моделях. Она и есть синтаксис этого языка моделирования. Например, нотация диаграммы классов определяет способ представления таких элементов и понятий, как класс, ассоциация и кратность. В настоящее время многие люди, вовлечённые в разработку UML, интересуются в основном метамоделью — описанием языка построения модели — в частности потому, что она важна при использовании UML и языка программирования. Метамодель определяет абстрактный синтаксис и семантику понятий объектного моделирования на языке UML. Когда вы глубже погрузитесь в изучение UML, то поймёте, что вам требуется значительно больше, чем просто графическая нотация. Вот почему инструменты UML так сложны. UML 2.0 описывает 13 официальных типов диаграмм. Далее рассмотрим основные из них. Структурные диаграммы Структурные диаграммы представляют статический аспект системы. Эти статические части представлены классами, интерфейсами, объектами, компонентами и узлами. 1. Диаграмма классов (Class diagram). 2. Диаграмма объектов (Object diagram). 3. Диаграмма компонентов (Component diagram). 4. Диаграмма развёртывания (Deployment diagram). Поведенческие диаграммы Поведенческие диаграммы в основном отражают динамический аспект системы. Динамический аспект может быть далее описан как изменяющиеся или движущиеся части системы. UML имеет следующие типы поведенческих диаграмм: 1. Диаграмма вариантов использования (прецедентов) (Use case diagram). 2. Диаграмма последовательности (Sequence diagram). 3. Диаграмма сотрудничества (Collaboration diagram). 4. Диаграмма состояний (State diagram). 5. Диаграмма деятельности (Activity diagram). © geekbrains.ru 6 Унифицированный процесс разработки (Unified Process) Когда говорят о UML, часто упоминают RUP (Rational Unified Process — унифицированный процесс, созданный компанией Rational). Он не имеет особого отношения к UML, хотя тоже создавался сотрудниками фирмы Rational и в его названии есть слово «унифицированный». Язык UML можно использовать с любыми процессами, которые не рассматриваются в этом уроке. RUP — это коммерческий продукт, расширяющий UP. Унифицированный процесс разработки программного обеспечения (Unified Software Development Process, USDP) — это SEP, процесс производства программного обеспечения (Software Engineering Process) от авторов UML. Обычно его называют унифицированным процессом или UP. Это универсальный процесс разработки ПО, который должен настраиваться для определённой организации и для каждого конкретного проекта. Следует заметить, что UML был стандартизован OMG, а UP — нет. Поэтому до сих пор не существует стандартного процесса для UML. UP базируется на трёх аксиомах. Он является: ● управляемым требованиями и риском; ● архитектуроцентричным; ● итеративным и инкрементным. В каждой итерации пять основных рабочих потоков (см. ниже) определяют, что должно быть сделано и какие навыки для этого необходимы. Наряду с пятью основными рабочими потоками — по сути, в других методологиях это стадии разработки ПО — будут присутствовать и другие, такие как планирование, оценка и всё, что характерно для этой конкретной итерации. Однако эти этапы не выделены в UP. К пяти основным рабочим потокам относятся: ● определение требований — сбор данных о том, что должна делать система; ● анализ — уточнение и структурирование требований; ● проектирование — реализация требований в архитектуре системы; ● реализация — построение программного обеспечения; ● тестирование — проверка, отвечает ли реализация предъявляемым требованиям. Рисунок 3. Структура UP © geekbrains.ru 7 Основные принципы моделирования Рассмотрим основные рекомендации для ОО-проектирования на UML. Этот список можно расширять бесконечно — это как раз то, что вы постепенно собираете в качестве своего опыта проектирования на UML. 1. Не спешите строить диаграмму классов. Сначала поймите проблему, которую необходимо решить. 2. Старайтесь делать модель простой, без излишних усложнений. 3. Осторожно выбирайте названия классов, атрибутов и ассоциаций. 4. Не спешите выбирать отношение генерализации, зачастую его можно представить другим способом, декомпозировав задачу. 5. Не старайтесь сразу обозначить множественность для ассоциаций. 6. Используйте квалификатор для ассоциаций между классами, где возможно. 7. Используйте абстрактные классы для возможности повторного использования кода. 8. Обращайтесь к паттернам проектирования (см. пункт 10 в «Используемых источниках». 9. Проводите ревизию модели. Уточнения могут возникать на любом этапе проекта. 10. Документируйте свою модель. Пояснения позволяют объяснить причины выбора конкретного пути решения задачи, прояснить смысл выделенных классов. 11. Старайтесь создать гибкое решение и модель для повышения устойчивости к изменениям. Классы и отношения между ними Как было обозначено выше, на начальных этапах анализа и проектирования необходимо определить логическую структуру системы, что очень удобно сделать с помощью диаграммы классов. Диаграмма классов описывает типы объектов системы и различного рода статические отношения между ними. На диаграммах классов отображаются также свойства классов, операции классов и ограничения, которые накладываются на связи между объектами. В общем случае пакет статической структурной модели может быть представлен в виде одной или нескольких диаграмм классов. Декомпозиция некоторого представления на отдельные диаграммы выполняется с целью удобства и графической визуализации структурных взаимосвязей предметной области. Класс (class) служит для обозначения множества объектов, которые обладают одинаковой структурой, поведением и отношениями с объектами из других классов. Обязательный элемент обозначения класса — его имя. Имя класса должно быть уникальным в пределах пакета, который описывается некоторой совокупностью диаграмм классов (возможно, одной диаграммой). На начальных этапах разработки диаграммы отдельные классы могут обозначаться простым прямоугольником с указанием только имени соответствующего класса. По мере проработки отдельных компонентов диаграммы описания классов дополняются атрибутами и операциями. Предполагается, что окончательный вариант диаграммы содержит наиболее полное описание классов. © geekbrains.ru 8 Класс может не иметь экземпляров или объектов. В этом случае он называется абстрактным классом, а для обозначения его имени используется наклонный шрифт (курсив). В языке UML принято общее соглашение, что любой текст, относящийся к абстрактному элементу, записывается курсивом. Рисунок 4. Пример диаграммы классов Каждому атрибуту класса соответствует отдельная строка текста, которая состоит из квантора видимости атрибута, имени атрибута, его кратности, типа значений атрибута и, возможно, его исходного значения: 1. Символ «+» обозначает атрибут с областью видимости типа «общедоступный» (public). Атрибут с этой областью видимости доступен или виден из любого другого класса пакета, в котором определена диаграмма. 2. Символ «#» обозначает атрибут с областью видимости типа «защищённый» (protected). Атрибут с этой областью видимости недоступен или не виден для всех классов, за исключением подклассов этого класса. 3. И, наконец, знак «-» обозначает атрибут с областью видимости типа «закрытый» (private). Атрибут с этой областью видимости недоступен или не виден для всех классов без исключения. Если квантор видимости не указан, это означает, что видимость атрибута не указывается. Рассмотрим варианты задания кратности атрибутов: 1. [0..1] означает, что кратность атрибута может принимать значение 0 или 1. При этом 0 означает отсутствие значения для данного атрибута. 2. [0..*] означает, что кратность атрибута может принимать любое положительное целое значение, большее или равное 0. Эта кратность может быть записана короче в виде простого символа — [*]. 3. [1.:*] означает, что кратность атрибута может принимать любое положительное целое значение, большее или равное 1. © geekbrains.ru 9 Тип атрибута представляет собой выражение, семантика которого определяется языком спецификации соответствующей модели. В нотации UML тип атрибута иногда определяется в зависимости от языка программирования, который предполагается использовать для реализации этой модели. Операция (operation) представляет собой некоторый сервис, предоставляющий каждый экземпляр класса по определённому требованию. Совокупность операций характеризует функциональный аспект поведения класса. Запись операций класса в языке UML также стандартизована и подчиняется определённым синтаксическим правилам. При этом каждой операции класса соответствует отдельная строка, которая состоит из квантора видимости операции, имени операции, выражения типа возвращаемого операцией значения и, возможно, строка-свойство этой операции. Отношения между классами Кроме внутреннего устройства или структуры классов на соответствующей диаграмме указываются различные отношения между классами. При этом совокупность типов таких отношений фиксирована в языке UML и предопределена семантикой этих типов отношений. Базовые отношения (связи) в языке UML: ● отношение зависимости (dependency relationship); ● отношение ассоциации (association relationship); ● отношение обобщения (generalization relationship); ● отношение реализации (realization relationship). Для начала, пока вы не определили детали, используйте отношение ассоциации. Отношение ассоциации соответствует наличию некоторого отношения между классами. Оно связывает в точности два класса и, как исключение, может связывать класс с самим собой. Отдельный класс ассоциации имеет собственную роль в отношении. Эта роль может быть изображена графически на диаграмме классов. С этой целью в языке UML вводится в рассмотрение специальный элемент — конец ассоциации (Association End), который графически соответствует точке соединения линии ассоциации с отдельным классом. Конец ассоциации — часть ассоциации, но не класса. Каждая ассоциация имеет два или больше концов ассоциации. Наиболее важные свойства ассоциации указываются на диаграмме рядом с этими элементами и должны перемещаться вместе с ними. Для любого отношения, кроме зависимости, принято указывать кратность отдельного класса. Кратность обозначается в виде интервала целых чисел, аналогично кратности атрибутов и операций классов. Интервал записывается рядом с концом ассоциации и для N-арной ассоциации означает потенциальное число отдельных экземпляров или значений кортежей этой ассоциации, которые могут иметь место, когда остальные N-1 экземпляров или значений классов фиксированы. Кратность для отношения определяется аналогично кратности атрибутов (см. выше). © geekbrains.ru 10 Отношение агрегации имеет место между несколькими классами в том случае, если один из классов представляет собой некоторую сущность, включающую в себя в качестве составных частей другие сущности. Отношение композиции — частный случай отношения агрегации. Это отношение служит для выделения специальной формы отношения «часть – целое», при которой составляющие части в некотором смысле находятся внутри целого. Специфика взаимосвязи между ними заключается в том, что части не могут выступать в отрыве от целого, то есть с уничтожением целого уничтожаются и все его составные части. Отношение обобщения (генерализации) — обычное таксономическое отношение между более общим элементом (родителем или предком) и более частным или специальным элементом (дочерним или потомком). Отношение зависимости в общем случае означает семантическое отношение между двумя элементами модели или двумя множествами элементов, которое не является отношением ассоциации, обобщения или реализации. Оно касается только самих элементов модели и не требует множества отдельных примеров для пояснения своего смысла. Отношение зависимости используется в такой ситуации, когда некоторое изменение одного элемента модели может потребовать изменения другого зависимого от него элемента. Диаграммы последовательностей Диаграммы последовательностей (sequence diagram) описывают отношения объектов в различных условиях. Это разновидность диаграмм взаимодействия языка UML, которая широко используется в качестве эскизов: например, на рабочих встречах при обсуждении задач по разработке информационных систем. Можно использовать диаграммы последовательностей при проектировании новых или при анализе и рефакторинге старых систем. На диаграмме последовательности неявно присутствует ось времени, что позволяет визуализировать временные отношения между передаваемыми сообщениями. © geekbrains.ru 11 Рисунок 5. Общая схема диаграммы последовательности Каждый объект графически изображается в виде прямоугольника и располагается в верхней части своей линии жизни. Внутри прямоугольника записываются собственное имя объекта со строчной буквы и имя класса, разделённые двоеточием. Крайним слева на диаграмме изображается объект-инициатор моделируемого процесса взаимодействия. Правее — другой объект, который непосредственно взаимодействует с первым. И так далее. Сообщения изображаются в виде горизонтальных стрелок с именем сообщения и образуют определённый порядок относительно времени своей инициализации. Другими словами, сообщения, расположенные на диаграмме последовательности выше, передаются раньше тех, которые расположены ниже. При этом масштаб на оси времени не указывается, поскольку диаграмма последовательности моделирует лишь временную упорядоченность взаимодействий типа «раньше/позже». Линия жизни объекта (object lifeline) — вертикальная линия на диаграмме последовательности, которая представляет существование объекта в течение определённого периода времени. Линия жизни объекта изображается пунктирной вертикальной линией, ассоциированной с единственным объектом на диаграмме последовательности. Линия жизни служит для обозначения периода времени, в течение которого объект существует в системе и, следовательно, может потенциально участвовать во всех её взаимодействиях. Фокус управления — вытянутый прямоугольник на линии жизни, указывающий период времени, в течение которого объект выполняет некоторое действие, находясь в активном состоянии. В отдельных случаях инициатором взаимодействия в системе может быть актёр или внешний пользователь. При этом актёр изображается на диаграмме последовательности самым первым объектом слева со своим фокусом управления. © geekbrains.ru 12 В отдельных случаях объект может посылать сообщения самому себе, инициируя так называемые рефлексивные сообщения. Они изображаются в форме сообщения, начало и конец которого соприкасаются с линией жизни или фокусом управления одного и того же объекта. Подобные ситуации возникают, например, при обработке нажатий на клавиши клавиатуры при вводе текста в редактируемый документ. На диаграммах последовательности могут присутствовать три разновидности сообщений, каждое из которых имеет свое графическое изображение. Рисунок 6. Графическое изображение различных видов сообщений между объектами на диаграмме последовательности Типы сообщений 1. Синхронные сообщения используются для вызова процедур, выполнения операций или обозначения отдельных вложенных потоков управления. Отправитель сообщения не может совершать действий, пока не будет получен ответ на отправленное сообщение. 2. Асинхронные сообщения — передача такого сообщения обычно не сопровождается получением фокуса управления объектом-получателем. 3. Ответное сообщение (reply) используется для возврата из вызова процедуры. Примером может служить простое сообщение о завершении вычислений без предоставления результата расчётов объекту-клиенту. В процедурных потоках управления эта стрелка может быть опущена, поскольку её наличие неявно предполагается в конце активизации объекта. В то же время считается, что каждый вызов процедуры имеет свою пару — возврат вызова. 4. Найденное сообщение (found message) — у первого сообщения нет участника, пославшего его, поскольку оно приходит из неизвестного источника. 5. Потерянное сообщение (lost message) — сообщение, для которого существует событие передачи и отсутствует событие приёма. Изображается в форме небольшого чёрного круга на конце стрелки сообщения. Оно интерпретируется как сообщение, которое никогда не достигнет своего места назначения. © geekbrains.ru 13 Правила построения диаграмм последовательностей 1. Для начала выделите все объекты, участвующие во взаимодействии, расположите их в порядке инициации, далее переходите к визуализации сообщений между объектами. 2. Помните, что диаграмма должна оставаться читаемой. 3. Чрезмерное ветвление использовать не рекомендуется, так как для изображения деталей алгоритмов в языке UML есть диаграммы деятельности. Общее правило — визуализация каждого потока управления на отдельной диаграмме последовательности. Фреймы взаимодействия На рисунке ниже отображён более сложный вариант диаграммы последовательностей, на котором показаны фреймы взаимодействия. Каждый фрейм представляет собой разделённую на несколько фрагментов область диаграммы, причём каждый фрейм имеет оператор для обозначения условной логики. Рисунок 7. Пример отображения фреймов взаимодействия 1. alt — несколько альтернативных фрагментов (alternative). Выполняется только тот фрагмент, условие которого истинно. 2. opt — необязательный (optional) фрагмент. Выполняется, только если условие истинно. Эквивалентен alt с одной веткой. © geekbrains.ru 14 3. par — параллельный (parallel). Все фрагменты выполняются параллельно. Например, система уведомляет параллельно всех трёх подписчиков и все они параллельно и независимо друг от друга начинают работать. 4. loop — цикл (loop). Фрагмент может выполняться несколько раз. 5. region — критическая область (critical region). Фрагмент может иметь только один поток, выполняющийся за один приём. 6. neg — отрицательный (negative) фрагмент. Обозначает неверное взаимодействие. 7. ref — ссылка (reference). Ссылается на взаимодействие, определённое на другой диаграмме. Фрейм рисуют, чтобы охватить линии жизни, вовлечённые во взаимодействие. Можно определять параметры и возвращать значение. Фрейм ref может показывать предусловия, то есть требования, которые должны быть выполнены для начала выполнения действий. 8. sd — диаграмма последовательности (sequence diagram). Используется для очерчивания всей диаграммы последовательности, если это необходимо. Рисунок 8. Пример построения диаграммы последовательностей © geekbrains.ru 15 Практическое задание Кейс: вы устроились аналитиком в крупную страховую компанию. Страховая компания внедряет программное обеспечение для автоматизации процесса обработки обращений от клиентов. Каждое обращение рассматривается, и на основе определённых правил принимается решение о размере возмещения по данному обращению. 1. Выделите главные сущности описанного кейса. 2. В удобном вам инструменте нарисуйте диаграмму классов на языке UML. На диаграмме должно быть не менее 3 классов, атрибуты и операции этих классов, должны быть определены отношения между классами, кратность. 3. В удобном вам инструменте нарисуйте диаграмму последовательности на языке UML. На диаграмме должно быть не менее 3 взаимодействующих объектов. Глоссарий Диаграмма классов (class diagram) — вид диаграммы, описывающий типы объектов системы и различного рода статические отношения между ними. На диаграммах классов отображаются также свойства классов, операции классов и ограничения, которые накладываются на связи между объектами. Диаграмма последовательности (sequence diagram) — вид диаграммы, используемый для представления временных особенностей передачи и приёма сообщений между объектами. Объектно-ориентированный анализ — метод анализа, исследующий требования к системе с точки зрения классов и объектов, относящихся к словарю предметной области. Унифицированный процесс (UP, Unified Process) — универсальный процесс разработки ПО, который должен настраиваться для определённой организации и для каждого конкретного проекта. Унифицированный язык моделирования (Unified Modeling Language) — язык визуального моделирования, чаще всего используемый для ОО-анализа. Основная идея UML — возможность моделировать программное обеспечение и другие системы как наборы взаимодействующих объектов. CASE-средства (Computer-Aided Software Engineering) — это методы и технологии, которые позволяют проектировать различные информационные системы и автоматизировать их создание. MDA (Model Driven Architecture) — архитектура, управляемая моделью, — подход, предполагающий генерацию программного кода на основе моделей системы. © geekbrains.ru 16 Используемые источники 1. Фаулер M. «UML. Основы», 3-е изд. 2. Буч Гради «Объектно-ориентированный анализ и проектирование с примерами приложений», 3-е изд. 3. Новиков Ф. А. «Учебно-методическое пособие по дисциплине «Анализ и проектирование на UML» 2007 г. 4. К. Ларман «Применение UML и шаблонов проектирования», 2-е или 3-е изд. 5. Арлоу Д., Нейштадт А. «UML 2 и унифицированный процесс. Практический объектно-ориентированный анализ и проектирование», 2-е изд. 6. Мухортов В. В., Рылов В. Ю. «Объектно-ориентированное программирование, анализ и дизайн. Методическое пособие». 7. James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and William Premerlani, Frederick Eddy, and William Lorenson, Object-Oriented Modeling and Design, Lorenson, Object-Oriented Modeling and Design, Prentice Hall, 1991. 8. Леоненков В. А. «Самоучитель UML» 2-е изд. 9. OMG Unified Modeling Language Specification, version 2.0. 10. Эрик Фримен, Элизабет Фримен, Кэтти Сьерра, Берт Бейтс «Паттерны проектирования» (Head First Design Patterns: A Brain-Friendly Guide), 2018. 11. BABOK v3 Guide. © geekbrains.ru 17