Анализ систем на языке Uml

Размещено на http://www.allbest.ru/

Анализ систем на языке Uml

диаграмма класс развертывание

Применение диаграмм языка UML для анализа систем

Реально процесс разработки ПО состоит из нескольких стадий. Причем эти стадии существуют в любых моделях ЖЦ ПО, они лишь отличаются названиями и группировкой действий.

Цели стадии анализа требований состоят в том, чтобы понять процессы, которые управляют предприятием или системой, определить область деятельности системы и требования пользователя. Система рассматривается с точки зрения конечного пользователя как “черный ящик”, и составляется представление то что система будет делать, не рассматривая, как она это будет делать.

На данной стадии с помощью UML создается модель прецедентов системы. Она позволяет выделить внешние системы, контактирующие с системой, основные процессы и их взаимосвязь. Диаграммы прецедентов (вариантов использования) дают возможность выделить функциональную структуру системы, не вдаваясь в детали ее реализации. Кроме того, производится предварительное выделение объектов системы и их классификация. На основании построенной модели составляется план разработки системы.

Часто, для того, чтобы уяснить, что система будет делать, уже на начальном этапе работ осуществляется разработка диаграммы деятельностей (activity diagrams). Эта диаграмма предназначена для того, чтобы отразить переходы в рамках выполнения определенной задачи, вызванные внутренними процессами. Диаграммы деятельности используются для моделирования потоков работ в различных вариантах использования, для анализа вариантов использования. В какой-то степени, эти диаграммы похожи на схемы алгоритмов, причем это касается как применяемых в них обозначений, так и реализуемых ими функций. Обычно первый вариант этой диаграммы разрабатывается в процессе общения с заказчиком, который объясняет разработчику, как должна вести себя разрабатываемая система в процессе ее функционирования. По сути, Activity Diagram представляет собой модель последовательности действий.

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

Диаграмма Use Case определяет поведение системы с точки зрения ее пользователей, которые называются в моделировании исполнителями или актантами (actors). При этом, в качестве исполнителей могут выступать не только одушевленные объекты (Клиент, Оператор и т. п.), но и другие объекты, использующие систему, например, ПечатающееУстройство, Датчик и т. п.пользователя.

Рис.

Диаграмма Use Case рассматривается как главное средство для первичного моделирования динамики системы. Она используется для выяснения требований к разрабатываемой системе, фиксации этих требований в форме, которая позволит проводить дальнейшую разработку. В русской литературе диаграммы Use Case часто называют диаграммами прецедентов, или диаграммами вариантов использования.

Прецедент (элемент Use Case) - это описание поведения системы с точки зрения пользователя. Для разработчиков системы это полезный инструмент, предоставляющий надежную методику формирования требований к системе с точки зрения пользователя. Это важно, если целью работы является создание системы, которую смогут использовать обычные люди, а не только специалисты в области компьютерных технологий. Прецедент представляется на диаграмме эллипсом.

Рис.

Название элемента Use Case начинается с глагола и обозначает действие элемента actors.

Один актер может использовать несколько элементов Use Case, и наоборот, один элемент Use Case может иметь несколько актеров, использующих его. Каждый элемент Use Case задает определенный путь использования системы. Набор всех элементов Use Case определяет полные функциональные возможности системы.

Актеры взаимодействуют с системой посредством передачи и приема сообщений от вариантов использования. Сообщение представляет собой запрос актером сервиса от системы и получение этого сервиса. Это взаимодействие может быть выражено посредством ассоциаций между отдельными актерами и вариантами использования или классами. Кроме этого, с актерами могут быть связаны интерфейсы, которые определяют, каким образом другие элементы модели взаимодействуют с этими актерами.

Каждый вариант использования определяет последовательность действий, которые должны быть выполнены проектируемой системой при взаимодействии ее с соответствующим актером. Диаграмма вариантов может дополняться пояснительным текстом, который раскрывает смысл или семантику составляющих ее компонентов. Такой пояснительный текст получил название примечания или сценария. Что бы не путать этот термин с элементом примечание на диаграмме Use Case, мы в дальнейшем будем использовать только термин сценарий. Обычно текст сценария помещается в обычный файл документа, ассоциированный с данной диаграммой.

В состав диаграмм Use Case кроме элементов Use Case и актеров, входят также отношения зависимости, обобщения и ассоциации. Как и другие диаграммы, диаграммы Use Case могут включать примечания и ограничения.

Для лучшей организации системы, можно также формировать группы. Для этого, диаграммы Use Case могут содержать пакеты, используемые для группировки элементов модели в крупные фрагменты и, сокрытия деталей системы. В дальнейшем, при необходимости, эти пакеты могут быть развернуты. Между пакетами могут существовать только отношения зависимости.

