Методология UML

Введение

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

В данном проекте мы обратимся  к построению и анализу необычных  моделей. В качестве предметной области  рассмотрим Фирма-разработчик утилит системной оптимизации. Вербальное описание и сущность фирмы-разработчика рассмотрим в следующем разделе. Построение соответствующих диаграмм и схем является первой задачей данной работы. Такой анализ будет производиться с помощью специализированного программного обеспечения. Visual™ UML™ - программный пакет для создания диаграмм нотации UML, построения по диаграммам архитектуры будущего программного проекта; Microsoft® Visio™ - мощный инструмент построения и анализа различных диаграмм и схем с полным набором графических средств и инструментов.

 

Описание  задачи:

Создать информационную систему (далее ИС) для «Фирма-разработчик ПО». В данной системе главным действующим лицом является «Заказчик». Заказчик обращается к фирме по разработке ПО для создания уникального ПО для своей деятельности.

 

Функции системы:

1. Сформировать бюджет фирмы
2. Произвести рекламную программу (привлечь заказчиков)
3. Принять заказ от заказчика
4. Занести данные в бюджет фирмы
5. Принять и обработать требования от заказчика
6. Формирование списка задача для программистов
7. Корректировка и улучшение ПО
8. Разработка и тестирование ПО
9. Реализация ПО

 

Краткое описание ИС  Фирма-разработчик утилит системной оптимизации

Описание информационной системы «Фирма-разработчик утилит системной оптимизации»:

• Фирма-разработчик функционирует в сфере многоплановой оптимизации ОС класса Microsoft Windows. (Например: GMBH TuneUp Utilites, Auslogics BoostSpeed, Raxco Int.)
• Внешние заказы к разработке поступают от пользователей ОС Microsoft Windows, а также от третьих компаний по разработке и эксплуатации ПО.
• Выполненные проекты представлены в виде дистрибутивного пакеты, включающего инсталляционные пакеты, библиотеки, документацию, контактную информацию для поддержки, информация о лицензировании.
• Распространение конечных продуктов осуществляется в виде BOX’ов с компакт-диском, либо опционально по сети Интернет. Предусмотрено несколько способ оплаты.
• Разрабатываемое ПО учитывает множество аспектов оптимизации, такие как: Компоненты ОС Windows, дисковая подсистема, интернет-соединение, оптимальный менеджмент пользовательскими данными, контроль актуальности имеющегося ПО (обновление). Сканеры конечного продукта – адаптивные.
• Основная концепция программного продукта – возможность выбора пользователем режимов функционирования: мануальный и/или автоматический.
• Интерфейс ПП представлен в виде интегратора утилит различного назначения. В интеграторе (главный интерфейс на  окно) утилиты структурированы, сгруппированы по типу задач. Присутствуют так называемые «однокнопочные решения». Диагностики и оптимизации.
• Имеется «горячая» справочная система.

 

 

Диаграмма вариантов  использования (USE-CASE)

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

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

Рис 1. Диаграмма USE-CASE

В данной диаграмме есть интересная деталь: «Разработчики». В данной ИС программисты, отдел по планированию, тестеры имеют схожие функции поэтому они объедены в одну группу называемую «Разработчики».

 

Сценарии  вариантов использования.

Чтобы рассмотреть диаграмму  вариантов использования поближе необходимо разработать сценарии работы ИС.

 

Сценарий 1:

Название: Оформление заказа

Актеры: Заказчик, Менеджер

Описание:

Оформление заказа для  начала разработки ПО

 

Основной ход события:

1. Заказчик обращается к менеджеру и предоставляет задание для разработки ПО, его необходимый функционал, пожелания, требования для разрабатываемого ПО.
2. Менеджер сообщает стоимость заказного ПО
3. Менеджер заносит данные в БД, а также передает документы в финансовый отдел

Возможные проблемы в сценарии:

1. Отказ заказчика от разработки ПО – в данном случае разработка ПО не начинается.

 

 

Сценарий 2:

Название: Учет требований

Актеры: Заказчик, Разработчики

