Лекции по курсу УМЛ часть 1

+7

No comments posted yet

Comments

Slide 2

Современный рынок программного обеспечения диктует жесткие требования на разрабатываемые информационные системы. Системы должны быть надежными, высокопроизводительными, обладать гибкостью к любого рода изменениям в предъявляемых ей требованиям, обеспечивать возможность масштабирования и наращивания функциональности. Кроме того, разработка должна вестись быстро, качественно и с минимальными затратами. Разработка модели сложной программной системы перед непосредственной ее реализацией является такой же неотъемлемой частью всего проекта, какой чертеж является основой для постройки большого здания. Хорошая модель является основой для беспрепятственного взаимодействия в команде разработчиков и гарантирует общий успех начатого проекта. Построение модели необходимо, потому что невозможно охватить с первого взгляда как всю систему в целом, так и отдельные ее функциональные части. По мере роста разрабатываемых систем все больше проявляется необходимость в наличии хорошего средства моделирования. Существует большое число факторов, влияющих на общий успех разработки, но присутствие строгого стандарта на язык моделирования является первостепенным фактором - поэтому обратимся к более подробному рассмотрению вопроса, связанного с появлением промышленного объектно-ориентированного стандарта моделирования - UML - Унифицированного Языка Моделирования.

Slide 6

Разработка UML началась в октябре 1994 года, когда Гради Буч и Jim Rumbaugh из Rational Software Corporation приступили к совместной работе по унифицированию методов Booch и OMT (Object Modeling Technique). Оба метода развивались независимо друг от друга и были по праву названы одними из лучших методов объектно-ориентированного подхода при разработке программных систем. Было принято решение об объединении этих двух методов, и в октябре 1995 вышла бета-версия, которая получила название Unified Method. К концу 1996 года выяснилось, что ряд крупных компаний готовы рассмотреть UML в качестве основной стратегии своего бизнеса. Был создан некоммерческий консорциум OMG (Object Modeling Group), который объединил таких ведущих производителей ПО, как DEC, HP, IBM, Microsoft, Oracle, Rational Software и др. В январе 1997 был выдан UML 1.0. Вскоре к OMG примкнули такие компании, как IBM, Objectime, Platinum Technology и Softeam. Как результат этого сотрудничества появилась версия UML 1.1. 2003 – принята версия 1.5. В 2004 время принята версия 2.0.

Slide 14

