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

Размещено на http://www.allbest.ru/

Введение

Сейчас на начальном периоде рыночной экономики в стране возрастают требования ко всем отраслям промышленности и частного производства. На данном этапе характерно востребование проектируемых систем, помогающих не только при производственном процессе, но и при анализе возникающих проблем производства. В этих условиях задачи проектирования становятся наиболее существенными и решение их незамедлительно требуют использование систем автоматизированного проектирования (САПР).

Отмечая факт изменения подходов к проектированию различных систем, можно утверждать, что проектировщики разного уровня стремятся использовать в новых изделиях уже проверенные решения проектирования, а во многих случаях и ранее спроектированные модули и системы. Ярким примером этому служит использование паттернов проектирования в UML[1]. Отработанные подходы работы с паттернами распространяются на все новые области практического применения.

Если предположить, что измененные технологии проектирования начнут широко использовать технологию работы с паттернами проектирования[2], то возникает вопрос, каким образом разработчики смогут обмениваться результатами и в каком виде результат работы должен быть представлен. На это может дать ответ и информационно обеспечить только коллективная система проектирования, которая построена на применении системы накопления, хранения и предоставления информации, т.е. это функционирующая база данных.

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

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

1. Анализ предметной области и постановка задачи

Современные автоматизированные информационные системы (АИС) относятся к числу наиболее сложных систем, создаваемых человеком. Методы и средства их создания развиваются быстрыми темпами, как в качественном так и в количественном отношениях, вовлекая в русло системной интеграции все большее число специалистов.

1.1 Этапы проектирования автоматизированных информационных систем

К проектированию АИС непосредственное отношение имеют два направления деятельности:

- собственно проектирование АИС конкретных предприятий (отраслей) на базе готовых программных и аппаратных компонентов с помощью специальных инструментальных средств разработки;

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

Сущность первого направления может быть выражена словами “системная интеграция”. Разработчик АИС должен быть специалистом в области системотехники, хорошо знать международные стандарты, состояние и тенденции развития информационных технологий и программных продуктов, владеть инструментальными средствами разработки приложений (CASE-средствами) и быть готовым к восприятию и анализу автоматизируемых прикладных процессов в сотрудничестве со специалистами соответствующей предметной области. Существует ряд фирм, специализирующихся на разработке проектов АИС (например, Price Waterhouse, Jet Info, Consistent Software и др.)

Второе направление в большей мере относится к области разработки математического и программного обеспечения для реализации функций АИС -- моделей, методов, алгоритмов, программ на базе знания системотехники, методов анализа и синтеза проектных решений, технологий программирования, операционных систем и т. п. В каждом классе АИС (АСУ, САПР, ГИС и т. д.) имеются фирмы, специализирующиеся на разработке программных (а иногда и программно-аппаратных) систем. Каждая из них рекламирует свою технологию создания АИС и придерживается стратегии либо тотального поставщика, либо открытости и расширения системы приложениями и дополнениями третьих фирм.

Как, собственно, АИС, так и компоненты АИС являются сложными системами, и при их проектировании целесообразно использовать нисходящий стиль блочно-иерархического проектирования, включающего ряд уровней и этапов [3].

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

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

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

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

Результаты анализа -- техническое предложение и бизнес-план создания АИС -- представляются заказчику для окончательного согласования.

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

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

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

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

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

Если территориально АИС располагается в одном здании или в нескольких близкорасположенных зданиях, то корпоративная сеть может быть выполнена в виде совокупности нескольких локальных подсетей типа Ethernet или Token Ring, связанных опорной сетью типа FDDI, ATM или высокоскоростными вариантами Ethernet. Кроме выбора типов подсетей, связных протоколов и коммутационного оборудования приходится решать задачи распределения узлов по подсетям, выделения серверов, выбора сетевого ПО, определения способа управления данными в выбранной схеме распределенных вычислений и т. п.

