Анализ вариантов использования - Use-case analysis

Анализ вариантов использования - это метод, используемый для определения требований к системе (обычно связанных с разработкой программного обеспечения / процесса) и информации, используемой для определения используемых процессов и классов (которые представляют собой совокупность субъектов и процессов), которые будут использоваться как в диаграмма вариантов использования и в целом вариант использования при разработке или перепроектировании программной системы или программы. Анализ вариантов использования - это фундамент, на котором будет построена система.^[1]

Задний план

Анализ варианта использования - это основная форма для сбора требований к использованию для новой программы или задачи, которую необходимо выполнить. Основными целями анализа варианта использования являются: проектирование системы с точки зрения пользователя, передача поведения системы в терминах пользователя и определение всех видимых извне поведений. Другой набор целей для анализа вариантов использования - четко сообщить: системные требования, то, как система должна использоваться, роли, которые пользователь играет в системе, что система делает в ответ на стимулы пользователя, что пользователь получает от систему и какую ценность получит от системы покупатель или пользователь.^[2]

Обработать

Анализ варианта использования состоит из нескольких этапов.

Реализация

Реализация варианта использования описывает, как конкретный вариант использования был реализован в рамках проектной модели с точки зрения взаимодействующих объектов.^[3]

Этап реализации устанавливает структуру, в которой анализируется возникающая система. Здесь документируется первый, самый общий план того, что требуется для системы. Это влечет за собой грубую разбивку процессов, участников и данных, необходимых для системы. Это то, что составляет классы анализа.^{[нужна цитата ]}

Описание

После того, как общий план завершен, следующим шагом будет описание поведения системы, видимого потенциальному пользователю системы. Хотя внутреннее поведение также можно описать, это больше связано с проектированием системы, а не со сбором требований к ней. Преимущество краткого описания внутреннего поведения будет заключаться в разъяснении потенциальным пользователям того, что система не упускает жизненно важный компонент извне из-за того, что он завершается внутри. Общая цель этого шага - предоставить достаточно деталей, чтобы понять, какие классы требуются для системы. Слишком большое количество деталей может затруднить изменение системы в дальнейшем.^[4]

Классы анализа

Этот шаг сужает список классов до тех классов, которые способны выполнять поведение, необходимое для успешного функционирования системы. Если для системы еще не существует классов, их необходимо создать до завершения этого шага. Классы можно создавать разными способами из множества источников. Вот несколько примеров: предыдущие, но похожие системы, модели предприятия и интеллектуальный анализ данных. После того, как классы созданы и сужены, необходимо установить отношения между классами, которые теперь называются классами анализа, которые моделируют задачу системы.^[4]

Обязанности

Для каждого класса анализа, указанного на предыдущем шаге, необходимо четко указать обязанности класса. Это гарантирует, что у отдельного класса есть задача, которую не может выполнить ни один другой класс в системе. Обязанности разных классов не должны пересекаться.^[4]

Ассоциации

После подробного описания обязанностей каждого класса анализа следует уточнить отношения между классами. Этот шаг состоит из четырех частей:

Определите классы, которые будут использоваться.
Определите возможные отношения между классами.
Для тех, у кого есть отношения, опишите характер отношений.
Если возможно, определите множественность отношения, то есть определите, сколько из первого класса соответствует одному объекту во втором классе отношения.^[4]

На рисунке 1 показан пример ассоциаций между классами:

Взаимосвязи анализа случаев использования на примере магазина видео

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

Поведение

После того, как отношения между классами будут поняты, следующий процесс - детализировать поведение, которое классы будут демонстрировать, и то, как они будут взаимодействовать для завершения системы. Это влечет за собой определение того, как классы взаимодействуют и отправляют сообщения на временной шкале разрабатываемого системного процесса. Это проистекает из обязанностей ранее определенных классов. Определение того, к какому классу относится сообщение, следует за ассоциациями, установленными на предыдущем шаге.^[4]

Описать атрибуты

До сих пор в ходе анализа вариантов использования могли быть обнаружены атрибуты классов и объектов, которые необходимы классам для выполнения своих задач. Они могут быть в форме переменных данных или функций. Некоторые из этих атрибутов могут быть получены из предыдущих шагов, в то время как другие являются общими предположениями из общеизвестных знаний (например, все работающие современные компьютеры имеют операционную систему, процессор и устройства ввода / вывода).^[4]

Посмотрите на рисунок 2 в качестве примера описанных атрибутов после диаграммы на рисунке 1:

Анализ сценария использования Описание примера магазина видео

Атрибуты, описанные на диаграмме на этом этапе, обычно являются элементами, которые становятся данными, необходимыми для правильного функционирования системы / процесса.

Механизмы

Последний шаг - определить компоненты, которые обеспечивают решение проблемной области. Сюда входят базы данных для хранения данных, безопасности, обработки исключений и связи между процессами или программами.^[4]

использованная литература

^ Тейлор, ст. «Методы анализа, проектирования и разработки с помощью J2EE». InformIT. 6 июня 2003 г. 22 марта 2008 г. <http://www.informit.com/articles/article.aspx?p=31942&seqNum=5 >
^ Шаклетт, Марк. 22 марта 2008 г. <http://people.cs.uchicago.edu/~mark/51023/Ucstyleg.html >
^ Реализация вариантов использования Эсекьель Куэльяр
^ ^а ^б ^c ^d ^е ^ж ^г Переход от вариантов использования к коду, часть 1: Анализ вариантов использования Гэри Эванс, IBM, 2004 г.

[1] Тейлор, ст. «Методы анализа, проектирования и разработки с помощью J2EE». InformIT. 6 июня 2003 г. 22 марта 2008 г. <http://www.informit.com/articles/article.aspx?p=31942&seqNum=5 >

[2] Шаклетт, Марк. 22 марта 2008 г. <http://people.cs.uchicago.edu/~mark/51023/Ucstyleg.html >

[3] Реализация вариантов использования Эсекьель Куэльяр

[ibm-4] а ^б ^c ^d ^е ^ж ^г Переход от вариантов использования к коду, часть 1: Анализ вариантов использования Гэри Эванс, IBM, 2004 г.

[1]

[2]

[3]

[4]