Между актером и элементом Use Case возможен только один вид отношения - ассоциация, отображающая их взаимодействие. Как и любая другая ассоциация, она может быть помечена именем, ролями, мощностью.

Рис.

Между актерами допустимо отношение обобщения, означающее, что экземпляр потомка может взаимодействовать с такими же разновидностями экземпляров элементов Use Case, что и экземпляр родителя.

Между элементами Use Case определены отношение обобщения и две разновидности отношения зависимости - включения (стереотип «include») и расширения (стереотип «extend»). Отношение обобщения фиксирует, что потомок наследует поведение родителя. Кроме того, потомок может дополнить или переопределить поведение родителя. Элемент Use Case, являющийся потомком, может замещать элемент Use Case, являющийся родителем, в любом месте диаграммы.

Рис.

Отношение включения между элементами Use Case (стереотип «include») означает, что базовый элемент Use Case явно включает поведение другого элемента Use Case в точке, которая определена в базе. Другими словами, имеет место фрагмент поведения, который повторяется более чем в одном варианте использования и нежелательно, что бы его описание копировалось в каждом из этих вариантов.

Отношение расширения между элементами Use Case (стереотип «extend») означает, что базовый элемент Use Case неявно включает поведение другого элемента Use Case в точке, которая определяется косвенно расширяющим элементом Use Case. Базовый элемент Use Case может быть автономен, но при определенных условиях его поведение может расширяться поведением из другого элемента Use Case. Базовый элемент Use Case может расширяться только в определенных точках - точках расширения. Отношение расширения применяется для моделирования выбираемого поведения системы. Таким способом можно отделить обязательное поведение от необязательного поведения. Например, можно использовать отношение расширения для отдельного подпотока, который выполняется только при определенных условиях, находящихся вне поля зрения базового элемента Use Case. Наконец, можно моделировать отдельные потоки, вставка которых в определенную точку управляется актером.

Рис.

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

Диаграммы деятельностей (activity diagrams) предназначены для того, чтобы отразить переходы в рамках выполнения определенной задачи, вызванные внутренними процессами (в противоположность внешним событиям). Диаграммы деятельности используются для моделирования потоков работ в различных вариантах использования, для анализа вариантов использования.

Рис.

Основным элементом диаграммы деятельностей является состояние действия (action state). Состояние действия на диаграмме представляется как прямоугольник со скругленными углами. Выражение, описывающее выполняемое действие, располагается внутри прямоугольника. Выражения на одной диаграмме могут дублироваться.

Состояние действия представляет собой состояние, в котором определено внутреннее действие, и имеющее хотя бы один выходящий из него переход, включающий в себя неявное событие завершения данного внутреннего действия (при наличии условий перехода, таких переходов может быть несколько). Состояния действия не могут иметь внутренних или внешних исходящих переходов, основывающихся на явных событиях; в таких ситуациях используются обычные состояния. За одним состоянием действия следует другое состояние, вместе они образуют простую последовательность действий. Переходы, выходящие из состояния действия, неявно вызываются завершением некого события в состоянии. Переходы могут включать в себя условия перехода и действия. Выполняемое действие может быть описано на естественном языке или на любом языке программирования.

Начальное псевдосостояние (Start State) представляется маленьким черным кружком. Конечное псевдосостояние (End State) представляется маленьким черным кружком, обведенным сплошной линией.

В диаграмме деятельностей может использоваться состояние, связанное с принятием решения - решение (decision). Решение представляется на диаграмме как ромб, с одним или более входящим в него переходом и с одним или более выходящим переходом. Оно используется в тех случаях, когда в зависимости от условий перехода, может быть выбран тот или иной переход на диаграмме.

Может показаться, что диаграмма действий является аналогом схемы алгоритмов. Это не так. главное различие между схемой алгоритма и диаграммой деятельностей заключается в том, что на диаграмме действий доступна синхронизация, обеспечивающая возможность параллельного выполнения нескольких деятельностей, причем при этом порядок их выполнения не играет роли. Т. е. схемы алгоритмов ограничиваются последовательными процессами, а диаграммы деятельностей могут поддерживать параллельные процессы. Значок Synchronizations (синхронизация) позволяет определить независимо выполняемые действия. При этом действия разделяются на несколько выполняемых независимо и, только по завершении всех действий, объект продолжает работу. Этот значок представляет собой горизонтальную или вертикальную черту, обозначающую синхронизацию выполняемых работ.