Если АИС располагается в удаленных друг от друга пунктах, в частности, расположенных в разных городах, то решается вопрос об аренде каналов связи для корпоративной сети, поскольку альтернативный вариант использования выделенного канала в большинстве случаев оказывается неприемлемым из-за высокой цены. Естественно, что при этом, прежде всего, рассматривается возможность использования услуг Internet. Именно через Internet могут взаимодействовать предприятия, работающие по технологии CALS (Computer Acquisition Life-Cycle System). Возникающие при этом проблемы связаны с обеспечением информационной безопасности и надежности доставки сообщений.

Одной из главных тенденций современной индустрии информатики является создание открытых систем. Свойство открытости означает, во-первых, переносимость (мобильность) программного обеспечения на различные аппаратные платформы, во-вторых, приспособленность системы к ее модификациям (модифицируемость или собственно открытость) и комплексированию с другими системами в целях расширения ее функциональных возможностей и/или придания системе новых качеств (интегрируемость).

Важное значение для создания открытых систем имеет унификация и стандартизация средств межпрограммного интерфейса или, другими словами, необходимо наличие профилей АИС для информационного взаимодействия программ, входящих в АИС. Профилем открытой системы называют совокупность стандартов и других нормативных документов, обеспечивающих выполнение системой заданных функций. Так, в профилях АИС могут фигурировать язык EXPRESS стандарта STEP, стандарт графического пользовательского интерфейса Motif, унифицированный язык SQL обмена данными между различными системами управления базами данных (СУБД), стандарты сетевого взаимодействия, в профили САПР машиностроения может входить формат IGES и в случае САПР радиоэлектроники -- формат EDIF и т. п.

1.2 Инструментальные системы разработки программного обеспечения

В современных информационных технологиях важное место отводится инструментальным средствам и средам разработки АИС и, в частности, системам разработки и сопровождения их ПО. Эти технологии и среды образуют системы, называемые CASE-системами.

Используется двоякое толкование аббревиатуры CASE, соответствующее двум направлениям использования CASE-систем. Первое из них -- Computer Aided Software Engineering -- переводится как автоматизированное проектирование программного обеспечения, соответствующие CASE-системы часто называют инструментальными средами разработки ПО (RAD -- Rapid Application Development). Второе -- Computer Aided System Engineering -- подчеркивает направленность на поддержку концептуального проектирования сложных систем, преимущественно слабоструктурированных. Такие CASE-системы часто называют системами BPR (Business Process Reengineering).

Среди систем RAD различают интегрированные комплексы инструментальных средств для автоматизации всех этапов жизненного цикла ПО (такие системы называют Workbench) и специализированные инструментальные средства для выполнения отдельных функций (Tools). Средства CASE по своему функциональному назначению принадлежат к одной из следующих групп: 1) средства программирования; 2) средства управления программным проектом; 3) средства верификации (анализа) программ; 4) средства документирования.

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

1.3 Спецификации проектов программных систем

Важное значение в процессе разработки ПО имеют средства спецификации проектов ПО. Средства спецификации в значительной мере определяют суть методов CASE.

Существует ряд способов представления моделей [3]. Практически все способы функциональных спецификаций имеют следующие общие черты:

- модель имеет иерархическую структуру, представляемую в виде диаграмм нескольких уровней;

- ?элементарной частью диаграммы каждого уровня является конструкция "вход--функция--выход";

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

1.3.1 Построение DFD диаграммы процесса создания компоненты в системе проектирования

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

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

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

- группа математиков аналитиков. Определяют непротиворечивость требований к реализации компоненты;

- группа создания программных моделей замещения компоненты;

- группа реализации компоненты.

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

Рисунок 3.2 - Диаграмма потоков данных в «структуре» разработки компонентов

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

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

1.3.2 Технологии реинжиниринга и параллельного проектирования

Взаимосвязанная совокупность методик концептуального проектирования IDEF (Integrated Definition) разработана по программе Integrated Computer-Aided Manufacturing в США. В этой совокупности имеются методики функционального, информационного и поведенческого моделирования и проектирования, в ее состав в настоящее время входят IDEF-методики, отмеченные в таблице.

