Файл: Унифицированный язык моделирования (Unified Modeling Language, uml).pptx
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 06.05.2024
Просмотров: 13
Скачиваний: 0
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Унифицированный язык моделирования (Unified Modeling Language, UML)
План
- Введение в UML
- Жизненные циклы и UML
- Диаграммы UML
- Диаграмма прецедентов (Use Case)
- Диаграмма классов
- Диаграмма последовательности (sequence diagram)
1. Введение в UML
UML позволяет системным архитекторам представлять свое видение системы в виде набора стандартных диаграмм. Авторы UML определяют его как графический язык моделирования общего назначения (т. е. его можно применять для проектирования как простой системы, так и сложного аппаратно-программного комплекса или даже космического корабля), предназначенный для спецификации, визуализации, проектирования и документирования всех артефактов, создаваемых в ходе разработки
Чаще всего UML ассоциируется с моделированием ОО программных систем, но он имеет намного более широкое применение благодаря свойственной ему расширяемости. UML объединил лучшие современные технические приемы моделирования и разработки программного обеспечения.
UML не предлагает нам какой-либо методологии моделирования. UML это не методология, это унифицированный язык визуального моделирования. UP – это методология.
Унифицированный процесс (Unified Process, UP) – это методология. Она указывает на исполнителей, действия и артефакты, которые необходимо использовать, осуществить или создать для моделирования программной системы.
UML не привязан к какойлибо конкретной методологии или жизненному циклу. На самом деле он может использоваться со всеми существующими методологиями. UP использует UML в качестве базового син таксиса визуального моделирования. Следовательно, UP можно рас сматривать как предпочтительный метод для UML.
Для разработки существуют средства UML-моделирования. Например, StarUML. StarUML - это пакет с открытым программным кодом, написанный на Delphi и работающий под управлением ОС семейства Windows. На данный момент на рынке присутствует огромное количество и полноценных средств UML-моделирования, и программ для рисования диаграмм, в том числе и UML. Такие продукты, как Borland Together, Poseidon, StarUML и Dia, могут быть загружены с сайта производителя бесплатно. StarUML выглядит наиболее функциональным из бесплатных продуктов и может служить полноценной заменой коммерческим программам для UML-моделирования. Также разработка UML-диаграмм доступна в пакете SAP Signavio.
UML вобрал в себя черты нотаций Грейди Буча (Grady Booch), Джима Румбаха (Jim Rumbaugh), Айвара Якобсона (Ivar Jacobson) и многих других.
Румбах присоединился к Бучу в Rational Inc. Они объединили свои нотации и создали первую версию UML. В 1995 году на конференции OOPSLA они представили его как Unified Method, который потом и получил название UML. Чуть позже к ним присоединился Якобсон, который добавил к результатам их труда элементы Objectory и начал работу над Rational Unified Process (RUP). В 1997 году UML был отправлен в Object Management Group (OMG) для стандартизации. Кроме трех нотаций, UML вобрал в себя элементы многих других методологий.
В 1994 году Буч и Рамбо объединились в компании Rational Corporation для работы над UML. Rational занимал более половины рынка по разработке подобного рода методов.
Позже UML стал открытым промышленным стандартом. В 1996 г. Группа управления объектами (OMG, Object Management Group) выпускает запрос на предложение (request-for-proposal, RFP) для ОО языка визуального моделирования и предлагает UML. В 1997 г. OMG принимает UML и появляется первый открытый, удовлетворяющий промышленным стандартам ОО язык визуального моделирования. С этого момента исчезли все конкурирующие методы, и UML стал стандартным ОО языком моделирования.
В наши дни Rational не владеет UML, но продолжает работать над ним. UML же принадлежит OMG, а сама Rational ныне является одним из подразделений IBM и фигурирует во всех документах как IBM Rational. Известен и крайне популярен более неподдерживаемый пакет моделирования UML – IBM Rational Rose.
UML получил множество пакетов расширений, называемых профайлами и позволяющих использовать его для моделирования систем из специфических предметных областей.
• Жизненный цикл разработки: UML предоставляет визуальный синтаксис для моделирования на протяжении всего жизненного цикла разработки программного обеспечения – от постановки требований до реализации.
• Области приложений: UML используется для моделирования всех аспектов – от аппаратных встроенных систем реального времени до систем поддержки принятия решений.
2. Жизненные циклы и UML
• Языки реализации и платформы: UML является независимым от языков и платформ. Естественно, он прекрасно поддерживает чистые ОО языки (Java, C# и др.), но также эффективен и для гибридных ОО языков, таких как C++, и основанных на концепции объектов, таких как Visual Basic. UML также используется для создания моделей, реализуемых на не ОО языках программиро вания, таких как С.
• Процессы разработки: хотя UP и его разновидности на практике зачастую являются предпочтительными процессами разработки ОО систем, UML может поддерживать (и поддерживает) множество других процессов разработки ПО.
Основная идея UML – возможность моделировать программное обеспечение и другие системы как наборы взаимодействующих объектов. Это одходит для ОО программных систем и языков программирования, но также очень хорошо работает и для бизнес-процессов и других прикладных задач.
В UML-модели есть два аспекта:
• Статическая структура – описывает, какие типы объектов важны для моделирования системы и как они взаимосвязаны.
• Динамическое поведение – описывает жизненные циклы этих объектов и то, как они взаимодействуют друг с другом для обеспечения требуемой функциональности системы.
UML-модель состоит из совокупности диаграмм. В процессе проектирования система рассматривается с разных точек зрения с помощью моделей, различные представления которых предстают в форме диаграмм.
При проектировании систем с помощью диаграмм UML можно визуализировать систему с различных позиций представления ее функционирования. Одна из диаграмм, например, может описывать взаимодействие пользователя с системой, другая - изменение состояний системы в процессе ее работы, третья - взаимодействие между собой элементов системы и т. д.
3. Диаграммы UML
Сложную систему можно и нужно представить в виде набора небольших и почти независимых моделей диаграмм, причем ни одна из них не является достаточной для описания системы и получения полного представления о ней, поскольку каждая из них фокусируется на каком-то определенном аспекте функционирования системы и выражает разный уровень абстракции. В контексте приведенных определений ни одна отдельная диаграмма не является моделью. Лишь набор диаграмм составляет модель системы и наиболее полно ее описывает (визуализирует).
Диаграмма прецедентов или диаграмма вариантов использования (Use case diagram) — диаграмма, на которой отражены отношения, существующие между акторами и вариантами использования.
Основная задача — представлять собой единое средство, дающее возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы.
Разберем пример проектирования ИС (маркет-плейс).
Отправная точка для разработки платформы «Электронная ярмарка» - это ее модель функционирования, комбинированная В2В + B2C модель, соответствующая маркетплейсу и требующая мультивендорной реализации (функционал для совместной работы многих продавцов, а не только магазина и покупателей, как в модели В2С).
4. Диаграмма прецедентов (Use Case, вариантов использования)
Основные функции:
- регистрация (юрлица: фермера, производителя, поставщика; физлица);
- личный кабинет юрлица / физлица;
- подача объявления о конкретном товаре / партии товара;
- участие в торгах;
- поиск по городу, району, региону;
- механизм формирования рейтинга продавца, контактные данные, обратная связь с продавцом в объявлении.
Для начала представим проектируемую систему как множество акторов (actors – действующие лица, также в учебной литературе встречается – экторы), взаимодействующих с системой с помощью прецедентов (use case – событие, или вариантов использования системы).
Эктор – это роль, исполняемая при взаимодействии с прецедентом. Прецеденты (use case) - описание множества последовательных событий (включая варианты), выполняемых системой, которые приводят к наблюдаемому эктором результату.
На рисунке редставлена диаграмма прецедентов (диаграмма использования, use case diagram). Это наиболее общее представление функционального назначения системы. Диаграмма такого типа являются самым стабильным и классическим элементом языка UML, практически не изменяются с 1986 года, с момента, когда они впервые были предложены Иваром Якобсоном. Графическая нотация таких диаграмм также проста: они обладают двумя типами сущностей (как уже было сказано, акторы и прецеденты), и тремя типами отношений (зависимости, ассоциации, обобщения).
Выделим акторов. Принцип выделения:
- пользователи участвуют в разных (независимых) бизнес-процессах;
- пользователи имеют различные права на выполнение действий и доступ к информации;
- пользователи взаимодействуют с системой в разных режимах: от случая к случаю, регулярно, постоянно.
Таким образом, анализ действующих лиц – пользователей будущей системы – позволяет выделить следующих акторов: Администратор, Менеджер, Фермер, Покупатель.
Далее необходимо определиться с вариантами использования системы.
Семантически вариант использования (use case) — это описание множества возможных последовательностей действий (событий), приводящих к значимому для действующего лица результату
Анализ требований, сформированных нами к системе, позволяет выделить следующие варианты использования (прецеденты) системы и акторов, взаимодействующих с системой в контексте вариантов ее использования (тип отношения - ассоциация между действующим лицом и вариантом использования):
- актор Администратор – прецеденты: Контроль СУБД, Редактирование структуры интерфейса платформы, Редактирование учетных записей пользователей;
- актор Менеджер – прецеденты: Верификация учетных записей покупателя и продавца, Верификация предоставленных документов, Блокировка учетных записей продавца и покупателя, Выставление полномочий продавца и покупателя, Вывод отчетов о сделках;
- актор Фермер – прецеденты: Регистрация на платформе, Размещение объявления, Поиск товара по критериям, Совершение сделки, Оценка покупателя после совершения сделки;
- актор Покупатель – прецеденты: Регистрация на платформе, Поиск товара по критериям, Совершение сделки, Оценка качества услуг фермерского хозяйства.
Прецеденты Поиск товара по критериям, Совершение сделки имеют тип отношения – обобщение между вариантами использования.
Диаграмма, по сути, иллюстрирует варианты использования будущей платформы: что покупатель увидит, зайдя на сайт, и что происходит при определённых его действиях. Также диаграмма отображает взаимодействие пользователей в рамках платформы. Так, фермер может размещать объявление и закупать нужные ему товары, а, например, менеджер верифицировать учетные записи и выставлять полномочия пользователям ниже своей роли.
Диаграммы прецедентов относятся к той группе диаграмм, которые представляют динамические или поведенческие аспекты системы. Они являются средством для достижения взаимопонимания между разработчиками, экспертами и конечными пользователями продукта.
5. Диаграмма классов
Диаграмма классов (class diagram) является одной из важнейших диаграмм UML. Она используется для документирования программных систем, и основным ее компонентом является класс. Создание диаграммы классов знаменует собой окончание процесса анализа и начало процесса проектирования. Класс (class) - категория вещей, которые имеют общие атрибуты и операции. Они представляют собой описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой.
При проектировании объектно-ориентированных систем диаграммы классов обязательны. Классы используются в процессе анализа предметной области для составления словаря предметной области разрабатываемой системы. Это могут быть как абстрактные понятия предметной области, так и классы, на которые опирается разработка и которые описывают программные или аппаратные сущности. Информация с диаграммы классов напрямую отображается в исходный код приложения - в большинстве существующих инструментов UML-моделирования возможна кодогенерация для определенного языка программирования (обычно Java или C++). Таким образом, диаграмма классов - конечный результат проектирования и отправная точка процесса разработки.