3.3 Построение диаграммы IDEF3

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

На диаграмме (рис. 3.4.) изображен процесс расчета премии.


Рис. 3.4 – Диаграмма IDEF3.

Основные элементы модели представлены в таблицах 3.4 – 3.6.

Таблица 3.4. Основные элементы модели

Название проекта: Проектирование ИС для расчета оплаты труда в торговле
Цель проекта: реализация структурной функциональной модели ИС
Технология моделирования: метод описания бизнес-процессов IDEF3
Инструментарий: программный продукт BPwin 4.0
Перечень действий Тип соединения
Название Вид
1. Получить данные о работнике Соединение «И» J1 Разворачивающее

3. Выбрать систему обработки запросов

4. Выбрать шаблон отчета

5. Запросить данные из текущей БД

Соединение «ИЛИ» J2 Сворачивающее
6. Вывести отчет

Таблица 3.5. Словарь

Термины Определение
Текущая БД БД, которая имеет актуальное содержимое своих таблиц.
Шаблон отчета Заранее сформированный образец отчета, который можно выбрать из списка.
Сворачивающее соединение «И» Объединяет потоки. Завершение одного или нескольких действий вызывает выполнение другого действия. Каждое исходное действие обязательно должно завершиться.
Разворачивающее соединение «И» Разъединяет потоки. Все следующие процессы должны быть запущены.
Система обработки заявок Часть ИС, в которой администратором выполняется заявка клиента.

Таблица 3.6. Описание действий

Наименование действия Описание решаемых задач
2. Принять заявку на обработку На данном этапе происходит получение данных заказов лекарств.
3. Выбрать подсистему обработки заявок На этом этапе происходит выбор системы обработки заявок.
4. Выбрать шаблон отчета Выбор шаблона отчета по продажам лекарств.
5. Запросить данные из текущей БД Запрос информации из БД лекарств для их отображения.
6. Вывести отчет Вывод отчета по лекарствам администратору ИС с последующей печатью
 

3.3 Построение диаграммы потоков данных DFD

Диаграммы потоков данных DFD моделируют систему как набор действий, соединенных друг с другом стрелками.

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


Рис. 3.5 – Диаграмма DFD.

Основные элементы модели представлены в таблицах 3.7 – 3.9.

Таблица 3.7. Основные элементы модели

Название проекта: Проектирование ИС предприятия оптовой торговли лекарственными препаратами
Цель проекта: реализация структурной функциональной модели ИС
Технология моделирования: метод построения диаграмм потоков данных DFD
Инструментарий: программный продукт BPwin 4.0
Список данных Перечень объектов

Право на обработку

Данные счетов

Запросы на изменение БД

Обработанная заявка

Ответы на запросы

Продукция

Функциональные блоки:

1. Обработать заявки

2. Проконтролировать оплату

3. Доставить лекарства

Лекарства

Счета и платежные документы

Внешние сущности:

1.          Лекарства

2.          Потребность

Название и адрес клиента

Данные счетов

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

Хранилища данных:

1.          Заявки

2.          Счета

3.          Клиенты

Таблица 3.8. Словарь

Термины Определение
Данные Факты, характеризующие деятельность предприятия, подлежащие количественному выражению.

Таблица 3.9. Описание объектов

Наименование объекта Описание функций

Функциональные блоки:

1. Обработать заявки

 

На данном этапе происходит ввод данных по заявкам и их обработка.

2. Проконтролировать оплату

 

На этом этапе ведется администратором ИС контроль оплаты выписанных лекарств.
3. Доставить лекарства Доставка лекарств клиенту для удовлетворения его потребности в них.

Внешние сущности:

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

Хранилища данных:

1. Счет Здесь собирается и хранится информация о счетах оплаты.
2. Заявки Здесь собирается и хранится информация о заявках от клиентов.
3. Клиенты Здесь содержится информация о клиентах
   
4. Объектно-ориентированное проектирование информационной системы

 

4.1 Построение диаграммы вариантов использования

Для описания функционального назначения системы построена диаграмма вариантов использования (use case diagram). Диаграмма вариантов использования является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки.

Разработка диаграммы вариантов использования преследует следующие цели:

– определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы;

– сформулировать общие требования к функциональному поведению проектируемой системы;

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

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

Построение диаграммы вариантов использования является первым этапом процесса объектно-ориентированного анализа и проектирования, цель которого – представить совокупность функциональных требований к поведению проектируемой системы. Разработанная диаграмма вариантов использования представлена на рис. 4.1.

Система имеет двух актеров – администратора ИС и администратора БД. Базовыми вариантами использования являются «Сортировка данных», «Поиск лекарства», «Формирование отчетов», «Ввод данных», «Редактирование данных».

Рис. 4.1 – Диаграмма вариантов использования.

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