Наиболее известной методикой функционального моделирования сложных систем является методика SADT (Structured Analysis and Design Technique), предложенная в 1973г. Д. Россом и впоследствии ставшая основой стандарта IDEF0 [4, 5].

Таблица 1.1 Семейство стандартов IDEF

Название	Назначение
IDEF0	Функциональное моделирование (Function Modeling Method)
IDEF1 и IDEF1X	Информационное моделирование (Information and Data Modeling Methods)
IDEF2	Поведенческое моделирование (Simulation Modeling Method)
IDEF3	Моделирование процессов (Process Flow and Object State Description Capture Method)
IDEF4	Объектно-ориентированное проектирование (Object-Oriented Design Method)
IDEF5	Систематизации объектов приложения (Ontology Description Capture method)
IDEF6	Использование рационального опыта проектирования (Design Rationale Capture Method)
IDEF8	Взаимодействие человека и системы (Human-System Interaction Design)
IDEF9	Учет условий и ограничений (Business Constraint Discovery)
IDEF14	Моделирование вычислительных сетей (Network Design)

 

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

Разработка SADT-модели начинается с формулировки вопросов, на которые модель должна давать ответы, т. е. формулируется цель моделирования. Далее выполняются этапы:

- сбор информации. Источниками информации могут быть документы, наблюдение, анкетирование и т. п. Существуют специальные методики выбора экспертов и анкетирования;

- создание модели. Используется нисходящий стиль: сначала разрабатываются верхние уровни, затем нижние;

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

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

Поведенческие аспекты приложений отражает методика IDEF3 [6]. Если методика IDEF0 связана с функциональными аспектами и позволяет отвечать на вопрос "Что делает система?", то в IDEF3 детализируются и конкретизируются IDEF0-функции, IDEF3-модель отвечает на вопрос "Как система это делает?". В IDEF3 входят два типа описаний:

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

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

Системы информационного моделирования реализуют методики инфологического проектирования баз данных. Широко используются язык и методика IDEF1X создания информационных моделей приложений, развивающая более раннюю методику IDEF1 [7]. Кроме того, развитые коммерческие СУБД, как правило, имеют в своем составе совокупность CASE-средств проектирования приложений.

В IDEF1X имеется ясный графический язык для описания объектов и отношений в приложениях. Этот язык есть язык диаграмм "сущность-связь" (ERD). Разработка информационной модели по IDEF1X выполняется за несколько стадий.

Стадия 0. Выясняются цели проекта, составляется план сбора информации. Обычно исходные положения для информационной модели следуют из IDEF0-модели.

Стадия 1. Выявление и определение сущностей. Это неформальная процедура.

Стадия 2. Выявление и определение основных отношений. Результат представляется или графически в виде ER-диаграмм, или в виде матрицы отношений, элемент которой Aij = 1, если имеется связь между сущностями i и j, иначе Aij = 0, транзитивные связи не указываются.

Стадия 3. Детализация неспецифических отношений, определение ключевых атрибутов, установление внешний ключей. Детализация неспецифических отношений заключается в замене связей "многие ко многим" на связи "многие к одному" и "один ко многим" введением сущности-посредника.

Стадия 4. Определение атрибутов и их принадлежности сущностям.

Методика IDEF4 реализует объективно-ориентированное проектирование больших систем. Она предоставляет пользователю графический язык для изображения классов, диаграмм наследования, таксономии методов.

Методика IDEF5 направлена на представление онтологической информации приложения в удобном для пользователя виде. Для этого используются символические обозначения (дескрипторы) объектов, их ассоциаций, ситуаций и схемный язык описания отношений классификации, "часть--целое", перехода и т. п. В методике имеются правила связывания объектов (термов) в правильные предложения и аксиомы интерпретации термов.

Развитие BPR методик продолжается в США по программе IIСЕ (Information Integration for Concurrent Engineering) [8]. Разработаны методики:

- IDEF6 направленная на сохранение рационального опыта проектирования информационных систем, что способствует предотвращению повторных ошибок;

