Образец КП

11

3 Функциональное проектирование информационной системы

3.1 Описание средства проектирования системы BPWin

Для разработки функциональной модели использовалось CASE-средство верхнего уровня - BPwin. BPwin – это модель, поддерживающая следующие методологии: IDEF0 (функциональная модель), IDEF3 (WorkFlow Diagram), DFD (DataFlow Diagram), каждая из которых решает свои специфические задачи. В BPwin возможно построение смешанных моделей, т. е. модель может содержать одновременно как диаграммы IDEF0, так и IDEF3 и DFD.

Врезультате анализа предметной области была разработана функциональная модель системы обслуживания отделения связи. Проектирование проводилось на основе методологий DFD и IDEF0.

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

Основу методологии DFD (Data Flow Diagramming) составляет графический язык описания бизнес-процессов. Диаграмма DFD используется для описания документооборота и обработки информации. Данная диаграмма представляет моделируемую систему как совокупность связанных между собой работ для более наглядного отображения текущих операций документооборота. DFD включает в себя:

−логические функции (активности);

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

−внешние ссылки (внешние источники и адресаты данных, которых находятся за границами моделируемой системы);

– хранилища данных – место, где объекты ожидают обработки.

12

Для описания логики взаимодействия информационных потоков более подходит IDEF3, называемая также Workflow Diagramming, — нотация моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектами, являющимися частью этих процессов.

BPwin предоставляет два инструмента для оценки модели — стоимостный анализ, основанный на работах (Activity Based Costing, ABC), и свойства, определяемые пользователем (User Defined Properties, UDP). Функциональное оценивание – ABC – это технология выявления и исследования стоимости выполнения той или иной функции (действия). Исходными данными для функционального оценивания являются затраты на ресурсы (материалы, персонал и т.д.).

АВС позволяет оценить стоимостные и временные характеристики системы. Если стоимостных показателей недостаточно, имеется возможность внесения собственных метрик — свойств, определенных пользователем — (User Defined Properties, UDP). UDP позволяют провести дополнительный анализ, хотя и без суммирующих подсчетов.

BPwin является уникальным инструментом, позволяющим создавать модель, содержащую диаграммы всех трех нотаций одновременно. Он позволяет эффективно манипулировать моделями — сливать и расщеплять их, а также документировать модели посредством генерации отчетов.

3.2 Описание функциональной модели системы

Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии. Сначала проводится описание системы в целом

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

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

13

На основе анализа предметной области разработана диаграмма верхнего уровня АИС «Корпуса и аудитории» на основе методологии IDEF0. Контекстная диаграмма для системы представлена на рисунке А.1 в приложении А.

Входными данными для системы являются: а) технический документ корпуса; б) данные о помещении; в) данные об опасности; г) данные о ремонте;

д) данные по электроустановкам. Выходными данными для системы являются: а) отчет по корпусам; б) отчет по помещениям.

Учет хозяйственных процессов в корпусах и аудиториях ведется в соответствии с правилами ведения учета (стрелка управления) комендантом (механизм).

Функциональная декомпозиция работы «АИС «Корпуса и аудитории» проводится на основе методологии DFD (рисунок А.2 приложения А). В результате декомпозиции выделено 6 бизнес-процессов (работ):

а) редактирование данных о корпусе; б) редактирование данных о помещении;

в) редактирование данных об опасности; г) регистрация проведенного ремонта;

д) занесение сведений о проведенных работах; е) редактирование данных по электроустановкам.

Входными данными для работы «Редактирование данных о корпусе» является технический документ корпуса. Выходными данными для работы «Редактирование данных о корпусе» является информация о корпусе, поступающая в хранилище «Корпуса».

− Входными данными для работы «Редактирование данных о помещении» являются данные о помещении. Выходными данными для работы

14

«Редактирование данных о помещении» является информация о помещении, поступающая в хранилище «Помещения».

Входными данными для работы «Редактирование данных об опасности» являются данные об опасности. Выходными данными для работы «Редактирование данных об опасности» являются:

−информация об опасности, поступающая в хранилище «Помещения»;

−информация об опасности, поступающая в хранилище «Корпуса».

−Входными данными для работы «Регистрация проведенного ремонта» являются данные о ремонте и проведенных работах. Выходными данными для работы «Регистрация проведенного ремонта» является информация о проведенном ремонте, которая заносится в хранилище «Ремонт».

