Характеристика визуального моделирования

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

Визуальное моделирование. Язык UML

1. Идея визуального моделирования

Вспомним, в чем состоит основная проблема в разработке ПО? Проекты не укладываются в сроки, бюджет, не удовлетворяют требованиям.

Как решать эту проблему? На помощь приходит моделирование. Под моделью обычно понимают упрощенное представление объектов и явлений реального мира.

Ответим на вопрос, зачем строят модели? Модели строят для того, чтобы лучше понять исследуемую систему.

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

Задачи моделирования:

Визуализация системы в ее некотором состоянии.

Определение структуры и поведения системы.

Получение шаблона для создания системы.

Документирование принятых решений.

Принципы моделирования [3.3]:

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

Каждая модель может быть воплощена с разной степенью абстракции.

Лучшие модели - те, что ближе к реальности.

Наилучший подход при разработке сложной системы - использовать несколько почти независимых моделей.

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

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

Это и означает необходимость визуального моделирования.

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

Визуализация упрощает понимание проекта в целом.

Визуализация помогает согласовать терминологию и убедиться, что все одинаково понимают термины.

Визуализация делает обсуждение конструктивным и понятным.

Для визуального моделирования нужна специальная нотация или язык.

UML (unified modeling language) - это язык для визуализации, специфицирования, конструирования, документирования элементов программных систем. UML - язык общего назначения, предназначенный для объектного моделирования.

2. Структура языка UML

2.1 Модели UML

UML позволяет описывать систему следующими моделями:

Модель функционирования (показывает, как описывается функциональность системы с точки зрения пользователя).

Объектная модель (показывает, как выглядит проект системы с точки зрения объектного подхода).

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

2.2 UML диаграммы в Rational Rose

Rational Rose - мощное CASE-средство для проектирования программных систем любой сложности. Одним из достоинств этого программного продукта будет возможность использования диаграмм на языке UML. Можно сказать, что Rational Rose является графическим редактором UML диаграмм. (Подробнее читайте в книге "CASE-технологии: Практическая работа в Rational Rose".)

В распоряжение проектировщика системы Rational Rose предоставляет следующие типы диаграмм, последовательное создание которых позволяет получить полное представление о всей проектируемой системе и об отдельных ее компонентах :

Use case diagram (диаграммы прецедентов);

Deployment diagram (диаграммы топологии);

Statechart diagram (диаграммы состояний);

Activity diagram (диаграммы активности);

Interaction diagram (диаграммы взаимодействия);

Sequence diagram (диаграммы последовательностей действий);

Collaboration diagram (диаграммы сотрудничества);

Class diagram (диаграммы классов);

Component diagram (диаграммы компонент).

Диаграммы прецедентов (Use case diagram)

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

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

Данный тип диаграмм используется при описании бизнес процессов автоматизируемой предметной области, определении требований к будущей программной системе. Отражает объекты как системы, так и предметной области и задачи, ими выполняемые.

Диаграммы топологии (Deployment diagram)

Этот вид диаграмм предназначен для анализа аппаратной части системы, то есть «железа», а не программ. В прямом переводе с английского Deployment означает «развертывание», но термин «топология» точнее отражает сущность этого типа диаграмм.

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



Обычно этот тип диаграмм используется в самом начале проектирования системы для анализа аппаратных средств, на которых она будет эксплуатироваться.

Диаграммы состояний (State Maсhine diagram)

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

Диаграмма состояний (Statechart) предназначена для отображения состояний объектов системы, имеющих сложную модель поведения. Это одна из двух диаграмм State Machine, доступ к которой осуществляется из одного пункта меню.

Диаграммы активности (Activity diagram)

Это дальнейшее развитие диаграммы состояний. Фактически данный тип диаграмм может использоваться и для отражения состояний моделируемого объекта, однако, основное назначение Activity diagram в том, чтобы отражать бизнес-процессы объекта. Этот тип диаграмм позволяет показать не только последовательность процессов, но и ветвление и даже синхронизацию процессов.

Этот тип диаграмм позволяет проектировать алгоритмы поведения объектов любой сложности, в том числе может использоваться для составления блок-схем.

Диаграммы взаимодействия (Interaction diagram)

Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.

Диаграммы последовательностей действий (Sequence diagram)

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



Данный тип диаграмм позволяет отразить последовательность передачи сообщений между объектами. Этот тип диаграммы не акцентирует внимание на конкретном взаимодействии, главный акцент уделяется последовательности приема/передачи сообщений. Для того чтобы окинуть взглядом все взаимосвязи объектов, служит Collaboration diagram.

Диаграммы сотрудничества (Collaboration diagram)

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

По причине того, что диаграммы Sequence и Collaboration являются разными взглядами на одни и те же процессы, Rational Rose позволяет создавать из Sequence диаграммы диаграмму Collaboration и наоборот, а также производит автоматическую синхронизацию этих диаграмм.

Диаграммы классов (Class diagram)

Этот тип диаграмм позволяет создавать логическое представление системы, на основе которого создается исходный код описанных классов.



Значки диаграммы позволяют отображать сложную иерархию систем, взаимосвязи классов (Classes) и интерфейсов (Interfaces). Данный тип диаграмм противоположен по содержанию диаграмме Collaboration, на котором отображаются объекты системы. Rational Rose позволяет создавать классы при помощи данного типа диаграмм в различных нотациях. похожего на облако. Таким образом Г.Буч пытается показать, что класс - это лишь шаблон, по которому в дальнейшем будет создан конкретный объект.

Диаграммы компонентов (Component diagram)