- IDEF8 для проектирования диалога человека с технической системой;

- IDEF9 для анализа имеющихся условий и ограничений (в том числе физических, юридических, политических) и их влияния на принимаемые решения в процессе реинжиниринга;

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

Основные положения стандартов IDEF0 и IDEF1X использованы также при создании комплекса стандартов ISO 10303, задающих технологию STEP для представления в компьютерных средах информации, относящейся к промышленному производству. В свою очередь, стандарты STEP, совокупность языков таких, как Express и SGML, а также разрабатываемые стандарты P-LIB и MANDATE [9] составляют основу технологии CALS информационного обеспечения всех этапов жизненного цикла промышленных изделий.

Технология CALS призвана разрешить проблему согласования содержания и формы представления данных о промышленной продукции в территориально распределенной сети проектных и производственных узлов на основе совокупности международных стандартов и телекоммуникационных технологий. Только в этих условиях станет возможной оптимальная специализация предприятий, распределенное проектирование, минимизация затрат на освоение и эксплуатацию созданных систем.

1.3.3 Системные (операционные) среды автоматизированных информационных систем (АИС)

Системы автоматизированного проектирования относятся к числу наиболее сложных и наукоемких автоматизированных систем. Более того, на крупных и средних предприятиях заметна тенденция к интеграции САПР с системами документооборота, а иногда и с системами управления производством.

Системные среды САПР [11] часто называют инфраструктурами САПР или Frameworks (FW). Основные функции системных сред САПР:

- управление данными;

- управление процессом проектирования;

- интеграция программного обеспечения;

- реализация интерфейса с пользователем САПР;

- помощь в разработке и сопровождении ПО САПР.

Сходные функции реализуются и в системных средах АСУ с той разницей, что в них вместо проектных операций и процедур фигурируют бизнес-функции и бизнес-процессы. В типичной структуре программного обеспечения системных сред САПР выделяют следующие подсистемы.

Ядро FW отвечает за взаимодействие компонентов FW, доступ к ресурсам операционной системы и к сети, возможность работы в гетерогенной распределенной среде, настройку на конкретную САПР с помощью специальных языков расширения.

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

Подсистема управления методологией проектирования представлена в виде базы знаний БЗ УПР. В этой базе знаний содержатся такие сведения о предметной области, как информационная модель (например, в виде диаграмм "сущность--отношение"), иерархическая структура проектируемых объектов (например, в виде И--ИЛИ-дерева), описания типовых проектных процедур, типовые фрагменты маршрутов проектирования -- так называемые потоки (flows) процедур, соответствие между процедурами и имеющимися пакетами прикладных программ, ограничения на их применение и т. п. Часто БЗ УПР дополняется обучающей подсистемой, используемой для подготовки специалистов к использованию САПР.

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

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

Интеграция может быть на основе унифицированных форматов или общего банка данных. Пример унифицированного формата -- TES (Tool Encapsulation Specification), предложенного консорциумом CFI (CAD Framework Initiative). Информация из TES используется для создания конверторов файлов при инкапсуляции.

Подсистема пользовательского интерфейса включает текстовый и графический редакторы и поддерживается системами многооконного интерфейса типа X Windows System или Open Look.

Подсистема CASE предназначена для адаптации САПР к нуждам конкретных пользователей, для разработки и сопровождения прикладного ПО. Обычно CASE-подсистема включает обычные CASE-компоненты для разработки структурных схем алгоритмов, "экранов" для взаимодействия с пользователем в интерактивных процедурах, средства для инфологического проектирования баз данных (БД), отладки программ, документирования, сохранения "истории" проектирования и т. п. Но наряду с этим, в подсистему входят и компоненты со специфическими для САПР функциями.

Так, в состав САПР Microstation [12] (фирма Bentley Systems) включена RAD-среда Microstation Basic и язык MDL (Microstation Development Language) с соответствующей программной поддержкой. Microstation Basic близка по своим функциям к среде MS Visual Basic, в ней имеются генератор форм, редактор, конструктор диалога, отладчик. Язык MDL -- С - подобный, с его помощью можно лаконично выразить обращения к проектным операциям и процедурам.

