Информационные системы Лекция 3 Унифицированный язык визуального

Информационные системы Лекция № 3 Унифицированный язык визуального моделирования Unified Modeling Language (UML)

Так объяснил заказчик…

Так понял лидер проекта…

Так спроектировал аналитик…

Так реализовал программист…

Так описал бизнес консультант…

Так проект был документирован!

Так продукт был проинсталлирован…

Такой счет был выставлен заказчику…

Так осуществлялась техническая поддержка…

А вот чего на самом деле хотелось заказчику!!!

Программистам нужен был универсальный язык… Все шло к созданию единого языка, который объединял бы сильные стороны известных методов и обеспечивал наилучшую поддержку моделирования. Таким языком оказался UML. Создание UML началось в октябре 1994 г. , когда Джим Рамбо и Гради Буч из Rational Software Corporation стали работать над объединением своих методов OMT и Booch.

UML в первую очередь спецификации. Спецификация - подробное описание системы, которое полностью определяет ее цель и функциональные возможности. Различают: словесные спецификации на естественном языке; модельные спецификации; формальные спецификации.

Картинки с подписями наглядны и интуитивно понятны

Подводя итоги… UML можно использовать для рисования картинок, которые можно использовать для коммуникаций внутри команды и в ходе взаимодействия с заказчиком. UML является отличным средством спецификации систем, причем спецификации в процессе разработки. Разработанные архитектурные решения, задокументированные с помощью UML, могут быть использованы повторно!

Для чего UML использовать нельзя Во-первых, UML не является языком программирования. Во-вторых, UML не является и спецификацией какого бы то ни было инструмента моделирования, хотя такие инструменты (и в больших количествах) имеются. Borland Together, Poseidon, Enterprise Architect, IBM Rational Rose, Dia, Visio и др. В-третьих, UML не является и моделью какого-либо процесса разработки. UML можно использовать независимо от того, какую методологию разработки ПО вы используете, и даже если вы вообще не пользуетесь никакой методологией!

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

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

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

Диаграмма прецедентов (use case diagram) Эктор (actor) - это множество логически связанных ролей. Эктором может быть человек или другая система, подсистема или класс, которые представляют нечто вне сущности. Прецедент (use case) - описание множества последовательных событий, которые приводят к наблюдаемому эктором результату. Прецедент не показывает, "как" достигается некоторый результат, а только "что" именно выполняется.

ПРЕЦЕДЕНТ – кто он!? Для включения в диаграмму выбранные прецеденты должны удовлетворять следующим критериям: прецедент должен описывать, ЧТО нужно делать, а не КАК; прецедент должен описывать действия с точки зрения ИСПОЛНИТЕЛЯ; прецедент должен возвращать исполнителю некоторое СООБЩЕНИЕ; последовательность действий внутри прецедента должна представлять собой одну НЕДЕЛИМУЮ цепочку.

Виды отношений между актерами и вариантами использования: ассоциации (association relationship) включения (include relationship) расширения (extend relationship) обобщения (generalization relationship)

Включение (include) в языке UML При этом отношением зависимости (dependency) является такое отношение между двумя элементами модели, при котором изменение одного элемента (независимого) приводит к изменению другого элемента (зависимого).

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

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

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

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

Цели создания диаграмм прецедентов: определение границы и контекста моделируемой предметной области на ранних этапах проектирования; формирование общих требований к поведению проектируемой системы; разработка концептуальной модели системы для ее последующей детализации; подготовка документации для взаимодействия с заказчиками и пользователями системы.

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

В качестве бизнес-актера данной системы можно рассматривать покупателя супермаркета, а в качестве сотрудника – продавца.

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

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

Отношения "обобщение-специализация" В рамках рассматриваемой системы продажи товаров может иметь самостоятельное значение и специфические особенности отдельная категория товаров — телевизоры.

Диаграмма классов (class diagram) Классы — это базовые элементы любой объектноориентированной системы. Классы представляют собой описание совокупностей однородных объектов с присущими им свойствами — атрибутами, операциями, отношениями и семантикой.

Синтаксис UML для свойств классов Видимость свойства указывает на возможность его использования другими классами. Один класс может "видеть" другой, если тот находится в области действия первого и между ними существует явное или неявное отношение. В языке UML определены три уровня видимости: public (общий) — любой внешний класс, который "видит" данный, может пользоваться его общими свойствами. Обозначаются знаком "+" перед именем атрибута или операции; protected (защищенный) — только любой потомок данного класса может пользоваться его защищенными свойствами. Обозначаются знаком "#"; private (закрытый) — только данный класс может пользоваться этими свойствами. Обозначаются символом "-".

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

Отображение связей между классами

Зависимостью называется отношение использования, согласно которому изменение в спецификации одного элемента (например, класса "товар") может повлиять на использующий его элемент (класс "строка заказа"). Часто зависимости показывают, что один класс использует другой в качестве аргумента.

Отображение связей между классами

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

Отображение связей между классами

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

Отображение связей между классами

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

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

Рефлексивное сообщение Так рисуют, если нужно показать действие, выполняемое самим объектом (или внутри него), либо то, что объект сам себя вводит в некоторое состояние

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

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

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

Разработка моделей базы данных и приложений На этом этапе осуществляется отображение элементов полученных ранее моделей классов в элементы моделей базы данных и приложений: классы отображаются в таблицы; атрибуты – в столбцы; типы – в типы данных используемой СУБД; ассоциации – в связи между таблицами (ассоциации "многие-комногим" преобразуются в ассоциации "один-ко-многим" посредством создания дополнительных таблиц связей); приложения – в отдельные классы с окончательно определенными и связанными с данными в базе методами и атрибутами.

Главное знать меру…