Шаг - Точное формулирование требований к системе
В начале пути у нас есть лишь один главный вопрос: «Что должна делать система?».
Необходимо четко, лаконично и формально описать требования к системе. Например, система должна:
1. Формировать справочник…
2. Вводить информацию о …..
3. Осуществлять поиск ….
Рекомендуется сначала проанализировать те данные, которые будут храниться в вашей системе постоянно (условно-постоянно). Обычно такими данными являются справочники. Затем необходимо сформировать требования, предъявляемые к хранению и обработке заново возникающей информации или часто изменяющейся (документы).
Затем следует описать обработки данных в системе, осуществление поиска, различных расчетов и пр. Затем следует анализировать формирование отчетов системы. В некоторых случаях возникают и другие действия: авторизация пользователя и пр. Требования к таким возможностям системы тоже необходимо формулировать.
Сформулированные требования в дальнейшем будут основой для создания диаграммы вариантов использования.
2 шаг - Проектирование диаграммы вариантов использования
Создается диаграмма вариантов использования на основе сформулированных требований.
Цель построения диаграмм ВИ – документирование функциональных требований к системе в самом общем виде, поэтому они должны быть предельно простыми.
Поиск актеров — большая работа. Актером может быть как пользователь, так и другая система и время.
|
|
|
Каждый элемент Use Case задает некоторый путь использования системы, выполнение некоторой части функциональных возможностей. Полная совокупность элементов Use Case определяет все существующие пути использования системы.
Рассматривая каждого актера, мы решаем, какие элементы Use Case он может выполнять. Для этого изучается описание системы (с точки зрения актера) или проводится обсуждение с теми, кто будет действовать как актер.
Чаще всего полные описания элементов Use Case формируются за несколько итераций. На каждом шаге в описание вводятся дополнительные детали.
Не всегда очевидно, как распределить функциональные возможности по отдельным элементам Use Case и что является вариантом одного и того же элемента Use Case. Основной критерий выбора — сложность элемента Use Case. При анализе вариантов поведения рассматривают их различия. Если различия малы, варианты встраивают в один элемент Use Case. Если различия велики, то варианты описываются как отдельные элементы Use Case. ПРИМЕР
Элемент Use Case описывает, что должна делать система, но не определяет, как она должна это делать. При моделировании это позволяет отделять внешнее представление системы от ее внутреннего представления.
Дата добавления: 2016-01-05; просмотров: 18; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!