САПР Спрут [13] (российская фирма Sprut Technologies) вообще создана как инструментальная среда для разработки пользователем потоков задач конструкторского и технологического проектирования в машиностроении с последующим возможным оформлением потоков в виде пользовательских версий САПР. Сконструированный поток поддерживается компонентами системы, в число которых входят графические 2D и 3D подсистемы, СУБД, продукционная экспертная система, документатор, технологический процессор создания программ для станков с ЧПУ, постпроцессоры.

1.4 Модели процесса создания систем

Приступая к проектированию, разработчик должен определиться с выбором варианта модели процесса, по которому будет создана система [6]. Выбранная модель будет использоваться в виде шаблона, по которому будет создаваться программная или техническая система. Модель будет задавать последовательности работ при выполнении и декларировать результаты, которые необходимо получить на каждом этапе. В настоящее время наиболее часто используют следующие модели разработки:

- каскадная модель разработки;

- эволюционная модель разработки;

- модель формальной разработки систем;

- модель разработки на основе ранее созданных компонентов;

- модель пошаговой разработки;

- спиралевидная модель разработки.

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

Рассмотрим подробнее каждую модель.

Каскадная модель

Основные принципиальные этапы модели отражают все базовые виды деятельности, необходимые для создания ПО:

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

б) Проектирование системы и программного обеспечения. Процесс проектирования системы разбивается на реализацию следующих пунктов:

- системные требования;

- требования, предъявляемые к аппаратным средствам;

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

Разрабатывается общая архитектура системы. До начала проведения работ предполагается, что имеются все определения и словесные описания требований к основным программным компонентам и их взаимосвязям.

в) Кодирование и тестирование программных модулей. На этой стадии реализуется архитектура ПО, как множество программ или программных модулей. Тестирование каждого модуля включает проверку его соответствия требованиям к данному модулю.

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

д) Эксплуатация и сопровождение системы. Обычно это самая длительная фаза жизненного цикла ПО. Система инсталлируется, и начинается период ее эксплуатации. Сопровождение системы включает исправление ошибок, которые не были обнаружены на более ранних этапах жизненного цикла, совершенствование системных компонентов и "подгонку" функциональных возможностей системы к новым требованиям. Смотри рис.1.1.



Размещено на http://www.allbest.ru/

Рисунок1.1 - Каскадная модель разработки программного обеспечения

На каждом этапе разработки ПО выполняются определенные виды работ и создается соответствующая документация. Если на каком-то этапе происходит выявление ошибки, то повторно выполняются этапы которые «затронула» выявленная ошибка, что приводит увеличению сроков выполнения и стоимости проекта.

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

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

Эволюционная модель разработки

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

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

б) Прототипирование. Здесь целью процесса эволюционной разработки есть поэтапное уточнение требований заказчика и, следовательно, получение законченной спецификации, определяющей разрабатываемую систему. Прототип обычно строится для экспериментирования с той частью требований заказчика, которые сформированы нечетко или с внутренними противоречиями. Смотри рис. 1.2.

Эволюционный подход часто более эффективен, чем подход, построенный на основе каскадной модели, особенно если требования заказчика могут меняться в процессе разработки системы. Достоинством процесса создания ПО, построенного на основе эволюционного подхода, является то, что здесь спецификация может разрабатываться постепенно, по мере того как заказчик (или пользователи) осознает и сформулирует те задачи, которые должно решать программное обеспечение.

Вместе с тем данный подход имеет и некоторые недостатки:

а) Многие этапы процесса создания ПО не документируются. Менеджерам проекта по созданию ПО необходимо регулярно документально отслеживать выполнение работ. Но если система разрабатывается быстро, то экономически не выгодно документировать каждую версию системы.

б) Система часто получается плохо структурированной. Постоянные изменения в требованиях приводят к ошибкам и упущениям в структуре ПО. Со временем внесение изменений в систему становится все более сложным и затратным.

