Конспект лекций для студентов специальности i 53 01 07 Информационные технологии и управление в технических системах
 Скачать 0.6 Mb.
|
|
7 Диаграммы деятельности (activity diagram) При моделировании поведения проектируемой или анализируемой системы возникает необходимость не только представить процесс изменения ее состояний, но и детализировать особенности алгоритмической и логической реализации выполняемых системой операций. Для моделирования процесса выполнения операций в языке UML используются так называемые диаграммы деятельности. Применяемая в них графическая нотация во многом похожа на нотацию диаграммы состояний, поскольку на диаграммах деятельности также присутствуют обозначения состояний и переходов. Отличие заключается в семантике состояний, которые используются для представления не деятельностей, а действий, и в отсутствии на переходах сигнатуры событий. Каждое состояние на диаграмме деятельности соответствует выполнению некоторой элементарной операции, а переход в следующее состояние срабатывает только при завершении этой, операции в предыдущем состоянии. Графически диаграмма деятельности представляется в форме графа деятельности, вершинами которого являются состояния действия, а дугами – переходы от одного состояния действия к другому. В контексте языка UML деятельность (activity) представляет собой некоторую совокупность отдельных вычислений, выполняемых автоматом. При этом отдельные элементарные вычисления могут приводить к некоторому результату или действию (action). На диаграмме деятельности отображается логика или последовательность перехода от одной деятельности к другой, при этом внимание фиксируется на результате деятельности. Сам же результат может привести к изменению состояния системы или возвращению некоторого значения. 7.1. Основные элементы диаграммы деятельности Состояние действия (action state) является специальным случаем состояния с некоторым входным действием и по крайней мере одним выходящим из состояния переходом. Графически состояние действия изображается фигурой, напоминающей прямоугольник, боковые стороны которого заменены выпуклыми дугами (рис. 58). Внутри этой фигуры записывается выражение действия (action-expression), которое должно быть уникальным в пределах одной диаграммы деятельности. Рис. 58 Графическое изображение состояния действия Действие может быть записано на естественном языке, некотором 55 псевдокоде или языке программирования. Никаких дополнительных или неявных ограничений при записи действий не накладывается. При построении диаграммы деятельности используются только те переходы, которые переводят деятельность в последующее состояние сразу, как только закончится действие в предыдущем состоянии (нетриггерные). На диаграмме такой переход изображается сплошной линией со стрелкой. Ветвление на диаграмме деятельности обозначается небольшим ромбом, внутри которого нет никакого текста (рис. 59). В качестве примера рассмотрим фрагмент алгоритма нахождения корней квадратного уравнения. В общем случае после приведения уравнения второй степени к каноническому виду: а*х*х + b*х + с = 0 необходимо вычислить его дискриминант. Причем, в случае отрицательного дискриминанта уравнение не имеет решения на множестве действительных чисел, и дальнейшие вычисления должны быть прекращены. При неотрицательном дискриминанте уравнение имеет решение, корни которого могут быть получены на основе конкретной расчетной формулы. Процедуру вычисления корней квадратного уравнения можно представить в виде диаграммы деятельности с тремя состояниями действия и ветвлением (рис. 59). Каждый из переходов, выходящих из состояния "Вычислить дискриминант", имеет сторожевое условие, определяющее единственную ветвь, по которой может быть продолжен процесс вычисления корней в зависимости от знака дискриминанта. Рис. 59 Фрагмент диаграммы деятельности для алгоритма нахождения корней квадратного уравнения В языке UML для распараллеливания вычислений используется 56 специальный символ для разделения (рис. 60, а) и слияния (рис. 60, б) параллельных вычислений или потоков управления. Рис. 60 Разделения и слияния параллельных потоков управления Диаграммы деятельности могут быть использованы не только для спецификации алгоритмов вычислений или потоков управления в программных системах. Не менее важная область их применения связана с моделированием бизнес-процессов. Для моделирования этих особенностей в языке UML используется специальная конструкция, получившее название дорожки (swimlanes). Имеется в виду визуальная аналогия с плавательными дорожками в бассейне, если смотреть на соответствующую диаграмму. При этом все состояния действия на диаграмме деятельности делятся на отдельные группы, которые отделяются друг от друга вертикальными линиями. Две соседние линии и образуют дорожку, а группа состояний между этими линиями выполняется отдельным подразделением (отделом, группой, отделением, филиалом) компании (рис. 61). Рис. 61 Вариант диаграммы деятельности с дорожками В общем случае действия на диаграмме деятельности выполняются над теми или иными объектами. Эти объекты либо инициируют выполнение действий, либо определяют некоторый результат этих действий. При этом действия специфицируют вызовы, которые передаются от одного объекта графа деятельности к другому. Поскольку в таком ракурсе объекты играют определенную роль в понимании процесса деятельности, иногда возникает необходимость явно указать их на диаграмме деятельности. 57 Для графического представления объектов используются прямоугольник класса, с тем отличием, что имя объекта подчеркивается. Далее после имени может указываться характеристика состояния объекта в прямых скобках. Такие прямоугольники объектов присоединяются к состояниям действия отношением зависимости пунктирной линией со стрелкой. Соответствующая зависимость определяет состояние конкретного объекта после выполнения предшествующего действия. 7.2 Пример диаграммы деятельности В качестве примера рассмотрим фрагмент диаграммы деятельности торговой компании, обслуживающей клиентов по телефону. Подразделениями компании являются отдел приема и оформления заказов, отдел продаж и склад. Этим подразделениям будут соответствовать три дорожки на диаграмме деятельности, каждая из которых специфицирует зону ответственности подразделения (рис. 62). Рис. 62 Диаграмма деятельности торговой компании с объектом-заказом В данном случае диаграмма деятельности заключает в себе не только 58 информацию о последовательности выполнения рабочих действий, но и о том, какое из подразделений торговой компании должно выполнять то или иное действие. Кроме того центральным объектом процесса продажи является заказ или вернее состояние его выполнения. Вначале до звонка от клиента заказ как объект отсутствует и возникает лишь после такого звонка. Однако этот заказ еще не заполнен до конца, поскольку требуется еще подобрать конкретный товар в отделе продаж. После его подготовки он передается на склад, где вместе с отпуском товара заказ окончательно дооформляется. Наконец, после получения подтверждения об оплате товара эта информация заносится в заказ, и он считается выполненным и закрытым. 8 Диаграммы компонентов (component diagram) Все рассмотренные ранее диаграммы отражали концептуальные аспекты построения модели системы и относились к логическому уровню представления. Диаграмма компонентов описывает особенности физического представления системы. Диаграмма компонентов позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный, бинарный и исполняемый код. Основными графическими элементами диаграммы компонентов являются компоненты, интерфейсы и зависимости между ними. Диаграмма компонентов разрабатывается для следующих целей: · визуализации общей структуры исходного кода программной системы; · спецификации исполнимого варианта программной системы; · обеспечения многократного использования отдельных фрагментов программного кода; · представления концептуальной и физической схем баз данных. Диаграмма компонентов обеспечивает согласованный переход от логического представления к конкретной реализации проекта в форме программного кода. Одни компоненты могут существовать только на этапе компиляции программного кода, другие – на этапе его исполнения. Диаграмма компонентов отражает общие зависимости между компонентами, рассматривая последние в качестве классификаторов. 8.1 Основные графические элементы диаграммы компонентов Для представления физических сущностей в языке UML применяется специальный термин – компонент (component). Компонент реализует некоторый набор интерфейсов и служит для общего обозначения элементов физического представления модели. Для графического представления компонента может использоваться специальный символ – прямоугольник со вставленными слева двумя более мелкими прямоугольниками (рис. 63). Внутри объемлющего прямоугольника записывается имя компонента и, возможно, некоторая дополнительная информация. 59 Рис. 63 Графическое изображение компонента в языке UML В первом случае (рис. 63, а) с компонентом уровня экземпляра связывается только его имя, а во втором (рис. 63, б) – дополнительно имя пакета и помеченное значение. В языке UML выделяют три вида компонентов: · компоненты развертывания, которые обеспечивают непосредственное выполнение системой своих функций: динамически подключаемые библиотеки с расширением dll, Web-страницы на языке разметки гипертекста с расширением html и файлы справки с расширением hlp. · компоненты-рабочие продукты: файлы с исходными текстами программ, например, с расширениями h или срр для языка C++. · компоненты исполнения, представляющие исполнимые модули – файлы с расширением ехе. Следующим элементом диаграммы компонентов являются интерфейс. Этот элемент уже рассматривался ранее, поэтому отметим только его особенности, которые характерны для представления на диаграммах компонентов. В общем случае интерфейс графически изображается окружностью, которая соединяется с компонентом отрезком линии без стрелок (рис. 64, а). Семантически линия означает реализацию интерфейса, а наличие интерфейсов у компонента означает, что данный компонент реализует соответствующий набор интерфейсов. Рис. 64 Графическое изображение интерфейсов на диаграмме компонентов Другим способом представления интерфейса на диаграмме компонентов является его изображение в виде прямоугольника класса со стереотипом "интерфейс" и возможными секциями атрибутов и операций (рис. 64, б). Как правило, этот вариант обозначения используется для представления внутренней структуры интерфейса, которая может быть важна для реализации. Применительно к диаграмме компонентов зависимости могут связывать 60 компоненты и импортируемые этим компонентом интерфейсы, а также различные виды компонентов между собой. В первом случае рисуют стрелку от компонента-клиента к импортируемому интерфейсу (рис. 65). Наличие такой стрелки означает, что компонент не реализует соответствующий интерфейс, а использует его в процессе своего выполнения. Причем на этой же диаграмме может присутствовать и другой компонент, который реализует этот интерфейс. Так, например, изображенный ниже фрагмент диаграммы компонентов представляет информацию о том, что компонент с именем "main.exe" зависит от импортируемого интерфейса IDialog, который, в свою очередь, реализуется компонентом с именем "image.java". Для второго компонента этот же интерфейс является экспортируемым. Рис. 65. Фрагмент диаграммы компонентов с отношением зависимости На диаграмме компонентов также могут быть представлены отношения зависимости между компонентами и реализованными в них классами (рис. 66). Эта информация имеет важное значение для обеспечения согласования логического и физического представлений модели системы. Рис. 66 Графическое изображение зависимости между компонентом и классами 9 Диаграммы развертывания (deployment diagram) Физическое представление программной системы не может быть полным, если отсутствует информация о том, на какой платформе и на каких вычислительных средствах она реализована. Диаграмма развертывания предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения (runtime). При этом представляются только компоненты-экземпляры программы, являющиеся исполнимыми файлами или динамическими библиотеками. Те компоненты, которые не используются на этапе исполнения, на диаграмме развертывания не показываются. Так, компоненты с исходными текстами программ могут 61 присутствовать только на диаграмме компонентов. На диаграмме развертывания они не указываются. Диаграмма развертывания содержит графические изображения процессоров, устройств, процессов и связей между ними. В отличие от диаграмм логического представления, диаграмма развертывания является единой для системы в целом, поскольку должна всецело отражать особенности ее реализации. Эта диаграмма, по сути, завершает процесс ООАП для конкретной программной системы и ее разработка, как правило, является последним этапом спецификации модели. 9.1 Элементы диаграммы компонентов К основным элементам диаграммы развертывания относятся узлы и соединения. Узел (node) представляет собой некоторый физически существующий элемент системы, обладающий некоторым вычислительным ресурсом. В качестве вычислительного ресурса узла может рассматриваться наличие по меньшей мере некоторого объема электронной или магнитооптической памяти и/или процессора. Понятие узла также может включать в себя и другие механические или электронные устройства, такие как датчики, принтеры, модемы, цифровые камеры, сканеры и манипуляторы. Графически на диаграмме развертывания узел изображается в форме трехмерного куба. Узел имеет собственное имя, которое указывается внутри этого графического символа. Сами узлы могут представляться как в качестве типов (рис. 67, а), так и в качестве экземпляров (рис. 67, б). Рис. 67 Графическое изображение узла на диаграмме развертывания Помеченное значение – это расширение свойств элемента UML, позволяющее вводить новую информацию в его спецификацию. У каждой сущности в UML есть фиксированный набор свойств: классы имеют имена, атрибуты и операции; ассоциации-имена и концевые точки (каждая со своими свойствами) и т.д. Помеченные значения позволяют добавлять новые свойства. Например, как показано на рис. 68, в диаграмме развертывания можно указать число процессоров, установленных на узле каждого вида, или потребовать, чтобы каждому компоненту был приписан стереотип библиотеки, если его предполагается развернуть на клиенте или сервере. 62 Рис. 68 Помеченные значения Так же, как и на диаграмме компонентов, изображения узлов могут расширяться, чтобы включить некоторую дополнительную информацию о спецификации узла. Если дополнительная информация относится к имени узла, то она записывается под этим именем в форме помеченного значения (рис. 69). Рис. 69 Графическое изображение узла-экземпляра с дополнительной информацией в форме помеченного значения Соединения указывают отношения между узлами и являются разновидностью ассоциации. Изображаются отрезками линий без стрелок. Наличие такой линии указывает на необходимость организации физического канала для обмена информацией между соответствующими узлами. Характер соединения может быть дополнительно специфицирован примечанием, помеченным значением или ограничением (рис. 70). В рассмотренном примере явно определены не только требования к скорости передачи данных в локальной сети с помощью помеченного значения, но и рекомендации по технологии физической реализации соединений в форме примечания. Рис. 70 Фрагмент диаграммы развертывания с соединениями между узлами Кроме соединений на диаграмме развертывания могут присутствовать отношения зависимости между узлом и развернутыми на нем компонентами. Подобный способ является альтернативой вложенному изображению 63 компонентов внутри символа узла, что не всегда удобно, поскольку делает этот символ излишне объемным (рис. 71). Рис. 71 Диаграмма развертывания с отношением зависимости между узлом и развернутыми на нем компонентами 9.2 Пример диаграммы развертывания Рассмотрим фрагмент физического представления системы удаленного обслуживания клиентов банка (рис. 72). Рис. 72 Диаграмма развертывания для системы удаленного обслуживания клиентов банка На диаграмме развертывания узлами системы являются удаленный терминал (узел-тип) и сервер банка (узел-экземпляр). Указана зависимость компонента реализации диалога "dialog.exe" на удаленном терминале от интерфейса lAuthorise, реализованного компонентом "main.exe", который, в свою очередь, развернут на анонимном узле-экземпляре "Сервер банка". Последний зависит от компонента базы данных "Клиенты банка", который развернут на этом же узле. Примечание указывает на необходимость использования защищенной линии связи для обмена данными в данной системе. Другой вариант записи этой информации заключается в дополнении диаграммы узлом со стереотипом "закрытая сеть". 64 Литература 1. Информационные технологии управления: Учебное пособие / Под ред. Ю.М. Черкасова. – М.: ИНФРА-М, 2001. – 216 с. 2. М. Фаулер, К.Скотт. UML в кратком изложении. М. Мир. 1999. 191 с. 3. Грейди Буч, Джеймс Рамбо, Айвар Джекобсон. UML. Руководство пользователя. М. ДМК 2000. 432 с. 4. Фаулер М., Скотт К. UML. Основы. – Пер. с англ. – СПб: Символ-Плюс, 2002. – 192с., ил. 5. Автоматизация управления предприятием / Баронов В.В. и др. – М.: ИНФРА- М, 2000. – 239 с. 6. Вебер Д. Технология Java в подлиннике. С.Пб: BHV-Санкт-Петербург, 1998. 1104 с. 7. Эферган М. JAVA Справочник. С.Пб: Питер, 1998. 448 с. 8. Мейнджер Д. JAVA: Основы программирования. С.Пб: BHV-Санкт- Петербург, 1997. 320 с. 9. Мейсо Б. JAVA ++: Основы программирования. С.Пб: BHV-Санкт-Петербург, 1997. 400 с. 10.Калянов Г.Н. CASE структурный системный анализ (автоматизация и применение).- М.: ЛОРИ, 1996. 11.Уэнди Боггс, Майкл Боггс «UML и Rational Rose 2002» /Пер. с англ. – М. «Лори», 2004. 12.Березин С.В., Раков С.В. Internet у вас дома / 2-е изд. перераб. и доп. – СПб.: БХВ – Санкт-Петербург, 1999. – 752 с. 13.С.Спейнаур, В.Куэрсиа "Справочник Web-мастера": Пер. с англ. – К.: Издательская группа BHV, 1997. – 386 с. 14.А.М. Вендров. CASE-технологии. Современные методы и средства проектирования информационных систем. М.: Финансы и статистика, 1998, - 176с. 15.Кватрани Т. Rational Rose 2000 и UML. Визуальное моделирование: Пер. с англ. – М.: ДМК Пресс, 2001 – 176с.: ил. 16.Маклаков С.В. ERWin и BPWin. CASE средства разработки информационных систем. - М.:Диалог-МИФИ, 1999. 17.Джеймс Рамбо, Айвар Якобсон, Гради Буч «UML Специальный справочник». – СПб.: «Питер», 2002. 18.Бабушкин М., Иваненко С., Коростелев В. Web-сервер в действии. - Санкт- Петербург, Питер. – 1997. |