−Входными данными для работы «Занесение сведений о проведенных работах» являются данные о ремонте и проведенных работах. Выходными данными для работы «Занесение сведений о проведенных работах» являются данные о информация о проведенных работах, которая заносится в хранилище «Ремонт».

−Входными данными для работы «Редактирование данных по электроустановкам» являются данные по электроустановкам. Выходными данными для работы «Редактирование данных по электроустановкам» являются:

−информация об электроустановках, которая поступает в хранилище «Электроустановки»;

−информация об электроустановках, которая поступает в хранилище «Корпуса».

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

15

4 Инфологическое проектирование информационной системы «Корпуса и аудитории»

4.1 Описание средства проектирования ERWin

Семейство продуктов ERwin относится к персональным CASE-продуктам, предназначенным для моделирования баз данных самого различного типа. Отличительной чертой продуктов ERwin является высокая степень обеспечения согласованного взаимодействия между средствами создания баз данных и средствами разработки приложений в технологии клиент-сервер.

CASE-средство ERwin предназначено для разработчиков, проектировщиков БД, системных аналитиков для построения модели данных в процессе разработки технического проекта информационной системы. С помощью ERwin разработчик может, используя визуальные средства, описать логическую модель данных. На основе логической модели создается физическая модель для конкретной СУБД с использованием хранимых процедур и триггеров. Результатом работы по созданию физической модели может стать генерация структуры базы данных.

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

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

16

индексы, правила поддержания целостности ссылок (первичных и внешних ключей), устанавливает значения по умолчанию и ограничения для доменов/столбцов. В состав ERwin включен целый ряд оптимизированных шаблонов триггеров, обеспечивающих целостность ссылок, и мощный макроязык, который позволяет создавать собственные триггеры и хранимые процедуры. Таким образом могут быть автоматически сформированы тысячи строк кода [1].

Методологическую основу ERwin составляет технология IDEF1X (моделирование данных для реляционных СУБД ). Результатом построения является ER-диаграмма («сущность-связь»). Графический подход к созданию моделей значительно упрощает процесс разработки.

4.2Логическое проектирование системы

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

На основе анализа предметной области выделены следующие сущности:

- сущность «Корпус» определяется следующими атрибутами: ID корпуса, адрес, год постройки, общая площадь, учебная площадь, учебно-вспомогательная площадь, общий объем корпуса, конструктивные особенности, потребление электроэнергии в летнее время, потребление электроэнергии в зимнее время, пиковое потребление электроэнергии, наличие мощных электрических установок, потребления тепла;

- сущность «Помещение» определяется следующими атрибутами: ID помещения, ID корпуса, ID вида помещения, этаж, площадь, объём, конструктивные особенности;

- сущность «Вид помещения» определяется следующими атрибутами: ID вида помещения, вид помещения;

- сущность «Опасность» определяется следующими атрибутами: ID корпуса, ID вида опасности, ID категории опасности;

17

-сущность «Вид опасности» определяется следующими атрибутами: ID вида опасности, вид опасности;

-сущность «Категория опасности» определяется следующими атрибутами: ID категории опасности, степень опасности;

-сущность «Проведённый ремонт» определяется следующими атрибутами: код ремонта, ID вида ремонта, ID корпуса, ID помещения, дата начала, дата окончания;

-сущность «Вид ремонта» определяется следующими атрибутами: ID вида ремонта, вид ремонта;

-сущность «Работы по ремонту» определяется следующими атрибутами: ID работы, наименование работы, цена работы;

-сущность «Состав ремонта» определяется следующими атрибутами: ID вида ремонта, ID работы;

-сущность «Наличие мощных электроустановок» определяется следующими атрибутами: ID электроустановки, название электроустановки;

-сущность «Электроустановки» определяется следующими атрибутами: ID электроустановки, ID корпуса.

Однозначно идентифицируем каждый экземпляр сущности - выделим первичные ключи.

Сущность «Корпус» - первичный ключ «ID корпуса».

Сущность «Помещение» - составной первичный ключ «ID помещения, ID корпуса».

Сущность «Вид помещения» - первичный ключ «ID вида помещения». Сущность «Опасность» - составной первичный ключ «ID корпуса, ID вида

опасности, ID категории опасности».

Сущность «Вид опасности» - первичный ключ «ID вида опасности». Сущность «Категория опасности» - первичный ключ «ID категории

опасности».

Сущность «Проведённый ремонт» - первичный ключ «Код ремонта». Сущность «Вид ремонта» - первичный ключ «ID вида ремонта». Сущность «Работы по ремонту» - первичный ключ «ID работы».

