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

Категория: Не указан

Дисциплина: Не указана

Добавлен: 06.01.2026

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

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

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

9

Продолжение таблицы 1

5.2 Разработка документации на АС и ее

части

 

 

 

5.3

Разработка

и

оформление

документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их

разработку 5.4 Разработка заданий на проектирование

 

 

в смежных частях проекта объекта

 

 

автоматизации

6

Рабочая документация

6.1

Разработка рабочей документации на

 

 

систему и ее части

 

 

6.2

Разработка или адаптация программ

7

Ввод в действие

7.1

Подготовка объекта автоматизации к

 

 

вводу АС в действие

 

 

7.2

Подготовка персонала

7.3 Комплектация АС поставляемыми

изделиями

(программными

и

техническими

средствами, программно-

техническими

комплексами,

информационными изделиями)

7.4 Строительно-монтажные работы

7.5 Пусконаладочные работы

7.6Проведение предварительных

испытаний 7.7 Проведение опытной эксплуатации

10

Продолжение таблицы 1

7.8

Проведение приёмочных испытаний

 

8 Сопровождение АС

8.1

Выполнение работ в соответствии с

 

гарантийными обязательствами

 

8.2

Послегарантийное обслуживание

2.6 Порядок контроля и приемки

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



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 категории опасности;