Лекции - Автоматизированные системы управления предприятием

Подождите немного. Документ загружается.

- Требования к математическому обеспечению (требования к алгоритмам

работы системы);

- Требования к информационному обеспечению (к внешнему и

внутреннему информационному обеспечению). Внутреннее

информационное обеспечение – представление информации в БД,

внешнее - документы. Должны быть описаны состав информационного

обеспечения и инфологическая модель предметной области (например, в

ERwin). Не требуется указание реквизитов сущности, только название и

связи;

- Требование к организационному обеспечению (к тому, как будет

построена организация);

- Требования к программному обеспечению (требование к составу

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

функционально-ориентированный подход). При объектно-

ориентированном подходе должна быть представлена диаграмма

компонент;

- Требования к техническому обеспечению – предусматривается указание

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

проекта. В случае объектно-ориентированного подхода может

указываться диаграмма размещения (размещение компонент по

аппаратным средствам);

- Лингвистическое обеспечение (указание языков программирования и

выбор интерфейсов пользователей – экранные формы взаимодействия с

клиентом);

- Требования к восстановлению систем во время сбоев и отказов;

- Требования к объёмам хранимых данных;

- Требования к операционной системе (выбор операционной системы);

- Требования к интерфейсам с внешними системами (и с существующими,

если они сохраняются);

- Требования к автоматическим действиям контроля и действиям

персонала.

К разным процессам применимы разные требования, или они могут

быть общими для системы.

Состав и содержание работ по созданию (развитию) системы

регламентируется ГОСТ’ом 24.601, который определяет номенклатуру (перечень)

стадий внедрения проекта, календарный план выполнения работ.

Этап Содержание

этапа

Ответственный Сроки

1. Разработка ТЗ Продолжительность

работы (в неделях,

месяцах)

2. Проектирование

3. Кодирование

4. Внедрение

- 51 -

В пункте «Состав и содержание работ по созданию (развитию) системы»

определяется состав приёмочной комиссии по каждому этапу, уровень приёмочной

комиссии.

В требованиях к составу и содержанию работ по подготовке объекта

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

необходимость следующих мер:

- Установка (приобретение) компьютеров,

- Установка программного обеспечения, его развёртывание;

- Строительные работы;

- Обучение сотрудников, и т.д.

В требованиях к организации сопровождения оговаривается, как будет

сопровождать систему организация – разработчик (создание «горячей линии»,

Интернет-канал, скорость реакции на ошибки). Существует технология ITIL – как

можно и должно обеспечивать сопровождение информационной системы.

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

документов, которые будут переданы заказчику после разработки системы (диски и

т.д.)

4 этап: Проектирование ИС

Существует 2 подхода к проектированию ИС:

I. Функционально-ориентированный подход

Подсистемы выделяются по функциям, которые в них реализуются

(подсистемы сбыта, продаж, производства).

II. Объектно-ориентированный подход

Подсистемы выделяются по классам, которые относятся к фрагментам ПО.

Функционально-ориентированный подход

Порядок проектирования

1. Создание словаря данных системы, т.е. создание репозитория системы

по материалам обследования;

2. Определение коллектива разработчиков, их ролей и прав доступа к

репозиторию и составляющим проекта;

3. Определение иерархии функций (построение диаграмм потоков

данных);

4. Построение диаграмм потоков данных;

5. Построение диаграмм перехода системы из одного состояния в другое

(блок-схемы, IDEF3, и т.д.);

- 52 -

6. Построение диаграмм сущность-связь:

7. Построение системной структурной диаграммы (диаграммы вызовов

программных блоков):

8. Выбор СУБД (может не быть, если СУБД определяется на уровне ТЗ);

9. Генерация БД на основе инфологических диаграмм (ER-диаграмм);

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

программных модулей, тестирование программных модулей, интеграция

в систему, системные испытания.

11. Передача в опытную, а затем и в промышленную эксплуатацию;

12. Сопровождение системы.

Теперь более подробно о каждом этапе

1 этап: Создание репозитория

Словарь данных – это термины с определениями (может быть простым или

сложным – репозиторий)

Репозиторий – словарь данных, выполненный в определенной структуре.

Репозиторий

Верификатор

Графический

редактор

диаграмм

Документатор

Подсистема

администрир

ования

Репозиторий – хранилище знаний о проекте

Графический редактор диаграмм – BP-win, ER-win (и другие CASE-средства

программирования)

Документатор – средства, при помощи которых описываются документы

Верификатор – контролирует синтаксис и семантику ввода информации.

Подсистема администрирования – определение прав.

2 этап: Определение команды разработчиков

Используется ролевой подход

Исходя из этого, в разработке должны принимать участие:

- Руководитель проекта (менеджер)

- 53 -

- Системный аналитик (разработка ТЗ, обследование ОА, и, возможно,

контроль исполнения)

- Программист

- Тестер (проводит испытания и ищет ошибки)

- Администратор (администратор БД)

- Внедренцы (обучают заказчика)

- «Писатели» (пишут техническую документацию)

Эти роли могут играть одни и те же люди. В крайнем случае, это может быть

один человек.

3 этап: Иерархия функций

Пользователь,

использующий

АРМ

F1 F2

Исполнитель без ИС

Будем рассматривать только ту функцию, которая применяет АРМ.

Иерархия функций (декомпозиция)

F1.1 F1.3F1.2

4 этап: Диаграмма потоков данных

