Файл: Инфрам.pdf

228 конкретную роль. Роль. Которую играет класс, находящийся на конце ассоциации, называется конечным именем (в первой версии UML она называлась именем роли). Ассоциация может иметь параметр множе-
ственности. Он представляет собой диапазон целых чисел, указываю- щий количество связанных объектов (рис. 5.27). Множественность мо- жет быть определена как единица (1), ноль или один (0..1), много (0..* или *), один или несколько (1..*).
Рис. 5.26. Способы соединения сущностей
Рис. 5.27. Отображение параметра множественности
3. Обобщение связывает обобщенные классы (родительские классы) с более специализированными (дочерними) и потому известны как свя- зи наследования (класс – подкласс, родитель – потомок). Дочерняя сущ- ность наследует свойства родителей, а именно его атрибуты и операции.
Часто потомок имеет дополнительные атрибуты и операции помимо родительских. Реализация операции в дочернем классе замещает реали- зацию той же операции родителя (это явление называется полиморфиз- мом). Графически обобщение представляется сплошной линией со стрелкой в форме пустого треугольника, указывающего на родителя.
Перечисленные выше три вида связей описывают большинство ос- новных способов взаимодействия сущностей. Как показано на рис. 5.26,
UML предлагает особое графическое представление для каждого вида связи. Эта нотация позволяет визуализировать связи независимо от кон- кретного языка программирования, причем способом, описывающим наиболее важные параметры связей: имя, соединяемые сущности и свойства.

229 5.3.4. Описание поведения системы
Для моделирования динамических аспектов систем в UML исполь- зуются диаграммы взаимодействия (набор объектов и их связей, вклю- чая передаваемые между ними сообщения), к которым относятся диа- граммы коммуникации и диаграммы последовательности. Первые пока- зывают структурную организацию объектов, отправляющих и прини- мающих сообщения, в виде наборов вершин и дуг. Вторые выделяют временной порядок сообщений.
Для описания особенностей поведения программной системы ис- пользуются диаграммы последовательностей системы, системные собы- тия, системные операции, диаграммы деятельности, и при необходимо- сти диаграммы состояний объектов.
Диаграммы последовательностей системы представляют собой графическую модель, которая для определенного варианта использова- ния показывает динамику взаимодействия объектов во времени [6, 8].
Для построения диаграммы последовательностей необходимо: идентифицировать каждое действующее лицо (объект) и изобразить для него линию жизни (вертикальная линия, направленная вниз от объекта, см. ниже). Крайним слева на диаграмме изображается объ- ект, который является инициатором взаимодействия. Правее изо- бражается объект, который непосредственно взаимодействует с пер- вым и т.д.; из описания варианта использования определить множество систем- ных событий и их последовательность; изобразить системные события в виде линий со стрелками на конце между линиями жизни действующих лиц и системы, а также указать имена событий и и списки передаваемых значений.
На диаграмме последовательностей изображаются только те объек- ты, которые непосредственно участвуют во взаимодействии, и не пока- зываются возможные статические ассоциации с другими объектами.
При этом диаграмма последовательностей имеет два измерения. Одно – слева направо в виде вертикальных линий, каждая из которых изобра- жает линию жизни отдельного объекта, участвующего во взаимодейст- вии. Графически каждый объект изображается прямоугольником и рас- полагается в верхней части своей линии жизни (рис. 5.28). Внутри пря- моугольника записывается имя объекта и имя класса, разделенные двое- точием. Вся запись подчеркивается, что является признаком объекта, который представляет собой экземпляр класса.
Линия жизни объекта служит обозначением периода времени, в те- чение которого объект существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях. На диаграмме линия жизни изображается пунктирной вертикальной линией, ассоции- руемой с единственным объектом. Если объект существует в системе постоянно, то линия его жизни должна продолжаться по всей плоскости диаграммы последовательно от самой верхней до самой нижней части
(объекты 1 и 2 на рис. 5.28).

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

