Выводы по практическому использованию

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

Выводы по диаграммам:

В языке UML для этапов анализа предназначены следующие виды диаграмм:

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

· activity diagram (диаграммы описаний технологий, процессов, функций);

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

· collaboration diagram (диаграммы взаимодействий).

Проанализируем их функциональную пригодность для этих целей.

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

Плюсом диаграммы является ее простота, наглядность и читабельность неспециалистами. Фактически является некоторым аналогом нотации IDEF0 (прецедент – работа, актер – один из механизмов).

Activity diagram – представляют собой схемы потоков управления в системе от действия к действию, а также параллельные и альтернативные потоки, с является неким аналогом нотацийIDEF0 и IDEF3. Т.е. понятие «перекресток» заменяется элементами «линия синхронизации» и «выбор», а «работа» - «действием». Диаграмма не очень приспособлена для отображения сложной логики, но возможно ее использование в качестве доступного для понимания аналога заказчику.

Дуги Use Case и Activity диаграмм не имеют смысловых типов, которые указаны для дуг IDEF0. Использование данных диаграмм требует установления дополнительных синтаксических соглашений, т.к. UML нежесткий язык и допускает построение синтаксически корректных Activity-диаграмм, не имеющих смысла или не поддающихся объяснению. Например, чтобы определить тип входящей стрелки, различать документы, можно их выделять цветом, использовать пунктирные и сплошные стрелки и т.п.

Sequence diagram – иллюстрирует события, инициирован­ные в системе исполнителями. Если изобразить диаграмму на абстрактном уровне в терминах предметной области, а систему рассматриваются как "черный ящик", то она является достаточно удобным инструментом для построения общей информационной модели. Т.е. входное сообщение является входной информацией в терминах IDEF0, а отклик системы (объекта) – выходной информацией.

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

Для этапа проектирования однозначно определены:

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

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

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

· Deployment diagram (диаграммы развертывания).

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

3. Методология ARIS