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

  • 8.8.5. Пример диаграммы деятельности

  • 8.9. Диаграмма взаимодействия

  • 8.9.1. Диаграмма последовательностей

  • 8.9.2. Диаграмма кооперации

  • 8.9.3. Пример диаграммы взаимодействия

  • 8.10. Диаграмма реализации UML

  • 8.10.1. Диаграмма компонентов

  • 8.10.2. Диаграмма развёртывания

  • Конспект лекций case cals. Конспект_САСТ-2. Конспект лекций по дисциплине case и cals технологии по направлению подготовки


    Скачать 3.53 Mb.
    НазваниеКонспект лекций по дисциплине case и cals технологии по направлению подготовки
    АнкорКонспект лекций case cals
    Дата28.10.2022
    Размер3.53 Mb.
    Формат файлаpdf
    Имя файлаКонспект_САСТ-2.pdf
    ТипКонспект лекций
    #759345
    страница11 из 23
    1   ...   7   8   9   10   11   12   13   14   ...   23
    8.8.4. Объекты
    В потоке управления, ассоциированном с диаграммой деятельности, могут участвовать объекты (Objects), которые либо инициируют выполнение действий, либо определяют результат этих действий. При этом действия специфицируют вызовы, которые передаются от одного объекта графа деятельности другому.
    Рис. 8.24. Графическое изображение дорожек в языке UML
    Графическим представлением объекта в нотации языка UML является прямоугольник класса, с тем отличием, что имя объекта подчёркивается. На диа- граммах деятельности после имени может указываться характеристика состоя- ния объекта в прямых скобках (рис. 8.25). Такие прямоугольники объектов при-

    137 соединяются к состояниям действия отношением зависимости пунктирной лини- ей со стрелкой. Соответствующая зависимость определяет состояние конкретно- го объекта после выполнения предшествующего действия.
    Рис. 8.25. Графическое изображение объекта в языке UML
    Полное имя объекта представляет собой строку текста, разделённую двое- точием и записанную в следующем формате:
    <собственное имя объекта>/<Имя роли класса>:<Имя класса>
    Если объект имеет собственное имя, то оно должно начинаться со строч- ной буквы. Имя роли класса указывается, если в модели отсутствует соответст- вующий класс или необходимо акцентировать внимание на особенности исполь- зования класса в рассматриваемом контексте моделирования взаимодействия.
    Имя класса –– имя одного из классов диаграммы классов.
    Варианты возможных записей полного имени объекта (рис. 8.26):
    –– o : — объект с собственным именем o;
    –– o : C — объект с собственным именем o, являющийся экземпляром класса C;
    –– : C — анонимный объект, являющийся экземпляром класса C;
    –– o/R : C — объект с собственным именем o, являющийся экземпляром класса C и играющий роль R;
    –– /R : C — анонимный объект, являющийся экземпляром класса C и играющий роль R;
    –– o/R — объект с собственным именем o, играющий роль R;

    138
    –– /R — анонимный объект, играющий роль R.
    Рис. 8.26. Варианты возможных записей полного имени объекта в языке
    UML
    В UML все объекты делятся на пассивные и активные (рис. 8.27). Пассив- ный объект оперирует только данными и не может инициировать деятельность по управлению другими объектами, но может посылать сигналы в процессе вы- полнения запросов. У активного объекта есть собственный процесс управления и он может инициировать деятельность по управлению другими объектами (обо- значается прямоугольником с утолщёнными границами). Относящиеся к дея- тельности объекты можно включить в диаграмму деятельности, и с помощью символа зависимости привязать к той деятельности или переходу, где они соз- даются, модифицируются или уничтожаются. Такое сочетание зависимостей и объекта называется траекторией объекта (Object Flow), поскольку описывает его участие в потоке управления.

    139
    Рис. 8.27. Активный и пассивный объекты в языке UML
    На диаграмме деятельности с дорожками расположение объекта может иметь дополнительный смысл. А именно, если объект расположен на границе двух дорожек, то это может означать, что переход к следующему состоянию действия в соседней дорожке ассоциирован с нахождением объекта в некотором состоянии. Если же объект расположен внутри дорожки, то и состояние этого объекта целиком определяется действиями данной дорожки.
    Диаграмму деятельности можно присоединить к любому элементу модели для визуализации, специфицирования, конструирования и документирования поведения этого элемента, в частности, к классам, интерфейсам, компонентам, узлам, прецедентам и кооперациям. Чаще всего диаграммы деятельности при- соединяются к операциям.
    8.8.5. Пример диаграммы деятельности
    В качестве примера можно рассмотреть фрагмент диаграммы деятельности торговой компании, обслуживающей клиентов в форме заказов [13, 12] (рис.
    8.28).
    Подразделениями компании обычно являются отдел приёма и оформления заказов, отдел продаж и склад. Этим подразделениям будут соответствовать три дорожки на диаграмме деятельности, каждая из которых специфицирует зону ответственности подразделения. В этом случае диаграмма деятельности заклю- чает в себе не только информацию о последовательности выполнения рабочих

    140 действий, но и о том, какое подразделение торговой компании должно выпол- нять то или иное действие.
    Рис. 8.28. Пример диаграммы деятельности
    Отделом приёма и оформления заказов фиксируется полученный от клиен- та заказ, после чего он регистрируется в отделе продаж. Затем осуществляется распараллеливание деятельности на два потока (переход-разделение).

    141
    Первый из них остаётся в этом же отделе и связан с получением оплаты от клиента за заказанный товар. Второй инициирует выполнение действия по реги- страции заказа в отделе продаж (модель товара, размеры, цвет, год выпуска и пр.) и передаче товара на склад.
    Однако выдача товара со склада начинается только после того, как от кли- ента будет получена оплата за товар (переход-слияние). Затем выполняется под- готовка товара к отправке и его отправка клиенту в отделе продаж. После завер- шения этих деятельностей заказ закрывается в отделе приёма и оформления за- казов.
    8.9. Диаграмма взаимодействия
    Диаграммой взаимодействия (Interaction Diagram) называется диаграмма, на которой представлено взаимодействие, состоящее из множества объектов и отношений между ними, включая и сообщения, которыми они обмениваются.
    Диаграммы взаимодействия относятся к динамическому виду системы, причём их можно строить двумя способами: упорядочивая по времени сообще- ния или структурно упорядочивая взаимодействующие объекты. Получаемые любым из этих способов диаграммы семантически эквивалентны и преобразуют- ся друг в друга без потери информации. По аспекту взаимодействия диаграммы взаимодействия делятся на диаграммы последовательностей и диаграммы коо- пераций.
    8.9.1. Диаграмма последовательностей
    Диаграммой последовательностей (Sequence Diagram) называется диа- грамма взаимодействий, акцентирующая внимание на временной упорядоченно- сти сообщений, которыми обмениваются объекты системы.
    Графически диаграмма последовательностей представляет собой таблицу, объекты в которой располагаются вдоль оси X, а сообщения в порядке возраста- ния времени — вдоль оси Y . На диаграмме изображаются только объекты, не- посредственно участвующие во взаимодействии.

    142
    Диаграммы последовательностей характеризуются двумя особенностями, отличающими их от диаграмм кооперации: линией жизни объекта и фокусом управления.
    Линия жизни объекта (Object Lifeline) представляет собой вертикальную пунктирную линию, отражающую существование объекта во времени (рис. 8.29).
    При этом каждый объект графически изображается в форме прямоугольника и располагается в верхней части своей линии жизни.
    Рис. 8.29. Графическое изображение различных вариантов линий жизни и фокусов управления объектов в языке UML
    Фокус управления (Focus of Control) изображается в виде вытянутого пря- моугольника, показывающего промежуток времени, в течение которого объект выполняет какое-либо действие непосредственно или с помощью подчинённой процедуры. Верхняя грань прямоугольника выравнивается по временной оси с моментом начала действия, нижняя — с моментом его завершения.
    Отдельные объекты, выполнив свою роль в системе, могут быть уничто- жены, чтобы освободить занимаемые ими ресурсы. Для обозначения момента уничтожения объекта в языке UML используется специальный символ в форме латинской буквы «X» (рис. 8.29).
    Взаимодействие между объектами описывается совокупностью сообще- ний, которыми эти объекты обмениваются между собой. Сообщение (Message) представляет собой законченный фрагмент информации, который инициирует

    143 выполнение определённых действий, направленных на решение некоторой зада- чи тем объектом, которому это сообщение отправлено.
    В UML определены следующие виды действий:
    –– «call» (вызвать) — вызывает операцию, применяемую к объекту;
    –– «return» (возвратить) — возвращает значение вызывающему объекту;
    –– «send» (послать) — посылает объекту сигнал;
    –– «create» (создать) — создаёт новый объект;
    –– «destroy» (уничтожить) — удаляет объект.
    В UML различают следующие сообщения (рис. 8.30):
    –– сообщения для вызова процедур, выполнения операций или обозначе- ния отдельных вложенных потоков управления — всегда выходит из фокуса управления или линии жизни объекта, инициирующего сообщение, и стрелкой соприкасается с линией жизни объекта, которому предназначено сообщение, с возможной передачей фокуса управления (графически — сплошная линия с за- крашенной стрелкой);
    –– сообщения для обозначения простого асинхронного сообщения, переда- ваемого в произвольный момент времени (графически — сплошная линия со стрелкой);
    –– сообщения для возврата из вызова процедуры (графически — пунктир- ная линия со стрелкой или без неё).

    144
    Рис. 8.30. Графическое изображение сообщений, передаваемых между объектами на диаграмме последовательностей в языке UML
    На диаграмме последовательностей все сообщения упорядочены по време- ни своего возникновения в моделируемой системе. Сообщения изображаются в виде горизонтальных стрелок с именем сообщения (или без него) и образуют оп- ределённый порядок относительно времени своей инициализации.
    8.9.2. Диаграмма кооперации
    Диаграммой кооперации (Collaboration Diagram) называется диаграмма взаимодействий, основное внимание в которой уделяется структурной организа- ции объектов, принимающих и отправляющих сообщения. Графически такая диаграмма представляет собой граф из вершин и рёбер.
    Кооперация (Collaboration) представляет собой спецификацию множества объектов отдельных классов, совместно взаимодействующих с целью реализа- ции отдельных вариантов использования в общем контексте моделируемой сис- темы. Кооперация определяет структуру поведения системы в терминах взаимо- действия участников этой кооперации.
    Понятие объекта в языке UML было рассмотрено в разделе 8.8.4.
    Для создания диаграммы кооперации нужно расположить участвующие во взаимодействии объекты в виде вершин графа. Затем связи, соединяющие эти объекты, изображаются в виде дуг этого графа. Связи дополняются сообщения- ми, которые объекты принимают и посылают.
    Диаграммы кооперации характеризуются двумя особенностями, отличаю- щими их от диаграмм последовательностей: путём (связью) и порядковым номе- ром сообщения.
    Путь или связь (Link) используется для описания связи одного объекта с другим. Связи не имеют собственных имён и кратности, но могут использовать- ся следующие стереотипы:

    145
    –– «association» — указывает, что связь является ассоциацией;
    –– «parameter» — указывает, что связь является параметром некоторого метода;
    –– «local» — указывает, что связь является локальной переменной метода, область видимости которой ограничена только соседним объектом;
    –– «global» — указывает, что связь является глобальной переменной, об- ласть видимости которой распространяется на всю диаграмму кооперации;
    –– «self» — указывает, что связь является рефлексивной связью объекта с самим собой (изображается петлёй в верхней части прямоугольника объекта).
    Порядковый номер сообщения используется для обозначения временной последовательности сообщений.
    8.9.3. Пример диаграммы взаимодействия
    На рис. 8.31 приведён пример диаграммы взаимодействия «Телефонный разговор».
    Рис. 8.31. Пример диаграммы взаимодействия «Телефонный разговор»
    Объектами в этом примере являются два абонента a и b, два телефонных аппарата c и d, коммутатор и сам разговор как объект моделирования. При этом

    146 как коммутатор, так и разговор являются анонимными объектами, первый теле- фонный аппарат изображён как активный объект, а второй — как пассивный.
    Все связи на диаграмме специфицированы, на их концах указана информа- ция в форме ролей связей. Заметим, что для объекта «Разговор» указано поме- ченное значение {transient}, которое означает, что этот объект создаётся в про- цессе выполнения объемлющего процесса и уничтожается до его завершения.
    Для того чтобы отобразить структурную организацию потоков управления, на диаграмме изображены все сообщения с указанием их порядка и семантиче- ских особенностей.
    8.10. Диаграмма реализации UML
    Для создания конкретной физической системы необходимо реализовать все элементы логического представления в конкретные материальные сущности.
    Для описания таких реальных сущностей используется физическое представле- ние модели. В контексте языка UML это означает совокупность связанных физи- ческих сущностей, включая программное и аппаратное обеспечение, а также персонал, которые организованы для выполнения специальных задач.
    Физическая система (Physical System) — реально существующий прототип модели системы.
    Базовыми элементами физического представления системы в нотации язы- ка UML являются исполняемые модули, библиотеки классов и процедур, стан- дартных графических интерфейсов, файлов баз данных, которые в совокупности составляют программный код системы. При этом программная система может считаться реализованной, если она будет способна выполнять функции своего целевого предназначения.
    Полный проект программной системы представляет собой совокупность моделей логического и физического представлений, которые должны быть со- гласованы между собой. В языке UML для физического представления моделей систем используются так называемые диаграммы реализации, которые включа-

    147 ют в себя две отдельные канонические диаграммы: диаграмму компонентов и диаграмму развёртывания.
    8.10.1. Диаграмма компонентов
    Диаграмма компонентов — диаграмма, на которой изображена организа- ция некоторого множества компонентов и зависимости между ними.
    Диаграмма компонентов используется для моделирования статического вида системы с точки зрения реализации, т.е. описывает особенности физическо- го представления системы. Этот тип диаграмм позволяет определить архитекту- ру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых могут выступать исходный, бинарный и испол- няемый коды.
    Диаграммы компонентов обычно включают в себя:
    –– компоненты;
    –– интерфейсы;
    –– отношения зависимости, обобщения, ассоциации и реализации.
    Компонент (Component) — физически существующая часть системы, кото- рая обеспечивает реализацию классов и отношений, а также функциональное по- ведение моделируемой программной системы. Компонентом может быть испол- няемый код отдельного модуля, командные файлы или файлы, содержащие ин- терпретируемые скрипты.
    Для графического представления компонента используется специальный символ — прямоугольник со вставленными слева двумя более мелкими прямо- угольниками, внутри которого записывается имя компонента и, возможно, до- полнительная информация (рис. 8.32).

    148
    Рис. 8.32. Графическое изображение компонента в языке UML
    Имя компонента подчиняется общим правилам именования элементов мо- дели в языке UML и может состоять из любого числа букв, цифр и некоторых знаков препинания. При этом, если компонент представляется на уровне типа, то в качестве его имени записывается только имя типа с заглавной буквы, и если компонент представляется на уровне экземпляра, то в качестве его имени запи- сывается <имя компонента> : <Имя типа>.
    В языке UML определены следующие виды компонентов:
    –– компоненты развёртывания — обеспечивают выполнение функций сис- темы (например, динамически подключаемые библиотеки, файлы справки и т.п.);
    –– компоненты «рабочие продукты» (файлы с исходными текстами про- грамм);
    –– компоненты исполнения (исполняемые модули).
    В языке UML для компонентов определены следующие стереотипы:
    –– «library» (библиотека) — компонент в форме динамической или стати- ческой библиотеки;
    –– «table» (таблица) — компонент в форме таблицы базы данных;
    –– «file» (файл) — компонент в виде файла с исходными текстами про- грамм;
    –– «document» (документ) — компонент в форме документа;
    –– «executable» (исполняемый) — компонент, который может исполняться в узле.
    Понятие интерфейса рассматривалось в разделах 8.4.3 и 8.5.3. Поэтому здесь отметим те особенности интерфейсов, которые характерны для их пред- ставления на диаграммах компонентов.
    Интерфейс графически изображается окружностью или в виде прямо- угольника класса со стереотипом «interface» и секцией поддерживаемых опера-

    149 ций (рис. 8.32). Соединяется интерфейс с компонентом отрезком линии без стре- лок, что семантически означает реализацию интерфейса. Наличие интерфейсов у компонента означает, что данный компонент реализует соответствующий набор интерфейсов.
    Рис. 8.33. Графическое изображение интерфейса в языке UML
    Различают два способа связи интерфейса и компонента. Если компонент реализует некоторый интерфейс, то такой интерфейс называют экспортируемым
    (или поддерживаемым), поскольку этот компонент предоставляет его в качестве сервиса другим компонентам. Если же компонент использует некоторый интер- фейс, реализуемый другим компонентом, то такой интерфейс для первого ком- понента называется импортируемым. Особенность импортируемого интерфейса состоит в том, что на диаграмме компонентов это отношение изображается с по- мощью зависимости.
    Отношения зависимости, обобщения, ассоциации и реализации также рас- сматривались ранее в разделах 8.4.4 и 8.5.2. Поэтому отметим только то, что от- ношения зависимости, применительно к диаграмме компонентов, могут связы- вать компоненты и импортируемые ими интерфейсы, а также различные виды компонентов между собой, что изображается пунктирной линией со стрелкой, направленной от клиента или зависимого элемента к источнику или независи- мому элементу модели (рис. 8.34).

    150
    Рис. 8.34. Графическое изображение отношения зависимости на диаграмме компонентов в языке UML
    8.10.2. Диаграмма развёртывания
    Диаграмма развёртывания (Deployment Diagram) — диаграмма, на которой представлена конфигурация обрабатывающих узлов и размещённые на них ком- поненты.
    Диаграмма развёртывания применяется для представления общей конфи- гурации и топологии распределённой программной системы и содержит изобра- жение размещения компонентов по отдельным узлам системы. Кроме того, она показывает наличие физических соединений — маршрутов передачи информа- ции между аппаратными устройствами, задействованными в реализации систе- мы.
    Диаграмма развёртывания содержит графические изображения процессо- ров, устройств, процессов и связей между ними.
    Узел (Node) представляет собой физически существующий элемент систе- мы, который может обладать вычислительным ресурсом или являться техниче- ским устройством.
    Графически узел на диаграмме развёртывания изображается в форме куба
    (рис. 8.35). Узел имеет имя, которое указывается внутри этого графического символа.

    151
    Рис. 8.35. Графическое изображение узла в языке UML
    На диаграмме развёртывания кроме изображения узлов указываются от- ношения между ними (рис. 8.36). В качестве отношений выступают физические соединения между узлами, а также зависимости между узлами и компонентами
    (рис. 8.37).
    Соединения являются разновидностью ассоциации и изображаются отрез- ками линий без стрелок. Наличие такой линии указывает на необходимость ор- ганизации физического канала для обмена информацией между соответствую- щими узлами. Характер соединения может быть дополнительно специфицирован примечанием, стереотипом, помеченным значением или ограничением.
    Рис. 8.36. Графическое изображение отношений между узлами в языке
    UML

    152
    Рис. 8.37. Графическое изображение связи и зависимости между узлами и компонентами в языке UML
    1   ...   7   8   9   10   11   12   13   14   ...   23


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