18

Сущность «Состав ремонта» - составной первичный ключ «ID вида ремонта, ID работы».

Сущность «Наличие мощных электроустановок»- первичный ключ «ID электроустановки».

Сущность «Электроустановки» - составной первичный ключ «ID электроустановки, ID корпуса».

4.3 Разработка структуры связей

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

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

Сущности «Корпус» и «Опасность» связаны через внешний ключ по полю «ID корпуса». Так как для одного корпуса характерны различные опасности, то эта связь будет «один-ко-многим». Связь идентифицирующая, поэтому первичный ключ сущности «Корпус» – «ID корпуса» – является внешним ключом и частью составного первичного ключа для сущности «Опасность».

Сущности «Вид опасности» и «Опасность» связаны через внешний ключ по полю «ID вида опасности». Так как одному виду опасности соответствуют различные опасности, то эта связь будет «один-ко-многим». Связь идентифицирующая, поэтому первичный ключ сущности «Вид опасности» – «ID

19

вида опасности» – является внешним ключом и частью составного первичного ключа для сущности «Опасность».

Сущности «Категория опасности» и «Опасность» связаны через внешний ключ по полю «ID категории опасности». Так как одна степень опасности может соответствовать разным категориям, а конкретная категория относится к конкретной степени опасности, то эта связь будет «один-ко-многим». Связь идентифицирующая, поэтому первичный ключ сущности «Категория опасности» – «ID категории опасности» – является внешним ключом и частью составного первичного ключа для сущности «Опасность».

Сущности «Корпус» и «Проведённые работы» связаны через внешний ключ по полю «ID корпуса». Так как в одном корпусе может быть проведено несколько работ, а конкретная работа соответствует одному корпусу, то эта связь будет «один-ко-многим». Связь неидентифицирующая, поэтому первичный ключ сущности «Корпус» – «ID корпуса» – мигрирует в качестве внешнего ключа в неключевые атрибуты сущности «Проведённые работы».

Сущности «Помещение» и «Проведённые работы» связаны через внешний ключ по полю «ID помещения». Так как в одном помещении могут быть проведены разные работы, а конкретная работа соответствует одному помещению, то эта связь будет «один-ко-многим». Связь неидентифицирующая, поэтому первичный ключ сущности «Помещение» – «ID помещения» – мигрирует в качестве внешнего ключа в неключевые атрибуты сущности «Проведённые работы».

Сущности «Вид ремонта» и «Проведённые работы» связаны через внешний ключ по полю «ID вида ремонта». Так как один вид ремонта может совершаться несколько раз, но в разное время, а конкретные проведенные работы соответствуют одному виду ремонта, то эта связь будет «один-ко-многим». Связь неидентифицирующая, поэтому первичный ключ сущности «Вид ремонта» – «ID вида ремонта» – мигрирует в качестве внешнего ключа в неключевые атрибуты сущности «Проведённые работы».

Сущности «Проведенные работы» и «Состав ремонта» связаны через внешний ключ по полю «Код ремонта». Так как конкретной проведённой работе

20

соответствует разный состав ремонта, а конкретный состав ремонта соответствуют одной проведённой работе, то эта связь будет «один-ко-многим». Связь идентифицирующая, поэтому первичный ключ сущности «Проведенные работы» – «Код ремонта» – является внешним ключом и частью составного первичного ключа для сущности «Состав ремонта».

Сущности «Работы по ремонту» и «Состав ремонта» связаны через внешний ключ по полю «ID работы». Так как конкретной работе по ремонту соответствует разный состав ремонта, а конкретный состав ремонта соответствуют одной проведённой работе по ремонту, то эта связь будет «один-ко-многим». Связь идентифицирующая, поэтому первичный ключ сущности «Работы по ремонту» – «ID работы» – является внешним ключом и частью составного первичного ключа для сущности «Состав ремонта».

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

Сущности «Электроустановка» и «Наличие электроустановок» связаны через внешний ключ по полю «ID электроустановки». Так как конкретноя электроустановка может относиться к конкретному наличию электроустановок, а конкретное наличие электроустановок соответствует одной электроустановке, то эта связь будет «один-ко-многим». Связь идентифицирующая, поэтому первичный ключ сущности «Электроустановка» – «ID электроустановки» – является внешним ключом и частью составного первичного ключа для сущности «Наличие электроустановок».

Логическая структура базы данных (ER – диаграмма) представлена на рисунке Б.1 в приложении Б.