24

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

Методические указания к лабораторным работам

Составители:

В.А.Белкин;

С.В.Костарев, к.т.н., доцент

Омск – 2000

Содержание

ЛАБОРАТОРНАЯ РАБОТА №1

Методология структурного системного анализа IDEF0

Пример построения IDEF0

ЛАБОРАТОРНАЯ РАБОТА №2

Методология структурного системного анализа DFD

Пример построения DFD

ПРИЛОЖЕНИЕ 1. ПРИМЕР МОДЕЛИ IDEF0

ПРИЛОЖЕНИЕ 2. ПРИМЕР МОДЕЛИ DFD

ПРИЛОЖЕНИЕ 3. ЗАДАНИЯ ДЛЯ ПОСТРОЕНИЯ МОДЕЛЕЙ

Задание 1. Музей

Задание 2. «Птичий» рынок

Задание 3. Быстрая пицца

Задание 4. Документооборот

Задание 5. Закусочная

Задание 6. Компакт по сбыту лекарственных препаратов

Задание 7. Авиакомпания

Список литературы

Данные методические указания предназначены для изучения прин­ципов построения информационных систем. Лабораторные работы осно­ваны на использовании специальной программы моделирования, которая реализует стандартные методы построения функциональных моделей и диаграмм потоков данных информационных систем.

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

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

Лабораторная работа №1

Методология структурного системного анализа IDEF0

Цель работы

Произвести анализ деятельности предприятия и построить функциональную модель в стандарте IDEF0.

Краткие сведения

Методология IDEF0 (Icam DEFinition), разработана на основе методологии SADT (Structured Analysis and Design Technique). Методология IDEF0 представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель IDEF0 отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Основные элементы этой методологии основываются на следующих концепциях.

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

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

Правила 1DEF0 включают:

• ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);

• связность диаграмм (номера блоков);

• уникальность меток и наименований (отсутствие повторяющихся имен);

• синтаксические правила для графики (блоков и дуг);

• разделение входов и управлений (правило определения роли данных).

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

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

Результатом применения методологии IDEF0 является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга.

Диаграммы - главные компоненты модели, все функции ИС и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода - с правой

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

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

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

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

Лабораторное задание

1. Получить номер задания у преподавателя.

2. Ознакомиться с работой предприятия в соответствии с номером лабораторного задания (прил. 3).

3. Изучить предметную область, используя вербальное описание.

4. На основании описания деятельности предприятия, построить функциональную модель AS-IS (как есть), т.е. так, как предприятие работает в данный момент времени или работало раньше.

Содержание отчета

Модель информационной системы, содержащая

• одну контекстную диаграмму,

• пять диаграмм декомпозиции,

• двадцать пять работ (Activity).

Пример построения IDEFO

Описание деятельности организации

Частный предприниматель закупает видеокассеты мелким оптом у компаний-производителей, привозит их в свой город и продает. В городе у него имеются два киоска по продаже и прокату видеокассет.

Для продажи и проката выбираются наиболее кассовые фильмы, которые продаются с небольшой надбавкой по отношению к оптовой цене, чтобы приносить предпринимателю прибыль.

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

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

Построение модели компании (AS-IS)

Модель AS-IS (как есть) предназначена для описания существующей организации работы, и на ее основе достигается консенсус между различными единицами бизнеса по тому, «кто что сделал» и что каждая единица бизнеса добавляет в процесс.

Построим модель деятельности компании AS-IS в нотации IDEF0. Контекстная диаграмма верхнего уровня представлена на рис. 1.

Рис. 1. Контекстная диаграмма

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

Лабораторная работа №2

Методология структурного системного анализа DFD

Цель работы

На основании проведенного анализа деятельности предприятия, построить модель деятельности реорганизованного предприятия в стандарте DFD (диаграмма потоков данных).

Краткие сведения

В основе данной методологии лежит построение модели анализируемой информационной системы (ИС) - проектируемой или реально существующей. Модель системы определяется как иерархия диаграмм потоков данных (DFD), описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы ИС с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция создает многоуровневую иерархию диаграмм, и продолжается до тех пор, пока процессы не станут элементарными (невозможна дальнейшая детализация).

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

• внешние сущности;

• системы. (подсистемы);

• процессы;

• накопители данных;

• потоки данных;

• текст;

• расширения для расщепления/объединения потоков;

• расширения реального времени.

Рекомендации для построения модели

