Разработка базы данных и интерфейса для системы, реализующей трансформацию высокоуровневого описания модели проекта в конструкции языка программирования - Курсовая работа
Анализ предметной области, этапы проектирования автоматизированных информационных систем. Инструментальные системы разработки программного обеспечения. Роль CASE-средств в проектировании информационной модели. Логическая модель проектируемой базы данных.
Аннотация к работе
Целью данной работы является разработка базы данных и интерфейса для системы, реализующей трансформацию высокоуровневого описания модели проекта в конструкции языка программирования, в процессе которой будут использованы результаты предварительных исследований. К проектированию АИС непосредственное отношение имеют два направления деятельности: - собственно проектирование АИС конкретных предприятий (отраслей) на базе готовых программных и аппаратных компонентов с помощью специальных инструментальных средств разработки; Эти технологии и среды образуют системы, называемые CASE-системами. Среди систем RAD различают интегрированные комплексы инструментальных средств для автоматизации всех этапов жизненного цикла ПО (такие системы называют Workbench) и специализированные инструментальные средства для выполнения отдельных функций (Tools). Если методика IDEF0 связана с функциональными аспектами и позволяет отвечать на вопрос "Что делает система?", то в IDEF3 детализируются и конкретизируются IDEF0-функции, IDEF3-модель отвечает на вопрос "Как система это делает?".В ходе выполнения дипломного проекта были выполнены исследования стандартов и методик проектирования различных систем. Исследованы стандарты описания интерфейсов, которые вложены в разнообразные CASE средства. На основании результатов проведенных работ и анализа способов применения паттернов проектирования сформированы положения о хранении информации в системе реализующей трансформацию высокоуровневого описания модели проекта в конструкции языка программирования. Предложена технология проектирования системы, которая опирается на комплексное использование различных инструментальных средств обеспечивающих проектирование и пошаговое продвижение к конечной цели. Подоляк, Б.А Позин Автоматизированное создание документов серии ГОСТ 34 и 19 с помощью инструментальных средств фирмы IBM Rational Доклад и статья опубликованы в рамках III-ей Всероссийской практической конференции: "Стандарты в проектах современных информационных систем" www.osp.ru , www.fostas.
Введение
Сейчас на начальном периоде рыночной экономики в стране возрастают требования ко всем отраслям промышленности и частного производства. На данном этапе характерно востребование проектируемых систем, помогающих не только при производственном процессе, но и при анализе возникающих проблем производства. В этих условиях задачи проектирования становятся наиболее существенными и решение их незамедлительно требуют использование систем автоматизированного проектирования (САПР).
Отмечая факт изменения подходов к проектированию различных систем, можно утверждать, что проектировщики разного уровня стремятся использовать в новых изделиях уже проверенные решения проектирования, а во многих случаях и ранее спроектированные модули и системы. Ярким примером этому служит использование паттернов проектирования в 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].
Эта методика рекомендуется для начальных стадий проектирования сложных систем автоматизации управления, производства, бизнеса, включающих людей, оборудование, программное обеспечение.
Разработка 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 методик продолжается в США по программе ІІСЕ (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.
Рисунок1.1 - Каскадная модель разработки программного обеспечения
На каждом этапе разработки ПО выполняются определенные виды работ и создается соответствующая документация. Если на каком-то этапе происходит выявление ошибки, то повторно выполняются этапы которые «затронула» выявленная ошибка, что приводит увеличению сроков выполнения и стоимости проекта.
Ошибки, выявленные на последний этап жизненного цикла - эксплуатация и сопровождение, самые дорогие при их устранении.
К недостаткам каскадной модели можно отнести негибкое разбиение процесса создания ПО на отдельные фиксированные этапы. В этой модели определяющие систему решения принимаются на ранних этапах и затем их трудно отменить или изменить, особенно это относится к формированию системных требований. Поэтому каскадная модель применяется тогда, когда требования формализованы достаточно четко и корректно. Вместе с тем каскадная модель хорошо отражает практику создания ПО.
Эволюционная модель разработки
Эта модель основана на следующей идее - разрабатывается первоначальная версия программного продукта, которая передается на испытание пользователям, затем она дорабатывается с учетом мнения пользователей, получается промежуточная версия продукта, которая также проходит "испытание пользователем", снова дорабатывается и гак несколько раз, пока не будет получен необходимый программный продукт. Отличительной чертой данной модели является то, что процессы специфицирования, разработки и аттестации ПО выполняются параллельно при постоянном обмене информацией между ними. Различают два подхода к реализации эволюционного метода разработки. а) Подход пробных разработок. Здесь большую роль играет постоянная работа с заказчиком (или пользователями) для того, чтобы определить полную систему требований к будущему ПО. Это необходимо для разработки конечной версии продукта. В рамках этого подхода вначале разрабатываются те части системы, которые очевидны или хорошо специфицированы. Система эволюционирует (дорабатывается) путем добавления новых средств по мере их предложения заказчиком. б) Прототипирование. Здесь целью процесса эволюционной разработки есть поэтапное уточнение требований заказчика и, следовательно, получение законченной спецификации, определяющей разрабатываемую систему. Прототип обычно строится для экспериментирования с той частью требований заказчика, которые сформированы нечетко или с внутренними противоречиями. Смотри рис. 1.2.
Эволюционный подход часто более эффективен, чем подход, построенный на основе каскадной модели, особенно если требования заказчика могут меняться в процессе разработки системы. Достоинством процесса создания ПО, построенного на основе эволюционного подхода, является то, что здесь спецификация может разрабатываться постепенно, по мере того как заказчик (или пользователи) осознает и сформулирует те задачи, которые должно решать программное обеспечение.
Вместе с тем данный подход имеет и некоторые недостатки: а) Многие этапы процесса создания ПО не документируются. Менеджерам проекта по созданию ПО необходимо регулярно документально отслеживать выполнение работ. Но если система разрабатывается быстро, то экономически не выгодно документировать каждую версию системы. б) Система часто получается плохо структурированной. Постоянные изменения в требованиях приводят к ошибкам и упущениям в структуре ПО. Со временем внесение изменений в систему становится все более сложным и затратным.
Рисунок 1.2 - Эволюционная модель разработки ПО
Часто требуются специальные средства и технологий разработки ПО. Это вызвано необходимостью быстрой разработки версий программного продукта.
Но, с другой стороны, это может привести к несовместимости некоторых применяемых средств и технологий, что, в свою очередь, требует наличия в команде разработчиков специалистов высокого уровня.
Эволюционный подход наиболее приемлем для разработки небольших программных систем (до 100 000 строк кода) и систем среднего размера (до 500 000 строк кода) с относительно коротким сроком жизни.
На больших долгоживущих системах слишком заметно проявляются недостатки этого подхода.
Формальная разработка систем
Этот подход к созданию ПО похож на модель каскадной разработки, но он построен на основе формальных математических преобразований системной спецификации в исполняемую программу. В приведенной схеме, для упрощения, не указаны обратные связи между делами процесса. Смотри рис. 1.3.
Рисунок 1.3 - Формальная модель разработки ПО
Между данным подходом и каскадной моделью существуют следующие кардинальные отличия. а) Здесь спецификация системных требований имеет вид детализированной формальной спецификации, записанной с помощью специальной математической нотации. б) Процессы проектирования, написания программного кода и тестирования системных модулей заменяются процессом, в котором формальная спецификация путем последовательных формальных преобразований трансформируется в исполняемую программу. См. рис.1.4.
Рисунок 1.4 - Модель формальных преобразований
В процессе преобразования формальное математическое представление системы последовательно и математически корректно тра
Вывод
В ходе выполнения дипломного проекта были выполнены исследования стандартов и методик проектирования различных систем. Исследованы стандарты описания интерфейсов, которые вложены в разнообразные CASE средства. На основании результатов проведенных работ и анализа способов применения паттернов проектирования сформированы положения о хранении информации в системе реализующей трансформацию высокоуровневого описания модели проекта в конструкции языка программирования.
Разработаны предложения по построению системы, которая будет независимой от технической платформы и операционной системы, легко масштабируемой и переносимой.
В результате работ была разработана база данных и интерфейс для работы с ней. Предложена технология проектирования системы, которая опирается на комплексное использование различных инструментальных средств обеспечивающих проектирование и пошаговое продвижение к конечной цели.
В итоге был получен результат, на который можно опереться при дальнейшей разработке системы.
Перечень ссылок
1. Гради Буч Объектно-ориентированное проектирование с примерами применения
3. Острейковский В. А. Теория систем. М: Высшая школа, 1997.
4. Д. Росс Структурный анализ (SA): язык для передачи понимания // Требования и спецификации в разработке программ. М.: Мир, 1984.
5. D. A. Marka, MCGOVAN К. L. SADT: Structured Analysis and Design Technique. N. Y.: MCGRAW Hill, 1988.
6. И.В. Галахов, Д.В. Лапыгин, А.Н. Новичков, О.Р. Подоляк, Б.А Позин Автоматизированное создание документов серии ГОСТ 34 и 19 с помощью инструментальных средств фирмы IBM Rational Доклад и статья опубликованы в рамках III-ей Всероссийской практической конференции: "Стандарты в проектах современных информационных систем" www.osp.ru , www.fostas.ru
7. Георгий Калянов - Публикации . Калянов Г.Н. CASE - технологии проектирования программного обеспечения // Кибернетика и системный анализ,...... и основные направления их развития // Материалы семинара "CASE технология", М.: ЦРДЗ,... - http://kalyanov.by.ru/publications/index.htm
10. Д.В. Богданов, В.А. Путилов, В.В. Фильчаков Стандартизация процессов обеспечения качества программного обеспечения. - Апатиты, КФ ПЕТРГУ, 1997. - 16
11. В.Н.Касьянов, В.А.Евстигнеев Графы в программировании: обработка, визуализация и применение - СПБ. БХВ Питербург, 2003 - 1104 с.
12. Питер Колетски, д-р Поль Дорси Oracle Designer Настольная книга пользователя Издательство ЛОРИ, 1999
13. Серверы корпоративных баз данных http://www.sitforum.ru
14. С.В.Маклаков EPWIN и BRWIN CASE-средства разработки информационных систем, Москва, ДИАЛОГМИФИ, 2000
15. Л. Сорокин Средства разработки Oracle как инструменты инженерного подхода в создании промышленного программного обеспечения, Oracle
16. Кевин Луни, Марлен Терью Oracle 9i Настольная книга администратора Перевод с англ., Москва, изд. ЛОРИ, 2004 - 748 с.