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

1

2

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

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

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

6 1. Диаграмма вариантов использования (use case diagram) 2. Диаграмма классов (class diagram) 3. Диаграммы поведения (behavior diagrams) 4. Диаграмма состояний (statechart diagram) 5. Диаграмма деятельности (activity diagram) 6. Диаграммы взаимодействия (interaction diagrams) 7. Диаграмма последовательности (sequence diagram) 8. Диаграмма кооперации (collaboration diagram) 9. Диаграммы реализации (implementation diagrams) 10. Диаграмма компонентов (component diagram) 11. Диаграмма развертывания (deployment diagram)

7

8 Конструкция или стандартный элемент языка UML - вариант использования применяется для спецификации общих особенностей поведения системы без рассмотрения внутренней структуры этой сущности. Каждый вариант использования определяет последовательность действий, которые должны быть выполнены проектируемой системой при взаимодействии ее с соответствующим лицом. Диаграмма вариантов использования может дополняться пояснительным текстом, который раскрывает смысл или семантику составляющих ее компонентов.

9 Отдельный вариант использования обозначается на диаграмме эллипсом, внутри которого содержится его краткое название или имя в форме глагола с пояснительными словами Проверить состояние текущего счета клиента банка

10 Вариант использования представляет собой последовательность действий, выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Вариант использования описывает типичное взаимодействие между пользователем и системой.

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

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

13

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

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

16 1. Прочитать любую документацию заказчика. 2. Рассмотреть области использования системы. 3. Учесть мнение каждого из заинтересованных лиц проекта. 4. Учесть реакцию системы на внешние события.

17 1. Присутствует ли каждое функциональное требование хотя бы в одном варианте использования? 2. Учли ли вы, как с системой будет работать каждое заинтересованное лицо? 3. Какую информацию каждое заинтересованное лицо будет передавать системе? 4. Какую информацию каждое заинтересованное лицо будет получать от системы? 5. Учли ли вы проблемы, связанные с эксплуатацией? Кто-то должен будет запускать готовую систему и выключать ее. 6. Учли ли вы все внешние системы, с которыми будет взаимодействовать данная? 7. Какой информацией каждая внешняя система будет обмениваться с данной? Детали варианта использования, т.е. как будут происходить действия в нем, описывают в документе, называемом «Потоком событий». Этот документ подробно описывает, что будут делать пользователи системы, а что сама система.

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