231 мации; сообщения могут поступать в любом порядке. Полные наборы сообщений на отдельных линиях жизни формируют частичное упорядо- чение. Серии сообщений, однако, устанавливают цепь причинных свя- зей, поэтому любая точка на другой линии жизни в конце цепи должна всегда следовать за точкой начала цепи на исходной линии.
Для моделирования процесса выполнения операций в Языке UML используются диаграммы деятельности. Диаграммы деятельности де- монстрируют потоки управления и потоки данных внутри прецедентов использования. На диаграммах отображаются последовательности дей- ствий, потоки управления, точки объединения и принятия решений. На этапе анализа требований и уточнения спецификаций диаграммы дея- тельности позволяют конкретизировать основные функции разрабаты- ваемой программной системы.
Под деятельностью в данном случае понимают задачу (операцию), которую необходимо выполнить вручную или при помощи средств ав- томатизации. Каждому варианту использования соответствует своя по- следовательность задач. В теоретическом плане диаграммы деятельно- сти являются обобщенным представлением алгоритма, реализующего анализируемый вариант использования.
Действия – это элементы, с помощью которых реализуется поведе- ние в рабочем потоке. Действия отображаются прямоугольниками с за- кругленными углами (рис. 5.29). Внутри этой фигуры записывается вы- ражение действия, которое должно быть уникальным в пределах одной диаграммы деятельности. Действия можно определить, изучив специ- фикацию прецедентов использования и определив, какое поведение не- обходимо для пошагового выполнения прецедента использования. Дей- ствие может быть записано на естественном языке, некотором псевдо- коде или языке программирования. Рекомендуется в качестве имени простого действия использовать глагол с пояснительными словами.
Управляющие потоки или потоки управления. После завершения действия управление передается следующему действию. Потоки управ- ления показывают передачу управления от одного действия другому.
Изображаются потоки управления стрелками. Потоку можно дать имя.
Точки принятия решений. Точки принятия решений используются для отображения разветвления управления. Потоки, исходящие из точек принятия решений, содержат условия, определяющие альтернативные пути потока управления после точки принятия решения. Условия пи- шутся в квадратных скобках, а точки принятия решений изображаются небольшими ромбами. Графически ветвление на диаграмме деятельно- сти обозначается небольшим ромбом, внутри которого текст отсутству- ет. В этот ромб может входить только одна стрелка от того состояния действия, после выполнения которого поток управления должен быть продолжен по одной из взаимно исключающих ветвей.
Потоки объектов. Поток объектов символизирует поток от действия к данным или от данных к действию. Данные изображаются прямо- угольником. А потоки данных обозначаются стрелками (рис.5.30).

232
Рис. 5.29. Элементы диаграммы деятельности
Рис. 5.30. Изображение данных и потоков данных
Разделение и слияние потока управления. В рабочем потоке могут быть действия, которые могут выполняться параллельно. Узел разделе- ния показывает, какие действия можно выполнять одновременно. Узел слияния показывает объединение потоков выполнения, поэтому соот- ветствующие действия должны завершиться перед выполнением даль- нейшей работы. Узлы разделения и слияния обозначаются отрезками
(рис. 5.31).
Начальный и конечный узлы. Для обозначения начального и конеч- ного узлов рабочего потока используются специальные символы. На- чальный узел изображается целого залитого круга, а конечный – в виде черного круга, окаймленного линией окружности несколько большего диаметра (так называемый “бычий глаз”). Возможный пример исполь- зования начального и конечного узлов показан на рис. 5.32.
Рис. 5.31. Разделение и слияние потоков управления
Рис. 5.32. Обозначение начального и конечного узлов

233
Кроме рассмотренных диаграмм для описания поведения системы используются диаграммы состояний. Главное назначение этих диа- грамм – описать возможные последовательности состояний и перехо- дов, которые в совокупности характеризуют поведение элемента модели в течение его жизненного цикла. Диаграмма состояний используется для моделирования динамических аспектов системы. В большинстве случаев под этим подразумевается моделирование поведения реактив- ных объектов. Реактивным является такой объект, поведение которого лучше всего характеризуется его реакцией на события, произошедшие вне его собственного контекста. Если внешние действия, изменяющие состояние системы, инициируются в произвольные случайные моменты времени, то говорят об асинхронном поведении модели.
Диаграмма состояний по существу является графом специального вида, который представляет некоторый автомат. Вершинами этого графа являются состояния, которые изображаются соответствующими графическими символами. Дуги графа служат для обозначения перехо- дов из одного состояния в другое. Диаграммы состояний могут быть вложены друг в друга, образуя более детальное представление отдель- ных элементов модели.
Простейший пример автомата с двумя состояниями демонстрирует ситуация с исправностью компьютера. Здесь рассматривается два самых общих состояния: “исправен” и ”неисправен” и два перехода: ”выход из строя“ и ”ремонт”. Графически эта информация может быть представ- лена в виде диаграммы состояний компьютера (рис. 5.33).
Рис. 5.33. Диаграмма состояний компьютера
Основными понятиями, описывающими автомат, являются состоя- ние и переход. Предполагается, что система находится в каком-либо состоянии в течение некоторого времени, тогда как переход объекта из состояния в состояние происходит мгновенно.
Состояние – это ситуация в жизни объекта, на протяжении которой он удовлетворяет некоторому условию, осуществляет определенную деятельность или ожидает какого-то события. Состояние на диаграмме изображается прямоугольником со скругленными вершинами, который может быть разделен горизонтальной линией на две секции. В прямо- угольнике может располагаться “Имя состояния“ (первая секция) и
”Список внутренних действий в дано состоянии” (вторая секция). При этом под действием в языке UML понимают некоторую атомарную опе-

