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

является вторичной, но не несущественной.

Модели позволяют:
наглядно продемонстрировать желаемую структуру

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

Модели необходимы:
для визуализации и управления архитектурой ИС.
минимизации риска процесса разработки.

разрабатываемых программных систем
Не позволяет эффективно управлять разработкой в условиях изменяющихся

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

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

затем сконструировать систему;
документировать принимаемые решения, используя полученные модели.


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

Метода Буча предоставлял разработчику отличные выразительные возможности на этапах проектирования

и конструирования модели.

Dr. Ivar Jacobson (Айвар Джекобсон, Ивар Якобсон) - OOSE (Object-Oriented Software Engineering). OOSE отлично приспособлен для анализа, формулирования требований и высокоуровневого проектирования.

Dr. James Rumbaugh (Джеймс Рамбо, Джим Румбах) - ОМТ (Object Modeling Technique). ОМТ-2 особенно полезен для анализа и разработки АИС, ориентированных на обработку больших объемов данных.

С 1989 по 1994 год число различных объектно-ориентированных методов возросло с десяти более чем до пятидесяти. Наиболее зрелыми методами на рынке являлись:

в 1989 году для разработки индустриальных стандартов с их последующим

использованием в процессе создания масштабируемых неоднородных распределенных объектных сред.
В настоящее время входит более 800 софтверных компаний
Официальный сайт: www.omg.org

описания, визуализации и документирования систем различной природы в процессе их

анализа и проектирования.

Язык UML не является методологией
Язык UML не является процессом
Язык UML не является языком программирования
Язык UML не является формальным языком

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

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

к поведению системы.
Создать и зафиксировать исходное концептуальное представление системы с

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

прецеденты, заказчику системы становится понятно, какие функциональные возможности закладываются в

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

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

непосредственно взаимодействующая с ней и использующая ее для достижения определенных

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

Актер. Определение.

Рисунок 2.
Актеры.

не может быть запущен, а значит, не связывается с актерами.
Абстрактный

прецедент

Рисунок 3. Абстрактный прецедент.

инициировать прецеденты.
Абстрактный актер
Рисунок 4. Абстрактный актер.

модель произвольной текстовой информации.
Примечания
Рисунок 5. Пример использования примечаний

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

коммуникации между актером и прецедентом

взаимодействия: актер или система.
Направленная и ненаправленная ассоциация
Рисунок 7. Направленные

и ненаправленные ассоциации

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

ассоциации. Кратность.

Рисунок 8. Кратность отношения ассоциации

прецеденту В, это означает, что свойства экземпляра прецедента В могут

быть дополнены, благодаря наличию свойств у расширяющего прецедента А.

Отношение расширения. Определение.

Рисунок 9. Отношение расширения

Но, может случиться так, что клиент решит изучить подробные спецификации

приобретаемой продукции. Тогда актер запросит у системы сервис подробного описания товара. На изучение подробного описания будет затрачен определенный промежуток времени, на протяжении которого выполнение основного прецедента приостановится.

Отношение расширения. Пример.

Рисунок 10. Пример использования отношение расширения

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

прецедента В.

Отношение включения. Определение.

Рисунок 11. Отношение включения

можно сформулировать как “Чтение и отправка электронной почты”. Однако, доступ

к нему возможен лишь после авторизации пользователя в системе, что показано путем введения прецедента “Авторизоваться”, включаемого в базовый прецедент.

Отношение включения. Пример.

Рисунок 12. Пример использования отношения включения

прецедентов

указания того факта, что некоторый прецедент A может быть обобщен

до прецедента B.

Рисунок 14. Отношение обобщения между прецедентами

та же последовательность действий, что и при оформлении продажи любого

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

Рисунок 15. Пример использования отношения обобщения между прецедентами

к актеру B призвано отразить тот факт, что каждый экземпляр

актера A является одновременно экземпляром актера B и обладает всеми его свойствами.

Рисунок 16. Пример использования отношения обобщения между прецедентами

продажи товаров с использованием сети Internet. Разместить заказ посредством сайта

может только зарегистрированный пользователь. Пользователь, не прошедший процедуру регистрации на сайте, может лишь просматривать каталог.

Рисунок 17. Пример использования отношения обобщения между актерами

розничной торговли
Рисунок 17. Прецедент и актер магазина розничной

торговли

являются полезными, будучи рассмотрены независимо друг от друга, они описывают

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

Рисунок 19. Ошибочное решение.
Прецеденты подобны пунктам меню системы или ее функциям.

22. Корректная
диаграмма
прецедентов

сервисы

25. Корректно сформулированные прецеденты.