Объектно-ориентированный язык UML Унифицированный язык моделирования (Unified Modeling Language, UML)
UML UML - Uniform (Унифицированный) Modeling (Язык) Language (Моделирования). UML является визуальным языком моделирования, который позволяет системным архитекторам представлять своё видение системы в стандартной и лёгкой для понимания форме. UML предоставляет эффективный механизм совместного использования проектных решений и взаимодействия разработчиков друг с другом. Карякин Иван Юрьевич 2
Терминология Диаграмма - графическое изображение элементов и связи между ними. Система - комбинация программных и аппаратных средств, которые обеспечивают выполнение поставленной задачи. Разработка системы представляет собой процесс её создания для клиента, т. е человека которому необходимо решить какую-то проблему. Карякин Иван Юрьевич 3
Польза UML Аналитик разрабатывает документы с описанием этой проблемы и передаёт их разработчикам программистам, которые создают программное обеспечение для решения требуемой задачи и гарантируют его развёртывание на аппаратных средствах. Ключевым аспектом процесса проектирования является его правильная организация, когда аналитики, клиенты, программисты и другие специалисты, участвующие в разработке системы, способны понять друга и прийти к общему мнению. Карякин Иван Юрьевич 4
Краткая история Авторами UML являются Grady Booch, James Rumbaugh & Ivar Jacobson. В 80 -х, в начале 90 -х они независимо друг от друга придумывали методологии объектно-ориентированного анализа и проектирования. В 94 -95 годах они втроём оказались в Rational Software Corporation. В конце 1997 года вышла версия 1. 0. После этого группа OMG приступила к сопровождению и выпустила в конце 1988 года его две новые версии. Язык UML стал стандартом де-факто в области разработки программного обеспечения. В настоящее время язык продолжает активно развиваться. В 2002 году вышла версия 2. 0, которая считается текущей. Карякин Иван Юрьевич 5
Авторы языка UML Карякин Иван Юрьевич 6
Четыре основных принципа моделирования 1. Выбор модели оказывает определяющее влияние на подход к решению проблемы и на то, как будет выглядеть это решение. 2. Каждая модель может быть воплощена с разной степенью абстракции. 3. Лучшие модели те, что ближе к реальности 4. Нельзя ограничиваться созданием только одной модели. Наилучший подход при разработке любой нетривиальной системы использовать совокупность нескольких моделей, почти независимых друг от друга. Карякин Иван Юрьевич 7
Выбор модели определяет решение Правильно выбранная модель высветит самые коварные проблемы разработки и позволит проникнуть в самую суть задачи, что при ином подходе было бы попросту невозможно. Неправильная модель заведет вас в тупик, поскольку внимание будет заостряться на несущественных вопросах. Разработчик баз данных основное внимание уделяет моделям «сущность связь» , Структурный аналитик – DFD моделям. Специалист, использующий объектно ориентированный метод создает систему, архитектура которой основана на множестве классов и образцах взаимодействия. Карякин Иван Юрьевич 8
Разная степенью абстракции модели Лучшей моделью будет та, которая позволяет выбрать уровень детализации в зависимости от того, кто и с какой целью на нее смотрит. Для аналитика или конечного пользователя наибольший интерес представляет вопрос «что» , а для разработчика вопрос «как» . В обоих случаях необходима возможность рассматривать систему на разных уровнях детализации в разное время. Карякин Иван Юрьевич 9
Лучшие модели - те, что ближе к реальности «Ахиллесова пята» структурного анализа несоответствие принятой в нем модели и модели системного проекта. Если этот разрыв не будет устранен, то поведение созданной системы с течением времени начнет все больше отличаться от задуманного. При объектно ориентированном подходе можно объединить все почти независимые представления системы в единое семантическое целое. Карякин Иван Юрьевич 10
Создавайте несколько независимых моделей Для понимания архитектуры объектно ориентированных систем требуется несколько взаимодополняющих видов: вид с точки зрения прецедентов, или вариантов использования (чтобы выявить требования к системе), с точки зрения проектирования (чтобы построить словарь предметной области и области решения), с точки зрения процессов (чтобы смоделировать распределение процессов и потоков в системе), вид с точки зрения реализации, позволяющий рассмотреть физическую реализацию системы, вид с точки зрения развертывания, помогающий сосредоточиться на вопросах системного проектирования. Карякин Иван Юрьевич 11
Объектно-ориентированное моделирование Основной строительный блок объект или класс. Объект это сущность, обычно извлекаемая из словаря предметной области или решения. Класс является объектов. Каждый объект обладает идентичностью, состоянием и поведением. Визуализация, специфицирование, конструирование и документирование объектно ориентированных систем это и есть назначение языка UML. описанием множества Карякин Иван Юрьевич однотипных 12
Назначение UML Моделирование информационных систем: от информационных систем масштаба предприятия до распределенных Web приложений и даже встроенных систем реального времени. Это выразительный язык, позволяющий рассмотреть систему со всех точек зрения, имеющих отношение к ее разработке и последующему развертыванию. UML это язык для визуализации, специфицирования, конструирования и документирования артефактов программных систем. Карякин Иван Юрьевич 13
Особенности языка Словарь и правила языка (UML) объясняют, как создавать и читать хорошо определенные модели, но ничего не сообщают о том, какие модели и в каких случаях нужно создавать. Это задача всего процесса разработки программного обеспечения. Хорошо организованный процесс должен подсказать вам, какие требуются артефакты, какие ресурсы необходимы для их создания, как можно использовать эти артефакты, чтобы оценить выполненную работу и управлять проектом в целом. Карякин Иван Юрьевич 14
UML- язык визуализации При разработке проектов компаниям приходится изобретать собственные языки; новичку это непросто. Нельзя получить представление об определенных аспектах программных систем без модели, выходящей за границы текстового языка программирования. Если автор кода никогда не воплощал в явной форме задуманные им модели, эта информация будет навсегда утрачена, если он сменит место работы. Карякин Иван Юрьевич 15
Графические символы UML За каждым символом стоит хорошо определенная семантика (описанных в "The Unified Modeling Language Reference Manual"). Это значит, что модель, написанная одним разработчиком, может быть однозначно интерпретирована другим или даже инструментальной программой. Карякин Иван Юрьевич 16
UML - это язык cпецифицирования Построение точных, недвусмысленных и полных моделей. UML позволяет специфицировать все существенные решения, касающиеся анализа, проектирования и реализации, которые должны приниматься в процессе разработки и развертывания системы программного обеспечения. Карякин Иван Юрьевич 17
UML - это язык конструирования Модели, созданные с его помощью, могут быть непосредственно переведены на различные языки программирования. Можно решить и обратную задачу: реконструировать модель по имеющейся реализации. Сочетание прямой генерации кода и обратного проектирования позволяет работать как в графическом, так и в текстовом представлении, если инструментальные программы обеспечивают согласованность между обоими представлениями. UML позволяет непосредственно исполнять модели, имитировать поведение систем и контролировать действующие системы. Карякин Иван Юрьевич 18
UML - это язык документирования UML позволяет решить проблему документирования системной архитектуры и всех ее деталей, предлагает язык для формулирования требований к системе и определения тестов и предоставляет средства для моделирования работ на этапе планирования проекта и управления версиями: требования к системе; архитектура; проект; исходный код; проектные планы; тесты; прототипы; версии, и др Карякин Иван Юрьевич 19
Использование UML информационные системы масштаба предприятия; банковские и финансовые услуги; телекоммуникации; транспорт; оборонная промышленность, авиация и космонавтика; розничная торговля; медицинская электроника; наука; распределенные Web системы. Карякин Иван Юрьевич 20
Концептуальная модель UML Включает в себя три составные части: основные строительные блоки языка, правила их сочетания, некоторые общие для всего языка механизмы. Карякин Иван Юрьевич 21
Строительные блоки UML Словарь языка UML включает три вида строительных блоков: сущности; отношения; диаграммы. Карякин Иван Юрьевич 22
Сущности Это абстракции, являющиеся основными элементами модели. Отношения связывают различные сущности; диаграммы группируют представляющие интерес совокупности сущностей В UML имеется четыре типа сущностей: структурные; поведенческие; группирующие; аннотационные. Карякин Иван Юрьевич 23
Структурные сущности это имена существительные в моделях на языке UML. Как правило, они представляют собой статические части модели, соответствующие концептуальным или физическим элементам системы: Классы (Class) Интерфейс (Interface) Кооперация (Collaboration) Прецедент (Use Case) Активный класс (Active class) Компонент (Component) Узел (Node) Карякин Иван Юрьевич 24
Классы(Class) Класс (Class) это описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой. Класс реализует один или несколько интерфейсов. Карякин Иван Юрьевич 25
Интерфейс (Interface) Интерфейс это совокупность операций, которые определяют сервис (набор услуг), предоставляемый классом или компонентом Описывает видимое извне поведение элемента. Может представлять поведение класса или компонента полностью или частично; он определяет только спецификации операций (сигнатуры), но не реализаций. Карякин Иван Юрьевич 26
Кооперация (Collaboration) Определяет взаимодействие. Она представляет собой совокупность ролей и других элементов, которые, работая совместно, производят некоторый кооперативный эффект, не сводящийся к простой сумме слагаемых. Кооперация имеет как структурный, так и поведенческий аспект. Один и тот же класс может принимать участие в нескольких кооперациях; таким образом, они являются реализацией образцов поведения формирующих систему. Карякин Иван Юрьевич 27
Прецедент (Use case) Описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого то определенного актера (Actor), Прецедент применяется для структурирования поведенческих сущностей Модели. Прецеденты реализуются посредством кооперации. Карякин Иван Юрьевич 28
Активный класс (Active class) Активный класс, объекты которого вовлечены в один или несколько процессов, или нитей (Threads), и поэтому могут инициировать управляющее воздействие. Активный класс во всем подобен обычному классу, за исключением того, что его объекты представляют собой элементы, деятельность которых осуществляется одновременно с деятельностью других элементов. Карякин Иван Юрьевич 29
Компонент (Component)) Это физическая заменяемая часть системы, которая соответствует некоторому набору интерфейсов и обеспечивает его реализацию. В системе можно встретить различные виды устанавливаемых компонентов, такие как СОМ+ или Java Beans, а также компоненты, являющиеся артефактами процесса разработки, например файлы исходного кода. Компонент, как правило, представляет собой физическую упаковку, логических элементов, таких как классы, интерфейсы и кооперации. Карякин Иван Юрьевич 30
Узел (Node) Это элемент реальной (физической) системы, который существует во время функционирования программного комплекса и представляет собой вычислительный ресурс, обычно обладающий как минимум некоторым объемом памяти, а часто еще и способностью обработки. Совокупность компонентов может размещаться в узле, а также мигрировать с одного узла на другой. Карякин Иван Юрьевич 31
Разновидности структурных сущностей Классы: актеры; сигналы; утилиты. Активные классы: процессы; нити (виды). Компоненты приложения; документы; файлы; библиотеки; страницы; таблицы. Карякин Иван Юрьевич 32
Поведенческие сущности (Behavioral things) Динамические составляющие модели UML. Это глаголы языка: они описывают поведение модели во времени и пространстве. Два основных типа поведенческих сущностей: Взаимодействие (Interaction) Автомат (State machine) Семантически они часто бывают связаны с различными структурными элементами, в первую очередь классами, кооперациями и объектами. Карякин Иван Юрьевич 33
Взаимодействие (Interaction) Это поведение, суть которого заключается в обмене сообщениями (Messages) между объектами в рамках конкретного контекста для достижения определенной цели. С помощью взаимодействия можно описать как отдельную операцию, так и поведение совокупности объектов. Взаимодействие предполагает ряд других элементов, таких как сообщения, последовательности действий (поведение, инициированное сообщением) и связи (между объектами). Карякин Иван Юрьевич 34
Автомат (State machine) Алгоритм поведения, определяющий последовательность состояний, через которые объект или взаимодействие проходят на протяжении своего жизненного цикла в ответ на различные события, а также реакции на эти события. С помощью автомата можно описать поведение отдельного класса или кооперации классов. С автоматом связан ряд других элементов: состояния, переходы (из одного состояния в другое), события (сущности, инициирующие переходы) и виды действий (реакция на переход) Карякин Иван Юрьевич 35
Группирующие сущности Организующая часть модели UML. Это блоки, на которые можно разложить модель. Есть только одна первичная группирующая сущность, а именно пакет. Пакеты (Packages) представляют собой универсальный механизм организации элементов в группы. В пакет можно поместить структурные, поведенческие и даже другие группирующие сущности. В отличие от компонентов, существующих во время работы программы, пакеты носят чисто концептуальный характер, то есть существуют только во время разработки. Существуют также вариации пакетов, например каркасы (Frameworks), модели и подсистемы Карякин Иван Юрьевич 36
Аннотационные сущности Пояснительные части модели UML Это комментарий для дополнительного описания, разъяснения или замечания к любому элементу модели. Имеется только один базовый тип аннотационных элементов примечание (Note). Существуют вариации этого элемента, например требования (requirement ), где описывают некое желательное поведение с точки зрения внешней по отношению к модели. Карякин Иван Юрьевич 37
Отношения Основные связующие строительные блоки в UML и применяются для создания корректных моделей. Основные типы отношений: зависимость; ассоциация; обобщение реализация. Дополнительные типы отношений: уточнение (Refinement), трассировка (Trace), включение и расширение (для зависимостей) Карякин Иван Юрьевич 38
Зависимость (Dependency) Семантическое отношение между двумя сущностями, при котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой. Карякин Иван Юрьевич 39
Ассоциация Структурное отношение, описывающее совокупность связей; связь это соединение между объектами. Разновидностью ассоциаций является агрегирование (Aggregation) так называют структурное отношение между целым и его частями. имена ролей агрегирование кратность Карякин Иван Юрьевич 40
Обобщение (Generalization) Отношение «специализация/обобщение» , при котором объект специализированного элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (родителя или предка) Таким образом, потомок (Child) наследует структуру и поведение своего родителя (Parent). Карякин Иван Юрьевич 41
Реализация (Realization) Семантическое отношение между классификаторами, при котором один классификатор определяет «контракт» , а другой гарантирует его выполнение. Отношения реализации встречаются в двух случаях: между интерфейсами и реализующими их классами или компонентами, между прецедентами и реализующими их кооперациями. Карякин Иван Юрьевич 42
Реализация (Realization) Create a realizes relationship between two elements In a static structure diagram, right click any class shape (Class, Parameterized Class, Utility or Meta. Class), click Shape Display Options, and then, under General Options, select Realization Link. Glue the control handle for the realization link on a class shape to a connection point on the interface, class, or other element. Карякин Иван Юрьевич 43
Диаграммы Графическое представление набора элементов, изображаемое чаще всего в виде связанного графа с вершинами; (сущностями) и ребрами (отношениями). Диаграммы рисуют для визуализаций системы с разных точек зрения (проекция системы). Как правило диаграммы дают свернутое представление элементов, из которых составлена система. Карякин Иван Юрьевич 44
Виды диаграмм действий; кооперации; компонентов; развертывания. последовательностей; состояний; классов + объектов = статические прецедентов Карякин Иван Юрьевич 45
Диаграмма классов (Use Static Structure) На диаграмме показывают классы, интерфейсы, объекты и кооперации, а также их отношения. При моделировании объектно ориентированных систем этот тип диаграмм используют чаще всего. Диаграммы классов соответствуют статическому виду системы с точки зрения проектирования. Диаграммы классов, которые включают активные классы, соответствуют статическому виду системы с точки зрения процессов. Карякин Иван Юрьевич 46
Диаграмма объектов (Use Static Structure) На диаграмме представлены объекты и отношения между ними. Они являются статическими «фотографиями» экземпляров сущностей, показанных на диаграммах классов. Относится к статическому виду системы с точки зрения проектирования или процессов, но с расчетом на настоящую или макетную реализацию. Карякин Иван Юрьевич 47
Диаграмма прецедентов (Use Case) На диаграмме представлены прецеденты и актеры (частный случай классов), а также отношения между ними. Относится к статическому виду системы с точки зрения прецедентов использования. Важна при организации и моделировании поведения системы. Карякин Иван Юрьевич 48
Диаграммы последовательностей (Use Sequence) и кооперации (Use Collaboration) Частный случай диаграмм взаимодействия. Диаграммы взаимодействия относятся к динамическому виду системы. Диаграммы последовательности отражают временную упорядоченность сообщений. Диаграммы кооперации структурную обменивающихся сообщениями объектов. Эти диаграммы являются изоморфными, то есть могут быть преобразованы друг в друга. Карякин Иван Юрьевич организацию 49
Диаграммы состояний (Statechart diagrams) На диаграммах представлен автомат, включающий в себя состояния, переходы, события и виды действий. Диаграммы состояний относятся к динамическому виду системы. Важны при моделировании класса или кооперации. Акцентируют внимание на поведении объекта, зависящем от последовательности событий (для моделирования реактивных систем). поведения Карякин Иван Юрьевич интерфейса, 50
Диаграмма деятельности (Activity) Частный случай диаграммы состояний. Представлены переходы потока управления от одной деятельности к другой внутри системы. Относятся к динамическому виду системы. Важны при моделировании ее функционирования и отражают поток управления между объектами. Карякин Иван Юрьевич 51
Диаграмма компонентов (Component) Представлена организация совокупности компонентов и существующие между ними зависимости. Относятся к статическому виду системы с точки зрения реализации. Могут быть соотнесены с диаграммами классов, так компонент обычно отображается на один или несколько классов, интерфейсов или коопераций. Карякин Иван Юрьевич 52
Диаграмма развертывания (Deployment) Представлена конфигурация обрабатывающих системы и размещенных в них компонентов. Относятся к статическому виду архитектуры системы с точки зрения развертывания. Связаны с диаграммами компонентов, поскольку в узле обычно размещаются один или несколько компонентов. Карякин Иван Юрьевич узлов 53
Семантические правила определяют: имена, которые можно давать сущностям, отношениям и диаграммам; область действия (контекст, в котором имя имеет некоторое значение); видимость (когда имена видимы и могут использоваться другими элементами); целостность (как элементы должны правильно и согласованно соотноситься друг с другом); выполнение (что значит выполнить или имитировать некоторую динамическую модель). Карякин Иван Юрьевич 54
Не «хорошие» модели содержат скрытые элементы (ряд элементов не показывают, чтобы упростит: восприятие); неполные (отдельные элементы пропущены); несогласованные (целостность модели не гарантируется). Карякин Иван Юрьевич 55
Общие механизмы языка спецификации (Specifications); дополнения (Adornments); принятые деления (Common divisions); механизмы расширения (Extensibility mechanisms). Карякин Иван Юрьевич 56
Спецификации UML это не просто графический язык. За каждой частью его системы графической нотации стоит спецификация, содержащая текстовое представление синтаксиса и семантики соответствующего строительного блока. Карякин Иван Юрьевич 57
Механизмы расширения Стереотипы Стереотип (Stereotype) расширяет словарь UML, позволяя на основе существующих блоков языка создавать новые, специфичные для решения конкретной проблемы. Помеченные значения Помеченное значение (Tagged value) расширяет свойства строительных блоков UML, позволяя включать новую информацию в спецификацию элемента. Ограничения (Constraints) расширяют семантику строительных блоков UML, позволяя определять новые или изменять существующие правила. Карякин Иван Юрьевич 58
Архитектура Это совокупность существенных решений: организации программной системы; выбора структурных элементов, составляющих систему, и их интерфейсов; поведения этих элементов, специфицированного в кооперациях с другими элементами; составления из этих структурных и поведенческих элементов все более и бо лее крупных подсистем; архитектурного стиля, направляющего и определяющего всю организацию системы: статические и динамические элементы, их интерфейсы, кооперации и способ их объединения. Карякин Иван Юрьевич 59
Моделирование системной архитектуры Карякин Иван Юрьевич 60
Жизненный цикл разработки ПО UML не зависите от организации процесса разработки, не привязан к какому либо конкретному циклу изготовления программного продукта. Рекомендуется применять процессы: управляемые прецедентами использования; основанными на архитектуре; являющимися итеративными и инкрементными. Карякин Иван Юрьевич 61
Управляемость прецедентами использования Прецеденты должны быть основным артефактом, на основании которого: устанавливается желаемое поведение системы, проверяется и подтверждается правильность выбранной системной архитектуры, производится тестирование, осуществляется взаимодействие между участниками проекта. Карякин Иван Юрьевич 62
Процесс основан на архитектуре Системная архитектура является решающим фактором при разработке концепций, конструировании, управлении, развитии создаваемой системы. Карякин Иван Юрьевич 63
Процессы итеративные и инкрементные Итеративным предполагает исполняемых версий системы. управление Инкрементный подразумевает постоянное развитие системной архитектуры при выпуске новых версий, причем каждая следующая версия усовершенствована в сравнении с предыдущей. Процесс, являющийся одновременно итеративным и инкрементным, называется управляемым рисками (в каждой новой версии серьезное внимание уделяется выявлению факторов, представляющих наибольший риск для успешного завершения проекта, и сведению их до минимума). Карякин Иван Юрьевич потоком 64
Жизненный цикл разработки ПО Карякин Иван Юрьевич 65
Скачать презентацию Объектно-ориентированный язык UML Унифицированный язык моделирования Unified Modeling
1 Объектно ориентированный язык UML.pptx