Глава 8 Создание проекта
Соответствие процессу: эта глава посвящена анализу в рамках дисциплины анализа и проектирования рационального унифицированного процесса (RUP).
Когда прецеденты будут зафиксированы, надо продолжить их анализ и начать процесс преобразования требований в проект системы. Это включает уточнение прецедентов и дальнейшее изучение их деталей.
В данной главе мы рассматриваем переход от прецедентов к начальному проекту системы.
Анализ прецедентов
Первоначальное исследование внутренних механизмов системы называется анализом прецедентов (use case analysis). При анализе прецедентов в начальной, обобщенной степени определяется, как должны взаимодействовать внутренние элементы, чтобы выполнить функциональные требования к системе, и как они относятся друг к другу статически. В этом процессе может быть затрачено много усилий и совершено много ошибок, прежде чем будет найдено удовлетворительное решение. По этой причине не следует тратить времени на создание детальных описаний внутренних элементов. Достаточно работать с "классами анализа", поведение которых часто описывается абстрактно, на естественном языке. Классы анализа не реализуются в программе. Позднее, в процессе собственно проектирования, на их основе составляются точно определенные классы и подсистемы проекта.
Реализация прецедентов
До сих пор мы обращали внимание в основном на то, чтобы зафиксировать требования и удостовериться, что мы понимаем, что именно нужно создать. Все эти действия универсальны в том смысле, что мы не привлекали никаких соображений относительно фактической реализации нашего решения.
Один и тот же набор функциональных требований может дать в результате очень разные системы, которые будут функционально эквивалентными, но совершенно различными по способу решения определенных проблем. Например, электронная банковская система может быть предложена заказчикам как два разных продукта: приложение, которое будет связываться непосредственно с банковской системой через модем, и Web-приложение, в котором применяется связь через Internet (возможно, банк захочет предложить систему с прямым соединением как более качественную и безопасную). В этих двух решениях функциональные требования одни и те же, но реализация совершенно разная.
Помочь в осуществлении нескольких реализаций проекта для одного и того же набора требований могут реализации прецедентов (use case realizations). Они позволяют превращать один и тот же прецедент в программное обеспечение разными способами, не порывая связи с исходными требованиями. Также они дают возможность выявлять связи с исходными требованиями для всех возможных моделей, которые могут быть разработаны на основе данного набора требований.
Графически реализация прецедента изображается пунктирным овалом. Отношение "реализации" в языке UML представляется пунктирной линией между реализацией и ее прецедентом. На рис. 8.1 показана реализация для прецедента "Перевод денег".
У каждой реализации прецедента могут быть свои диаграммы взаимодействий объектов и диаграммы классов. На каждой диаграмме взаимодействий объектов, которая создается в ходе анализа прецедентов, изображается взаимодействие между исполнителями и экземплярами классов анализа при осуществлении одного потока событий в прецеденте. Диаграммы классов иллюстрируют статические структурные отношения между этими внутренними элементами системы.
Уточненное описание прецедента
Процесс анализа прецедентов часто начинают, представляя обращенную к клиенту часть прецедентов в виде "черного ящика" текстовых описаний прецедентов и добавляя к ним "серый ящик", изображающий некоторые внутренние действия системы по их обработке. Описание прецедентов в виде "черного ящика" может быть полным с точки зрения клиента, но, конечно, информации в нем недостаточно для того, чтобы разработчики смогли построить систему.
Рассмотрим, например, прецедент "Перевод денег", который был намечен в предыдущей главе. Хотя этот прецедент точен в том смысле, что он полностью описывает происходящее взаимодействие, некоторые детали в нем отсутствуют. Например, как клиент выбирает счет? Должна ли система показывать ему список счетов? Может ли клиент указывать переводимую сумму денег в дробном виде, или это обязательно должно быть целое число? Как система проверяет, что на счету, с которого предполагается перевести деньги, есть достаточная сумма? Разрешение вопросов такого рода помогает уточнить прецеденты на стадии анализа прецедентов.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.