Описание:

Анализ и обработка  требований и пожеланий заказчика  к ПО

 

Основной ход события:

1. Заказчик передает  требования и пожелания
2. Разработчики анализируют и предоставляют заказчику обработанные требования и пожелания (возможно/не возможно, возможное усовершенствование предъявленных требований)
3. Заказчик ознакомляется с требованиями и пожеланиями разработчиков, если соглашается, то начинается разработка ПО

Возможные проблемы в сценарии:

1. Отказ заказчика от разработки ПО – в данном случае разработка ПО не начинается.
2. Отказ или не согласие с представленными требованиями и пожеланиями – в этом случае заказчик представляет свои новые требования исходя из обработанных требований разработчиками

 

 

Сценарий 3:

Название: Формирование списка задач

Актеры: Разработчики (в данном сценарии рассматривается отдел по планированию и программисты)

Описание:

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

 

Основной ход события:

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

Возможные проблемы в сценарии:

Отсутствуют

 

Сценарий 4:

Название: Разработка ПП

Актеры: Разработчики (в данном сценарии рассматривается программисты)

Описание:

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

 

Основной ход события:

1. Прием списка задач и требований от отдела планирования
2. Начало разработки ПП

Возможные проблемы в сценарии:

Отсутствуют

 

Сценарий 5:

Название: Тестирование

Актеры: Разработчики (в данном сценарии рассматривается тестеры)

Описание:

Выполняются тесты ПП на наличие ошибок и не точностей.

 

Основной ход события:

1. Программисты высылают ПП тестерам
2. Тестеры выполняю тесты
3. После тестов, составляется отчет о полной готовности ПП

Возможные проблемы в сценарии:

1. Если в отчете указаны ошибки, то начинается процесс корректировки

 

Сценарий 6:

Название: Корректировка и усовершенствование ПП

Актеры: Разработчики

Описание:

Выполняется устранение дефектов в ПП, ведётся рекурсивное усовершенствование ПП.

 

Основной ход события:

1. По отчетам составлены тестерами (в случае обнаружении ошибок) начинается процесс корректировки ПП

Альтернативный  ход события:

1. Рекурсивное улучшение ПП

Возможные проблемы в сценарии:

Отсутствуют

 

Сценарий 7:

Название: Запрос в техническую поддержку

Актеры: Заказчик, Отдел технической поддержки

Описание:

Обслуживание заказчика, решение вопросов и помощь в ПП.

Ссылки:

1. Расширения:

1. Формирование списка запросов

 

Основной ход события:

1. Заказчик посылает запрос в техническую поддержку
2. Отдел технической поддержки принимает запрос, обрабатывает и отвечает на заданный вопрос.
3. Если запрос уникальный и не повторялся, то он заносится в БЗ (база знаний).

Возможные проблемы в сценарии:

1. Обнаружение ошибки в ПП – в данном случае посылается запрос на корректировку ПП и начинается процесс корректировки ПП, а также добавление записи в БЗ.

 

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

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

Диаграмма классов UML - это  граф, узлами которого являются элементы статической структуры проекта (классы, интерфейсы), а дугами - отношения  между узлами (ассоциации, наследование, зависимости).

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

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

 

Диаграммы последовательности

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

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

На  диаграмме  последовательности  объект  изображается  в  виде прямоугольника,  от  которого  вниз  проведена  пунктирная  вертикальная линия.  Эта  линия  называется  линией  жизни (lifeline)  объекта.  Она представляет  собой  фрагмент  жизненного  цикла  объекта  в  процессе взаимодействия.

Каждое  сообщение  представляется  в  виде  стрелки  между  линиями жизни  двух  объектов. Сообщения  появляются  в  том  порядке,  как  они  показаны  на странице  сверху вниз.  Каждое  сообщение помечается  как минимум именем  сообщения. При желании можно добавить  также аргументы и некоторую управляющую информацию. Можно показать самоделегирование (self-delegation) – сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни.

 

Диаграммы коопераций

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

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

 

 

Диаграмма размещения

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

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