Создание физической модели данных
Физическая модель содержит всю информацию, необходимую для реализации конкретной БД. Различают два уровня физической модели:
трансформационную модель;
модель СУБД.
Трансформационная модель содержит информацию для реализации отдельного проекта, который может быть частью общей ИС и описывать подмножество предметной области. Данная модель позволяет проектировщикам и администраторам БД лучше представить, какие объекты БД хранятся в словаре данных, и проверить, насколько физическая модель удовлетворяет требованиям к ИС.
Модель СУБД автоматически генерируется из трансформационной модели и является точным отображением системного каталога СУБД.
Физический уровень представления модели зависит от выбранного сервера. ERwin поддерживает более 20 реляционных и нереляционных БД.
По умолчанию ERwin генерирует имена таблиц и индексов по шаблону на основе имен соответствующих сущностей и ключей логической модели, которые в дальнейшем могут быть откорректированы вручную. Имена таблиц и колонок будут сгенерированы по умолчанию на основе имен сущностей и атрибутов логической модели.
ERwin поддерживает правила валидации для колонок, а также значение, присваиваемое колонкам по умолчанию.
Правило валидации задает список допустимых значений для конкретной колонки и/или правила проверки допустимых значений. ERwin позволяет сгенерировать правила валидации соответственно синтаксису выбранной СУБД с учетом границ диапазона или списка значений. Значение по умолчанию – значение, которое нужно ввести в колонку, если никакое другое значение не задано явным образом во время ввода данных.
При генерации схемы физической БД ERwin автоматически создает индекс на основе первичного ключа каждой таблицы, а также на основе всех альтернативных ключей и внешних ключей, поскольку эти колонки наиболее часто используются для поиска данных.
Данные, которые редко меняются. помещают в хранилища данных. Хранилища ориентированы на выполнение аналитических запросов, обеспечивающих поддержку принятия решений для руководителей и менеджеров. Проектирование хранилища данных подразумевает создание денормализованной структуры данных, ориентированных в первую очередь на высокую производительность при выполнении аналитических запросов. Нормализация делает модель хранилища слишком сложной, затрудняет ее понимание и снижает скорость выполнения запроса. Для эффективного проектирования хранилищ данных ERwin использует размерную модель – методологию проектирования, предназначенную специально для разработки хранилищ данных.
ERwin обеспечивает прямое и обратное проектирование. Прямым проектированием называется процесс генерации физической схемы БД из логической модели. При генерации физической схемы ERwin включает триггеры ссылочной целостности, хранимые процедуры, индексы, ограничения и другие возможности.
Обратным проектированием называется процесс генерации логической модели из физической БД. Обратное проектирование позволяет конвертировать БД из одной СУБД в другую. После создания логической модели БД путем обратного проектирования можно переключиться на другой сервер и произвести прямое проектирование.
ERwin поддерживает не только проектирование сервера БД, но и автоматическую генерацию клиентского приложения в средах разработки MS Visual Basic и Power Builder. Технология генерации состоит в том, что на этапе разработки физической модели данных каждой колонке присваиваются расширенные атрибуты, содержащие информацию о свойствах объектов клиентского приложения, которые будут отображать информацию, хранящуюся в соответствующей колонке. На основе информации, содержащейся в расширенных атрибутах, генерируются экранные формы. Полученный код может быть откомпилирован и выполнен без дополнительного ручного кодирования.
ERwin поддерживает генерацию кода в Visual Basic версий 4.0 и 5.0. В качестве источника информации при генерации форм служит модель ERwin. С помощью ERwin можно одновременно описывать как клиентскую часть (объекты, отображающие данные на экране), так и сервер БД (процедуры и триггеры), тем самым оптимально распределяя функциональность ИС между клиентской и серверной частью. Компонент ERwin Form Wizard автоматически проектирует формы с дочерними объектами – кнопками, списками, полями, радиокнопками и т. д. Совместное использование ERwin и Visual Basic позволяет сократить жизненный цикл разработки ИС. Visual Basic может быть использован для проектирования визуального интерфейса, а ERwin – для разработки физической и логической модели данных с последующей генерацией системного каталога сервера.
В ERwin имеется простой и эффективный инструмент для генерации отчетов. Отчеты позволяюь наглядно представить информацию об основных объектах модели данных – как логической, так и физической.
Для управления большими проектами ERwin имеет специальный инструмент – Словарь, который обеспечивает коллективную работу над диаграммами и позволяет сохранять и документировать различные версии моделей данных.
Методология RAD.
Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:
небольшую команду программистов (от 2 до 10 человек);
короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);
повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком.
Команда разработчиков должна представлять из себя группу профессионалов, имеющих опыт в анализе, проектировании, генерации кода и тестировании ПО с использованием CASE-средств.
Жизненный цикл ПО по методологии RAD состоит из четырех фаз:
фаза анализа и планирования требований;
фаза проектирования;
фаза построения;
фаза внедрения.
На фазе анализа и планирования требований пользователи системы определяют функции, которые она должна выполнять, выделяют наиболее приоритетные из них, требующие проработки в первую очередь, описывают информационные потребности. Определение требований выполняется в основном силами пользователей под руководством специалистов-разработчиков. Ограничивается масштаб проекта, определяются временные рамки для каждой из последующих фаз. Кроме того, определяется сама возможность реализации данного проекта в установленных рамках финансирования, на данных аппаратных средствах и т.п. Результатом данной фазы должны быть список и приоритетность функций будущей ИС, предварительные функциональные и информационные модели ИС.
На фазе проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. CASE-средства используются для быстрого получения работающих прототипов приложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и, при необходимости, корректируется функциональная модель. Каждый процесс рассматривается детально. При необходимости для каждого элементарного процесса создается частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности. На этой же фазе происходит определение набора необходимой документации.
После детального определения состава процессов оценивается количество функциональных элементов разрабатываемой системы и принимается решение о разделении ИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время - порядка 60 - 90 дней. С использованием CASE-средств проект распределяется между различными командами (делится функциональная модель). Результатом данной фазы должны быть:
общая информационная модель системы;
функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;
точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;
построенные прототипы экранов, отчетов, диалогов.
Все модели и прототипы должны быть получены с применением тех CASE-средств, которые будут использоваться в дальнейшем при построении системы. В отличие от традиционного подхода, при котором использовались специфические средства прототипирования, не предназначенные для построения реальных приложений, а прототипы выбрасывались после того, как выполняли задачу устранения неясностей в проекте, в подходе RAD каждый прототип развивается в часть будущей системы. Таким образом, на следующую фазу передается более полная и полезная информация.
На фазе построения выполняется непосредственно сама быстрая разработка приложения. На данной фазе разработчики производят итеративное построение реальной системы на основе полученных в предыдущей фазе моделей, а также требований нефункционального характера. Программный код частично формируется при помощи автоматических генераторов, получающих информацию непосредственно из репозитория CASE-средств. Конечные пользователи на этой фазе оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требованиям. Тестирование системы осуществляется непосредственно в процессе разработки.
После окончания работ каждой отдельной команды разработчиков производится постепенная интеграция данной части системы с остальными, формируется полный программный код, выполняется тестирование совместной работы данной части приложения с остальными, а затем тестирование системы в целом. Завершается физическое проектирование системы:
определяется необходимость распределения данных;
производится анализ использования данных;
производится физическое проектирование базы данных;
определяются требования к аппаратным ресурсам;
определяются способы увеличения производительности;
завершается разработка документации проекта.
Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.
На фазе внедрения производится обучение пользователей, организационные изменения и параллельно с внедрением новой системы осуществляется работа с существующей системой (до полного внедрения новой). Так как фаза построения достаточно непродолжительна, планирование и подготовка к внедрению должны начинаться заранее, как правило, на этапе проектирования системы. Приведенная схема разработки ИС не является абсолютной. Возможны различные варианты, зависящие, например, от начальных условий, в которых ведется разработка: разрабатывается совершенно новая система; уже было проведено обследование предприятия и существует модель его деятельности; на предприятии уже существует некоторая ИС, которая может быть использована в качестве начального прототипа или должна быть интегрирована с разрабатываемой.
Методология RAD, как и любая другая, не может претендовать на универсальность, она хороша в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Если же разрабатывается типовая система, которая не является законченным продуктом, а представляет собой комплекс типовых компонент, централизованно сопровождаемых, адаптируемых к программно-техническим платформам, СУБД, средствам телекоммуникации, организационно-экономическим особенностям объектов внедрения и интегрируемых с существующими разработками, на первый план выступают такие показатели проекта, как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Для таких проектов необходимы высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки.
Методология RAD неприменима для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т.е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода.
Не подходят для разработки по методологии RAD приложения, в которых отсутствует ярко выраженная интерфейсная часть, наглядно определяющая логику работы системы (например, приложения реального времени) и приложения, от которых зависит безопасность людей (например, управление самолетом или атомной электростанцией), так как итеративный подход предполагает, что первые несколько версий наверняка не будут полностью работоспособны, что в данном случае исключается.
Оценка размера приложений производится на основе так называемых функциональных элементов (экраны, сообщения, отчеты, файлы и т.п.) Подобная метрика не зависит от языка программирования, на котором ведется разработка. Размер приложения, которое может быть выполнено по методологии RAD, для хорошо отлаженной среды разработки ИС с максимальным повторным использованием программных компонентов, определяется следующим образом:
|
< 1000 функциональных элементов |
один человек |
|
1000-4000 функциональных элементов |
одна команда разработчиков |
|
> 4000 функциональных элементов |
4000 функциональных элементов на одну команду разработчиков |
Основные принципы методологии RAD:
разработка приложений итерациями;
необязательность полного завершения работ на каждом из этапов жизненного цикла;
обязательное вовлечение пользователей в процесс разработки ИС;
необходимое применение CASE-средств, обеспечивающих целостность проекта;
применение средств управления конфигурацией, облегчающих внесение изменений в проект и сопровождение готовой системы;
необходимое использование генераторов кода;
использование метода прототипов, позволяющее полнее выяснить и удовлетворить потребности конечного пользователя;
тестирование и развитие проекта, осуществляемые одновременно с разработкой;
ведение разработки немногочисленной хорошо управляемой командой профессионалов;
грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ.
Залючение
Таким образом, при проектировании сложной ИС она разделяется на части, и каждая из них затем исследуется и создается отдельно. В настоящее время используются два различных способа такого разбиения ИС на подсистемы: структурное (или функциональное) разбиение и объектная (компонентная) декомпозиция.
С позиций проектирования ИС суть функционального разбиения может быть выражена известной формулой: "Программа = Данные + Алгоритмы". При функциональной декомпозиции программной системы ее структура описывается блок-схемами, узлы которых представляют собой "обрабатывающие центры" (функции), а связи между узлами описывают движение данных.
При объектном разбиении в системе выделяются "активные сущности" – объекты (или компоненты), которые взаимодействуют друг с другом, обмениваясь сообщениями и выполняя соответствующие функции (методы) объекта.
Если при проектировании ИС разбивается на объекты, то для ее визуального моделирования следует использовать UML. Если в основу проектирования положена функциональная декомпозиция ИС, то UML не нужен и следует использовать структурные нотации.
В то же время, при выборе подхода к разработке ИС следует учитывать, что визуальные модели все более широко используются в существующих технологиях управления проектированием систем, сложность, масштабы и функциональность которых постоянно возрастают. Они хорошо приспособлены для решения таких часто возникающих при создании систем задач как: физическое перераспределение вычислений и данных, обеспечение параллелизма вычислений, репликация БД, обеспечение безопасности доступа к ИС, оптимизация балансировки нагрузки ИС, устойчивость к сбоям и т.п. Визуализированные средствами UML модели ИС позволяют наладить плодотворное взаимодействие между заказчиками, пользователями и командой разработчиков. Они обеспечивают ясность представления выбранных архитектурных решений и позволяют понять разрабатываемую систему во всей ее полноте.
Список литературных источников
Автоматизированные информационные технологии в экономике. Учебник /М.И. Семенов, И.Т. Трубилин, В.И. Лайко, Т.П. Барановска; Под общ. Ред. И.Т. Трубилина. – М.: Финансы и статистика, 2000. – 416 с.
Автоматизированные информационные технологии в экономике. Учебник. / Под ред. Проф. Титоренко Г.А. – М.: ЮНИТН, 1998.
Базин И.И. Информационные системы в менеджменте. _ М.:ГУВШЭ, 2000.
Бэрри Нанс. Компьютерные сети: Пер. с англ. – М.: БИНОМ, 1995. –400с.
Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – М.: Финансы и статистика, 2000.- 352с.
Гиго С.М. Проектирование и использование баз данных». – М.: Финансы и статистика, 1995.
ГОСТ 34.201-89. Информационные технологии. Комплекс стандартов на АС. Виды, комплектность и обозначения документов при создании АС.
ГОСТ 34.601-90. Информационные технологии АС. Стадии создания.
Диго С.М. Проектирование и использование БД. – М.: Финансы и статистика, 1995.
Евдокимов В.В. и др. Экономическая информатика. Учебник для ВУЗов. Под ред. д.э.н., проф. В.В. Евдокимова, - СПб.: Питер, 1997. – 592с.
Информационные системы в экономике: Учебник/ Под ред. проф. В.В. Дика. – М.: Финансы и статистика, 1996. –292с.
Информационная технология. Комплекс стандартов на автоматизированные системы. ГОСТ 34.201-89, ГОСТ 34.602-89, ГОСТ 34.003-90, РД 50-34.698-90.
ISO2382-20:1990. Информационные технологии. Словарь. Часть20. Разработка системы.
ISO/IEC2382-23. Информационные технологии. Словарь. Часть 23. Обработка текста.
ISO/IECTR9294:1990. Информационная технология. Руководящие положения по управлению документацией на программное обеспечение.
Калянов Г.Н. Современные CASE– технологии. М.: ИПУ, 1992.
Калянов Г.Н. CASEструктурный системный анализ (автоматизация и применение). – М.: Изд-во «ЛОРИ», 1996. –242с.
Карминский А.М., Нестеров П.В. Информатизация бизнеса. / М.: Экономика, 1997.
Колесник А.П. Компьютерные системы в управлении финансами. – М.: Финансы и статистика. 1995.
Компьютерные сети. Учебный курс/ пер. с англ.– М.: Издательский отдел «Русская редакция», 1997.
Копылов В.И. Информационное право. – М.: Финансы и статистика, 1997.
Крылова Г.Д. Основы стандартизации, сертификации, метрологии. – М.: Издательство стандартов, 1998. – 596с.
Лихачёва Г.Н. Информационные технологии в экономике. УПП. – М.: МЭСИ, 2000.
Маклаков С.В. BpwinиErwin.CASE-средства разработки информационных систем. – М.: ДИАЛОГ-МИФИ, 1999. – 256 с.
Мишенин А.И. Теория экономических информационных систем. Учебник. – М. - Финансы и статистика, 1997.
Моррис С. Объектно-ориентированное проектирование / Под ред. Б.Г. Сидеева – Ростов-на-Дону: ФЕНИКС, 1997.
ПР 50-733-93 «Основные положения Единой системы классификации и кодирования технико-экономической и социальной информации и унифицированных систем документации РФ».
ПР 50-734-93 «Порядок разработки общероссийских классификаторов технико-экономической и социальной информации».
ПР 50-735-93 «Положение о ведении общероссийских классификаторов на базе информационно-вычислительной сети Госкомстата России».
Савельев М.В. Автоматизация проектирования вычислительных систем. Учеб. пособие / НГТУ – Новочеркасск, 1997. – 50с.
Смирнова Г.Н. и др. Проектирование экономических информационных систем: Учебник /Г.Н. Смирнова, А.А. Сорокин, Ю.Ф. Тельнов; Под ред. Ю.Ф. Тельнова. – М.: Финансы и статистика, 2001. – 512 с.
Тельнов Ю.Ф. Интеллектуальные информационные системы в экономике.: Учеб. Пособие (2-е изд), СИНТЕТ, 1999. – 214 с.
Экономика, разработка и использование программного обеспечения ЭВМ: Учебник/ В.А. Благодатских, М. А. Енгибарян, Е.В. Ковальская и др. – М.: Финансы и статистика, 1995. – 288с.
http://www.intuit.ru/