Создание проекта. Анализ прецедентов. Реализация прецедентов. Уточненное описание прецедента

Страницы работы

Содержание работы

Глава 8 Создание проекта

Соответствие процессу: эта глава посвящена анализу в рамках дисциплины анализа и проектирования рационального унифицированного процесса (RUP).

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

В данной главе мы рассматриваем переход от прецедентов к начальному проекту системы.

Анализ прецедентов

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

Реализация прецедентов

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

Один и тот же набор функциональных требований может дать в результате очень разные системы, которые будут функционально эквивалентными, но совершенно различными по способу решения определенных проблем. Например, электронная банковская система может быть предложена заказчикам как два разных продукта: приложение, которое будет связываться непосредственно с банковской системой через модем, и Web-приложение, в котором применяется связь через Internet (возможно, банк захочет предложить систему с прямым соединением как более качественную и безопасную). В этих двух решениях функциональные требования одни и те же, но реализация совершенно разная.

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

Графически реализация прецедента изображается пунктирным овалом. Отношение "реализации" в языке UML представляется пунктирной линией между реализацией и ее прецедентом. На рис. 8.1 показана реализация для прецедента "Перевод денег".

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

Уточненное описание прецедента

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

Рассмотрим, например, прецедент "Перевод денег", который был намечен в предыдущей главе. Хотя этот прецедент точен в том смысле, что он полностью описывает происходящее взаимодействие, некоторые детали в нем отсутствуют. Например, как клиент выбирает счет? Должна ли система показывать ему список счетов? Может ли клиент указывать переводимую сумму денег в дробном виде, или это обязательно должно быть целое число? Как система проверяет, что на счету, с которого предполагается перевести деньги, есть достаточная сумма? Разрешение вопросов такого рода помогает уточнить прецеденты на стадии анализа прецедентов.

Похожие материалы

Информация о работе