Файл: Контрольная работа.docx

ВУЗ: Не указан

Категория: Методичка

Дисциплина: Проектирование информационных систем

Добавлен: 21.10.2018

Просмотров: 608

Скачиваний: 12

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

СОДЕРЖАНИЕ




Цель работы

Освоить методы структурного моделирования процессов на основе IDEF-методологии.

Задание на разработку модели

Требуется:

  1. Спроектировать модели выделенных процессов информационной системы «Служба занятости в рамках ВУЗа» средствами среды Ramus на основе IDEF0-методологии.

  2. Средствами среды Ramus построить DFD-диаграмму заданного процесса.

Описание предметной области:

Разрабатываемая система предназначена для того, чтобы помочь студенту устроиться на производственную практику в организацию уже в процессе его обучения в ВУЗе. Подав заявление в систему, студент становится её клиентом и начинает обслуживаться на протяжении всего обучения в ВУЗе. Система предлагает профессиональные (основанные на изучаемых предметах) и психологические тестирования.

Информация об успеваемости заносится в систему. По итогам успеваемости и результатам тестирования руководителем практики от предприятия (экспертом) проставляются экспертные оценки. Кроме того, система позволяет студенту формировать и хранить резюме.

  1. КРАТКОЕ ОПИСАНИЕ МЕТОДОЛОГИИ

IDEF0 - методология функционального моделирования (англ. function modeling) и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временная последовательность (поток работ).

Каждая IDEF0-диаграмма содержит блоки и дуги. Блоки изображают функции моделируемой системы. Дуги связывают блоки вместе и отображают взаимодействия и взаимосвязи между ними.

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

Рисунок 1

IDEF0 требует, чтобы в диаграмме было не менее трех и не более шести блоков. Эти ограничения поддерживают сложность диаграмм и модели на уровне, доступном для чтения, понимания и использования (рисунок 1.1).

Каждая сторона блока имеет особое, вполне определенное назначение. Левая сторона блока предназначена для входов, верхняя - для управления, правая - для выходов, нижняя - для механизмов. Такое обозначение отражает определенные системные принципы: входы преобразуются в выходы управление ограничивает или предписывает условия выполнения преобразований, механизмы показывают, что и как выполняет функция.

Блоки в IDEF0 размещаются по степени важности, как ее понимает автор диаграммы. Этот относительный порядок называется доминированием. Доминирование понимается как влияние, которое один блок оказывает на другие блоки диаграммы. Например, самым доминирующим блоком диаграммы может быть либо первый из требуемой последовательности функций, либо планирующая или контролирующая функция, влияющая на все другие.


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

Расположение блоков на странице отражает авторское определение доминирования. Таким образом, топология диаграммы показывает, какие функции оказывают большее влияние на остальные. Чтобы подчеркнуть это, аналитик может перенумеровать блоки в соответствии с порядком их доминирования. Порядок доминирования может обозначаться цифрой, размещенной в правом нижнем углу каждого прямоугольника: 1 будет указывать на наибольшее доминирование, 2 - на следующее и т. д.

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

  1. ОПИСАНИЕ МОДЕЛЕЙ

    1. Создание контекстной диаграммы

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

  1. Необходимо определить единственную работу контекстной диаграммы, как «Обслужить клиента системы».

  1. Для того, чтобы обслужить клиента необходимо зарегистрировать его в системе, открыть доступ к БД и обработать его запрос.

В качестве входных данных будут использоваться:

  • имя клиента;

  • пароль клиента;

  • исходная БД;

  • запрос клиента.

  1. Выполнение запроса ведет либо к получению информации из системы, либо к изменению содержимого БД (например, при составлении экспертных оценок).

Выходными данными будут являться:

  • отчеты;

  • измененная БД.

Процесс обработки запросов будет выполнять:

  • пользователь системы;

  • администратор системы.

Результат построения контекстной диаграммы (рисунок 2.1).





Рисунок 2 – Контекстная диаграмма «Обслуживание пользователя системы профессиональной ориентации студентов ВУЗа»

    1. Создание декомпозиционной контекстной диаграммы

  1. Далее, необходимо провести декомпозицию контекстной диаграмм. Для этого необходимо описав последовательность обслуживания клиентов:

  • определение уровня доступа в систему;

  • обращение к подсистеме;

  • изменение БД (при необходимости);

  • обработка запроса клиента.

Результат построения декомпозиционной контекстной диаграммы (рисунок 2.2).


Рисунок 3 – Декомпозированная контекстная диаграмма

    1. Создание дальнейших диаграмм декомпозиций

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

  1. Декомпозиция блока «Определение уровня доступа в систему».

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

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


Далее производится процедура аутентификации пользователя (Проверка имени и пароля). Объединяя информацию о полномочиях и уровне доступа в систему, для пользователя формируется набор разрешенных действий (рисунок 2.3).


Рисунок 4 – Декомпозиция блока «Определения уровня доступа в систему»

  1. Декомпозиция блоков «Обращение к подсистеме» и «Изменение БД» не отвечает цели и точки зрения модели. Пользователя системы не интересуют внутренние алгоритмы её работы. Поэтому декомпозиция данных блоков не проводится.

  2. Декомпозиция блока «Обработка запроса клиента».

Перед осуществлением поиска ответа на запрос клиента, необходимо сообщить системе об установлении соединения с БД, после чего выполнить запрос и сгенерировать отчеты для пользователя. (рисунок 2.4).


Рисунок 5 – Декомпозиция блока «Обработка запроса клиента»

    1. Детализация подпроцесса «Выполнение запроса» в виде диаграммы DFD

  1. Декомпозицию подпроцесса «Выполнение запроса» целесообразно провести при помощи диаграммы DFD. Т.к. методология IDEF0 рассматривает систему, как совокупность взаимосвязанных работ, что плохо отражает процессы обработки информации (рисунок 2.5).


Рисунок 6 – Декомпозиция блока «Выполнение запроса»

    1. Детализация подпроцесса «Обработать запрос эксперта» в виде диаграммы DFD

При формировании декомпозиции необходимо внести следующие имена работ:

  • определить студента для составления экспертной оценки;

  • получить данные по тестам;

  • получить данные по успеваемости студента;

  • дать студенту экспертную оценку.

А также соответствующие хранилища данных:

  • хранилище «Резюме»;

  • хранилище «Тесты»;

  • хранилище «Успеваемость»;

  • хранилище «Экспертные оценки».



Рисунок 7 – DFD модель декомпозированного блока «Обработать запроса эксперта»

  1. ЛОГИЧЕСКАЯ МОДЕЛЬ БАЗЫ ДАННЫХ ИНФОРМАЦИОННОЙ СИСТЕМЫ «СЛУЖБА ЗАНЯТОСТИ В РАМКАХ ВУЗА»

Логическая схема данных MS Access представлена на рисунке 8.

Рисунок 8 – Логическая модель базы данных MS Access




Логическая схема данных MS Visio представлена на рисунке 9.

Рисунок 9Логическая модель MS Visio