Лабораторная работа №1 «Разработка описания и анализ информационной системы в автотранспорте»



бет9/46
Дата08.11.2023
өлшемі1,15 Mb.
#190293
түріЛабораторная работа
1   ...   5   6   7   8   9   10   11   12   ...   46
Байланысты:
лаборат Инженерия 21,09,17

клиент

покупатель

постоянный покупатель

товар

поставщик

продавец

администратор

Проверка наличия товара

Занесение в список постоянных клиентов

Получение скидки

Прием товара

Занесение в базу данных (название, адрес, телефон и т.д.) 

Продажа товара

Доступ к базе данных

Покупка товара


Получение информацию о новых поступлениях

Занесение в базу данных (данные о поставщике, кол-ве, месте хранения и.д.)


Печать чека

Проверка статистики

Получение чека



Назначение цены


Доступ к каталогу

Переопределение цены

Заказ товара



Переопределение цены


Проверка наличия товара

Оформление заказа поставщику

Занесение покупателя и суммы покупки в базу данных



«Покупаемый» или «непокупаемый» товар


Оформление заказа покупателю

Печать заказа

Информация, извлеченная из точек зрения, используется для заполнения форм шаб­лонов точек зрения и организации точек зрения в иерархию наследования. Это позволяет увидеть общие точки зрения и повторно использовать информацию в иерархии наследо­вания. Сервисы, данные и управляющая информация наследуются подмножеством точек зрения. На рис. 5 показана часть иерархии точек зрения для системы поддержки заказа и учета товаров.

Рис. 5. Иерархия точек зрения


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

  1. Проверка правильности требований. Пользователь может считать, что система необ­ходима для выполнения некоторых определенных функций. Однако дальнейшие размышления и анализ могут привести к необходимости введения дополнительных или новых функций. Системы предназначены для разных пользователей с различными потребностями, и поэтому набор требований будет представлять собой неко­торый компромисс между требованиями пользователей системы.

  2. Проверка на непротиворечивость. Спецификация требований не должна содержать про­тиворечий. Это означает, что в требованиях не должно быть противоречащих друг другу ограничений или различных описаний одной и той же системной функции.

  3. Проверка на полноту. Спецификация требований должна содержать требования, ко­торые определяют все системные функции и ограничения, налагаемые на систему.

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

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

  1. Обзор требований. Требования системно анализируются рецензентами.

  2. Прототипирование. На этом этапе прототип системы демонстрируется конечным пользователям и заказчику. Они могут экспериментировать с этим прототипом, чтобы убедиться, что он отвечает их потребностям.

  3. Генерация тестовых сценариев. В идеале требования должны быть такими, чтобы их реализацию можно было протестировать. Если тесты для требований разрабаты­ваются как часть процесса аттестации, то часто это позволяет обнаружить пробле­мы в спецификации. Если такие тесты сложно или невозможно разработать, то обычно это означает, что требования трудно выполнить и поэтому необходимо их пересмотреть.

  4. Автоматизированный анализ непротиворечивости. Если требования представлены в виде структурных или формальных системных моделей, можно использовать инструментальные CASE-средства для проверки непротиворечивости моделей. Для автоматизированной проверки непротиворечивости необходимо построить базу данных требований и затем проверить все требования в этой базе данных. Анализатор требований готовит отчет обо всех обна­руженных противоречиях.



Достарыңызбен бөлісу:
1   ...   5   6   7   8   9   10   11   12   ...   46




©engime.org 2024
әкімшілігінің қараңыз

    Басты бет