Размещено на http://www.allbest.ru/

Рисунок 1.2 - Эволюционная модель разработки ПО

Часто требуются специальные средства и технологий разработки ПО. Это вызвано необходимостью быстрой разработки версий программного продукта.

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

Эволюционный подход наиболее приемлем для разработки небольших программных систем (до 100 000 строк кода) и систем среднего размера (до 500 000 строк кода) с относительно коротким сроком жизни.

На больших долгоживущих системах слишком заметно проявляются недостатки этого подхода.

Формальная разработка систем

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

Размещено на http://www.allbest.ru/

Рисунок 1.3 - Формальная модель разработки ПО

Между данным подходом и каскадной моделью существуют следующие кардинальные отличия.

а) Здесь спецификация системных требований имеет вид детализированной формальной спецификации, записанной с помощью специальной математической нотации.

б) Процессы проектирования, написания программного кода и тестирования системных модулей заменяются процессом, в котором формальная спецификация путем последовательных формальных преобразований трансформируется в исполняемую программу. См. рис.1.4.



Размещено на http://www.allbest.ru/

Рисунок 1.4 - Модель формальных преобразований

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

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

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

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

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

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

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

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

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

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

в) Проектирование системы. На данном этапе проектируется структура системы либо модифицируется существующая структура повторно используемой системы. Проектирование должно учитывать отобранные программные компоненты и строить структуру в соответствии с их функциональными возможностями. Если некоторые готовые программные компоненты недоступны, проектируется «новое» ПО.

г) Разработка и сборка системы. Это этап непосредственного создания системы. В рамках рассматриваемого подхода сборка системы является скорее частью разработки системы, чем отдельным этапом. См. рис. 1.5.

Размещено на http://www.allbest.ru/

Рисунок 1.5 - Разработка ПО с повторным использованием ранее созданных компонентов

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

Вместе с тем при использовании этого подхода неизбежны компромиссы при определении требований; это может привести к тому, что законченная система не будет удовлетворять всем требованиям заказчика. Кроме того, при проведении модернизации системы (т.е. при создании ее новой версии) отсутствует возможность влиять на появление новых версий компонентов, используемых в системе, что значительно затрудняет сам процесс модернизации.

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

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

Модель пошаговой разработки

Процесс пошаговой разработки (смотри рис. 1.6) имеет целый ряд достоинств:

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

б) Заказчик может использовать компоненты, полученные на первых шагах разработки, как прототипы и провести с ними эксперименты для уточнения требований к тем компонентам, которые будут разрабатываться позднее.

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

г) Поскольку системные сервисы с высоким приоритетом разрабатываются первыми, а все последующие компоненты интегрируются с ними, неизбежно получается так, что наиболее важные подсистемы подвергаются более тщательному всестороннему тестированию и проверке. Это значительно снижает вероятность программных ошибок в особо важных частях системы.

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

Размещено на http://www.allbest.ru/

Рисунок 1.6 - Модель пошаговой разработки ПО

Спиральная модель разработки

Каждый виток спирали разбит на четыре сектора, на которых выполняются следующие действия:

а) Определение целей. Определяются цели каждой итерации проекта. Кроме того, устанавливаются ограничения на процесс создания ПО и на программный продукт. Уточняются планы производства компонентов. Определяются проектные риски (например, риск превышения сроков или риск превышения стоимости проекта). В зависимости от "проявленных" рисков, могут использоваться альтернативные стратегии разработки ПО.

б) Оценка и разрешение рисков. Для каждого определенного проектного риска проводится его детальный анализ. Планируются мероприятия для уменьшения (разрешения рисков). Например, если существует риск, что системные требования определен неверно, планируется разработать прототип системы.

в) Разработка и тестирование. После оценки рисков выбирается модель процесса создания системы. Например, сети доминируют риски, связанные с разработкой интерфейсов, наиболее подходящей будет эволюционная модель разработки методом создания прототипов. Если основные риски связаны с соответствием системы и спецификации, скорее всего, следует применить модель формальных преобразований. Каскадная модель может быть применена в том случае, если основные риски определены как ошибки, которые могут проявиться на этапе сборки системы.