Этот тип диаграмм предназначен для распределения классов и объектов по компонентам при физическом проектировании системы. Часто данный тип диаграмм называют диаграммами модулей.

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

2.3 Понятия UML

Для описания структуры: Актер, Атрибут, Класс, Компонент, Интерфейс, Объект, Пакет.

Для описания поведения: Действие, Событие, Сообщение, Метод, Операция, Состояние, Вариант использования.

Для описания связей: Агрегация, Ассоциация, Композиция, Зависимость, Наследование.

Некоторые другие понятия: Стереотип, Множественность, Роль.

3. Система бронирования билетов для авиакомпании

3.1 Краткое описание

На рынок вышла новая авиакомпания "GlobalAvia". Менеджеры компании решили заказать у вашей фирмы разработку системы бронирования билетов. При заказе фирма поставила ряд условий, которые обязательно должны быть выполнены. В первой версии системы они хотят видеть две части. Работа первой части системы связана с занесением информации. Вторая часть системы предназначена для общения с клиентами.

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

Анализ постановки - полное описание

Задача является математической. Система должна уметь решать однокритериальную задачу поиска кратчайших путей на графах. Критерий - цена.

Система распределенная: так как в каждом аэропорте своя база направлений полетов самолетов, то знают о рейсе только аэропорты-соседи по рейсам.

Объекты системы: распределенное хранилище рейсов, покупатель билетов, менеджер рейсов.

Распределенное хранилище рейсов: название рейсов, номера и стоимость билетов.

Покупатель: ФИО, сумма. Покупатель задает параметры, связанные с суммой, которую он хочет потратить. Система должна подобрать оптимальный маршрут. При отсутствии прямых маршрутов система должна попробовать найти маршруты с пересадками. Если таковых не находится, система должна сказать, что с такими ограничениями нельзя добраться до места назначения.

Среди причин:

Отсутствие рейсов в желаемом направлении даже с учетом пересадок.

Нехватка денег.

В ответ, пользователь должен иметь возможность поменять параметры с учетом предыстории.

Менеджер рейсов: должен иметь следующие возможности:

создания и удаления аэропортов в системе.

создания и удаления рейсов в аэропортах.

4. Визуальное описание функциональной модели средствами UML

4.1 Актеры и варианты использования в UML

Программная система не функционирует сама по себе. Программная система функционирует под воздействием актеров (Actor) - пользователей, машин и других программ. При этом актер ожидает, что система ведет себя строго определенным образом. Актер оказывает воздействие - система выдает ожидаемый результат. В случае, если ожидаемого результата нет, требования пользователя не удовлетворены со всеми вытекающими отсюда результатами. Таким образом, актер в UML - человек, машина или программа, воздействует на систему, является внешним по отношению к ней. Модель того, как воздействие приводит к результату, называется Вариантом использования (Use case). Актеры и варианты использования имеют специальные обозначения в UML:

Рис. 4.1

Актеры и варианты использования общаются посредством посылки сообщений. Сообщения могут идти в обе стороны. Стрелка показывает инициатора общения (актер на рисунке) и может быть опущена.

Рис. 4.2.

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

Перечень Вариантов использования для нашей задачи может быть, например, таким:

Забронировать билет.

Подобрать рейс.

Работать с данными.

Управлять рейсами.

Работать с БД аэропорта.

Для визуального представления актеров, вариантов использования и отношений между ними в UML предусмотрена специальная диаграмма - диаграмма вариантов использования. Ниже приведена диаграмма для рассматриваемого примера:

Рис. 4.3.

Приведем некоторые дополнительные соображения :

При таком моделировании обращают внимание на поведение системы, а не на ее реализацию.

Хорошая модель описывает основное поведение системы, не являясь слишком подробной.

Подобная модель позволяет проверить, удовлетворит ли система требования заказчика.

Система средних размеров может быть описана большим количеством вариантов использования.

Варианты использования могут описываться разными сценариями.

На последнем пункте остановимся подробнее. Очевидно, название варианта использования не дает полного представления о том, как он претворяется в жизнь. Для описания сценария работы варианта использования UML содержит специальные средства. Основное из них - диаграмма действия.

Диаграмма действия это блок-схема, которая отображает динамику в поведении системы. Заметим, что эта диаграмма может использоваться не только для описания сценариев Варианта использования.

Приведем пример соответствующей диаграммы для варианта использования Бронирование билетов в системе SRS.

Рис. 4.4.

5. Структура системы и ее описание средствами UML

В данном разделе рассматриваются элементы UML, предназначенные для описания структуры проектируемой программной системы. Наше изложение устроено следующим образом: для стандартных понятий, известных из курса ООП, мы приводим только обозначения. Для других прежде всего даем определение и краткую характеристику. Итак, приступим.

5.1 Классы

Рис. 4.5.

Обозначения модификаторов доступа:

+ public

# protected

- private

5.2 Шаблоны классов

Рис. 4.6.

5.3 Объекты

Рис. 4.7.

Интерфейсы

Определимся с тем, что мы в данном случае понимаем под Интерфейсом.

Интерфейс определяет границу между спецификацией того, что делает абстракция, и реализацией того, как она это делает [3.3].

Интерфейс - это набор операций, используемых для специфицирования услуг, предоставляемых классом или компонентом [3.3].

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

Во многих языках программирования понятие Интерфейс включено в объектную модель, что сообразно отражается на синтаксисе (Object Pascal, Java и др.). С++, к сожалению, не содержит понятия Интерфейс, поэтому Интерфейсы моделируются посредством использования классов.

Рис. 4.8

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

...