Слайд 2Литература
Буч Г., Рамбо Д., Якобсон А. Язык UML. Руководство пользователя.
Второе издание. ДМК, 2006, 496 с.
Максимчук Роберт А., Нейбург Эрик
Дж. UML для простых смертных. М., Лори, 2008, 268 с.
Мартин Фаулер.UML.Основы, 3-е изд. С-Пб. СИМВОЛ-ПЛЮС,2005,-192с.
Слайд 3Язык - система знаков, служащая:
средством человеческого общения и мыслительной
деятельности;
способом выражения самосознания личности;
средством хранения и передачи информации.
Язык
включает в себя:
набор знаков (словарь)
правила их употребления и интерпретации (грамматику).
Языки бывают естественные и искусственные, формальные и неформальные. UML - язык формальный и искусственный.
Слайд 4При описании формального искусственного языка описываются такие его элементы, как:
синтаксис, то есть определение правил построения конструкций языка;
семантика, то
есть определение правил, в соответствии с которыми конструкции языка приобретают смысловое значение;
прагматика, то есть определение правил использования конструкций языка для достижения нужных нам целей.
Слайд 5Методологии, от которых произошел UML
метод Буча был хорош в проектировании,
но слабоват в анализе.
OMT Румбаха был, наоборот, отличным средством анализа,
но плох в проектировании.
Objectory Якобсона был действительно хорош с точки зрения user experience, на который ни метод Буча, ни OMT не обращали особого внимания. Основной идеей Objectory было то, что анализ должен начинаться с прецедентов, а не с диаграммы классов, которые должны быть производными от них.
Слайд 7UML в первую очередь - это спецификации.
Спецификация - подробное
описание системы, которое полностью определяет ее цель и функциональные возможности.
Различают:
словесные спецификации на естественном языке;
модельные спецификации;
формальные спецификации.
Слайд 8Чем UML не является.
Во-первых, UML не является языком программирования. UML
- средство не программирования, а моделирования, т. е. создания не
программ, а моделей любого уровня абстракции для систем из любой предметной области.
Во-вторых, UML не является и спецификацией какого бы то ни было инструмента моделирования, хотя такие инструменты (и в больших количествах) имеются. Например, TAU G2, Borland Together, Poseidon, Enterprise Architect, IBM Rational Rose, Dia, Visio и др.
В-третьих, UML не является и моделью какого-либо процесса разработки.
Слайд 9Элементы нотации (синтаксиса)
в UML используется четыре вида элементов нотации:
Фигуры (используются
"плоские" - прямоугольники, эллипсы, ромбы и т. д., но есть
одно исключение - на диаграмме развертывания для обозначения узлов инфраструктуры применяется "трехмерное" изображение параллелепипеда) ,
Линии (своими концами они должны соединяться с фигурами; применяется два типа линий - сплошная и пунктирная; линии могут пересекаться, и хотя таких случаев следует по возможности избегать),
значки,
надписи.
Слайд 10UML – стандартный язык для создания моделей на этапах анализа
и проектирования ПС
UML - еще один формальный язык, который необходимо
освоить каждому, кто собирается заниматься программной инженерией.
Знание UML не гарантирует построения разумных и понятных моделей, хотя и является для этого необходимым.
UML предоставляет огромную свободу при рисовании диаграмм и выборе инструмента рисования.
Словарь UML образуют три разновидности строительных блоков: предметы (сущности), отношения и диаграммы. Предметы – это абстракции, которые являются основными элементами в модели. Отношения связывают эти предметы. Связанные между собой предметы образуют диаграммы.
Слайд 11Способы использования UML
Рисование картинок. Графические средства UML можно и нужно
использовать безотносительно ко всему остальному. Даже рисование диаграмм карандашом на
бумаге позволяет упорядочить мысли и зафиксировать для себя существенную информацию о моделируемом приложении или иной системе.
Обмен информацией. Сообщество людей, применяющих и понимающих UML, стремительно растет. Если вы будете использовать UML, то вас будут понимать другие, и вы будете понимать других "с полувзгляда".
Спецификация систем. Это важнейший способ использования UML. И хотя не во всех случаях UML оказывается абсолютно адекватным средством спецификации, мы надеемся, что по мере развития языка все меньше будет оставаться таких исключений, где UML неприменим.
Слайд 12Способы использования UML
Повторное использование архитектурных решений. Повторное использование ранее разработанных
решений — ключ к повышению эффективности. К сожалению, модели UML
пока что повторно используются в весьма ограниченных масштабах.
Генерация кода. Генерировать код нужно и можно, но возможности имеющихся инструментов не стоит переоценивать.
Имитационное моделирование. Возможности построения моделей UML, из которых путем вычислительных экспериментов можно было бы извлекать информацию о моделируемом объекте, пока что уступают возможностям специализированных систем, сконструированных для этих целей.
Верификация моделей. Было бы замечательно, если бы по модели можно было бы делать формальные заключения об ее свойствах: модель непротиворечива, согласована, эффективна и т. п. Кое-что UML позволяет проверить, но, конечно, очень мало. Здесь уместно привести аналогию с традиционными системами программирования: они позволяют быстро и надежно избавиться от синтаксических ошибок, но с логическими ошибками дело обстоит гораздо хуже. Может быть, в будущем...
Слайд 13Предметы в UML
В UML имеются четыре разновидности предметов:
структурные предметы;
предметы поведения;
группирующие
предметы;
поясняющие предметы.
Эти предметы являются основными объектно-ориентированными строительными блоками. Они используются
для создания моделей.
Слайд 14Структурные предметы – это имена существительные в UML-моделях. Они представляют
статические части модели – понятийные или физические элементы.
Класс -
описание множества объектов, которые разделяют одинаковые свойства, операции, отношения и семантику (смысл).
Класс реализует один или несколько интерфейсов.
Слайд 15Структурные предметы
Интерфейс – набор операций, которые предоставляются классом или компонентом.
Интерфейс описывает поведение элемента, видимое извне.
Интерфейс может содержать все
операции класса или компонента либо только часть этих операций.
Интерфейс определяет только спецификации операций (то есть только их названия).
Интерфейс не содержит реализаций этих операций.
Интерфейс редко существует самостоятельно. Обычно он присоединяется к классу или компоненту, который реализует интерфейс.
Слайд 16Структурные предметы
Кооперация (сотрудничество) определяет взаимодействие.
Является совокупностью ролей и других
элементов, которые взаимодействуют между собой, причем результат их работы больше
чем простая сумма результатов работы всех элементов.
Классы могут участвовать в нескольких кооперациях.
Слайд 17Структурные предметы
Прецедент (Элемент Use Case) – описание последовательности действий (или
нескольких последовательностей), выполняемых системой в интересах отдельного актера и производящих
видимый для актера результат.
Элемент Use Case реализуется кооперацией
Актер — набор согласованных ролей, которые могут играть пользователи при взаимодействии с системой (ее элементами Use Case). Каждая роль требует от системы определенного поведения.
Слайд 18Структурные предметы
Активный класс - класс, экземпляры которого – активные объекты.
Активный объект – объект, который владеет процессом или потоком и
может управлять им.
Активные классы применяются при многопоточном программировании, когда несколько участков программы могут выполняться параллельно и нужно синхронизовать.
Слайд 19Структурные предметы
Компонент - физическая и заменяемая часть ПС, которая соответствует
определенному набору интерфейсов и содержит реализацию этого набора интерфейсов.
В
качестве компонентов могут выступать динамические библиотеки (DLL), исполняемые файлы, файлы, управляющие выполнение программы (INI), файлы со справкой и т.д.
Компонент представляет собой контейнер логических элементов системы (например, классов).
Слайд 20Структурные предметы
Узел - физический элемент, который существует во время выполнения
программы и представляет собой вычислительный ресурс, обычно обладающий как минимум
определенным объемом памяти, а зачастую и своим процессором.
Узлы используются для моделирования аппаратных средств (также могут сопровождаться текстами программ на языке VHDL).
Связь с узлом может осуществляться через компоненты.
Слайд 21Предметы поведения
Это динамические составляющие UML-моделей. Они являются глаголами языка. Описывают
поведение модели во времени и пространстве. Существует две основные разновидности
предметов поведения.
Взаимодействие – это поведение, суть которого – обмен сообщениями между объектами для достижения определенной цели.
С помощью взаимодействия можно описать как отдельную операцию, так и поведение совокупности объектов.
Элементами взаимодействия являются сообщения,
последовательности действий (поведение, вызываемое сообщением) и
связи (соединения между объектами).
Слайд 22Предметы поведения
Автомат – поведение, которое определяет последовательность состояний, через которые
проходят объект или взаимодействие на протяжении всего своего жизненного цикла
в ответ на некоторые события.
С помощью автомата можно определять поведение класса или кооперации классов.
Элементами автомата являются
состояния,
переходы (от состояния к состоянию),
события (предметы, вызывающие переходы) и
действия (реакции на переход).
Слайд 23Группирующие предметы – организационные части UML-моделей. Это блоки, на которые
может быть разложена модель. Предусмотрена одна разновидность группирующего предмета —
пакет.
Пакет – контейнер, в который могут помещаться структурные предметы, предметы поведения и другие группирующие предметы. Пакет существует только в период разработки.
Слайд 24Поясняющие предметы – комментарии к элементам UML-моделей. Предусмотрена одна разновидность
поясняющего предмета – примечание.
Примечание – символ для отображения ограничений и
замечаний, присоединяемых к элементу или группе элементов.
Изображается в виде прямоугольника с загнутым углом, в который вписывается текстовый или графический комментарий.
Слайд 25Отношения UML
Зависимость – это отношение между двумя предметами, при котором
изменение в одном предмете (независимом предмете) может влиять на состояние
другого предмета (зависимого предмета).
Ассоциация – это отношение, которое показывает, что предметы одного типа некоторым способом связаны с предметами другого типа. Агрегация – частный случай ассоциации.
Слайд 26Отношения UML. Ассоциация
Агрегация:
Один из элементов модели является частью другого
То же,
но дочерний элемент не может существовать без родительского.
Комбинации аннотаций множественности:
1 ровно
один
0..*ноль или более
1..* один или более
0..1 один или ноль
3..9 от 3 до 9 включ.
Слайд 27Отношения UML
Обобщение – отношение, в котором объекты специализированного предмета (потомка)
могут заменять объекты обобщенного предмета (родителя).
Таким образом, потомок разделяет
структуру и поведение родителя.
Реализация - отношение между предметами, при котором первый предмет определяет набор услуг, предоставляемых вторым предметом, а тот в свою очередь гарантирует их выполнение.
Отношения реализации применяют между интерфейсами и классами (или компонентами), реализующими их, а также между прецедентами и реализующими их кооперациями.
Слайд 28Диаграммы UML
UML 2 описывает 13 официальных типов диаграмм. Диаграммы определены
не очень строго. Часто вполне допустимо присутствие элементов диаграммы одного
типа в другой диаграмме.
Стандарт UML указывает, что определенные элементы обычно рисуются в диаграммах соответствующего типа, но это не догма.
UML содержит 2 типа базовых диаграмм – структуры (отображают статическую структуру элементов системы) и поведения (изображают динамическое поведение элементов системы.
Слайд 29Диаграммы структуры
Классов (class diagrams) – наиболее часто используемые. Представляют статические
сущности, существующие в системе, их структуру и взаимоотношения. Используются для
описания логической и физической модели системы.
Компонентов (component diagrams) показывают организацию и зависимости между набором компонентов, а также систему, ее реализацию и совместную работу ее частей.
Объектов (object diagrams) показывают взаимоотношения между набором объектов в системе. Мгновенный снимок системы на данный момент времени.
Развертывания (deployment diagrams) – показывают архитектуру системы во время выполнения. Здесь может быть описание оборудования и ПО, которое постоянно связано с этим оборудованием.
Диаграмма составных (композитных) структур (composite structure diagrams) показывают внутреннюю структуру элементов модели.
Диаграмма пакетов – зависимости между пакетами.(пакет – элемент модели, используемый для соединения в группы с другими элементами моделей).
Слайд 30Диаграммы поведения
Диаграммы деятельности (activity) показывают потоки активности в системе. Часто
используют для описания бизнес-процессов.
Прецедентов или вариантов использования (use case diagrams)
– способы возможной работы системы и того, кто будет с системой взаимодействовать.
Состояний (конечных автоматов) statechart (state machine) – показывает состояние объекта и то, как объект переходит из одного состояния в другое.
Взаимодействий
Коммуникации (кооперации – старое название) (collaboration diagrams) – логически выделяют, как именно объект сотрудничает и взаимодействует с другими объектами.
Последовательности взаимодействий (sequence diagrams) – подчеркивают временное упорядочение сообщений между различными элементами системы.
Временные – отражают детальную информацию о временных характеристиках и об изменениях состояния или ситуации для взаимодействующих элементов.
Обзорные диаграммы взаимодействия – диаграммы высокого уровня, для получения общего представления о потоках управления между последовательностями взаимодействий.
Слайд 31Канонические диаграммы языка UML
вариантов использования (use case diagram)
классов (class
diagram)
кооперации (collaboration diagram)
последовательности (sequence diagram)
состояний (statechart diagram)
деятельности (activity diagram)
компонентов (component diagram)
развертывания (deployment diagram)
Слайд 32Рекомендации по графическому изображению диаграмм языка UML
Каждая диаграмма должна служить
законченным представлением соответствующего фрагмента моделируемой предметной области.
Все сущности на
диаграмме модели должны быть одного уровня представления.
Вся информация о сущностях должна быть явно представлена на диаграммах
Диаграммы не должны содержать противоречивой информации.
Каждая диаграмма должна быть самодостаточной для правильной интерпретации всех ее элементов и понимания семантики всех используемых графических символов
Количество типов диаграмм для конкретной модели приложения строго не фиксировано.
Любая модель системы должна содержать только те элементы, которые определены в нотации языка UML.
Слайд 33Диаграмма вариантов использования (прецедентов)
Слайд 34Диаграмма вариантов использования - это исходное концептуальное представление или концептуальная
модель системы в процессе ее проектирования и разработки.
Создание диаграммы
вариантов использования имеет следующие цели:
Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы
Сформулировать общие требования к функциональному поведению проектируемой системы
Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей
Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями
Слайд 35Базовые элементы диаграммы вариантов использования:
Вариант использования (use case) — внешняя
спецификация последовательности действий, которые система или другая сущность могут выполнять
в процессе взаимодействия с актерами.
Вариант использования представляет собой спецификацию общих особенностей поведения или функционирования моделируемой системы без рассмотрения внутренней структуры этой системы.
Каждый вариант использования определяет последовательность действий, которые должны быть выполнены проектируемой системой при взаимодействии ее с соответствующим актером, сами эти действия на рассматриваемой диаграмме не изображаются .
Содержание варианта использования может быть представлено в форме дополнительного пояснительного текста, который раскрывает смысл или семантику действий при выполнении данного варианта использования (сценарий).
Слайд 36Базовые элементы диаграммы вариантов использования:
Актер (actor) — согласованное множество ролей,
которые играют внешние сущности по отношению к вариантам использования при
взаимодействии с ними.
Актер представляет собой любую внешнюю по отношению к моделируемой системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей или решения частных задач.
В некоторых случаях актер может обозначаться в виде прямоугольника класса со стереотипом <
> и обычными составляющими элементами класса.
Имена актеров должны начинаться с заглавной буквы и следовать рекомендациям использования имен для типов и классов модели.
Имя актера должно быть достаточно информативным с точки зрения семантики (например, продавец, кассир, менеджер, президент). Не рекомендуется давать актерам имена собственные или названия моделей конкретных устройств.
Актеры взаимодействуют с системой посредством передачи и приема сообщений от вариантов использования.
Слайд 37Отношения на диаграмме вариантов использования
Отношение (relationship) — семантическая связь между
отдельными элементами модели.
Между элементами диаграммы вариантов использования могут существовать
различные отношения, которые описывают взаимодействие экземпляров одних актеров и вариантов использования с экземплярами других актеров и вариантов. Один актер может взаимодействовать с несколькими вариантами использования. В этом случае этот актер обращается к нескольким сервисам данной системы. В свою очередь один вариант использования может взаимодействовать с несколькими актерами, предоставляя для всех них свой сервис.
В то же время два варианта использования, определенные в рамках одной моделируемой системы, также могут взаимодействовать друг с другом, однако характер этого взаимодействия будет отличаться от взаимодействия с актерами.
В обоих случаях способы взаимодействия элементов модели предполагают обмен сигналами или сообщениями, которые инициируют реализацию функционального поведения моделируемой системы.
Слайд 38Отношения на диаграмме вариантов использования
В языке UML имеется несколько стандартных
видов отношений между актерами и вариантами использования:
ассоциации (association relationship)
включения (include relationship)
расширения (extend relationship)
обобщения (generalization relationship)
При этом общие свойства вариантов использования могут быть представлены тремя различными способами, а именно — с помощью отношений включения, расширения и обобщения.
Слайд 39Отношения на диаграмме вариантов использования. Ассоциация
Отношение ассоциации – одно из
фундаментальных понятий в языке UML и в той или иной
степени используется при построении всех графических моделей систем в форме канонических диаграмм.
Применительно к диаграммам вариантов использования ассоциация служит для обозначения специфической роли актера при его взаимодействии с отдельным вариантом использования. Другими словами, ассоциация специфицирует семантические особенности взаимодействия актеров и вариантов использования в графической модели системы.
На диаграмме вариантов использования, так же как и на других диаграммах, отношение ассоциации обозначается сплошной линией между актером и вариантом использования. Эта линия может иметь некоторые дополнительные обозначения, например, имя и кратность
Слайд 40Отношения на диаграмме вариантов использования. Включение
Включение (include) в языке UML
— это разновидность отношения зависимости между базовым вариантом использования и
его специальным случаем. Причем такое, при котором изменение одного элемента (независимого) приводит к изменению другого элемента (зависимого).
Отношение включения устанавливается только между двумя вариантами использования и указывает на то, что заданное поведение для одного варианта использования включается в качестве составного фрагмента в последовательность поведения другого варианта использования.
Так, например, отношение включения, направленное от варианта использования "Предоставление кредита в банке" к варианту использования "Проверка платежеспособности клиента", указывает на то, что каждый экземпляр первого варианта использования всегда включает в себя функциональное поведение или выполнение второго варианта использования. В этом смысле поведение второго варианта использования является частью поведения первого варианта использования на данной диаграмме.
Слайд 41Отношения на диаграмме вариантов использования. Расширение
Отношение расширения (extend) определяет взаимосвязь
базового варианта использования с другим вариантом использования, функциональное поведение которого
задействуется базовым не всегда, а только при выполнении дополнительных условий.
Слайд 42Отношения на диаграмме вариантов использования. Обобщение
Два и более актера могут
иметь общие свойства, т. е. взаимодействовать с одним и тем
же множеством вариантов использования одинаковым образом. Такая общность свойств и поведения представляется в виде отношения обобщения с другим, возможно, абстрактным актером, который моделирует соответствующую общность ролей.
Графически отношение обобщения обозначается сплошной линией со стрелкой в форме не закрашенного треугольника, которая указывает на родительский вариант использования — она называется стрелка-обобщение.
Слайд 43Отношения включения и расширения
Совершить поездку
Заправить автомобиль
перекусить
Сфотографировать понравившееся место
Водитель
Слайд 44Ключевые различия между отношениями включения и расширения
Слайд 45Дополнительные обозначения языка UML для бизнес-моделирования
Бизнес-актер (business actor) – индивидуум,
группа, организация, компания или система, которые взаимодействуют с моделируемой бизнес-системой,
но не входят в нее, т.е. не являются частью моделируемой системы. Примерами бизнес-актеров являются клиенты, покупатели, поставщики, партнеры. Общее свойство бизнес-актеров состоит в том, что они являются инициаторами или клиентами бизнес-процессов моделируемой системы.
Сотрудник (business worker) – индивидуум, который действует внутри моделируемой бизнес-системы, взаимодействует с другими сотрудниками и является участником бизнес-процесса моделируемой системы. Примерами сотрудников являются менеджеры, администраторы, кассиры, инженеры. Общее свойство сотрудников заключается в том то, что они являются субъектами и входят в состав моделируемой системы.
Бизнес-вариант использования (business use case) — вариант использования, определяющий последовательность действий моделируемой системы, направленных на выполнение отдельного бизнес-процесса. Общее свойство бизнес-вариантов использования состоит в том, что они являются концептуальной моделью отдельных бизнес-процессов моделируемой системы.
Слайд 46Диаграмма вариантов использования для системы продажи товаров по каталогу в
общих обозначениях языка UML
Слайд 47Диаграммы классов UML. Логическое моделирование
Диаграммы классов используются при моделировании ПС
наиболее часто.
Они являются одной из форм статического описания системы
с точки зрения ее проектирования, показывая ее структуру.
Диаграмма классов не отображает динамическое поведение объектов изображенных на ней классов.
На диаграммах классов показываются классы, интерфейсы и отношения между ними.
Слайд 48Представление классов
Класс – это основной строительный блок ПС.
Диаграммы классов
могут применяться и при прямом проектировании, то есть в процессе
разработки новой системы, и при обратном проектировании - описании существующих и используемых систем.
В большинстве существующих инструментов UML-моделирования возможна кодогенерация для определенного языка программирования (обычно Java или C++).
Таким образом, диаграмма классов - конечный результат проектирования и отправная точка процесса разработки.
Слайд 49Каждый класс имеет название, атрибуты и операции.
Слайд 50Атрибуты класса
Определяют состав и структуру данных, хранимых в объектах этого
класса.
Каждый атрибут имеет имя и тип, определяющий, какие данные
он представляет.
При реализации объекта в программном коде для атрибутов будет выделена память, необходимая для хранения всех атрибутов, и каждый атрибут будет иметь конкретное значение в любой момент времени работы программы.
Объектов одного класса в программе может быть сколь угодно много, все они имеют одинаковый набор атрибутов, описанный в классе, но значения атрибутов у каждого объекта свои и могут изменяться в ходе выполнения программы.
Слайд 51Модификаторы видимости - ограничение доступа к атрибутам и операциям объекта
со стороны других объектов.
Слайд 52Отношения.
Ассоциации и обобщения.
Ассоциация сама может обладать свойствами класса, то есть,
иметь атрибуты и операции. В этом случае она называется класс-ассоциацией
и может рассматриваться как класс, у которого помимо явно указанных атрибутов и операций есть ссылки на оба связываемых ею класса. В примере на рис.2 ассоциация «включает» по существу есть класс-ассоциация, у которой есть атрибут «Количество», показывающий, сколько единиц каждого товара входит в набор (см. рис.4).
Слайд 53Отношение обобщения.
Обобщение на диаграммах классов используется, чтобы показать связь между
классом-родителем и классом-потомком.
Оно вводится на диаграмму, когда возникает разновидность
какого-либо класса (например, при развитии ПС), а также в тех случаях, когда в системе обнаруживаются несколько классов, обладающих сходным поведением (в этом случае общие элементы поведения выносятся на более высокий уровень, образуя класс-родитель).
Слайд 54Отношение обобщения. Наследуются атрибуты и операции.
Слайд 55UML позволяет строить модели с различным уровнем детализации. Детализация модели,
представленной ранее.
Обобщение показывает, что набор товаров – это тоже товар,
который может быть предметом заказа, продажи, поставки и т.д. Набор включает опись, в которой указывается, какие товары входят в набор, а класс-ассоциация «включает» определяет количество каждого вида товаров в наборе.
Слайд 56Стереотипы классов
Стереотип класса – это элемент расширения словаря UML, который
обозначает отличительные особенности в использовании класса. Стереотип имеет название, которое
задается в виде текстовой строки. При изображении класса на диаграмме стереотип показывается в верхней части класса в двойных угловых скобках.
Стереотип :
используется для обозначения классов-сущностей (классов данных),
стереотип описывает пограничные классы, которые являются посредниками между ПС и внешними по отношению к ней сущностями – актерами,
стереотип описывает классы и объекты, которые управляют взаимодействиями.
Есть четыре стандартных стереотипа классов, для которых предусмотрены специальные графические изображения .
Слайд 57Интерфейсы
это логическая группа открытых ( public ) операций объекта.
Один
и тот же объект может иметь несколько интерфейсов.
Интерфейс отражает
внешние проявления объекта, показывает, каким образом осуществляется взаимодействие с ним, скрывая остальные детали, не имеющие отношения к процессу взаимодействия.
Интерфейс всегда реализуется некоторым классом, который в таком случае называют классом, поддерживающим интерфейс. Если один объект имеет несколько интерфейсов, это означает, что класс этого объекта реализует все операции этих интерфейсов.
Многие из существующих технологий программирования (например, COM, CORBA, Java Beans) не только активно используют механизм интерфейсов, но и, по сути, полностью основаны на нем.
Слайд 58Как интерфейс изображается на диаграммах
Интерфейс изображается на диаграммах несколькими способами.
Первый и самый простой из них - это класс со
стереотипом <
>.
Этот способ хорош, если нужно показать, какие именно операции предоставляет интерфейс
Если же такие подробности в данный момент не важны, предоставляемый интерфейс изображают в виде кружочка.
Обратите внимание на маленький значок на закладке папки ConduitSet. Это обозначение подсистемы, мы могли бы не рисовать его, а просто использовать стереотип <>.
Слайд 59Требуемый интерфейс
Используется для изображения интерфейсов, требующихся объекту для выполнения его
работы. Обозначается он очень простым и логичным символом.
Тогда видно, что
логически совмещаются символы предоставляемого и требуемого интерфейсов.
Названия интерфейсов традиционно начинаются с буквы I. Помогает быстро разобраться в сложной диаграмме, составленной другим человеком.
Слайд 60Почему стоит использовать уже существующие классы:
Идя этим путем, мы пользуемся
плодами ранее принятых решений. Действительно, если когда-то мы уже решили
некоторую проблему, зачем начинать все "с нуля", повторяя уже однажды проделанные действия?
Таким образом мы делаем решение мобильным и расширяемым. Используя уже существующие классы и создавая на их основе новые, мы можем развивать решение практически неограниченно, добавляя лишь необходимые нам в данный момент детали - атрибуты и операции.
Существующие классы, как правило, хорошо отлажены и показали себя в работе. Разработчику не надо тратить время на кодирование, отладку, тестирование и т. д., - мы работаем с хорошо отлаженным и проверенным временем кодом, который зарекомендовал себя в других проектах и в котором уже выявлено и исправлено большинство ошибок.
Слайд 61Моделирование наследования по Бучу.
Найдите атрибуты, операции и обязанности, общие для
двух или более классов из данной совокупности. Это позволит избежать
ненужного дублирования структуры и функциональности объектов.
Вынесите эти элементы в некоторый общий суперкласс, а если такого не существует, то создайте новый класс.
Отметьте в модели, что подклассы наследуются от суперкласса, установив между ними отношение обобщения.
Слайд 63Применение диаграмм классов
Для моделирования данных. Анализ предметной области позволяет выявить
основные характерные для нее сущности и связи между ними. Это
удобно моделируется с помощью диаграмм классов. Эти диаграммы являются основой для построения концептуальной схемы базы данных.
Для представления архитектуры ПС. Можно выделить архитектурно значимые классы и показать их на диаграммах, описывающих архитектуру ПС.
Для моделирования навигации экранов. На таких диаграммах показываются пограничные классы и их логическая взаимосвязь. Информационные поля моделируются как атрибуты классов, а управляющие кнопки – как операции и отношения.
Для моделирования логики программных компонент.
Для моделирования логики обработки данных.
Слайд 64Диаграмма объектов (object diagram)
Объект (object) - экземпляр класса.
Объект (object) -
конкретная
материализация абстракции;
сущность с хорошо определенными границами, в которой инкапсулированы состояние
и поведение;
экземпляр класса (вернее, классификатора - эктор, класс или интерфейс). Объект уникально идентифицируется значениями атрибутов, определяющими его состояние в данный момент времени.
Слайд 65Объекты
Объект, как и класс, обозначается прямоугольником, но его имя подчеркивается.
Под словом имя здесь мы понимаем название объекта и наименование
его класса, разделенные двоеточием.
Для указания значений атрибутов объекта в его обозначении может быть предусмотрена специальная секция.
Объект может быть анонимным: это нужно в том случае, если в данный момент не важно, какой именно объект данного класса принимает участие во взаимодействии.
Слайд 66Диаграмма объектов показывает множество объектов - экземпляров классов (изображенных на
диаграмме классов) и отношений между ними в некоторый момент времени.
Слайд 67Диаграммы последовательностей (Sequence diagrams) или сценарии
Слайд 68Сообщения на диаграммах последовательностей
Сообщение, показываемое в виде стрелки от объекта
к объекту, соответствует вызову операции соответствующего класса, ответные сообщения -
пунктирные линии со стрелками.
Сообщения, отправленные ранее, расположены выше, чем отправленные позже. Таким образом, последовательность сообщений легко читается "сверху вниз".
Объект отправляет сообщение в расчете на то, что оно вызовет некую реакцию и за этим последует некоторая деятельность.
Синхронные сообщения приостанавливают поток выполнения до тех пор, пока не будет получен ответ.
Асинхронные сообщения не ждут ответа, не приостанавливают поток выполнения - сразу после их посылки происходит немедленный переход к следующему шагу, и последовательность продолжается.
Слайд 69Диаграммы кооперации (Collaboration Diagrams)
Диаграмма кооперации получается из диаграммы объектов путем
добавления сообщений.
Для представления сообщений используются стрелки, располагаемые около ассоциаций.
Стрелка показывает направление передачи сообщения, а в названии сообщения показываются передаваемые параметры.
Временная последовательность сообщений задается с помощью их нумерации.
На диаграммах кооперации более важным является не временной порядок, а показ данных, передаваемых в сообщениях.
Слайд 70Другой вариант диаграммы кооперации – показаны прикрепленные к объектам (классам)
роли в рамках данной кооперации. Назначение роли изображается пунктирной линией
со стрелкой на конце, направленной в сторону объекта. Имя роли указывается на конце линии, рядом с объектом. Здесь видно, кто какую роль играет и в каком взаимодействии (кооперации). А еще показана генерализация и кооперации, и самих исполнителей.
Слайд 71Диаграммы состояний
Диаграммы состояний предназначены для представления жизненного цикла объекта в
виде конечного автомата.
Каждое состояние – это период жизни объекта,
когда он удовлетворяет определенным условиям.
Некоторое событие может привести переходу объекта в другое состояние. При переходе может выполняться действие, предписанное данному переходу.
Диаграмма состояний обычно связывается с классом, поскольку все объекты класса имеют одинаковое поведение.
При функциональном моделировании диаграммы состояний создаются для объектов, имеющих сложное поведение, показывая логику их работы.
Слайд 72Диаграммы состояний
Скругленные прямоугольники представляют состояния, через которые проходит объект в
течение своего жизненного цикла.
Стрелками показываются переходы между состояниями, которые
вызваны выполнением методов описываемого диаграммой объекта.
Псевдосостояния: начальное, в котором находится объект сразу после его создания (обозначается сплошным кружком), и конечное, которое объект не может покинуть, если перешел в него (обозначается кружком, обведенным окружностью).
Слайд 73В диаграмму входит составное состояние, включающее другие состояния, одно из
которых содержит также параллельные подсостояния.
Слайд 75Диаграммы деятельностей (активностей)
Диаграммы активностей (Activity Diagrams) являются представлением алгоритмов неких
действий (активностей), выполняющихся в системе.
Нотация UML предлагает пять представлений
системы:
Вид системы с точки зрения прецедентов.
Вид с точки зрения проектирования.
Вид с точки зрения процессов.
Вид с точки зрения развертывания.
Вид с точки зрения реализации.
И при этом каждый из перечисленных способов представления системы может содержать последовательности действий, которые могут быть описаны с помощью алгоритмов. Вот здесь-то и выходят на сцену диаграммы деятельностей.
Слайд 76Диаграммы деятельностей (активностей)
Любой элемент модели, имеющий динамическое поведение, может быть
дополнен диаграммой деятельности - именно для уточнения этой самой динамики.
Можно построить несколько диаграмм деятельности для одной и той же системы, причем каждая из них будет фокусироваться на разных аспектах системы.
Именно на диаграмме деятельности представлены переходы потока управления от одной деятельности к другой. Это, по сути, разновидность диаграммы состояний, где все или большая часть состояний являются некоторыми деятельностями, а все или большая часть переходов срабатывают при завершении определенной деятельности и позволяют перейти к выполнению следующей.
Слайд 77Диаграммы деятельностей (активностей)
Диаграмма деятельностей похожа на обычную блок-схему.
На ней
показываются деятельности – шаги в выполнении процесса, изображаемые в виде
прямоугольников с сопряженными дугами горизонтальными сторонами и переходы между ними, показываемые стрелками.
Предусмотрена возможность ветвления, изображаемая в виде ромба.
На этих диаграммах можно показать распараллеливание процесса на подпроцессы и слияние подпроцессов.
Для обозначения этих действий используются жирные горизонтальные или вертикальные линии.
Все элементы могут быть поименованы.
Слайд 78Диаграмма деятельностей при проектировании и разработке ПС.
Слайд 79Диаграммы деятельностей эффективны при описании деятельности организации
Слайд 80Диаграммы деятельности с разделами («плавательными дорожками»)
Слайд 81Диаграммы компонентов
Компонентно-базисный подход базируется на трех основных принципах:
отделение спецификации от
реализации;
инкапсуляция данных и процессов;
абстрагирование проектирования компонентов, позволяющее автоматизировать реализацию компонента.
Каждый
компонент имеет интерфейс и реализуется одним или несколькими объектами, поэтому логику компонента удобно моделировать с помощью диаграмм классов.
Для этой цели на диаграммах классов UML предусмотрена возможность представления интерфейсов компонент.
Интерфейс – это класс, которому присвоен стереотип .
Интерфейс связывается с реализующими его классами отношением реализации.
Интерфейс не может содержать атрибутов, он включает только сигнатуры операций.
Слайд 82Диаграмма классов, показывающая взаимодействие компонент
Слайд 83Пример диаграммы компонентов
На диаграммах компонентов показывается физическое разбиение ПС
на компоненты и другие программные блоки, а также отношения зависимости
между ними.
Можно, используя пакеты для обозначения узлов многозвенной ПС, в одном пакете собрать компоненты, реализуемые на этом узле.
Слайд 84Диаграммы развертывания
Это графическое представление инфраструктуры, на которую будет развернуто приложение.
Диаграмма развертывания показывает топологию системы и распределение компонентов системы по
ее узлам, а также соединения - маршруты передачи информации между аппаратными узлами.
Такие диаграммы есть смысл строить только для аппаратно-программных систем.
Слайд 85Диаграммы развертывания
Под линиями передачи информации можно подписать протоколы, по которым
происходит передача данных, а рядом с обозначением узла перечислить программное
обеспечение, установленное на нем.
Слайд 86Диаграмма развертывания с большим количеством узлов