г) Планирование. Здесь пересматривается проект и принимается решение о том, начинать ли следующий виток спирали. Если принимается решение о продолжении проекта, разрабатывается план на следующую стадию проекта. Смотри рис. 1.7.

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

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

Рисунок 1.7 - Спиралевидная модель разработки ПО

Оценивая возможность использования одной из перечисленных моделей разработки, при создании системы трансформации высокоуровневого описания в код, нужно акцентировать внимание на трех моделях проектирования. Это каскадная модель разработки, которая наиболее часто используется при создании систем и поддерживается национальными ГОСТами, это формальная модель разработки и модель разработки программного обеспечения с повторным использованием ранее созданных компонентов. Каждая, из перечисленных моделей, обладает рядом достоинств и недостатков. Так каскадная модель может быть использована в случае, когда заказчик предает техническое задание на разработку и требует строгого его исполнения. Для разработки НИР такой подход неприемлем. Следующие две модели имеют свои достоинства и недостатки при выполнении НИР. Но при их объединении, можно построить новую модель системы проектирования, в которой обе модели проектирования будут дополнять друг друга, локализуя частные недостатки. Основным достоинством такой модели проектирования можно считать, что имеется возможность виртуального построения проектируемой системы, на которой можно выполнить тестирование свойств системы, с одной стороны, и проведение параллельных работа над «физической» реализацией системы. При создании как виртуальной, так и «физической» системы появляется возможность использовать ранее созданные компоненты (паттерны) которые уже функционируют в иных системах. Для эффективного применения компонентов проектирования необходимо наличие системы хранения и поиска компонентов по требованию.

1.5 Инструментальные средства и среды разработки баз данных

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

Используется двоякое толкование аббревиатуры CASE, соответствующее двум направлениям применения CASE-систем. Первое из них -- Computer Aided Software Engineering -- переводится как автоматизированное проектирование программного обеспечения, такие CASE-системы часто называют инструментальными средами разработки (RAD -- Rapid Application Development). Второе -- Computer Aided System Engineering -- подчеркивает направленность на поддержку концептуального проектирования сложных систем, преимущественно слабоструктурированных.

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

Наиболее полное и комплексное решение в области разработки корпоративных баз данных предлагается корпорацией Oracle [9]. В зависимости от масштаба и назначения разработки, инструменты Oracle могут комплектоваться в наборы, наиболее оптимально соответствующие поставленным задачам. Из основных инструментов предлагаемых Oracle можно выделить наиболее часто используемые компоненты:

а) Designer - Средство описания разрабатываемой системы в виде все охватывающей модели и генерации на ее основе законченных приложений для различных средств разработки.

б) Developer - Многоплатформенное и масштабируемое средство визуального создания промышленных приложений, легко настраиваемых в зависимости от мощности сервера и клиентских компьютеров и переносимых на работу в среду Internet/Intranet.

в) Power Objects - Инструмент для разработки приложений небольшого масштаба, способного работать с разнообразными источниками данных.

г) Programmer - Набор предкомпиляторов для C/C+, заметно упрощающих создание приложений на C/C+ для сервера Oracle.

д) Mobile Agents - Позволяет разрабатывать приложения для мобильных пользователей или для удаленных систем, работающих через плохие, неустойчивые каналы связи.

Необходимо отметить, что в отличие от "универсальных" средств разработок, ориентированных на работу с любыми СУБД (Delphi, Visual Basic, PowerBuilder, BPwin/ERwin, Rational Rose и ARIS), "родные" инструменты полностью используют все возможности сервера Oracle. А именно, поддержка последовательностей и синонимов, работа с механизмом обеспечения секретности на сервере, доступ к хранимым на сервере процедурам и переменным, управление оптимизатором выполнения SQL-команд - использование этих возможностей либо невозможно в универсальных средствах разработок, либо требует большого труда при кодировании.