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

Ответ: Инфологическая модель (ИЛМ) Создание КМ завершается построением информационно-логической модели ИЛМ. ИЛМ является логической основой проектирования баз данных и основана на трактовке данных в контексте их взаимосвязи с другими данными. Построение ИЛМ требует определения состава и структуры данных предметной области, которые должны находиться в базе данных (БД) и обеспечить выполнение необходимых запросов. ИЛМ описывает требования к структуре базы данных. Тем не менее, данное описание должно быть независимым от выбора конкретной СУБД.

Вид и содержание ИЛМ определяется выбранным для этого формальным аппаратом. Обычно используются графические нотации, подобные ER-диаграммам.

Основными составляющими модели являются:

1) Сущность - реальный или абстрактный объект,

представляющий интерес для задач в

конкретной области о которых хранится

информация.

2) Отношения - связи между этими элементами

3) Атрибуты - характеристики этих элементов

На рисунке 3 изображен пример ИЛМ в виде диаграммы «сущность-связь». Производить нормализацию базы данных на этапе построения ИЛМ не требуется, например, физическая таблица «Накладная» может не содержать поле «Сумма накладной», а вычислять это значение во время запроса к таблице. На ИЛМ не обязательно отображать внешние ключи, которые будут обязательно использоваться при реализации базы данных с использованием реляционной системе управления база данных (РСУБД).

При разработке ИЛМ студент должен получить информацию о предметной области:

-  список сущностей предметной области;

-  список атрибутов сущностей;

-  описание взаимосвязей между сущностями.

Рисунок 3 – Упрощенный пример ИЛМ

8. Конкретизация требований к проектируемой системе с использованием вариантов использования.

Ответ: Конкретизация требований к проектируемой системе также может быть проведена с помощью модели вариантов использования (ВИ).

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

ВИ фиксирует соглашение между участниками системы о её по­ведении. ВИ описывает поведение системы при ее ответах на за­прос одного из участников, называемого основным действующим лицом (исполнителем), в раз­личных условиях. Основное действующее лицо инициирует взаимодействие с сис­темой, чтобы добиться некоторой цели. Система отвечает, соблюдая интересы всех участников. Различные модели поведения, или сценарии, развертываются в зави­симости от определенных запросов и условий, при которых делались эти запросы [6]

Исполнителем или действующим лицом (ДЛ) называют сущность, обладающую поведением, например, человека, систему или организацию. ДЛ представляет собой логически связанное множество ролей, которые играют пользователи ВИ во время взаимодействия с ними. ДЛ могут быть как люди, так и автоматизированные системы.

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

Когда варианты использования документируют бизнес-процессы организации, рассматриваемая система (SuD – system under discussion) и является этой организацией. Участники ­ это акционеры компании, заказчики, поставщики, органы государственного управления. Основные ДЛ ­ это заказчики компании и, возможно, их поставщики. Пример ВИ обработки заявления клиента о получении возмещения за страховое событие от страховой компании в таблице 1 [6].

Таблица 1 - ВИ «Обработка заявления»

Основной сценарий

1. Клиент подает заявление (на бумаге, по телефону или факсу) служащему.

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

3. Оценщик расследует заявление и обновляет его с помощью дополнительной информации

4. Оценщик вводит информацию по ходу расследования

5. Оценщик корректирует записи и резервирует сумму по ходу расследования

6. Оценщик получает документацию, включая счета за период срока действия заявления, и вводит счета

7. Оценщик оценивает ущерб по заявлению и документирует процесс переговоров в системе

8. Оценщик решает вопрос с возмещением и закрывает дело в системе

9. Система удаляет заявление из базы данных спустя 6 месяцев после закрытия дела

10. Система архивирует заявление по прошествию установленного периода

Расширения

а*. В любое время система выходит из строя: *а1. Группа системной поддержки восстанавливает систему.

1а. Представленная информация неполна: 1а1. Страховая компания запрашивает недостающую информацию. 1а2. Претендент предоставляет недостающую информацию. 1а2а. Претендент не предоставляет информацию в течение установленного периода. 1а2а1. Оценщик закрывает дело в системе.

2а. У претендента недействительный полис: 2а1. Страховая компания отклоняет заявление, уведомляет претендента, обновляет заявление, закрывает дело.

3а. На данный момент не свободных агентов. 3а1. (Что мы здесь делаем?).

8а. Претендент уведомляет оценщика о новых действиях по поводу возмещения: 8а1. Служащий открывает дело повторно. Возвращается к шагу 3.

Если варианты использования описывают требования к поведению части программного обеспечения, SuD - это компьютерная программа. Участники это пользователи программы, компания, владеющая ею, органы государственного управления и другие компьютерные программы. Основное ДЛ - это сидящий за компьютером пользователь или другая компьютерная система. Пример ВИ “Оформления продажи в магазине» при помощи программной системы приведен в таблице 2 [9].

Таблица 2 – Оформление продажи

Основной успешный сценарий (или основной процесс)

1. Покупатель подходит к кассовому аппарату Системы с выбранными товарами

2. Кассир открывает новую продажу.

3. Кассир вводит идентификатор товара.

4. Система записывает наименование товара и выдает его описание, цену и общую стоимость. Цена вычисляется на основе набора правил. Кассир повторяет действия, описанные в пп. 3-4 для каждого наименования товара.

5. Система вычисляет общую стоимость покупки с налогом.

6. Кассир сообщает покупателю общую стоимость и предлагает оплатить покупку.

7. Покупатель оплачивает покупку, система обрабатывает

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

9. Система выдает товарный чек.

10. Покупатель покидает магазин с чеком и товарами (если он что-то купил).

Расширения (или альтернативные потоки)

7а. Оплата наличными Кассир вводит предложенную покупателем сумму. Система вычисляет положенную сдачу и открывает кассу с наличностью. Кассир складывает полученные деньги и выдает сдачу покупателю. Система регистрирует платеж наличными.

Основное внимание при описании ВИ надо уделить тому, как использование системы обеспечит ощутимый для ДЛ результат.

Описание ВИ – текстовые документы, из которых вытекают функциональные требования, отвечающие на вопрос “что должна делать система?”.

Итак, ВИ описывает, что делает система (подсистема), но не определяет, каким образом она это делает.