Она может быть построена при помощи BPwin (в стандарте IDEF0)/

Туда включаются только те функции, которые автоматизируются и поток

данных между ними.

То есть, практически определяются только входы и выходы функций.

5 этап: Диаграмма перехода

Строится в IDEF 3

6 этап : Построение ER-диаграммы

1 1

- 54 -

7 этап: Построение системной структурной диаграммы

Определяется соответствие функции программным модулям и система

вызовов одного программного компонента из других.

M1.1 M1.3M1.2

8 этап: Выбор СУБД

СУБД определяется либо в ТЗ, либо на основе вышеперечисленных этапов.

9 этап: Генерация БД

Производится при помощи CASE-средств (в ERwin, BPwin, Paradigm).

Объектно-ориентированный подход

Вспомним понятие класса.

Класс – множество однотипных объектов, у которых есть:

- свойства

- методы

Для описания свойств системы используется специальный язык UML (Unified

Modeling Language) под управлением Rational Rose.

Язык UML

Этот язык хорошо описывает проект и архитектуру создаваемой системы.

Архитектура создаваемой системы описывается следующими документами

(или артефактами, как они называются в Rational Rose):

1. Представление условий использования (взаимодействие системы с

пользователем);

2. Логическое представление (структура системы, например диаграмма

классов);

3. Компонентное представление системы (размещение логических

элементов системы по программным исполняемым модулям и

физическим БД);

4. Представление о размещении (привязка компонент к конкретным

- 55 -

аппаратным средствам);

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

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

Рассмотрим подробно все типы графических средств UML.

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

Иначе это называется прецедентами использования системы пользователем.

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

системой.

Вспомогательный прецедент – нетиповые алгоритмы взаимодействия

пользователя с системой.

ГОСТов на описание прецедентов нет.

Этот артефакт составляется системным аналитиком.

Рассмотрим пример артефакта описания прецедента использования системы.

Прецедент – «Покупка товара»

№

Шага

Действующий субъект Система Ограничения

1. Прецедент начинается,

когда продавец нажимает

кнопку «Новая продажа»

Для продавца открывается

окно «Новая продажа» и

включается сканер

Общее время отклика < 1

сек

2. Продавец сканирует товары

и вводит количество

Отображает наименование

и цену товара

Общее время отклика на

сканирование 1 товара <

1 сек

3. Продавец щелкает кнопку

«Итого»

Вычисляет и отображает

стоимость

4. Продавец считывает

дисконтную карту

Если карта

действительна*, то

распечатывается чек со

скидками, обновляется

состав товара в магазине и

сумма дохода.

Это конец условия

использования

* Если дисконтная карта не действительна, то действует другой,

вспомогательный прецедент.

Диаграмма прецедента использования на языке UML.

- 56 -

Условные обозначения:

№ Условное обозначение Расшифровка

Актер (либо пользователь,

либо внешняя система)

Прецедент использования

Пример:

Начать продажу

Добавить товар

в продажу

Выполнить

платеж

Продавец

Диаграммы прецедентов определяют основные требования к системе,

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

Прочие функциональные требования – дополнительные требования по

быстродействию, объему памяти и другие специфические количественные

требования.

Для описания дополнительных требований специальных формализмов нет, в

ряде случаев при описании требований используют ограничения.

Диаграммы логического представления.

Диаграммы класса

Условные обозначения:

1. класс

2. Отношение

ассоциаций

- 57 -

Имя

Свойства

Методы

1 * 1 * 1 1*

Летательный

аппарат

3. Отношение

обобщения

Пример:

Свойства летательного аппарата

наследуются самолетом.

4. Отношение

агрегации

Пример:

5. Отношение

зависимости

Независимый класс (элемент) может

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

зависимого класса (элемента).

6. Отношение

включения

(физического)

Один класс входит в состав другого

более сложного класса.

7. Отношение

реализации

Пример:

Для выполнения

методов

используется

класс –

справочник.

Пример диаграммы класса:

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

Введем классы в ПО:

1. Продукт и его запасы в магазине

2. Заказ его составляющие

3. Клиент:

- Юридическое лицо

- Физическое лицо

- 58 -

подкласс класс

часть целое

Велосипед

Рама Колесо . . .

зависим. независим.

часть целое

приемник источник

Самолет

Интерфейсный класс:

работа со справочником

Заполнить ()

Искать()

Справочник

Эта диаграмма является базовой. В основе получения программного кода лежит

именно диаграмма класса.

В начале создается базовая диаграмма класса, а затем она уточняется.

Классы, относящиеся к одной подобласти предметной области, могут быть

объединены в пакеты.

Между пакетами могут существовать отношения, в основном это отношения

зависимостей.

- 59 -

Запас

имя

кол-во

Уменьш

ение

Увеличе

ние

Анализ

Строка заказа

Имя

Кол-

во

Стоим

ость

Создание строки

заказа

Заказ

Продукт

мя

дрес

Физ. лицо Юрид. лицо

1 1

– пакет

Эти отношения между пакетами описываются в рамках диаграммы пакетов.

Пример диаграммы пакетов:

Диаграмма состояния класса

Диаграмма состояния класса описывает диаграммы объектов одного класса.

Условные обозначения:

1. Вершина

2. Конечная вершина

- 60 -

Имя 1

Имя 2

Интерфейс

подсистемы

Подсистема

БД

Зависимый

Независимый