Цикл лекций “Унифицированный язык моделирования”. Лекция 1. «Введение

Цикл лекций “Унифицированный язык моделирования”. Лекция 1. «Введение в UML». «Диаграмма прецедентов».

2 Значение моделирования С точки зрения цели, которой является создание АИС, модель является вторичной, но не несущественной. Модели позволяют: наглядно продемонстрировать желаемую структуру и поведение системы; добиться лучшего понимания создаваемой системы, что зачастую приводит к ее упрощению; Модели необходимы: для визуализации и управления архитектурой ИС. минимизации риска процесса разработки.

3 Проекты разного масштаба

4 Отсутствие моделей при разработке ПО Не позволяет справиться с растущей сложностью разрабатываемых программных систем Не позволяет эффективно управлять разработкой в условиях изменяющихся требований Создает барьеры непонимания: аналитик не понимает руководителя проекта, разработчик – аналитика, тестировщик – разработчика и пр. Не позволяет обеспечить контроль изменений в процессе выполнения работ Не позволяет избежать субъективности в оценке качества разрабатываемых продуктов

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

6 Предпосылки возникновения UML Grady Booch (Гради Буч, Грэйди Буч) - Booch. Метода Буча предоставлял разработчику отличные выразительные возможности на этапах проектирования и конструирования модели. Dr. Ivar Jacobson (Айвар Джекобсон, Ивар Якобсон) - OOSE (Object-Oriented Software Engineering). OOSE отлично приспособлен для анализа, формулирования требований и высокоуровневого проектирования. Dr. James Rumbaugh (Джеймс Рамбо, Джим Румбах) - ОМТ (Object Modeling Technique). ОМТ-2 особенно полезен для анализа и разработки АИС, ориентированных на обработку больших объемов данных. С 1989 по 1994 год число различных объектно-ориентированных методов возросло с десяти более чем до пятидесяти. Наиболее зрелыми методами на рынке являлись:

7 История развития UML OMG (Object Management Group) — название консорциума, созданного в 1989 году для разработки индустриальных стандартов с их последующим использованием в процессе создания масштабируемых неоднородных распределенных объектных сред. В настоящее время входит более 800 софтверных компаний Официальный сайт: www.omg.org

8 Определение UML Unified Modeling Language - унифицированный язык моделирования, предназначенный для описания, визуализации и документирования систем различной природы в процессе их анализа и проектирования. Язык UML не является методологией Язык UML не является процессом Язык UML не является языком программирования Язык UML не является формальным языком

9 Назначение UML Предоставить разработчикам легко воспринимаемый и выразительный язык визуального моделирования, специально предназначенный для разработки и документирования моделей сложных систем различного назначения. Снабдить исходные понятия языка UML возможностью расширения и специализации для более точного представления моделей систем в конкретной предметной области. Графическое представление моделей в нотации UML не должно зависеть от конкретных языков программирования и инструментальных средств проектирования. Описание языка UML должно включать в себя семантический базис для понимания общих особенностей ООАП. Способствовать распространению объектных технологий и поощрять развитие рынка программных инструментальных средств. Интегрировать в себя новейшие и наилучшие достижения практики ООАП.

10 Назначение диаграммы прецедентов Определить границы и контекст моделируемой системы. Сформулировать требования к поведению системы. Создать и зафиксировать исходное концептуальное представление системы с целью его последующей детализации в форме логических и физических моделей. Подготовить набор артефактов, используемых разработчиками системы для общения с ее заказчиками и будущими пользователями.

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

12 Прецеденты предназначены для спецификации общих особенностей поведения моделируемой системы без рассмотрения ее внутренней структуры. Прецедент (Use Case). Назначение. Рисунок 1. Эквивалентные прецеденты.

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

14 Абстрактным является прецедент, который не может иметь экземпляров. Такой прецедент не может быть запущен, а значит, не связывается с актерами. Абстрактный прецедент Рисунок 3. Абстрактный прецедент.

15 Абстрактные актеры не могут иметь экземпляров, а значит, не могут инициировать прецеденты. Абстрактный актер Рисунок 4. Абстрактный актер.

16 Примечания (notes) используются в языке унифицированного моделирования для включения в модель произвольной текстовой информации. Примечания Рисунок 5. Пример использования примечаний

