Язык моделирования UML
Особенности составных частей концептуальной модели, сущностей и отношений Unified Modeling Language – языка графического описания для объектного моделирования в области разработки программного обеспечения. Анализ видов диаграмм для моделирования.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | контрольная работа |
| Язык | русский |
| Дата добавления | 10.11.2016 |
| Размер файла | 1,2 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
1. Унифицированный язык моделирования UML
Большинство существующих методов объектно-ориентированного анализа и проектирования (ООАП) включают как язык моделирования, так и описание процесса моделирования. Язык моделирования- это нотация (в основном графическая), которая используется методом для описания проектов.
Нотация представляет собой совокупность графических объектов, которые используются в моделях; она является синтаксисом языка моделирования. Например, нотация диаграммы классов определяет, каким образом представляются такие элементы и понятия, как класс, ассоциация и множественность.
Процесс - это описание шагов, которые необходимо выполнить при разработке проекта.
Унифицированный язык моделирования UML(Unified Modeling Language) - это преемник того поколения методов ООАП, которые появились в конце 80-х и начале 90-х гг.
Язык UML представляет собой общецелевой язык визуального моделирования, который разработан для спецификации, визуализации, проектирования и документирования компонентов программного обеспечения, бизнес-процессов и других систем. Язык UML одновременно является простым и мощным средством моделирования, который может быть эффективно использован для построения концептуальных, логических и графических моделей сложных систем самого различного целевого назначения.
2. Язык моделирования UML
UML (унифицированный язык моделирования) - язык графического описания для объектного моделирования в области разработки программного обеспечения. Он использует графические обозначения для создания модели системы. Данный язык был создан для определения, визуализации, проектирования и документирования программных систем, а также его используют для моделирования бизнес-процессов, системного проектирования.
Описание унифицированного языка моделирования UML
Концептуальная модель UML (концептуальную модель включает: основные строительные блоки языка; правила их сочетания; некоторые общие для всего языка механизмы)
3. Концептуальная модель UML
Для понимания UML необходимо усвоить его концептуальную модель, которая включает в себя три составные части:
- основные строительные блоки языка;
- правила их сочетания;
- некоторые общие для всего языка механизмы.
Словарь языка UML включает три вида строительных блоков:
- сущности;
- отношения;
- диаграммы.
Сущности- это абстракции, являющиеся основными элементами модели.Отношениясвязывают различные сущности;диаграммыгруппируют представляющие интерес совокупности сущностей.
В UML имеется четыре типа сущностей:
- структурные;
- поведенческие;
- группирующие;
- аннотационные.
Сущности являются основными объектно-ориентированными блоками языка. С их помощью можно создавать корректные модели.
Структурные сущности - это имена существительные в моделях на языке UML. Как правило, они представляют собой статические части модели, соответствующие концептуальным или физическим элементам системы. Существуетнесколько разновидностей структурных сущностей.
Класс(Class) - это описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой. Класс реализует один или несколько интерфейсов.Графически класс изображается в виде прямоугольника, в котором обычно записаны его имя, атрибуты и операции, как показано на рисунке.
Интерфейс(Interface) - это совокупность операций, которые определяют сервис (набор услуг), предоставляемый классом или компонентом. Таким образом, интерфейс описывает видимое извнеповедение элемента. Интерфейс может представлять поведение класса или компонента полностью или частично; он определяет только спецификации операций (сигнатуры), но никогда - их реализации.Графически интерфейс изображается в виде круга, под которым пишется его имя, как показано на рисунке. Интерфейс редко существует сам по себе - обычно он присоединяется к реализующему его классу или компоненту.
Кооперация(Collaboration) определяет взаимодействие; она представляет собой совокупность ролей и других элементов, которые, работая совместно, производят некоторый кооперативный эффект, не сводящийся к простой сумме слагаемых. Кооперация, следовательно, имеет как структурный, так и поведенческий аспект. Один и тот же класс может принимать участие в нескольких кооперациях; таким образом, они являются реализацией образцов поведения, формирующих систему. Графически кооперация изображается в виде эллипса, ограниченного пунктирной линией, в который обычно заключено только имя, как показано на рисунке.
Прецедент(Use case) - это описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-то определенногоактера(Actor). Прецедент применяется дляструктурирования поведенческих сущностей модели. Прецеденты реализуются посредством кооперации. Графическипрецедент изображается в виде ограниченного непрерывной линией эллипса, обычно содержащего только его имя, как показано на рисунке.
Компонент(Component) - это физическая заменяемая часть системы, которая соответствует некоторому набору интерфейсов и обеспечивает его реализацию. В системе можно встретить различные виды устанавливаемых компонентов, такие как СОМ+ или Java Beans, а также компоненты, являющиеся артефактами процесса разработки, например файлы исходного кода. Компонент, как правило, представляет собой физическую упаковку логических элементов, таких как классы, интерфейсы и кооперации. Графически компонент изображается в виде прямоугольника с вкладками, содержащего обычно только имя, как показано на рисунке. Компонент подобен классу: он описывает совокупность объектов с общими атрибутами, операциями, отношениями и семантикой.
Эти базовые элементы - классы, интерфейсы, кооперации, прецеденты и компоненты- являются основными структурными сущностями, которые могут быть включены в модель UML Существуют также разновидности этих сущностей: актеры, сигналы, утилиты(виды классов),процессы и нити(виды активных классов),приложения,документы,файлы,библиотеки,страницыитаблицы(виды компонентов).
Поведенческие сущности(Behavioral things) являются динамическими составляющими модели UML. Это глаголы языка: они описывают поведение модели во времени и пространстве. Существует всего два основных типа поведенческих сущностей.
Взаимодействие(Interaction) - это поведение, суть которого заключается в обмене сообщениями(Messages) между объектами в рамках конкретного контекста для достижения определенной цели. С помощью взаимодействия можно описать как отдельную операцию, так и поведение совокупности объектов. Взаимодействие предполагает ряд других элементов, таких как сообщения, последовательности действий (поведение, инициированное сообщением) и связи (между объектами).Графически сообщения изображаются в виде стрелки, над которой почти всегда пишется имя соответствующей операции, как показано на рисунке.
Автомат(State machine) - это алгоритм поведения, определяющий последовательность состояний, через которые объект или взаимодействие проходят на протяжении своего жизненного цикла в ответ на различные события, а также реакции на эти события. С помощью автомата можно описать поведение отдельного класса или кооперации классов. С автоматом связан ряд других элементов: состояния, переходы (из одного состояния в другое), события (сущности, инициирующие переходы) и виды действий (реакция на переход).Графически состояние изображается в виде прямоугольника с закругленными углами, содержащего имя и, возможно, под состояния.
Эти два элемента - взаимодействия и автоматы- являются основными поведенческими сущностями, входящими в модель UML. Семантически они часто бывают связаны с различными структурными элементами, в первую очередь - классами, кооперациями и объектами.
Группирующие сущности являются организующими частями модели UML. Это блоки, на которые можно разложить модель. Есть только одна первичная группирующая сущность, а именно пакет.
Пакеты(Packages) представляют собой универсальный механизм организации элементов в группы. В пакет можно поместить структурные, поведенческие и даже другие группирующие сущности. В отличие от компонентов, существующих во время работы программы, пакеты носят чисто концептуальный характер, то есть существуют только во время разработки. Изображается пакет в виде папки с закладкой, содержащей, как правило, только имя и иногда - содержимое.
Пакеты- это основные группирующие сущности, с помощью которых можно организовать модель UML. Существуют также вариации пакетов, например каркасы (Frameworks), модели и подсистемы.
Аннотационные сущности- пояснительные части модели UML. Это комментарии для дополнительного описания, разъяснения или замечания к любому элементу модели. Имеется только один базовый тип аннотационных элементов - примечание(Note).
Примечание - это просто символ для изображения комментариев или ограничений, присоединенных к элементу или группе элементов. Графически примечание изображается в виде прямоугольника с загнутым краем, содержащим текстовый или графический комментарий, как показано на рисунке. unified modeling language моделирование
Этот элемент является основной аннотационной сущностью, которую можно включать в модель UML. Чаще всего примечания используются, чтобы снабдить диаграммы комментариями или ограничениями, которые можно выразить в виде неформального или формального текста. Существуют вариации этого элемента, например требования, где описывают некое желательное поведение с точки зрения внешней по отношению к модели.
В языке UML определены четыре типа отношений:
- зависимость;
- ассоциация;
- обобщение;
- реализация.
Эти отношения являются основными связующими строительными блоками в UML и применяются для создания корректных моделей.
Зависимость(Dependency) - это семантическое отношение между двумя сущностями, при котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой.Графически зависимость изображается в виде прямой пунктирной линии, часто со стрелкой, которая может содержать метку.
Ассоциация(Association) - структурное отношение, описывающее совокупность связей; связь - это соединение между объектами. Разновидностью ассоциации является агрегирование (Aggregation) - так называют структурное отношение между целым и его частями. Графически ассоциация изображается в виде прямой линии (иногда завершающейся стрелкой или содержащей метку), рядом с которой могут присутствовать дополнительные обозначения, например кратность и имена ролей. На рисунке показан пример отношений этого типа.
Обобщение(Generalization) - это отношение «специализация/обобщение», при котором объект специализированного элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (родителя или предка). Таким образом, потомок (Child) наследует структуру и поведение своего родителя (Parent).Графически отношение обобщения изображается в виде линии с не закрашенной стрелкой, указывающей на родителя, как показано на рисунке.
Реализация(Realization) - это семантическое отношение между классификаторами, при котором один классификатор определяет «контракт», а другой гарантирует его выполнение. Отношения реализации встречаются в двух случаях: во-первых, между интерфейсами и реализующими их классами или компонентами, а во-вторых, между прецедентами и реализующими их кооперациями. Отношение реализации изображается в виде пунктирной линии с не закрашенной стрелкой, как нечто среднее между отношениями обобщения и зависимости.
Четыре описанных элемента являются основными типами отношений, которые можно включать в модели UML. Существуют также их вариации, например уточнение (Refinement), трассировка (Trace), включение и расширение (для зависимостей).
4. Виды диаграмм для моделирования
Диаграммы вариантов использования.
На рисунке показаны некоторые варианты использования для системы торговой организации; человеческие фигурки здесь обозначают действующих лиц, овалы - варианты использования, а линии и стрелки - различные связи между действующими лицами и вариантами использования.
Рисунок 1--Диаграмма вариантов использования.
Действующее лицо (actor) - это роль, которую пользователь играет по отношению к системе. На рисунке четыре действующих лица: Менеджер по продажам, Оптовый торговец, Продавец и Система учета. Действующие лица представляют собой роли, а не конкретных людей или наименования работ. Несмотря на то, что на диаграммах вариантов использования они изображаются в виде стилизованных человеческих фигурок, действующее лицо может также быть внешней системой, которой необходима некоторая информация от данной системы (например, Система учета). Показывать на диаграмме действующих лиц системы следует только в том случае, когда им действительно необходимы некоторые варианты использования.
Диаграммы классов.
Диаграммы классов являются центральным звеном объектно-ориентированных методов. Диаграмма классов определяет типы объектов системы и различного рода статические связи, которые существуют между ними. Имеются два основных вида статических связей:
- ассоциации (например, клиент может сделать заказ);
- подтипы (частный клиент является разновидностью клиента).
На диаграммах классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между объектами. На рисунке изображена типичная диаграмма классов.
Рисунок 2-Диаграмма классов.
Перед тем как приступить к описанию диаграмм классов, следует обратить внимание на один важный момент, связанный с характером использования этих диаграмм разработчиками. Этот момент обычно никак не документируется, однако оказывает существенное воздействие на способ интерпретации диаграмм и поэтому имеет важное отношению к тому, что описывается с помощью модели.
Диаграммы взаимодействия.
Диаграммы взаимодействия (interaction diagrams) являются моделями, описывающими поведение взаимодействующих групп объектов. Как правило, диаграмма взаимодействия охватывает поведение объектов в рамках только одного варианта использования. На такой диаграмме отображаются ряд объектов и те сообщения, которыми они обмениваются между собой.
Проиллюстрируем данный подход на примере достаточно простого варианта использования, который описывает следующее поведение:
- Окно Ввода Заказа посылает Заказу сообщение "приготовиться";
- Заказ посылает данное сообщение каждой Строке заказа в данном Заказе;
- Каждая Строка заказа проверяет состояние определенного Запаса товара: Если данная проверка удовлетворяется (результат -- true), то Строка заказа удаляет соответствующее количество товара из Запаса.
В противном случае количество Запаса снижается до уровня повторного заказа, и Запас запрашивает новую поставку товара.
Существуют два вида диаграмм взаимодействия:
- диаграммы последовательности (sequence diagrams);
- кооперативные диаграммы (collaboration diagrams).
У разных разработчиков имеются различные предпочтения вида диаграммы взаимодействия. В диаграмме последовательности делается акцент именно на последовательность сообщений: легче наблюдать порядок, в котором происходят различные события. На кооперативной диаграмме можно использовать пространственное расположение объектов для того, чтобы показать их статическое взаимодействие.
Одним из принципиальных свойств любой формы диаграммы взаимодействия является их простота. Посмотрев на диаграмму, можно легко увидеть все сообщения. Однако если попытаться изобразить нечто более сложное, чем единственный последовательный процесс без особых условных переходов или циклов, такой подход не сработает.
Диаграммы взаимодействия наиболее хороши, когда они отображают простое поведение; при более сложном поведении они быстро теряют свою ясность и наглядность. Если нужно показать сложное поведение системы на одной диаграмме, то следует использовать диаграмму деятельностей.
Диаграммы взаимодействия следует использовать, когда нужно описать поведение нескольких объектов в рамках одного варианта использования. Они хороши для отображения взаимодействия между объектами и вовсе не так хороши для точного описания их поведения.
Если нужно описать поведение единственного объекта во многих вариантах использования, то следует применить диаграмму состояний. Если же описывается поведение во многих вариантах использования или многих параллельных процессах, следует рассмотреть диаграмму деятельностей.
Диаграммы состояний.
Диаграммы состояний - хорошо известное средство описания поведения систем. Они определяют все возможные состояния, в которых может находиться конкретный объект, а также процесс смены состояний объекта в результате наступления некоторых событий. В большинстве объектно-ориентированных методов диаграммы состояний строятся для единственного класса и отражают динамику поведения единственного объекта.
Существует много форм диаграмм состояний, незначительно отличающихся друг от друга семантикой. Наиболее популярная форма, используемая в объектно-ориентированных методах, впервые применялась в методе ОМТ и впоследствии была адаптирована Гради Бучем.
На рисунке показана диаграмма состояний UML, отражающая поведение заказа в системе обработки заказов. На диаграмме изображены различные состояния, в которых может находиться заказ.
Рисунок 3-Диаграмма состояний.
Процесс начинается с начальной точки, затем следует самый первый переход в состояние Проверка позиции заказа. Метка этого перехода - «получить первую позицию заказа». Синтаксически метка перехода состоит из трех частей, каждая из которых является необязательной: <Событие> [<Условие>]/<Действие>. В данном случае метка включает только действие «получить первую позицию заказа». После выполнения этого действия мы попадаем в состояние Проверка позиции заказа. С этим состоянием связана деятельность, которая обозначается меткой со следующим синтаксисом: выполнить/деятельность. В данном случае деятельность называется «проверить позицию».
Диаграммы деятельности.
В отличие от большинства других средств UML диаграммы деятельностей основаны на нескольких различных методах, в частности методе моделирования состояний SDL и сетях Петри.
Эти диаграммы особенно полезны в описании поведения, включающего большое количество параллельных процессов.
Рисунок 4-Диаграмма деятельности.
На рисунке основным элементом является деятельность. Интерпретация этого термина зависит от той точки зрения, с которой строится данная диаграмма. На концептуальной диаграмме деятельность - это некоторая задача, которую необходимо выполнить вручную или автоматизированным способом. На диаграмме, построенной в аспекте спецификации или реализации, деятельность представляет собой некоторый метод над классом.
Диаграммы реализации.
Диаграммы реализации предназначены для отображения состава компилируемых и выполняемых модулей системы, а так же связей между ними. Диаграммы реализаций разделяются на два конкретных вида: диаграммы компонентов (component diagrams) и диаграммы развертывания (deployment diagrams).
Диаграмма компонентов отражает зависимости составных частей программного обеспечения, в которые включаются файлы исходных текстов, двоичные файлы библиотек объектных модулей и исполняемые файлы. Она состоит из компонентов и отношений между ними. Используются отношения двух типов:
- зависимость - это зависимость любого типа (использование, совместная компиляция);
- композиция - это включение одних компонентов в состав других.
Компонент изображается в виде прямоугольника с двумя маленькими прямоугольниками у левого края, внутри прямоугольника записывается имя компонента.
Зависимость изображается штриховой линией от использующего компонента к используемому. Композиция (или включение) изображается размещением включаемого компонента внутри включающего. Компоненты могут иметь интерфейсы, через которые выражаются зависимости. Интерфейсами могут являться, например, имена вызываемых подпрограмм. Интерфейсы изображаются окружностями, соединенными с компонентой линией без направления, рядом записывается имя интерфейса.
Диаграммы развертывания показывают конфигурацию исполняемой программной системы, состоящей из программных компонентов, процессов, объектов. Она состоит из узлов и отношений взаимодействия между узлами и компонентами. Узлы могут включать компоненты и объекты.
Узлы представляют собой физические элементы времени выполнения, обозначающие вычислительный ресурс, обладающий как минимум запоминающим устройством и возможно вычислительным устройством. Узлы могут обозначать компьютеры, человеческие ресурсы или механические устройства. Внутри узлов могут содержаться компоненты и объекты, что обозначает, что данный компонент или объект существует в рамках данного узла. Узлы изображаются как проекция трехмерного куба. Узел может представлять собой тип узла или конкретный экземпляр узла. В зависимости от этого происходит именования узла. В случае узла - типа его имя выглядит так:
имя типа,
в случае узла - экземпляра имя выглядит так:
имя узла: имя типа.
На диаграмме развертывания компоненты могут представлять не только типы, но и конкретные экземпляры, поэтому их имя может быть дополнено именем типа через двоеточие.
Отношение взаимодействия между узлами, компонентами или объектами обозначается штриховой линией, направленной от использующего элемента к используемому.
Диаграммы компонентов
Диаграммы компонентов показывают, как выглядит модель системы на физическом уровне. На диаграмме изображены компоненты программного обеспечения и связи между ними. При этом выделяют два типа компонентов: исполняемые компоненты и библиотеки кода.
Каждый класс модели преобразуется в компонент исходного кода. После создания они сразу добавляются к диаграмме компонентов. Между отдельными компонентами изображают зависимости, соответствующие зависимостям на этапе компиляции или выполнения программы.
На рисунке изображена одна из диаграмм компонентов для некоторой системы обслуживания банкоматов архитектуры клиент-сервер.
Рисунок 5-Диаграмма компонентов.
На этой диаграмме показаны компоненты клиента системы. В данном случае система строится с помощью языка C++. У каждого класса имеется свой собственный заголовочный файл и файл с расширением .СРР, так что каждый класс преобразуется в свои собственные компоненты на диаграмме. Например, некоторый класс Screen преобразуется в два компонента, представляющие тело и заголовок класса Screen. Выделенный темным компонент называется спецификацией пакета (package specification) и соответствует файлу тела класса Screen на языке C++ (файл с расширением .СРР). Невыделенный компонент также называется спецификацией пакета, но соответствует заголовочному файлу класса языка C++ (файл с расширением .Н). Компонент Client.exe является исполняемой программой.
Компоненты соединены штриховой линией, что соответствует зависимостям между ними. Например, класс CardReader зависит от класса Screen. Это означает, что, для того чтобы класс CardReader мог быть скомпилирован, класс Screen должен уже существовать. После компиляции всех классов может быть создан исполняемый файл Client.exe.
Диаграммы размещения.
Диаграмма размещения (deployment diagram) отражает физические взаимосвязи между программными и аппаратными компонентами системы. Она является хорошим средством для того, чтобы показать маршруты перемещения объектов и компонентов в распределенной системе.
Каждый узел на диаграмме размещения представляет собой некоторый тип вычислительного устройства, в большинстве случаев - часть аппаратуры. Эта аппаратура может быть простым устройством или датчиком, а может быть и мэйнфреймом. На рисунке изображен персональный компьютер, связанный с UNIX-сервером посредством протокола TCP/IP (Transmission Control Protocol/Internet Protocol - протокол управления передачей - протокол Интернет). Связи между узлами показывают коммуникационные каналы, с помощью которых осуществляются системные взаимодействия. Компоненты на диаграмме размещения представляют собой физические модули программного кода. Как правило, они в точности соответствуют компонентам на диаграмме компонентов. Таким образом, диаграмма размещения отражает выполнение каждого компонента в системе.
Рисунок 6-Диаграмма размещения
Список литературы
1. Мартин Фаулер. UML. Основы, 3 е издание. Спб Символ 2005 г.
2. Джим Арлоу и Айла Нейштадт.. UML 2 и Унифицированный процесс, 2 е издание. Спб Символ 2008 г.
3. Грейди Буч, Джеймс Рамбо, Айвар Джекобсон. UML. Руководство пользователя. Спб ДМК пресс 2000 г.
Размещено на Allbest.ru
Подобные документы
Характеристика UML как унифицированного графического языка моделирования для описания, визуализации, проектирования и документирования объектно-ориентированных систем. Диаграмма программного обеспечения, деятельности, последовательности и реализации UML.
курсовая работа [439,9 K], добавлен 05.06.2014UML (Unified Modeling Language) как унифицированный графический язык моделирования. Диаграмма программного обеспечения, диаграмма деятельности, последовательности и реализации UML. IDEF0 как нотация описания бизнес-процессов, основана на методологии SADT.
курсовая работа [460,0 K], добавлен 21.06.2014Описание бизнес-процесса "Химчистка" в визуальной среде Visual Paradigm UML 2.0. Основные виды взаимодействия между актерами и вариантами использования. Составление диаграммы классов, последовательности, коммуникаций и состояний. Кодогенерация на Delphi.
контрольная работа [1,4 M], добавлен 04.04.2011Использование моделирования в программной инженерии в процессе разработки программного обеспечения. Основные этапы процесса разработки программного обеспечения, их характеристика. Моделирование процессов, их определение фазами и видами деятельности.
реферат [2,2 M], добавлен 25.12.2017Теория и основные этапы моделирования бизнес-процессов. Метод объектно-ориентированного анализа и проектирования. Особенности методологии ARIS. Метод, используемый в технологии Rational Unified Process. Связь функционального и имитационного моделирования.
презентация [531,0 K], добавлен 22.10.2014Сущность принципов информационной достаточности, осуществимости, множественности моделей, параметризации и агрегирования. Построение концептуальной модели. Сравнение размеров программного кода. Особенности технологии компьютерного моделирования.
презентация [49,3 K], добавлен 16.10.2013Технология разработки и тестирования программного обеспечения в среде Visual Studio на примере создания программы моделирования систем массового обслуживания. Аналитические и имитационные методы моделирования с разными дисциплинами обслуживания заявок.
дипломная работа [1,1 M], добавлен 09.09.2012Основные теоретические положения объектно–ориентированной технологии программирования. Характеристика языка и словарь моделирования UML. Представление управления моделью. Построение диаграммы классов и описание функционирования предметной области.
курсовая работа [859,4 K], добавлен 11.05.2015UML как язык моделирования, используемый архитектором при разработке дизайна системы для создания описания основных, важных аспектов программного обеспечения. Диаграмма прецедентов (UseCase), классов, видов деятельности, компонентов, последовательностей.
отчет по практике [633,1 K], добавлен 22.07.2012Понятие технологии разработки программного обеспечения и модели жизненного цикла. Сущность объектно-ориентированного подхода. Строительные блоки, общие механизмы языка моделирования UML, диаграммы классов, состояний, взаимодействий и компонентов.
курсовая работа [262,5 K], добавлен 10.07.2014
