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

• Название: Лекция 2 Что такое The uml
• Анкор: ВВедение в ИМЛ
• Дата: 10.03.2023
• Размер: 2.99 Mb.
• Имя файла: vvedenie_v_UML (1).docx
• Тип: Лекция; #978338
• страница: 9 из 24

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

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

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

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

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

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

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

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

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

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

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

Рис. 6.1.

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

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

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

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

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

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

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

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

• 
  диаграммыпрецедентов;
  
• 
  нефункциональные требования.
  

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

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

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

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

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

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