17 Отношение указывает, какую конкретно роль играет актер при взаимодействии с системой, связывая его с соответствующим прецедентом, Отношение ассоциации Рисунок 6. Отношение коммуникации между актером и прецедентом

18 Направление ассоциации призвано показать лицу, читающему диаграмму, кто является инициатором взаимодействия: актер или система. Направленная и ненаправленная ассоциация Рисунок 7. Направленные и ненаправленные ассоциации

19 Кратность (multiplicity) ассоциации может быть указана на обоих концах отношения и указывает на количество экземпляров элементов, участвующих в отношении. Отношение ассоциации. Кратность. Рисунок 8. Кратность отношения ассоциации

20 Если имеет место отношение расширения, направленное от прецедента А к прецеденту В, это означает, что свойства экземпляра прецедента В могут быть дополнены, благодаря наличию свойств у расширяющего прецедента А. Отношение расширения. Определение. Рисунок 9. Отношение расширения

21 Основным сервисом, который электронный магазин предоставляет клиенту, является оформление заказа. Но, может случиться так, что клиент решит изучить подробные спецификации приобретаемой продукции. Тогда актер запросит у системы сервис подробного описания товара. На изучение подробного описания будет затрачен определенный промежуток времени, на протяжении которого выполнение основного прецедента приостановится. Отношение расширения. Пример. Рисунок 10. Пример использования отношение расширения

22 Отношение включения, направленное от прецедента А к прецеденту В, указывает, что каждый экземпляр прецедента А включает в себя функциональные свойства прецедента В. Отношение включения. Определение. Рисунок 11. Отношение включения

23 Рассматривая Web-ориентированную систему, позволяющую работать с электронной почтой, основной сервис можно сформулировать как “Чтение и отправка электронной почты”. Однако, доступ к нему возможен лишь после авторизации пользователя в системе, что показано путем введения прецедента “Авторизоваться”, включаемого в базовый прецедент. Отношение включения. Пример. Рисунок 12. Пример использования отношения включения

24 Различия между отношениями включения и расширения. Рисунок 13. Неэквивалентные диаграммы прецедентов

25 Отношение обобщения между прецедентами. Определение. Отношение обобщения (generalization relationship) служит для указания того факта, что некоторый прецедент A может быть обобщен до прецедента B. Рисунок 14. Отношение обобщения между прецедентами

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

27 Отношение обобщения между актерами. Определение. Отношение обобщения, направленное от актера A к актеру B призвано отразить тот факт, что каждый экземпляр актера A является одновременно экземпляром актера B и обладает всеми его свойствами. Рисунок 16. Пример использования отношения обобщения между прецедентами

28 Отношение обобщения между актерами. Пример. Имеется некоторая Web-ориентированная информационная система продажи товаров с использованием сети Internet. Разместить заказ посредством сайта может только зарегистрированный пользователь. Пользователь, не прошедший процедуру регистрации на сайте, может лишь просматривать каталог. Рисунок 17. Пример использования отношения обобщения между актерами

29 Установка границ системы. Рисунок 18. Прецедент и актер АИС магазина розничной торговли Рисунок 17. Прецедент и актер магазина розничной торговли

30 Различия между прецедентами и функциями. Некорректная диаграмма. Приведенные на рисунке прецеденты не являются полезными, будучи рассмотрены независимо друг от друга, они описывают все, что система должна уметь делать. Однако диаграмма призвана раскрыть лишь способ использования системы актером, который формулируется крайне просто: заказчик должен иметь возможность разместить в системе свой заказ. Рисунок 19. Ошибочное решение. Прецеденты подобны пунктам меню системы или ее функциям.

31 Различия между прецедентами и функциями. Корректная диаграмма. Рисунок 20. Корректная диаграмма прецедентов.

32 Пропорции прецедентов и актеров Рисунок 21. Некорректная диаграмма прецедентов Рисунок 22. Корректная диаграмма прецедентов

33 Пропорции прецедентов и актеров Рисунок 23. Различные актеры – различные сервисы

34 Пропорции прецедентов и актеров Рисунок 24. Слишком размытый прецедент. Рисунок 25. Корректно сформулированные прецеденты.