Диаграммы деятельностей отражают происходящие события, однако они ничего не говорят о том, кто участвует в реализации того или иного процесса. Один способ решения этой проблемы - это снабдить каждое состояние действия меткой класса, который за него отвечает. Другой способ - применение так называемых плавательных дорожек (swimlines). В этом случае диаграмма деятельностей разделяется пунктирными линиями на вертикальные зоны. Каждая зона представляет собой зону ответственности конкретного класса, например, продавца, покупателя, менеджера и т. п. Другими словами, элементы диаграммы деятельностей перегруппировываются так, что на каждой дорожке находятся состояния действия для конкретного класса, т. е. видно кто что делает. Таким образом, на диаграмме деятельностей отображаются роли участников процесса. При этом сохраняется последовательность выполнения этих действий.

Диаграмма классов

На этапе анализа обычно разрабатывается предварительный вариант диаграммы классов (Class). Обычно, на основании диаграмм вариантов использования и диаграммы деятельности и их описания, составляется словарь терминов (понятий) предметной области. Затем он подвергается анализу: выделяются специфические для данной предметной области существительные и глаголы. Среди существительных выделяются некоторые ключевые понятия (сущности) и подчиненные им существительные. Например, СЧЕТ - ключевое понятие (сущность), а Номер Счета или Сумма На Счете и т. п. - подчиненные ему понятия. В дальнейшем, ключевые понятия (сущности) будут являться кандидатами на классы, а подчиненные им понятия - кандидатами на атрибуты классов. Глаголы, специфические для данной предметной области, будут являться кандидатами на методы классов и ассоциации.

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

В случае необходимости, на этом этапе кроме операций и атрибутов оговариваются и возможные ограничения. Например: Минимальная Сумма На Счете - 10 гривен.

Как и диаграммы Use Case, диаграммы классов могут содержать пакеты, используемые для группировки элементов модели в крупные фрагменты и, сокрытия деталей системы. В дальнейшем, при необходимости, эти пакеты могут быть развернуты. Между пакетами могут существовать только отношения зависимости.

Диаграмма развертывания

Кроме рассмотренных выше диаграмм на этапе анализа обычно выполняется предварительный анализ аппаратной части системы. Для этого предназначена диаграмма развертывания Deployment (топология). Совместно с диаграммой компонентов, эта диаграмма используется для физического представления модели. При помощи данной диаграммы проектировщик может произвести анализ необходимой аппаратной конфигурации, на которой будут работать отдельные процессы системы, и описать их взаимодействие между собой и другими аппаратными устройствами. Этот тип диаграмм также позволяет анализировать взаимодействие процессов, работающих на разных компьютерах сети. Для каждой модели такая диаграмма может быть только одна.

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

Элементами диаграмм развертывания (размещения) являются узлы, а также отношения зависимости и ассоциации. Узлы могут быть двух типов: процессоры (processor) и устройства (device).

Processor (процессор). Процессор - это устройство, способное выполнять программы. Процессор обязательно должен иметь свое имя (например, Компьютер), которое, однако, никак не связано с другими диаграммами модели по причине того, что процессор обозначает не программное обеспечение, а аппаратуру.

Device (устройство). Данный инструмент позволяет создавать на диаграмме объект устройства, неспособного выполнять программы. Каждое такое устройство также относится к аппаратному обеспечению и должно иметь общее для данного вида имя, такое как “модем”, или “терминал”.

Связь между узлами осуществляется с помощью инструмента Connection (соединение). Connection представляет собой некоторый тип кабельного или другого соединения, например, соединение при помощи сетевых карт, последовательных или параллельных портов или даже связь “Земля - спутник”. В отличие от реального соединения, на диаграмме не может быть показано направление перемещения информации посредством соединения, и считается, что соединение всегда двунаправлено. Конкретный тип соединения, при необходимости, может быть явно определен с помощью стереотипов - «RS-485», «10-T-Ethernet» и т. п. Визуально соединение отображается с помощью отрезка прямой линии.

Узлы, кроме имени, могут иметь дополнительную секцию, отображающую размещаемые в них элементы (обычно программные модули и компоненты). При необходимости, эту связь можно показать явно, используя отношения зависимости, хотя такой вариант применяется сравнительно редко.

Как и другие диаграммы, диаграммы развертывания могут включать примечания и ограничения. Кроме того, диаграммы развертывания могут включать компоненты, установленные в конкретном узле, а также содержать пакеты или подсистемы, используемые для группировки элементов модели в более крупные фрагменты. При необходимости визуализации конкретного варианта аппаратной топологии, в диаграммы размещения могут помещаться объекты.

Размещено на Allbest.ru