Таблица 4.1. Шаблон для написания сценария отдельного варианта использования

Главный раздел Раздел «Типичный ход событий»

Раздел

«Исключения»

Раздел

«Примечания»

Имя варианта использования Типичный ход событий, приводящий к успешному выполнению варианта использования

Исключение №1

Исключение №2

Исключение №3

Примечания
Актеры
Цель
Краткое описание
Тип
Ссылки на другие варианты использования

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

Главный раздел сценария представлен в таблице 4.2.

Таблица 4.2. Главный раздел

Вариант использования Формирование отчетов
Актеры Администратор ИС
Цель Ведение учета продаж лекарств
Краткое описание Администратор должен вводить и редактировать данные заявок от клиентов, формировать содержание отчета на основе запросов.
Тип Базовый

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


Таблица 4.3. Раздел «Типичный ход событий»

Действия актеров Отклик системы

1.          Администратор ИС выбирает сортировку данных по алфавиту или по возрастанию.

Исключение №1: администратор ИС не имеет возможности упорядочить все данные сразу, а только по одному параметру.

2. Система отображает записи в соответствии с параметрами сортировки в БД.

3. Администратор ИС выбирает поиск лекарств.

Исключение №2: администратор ИС не имеет прав доступа ввод / редактирование / удаление информации о лекарствах.

4. Система выдает лекарства по заданному критерию.

5. Пользователь выбирает формирование отчетов.

Исключение №3: отсутствие записей по продажам лекарств за выбранный месяц.

6. Система формирует отчет.

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

Таблица 4.4. Раздел «Исключения»

Действия актеров Отклик системы
Исключение №1: администратор ИС не имеет возможности упорядочить все данные сразу, а только по одному параметру.

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

Система предлагает отменить упорядочивание данных.
Исключение №2: администратор ИС не имеет прав доступа ввод / редактирование / удаление информации о лекарствах.
8. Пользователь отменяет добавление / удаление / изменение данных по продажам лекарств. Система предлагает отменить добавление / удаление / изменение данных по продажам лекарств.
Исключение №3: отсутствие записей по продажам лекарств за выбранный месяц.
9. Пользователь отменяет формирование отчета. Система предлагает не формировать отчет.
4.2 Построение диаграммы деятельности

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

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

Диаграмма деятельности для «Проектирования ИС предприятия оптовой торговли лекарственными препаратами» представлена на рис. 4.2.

Рис. 4.2 – Диаграмма деятельности


В рамках вариантов использования инициируемых действующим лицом «Администратор ИС» система имеет восемь состояний действия: «Ввести пароль», «Ввести данные по лекарствам», «Ввести данные по клиентам», «Ввести данные по поставщикам», «Ввести заказ от клиента», «Выбрать шаблоны отчетов», «Распечатать отчет» и «Выйти из приложения».

Пользователь запускает приложение, вводит пароль. Если пароль верен, пользователь вводит исходные данные по лекарствам, по клиентам и по поставщикам. Затем, используя введенные данные или изменяя их, он вводит заказ от клиента, выбирает шаблоны отчетов по продажам. осле этого, если необходимо, он распечатывает отчет и выходит из приложения. Если пароль неверен, выводится сообщение об ошибке «Неправильный пароль. Закройте окно регистрации».


Информация о работе «Проектирование информационной системы для расчета оплаты труда в торговле»
Раздел: Информатика, программирование
Количество знаков с пробелами: 33464
Количество таблиц: 25
Количество изображений: 9

Похожие работы

Скачать
96855
34
4

... уделяется большое внимание к работам по обеспечению безопасности информации в кредитно-финансовой сфере [15]. Конечно же, информационные технологии (ИТ) сегодня остаются в центре внимания структур государственной власти. Однако, существует мнение, что интерес к использованию современных технологий в системе управления государством до сих пор остается скорее показным. «Глядите, мол, какие мы ...

Скачать
42478
13
8

... Программисты (5) 9.         Оператор (1) Разработка системы будет включать следующие этапы: ·        Анализ предметной области. ·        Разработка технического задания. ·        Разработка базы данных и определение входных и выходных данных ·        Проектирование информационной системы ·        Кодирование и отладка информационного обеспечения. ·        Промежуточное тестирование и ...

Скачать
76871
0
0

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

Скачать
29909
2
6

... создания. Ответственность за разработку ТЗ несет основной разработчик. 3.1 Общие сведения Полное наименование АИС: Информационная система по автоматизации учёта товаров и денежных потоков на предприятии «Computer Master». Условное обозначение: АИС – «Computer Master». Разработка ведется на основании договора №1 от 09.11.09 между заказчиком (Виктором Ивановичем директор «Computer Master») ...

0 комментариев


Наверх