Главная страница

ВВедение в ИМЛ. Лекция 2 Что такое The uml


Скачать 2.99 Mb.
НазваниеЛекция 2 Что такое The uml
АнкорВВедение в ИМЛ
Дата10.03.2023
Размер2.99 Mb.
Формат файлаdocx
Имя файлаvvedenie_v_UML (1).docx
ТипЛекция
#978338
страница9 из 24
1   ...   5   6   7   8   9   10   11   12   ...   24

Лекция 7: Диаграммы прецедентов: крупным планом



Аннотация: Мы уже познакомились с диаграммами UML нескольких видов. Все они описывают, как устроена и как работает система. Но иногда важно показать, как ведет себя система с точки

зрения внешнего наблюдателя, показать, что именно делает система, а не то, как она это делает. Для этого в UML имеется диаграмма прецедентов. О ней-то мы наконец и поговорим. В этой лекции мы рассмотрим такие вопросы: несколько слов о требованиях; диаграммы прецедентов и их нотация; моделирование при помощи диаграмм прецедентов

Несколько слов о требованиях


Итак, поговорим о требованиях. Что это такое, мы, в общем, понимаем - когда заказчик описывает нам, чего же именно он хочет, мы всегда слышим фразы типа "хотелось бы, чтобы проверка

обновлений проводилась автоматически, как в антивирусах", "хочу большую зеленую кнопку в

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

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

Если обратиться к классикам, например, к той же "банде трех" (Якобсон, Буч, Рамбо), мы узнаем, что требование - это желаемая функциональность, свойство или поведение системы. Именно со сбора требований начинается процесс разработки ПО. Если изобразить процесс

разработки ПОв виде " черногоящика" (уверены, читатель знает, что это такое, если нет -

"Википедия" к вашим услугам), на выходе которого мы получаем программный продукт, то на вход этого "черного ящика" будет подаваться именно набор требований к программному продукту (рис. 6.1)!


Рис. 6.1.


Кстати, какую диаграмму напоминает этот рисунок? Правильно, диаграммуактивностей. И

выбор именно этой диаграммы тут абсолютно оправдан - помните, мы говорили, что диаграммыактивностей часто используют для описания бизнес-процессов? Единственный нюанс: обычно процесс разработки не заканчивается с выпуском программного продукта - грядет

новая итерация, новые, уточненные требования, новая версия и т. д.

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

большинство читателей помнит, что такое техническоезадание- основной документ, без

составления которого не начинался в советские времена ни один проект. Документ это был

большой, многостраничный, с четкой структурой, определяемой ГОСТами (государственными отраслевыми стандартами). И описывал он, по сути, не что иное, как требования к создаваемой системе!

Техническое задание - вещь по-своему хорошая. Но время шло, менялись стандарты, нотации, способы описания требований. И вот постепенно техническое задание уступило место набору артефактов, состоящему из документов двух видов:

    • диаграммыпрецедентов;

    • нефункциональные требования.

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

прецеденты, часто в русской терминологии фигурируют как вариантыиспользования. Варианты

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

этого, варианты использования неявно описывают типичные способы взаимодействия

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

Нефункциональные требования - это описание таких свойств системы, как особенности среды и реализации, производительность, расширяемость, надежность и т. д. Часто нефункциональные требования не привязаны к конкретному варианту использования и потому выносятся в отдельный списокдополнительных требований к системе (рис.6.2).


1   ...   5   6   7   8   9   10   11   12   ...   24


написать администратору сайта