 |
|
Проектирование автоматизированных информационных систем
Функциональные методики, наиболее известной из которых является методика IDEF, рассматривают организацию как набор функций, преобразующий поступающий поток информации в выходной поток.
В основе методологии IDEF0 лежат четыре основных понятия: функциональный блок, интерфейсная дуга, декомпозиция, глоссарий.
Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, "производить услуги"). На диаграмме функциональный блок изображается прямоугольником (рис.). Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом:
- верхняя сторона имеет значение "Управление" (Control);
- левая сторона имеет значение "Вход" (Input);
- правая сторона имеет значение "Выход" (Output);
- нижняя сторона имеет значение "Механизм" (Mechanism).
Рис.1 Функциональный блок
Интерфейсная дуга (Arrow) отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, представленную данным функциональным блоком. Интерфейсные дуги часто называют потоками или стрелками.
Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой.
Декомпозиция (Decomposition) является основным понятием стандарта IDEF0. Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.
В процессе декомпозиции функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы, и называется дочерней (Child Diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме, соответственно называется дочерним блоком – Child Box). В свою очередь, функциональный блок — предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. В каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок или исходящие из него, фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0–модели.
Для создания функциональной модели рекомендуется использовать BPwin.
Рассмотренные возможности BPWin могут быть использованы для построения модели «ЗАО Авиакомпания полет».
В соответствии с базовыми принципами методологии SADT первый уровень рассмотрения является наиболее общим. Компания может быть представлена в виде работы, имеющей следующие выходы и входы:
1. Заявки клиентов – заявки клиентов на предоставление услуг компании;
2. Правила и процедуры – включает в себя нормативно правовые документы, законы, и внутренние правила и процедуры организации;
3. Услуги по организации полетов – услуги предоставляемые компанией;
4. Персонал – персонал, участвующий в работе подразделений организации.
Рис. 2 Диаграмма А0 «ЗАО Авиакомпания полет»
С целью уточнения функций отдельных подразделений компании выполним декомпозицию диаграммы первого уровня. В структуре компании можно выделить три подразделения взаимосвязанные между собой по выходам и входам. Функции подразделений и их выходы и входы:
1. Отдел кадров - отвечает за учет работников предприятия:
- Учетная карточка сотрудника (вход);
- Трудовое законодательство (управление);
- Информация о летном персонале (выход);
- Информация о персонале компании (выход);
- Сотрудники отдела кадров (механизм);
- Система автоматизации (механизм).
2. Бухгалтерия – отдел, выполняющий экономические расчеты организации:
- Информация о персонале компании (вход);
- Проект услуги (вход);
- Информация о летном персонале (вход);
- Бухгалтерская политика (управление) – документ, строгих правил работы отдела;
- Информация о стоимости услуг (выход);
- Бухгалтеры (механизм) – персонал, работающий в отделе;
- Система автоматизации (механизм).
3. Экономический отдел – отвечает за обслуживание клиентов:
- Информация о стоимости услуги (вход);
- Информация о летном персонале (вход);
- Заявки клиентов (вход);
- Правила и процедуры (управление);
- Услуги по организации полетов (выход);
- Проект услуги (выход);
- Экономисты (механизм);
- Система автоматизации (механизм).
Рис.3 Декомпозиция диаграммы А0
Рис.4 Декомпозиция работы «бухгалтерия». Диаграмма А2.1
Одним из наиболее крупных подразделений предприятия является бухгалтерия. Рассмотрим более подробно структуру и функции ее элементов:
1. Начисление заработной платы – производится расчет заработной платы работникам:
- Информация о летном персонале (вход);
- Информация о персонале компании (вход);
- Бухгалтерская политика (управление);
- Информация о заработной плате персонала компании (выход);
- Информация о стоимости услуг (выход);
- Специалист по начислению заработной платы (механизм);
- Система автоматизации (механизм) – 1С.
2. Расчет амортизационных отчислений – производится расчет износа основных средств организации:
- Проект услуги (вход);
- Бухгалтерская политика (управление);
- Амортизационные отчисления (выход);
- Остаточная стоимость (выход);
- Специалист по начислению амортизации (механизм);
- Система автоматизации (механизм).
3. Расчет налогов – производится расчет всех необходимых налогов организации:
- Проект услуги (вход);
- Информация о заработной плате персонала (вход);
- Бухгалтерская политика (управление);
- Информация о стоимости услуг (выход);
- Специалист по расчету подоходного налога (механизм);
- Система автоматизации (механизм) - Система Налог.
Ядро информационной системы – база данных. Для её построения можно использовать метод, основанный на методологии структурного анализа и проектирования. На основании поступающей от экспертов информации о предметной области строится ее функциональная модель и инфологическая модель (ER–модель) предметной области. Затем, на основании ER-диаграммы и в рамках выбранной СУБД, генерируется схема базы данных, а затем создается программная оболочка.
В настоящее время большинство проектов информационных систем (ИС) разрабатывается в соответствии с какой-либо методологией разработки ПО. Как следствие, разработчикам требуется инструмент для моделирования данных на этапах анализа и проектирования. Таким инструментом являются ER-диаграммы (Entity-Relationship, «Сущность-Связь»). Фактически их использование является обязательным при разработке информационных систем.
Модель «сущность-связь» должна охватывать реальные объекты, содержать всю необходимую информацию для получения запросов пользователя и выходных отчетов.
Сущность (Entity) – это объект, о котором в системе будет накапливаться информация, например, СТУДЕНТЫ или ПРЕПОДАВАТЕЛИ.
Атрибуты – данные, описывающие свойства сущности. Пример атрибутов сущности СТУДЕНТЫ: ФИО, домашний адрес, год рождения.
Совокупность сущностей, характеризующихся в информационной системе одним и тем же перечнем свойств, называется классом сущностей (набором объектов). Так, например, совокупность всех сущностей СТУДЕНТЫ составляет класс сущностей СТУДЕНТЫ.
Класс сущностей описывается перечнем свойств сущностей, составляющих этот класс. Экземпляром сущности называется конкретная сущность с определенными свойствами).
В данном разделе требуется привести описание используемых в проекте сущностей с их атрибутами. Спецификация атрибута должна содержать его название, тип данных, длину в знаках, домен (диапазон принимаемых значений) и ключевое поле (Таблица 1).
Таблица 1
Преподаватель
| Название атрибута | Тип данных | Длина в знаках | Диапазон принимаемых значений | Ключевое поле |
| Код преподавателя Фамилия преподавателя Имя преподавателя Отчество преподавателя Разряд Стаж работы | Счётчик Строковый Строковый Строковый Числовой Числовой | 1-999 - - - 9 – 14 0-50 | Да Нет Нет Нет Нет Нет |
ER-диаграммы позволяют строить модели логической структуры данных предметной области, а так же производить моделирование физической структуры систем хранения данных.
Для создания ER-диаграммы реляционной БД необходимо определить:
1. сколько и каких таблиц должна включать БД;
2. сколько столбцов содержит каждая таблица;
3. какие атрибуты используются в качестве ключей;
4. как устанавливаются связимежду разными таблицами:
а использование в разных таблицах одного и того же ключа;
б помещение ключа одной таблицы в качестве атрибута в записи другой таблицы;
в создание специальных связующих таблиц;
5. как обеспечить полноту, непротиворечивость и согласованность информации, хранящейся в БД.
То, как логические модели будут выражаться в терминах физической базы данных, включая выбор СУБД, типов данных по умолчанию и эффективных схем индексирования, принято называть физическим уровнем модели Erwin. Erwin поддерживает построение и организацию работы на этих двух уровнях для одной диаграммы.
Используя одну и ту же модель, можно говорить с конечными пользователями в понятной им терминологии и в то же время генерировать схему базы данных на языке, который может быть обработан СУБД пользователя.
Используя Erwin, создадим атрибуты и разобьем их на сущности. Первая сущность «Поставщики» с атрибутами: «Наименование поставщика», «Телефон», «Дата начала сотрудничества», «Адрес», «Руководитель», «Комментарии». Следующая сущность «Товар» с атрибутами: «Наименование товара», «Количество», «Единица измерения», «Дата поставки», «Требования к хранению», «Срок хранения», «Упаковка», «Примечание». Сущность «Расход товара» с атрибутами: «Расход», «Остаток», «Потребитель». Сущность «Складирование» с атрибутами: «Место складирования» и «Дата приёмки». Сущность «Склады» с атрибутами: «Площадь», «Ответственный», «Расположение» и «Характеристика склада». Сущность «Сотрудники» с атрибутами: «Имя», «Фамилия», «Отчество», «Должность», «Паспортные данные» и «Дата начала работы».
Рис. 6ER–диаграмма (логическая модель базы данных)
Для создания модели информационного ядра рекомендуется использовать EPwin.
Важным этапом в разработке БД является анализ требований. На этом этапе происходит преобразование общих знаний о требованиях к будущей системе в точные определения, насколько это возможно. Здесь определяются:
1. архитектура системы, ее функции, внешние условия, базовые средства и технологии разработки;
2. интерфейсы и распределение функций между человеком и системой;
3. требования к программным и информационным компонентам программного обеспечения, необходимые аппаратные ресурсы, требования к БД, физические характеристики компонентов программного обеспечения, их интерфейсы.
При подготовке логической модели базы данных в ERwin, создавалась и физическая модель базы данных, которая может понятнее показать ключевые поля и связи таблиц.
Рис.7 Физическая модель базы данных