UML презентация. Унифицированный язык моделирования (Unified Modeling Language,. Унифицированный язык моделирования (Unified Modeling Language, uml)
 Скачать 1.27 Mb.
|
Унифицированный язык моделирования (Unified Modeling Language, UML)План
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++). Таким образом, диаграмма классов - конечный результат проектирования и отправная точка процесса разработки. Диаграмма классов — основной способ описания структуры системы. На диаграмме классов применяется один основной тип сущностей: классы, между которыми устанавливаются основные типы отношений (ассоциации, зависимости, обобщение). Диаграммы классов являются статическим представлением системы. Описание класса может включать множество различных элементов, и чтобы они не путались, в языке предусмотрено группирование элементов описания класса по секциям (compartment). Стандартных секций три: - секция имени — наряду с обязательным именем может содержать также стереотип, кратность и список именованных значений; - секция атрибутов — содержит список описаний атрибутов класса; - секция операций — содержит список описаний операций класса. Как и все основные сущности UML, класс обязательно имеет имя, а стало быть, секция имени не может быть опущена. Прочие секции могут быть пустыми или отсутствовать вовсе. Нотация классов проста — это всегда прямоугольник. Если секций более одной, то внутренность прямоугольника делится горизонтальными линиями на части, соответствующие секциям. В информационной системе, соответствующей сайту фермерской платформы, выделим классы: Витрина, Товары, Документы, Сделки, Пользователь, Доставка, Тип документа, Тип товара. Каждый из этих классов обладает атрибутами, имеющими имя и открытую видимость — предполагается, что манипуляции с именем будут производиться непосредственно. Атрибут имеет тип данных, описывает свойства и характеристики класса. Классы Витрина, Пользователи, Документы и Сделки имеют также операции, которые могут быть вызваны (реализованы) как методы. Между определенными нами классами присутствуют отношения ассоциации, в общем случае ассоциация, нотация которой - сплошная линия, соединяющая классы, означает, что экземпляры одного класса связаны с экземплярами другого класса. Так как экземпляров может быть много и каждый может быть связан с несколькими, ясно, что ассоциация является дескриптором, который описывает множество наборов связанных объектов. В UML ассоциация является классификатором, экземпляры которого называются связями. Для ассоциации предусмотрено наибольшее количество различных дополнений, например, имя ассоциации вместе с направлением чтения, кратность полюса ассоциации и т. д. Возможность навигации для полюса ассоциации - это свойство полюса, имеющее значение типа Boolean и определяющее, можно ли эффективно получить с помощью данной ассоциации доступ к объектам класса, присоединенным к данному полюсу ассоциации. Если навигация для некоторого полюса возможна, то этот полюс отмечают стрелкой на конце линии ассоциации, если же навигация невозможна, то на конце линии ассоциации рисуют крестик. 6. Диаграмма последовательности (sequence diagram) Диаграмма последовательности (sequence diagram) отображает взаимодействие объектов в динамике. Эта диаграмма относится к диаграммам взаимодействия UML, описывающим поведенческие аспекты системы, но рассматривает взаимодействие объектов во времени. Другими словами, диаграмма последовательности отображает временные особенности передачи и приема сообщений объектами во время выполнения одного из возможных сценариев. Диаграммы последовательностей можно и необходимо использовать для уточнения диаграмм прецедентов, более детального описания логики сценариев использования. На диаграмме последовательности применяют один основной тип сущностей — экземпляры взаимодействующих классификаторов (в основном классов, компонентов и действующих лиц), и один тип отношений — связи, по которым происходит обмен сообщениями. Предусмотрено несколько способов посылки сообщений, которые в графической нотации различаются видом стрелки, соответствующей отношению. Важным аспектом диаграммы последовательности является явное отображение течения времени. В отличие от других типов диаграмм, кроме разве что диаграмм синхронизации, на диаграмме последовательности имеет значение не только наличие графических связей между элементами, но и взаимное расположение элементов на диаграмме. А именно, считается, что имеется (невидимая) ось времени, по умолчанию направленная сверху вниз, и то сообщение, которое отправлено позже, нарисовано ниже. Для обозначения самих взаимодействующих объектов применяется стандартная нотация — прямоугольник с именем экземпляра классификатора. Пунктирная линия, выходящая из него, называется линией жизни (lifeline). Это не обозначение отношения в модели, а графический комментарий. Фигуры в виде узких полосок, наложенных на линию жизни, также не являются изображениями моделируемых сущностей. Это графический комментарий, показывающий отрезки времени, в течении которых объект владеет потоком управления (execution occurrence) или, другими словами, имеет место активация (activation) объекта. Составные шаги взаимодействия (combined fragment) позволяют на диаграмме последовательности, отражать и алгоритмические аспекты протокола взаимодействия. Так как диаграмма последовательности реализует один из возможных сценариев поведения системы, можем определить следующие факты. На диаграмме присутствуют только те экземпляры классификаторов, которые задействованы в данном взаимодействии. Прочие экземпляры не показываются, хотя возможно и присутствуют в системе. Отображаются только те связи, которые нужны для передачи данной последовательности сообщений, прочие связи не показываются. Состав сообщений (а тем самым операций и сигналов) определяется назначением данного взаимодействия; в других взаимодействиях эти же экземпляры классификаторов могут обмениваться другими сообщениями. |