Структурный и обьектно-ориентированный подход к проектирования АИС

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

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

Цель методики – построение модели, определяющей отдельные объекты, участвующие в бизнес-процессах.

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

1) объект –предмет, имеющее определенное поведение и свойства. Структура и поведение схожих объектов, определяющих общий для них класс.

2)Класс- это множество объектов, связанных общностью структуры и методов.

Любой объект является экземпляром класса. Определение классов и объектов — одна из самых сложных задач объектно-ориентированного проектирования.

3)Полиморфизм – способность класса принадлежать более чем к 1му типу объектов.

4)Наследование – построение новых классов на основе сущности с возможностью добавления или переопределения свойств и методов.

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

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

Объектный анализ реализуется с помощью CASE средств:

1)UML – универсальный язык моделирования, позволяющий с помощью диаграмм проанализировать объекты и функции ПО.

Виды диаграмм:

-вариантов использования;

-последовательности действий;

-классов и объектов.

2)ERWIN – позволяет построить логические и физические модели объектов данных.

-в логической модели – отражаются сущности с их описанием атрибутов и ключей.

-физическая модель – строится на основе логической с направленностью на конкретное СУБД.

Структурный подход проектированияАИС – совокупность методов и правил построения функциональной модели предметной области, в которой отражается структура выполняемых действий и связи между этими действиями.

На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.

Методология SADT - совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT - отображает функциональную структуру объекта, т.е. производимые им действия и связи между действиями. Основные элементы этой методологии основываются на следующих концепциях: графическое представление блочного моделирования.Может использоваться для моделирования широкого круга систем и определения требований и функций, а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции. Правила SADTвключают: -ограничение количества блоков на каждом уровне декомпозиции (правило 3—6 блоков); -связность диаграмм (номера блоков); -уникальность меток и наименований (отсутствие повторяющихся имен); -синтаксические правила для графики (блоков и дуг); -разделение входов и управлений (правило определения роли данных). Результатом применения методологии SADT (модель IDEF0) является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы — главные компоненты модели, все функции ИС и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода — с правой стороны. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу.

6 Разработка технического задания

Техническое задание – документ, определяющий цели, требования и основные исходные данные для разработки АИС.

ТЗ устанавливает основное назначение разрабатываемого объекта, его технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации.

Все изменения, дополнения и уточнения формулировок ТЗ согласуются с заказчиком и им утверждаются.

Исходное задание выдаётся заказчиком и оформляется в виде технических требований.

1)Общие сведения: наименование и условное обозначение АИС, номер договора, плановые сроки начала и конца работ, порядок оформления и предъявление работ заказчику.

2)Назначение и цели создания:перечень объектов автоматизации, перечень показателей, которые должны быть достигнуты при внедрении АИС.

4)Требования к системе: требования к структуре и функционирования системы, требования к персоналу, требования к безопасности.

5)Состав и содержание работ по созданию системы: перечень этапов работ, сроки, исполнители.

6)Порядок контроля и приемки системы: виды, состав, методы испытаний АИС.

7)Требования к документированию – содержит перечень необходимых для разработки документов.