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

  • 22 МЕТОДОЛОГИЯ UML: ДИАГРАММЫ СОСТОЯНИЙ

  • 22.1 Диаграммы состояний Диаграмма состояний

  • Срабатывание перехода

  • 22.2 Диаграммы кооперации Кооперации

  • 22.3 Диаграммы деятельности

  • Состояние деятельности

  • Состояние под-деятельности

  • 22.4 Диаграммы компонентов

  • Лекции по предмету проектирование асоиу


    Скачать 0.94 Mb.
    НазваниеЛекции по предмету проектирование асоиу
    Дата20.08.2019
    Размер0.94 Mb.
    Формат файлаpdf
    Имя файлаlekcii-proektirovanie-avtomatizirovannyh-sistem-obrabotki-i-upra.pdf
    ТипЛекции
    #85227
    страница7 из 9
    1   2   3   4   5   6   7   8   9
    Фокус управления – специальный символ, указывающий период времени, в течение которого объект выполняет некоторое действие, находясь в активном состоянии. Изображается в форме вытянутого узкого прямоугольника, верхняя сторона которого обозначает начало активности, а ее нижняя сторона – окончание активности. Этот прямоугольник располагается ниже обозначения соответствующего объекта и может заменять его линию жизни, если на всем ее протяжении он активен.
    На диаграмме последовательности все сообщения упорядочены по времени своей передачи в моделируемой системе, хотя номера у них могут не указываться.
    На диаграммах последовательности могут присутствовать три разновидности сообщений, каждое из которых имеет свое графическое изображение (рисунок 24.13).
    Рисунок 24.13 – Виды сообщений между объектами на диаграмме последовательности
    Первая разновидность сообщения наиболее распространена и используется для вызова процедур, выполнения операций или обозначения отдельных вложенных потоков управления. Начало этой стрелки, как правило, соприкасается с фокусом управления того объекта-клиента, который инициирует это сообщение. Конец стрелки соприкасается с линией жизни того объекта, который принимает это сообщение и выполняет в ответ определенные
    78
    действия. При этом принимающий объект может получить фокус управления, становясь в этом случае активным. Передающий объект может потерять фокус управления или остаться активным.
    Вторая разновидность сообщения используется для обозначения простого асинхронного сообщения, которое передается в произвольный момент времени.
    Передача такого сообщения обычно не сопровождается получением фокуса управления объектом-получателем.
    Третья разновидность сообщения используется для возврата из вызова процедуры. Примером может служить простое сообщение о завершении вычислений без предоставления результата расчетов объекту-клиенту. В процедурных потоках управления эта стрелка может быть опущена, поскольку ее наличие неявно предполагается в конце активизации объекта. В тоже время считается, что каждый вызов процедуры имеет свою пару – возврат вызова. Для непроцедурных потоков управления, включая параллельные и асинхронные сообщения, стрелка возврата должна указываться явным образом.
    79

    22 МЕТОДОЛОГИЯ UML: ДИАГРАММЫ СОСТОЯНИЙ,
    КООПЕРАЦИИ, ДЕЯТЕЛЬНОСТИ И КОМПОНЕНТОВ
    22.1 Диаграммы состояний
    Диаграмма состояний – диаграмма, которая представляет конечный автомат.
    Главное назначение диаграммы состояний – описать возможные последовательности состояний и переходов, которые в совокупности характеризуют поведение моделируемой системы в течение всего ее жизненного цикла. Диаграмма состояний представляет динамическое поведение сущностей, на основе спецификации их реакции на восприятие некоторых конкретных событий. Системы, которые реагируют на внешние действия от других систем или от пользователей, иногда называют реактивными. Если такие действия инициируются в произвольные случайные моменты времени, то говорят об асинхронном поведении модели.
    Диаграммы состояний чаще всего используются для описания поведения отдельных систем и подсистем. Они также могут быть применены для спецификации функциональности экземпляров отдельных классов, т. е. для моделирования всех возможных изменений состояний конкретных объектов.
    Диаграмма состояний по существу является графом специального вида, который служит для представления конечного автомата.
    Конечный автомат – модель для спецификации поведения объекта в форме последовательности его состояний, которые описывают реакцию объекта на внешние события, выполнение объектом действий, а также изменение его отдельных свойств.
    Основными понятиями, характеризующими конечный автомат, являются состояние и переход. Ключевое различие между ними заключается в том, что длительность нахождения системы в отдельном состоянии существенно превышает время, которое затрачивается на переход из одного состояния в другое. Предполагается, что в пределе время перехода из одного состояния в другое равно нулю.
    80

    Состояние – условие или ситуация в ходе жизненного цикла объекта, в течение которого он удовлетворяет логическому условию, выполняет определенную деятельность или ожидает события.
    Состояние на диаграмме изображается прямоугольником со скругленными вершинами (рисунок 25.1). Этот прямоугольник может быть разделен на две секции. В первой записывается имя состояния, а во второй – список некоторых внутренних действий или переходов в данном состоянии.
    Рисунок 25.1 – Состояние на диаграмме состояний
    Действие – спецификация выполнимого утверждения, которая образует абстракцию вычислительной процедуры.
    Действие обычно приводит к изменению состояния системы, и может быть реализовано посредством передачи сообщения объекту, модификацией связи или значения атрибута. Для ряда состояний может потребоваться дополнительно указать действия, которые должны быть выполнены моделируемым элементом. Для этой цели служит добавочная секция в обозначении состояния, содержащая перечень внутренних действий или деятельность, которые производятся в процессе нахождения моделируемого элемента в данном состоянии.
    Кроме обычных состояний на диаграмме состояний могут размещаться псевдосостояния.
    Псевдосостояние – вершина в конечном автомате, которая имеет форму состояния, но не обладает поведением.
    Примерами псевдосостояний, которые определены в языке UML, являются начальное и конечное состояния.
    Начальное состояние – разновидность псевдосостояния, обозначающее начало выполнения процесса изменения состояний конечного автомата или
    81
    нахождения моделируемого объекта в составном состоянии (рисунок 25.2, а), из которого может только выходить стрелка-переход.
    Рисунок 25.2 – Начальное и конечное состояния на диаграмме состояний
    Конечное состояние – разновидность псевдосостояния, обозначающее прекращение процесса изменения состояний конечного автомата или нахождения моделируемого объекта в составном состоянии (рисунок 25.2, б), в которую может только входить стрелка-переход. Каждая диаграмма состояний или подсостояний может иметь несколько конечных состояний, при этом все они считаются эквивалентными на одном уровне вложенности состояний.
    Переход – отношение между двумя состояниями, которое указывает на то, что объект в первом состоянии должен выполнить определенные действия и перейти во второе состояние.
    Срабатывание перехода – выполнение перехода из одного состояния в другое. Может зависеть не только от наступления события, но и от выполнения определенного условия, называемого сторожевым. Объект перейдет из одного состояния в другое в том случае, если произошло указанное событие и сторожевое условие приняло значение «истина». До срабатывания перехода объект находится в предыдущем от него состоянии, называемым исходным, или в источнике, а после его срабатывания объект находится в последующем от него состоянии (целевом состоянии).
    На диаграмме состояний переход изображается сплошной линией со стрелкой, которая выходит из исходного состояния и направлена в целевое состояние.
    Событие – спецификация существенных явлений в поведении системы, которые имеют местоположение во времени и пространстве.
    Семантика понятия события фиксирует внимание на внешних проявлениях качественных изменений, происходящих при переходе моделируемого объекта из состояния в состояние.
    82

    22.2 Диаграммы кооперации
    Кооперацииспецификация множества объектов отдельных классов, совместно взаимодействующих с целью реализации отдельных вариантов использования в общем контексте моделируемой системы.
    На диаграмме кооперации размещаются объекты, представляющие собой экземпляры классов, связи между ними, которые в свою очередь являются экземплярами ассоциаций и сообщения. Связи дополняются стрелками сообщений, при этом показываются только те объекты, которые участвуют в реализации моделируемой кооперации. Далее, как и на диаграмме классов, показываются структурные отношения между объектами в виде различных соединительных линий. Связи могут дополняться именами ролей, которые играют объекты в данной взаимосвязи. И, наконец, изображаются динамические взаимосвязи – потоки сообщений в форме стрелок с указанием направления рядом с соединительными линиями между объектами, при этом задаются имена сообщений и их порядковые номера в общей последователь- ности сообщений.
    Одна и та же совокупность объектов может участвовать в реализации различных коопераций. В зависимости от рассматриваемой кооперации, могут изменяться как связи между отдельными объектами, так и поток сообщений между ними.
    Объект – сущность с хорошо определенными границами и индивидуальностью, которая инкапсулирует состояние и поведение.
    В контексте языка UML любой объект является экземпляром класса, описанного в модели и представленного на диаграмме классов. Объект создается на этапе реализации модели или выполнения программы. Он имеет собственное имя и конкретные значения атрибутов.
    Для диаграмм кооперации полное имя объекта в целом представляет собой строку текста, разделенную двоеточием и записанную в формате:
    <собственное имя объекта>'/'<Имя роли класса>:<Имя класса>
    83

    Имя роли класса указывается в том случае, когда соответствующий класс отсутствует в модели или разработчику необходимо акцентировать внимание на особенности его использования в рассматриваемом контексте моделирования взаимодействия.
    Если указано собственное имя объекта, то оно должно начинаться со строчной буквы. В тоже время имя объекта, имя роли с символом "/" или имя класса могут отсутствовать. Однако двоеточие всегда должно стоять перед именем класса, а косая черта – перед именем роли.
    В контексте языка UML все объекты делятся на две категории: пассивные и активные. Пассивный объект оперирует только данными и не может инициировать деятельность по управлению другими объектами. Однако пассивные объекты могут посылать сигналы в процессе выполнения запросов, которые они обрабатывают. На диаграмме кооперации пассивные объекты изображаются обычным образом без дополнительных стереотипов.
    Активный объект имеет собственный процесс управления и может инициировать деятельность по управлению другими объектами; на диаграмме обозначается прямоугольником с утолщенными границами.
    Мультиобъект – представляет собой множество анонимных объектов, которые могут быть образованы на основе одного класса; используется для того, чтобы показать операции и сигналы, которые адресованы всему множеству анонимных объектов. Изображается двумя прямоугольниками, один из которых выступает из-за верхней правой вершины другого.
    Составной объект – предназначен для представления объекта, имеющего собственную структуру и внутренние потоки управления; изображается как обычный объект, состоящий из секции с именем составного объекта, и секцией с его объектами-части вместо списка атрибутов.
    При изображении диаграммы кооперации отношения между объектами описываются с помощью связей, которые являются экземплярами соответствующих ассоциаций.
    Связи не имеют собственных имен и кратность концевых точек.
    84

    Сообщение – спецификация передачи информации от одного элемента модели к другому с ожиданием выполнения определенных действий со стороны принимающего элемента.
    Сообщения в языке UML специфицируют роли, которые играют объекты
    – отправитель и получатель сообщения. Сообщения на диаграмме кооперации изображаются дополнительными стрелками рядом с соответствующей связью или ролью ассоциации. Направление стрелки указывает на получателя сообщения (рисунок 25.3).
    Рисунок 25.3 – Типы сообщений на диаграмме кооперации
    Сплошная линия с треугольной стрелкой (рисунок 25.3, а) обозначает вызов процедуры или передачу потока управления.
    Сплошная линия с V-образной стрелкой (рисунок 25.3, б) обозначает асинхронное сообщение в простом потоке управления. В этом случае клиент передает асинхронное сообщение и продолжает выполнять свою деятельность, не ожидая ответа от клиента.
    Пунктирная линия с V-образной стрелкой (рисунок 25.3, в) обозначает возврат из вызова процедуры. Стрелки этого типа зачастую отсутствуют на диаграммах кооперации, поскольку неявно предполагается их существование после окончания процесса выполнения операции или деятельности.
    22.3 Диаграммы деятельности
    Диаграммы деятельности – частный случай диаграмм состояний. Они позволяют реализовать в языке UML особенности процедурного и синхронного управления, обусловленного завершением внутренних действий и деятельности. Основным направлением использования диаграмм деятельности является визуализация особенностей реализации операций классов, когда необходимо представить алгоритмы их выполнения. При этом каждое состояние может являться выполнением операции определенного класса либо ее части, позволяя использовать диаграммы деятельности для описания реакций на внутренние события системы.
    85

    В контексте языка UML деятельность представляет собой совокупность отдельных вычислений, выполняемых автоматом. При этом отдельные элементарные вычисления могут приводить к результату или действию. На диаграмме деятельности отображается логика или последовательность перехода от одной деятельности к другой, при этом внимание фиксируется на результате деятельности. Сам же результат может привести к изменению состояния системы или возвращению некоторого значения.
    Состояние деятельности – состояние в графе деятельности, которое служит для представления процедурной последовательности действий, требующих определенного времени.
    Состояние действия –- специальный случай состояния с некоторым входным действием и минимум одним выходящим из состояния переходом.
    Переход из состояния действия происходит после завершения входного действия. Состояние действия не может иметь внутренних переходов, поскольку оно является элементарным. Обычное использование состояния действия заключается в моделировании шага выполнения алгоритма или процедуры в рамках одного потока управления.
    Графически состояния деятельности и действия изображаются прямоугольником с закругленными углами. Внутри этой фигуры записывается имя состояния деятельности (рисунок 25.4, а) или действия (рисунок 25.4, б), которое должно быть уникальным в пределах одной диаграммы деятельности.
    Рисунок 25.4 – Состояния деятельности и действия
    Иногда возникает необходимость представить на диаграмме деятельности сложное действие, в свою очередь, состоящее из нескольких более простых.
    Состояние под-деятельности – состояние в графе деятельности, которое служит для представления неатомарной последовательности шагов процесса
    (рисунок 25.5).
    86

    Рисунок 25.5 – Состояние под-деятельности
    Каждая диаграмма деятельности должна иметь единственное начальное и конечное состояния. При этом каждая деятельность начинается в начальном состоянии и заканчивается в конечном состоянии. Саму диаграмму деятельности принято располагать таким образом, чтобы действия следовали сверху вниз или слева направо.
    При построении диаграммы деятельности используются только нетриггерные переходы, т. е. такие, которые происходят сразу после завершения деятельности или выполнения соответствующего действия. Такой переход передает управление в последующее состояние сразу, как только закончится действие или деятельность в предыдущем состоянии. На диаграмме такой переход изображается сплошной линией со стрелкой.
    Если из состояния действия выходит единственный переход, то его можно никак не помечать. Если же таких переходов несколько, то для каждого из них должно быть указано собственное сторожевое условие в прямых скобках. Такая ситуация получила название ветвления.
    Графически ветвление на диаграмме деятельности обозначается символом решения, изображаемого в форме небольшого пустого ромба (рисунок 25.6). В этот ромб может входить только одна стрелка от того состояния действия, после выполнения которого поток управления должен быть продолжен по одной из взаимно исключающих ветвей. Выходящих стрелок может быть две или более, но для каждой из них явно указывается соответствующее сторожевое условие в форме булевского выражения.
    Для объединения альтернативных ветвей на диаграмме деятельности рекомендуется также использовать аналогичный символ в форме ромба, который в этом случае называют соединением. Входящих стрелок у символа
    87
    соединения может быть несколько, они исходят от состояний действия, принадлежащих к одной из взаимно исключающих ветвей. Выходить из ромба соединения может только одна стрелка, при этом ни входящие, ни выходящая стрелки не должны содержать сторожевых условий.
    Рисунок 25.6 – Варианты ветвлений на диаграмме деятельности
    Дорожка – графическая область диаграммы деятельности, содержащая элементы модели, ответственность за выполнение которых принадлежит отдельным подсистемам.
    Названия подразделений или должностей явно указываются в верхней части дорожки. Пересекать линию дорожки могут только переходы, которые в этом случае обозначают выход или вход потока управления в соответствующее подразделение компании. Порядок следования дорожек не несет какой-либо семантической информации и определяется соображениями удобства.
    22.4 Диаграммы компонентов
    Для создания конкретной физической системы необходимо реализовать все элементы логического представления в конкретные материальные сущности. Для описания таких реальных сущностей предназначен другой аспект модельного представления, а именно – физическое представление
    88
    модели. В контексте языка UML это означает совокупность связанных физических сущностей, включая программное и аппаратное обеспечение, а также персонал, которые организованы для выполнения специальных задач.
    Физическая система – реально существующий прототип модели системы.
    В разработке диаграмм компонентов участвуют как системные аналитики и архитекторы, так и программисты. Диаграмма компонентов обеспечивает согласованный переход от логического представления к конкретной реализации проекта в форме программного кода. Одни компоненты могут существовать только на этапе компиляции программного кода, другие – на этапе его исполнения. Диаграмма компонентов отражает общие зависимости между компонентами, рассматривая последние в качестве отношений между ними.
    Для представления физических сущностей в языке UML применяется специальный термин – компонент.
    Компонент – физически существующая часть системы, которая обеспечивает реализацию классов и отношений, а также функционального поведения моделируемой программной системы.
    Компонент служит для общего обозначения элементов физического представления модели и может реализовывать некоторый набор интерфейсов.
    Для графического представления компонента используется специальный символ (рисунок 25.7). Внутри объемлющего прямоугольника записывается имя компонента и, возможно, дополнительная информация.
    Рисунок 25.7 – Компонент диаграммы компонентов
    В качестве собственных имен компонентов принято использовать имена исполняемых файлов, динамических библиотек, Web-страниц, текстовых файлов или файлов справки, файлов баз данных или файлов с исходными текстами программ, файлов скриптов и другие.
    89

    Для более наглядного изображения компонентов были предложены и стали общепринятыми следующие графические стереотипы:
    • динамически подключаемые библиотеки;
    • Web-страницы на языке разметки гипертекста;
    • файлы справки;
    • файлы с исходными текстами программ.
    Другой способ спецификации различных видов компонентов – указание текстового стереотипа компонента перед его именем, например, <>,
    <>, <>, <> и т. д.
    Следующим графическим элементом диаграммы компонентов являются
    1   2   3   4   5   6   7   8   9


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