1. Размещать на каждой диаграмме от 3 до 7 процессов. Верхняя граница соответствует человеческим возможностям одновременного восприятия и понимания структуры сложной системы с множеством внутренних связей, нижняя граница выбрана по соображениям здравого смысла, т.к. нет необходимости детализировать процесс диаграммой (Содержа­щей всего один или два процесса.

2. Не загромождать диаграммы несущественными на данном уровне деталями.

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

4. Выбирать ясные, отражающие суть дела, имена процессов и потоков для улучшения читаемости диаграмм, при этом стараться не использовать аббревиатуры.

5. Однократно определять функционально идентичные процессы на самом верхнем уровне, где такой процесс необходим, и ссылаться на него на нижних уровнях.

6. Пользоваться простейшими диаграммными техниками, если что-либо можно описать с помощью DFD, то не надо использовать для описания более сложные объекты.

7. Отделять управляющие структуры от обрабатывающих процессов, локализовать управляющие структуры.

Этапы построения модели

1. Расчленение множества требований и организация их в основные функциональные группы.

2. Идентификация внешних объектов, с которыми система должна быть связана.

3. Идентификация основных видов информации, циркулирующей между системой и внешними объектами.

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

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

6. Построение контекстной диаграммы путем объединения всех процессов предварительной диаграммы в один процесс, а также группирования потоков.

7. Формирование DFD первого уровня на базе процессов предварительной контекстной диаграммы.

8. Проверка основных требований по DFD первого уровня.

9. Декомпозиция каждого процесса текущей DFD с помощью детализирующей диаграммы или спецификации процесса.

10. Проверка основных требований по DFD соответствующего уровня.

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

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

13. После построения двух-трех уровней проведение ревизии с целью проверки корректности и улучшения читаемости модели.

14. Построение спецификации процесса, а не простейшей диаграммы, если некоторую функцию сложно или невозможно выразить комбинацией процессов.

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

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

Лабораторное задание

1. Получить номер задания у преподавателя.

2. Ознакомиться с работой предприятия в соответствии с номером лабораторного задания (прил. 3).

3. Изучить предметную область, используя вербальное описание.

4. На основании описания деятельности предприятия построить диаграмму потоков данных - модель ТО-ВЕ (как будет), т.е. так, как предприятие будет работать после реорганизации.

Содержание отчета

Модель информационной системы, содержащая:

• одну контекстную диаграмму,

• пять диаграмм декомпозиции,

• двадцать пять работ (Activity),

• хранилища данных (2 - 4 шт.) и внешние сущности (3-4 шт.).

Пример построения DFD

Описание деятельности организации

На книжном рынке появилась новая посредническая компания «Закажи книгу» (ЗК). Она преобразовалась из старой компании «Книга - почтой». «Книга - почтой» получала заказы от библиотек, заказывала книги у издателя, выкупала их со скидкой и поставляла по почте заказчику.

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

Новое руководство планирует существенно увеличить объемы реализации за счет полной автоматизации всех производственных операций и привлечения новых клиентов путем создания электронного магазина в сети Internet. Планируется привлечь программистов для разработки собственного Web-сайта. Клиент, подключившись к сайту, может просмотреть список имеющихся книг и сформировать свой заказ, заполнив карточку. Также предполагается организовать прием заказов по телефону.

Компания намерена работать как со старыми партнерами, так и с новыми клиентами. Для ускорения работы планируется хранить на складе несколько тысяч часто заказываемых книг. Предполагается значительное увеличение нагрузки на сотрудников, которые принимают заказы по телефону. Этим сотрудникам потребуется быстрый доступ к каталогу книг для проверки фамилий авторов и названий книг, а также для предоставления клиентам сведений о наличии книг по различным тематикам. Предполагается увеличения количества заказов до 1000 в день.

Руководитель намерен по-новому организовать работу своей компании. Вместе с аналитиком решено создать модель, отображающую планируемые работы.

Построение модели реорганизованной компании (ТО-ВЕ)

Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (как будет), представляющей собой модель новой организации бизнес-процессов. Модель ТО-ВЕ нужна для анализа альтернативных путей выполнения работы и документирования того, как компания будет организовывать бизнес в будущем. Подобно существующему порядку, новая система будет:

• принимать заказы на книги;

• проверять их по списку книг, имеющихся в наличии;

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

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

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

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

Контекстная диаграмма А-0 верхнего уровня представлена на рис. 2. Она дает общее представление о работе, компании.

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

Всю работу условно можно разбить на две крупные части и затем рассмотреть каждую в отдельности. Первая часть - это работа с клиентами, вторая - это работа с издателями.

Рассмотрим первую часть - работу с клиентами.

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

Рассмотрим вторую часть - работу с издателями.

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

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

Рис. 3 Фрагмент схемы при работе с клиентами

Фрагмент схемы при работе с издательствами представлен на рис. 4.

Рис. 4. Фрагмент схемы при работе с издательствами

Рассмотрев две части работ отдельно, отметим, что эти части связаны между собой. Определим, каким образом они взаимодействуют.

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

При отсутствии книг на складе компания выставляет заказ издателю. Для этого в компании должен существовать перечень издательств с адресами. Каждый заказ издателю необходимо сохранить для дальнейшего использования в деятельности компании.

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

Полная диаграмма декомпозиции процесса АО обработка заказа на книги представлена в прил. 2.

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

Ошибочные условия

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

Приложение 3. Задания для построения моделей информационных систем