ВВедение в ИМЛ. Лекция 2 Что такое The uml
Скачать 2.99 Mb.
|
Лекция 7: Диаграммы прецедентов: крупным планомАннотация: Мы уже познакомились с диаграммами UML нескольких видов. Все они описывают, как устроена и как работает система. Но иногда важно показать, как ведет себя система с точки зрения внешнего наблюдателя, показать, что именно делает система, а не то, как она это делает. Для этого в UML имеется диаграмма прецедентов. О ней-то мы наконец и поговорим. В этой лекции мы рассмотрим такие вопросы: несколько слов о требованиях; диаграммы прецедентов и их нотация; моделирование при помощи диаграмм прецедентов Несколько слов о требованияхИтак, поговорим о требованиях. Что это такое, мы, в общем, понимаем - когда заказчик описывает нам, чего же именно он хочет, мы всегда слышим фразы типа "хотелось бы, чтобы проверка обновлений проводилась автоматически, как в антивирусах", "хочу большую зеленую кнопку в центре окна, которая начинает процесс", "программа должна позволять просматривать и печатать отчеты", "и чтоб красивенько все было, с полупрозрачностями, как в Висте", "при выходе должно выводиться подтверждение" и т. д. и т. п. Конечно, как настоящие разработчики, мы понимаем и то, что заказчик никогда не знает, что именно ему нужно, а если понимает, то объяснить не может. Но ведь фразы-то всегда, по сути, одинаковы! Они описывают, как заказчик представляет себе систему, чего заказчик хочет от системы, функциональность, которой он от нее ожидает, требования, которые к ней предъявляет. Если обратиться к классикам, например, к той же "банде трех" (Якобсон, Буч, Рамбо), мы узнаем, что требование - это желаемая функциональность, свойство или поведение системы. Именно со сбора требований начинается процесс разработки ПО. Если изобразить процесс разработки ПОв виде " черногоящика" (уверены, читатель знает, что это такое, если нет - "Википедия" к вашим услугам), на выходе которого мы получаем программный продукт, то на вход этого "черного ящика" будет подаваться именно набор требований к программному продукту (рис. 6.1)! Рис. 6.1.Кстати, какую диаграмму напоминает этот рисунок? Правильно, диаграммуактивностей. И выбор именно этой диаграммы тут абсолютно оправдан - помните, мы говорили, что диаграммыактивностей часто используют для описания бизнес-процессов? Единственный нюанс: обычно процесс разработки не заканчивается с выпуском программного продукта - грядет новая итерация, новые, уточненные требования, новая версия и т. д. Кстати, вернемся к требованиям. Да, мы сказали, что на вход нашего "черного ящика" подается набор требований. Но в какой форме? Как их документируют, эти требования? Думаю, большинство читателей помнит, что такое техническоезадание- основной документ, без составления которого не начинался в советские времена ни один проект. Документ это был большой, многостраничный, с четкой структурой, определяемой ГОСТами (государственными отраслевыми стандартами). И описывал он, по сути, не что иное, как требования к создаваемой системе! Техническое задание - вещь по-своему хорошая. Но время шло, менялись стандарты, нотации, способы описания требований. И вот постепенно техническое задание уступило место набору артефактов, состоящему из документов двух видов: диаграммыпрецедентов; нефункциональные требования. Диаграммыпрецедентовсоставляют модельпрецедентов (вариантов использования, use- cases). Прецедент - это функциональность системы, позволяющая пользователю получить некий значимый для него, ощутимый и измеримый результат. Каждый прецедент соответствует отдельному сервису, предоставляемому моделируемой системой в ответ на запрос пользователя, т. е. определяет способ использования этой системы. Именно по этой причине use cases, или прецеденты, часто в русской терминологии фигурируют как вариантыиспользования. Варианты использования чаще всего применяются для спецификации внешних требований к проектируемой системе или для спецификации функционального поведения уже существующей системы. Кроме этого, варианты использования неявно описывают типичные способы взаимодействия пользователя с системой, позволяющие корректно работать с предоставляемыми системой сервисами. Нефункциональные требования - это описание таких свойств системы, как особенности среды и реализации, производительность, расширяемость, надежность и т. д. Часто нефункциональные требования не привязаны к конкретному варианту использования и потому выносятся в отдельный списокдополнительных требований к системе (рис.6.2). |