Диаграмма классов показывает статическую структуру части системы. Таким образом, составляющими данного типа диаграмм являются классы, объекты и отношения между ними. Класс представлен прямоугольником с тремя разделами, в которых соответственно помещаются имя класса, атрибуты и операции. Схожая нотация применяется и для объектов - экземпляров класса, с тем различием, что к имени класса добавляется имя объекта и вся надпись подчеркивается. Нотация UML предоставляет широкие возможности для отображения дополнительной (и зачастую очень важной) информации (абстрактные операции и классы, стереотипы, общие и частные методы, интерфейсы, параметризованные классы и т.д Отношение обобщения также имеет собственную графическую нотацию в виде треугольника и связующей линии, позволяя представить иерархию наследования: от суперкласса к подклассам.

Slide 27

Техника Прецедентов Использования (UseCase) - была впервые предложена Айваром Якобсоном в 1992 и быстро завоевала всеобщее признание за счет простоты и легкости восприятия и применения. Суть ее состоит в следующем: проектируемая система представляется в виде наборов Акторов, взаимодействующих с системой с помощью так называемых Прецедентов Использования. Актором является любая сущность, взаимодействующая с системой извне. Им может быть человек, оборудование, другая система, то есть мы определяем, что взаимодействует с системой. В свою очередь Прецедент Использования описывает, что система предоставляет актору, то есть определяет некоторый набор транзакций, совершаемый актором при диалоге с системой, при этом ничего не говориться о том, каким образом будет реализовано взаимодействие. Детальное описание - удел других техник моделирования UML, диаграмма же Прецедентов Использования несет в себе высокий уровень абстракции, что позволяет еще на ранних этапах проекта определить и зафиксировать функциональные требования к системе и обеспечить гибкий и эффективный механизм взаимодействия между разработчиком и заказчиком проекта. Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы. Сформулировать общие требования к функциональному поведению проектируемой системы. Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей. Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями.

Slide 31

Техника Прецедентов Использования (UseCase) - была впервые предложена Айваром Якобсоном в 1992 и быстро завоевала всеобщее признание за счет простоты и легкости восприятия и применения. Суть ее состоит в следующем: проектируемая система представляется в виде наборов Акторов, взаимодействующих с системой с помощью так называемых Прецедентов Использования. Актором является любая сущность, взаимодействующая с системой извне. Им может быть человек, оборудование, другая система, то есть мы определяем, что взаимодействует с системой. В свою очередь Прецедент Использования описывает, что система предоставляет актору, то есть определяет некоторый набор транзакций, совершаемый актором при диалоге с системой, при этом ничего не говориться о том, каким образом будет реализовано взаимодействие. Детальное описание - удел других техник моделирования UML, диаграмма же Прецедентов Использования несет в себе высокий уровень абстракции, что позволяет еще на ранних этапах проекта определить и зафиксировать функциональные требования к системе и обеспечить гибкий и эффективный механизм взаимодействия между разработчиком и заказчиком проекта. Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы. Сформулировать общие требования к функциональному поведению проектируемой системы. Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей. Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями.

Slide 36

Диаграмма классов показывает статическую структуру части системы. Таким образом, составляющими данного типа диаграмм являются классы, объекты и отношения между ними. Класс представлен прямоугольником с тремя разделами, в которых соответственно помещаются имя класса, атрибуты и операции. Схожая нотация применяется и для объектов - экземпляров класса, с тем различием, что к имени класса добавляется имя объекта и вся надпись подчеркивается. Нотация UML предоставляет широкие возможности для отображения дополнительной (и зачастую очень важной) информации (абстрактные операции и классы, стереотипы, общие и частные методы, интерфейсы, параметризованные классы и т.д Отношение обобщения также имеет собственную графическую нотацию в виде треугольника и связующей линии, позволяя представить иерархию наследования: от суперкласса к подклассам.

Slide 37

Диаграмма классов показывает статическую структуру части системы. Таким образом, составляющими данного типа диаграмм являются классы, объекты и отношения между ними. Класс представлен прямоугольником с тремя разделами, в которых соответственно помещаются имя класса, атрибуты и операции. Схожая нотация применяется и для объектов - экземпляров класса, с тем различием, что к имени класса добавляется имя объекта и вся надпись подчеркивается. Нотация UML предоставляет широкие возможности для отображения дополнительной (и зачастую очень важной) информации (абстрактные операции и классы, стереотипы, общие и частные методы, интерфейсы, параметризованные классы и т.д Отношение обобщения также имеет собственную графическую нотацию в виде треугольника и связующей линии, позволяя представить иерархию наследования: от суперкласса к подклассам.

Slide 1

УНИФИЦИРОВАННЫЙ ЯЗЫК МОДЕЛИРОВАНИЯ UML Курс лекций. МарГТУ 2008. Рыбаков А.Е., Нехорошкова Л.Г.

Slide 2

ВВЕДЕНИЕ.

Slide 3

Что такое UML UML – еще один формальный язык, который необходимо быстро освоить Знание UML является необходимым, но не является достаточным условием построения разумных моделей UML имеет синтаксис, семантику и прагматику, которые нужно использовать с учетом особенностей фактического инструмента

Slide 4

Как выглядит Сухой текст -> -> текст с картинками -> ->картинки с текстом = комиксы = UML 1.2. Назначение UML

Slide 5

Чем НЕ является UML Языком программирования хотя генерация кода не возбраняется Спецификацией инструмента (CASE) хотя инструменты подразумеваются (Sun , Together , Rose, Visio, Argo,…) Моделью процесса хотя модель необходима и имеется (Rational Unified Process Unified Software Development Process) 1.3. Способы использования

Slide 6

История UML 1995-96 гг. – Grady Booch, Ivar Jacobson и James Rumbaugh – работают над предварительными версиями UML. Объединение методов Booch и OMT - Unified Method 1996-97 гг. – представители индустрии организуют сообщество для работы над проектом стандарта UML 1997 г. – OMG принимает стандарт UML 1.1 2003 г. – принята версия – 1.5 2004 г. – принята версия 2.0

Slide 7

Авторы UML Grady Booch Грэди Буч James Rumbaugh Джеймс Рамбо Ivar Jacobson Айвар Якобсон 1.1. Что такое UML

Slide 8

Преимущества UML UML объектно-ориентированный; UML позволяет описать систему практически со всех возможных точек зрения; Диаграммы UML сравнительно просты; UML расширяем и позволяет вводить собственные текстовые и графические стереотипы; UML получил широкое распространение и динамично развивается. 20% языка достаточно для 80% случаев

Slide 9

Элементы UML UML образуют три разновидности строительных блоков: Объекты, отношения, диаграммы. Объекты (сущности) — это абстракции, которые являются основными элементами в модели; Отношения связывают эти предметы; Диаграммы группируют коллекции предметов.

Slide 10

Объекты В UML имеются четыре разновидности объектов(предметов) : структурные предметы; предметы поведения; группирующие предметы; поясняющие предметы. Эти предметы являются базовыми объектно-ориентированными строительными блоками. Они используются для описания моделей.

Slide 11

Нотация структурных сущностей 2.1. Модель UML

Slide 12

Нотация других сущностей 2.1. Модель UML

Slide 13

Отношения в UML 2.1. Модель UML

Slide 14

Примеры отношений ? ? ? ?

Slide 15

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

Slide 16

Канонические диаграммы Классов (class diagram) Использования (use case diagram) Последовательности (sequence diagram) Кооперации (collaboration diagram) Состояний (state chart diagram) Деятельности (activity diagram) Компонентов (component diagram) Размещения (deployment diagram)

Slide 17

Классификация диаграмм Диаграмма использования Структурные (static structure diagrams) Диаграмма классов Диаграмма объектов Реализации (implementation diagrams) Диаграмма компонентов Диаграмма размещения Поведенческие (behavioral diagrams) Диаграмма состояний Диаграмма действий Взаимодействия (interaction diagrams) Диаграмма кооперации Диаграмма последовательности

Slide 18

Три представления системы Представление использования ЧТО делает система Диаграммы использования Представление структуры ИЗ ЧЕГО состоит система Диаграммы классов, компонентов и размещения Представление поведения КАК работает система Диаграммы состояний, деятельности и взаимодействия (последовательности / коммуникации)

Slide 19

Итеративный процесс моделирования

Slide 20

Итого Модель UML состоит из описания сущностей и отношений между ними Элементы модели группируются в диаграммы и представления для наилучшего описания моделируемой системы с различных точек зрения В случае необходимости элементы UML могут быть расширены и переопределены средствами самого языка

Slide 21

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

Slide 22

Элементы диаграмм использования Сущности Действующие лица Варианты использования Примечания – применяются на всех диаграммах Пакеты Отношения Ассоциации между действующими лицами и вариантами использования Обобщения между действующими лицами Обобщения и зависимости между вариантами использования

Slide 23

Действующие лица и их идентификация Действующие лица находятся ВНЕ проектируемой системы Действующее лицо – это множество логически взаимосвязанных РОЛЕЙ Действующее лицо – это стереотипный КЛАСС Типовые случаи: категории пользователей, внешние программные и аппаратные средства

Slide 24

Обобщение между действующими лицами (1)

Slide 25

Обобщение между действующими лицами (1)

Slide 26

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

Slide 27

Пример use case diagram

Slide 28

Видеотека

Slide 29

Видеотека

Slide 30

Видеотека

Slide 31

Выводы Диаграмма использования – первый шаг моделирования Основное назначение – показать, что делает система во внешнем мире Не обязательно соответствует структуре классов, модулей и компонентов Адекватная идентификация действующих лиц и вариантов использования – ключ к успеху

Slide 32

Диаграмма классов

Slide 33

Диаграмма объектов Что такое UML

Slide 34

Свойства и операции Свойства: Видимость Имя [Множественность]: Тип = НачЗнач {Характеристики} начало + начало начало : Координаты имяфамилия [0..1]: String - левыйУгол : Координаты=(0, 10) сумма : Integer {frozen} Операции: Видимость Имя (Список Параметров): ВозврТип {Характеристики} + записать # зарегистрировать( и: Имя, ф: Фамилия) балансСчета (): Integer нагревать () {guarded}

Slide 35

Отношения Зависимости: простые и стереотипные Обобщение: включая множественное наследование Ассоциация: включая агрегацию и композицию Реализация: класс реализует интерфейс

Slide 36

Статическая структура с группами классов Диаграмма классов предназначена для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования.

Slide 37

Статическая структура с группами классов

Slide 38

Видеотека

Slide 39

Видеотека

Slide 40

Советы Не обязательно включать в модель все классы сразу Не обязательно определять все свойства класса сразу Не обязательно показывать на диаграмме все свойства класса Не обязательно определять все отношения между классами сразу

Slide 41

Конец первой части Спасибо за внимание! Вопросы?

Summary: Лекции по курсу УМЛ

Tags: умл диаграммы use case классов объектов использования деятельности состояний поведения

URL:
More by this User
Most Viewed
Previous Page Next Page