Модели и методы проектирования информационных
 Скачать 1.48 Mb.
|
|
Технология проектирования ИС— это совокупность методов и средств проектирования АИС, а также методов и средств организации проектирования (управление процессом создания и модернизации проекта ИС). Предметом выбираемой технологии проектирования должно служить отражение взаимосвязанных процессов проектирования на всех стадиях жизненного цикла ИС. Основные требования, предъявляемые к выбираемой технологии проектирования, следующие: · созданный с помощью этой технологии проект должен отвечать требованиям заказчика; · технология должна максимально отражать все этапы цикла жизни проекта; · технология должна обеспечивать минимальные трудовые и стоимостные затраты на проектирование и сопровождение проекта; · технология должна способствовать росту производительности труда проектировщиков; · технология должна обеспечивать надежность процесса проектирования и эксплуатации проекта; · технология должна способствовать простому ведению проектной документации. 16 Методы проектирования АИС можно классифицировать по степени использования средств автоматизации, типовых проектах решений, адаптивности к предполагаемым изменениям. По степени автоматизации различают: ручное проектирование, при котором проектирование компонентов АИС осуществляется без использования специальных инструментальных программных средств; программирование производится на алгоритмических языках; компьютерное проектирование, при котором генерация или конфигурация (настройка) проектных решений производится с использованием специальных инструментальных программных средств. По степени использования типовых проектных решений различают: оригинальное (индивидуальное) проектирование, когда проектные решения разрабатываются «с нуля» в соответствии с требованиями к АИС; типовое проектирование, предполагающее конфигурацию АИС из готовых типовых проектных решений (программных модулей). По степени адаптивности проектных решений различаются следующие методы: реконструкция — адаптация проектных решений выполняется путем переработки соответствующих компонентов (перепрограммирования программных модулей); параметризация — проектные решения настраиваются в соответствии с заданными и изменяемыми параметрами; реструктуризация модели — изменяется модель предметной области, что приводит к автоматическому переформированию проектных решений. Сочетание различных признаков классификации методов проектирования обусловливает характер используемой технологии проектирования АИС. Выделяются два основных класса технологии 17 проектирования: каноническая и индустриальная. Индустриальная технология проектирования в свою разбивается на два подкласса: автоматизированное (использование САSЕ-технологий) и типовое (параметрически-ориентированное или модельно-ориентированное) проектирование. CASE-технология представляет собой методологию проектирования ИС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей. Большинство существующих CASE-средств основано на методологиях структурного (в основном) или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств CASE-средства позволяют создавать не только продукт, практически готовый к применению, но и обеспечить “правильный” процесс его разработки. Основная цель технологии – отделить проектирование программного обеспечения от его кодирования, сборки, тестирования и максимально “скрыть” от будущих пользователей все детали разработки и функционирования ПО. При этом значительно повышается эффективность работы проектировщика: сокращается время разработки, уменьшается число программных ошибок, программные модули можно использовать при следующих разработках. В качестве примеров популярных CASE-средств укажем программные средства компании Computer Associates, IBM-Rational Software и Oracle: BPwin – моделирование бизнес-процессов; 18 ERwin – моделирование баз данных и хранилищ данных; ERwin Examiner – проверка структуры СУБД и моделей, созданных в Erwin; ModelMart – среда для командной работы проектировщиков; Paradigm Plus – моделирование приложений и генерация объектного кода; Rational Rose – моделирование бизнес-процессов и компонентов приложений; Rational Suite AnalystStudio – пакет для аналитиков данных; Oracle Designer (входит в Oracle9i Developer Suite) – высокофункциональное средство проектирования программных систем и баз данных, реализующее технологию CASE и собственную методологию Oracle – CDM. Сложное CASE-средство, его имеет смысл использовать при ориентации на линейку продуктов Oracle. 4. Этапы создания ИС Стандарт ISO/IEC 12207 определяет структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания информационной системы (рис.1.4): 19 Рис.1.4. Структура жизненного цикла Стадии создания АИС (ISO/IEC 15288) Стадия Описание Формирование концепции Анализ потребностей, выбор концепции и проектных решений Разработка Проектирование системы Реализация Изготовление системы Эксплуатация Ввод в эксплуатацию и использование системы Поддержка Обеспечение функционирования системы 20 Снятие с эксплуатации Прекращение использования, демонтаж, архивирование системы Стадии создания системы согласно требованиям ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания.»: Стадия Описание Формирование требований к АИС · обследование объекта и обоснование необходимости создания АИС; · формирование требований пользователей к АИС; · оформление отчета о выполненной работе и тактико-технического задания на разработку. Разработка концепции АИС: · изучение объекта автоматизации; · проведение необходимых научно- исследовательских работ; · разработка вариантов концепции АИС, удовлетворяющих требованиям пользователей; · оформление отчета и утверждение концепции. Техническое задание: . • разработка и утверждение технического задания на создание АИС Эскизный проект: · разработка предварительных проектных решений по системе и ее частям; · разработка эскизной документации на АИС и ее части. Технический проект: · разработка проектных решений по системе и ее частям; 21 · разработка документации на АИС и ее части; · разработка и оформление документации на поставку комплектующих изделий; · разработка заданий на проектирование в смежных частях проекта. Рабочая документация: · разработка рабочей документации на АИС и ее части; · разработка и адаптация программ. Ввод в действие: · подготовка объекта автоматизации; подготовка персонала; · комплектация АИС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями); · строительно-монтажные работы; пусконаладочные работы; · проведение предварительных испытаний; · проведение опытной эксплуатации; · проведение приемочных испытаний. Сопровождение АИС: · выполнение работ в соответствии с гарантийными обязательствами; · послегарантийное обслуживание. Детализация ряда работ по этапам. Наименование этапа Содержание работ Планирование разработки ИС Формулирование целей создания ИС; 22 Поиск и обоснование оптимальных методов (способов) ее организации в условиях конкретного предприятия, Определение границ применения ИС Определение требований к составу и распределению информации (в том числе к организации баз данных) Определение состава пользователей и установление задач для каждого из них в процессе проектирования и эксплуатации ИС; Выявление существующих рабочих процессов и документов Разработка единого описания характеристик объектов Сбор и анализ требований к описанию информационных объектов от всех потенциальных пользователей ИС Разработка и исследование моделей проекта ИС как СУБД Концептуальное, логическое и физическое моделирования баз данных, в том числе: Определение объектов базы данных; Определение связей, их мощностей и обязательности, атрибутов; Повторный анализ сущностей: связь между сущностью и предметной областью, рабочие процессы, влияющие на сущность, взаимодействие между сущностями, атрибуты, анализ доменов, выбор типа ограничений; Нормализация данных; Выбор архитектуры базы данных системы; Таблицы; Связи; Индексы; Запросы; Защита данных: уровни защиты; 23 Отслеживание и регистрация событий в ИС. Проектирование пользовательского интерфейса Выбор модели интерфейса; Архитектура пользовательского интерфейса: поддержка рабочих процессов; Уровни пользовательского интерфейса; Критерии пользовательского интерфейса; Связь между сущностями и формами; Выбор элементов управления; Поддержка целостности данных; Отчеты; Поддержка пользователя Обоснование и выбор программной системы для разработки ИС Оценка ожидаемых затрат на разработку и эксплуатацию ИС в условиях предприятия Разработка проекта (прототипа) ИС Создание прототипа (модели ИС) средствами визуального проектирования (например, Access) Разработка и реализация ИС Разработка серверной и клиентской частей ИС как баз данных и прикладных программ Загрузка данных Заполнение базы данных информацией Тестирование Проверка работы ИС и устранение возникающих ошибок работы приложений Эксплуатация и сопровождение Разработка организационных мероприятий по внедрению ИС, наблюдение за работой системы и при необходимости внесение изменений в программные приложения. 24 Задание. 1. Ознакомиться с теоретическими сведениями по лабораторной работе 2. Определить достоинства и недостатки моделей ЖЦ ИС 3. Выбрать и обосновать выбор модели ЖЦ ИС для выполнения индивидуального проектного задания. 4. Сформировать план построения ИС индивидуального проектного задания, с использованием программных средств. Содержание отчета. Отчет оформляется на листах формата А4 и содержит 1. Название работы 2. Цель работы 3. Заполненную таблицу «Достоинства и недостатки моделей ЖЦ ИС» Модель ЖЦ ИС Достоинства Недостатки Каскадная Итерационная Спиральная 4. Выбранную модель ЖЦ ИС и обоснование выбора для персонального проектного задания на разработку ИС. 5. План построения ИС персонального проектного задания в форме: № п/п Название стадии (этапа) работ Содержание работ Результат работ Применя емые программные средства 1 25 Лабораторная работа № 2 Разработка концептуальной модели и модели декомпозиции процесса (стандарт IDEF0) Цель работы: получить навыки построения диаграмм прецедентов. Задание: 1. Создание концептуальной модели 2. Создание диаграммы декомпозиции Теоретический материал Методология IDEF0 предназначена для моделирования деятельности организации. На начальном этапе разработки проекта создается модель, предназначенная для описания существующих бизнес-процессов и технологических процессов на предприятии по принципу «AS - IS» («Как есть»), причем, что немаловажно, она представляет предприятие с позиции сотрудников, которые на нем работают и досконально знают все нюансы, в том числе и неформальные. AS-IS – «что мы делаем сегодня», перед тем, как перепрыгнуть на то, «что мы будем делать завтра». Модель деятельности или, иначе говоря, функциональная модель. Функциональная модель рассматривает систему как набор действий, в котором каждое действие преобразует некоторый объект или набор объектов. Технология IDEF 0 использует принцип функциональной декомпозиции систем (разбиение системы на фрагменты). Принцип декомпозиции означает, что функциональную модель следует строить по правилу «сверху вниз», от общего вида модели к частным моделям. Поэтому обычно функциональная модель решения задачи представляет собой совокупность частных функциональных моделей. Функциональные модели выделяют действия посредством представления в виде специального элемента – блока. Блок – основной структурный элемент функциональной модели, графическим представлением которой 26 является диаграмма. Наименование действия – отглагольное существительное или глагол. В результате декомпозиции м одели создается совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном листе. Методология IDEF 0 основана на четырех основных понятиях: функциональный блок (узел), интерфейсная дуга, декомпозиция, глоссарий. Функциональный блок Фундаментальным понятием технологии IDEF 0 является понятие функционального блока. Он предназначен для представления определенного вида деятельности (Activity), которая представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. Эта функция в свою очередь означает некоторое действие (набор действий), имеющее фиксированную цель и приводящее к некоторому конечному результату. Функциональный блок изображается прямоугольником, стороны которого имеют следующие значения: Верхняя сторона – управление. Нижняя сторона – механизм. Правая сторона – выход. Левая сторона – вход. Функциональный блок имеет имя, которое задается в глагольном наклонении или отглагольным существительным. Взаимодействие между действием и окружающим его миром, в том числе и с другими действиями, отображается с помощью интерфейсных дуг (стрелок). Интерфейсная дуга Интерфейсная дуга отображает элемент системы, который или обрабатывается функциональным блоком, или оказывет иное влияние на деятельность (функцию), отображенную данным функциональным 27 блоком. Интерфейсная дуга изображается в виде стрелки, которая обозначает носителя, обеспечивающего перенос данных или объектов от одной деятельности к другой. Стрелки описывают взаимодействие работ с внешним миром и между собой, представляют собой некую информацию и именуются существительными. Имя стрелки указывает ее роль (совокупность возможных ролей обозначается – ICOM): Вход функционального блока – Input. Управление – Control. Выход функционального блока – Output. Механизм – Mechanism. Вход (Input) – это материал или информация, которые используются или преобразуются работой для получения результата (выхода). Стрелки входа может не быть. Управление (Control) – правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Оно влияет на работу, но не преобразуется работой. Стрелка рисуется как входящая в верхнюю грань работы. Каждый функциональный блок должен иметь как минимум одну стрелку управления. Часто сложно определить, являются ли данные входом или управлением. Если данные в работе изменяются или перерабатываются, то это, скорее всего, вход, а если нет – управление. Если определить статус стрелки сложно, рекомендуется рисовать стрелку управления. Выход (Output) – материал или информация, которые производятся работой. Обязательна хотя бы одна стрелка выхода, исходящая из правой грани работы. Механизм исполнения (Mechanism) – ресурсы, которые выполняют работу (например, персонал, станки, устройства и т. п.). Стрелка рисуется как входящая в нижнюю грань работы. Стрелки механизма могут не изображаться. В общем виде функциональный блок показан на рис. 2.1. 28 Рис. 2.1 Функциональный блок На рис. 2.1 все интерфейсные дуги показаны в виде поименованных стрелок. По требованиям стандарта каждый функциональный блок должен иметь по крайней мере один выход и одно управление, так как каждая задача (процесс) должны иметь хотя бы один выход и хотя бы одно правило ее решения. Интерфейсная дуга «Механизм» может не изображаться. Из нескольких функциональных блоков, соединенных интерфейсными дугами требуемым образом, строится функциональная модель. Следует обратить внимание на то, что стрелки могут разветвляться, осуществляя требуемые соединения функциональных блоков. Входом функционального блока может быть не только выход другого функционального блока, но и его управление или даже механизм. В результате в функциональной модели могут быть различные, достаточно сложные и необычные процессы решения задач в информационной системе. Создание диаграмм в технологии IDEF0 При разработке модели деятельности организации следует использовать три типа диаграмм: I тип диаграммы – Контекстная диаграмма (может быть только одна) – вершина древовидной структуры, которая представляет собой наиболее абстрактный уровень описания системы и ее взаимодействие с внешней средой. В ней определена |