Главная страница
Навигация по странице:

  • 1 Структура и компоненты языка UML 1.1 Общие принципы

  • 1.2 Сущности

  • Структурные сущности

  • Поведенческие сущности

  • Группирующие сущности

  • Аннотационные сущности

  • 1.2 Отношения В языке UML определены четыре типа отношений

  • 1.2 Диаграммы Диаграмма

  • Лекция языка UML. Лекция №1. Язык UML. Uml пригоден для моделирования любых систем от информационных


    Скачать 54 Kb.
    НазваниеUml пригоден для моделирования любых систем от информационных
    АнкорЛекция языка UML
    Дата06.10.2022
    Размер54 Kb.
    Формат файлаdoc
    Имя файлаЛекция №1. Язык UML.doc
    ТипДокументы
    #717995

    Язык UML

    Унифицированный язык моделирования (UML) является стандартным

    инструментом для создания «чертежей» программного обеспечения. С помощью

    UML можно визуализировать, специфицировать, конструировать и

    документировать артефакты программных систем.

    UML пригоден для моделирования любых систем: от информационных

    систем масштаба предприятия до распределенных Web-приложений и даже

    встроенных систем реального времени. UML – это язык для визуализации,

    специфицирования, конструирования и документирования артефактов

    программных систем. Язык моделирования, подобный UML, является

    стандартным средством для составления «чертежей» программного обеспечения.

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

    большое количество взаимосвязанных моделей. В применении к программным

    системам это означает, что необходим язык, с помощью которого можно с

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

    протяжении цикла ее разработки.

    UML – это графический язык специфицирования, что означает построение

    точных и полных графических моделей, касающиеся __________анализа, проектирования и

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

    развертывания системы программного обеспечения.

    UML – это язык конструирования, и модели, созданные с его помощью,

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

    программирования. Иными словами, UML-модель можно отобразить на такие

    языки, как Java, C++, Visual Basic, и даже на таблицы реляционной базы данных.

    Такое отображение модели на язык программирования позволяет

    осуществлять прямое проектирование: генерацию кода из модели UML в какой-

    то конкретный язык. Можно решить и обратную задачу: реконструировать

    модель по имеющейся реализации.

    UML позволяет решить проблему документирования системной

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

    к системе и определения тестов и, наконец, предоставляет средства для

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

    Использование UML эффективно в:

    · информационных системах масштаба предприятия;

    · банковских и финансовых услугах;

    · телекоммуникациях;

    · на транспорте;

    · оборонной промышленности, авиации и космонавтике;

    · розничной торговле;

    · медицинской электронике;

    23

    · науке;

    · распределенных Web-системах.

    Сфера применения UML не ограничивается моделированием ПО. Он

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

    структуру и функционирование системы обслуживания пациентов в больницах,

    осуществлять проектирование аппаратных средств.

    1 Структура и компоненты языка UML

    1.1 Общие принципы

    Конструктивное использование языка UML основывается на понимании

    общих принципов моделирования сложных систем и особенностей процесса

    объектно-ориентированного анализа и проектирования (ООАП). Выбор

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

    на нескольких принципах.

    Первым является принцип абстрагирования, который предписывает

    включать в модель только те аспекты проектируемой системы, которые имеют

    непосредственное отношение к выполнению системой своих функций или своего

    целевого предназначения. При этом все второстепенные детали опускаются,

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

    модели.

    Вторым принципом построения моделей сложных систем является

    принцип многомодельности. Это значит, что никакое единственное

    представление сложной системы не является достаточным для адекватного

    выражения всех ее особенностей.

    Еще одним принципом прикладного системного анализа является принцип

    иерархического построения моделей сложных систем. Этот принцип

    предписывает рассматривать процесс построения модели на разных уровнях

    абстрагирования или детализации в рамках фиксированных представлений.

    Таким образом, процесс ООАП можно представить как поуровневый спуск

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

    частным и детальным представлениям логического и физического уровня. При

    этом на каждом из этапов ООАП данные модели последовательно дополняются

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

    различные аспекты конкретной реализации сложной системы.

    Объектно-ориентированный анализ и проектирование системы

    предусматривает использование словаря языка UML, включающего _+€ユUтри вида

    строительных блоков: сущности, отношения, диаграммы.

    1.2 Сущности

    Основными объектно-ориентированными блоками являются сущности. В

    языке UML имеется четыре вида сущностей: структурные, поведенческие,

    24

    группирующие, аннотационные.

    Структурные сущности – это имена существительные в моделях на

    языке UML. Они представляют собой статические части модели,

    соответствующие концептуальным или физическим элементам системы.

    Существует пять разновидностей концептуальных и логических сущностей.

    Класс (Class) – это описание совокупности объектов с общими атрибутами,

    операциями, отношениями и семантикой (рис. 3). Класс реализует один или

    несколько интерфейсов.

    Рис. 3 Классы

    Интерфейс (Interface) – это совокупность операций, которые определяют

    набор услуг, предоставляемый классом или компонентом. Интерфейс описывает

    видимое извне поведение элемента (рис. 4). Интерфейс редко существует сам по

    себе – обычно он присоединяется к реализующему его классу или компоненту.

    Рис. 4 Интерфейс

    Кооперация (Collaboration) определяет взаимодействие, и представляет

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

    кооперативный эффект. Кооперация имеет как структурный, так и

    поведенческий аспект, – один и тот же класс может принимать участие в

    нескольких кооперациях (рис. 5).

    Рис. 5 Кооперация

    Прецедент (Use case) – это описание последовательности выполняемых

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

    какого-то определенного актера (Actor). Прецедент применяется для

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

    посредством кооперации (рис. 6).

    Рис. 6 Прецедент

    25

    Активным классом (Active class) называется класс, объекты которого

    вовлечены в один или несколько процессов (Threads), и могут инициировать

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

    что деятельность его объектов осуществляется одновременно с деятельностью

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

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

    включает имя, атрибуты и операции (рис. 7)

    Рис. 7 Активный класс

    Компоненты и узлы соответствуют физическим сущностям системы.

    Компонент (Component) – это физическая заменяемая часть системы,

    соответствующая некоторому набору интерфейсов и обеспечивает его

    реализацию (рис. 8). Компонент – это физическая упаковка логических

    элементов, (классов, интерфейсов и кооперации), например компоненты СОМ+

    или Java Beans, а также файлы исходного кода.

    Рис. 8 Компонент

    Узел (Node) – это элемент, представляющий вычислительный ресурс,

    обладающий памятью и способностью обработки. Совокупность компонентов

    может размещаться в узле, а также мигрировать с одного узла на другой (рис. 9).

    Рис. 9 Узел

    Существуют также разновидности этих семи сущностей: актеры, сигналы,

    утилиты (виды классов), процессы и нити (виды активных классов), приложения,

    документы, файлы, библиотеки, страницы и таблицы (виды компонентов).

    Поведенческие сущности (Behavioral things) являются динамическими

    составляющими модели UML. Это глаголы языка: они описывают поведение

    модели. Существует всего два типа поведенческих сущностей.

    Взаимодействие (Interaction) – это поведение, суть которого заключается в

    обмене сообщениями между объектами для достижения определенной цели. С

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

    совокупности объектов. Взаимодействие предполагает ряд других элементов,

    таких как сообщение (рис. 10), последовательность действий (поведение,

    26

    инициированное сообщением) и связь (между объектами).

    Рис. 10 Сообщение

    Автомат (State machine) – это алгоритм поведения, определяющий

    последовательность состояний, через которые объект или взаимодействие

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

    события, а также реакции на эти события (рис. 11). С помощью автомата можно

    описать поведение отдельного класса или кооперации классов. С автоматом

    связан ряд других элементов: состояния, переходы (из одного состояния в

    другое), события (сущности, инициирующие переходы) и виды действий

    (реакция на переход).

    Рис. 11 Состояние

    Взаимодействия и автоматы семантически связаны с различными

    структурными элементами, такими как классы, кооперации и объекты.

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

    блоки, на которые можно разложить модель. Основной группирующей

    сущностью является пакет.

    Пакет (Package) – это универсальный механизм организации элементов в

    группы (рис. 12). В пакет можно поместить структурные, поведенческие и даже

    другие группирующие сущности. В отличие от компонентов, существующих во

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

    существуют только во время разработки.

    Рис. 12 Пакеты

    Существуют также вариации пакетов, например каркасы (Frameworks),

    модели и подсистемы.

    Аннотационные сущности – пояснительные части модели UML. Это

    комментарии для дополнительного описания, разъяснения или замечания к

    любому элементу модели. Имеется только один базовый тип аннотационных

    элементов – примечание.

    Примечание (Note) – это символ для изображения комментариев,

    присоединенных к элементу или группе элементов (рис. 13).

    27

    Рис. 13 Примечание

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

    или ограничениями, которые можно выразить в виде неформального или

    формального текста. Существуют вариации этого элемента, например

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

    внешней по отношению к модели.

    1.2 Отношения

    В языке UML определены четыре типа отношений: зависимость,

    ассоциация, обобщение, реализация. Эти отношения являются основными

    связующими строительными блоками в UML.

    Зависимость (Dependency) – это семантическое отношение между двумя

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

    повлиять на семантику другой, зависимой (рис. 14).

    Рис. 14 Отношения зависимости

    Ассоциация (Association) – отношение, описывающее совокупность связей

    между объектами. Разновидностью ассоциации является агрегирование

    (Aggregation) – структурное отношение между целым и его частями (рис. 15).

    Графическое изображение ассоциации может включать кратность и имена ролей

    (рис. 16).

    Рис. 15 Агрегирование

    Рис. 16 Имена ассоциаций

    Обобщение (Generalization) – это отношение “специализация/обобщение”

    28

    (рис. 17), при котором объект специализированного элемента (потомок) может

    быть подставлен вместо объекта обобщенного элемента (родителя или предка).

    Таким образом, потомок (Child) наследует структуру и поведение своего

    родителя (Parent).

    Рис. 17 Обобщение

    Наконец, реализация (Realization) – это отношение между

    классификаторами, при котором один классификатор определяет “контракт”, а

    другой гарантирует его выполнение (рис. 18).

    Рис. 18 Реализация

    Отношения реализации встречаются в двух случаях: во-первых, между

    интерфейсами и реализующими их классами или компонентами, а во-вторых,

    между прецедентами и реализующими их кооперациями.

    1.2 Диаграммы

    Диаграмма в UML – это графическое представление набора элементов,

    изображаемое в виде связанного графа с вершинами (сущностями) и ребрами

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

    В UML выделяют 8 типов диаграмм (рис. 19).

    29

    Рис. 19 Интегрированная модель сложной системы в нотации UML

    На диаграмме классов (Class diagram) изображаются классы, интерфейсы,

    объекты и кооперации, а также их отношения. Используется при моделировании

    объектно-ориентированных систем.

    На диаграмме вариантов использования (Use case diagram) представлены

    прецеденты и актеры (частный случай классов), а также отношения между ними.

    Они используются при моделировании поведения системы.

    Диаграммы последовательностей (Sequence diagram) и кооперации

    (Collaboration diagram) являются частными случаями диаграмм взаимодействия.

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

    (сообщения, которыми объекты могут обмениваться). Диаграммы

    взаимодействия относятся к динамическому виду системы. При этом диаграммы

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

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

    сообщениями объектов. Эти диаграммы могут быть преобразованы друг в друга.

    На диаграммах состояний (Statechart diagrams) представлен автомат,

    включающий состояния, переходы, события и виды действий. Диаграммы

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

    кооперации, зависящем от последовательности событий.

    Диаграмма деятельности (Activity diagram) представляют переходы

    потока управления между объектами от одной деятельности к другой внутри

    системы.

    Диаграмма компонентов (Component diagram) представляет зависимости

    между компонентами. Диаграммы компонентов отображаются на один или

    несколько классов, интерфейсов или коопераций.

    На диаграмме развертывания (Deployment diagram) представлена

    конфигурация обрабатывающих узлов системы и размещенных в них

    компонентов.__


    написать администратору сайта