234 рацию, выполнение которой приводит к изменению состояния или воз- врату некоторого значения.
Имя состояния – это строка текста, начинающаяся с заглавной бук- вы, которая раскрывает содержательный смысл данного состояния. Имя является обязательным элементом. Рекомендуется в качестве имени использовать глаголы в настоящем времени (печатает, ожидает, получа- ет и т. п.) или соответствующие причастия (занят, свободен, получено и т. п.).
Список внутренних действий содержит перечень внутренних дейст- вий или деятельностей, которые выполняются в процессе нахождения моделируемого элемента в данном состоянии. Каждое действие записы- вается в виде отдельной сороки и имеет следующий формат:
< метка действия ‘/’ выражение действия >
Метка действия указывает на обстоятельства или условия, при кото- рых будет выполняться деятельность, определенная выражением дейст- вия. При этом выражение действия может использовать любые атрибу- ты и связи, которые принадлежат области имен или контексту модели- руемого объекта. Если список выражения действий пустой, то раздели- тель в виде наклонной черты ‘/’может не указываться. На рис. 5.34 по- казан пример состояния Считывает запись после открытия файла, со- держащего несколько записей.
Рис. 5.34. Пример изображения состояния с поясняющей информацией
Простой переход представляет собой отношение между двумя по- следовательными состояниями, которое указывает на факт смены одно- го состояния другим. Пребывание моделируемого объекта в первом со- стоянии может сопровождаться выполнением некоторых действий, а переход во второе состояние будет возможным после завершения этих действий, а также после удовлетворения некоторых дополнительных условий.
В этом случае говорят, что переход срабатывает. До срабатывания перехода объект находится в предыдущем от него (перехода) состоя- нии, называемом исходным состоянием, или в источнике (не путать с начальным состоянием – это разные понятия), а после его срабатывания объект находится в последующем от него (перехода) состоянии (целе- вом состоянии).
На диаграмме состояний переход изображается сплошной линией со стрелкой, которая направлена в целевое состояние. Рядом с линией мо- жет находиться строка текста, описывающая событие-триггер, вызы-

235 вающее переход (в этом случае переход будет триггерным), и стороже- вое условие, по которому осуществляется переход.
Событие – это спецификация существенного факта, который проис- ходит во времени и пространстве. В контексте автоматов – это стимул, способный вызвать срабатывание перехода.
Сторожевое условие, если оно есть, всегда записывается в прямых скобках после события-триггера и представляет собой некоторое булев- ское выражение, результатом которого является “истина” или “ложь”.

236
Подготовка полных и правильных внешних спецификаций – самая ответственная и трудная задача в разработке ПС. Это связано с тем, что внешние спецификации участвуют в большем числе процессов перевода
(в понятии, определенном в п. 4.1), чем любой другой проектный доку- мент. Несмотря на отсутствие сложившейся методологии по разработке внешнего проекта, полезным принципом является идея концептуальной
целостности, представляющей собой согласованность (или стремление к ней) между внешними функциями системы. В соответствии с этой концепцией лучше иметь относительно небольшой набор хорошо согла- сованных функций, чем, возможно, большой набор независимых и не- скоординированных функций. Особенности, которые кажутся привлека- тельными, но не согласуются с остальными, вероятно, следует откло- нить, чтобы не усложнять взаимодействие с пользователем.
Концептуальная целостность представляет собой меру единообразия способа взаимодействия с пользователем (т.е. меру однородности ин- терфейса пользователя). Система, лишенная концептуальной целостно- сти, – это система, в основе которой нет единообразия. В результате такая система характеризуется сложным взаимодействием с пользовате- лем и излишне сложной структурой.
В качестве примера рассмотрим распространенную программную систему MS Office. В ней пять основных компонентов: MS Word, MS
Excel, MS PowerPoint, MS Access и MS Outlook. Освоив работу, напри- мер, с текстовым процессором, пользователь без особых затруднений работает и с другими программами. Это обеспечивается именно кон- цептуальной целостностью MS Office, в котором интерфейсы пользова- телей различных компонентов практически одинаковы.
Самый легкий путь исключения концептуальной целостности можно отождествить с попыткой создать внешний проект большой группой разработчиков. Опыт показывает, что при числе разработчиков больше двух вероятность успеха (т.е. получения концептуальной целостности проекта) резко снижается [18]. Это справедливо даже для крупных про- ектов, например, создания операционных систем. Однако это не означа- ет, что в процессе проектирования должны принимать участие только двое; требуется, чтобы ответственность за внешние спецификации несла лишь маленькая группа людей, принимающая все решения подготавли- вая спецификации. В случае крупного проекта этим разработчикам не- обходима помощь исследователей, ассистентов и вспомогательного персонала (чертежников, секретарей и др.).
Помощники занимаются сбором и обработкой информации, но не проектированием и не написанием спецификаций. Кем же должны быть ответственные исполнители внешних спецификаций? Они не должны быть программистами, так кА процесс внешнего проектирования не имеет ничего общего с разработкой программ. Этот процесс этот про- цесс больше связан с пониманием окружающей среды пользователей, их проблем и нужд, психологии связи человек - машина. Особенно важ- но то, что эта тенденция внешнего проектирования возрастает с приме- нением новых средств вычислительной техники, касающихся большого