Лабораторные работы БД / Лабораторная 1. UseCase

Лабораторная № 1. Анализ требований (UML)

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

Для документирования требований используется диаграммы языка UML.

UML (англ. Unified Modeling Language – унифицированный язык моделирования) – язык графического моделирования в области разработки программного обеспечения. UML не является языком программирования, но на основании UML-моделей возможна генерация кода.

UML-модель – пакет, в котором содержится полное описание системы, сделанное с определенной точки зрения на определенном уровне абстракции. Модели сопровождают все этапы жизненного цикла процесса разработки программного обеспечения.

Сущности – это абстракции, являющиеся основными элементами модели. Отношения связывают сущности. Совокупности сущностей и отношений группируются в диаграммы.

Диаграмма вариантов использования (Синонимы: диаграмма прецедентов, Use Case Diagram) – иллюстрирует, какие актеры в каких вариантах использования фигурируют.

Сущность	Описание	Нотация
Актер (Actor)	Пользователи системы или иные объекты, непосредственно взаимодействующие с ней
Вариант использования, прецедент (Use Case)	Спецификация поведения системы при взаимодействии с актерами	Функция
Отношение	Описание	Нотация
Ассоциация	Отношение, указывающее на связь между актером и вариантом использования
Расширение	Включение дополнительного (необязательного) поведения в исходный вариант использования	<<extend>>
Включение	Выделение одного из обязательных действий в составе варианта использования	<<include>>
Обобщение	Отношение между общим и более специфичным (второй наследует черты первого, добавляя к ним свои)

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

Правила:

1. Не моделировать связи между актерами. По определению актеры находятся вне системы и связи между ними не относятся к сфере компетенции диаграммы.

2. Не соединять связью непосредственно два варианта использования, кроме случаев связи включения и расширения. Диаграммы данного типа не описывают порядок выполнения вариантов использования.

3. Каждый вариант использования должен быть инициирован актером.

4. Не требуется, чтобы актер был связан с каждым вариантом использования.

5. При выделении вариантов использования следует придерживаться концепции «Уровня моря», т.е. не слишком мелко и не слишком крупно. Допустимо опускаться до уровня подфункций в следующих случаях:

   1. Для более легкого прочтения диаграммы

   2. При их большой важности для проекта

   3. При их частой повторяемости

   4. Если этот вариант использования является единственным для определенного актера.

Пример:

Информационная система оптового заводского склада

На склад поставляются детали, выполненные из определенных материалов, от заданного круга поставщиков (постоянных или случайных) из различных городов.

В качестве поставщиков могут выступать юридические лица и индивидуальные предприниматели, причем эти группы описываются своим набором характеризующих атрибутов; юридические лица – номер и дата госрегистрации, наименование, юридический адрес, форма собственности; предприниматели – ИНН, ФИО, страховой полис, номер паспорта, дата прописки.

При оформлении поставки учитываются дата, количество и стоимость, вид упаковки и способ доставки (автотранспорт, ж/д транспорт, самовывоз), причем одна поставка может включать несколько видов деталей.

Поставщики переходят в разряд постоянных, если в течение года они совершили поставок на сумму свыше 1000000 рублей.

Осуществляется отпуск деталей в цеха завода с учетом даты, количества и номера цеха. Поддерживается актуальное количество товаров на складе.

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