63419

ИСПОЛЬЗОВАНИЕ CASE–ТЕХНОЛОГИЙ ДЛЯ ПРОЕКТИРОВАНИЯ БД

Лекция

Информатика, кибернетика и программирование

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

Русский

2014-06-20

630 KB

16 чел.

PAGE  188

IX. ИСПОЛЬЗОВАНИЕ CASE – ТЕХНОЛОГИЙ ДЛЯ ПРОЕКТИРОВАНИЯ БД

Обоснование необходимости использования Case средств

Состав, структура и функциональные особенности Case средств

Классификация Case средств

Обзор современных средств

Анализ систем

Методика проектирования БД с помощью Case

Создание диаграмм прецедентов

1. Обоснование необходимости использования Case-средств

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

неадекватная спецификация требований;

неспособность обнаруживать ошибки в проектных решениях;

низкое качество документации, снижающее эксплуатационные качества системы;

затяжной цикл и неудовлетворительные результаты тестирования системы.

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

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

CASE (Computer Aided Software Engineering) - технология представляет собой методологию проектирования ИС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей.

CASE-средства представляют собой программные средства, поддерживающие процессы создания и/или сопровождения ИС, такие как: анализ и формулировка требований, проектирование баз данных и приложений, генерация кода, тестирование, обеспечение качества, управление конфигурацией и проектом. То есть использование case-технологий охватывает весь процесс разработки ИС в целом [1].

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

а)                                                                   б)

Рисунок 1 - Модели жизненного цикла создания БД

а) без использования б) с использованием CASE

Таблица 1 - Оценка трудозатрат при различных способах разработки БД

Способ разработки

Анализ

Проектирование

Кодирование

Тестирование

Традиционная разработка

20%

15%

20%

45%

Использование case-технологий

40%

40%

5%

15%

Таблица 2 - Преимущества традиционной разработки и с помощью case-средств

Традиционная разработка

Разработка с помощью case

Основные усилия на кодирование и тестирование

Основные усилия на анализ и проектирование

“Бумажные” спецификации

Быстрое итеративное прототипирование

Ручное кодирование

Автоматическая кодогенерация

Ручное документирование

Автоматическая генерация документации

Тестирование кодов

Автоматический контроль проекта

Сопровождение кодов

Сопровождение спецификаций проектирования

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

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

При проектировании БД на основе case технологии используется спиральный цикл создания системы, рис.2. При неполном завершении работ на каждом этапе разработки переходим на следующий этап, не дожидаясь полного завершения работы на текущем этапе. При итеративном способе разработки недостающую работу выполняем на следующей итерации. Главная же задача ставится так - как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла [4].

Рисунок 2 - Спиральная модель жизненного цикла ИС [2]

Можно перечислить следующие факторы, усложняющие определение возможного эффекта от использования case-средств:

  •  широкое разнообразие качества и возможностей case-средств;
  •  относительно небольшое время использования case-средств в различных организациях и недостаток опыта их применения;
  •  широкое разнообразие в практике внедрения различных организаций;
  •  отсутствие детальных метрик и данных для уже выполненных и текущих проектов;
  •  широкий диапазон предметных областей проектов;
  •  различная степень интеграции case-средств в различных проектах.

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

Среди наиболее важных проблем использования case - технологии можно выделить следующие:

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

2 Состав, структура и функциональные особенности case-средств

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

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

Можно выделить следующие задачи, которые решаются с помощью case-средств:

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

  •  Проектирование (для уровня представления или реализации).
  •  Системное моделирование - использовать исполняемые модели (имитационное моделирование), чтобы помочь справиться со сложностями и рисками, а также повысить взаимодействие и взаимопонимание в командах.
  •  Качество - сосредоточиться на достижении качества уже на стадии дизайна, нежели надеяться только лишь на тестирование и испытания.
  •  Глобальное взаимодействие в реальном времени  - обеспечить объединение и взаимодействие распределенных команд.
  •  Моделирование БД для конкретной СУБД.
  •  Документирование БД.

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

  •  человеческий фактор, определяющий разработку БД как легкий, удобный и экономичный процесс;
  •  широкое использование базовых программных средств, получивших массовое распространение в других приложениях (СУБД, компиляторы с различных языков программирования, отладчики, документаторы, издательские системы, оболочки экспертных систем и др.);
  •  автоматизированная или автоматическая кодогенерация, выполняющая несколько видов генерации кодов: преобразование для получения документации, формирование БД, ввод/модификация данных, получение выполняемых машинных кодов из спецификаций программного обеспечения, автоматическая сборка модулей из словарей и моделей данных и повторно используемых программ, автоматическая конверсия ранее используемых файлов в форматы новых требований;
  •  ограничение сложности, позволяющее получать компоненты, поддающиеся управлению, обозримые и доступные для понимания, а также обладающие простой и ясной структурой;
  •  доступность для разных категорий пользователей;
  •  рентабельность;
  •  сопровождаемость, обеспечивающая способность адаптации при изменении требований и целей проекта.

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

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

Интегрированное case-средство (или комплекс средств, поддерживающих полный жизненный цикл БД) содержит следующие компоненты:

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

Интегрированный case-пакет содержит средства хранения, ввода, вывода и анализа.

Средства централизованного хранения всей информации о проектируемой БД в течение всего ЖЦ (репозитарий). Соответствующая БД должна иметь возможность поддерживать большую систему описаний и характеристик и предусматривать надежные меры по защите от ошибок и потерь информации. Репозитарий должен обеспечивать:

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

Средства ввода предназначены для ввода данных в репозитарий, а также для организации взаимодействия с case-пакетом. Эти средства должны поддерживать различные методологии и использоваться на всем ЖЦ разными категориями разработчиков: аналитиками, проектировщиками, инженерами, администраторами и т.д.

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

Средства вывода служат для документирования, управления проектами кодовой генерации.

3. Классификация case-средств

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

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

Вторую категорию составляют собственно средства проектирования БД, рассматриваемые в комплексе со средствами разработки приложений (например, Oracle Designer).

Классификация case-средств по типам отражает их функциональную ориентацию. Ниже дано рассмотрение case-средств на различных этапах проектирования БД.

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

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

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

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

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

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

  •  средства взаимодействия между разработчиками БД и приложений, иметь возможность распространять и обновлять как логические, так и физические модели данных в реальном времени;
    •  управление ЖЦ данных и приложений (разработчики БД должны проводить сквозное моделирование данных, чтобы обеспечить соответствие между новыми и уже существующими моделями данных во всех БД предприятия, независимо от того находятся ли они в стадии разработки или уже используются);
    •  средства поддержки модели, которая выходит за пределы структурированных данных.

Анализ систем

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

Таблица 3 - Наиболее популярные средства проектирования данных

CASE – средство

Производитель

URL

Designer 2000

Oracle

http://www.oracle.com/

ERwin

Computer Associates

http://www.cai.com/

PowerDesigner

Sybase

http://www.sybase.com/

ER/Studio

Embarcadero

http://www.embarcadero.com/

System Architect

Popkin Software

http://www.popkin.com/

Visible Analyst

Visible Systems

http://www.visible.com

Visio Enterprise

Microsoft

http://www.microsoft.com/

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

  •  поддержка множества языков программирования;
  •  широкие возможности моделирования;
  •  возможность одновременного ведения нескольких проектов;
  •  возможность совместной разработки;
  •  поддержка стандарта визуальной нотации - языка UML (Unified Modeling Language), который с 1997 г. определен как стандарт языка для этой области инструментальных средств [2].

Rational Rose поддерживает:

  •  генерацию кода и реинжениринг для нескольких языков, включая  Visual Basic, C++, Java, Delphi, PowerBuilder, Data Definition Language для большинства СУБД;
  •  визуальное моделирование, полностью совместимое с UML;
  •  драйверы, создаваемые многочисленными независимыми разработчиками инструментальных средств.

Базу инструментальной среды Designer+Developer Oracle составляют:

  •  методология структурного нисходящего проектирования;
  •  поддержка всех этапов жизненного цикла прикладной системы, начиная с самых общих описаний предметной области до получения и сопровождения готового программного продукта;
  •  ориентация на реализацию серверных приложений с использованием всех особенностей современных серверов БД, включая декларативные ограничения целостности, хранимые процедуры, триггеры БД, с поддержкой в клиентской части всех современных стандартов и требований к графическому интерфейсу конечного пользователя;
  •  наличие репозитария, для хранения спецификаций проекта по созданию БД на всех этапах ее разработки;
  •  возможность одновременной работы с репозитарием многих пользователей на основе средств СУБД Oracle (централизованное хранение проекта системы и управление одновременным доступом к нему всех участников разработки поддерживают согласованность действий разработчиков и не допускают ситуацию, когда каждый проектировщик или программист работает со своей версией проекта и модифицирует ее независимо от других);
  •  автоматизация последовательного перехода от одного этапа разработки к следующему;
  •  автоматизация стандартных действий по проектированию и реализации приложения: (генерация отчетов по содержимому репозитария, обеспечивающих документирование системы на всех этапах ее разработки; возможность проверки спецификаций на полноту и непротиворечивость и т.д.).

Генератор серверной части автоматически строит по спецификациям БД тексты программ на языке SQL, используя все средства определения БД, включая триггеры, хранимые процедуры и т.д. Генераторы клиентской части обеспечивают автоматическое формирование текстов программных модулей по их спецификациям, записанным в репозитарии. Все модули приложения классифицируются по типам, основными из которых являются экранные формы, отчеты, процедуры. Для каждого типа имеется свой генератор, результатом работы которого является программа, написанная на языке, соответствующем этому типу: генератор форм создает приложения для Oracle Forms, генератор отчетов позволяет получать процедуры на PL/SQL либо приложения для Oracle Report.

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

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

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

Case PowerDesigner (Sybase) служит для разработки структуры БД и генерации ее в целевой системе. Здесь предоставляются возможности работы в терминах объектно-ориентированной, концептуальной или физической моделей. Пользовательская рабочая среда отображается в виде иерархии объектов, таких как модель, отчет, пакет, внешние документы и т.д. PowerDesigner реализует следующие возможности:

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

Case ERwin представляет собой средство концептуального моделирования БД, реализует функции проектирования схемы БД, генерацию ее описания на языке целевой СУБД (ORACLE, Ingres, Sybase, DB/2, Microsoft SQL Server и др.) и реинжиниринг существующей БД. Версия ERwin/OPEN полностью совместима со средствами разработки приложений PowerBuilder и SQLWindows и позволяет экспортировать описание спроектированной БД непосредственно в репозитории данных средств. Для ряда средств разработки приложений (PowerBuilder, SQLWindows, Delphi, Visual Basic) выполняется генерация форм и прототипов приложений.

Семейство продуктов ERWin предназначено для моделирования и создания БД произвольной сложности. В настоящее время ERWin является наиболее популярным пакетом моделирования данных благодаря поддержке широкого спектра СУБД самых различных классов: SQL-серверов (Oracle, Sybase,  MS SQL Server, DB2, Ingress и др.) и “настольных” СУБД dBASE, FoxPro, MS Access и др.). ERwin Data Modeling Suite предоставляет расширенную поддержку СУБД Teradata, SQL Server 2008 и DB2 z/OS v.9, возможности обмена метаданными с инструментами управления данными Oracle Business Intelligence.

Информационная модель представляется в виде диаграмм “сущность-связь”, отражающих основные объекты предметной области и связи между ними. Дополнительно определяются атрибуты сущностей, характеристики связей, индексы и бизнес-правила, описывающие ограничения и закономерности предметной области. После создания ER-диаграммы пакет автоматически генерирует SQL-код для создания таблиц, индексов и других объектов БД. По заданным бизнес-правилам формируются стандартные триггеры БД для поддержки целостности данных, для сложных бизнес-правил можно создавать собственные триггеры, используя библиотеку шаблонов.

Пакет может осуществлять реинжиниринг существующих БД: по SQL-текстам автоматически генерируются ER-диаграммы. Пакет поддерживает выполнение последовательности следующих функций:

  •  импорт с сервера существующей БД;
  •  автоматическая генерация модели БД;
  •  модификация модели;
  •  автоматическая генерация новой схемы и построение физической БД на том же самом или любом другом сервере.

Для разработки клиентской части приложения имеются специальные версии пакета, обеспечивающие интеграцию с такими инструментами как SQLWindows, PowerBuilder, Visual Basic, Delphi.

Для коллективной разработки модели БД предназначен специальный продукт ModelMart, позволяющий контролировать версии модели, гибко распределять права доступа между членами группы, строить библиотеки моделей, осуществлять объединение моделей и т.п. Erwin версии 7.3 позволяет архитекторам данных осуществлять межсистемный анализ, обеспечивая интеграцию с моделями данных, платформами бизнес-аналитики, хранилищами данных, унаследованным и разрабатываемым программным обеспечением. Версия пакета для моделирования и анализа данных ERwin Data Modeling Suite снабжена технологией профилирования данных, что делает продукт центром в управлении в организациях.

В новом решении CA ERwin® Data Modeling Suite компания CA сделала возможным объединение моделирования данных с другими инструментами. Пакет CA ERwin® Data Modeler включает следующие возможности:

• создание отчетов о графической информации в самых популярных форматах (электронная таблица, PDF, HTML и т. д.);

• доступность и совместное использование всей имеющейся в компании информации, используя широкий набор инструментов и интерфейсов для составления отчетов;

• обмен критически важной деловой и технической информацией с популярными системами управления данными, такими как Oracle®, Cognos®, SAP NetWeaver® и другими;

• поддержку СУБД Teradata®, SQL Server® 2008 и DB2®, что позволяет оптимизировать процессы анализа и проектирования БД;

• упорядоченную разработку и развертывание промышленных приложений на базе СУБД SQL Server для операционных систем Windows XP, Windows 2003 Server и Windows Vista;

• для аналитиков выборочно открывать, документировать и заново использовать ERP-метаданные, чтобы упростить многочисленные бизнес-данные, а также управление данными, приложениями и руководство инициативами;

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

SoDA (Software Documentation Automation) - разработка компании Rational Software Corporation (http://www.rational.com) значительно упрощающая процесс создания проектной документации и поддержания ее в течение всего цикла разработки БД. SoDA, по существу, представляет собой макрос, написанный для MS Word и особенно полезный при реализации крупных информационных проектов, в которых на составление документации и ее постоянную переработку обычно тратится очень много времени и сил разработчиков. SoDA поддерживает всю линейку продуктов Rational Software, позволяя создавать сложные комбинированные отчеты на основе выходных данных программ состава Rational Suite. SoDA имеет доступ к данным из Microsoft Project. Основные возможности системы включают [3]:

  •  автоматическое извлечение информации из файлов, созданных различными инструментальными средствами. SoDA "понимает" структуру информации, хранимой теми системами, с которыми она интегрирована, а сама информация доступна ей через API этих систем;
  •  сохранение при "перекомпиляции" текста и графики, введенных пользователем вручную в текстовом редакторе Microsoft Word;
  •  настройка шаблонов, по которым генерируется документация, соответствующие всевозможным внешним или внутренним стандартам компании;
  •  синхронизация с источниками и проверка актуальности документации. SoDA может отслеживать изменения, происходящие с источниками, на основе которых была в последний раз "скомпилирована" документация, а во-вторых, пользователь может из любой секции документа быстро получить доступ к источникам, информация из которых используется в этой секции;
  •  частичная "перекомпиляция" больших документов;
  •  сбор информации из многочисленных и разнородных источников;
  •  документирование всех этапов работы над проектом;
  •  проверка соблюдения требований, предъявляемых к разрабатываемой системе. SoDA позволяет сформировать таблицы, из которых можно понять, насколько полученные результаты соответствуют требованиям, определенным на начальных этапах проектирования;
  •  поддержка русифицированных шаблонов и отчетов.

ER/Studio (Embarcadero Technologies, http://www.embarcadero.com/products/Design/erdatasheet.htm). По своему назначению этот продукт сходен с ERwin — он представляет собой специализированное средство проектирования БД и не содержит в своем составе инструментов для объектно-ориентированного моделирования или моделирования бизнес-процессов. Список поддерживаемых СУБД у этого продукта достаточно широк и включает все наиболее популярные серверные и настольные СУБД.

ER/Studio поддерживает написание макросов. Этот язык позволяет создавать макросы для выполнения однотипных операций, например добавления стандартных полей к вновь создаваемым сущностям. С помощью этого же языка можно генерировать стандартные триггеры и хранимые процедуры для вставки, удаления, изменения записей. Код на этом языке можно отлаживать и обращаться к свойствам сущностей для конструирования серверного кода. Однако, в отличие от ERwin, ER/Studio не позволяет добавить к каждой таблице свои шаблоны триггеров или просмотреть код конкретного триггера в процессе разработки модели — чтобы получить код одного триггера, нужно сгенерировать скрипт для всей модели.

Модели ER/Studio можно сохранить не только в виде DDL-скрипта, но и в формате XML. Можно также создать репозитарий для их хранения в любой серверной СУБД. ER/Studio может импортировать модели ERwin, но при импорте теряются связи шаблонов серверного кода с конкретными таблицами, и не все макросы ERwin корректно преобразуются в макросы. ER/Studio позволяет сгенерировать Java-классы для клиентских приложений.

System Architect (Popkin Software, http://www.popkin.com/products/sa2001/data/data.htm) представляет собой универсальное CASE-средство, позволяющее осуществить не только проектирование данных, но и структурное моделирование. Средство проектирования БД и создания ER-диаграмм является одной из составных частей этого продукта. Продукт поддерживает СУБД практически всех ведущих производителей, включая Oracle, Sybase, DB2, SQL Server, Informix, Sybase, Access, dBASE, Paradox и др.

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

Модели System Architect, как и в случае других CASE-средств, можно сохранять в репозитарии. Однако в отличие от традиционных репозитариев, обладающих более или менее стандартной структурой хранимых данных, репозитарий System Architect является настраиваемым — к сохраняемым объектам можно добавлять дополнительные свойства, определенные пользователем. System Architect обладает встроенным Visual Basic for Application, что позволяет создавать разнообразные решения на базе этого продукта, включая автоматическую генерацию моделей и проектной документации. System Architect позволяет генерировать код клиентских приложений для Visual Basic, Delphi и PowerBuilder, классы C++, а также код и текстовые экранные формы COBOL.

Visible Analyst (Visible Systems Corporation, http://www.visible.com/dataapp/daprods.html) выпускается в трех редакциях: Visible Analyst DB Engineer, который включает средства проектирования данных; Visible Analyst Standard, который кроме проектирования данных позволяет осуществлять структурное моделирование; Visible Analyst Corporate, который помимо указанных выше возможностей позволяет осуществлять также объектно-ориентированное моделирование. Visible Analyst поддерживает широкий спектр СУБД с точки зрения генерации серверного кода, включая Oracle 7, Sybase SQL Server; Informix, DB2, Ingres. Для Informix и DB2 позволяет генерировать DDL-скрипты, учитывающие специфические особенности организации физической памяти наиболее популярных серверных СУБД, такие как управление табличным пространством, размером экстентов, режимами блокировки данных, степенью заполнения данными, а также создавать кластеризованные индексы и генерировать триггеры для выполнения стандартных операций. Из этих же СУБД можно производить непосредственно обратное проектирование. Помимо этих двух СУБД обратное проектирование можно производить также из DDL-скриптов, сгенерированных для других СУБД, а также на основе кода языка COBOL. Visible Analyst позволяет на основе созданных моделей генерировать код для языков Visual Basic, С++ и COBOL.

Visio Enterprise (Microsoft, http://www.microsoft.com/office/visio/) содержит в своем составе полноценное case-средство, позволяет производить прямое и обратное проектирование БД, преобразовывать логическую модель в физическую. Этим средством поддерживаются драйверы ODBC и OLE DB-источники данных. С его помощью можно создавать триггеры для стандартной обработки нарушений ссылочной целостности в случае, если DDL-скрипт создается для Microsoft SQL Server, и серверные ограничения, если скрипт создается для другой СУБД. Visio при генерации скриптов позволяет указывать параметры организации физической памяти Oracle, Informix, Microsoft SQL Server, DB2 и некоторых других СУБД. Visio, в отличие от специализированных средств проектирования данных, не обладает скриптовым языком, позволяющим создавать серверный код, не связанный с конкретной СУБД. При использовании этого продукта такой код нужно создавать на этапе физического проектирования в уже созданном скрипте. Этот продукт является сервером автоматизации, обладает весьма обширной объектной моделью и встроенным средством разработки — Visual Basic for Applications, что позволяет, в частности, создавать на его базе разнообразные решения, в том числе и автоматизировать разработку моделей данных.

fabFORCE.net DBDesigner (www.fabforce.net/dbdesigner4) - Open Soucre программа, представляющая собой удобную визуальную среду проектирования БД и сочетающий профессиональные возможности с простым и ясным интерфейсом. Программа распространяется по лицензии GRL и способна работать под Linux Gnome/KDE и Microsoft Windows 2K/XP. Программа оптимизирована под другой Open Source продукт MySQL и называется MySQL Workbench (http://www.varvashenia.ru/ru/software/DBDesigner4/).

DBDESIGNER - это свободно распространяемая CASE-система, предназначенная для проектирования, моделирования, создания и поддержки информационных систем. Программа может использоваться для Windows 2000/XP, Linux KDE/Gnome и MySQL. DBDesigner позволяет:

  •  создавать модель проектируемой системы;
  •  преобразовывать модели системы в SQL-код, который можно использовать для создания базы данных с помощью DBDesigner или другого средства;
  •  проводить реинжиниринг - построение исходной модели программной системы путем исследования ее программных кодов. Эта функция очень удобна в случае, если необходимо разобраться уже существующей базе данных. Для проведения реинжиниринга следует выбрать в меню Database - Revers Engineering;
  •  создавать базу данных и автоматически вносить в нее изменения, используя соединение с сервером и синхронизацию;
  •  создавать SQL-запросы для внесения изменений и проведения операций над данными.

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

Анализ case-средств, приведенных в табл.4, показывает, что каждый из этих продуктов сам по себе является одним из наиболее мощных в своем классе.

Таблица 4 - Характеристики систем проектирования

Характеристики

West-mount I-СASE + Uniface

Rational Rose

Designer/2000
Developer/2000

SILVERRUN + JAM

Power
Designer

Поддержка полного цикла разработки ИС

+

+

+

+

-

Обеспечение целостности проекта

+

+

+

-

-

Целевые форматы

ORACLE, Informix, Sybase, Ingres, СУБД с dbf-форматом

ORACLE, Informix, MS SQL и др.

ORACLE

ORACLE, Informix, Sybase, Ingres и др.

ORACLE, Informix, Sybase, поддержка ODBC

Платформы

Большинство платформ UNIX. Windows планируется в версии 4.0

Windows

Windows

Windows, OS/2, Macintosh Solaris

Windows

Одновременная групповая разработка БД и приложений

+

+

Работа с базой данных только после завершения ее проектирования

CASE-средства используются для:

  •  анализа, построения и моделирования предметной области (case -Design/IDEF; BPwin, Logic Works);
  •  анализа и проектирования на основе наиболее распространенных методологий проектирования и создания проектных спецификаций компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных (case -Vantage Team Builder, Designer ORACLE; Silverrun);
  •  проектирования БД, обеспечивая моделирование данных и генерацию схем БД для наиболее распространенных СУБД (case - Erwin, S-Designor, DataBase Designer, Designer Oracle, Silverrun);
  •  разработки приложений для PowerBuilder, Sybase; Developer ORACLE; Informix; MS SQL;
  •  реинжиниринга, обеспечивающего анализ программных кодов и схем БД и формирование на их основе различных моделей и проектных спецификаций (case - Silverrun, Designer 2000, ERwin, S-Designor);
  •  планирования и управления проектом (SE Companion, Microsoft Project и др.);
  •  конфигурационного управления (PVCS, Intersolv);
  •  тестирования (Quality Works, Segue Software);
  •  документирования (SoDA, Rational Software).

Методика проектирования БД с помощью Case

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

Абстрагирование – это процесс упрощения и игнорирования деталей, не имеющих отношения к целостному пониманию системы на некотором уровне.

Спецификация – это описание свойств и поведения системы.

Процесс создания БД состоит из исследования и построения БД.

Исследование предметной области включает планирование и построение БД.

Планирование БД включает:

  •  разработку приблизительного плана создания БД;
  •  создание предварительного отчета об исследованиях;
  •  определение требований;
  •  запись терминов в словарь;
  •  реализация прототипа;
  •  определение основных прецедентов высокого уровня;
  •  определение приблизительной концептуальной модели;
  •  определение приблизительной архитектуры системы;
  •  уточнение плана.

Построение БД включает анализ, проектирование и конструирование.

Анализ включает:

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

Проектирование включает:

  •  определение реальных прецедентов;
  •  создание отчетов и интерфейсов пользователей;
  •  уточнение архитектуры системы;
  •  построение диаграмм классов;
  •  определение структуры БД.

Конструирование включает:

  •  реализацию классов и интерфейсов, методов, графических элементов интерфейса, отчетов, схемы БД;
  •  написание тестовых кодов.

Проектирование на основе Case включает определение функций, прецедентов и их диаграмм, описание концептуальной модели.

В соответствии с выявленными целями создания БД (получение прибыли, повышение уровня автоматизации в организации) определяются функции системы, табл.5.

Таблица 5 - Функции системы

Функции

Категории

Ввод данных

Очевидная

Вычисление статистических характеристик

Скрытая

Регистрация пользователей

Скрытая

Поддержка актуальности БД

Очевидная

Анализ ситуации

Скрытая

Выдача рекомендаций

Дополнительная

Критерии выполнения функций (табл.6) - характеристики системы: простота в использовании, отказоустойчивость (24 часа бесперебойной работы), время отклика, стиль интерфейса (графический), стоимость, используемая платформа (Windows, Linux, др.).

Таблица 6 - Функции и критерии их выполнения

Функция

Категория

Критерий

Значение, ограничения

Категория

Регистрация пользователей

Обязательная

Время отклика

5сек

Обязательная

Ввод данных

Обязательная

Опоздание для ввода новых данных

2 часа

Обязательная

Вычисление статистических характеристик

Обязательная

Опоздание для расчета

2 дня после окончания месяца

Обязательная

Регистрация пользователей

Обязательная

Опоздание с регистрацией

1 день

Обязательная

Поддержка актуальности БД

Обязательная

Опоздание с загрузкой новых порций данных

1 час

Обязательная

Выдача рекомендаций

Не обязательная

Опоздание по реагированию на ситуацию

10 мин после загрузки

Обязательная

После выявления функций системы необходимо:

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

Для определения прецедентов:

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

Процесс разработки, основанный на анализе прецедентов, обладает следующими преимуществами:

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

Таблица 7 Пример описания прецедентов

Свойства прецедента

Описание

Название прецедента

Регистрация пользователей

Исполнители

Пользователь, администратор, менеджер

Тип

Главный, вспомогательный

Описание

Пользователь входит в БД ……

Цель

Ведение регистра пользователей и платежей за услуги

Функции

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

Таблица 8 - Ход событий по прецеденту

Действия пользователя

Отклик системы

  1.  Пользователь входит в БД
  1.  Приглашение к регистрации
  1.  Пользователь регистрируется (вводит имя и пароль)

2.    Проверяется правильность ввода имени и пароля

  1.  В случае правильного ввода система выдает список услуг
  2.  В противном случае система выдает сообщение "пароль не совпадает" и предлагает повторить ввод имени и пароля до 3 раз, после третьего раза происходит разрыв связи с пользователем
  1.  Пользователь работает (вводит данные, осуществляет поиск, др.)

5.   Проверяется правильность ввода данных, если есть ошибка, то выдается сообщение («Дата записана неверно»), в противном случае данные записывают в БД

6.   Осуществляется поиск в БД

7.   Система выдает данные, если данные не найдены, то выдается сообщение «Для указанных критериев запроса данные отсутствуют»

Для описания событий по созданию БД можно использовать сетевой график создания БД, который представлен на рис.3, а технологические этапы и операции сбора, обработки и распространения данных - в табл.9.

Рисунок 3 - Сетевой график создания БД

Обозначения:

1. Исследование информационных потребностей и обследование потребителей

2.Выбор носителя для ввода данных

3.Разработка ТЗ на создание БД

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

5.Разработка технологии занесения данных на носитель

6.Разработка инструкции по занесению данных

7.Разработка ТЗ на программу первичной обработки, разработка алгоритмов и программ контроля данных

8.Опытное занесение данных

9.Опытная эксплуатация программ первичной обработки

10.Программирование

11.Сдача технологии занесения данных на носитель в эксплуатацию

12.Эксплуатация технологии

13.Эксплуатация БД

14.Разработка технологии занесения данных на носитель

15.Проверка записи данных на носителе путем получения справки о содержании

16.Исправление ошибок

17.Подготовка документации на БД

18.Экспертиза данных (рецензирование)

19.Архивация данных (акт сдачи)

Таблица 9 - Пример технологических этапов и операций сбора, обработки и распространения данных

Этапы

Выполняемые операции

Производство измерений (наблюдений)

Кодирование информации

Занесение данных на бумажный носитель в источнике данных

Высылка данных и носителей в центр сбора

Контроль данных

Заполнение таблиц

Проверка таблиц

Составление документации на передаваемые данные

Заполнение форм отчетности

Составление акта экспертизы

Пересылка данных в промежуточный центр сбора

Сбор данных в промежуточном источнике

Производство наблюдений, заполнение книжек и журналов наблюдений

Подготовка справочной информации, создание схемы данных

Занесение данных на технический носитель

Обработка данных на ЭВМ

Контроль и корректировка данных

Накопление данных

Прикладная обработка данных на месте

Комплектование данных на носителе

Копирование данных на сменный носитель для передачи в центр данных

Прием и контроль отчета в организации – владельце данных

Передача отчетных материалов в центр данных

Хранение

Каталогизация, копирование, контроль физического состояния

Обработка

Поиск, трансформация, прикладная обработка, передача, визуализация

Прогнозирование

Усвоение, моделирование

Поддержка решений

Реализация действий, объяснение, обучение

Создание диаграмм прецедентов

Прецеденты, участвующие в создании БД, представлены на рис.4, идентификация исполнителей и прецедентов дана в табл.10. Описания прецедентов "Оплата по кредитной карточке" и "Оплата по договору" даны в табл.11 и 12. Рекомендации по созданию диаграмм включают:

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

Рисунок 4 - Прецеденты БД

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

  •  СОБЫТИЕ в системе или ее внешнем окружении;
  •  СИГНАЛ к системе;
  •  ДЕЙСТВИЕ системы;
  •  ОТКЛИК от системы;
  •  ВЛИЯНИЕ на систему или ее окружение.

Например, в системе управления космическим кораблем прецедент может быть представлен как совокупность следующих компонент:

  •  СОБЫТИЕ - Диспетчер замечает, что корабль движется слишком быстро.
  •  СИГНАЛ - Замедлить скорость корабля на 210 м/сек.
  •  ДЕЙСТВИЕ - Определить какой из тормозных ракетных двигателей включить и на какое время.
  •  ОТКЛИК - Сигнал тормозному двигателю ракеты для его включения на 4.8 сек.
  •  ВЛИЯНИЕ - Корабль замедлил скорость до 210 м/сек.

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

  •  СОБЫТИЕ - Владелец дачи устал пилить и колоть дрова для камина и решил установить газовое отопление.
  •  СИГНАЛ - Информация о Владельце и его даче, а также дата начала обслуживания.
  •  ДЕЙСТВИЕ - Добавить данные о Владельце дачи в базу данных клиентов.
  •  ОТКЛИК - Разрешение на предоставление услуг.
  •  ВЛИЯНИЕ - В освободившееся от дровяных работ время Владелец дачи проектирует систему автоматизации газовой компании.

Рисунок 5 - Уточнение диаграммы авторизации

Диаграммы авторизации пользователей продемонстрированы на Рис.6.

Рисунок 6 - Диаграмма авторизации пользователей

Таблица 10 - Идентификация исполнителей и прецедентов

Исполнитель

Прецеденты

Ранг

Обоснование

Пользователь

Регистрация

Получение услуг

Высокий

Влияет на безопасность

Администратор

Разрешение (выдача пароля)

Минимальный

Влияет на безопасность

Система

Представление меню для регистрации

Представление меню для входа в систему

Проверка пароля

Предоставление перечня услуг

Отметка об обращении к услуге

Высокий

Влияет на развитие системы

Пользователь

Дает разрешение на оплату по:

- Кредитной карточке

- Хоздоговору

- Списанию за счет ранее внесенной суммы

Высокий

Влияет на прибыль

Таблица 11 - Описание прецедента "Оплата по кредитной карточке"

Действия пользователя

Отклик системы

Пользователь выбрал услуги

Система подсчитывает стоимость выбранных услуг и выдает на экран

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

Система генерирует запрос на оформление оплаты по кредитной карточке т и отправляет его во внешнюю службу авторизации кредитов

Служба авторизации кредитов авторизует оплату

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

Таблица 12 - Описание прецедента "Оплата по хоздоговору"

Действия пользователя

Отклик системы

Пользователь выбрал услуги

Система подсчитывает стоимость выбранных услуг и выдает на экран

Пользователь согласился со стоимостью

Система списывает со счета подсчитанную сумму

Пользователь не согласен со стоимостью

Система предлагает уточнить выбранные услуги

На рис.7 дан пример прецедента для проектирования Web портала.

Рисунок 7 - Прецедент Web портала - услуга
(пользователь выбирает, оплачивает и получает услугу)

Ранжирование прецедентов производится на основе следующих критериев, табл.13:

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

Таблица 13 - Ранжирование прецедентов

Прецедент

1

2

3

4

5

6

Сумма

Регистрация

5

3

2

0

5

3

18

Выполнение запросов

5

0

1

0

5

5

16

Оплата стоимости услуг

5

3

5

4

5

3

25

Концептуальная модель должна помочь выделить типовой ход событий при работе с БД:

  •  пользователь вводит критерии запроса;
  •  СУБД анализирует критерии, сравнивает со значениями в БД и выдает на экран;
  •  пользователь просматривает результаты и, если его они не удовлетворяют, то он уточняет критерии запроса.

На основе концептуальной модели можно описать системные операции по форме табл.14 и выделить предположения и упрощения для прецедентов, табл.15.

Таблица 14 - Описание системной операции

Характеристика операции

Описание

Имя

Имя операции и ее параметры (словесное описание обязанностей данной операции)

Обязанности

Ввести (записать) данные

Тип

Имя типа (понятие, программный класс, интерфейс) - системная

Ссылки

Ссылка на функции системы

Примечания

Использовать самый быстрый доступ к БД

Исключения

Исключительная операция (Если значение параметра выходит за допустимые пределы, то выдать сообщение об ошибке)

Вывод

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

Предусловия

Предельные значения параметров заранее известны системе

Постусловия

Декларируемся изменения состояния объектов концептуальной модели (создание или удаление экземпляров, модификация атрибута, формирование и разрыв ассоциаций)

Таблица 15 - Предположения и упрощения для прецедентов

Прецедент

Предположения и упрощения

Регистрация

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

Авторизация

Для каждого типа кредитной карточки задействована своя служба авторизации (банк, выдавший карточку)

Списание за счет ранее внесенных сумм

Поддерживается частичная оплата

Отметка об обращении

Сведения о всех запросах выполненных и невыполненных, регистрация в журнале

Перечень услуг

Сведения об услугах заносятся в отдельную таблицу

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

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

Заключение

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

Case продукты имеют сходные черты, в число которых входят:

  •  поддержка создания логических моделей, не зависящих от СУБД, и генерации физических моделей на их основе;
  •  поддержка нескольких типов СУБД, включая не только серверные, но и настольные;
  •  поддержка специфических особенностей тех или иных СУБД ведущих производителей (генерация триггеров, управление физическим хранением данных);
  •  способность осуществлять обратное проектирование на основе либо имеющейся БД;
  •  возможность генерации отчетов и проектной документации на основе созданной модели;
  •  возможность сохранения модели в репозитарии, который во многих случаях может быть разделяемым;
  •  поддержка генерации кода для одного или нескольких средств разработки или языков программирования.

Успешное внедрение CASE-средств обеспечивает такие выгоды как:

  •  высокий уровень технологической поддержки процессов разработки и сопровождения БД;
  •  положительное воздействие на производительность программных средств, качество продукции, соблюдение стандартов, документирование;
  •  позитивность отдачи от инвестиций в CASE-средства.

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

Тенденциями развития CASE-инструментов являются:

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

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

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

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

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

  •  предпочитайте простоту (не вводите дополнительные свойства объектов, не требующиеся сегодня, архитектурные, аналитические требования должны быть как можно более простыми и понятными для всех заинтересованных лиц, не перегружайте диаграмму излишними деталями);
  •  учитывайте изменения;
  •  обеспечивайте будущую работу (создавайте необходимую документацию по программному продукту и его поддержке);
  •  вносите изменения последовательно (сначала строите диаграмму высокого уровня и далее развивайте);
  •  привлекайте больше заинтересованных лиц – заказчиков, пользователей;
  •  обеспечьте быструю обратную связь с заказчиками, пользователями;
  •  знайте инструментальные средства создания БД;
  •  каждый участник разработки БД должен иметь возможность работать с case;
  •  тестируйте созданные модели данных;
  •  используйте стандарты именования для названий атрибутов, методов, отношений.
  •  обновлять модель данных нужно только при острой необходимости.

Список литературы

  1.  Вендров А.М. CASE - технологии. Современные методы и средства проектирования информационных систем. – М.: - Финансы и статистика, 1998. http://www.interface.ru/logworks/caset/glava4/glava4_1.htm 
  2.  Ларман Крэг. Применение UML и шаблонов проектирования: Введение в объектно - ориентированный анализ и проектирование. - М. - Санкт-Петербург- Киев. 2001. - Издательский дом "Вильямс. - 496 с.
  3.  Новичков А. Система генерации проектной документации Rational SoDA // Журнал «КомпьютерПресс». 2001. № 10. www.compress.ru
  4.  Федоров А., Елманова Н. Средства проектирования данных // Журнал «КомпьютерПресс». 2001. - № 1.

Перечень вопросов для самопроверки

  1.  Какие case-средства Вы знаете?
  2.  Составьте список процессов, происходящих при создании БД
  3.  Какие события и операции происходят в подсистеме создания БД?
  4.  Что делают системные операции в подсистеме выполнения запросов?
  5.  Когда использование CASE-систем и технологий эффективно? Как это связано со способом получения прикладного программного обеспечения на предприятии - покупкой готового пакета или заказной разработкой?

PAGE  1


EMBED Word.Picture.8  

EMBED Word.Picture.8  

EMBED Word.Picture.8  

EMBED Word.Picture.8  

EMBED Word.Picture.8  

EMBED Word.Picture.8

Анализ

Проектирование

Кодирование

Тестирование

Прототипирование

Сопровождение

Проектирование спецификаций

Контроль проекта

Кодогенерация

Системное тестирование

опровождение


 

А также другие работы, которые могут Вас заинтересовать

31397. Мониторинг страховых случаев без учета ущерба 62.79 KB
  Цель задачи: Осуществить мониторинг всех страховых случаев объектам страхования и расчет стоимости ущерба. Дано: Сводная таблица выданных полюсов страхования Заявление на страховой случай Справочник клиентов. Требуется: Определить расчет ущерба по объекту страхования Организационноэкономическая сущность: Данная задача состоит в том чтоб собрать всю информацию по страховым случаям в одну таблицу для дальнейшего анализа. Периодичность и область применения: Ведомость расчета ущерба по объекту страхования на момент запроса составляется...
31398. Алгоритм 25.04 KB
  Алгоритм, алгорифм (ағылшынша: algorіthm, algorіsmus Әл-Хорезмидің атынан шыққан) - бастапқы берілген мәліметтермен бір мәнде анықталатын нәтиже алу үшін қай амалды (жұмысты) қандай ретпен орындау қажеттігін белгілейтін есептерді
31399. Учет заявок на страхование 62.02 KB
  Дано: Справочник страховщиков Заявка от клиента. Для обновления такого рода информации нам потребуются следующие входные документы: Справочник страховщиков Заявка от клиента. Данные документы приходят из отдела персонала и отдела по работе с клиентами. Мы собираем все имеющиеся данные обо всех заявках клиентах и объектах.
31400. Формирование доходов и политика их перераспределения в современной экономике 86.73 KB
  Социальная направленность реформирования российской экономики находит практическое проявление в социальной политике государства. Государственная социальная политика - это целенаправленная деятельность государства, ставящая своей целью ослабление дифференциации доходов
31401. Расчет предварительной стоимости объекта страхования без учета рисков 60.54 KB
  Требуется: Вывести ведомость предварительной стоимости объекта страхования. Стоимость рассчитывается по следующей формуле СВ=ГСВ 12n Где Св ≈Стоимость; Страхового взноса ГСВ размер годового страхового полисаруб; n срок действия договора страхования в месяцах. Периодичность и область применения: Ведомость предварительной стоимости объекта страхования на момент запроса составляется при поступлении заявки.
31402. Захист прав інтелектуальної власності 96 KB
  Захист прав інтелектуальної власності. Система захисту прав інтелектуальної власності і її призначення. Причини, що приводять до порушення прав. Призначення системи захисту прав інтелектуальної власності.
31403. Понятие о системе «человек и машина» (СЧМ) 909 KB
  В современном производстве, на транспорте, в системах связи, в строительстве и сельском хозяйстве все шире применяются автоматы и вычислительная техника; происходит автоматизация многих производственных процессов.
31404. Дослiдження лiнiйного та нелiнiйного елементу 60.5 KB
  Обладнання: Стенд з регульованою напругою опiр дiод вольтамперметр блок живлення постiйного струму 6В. Вимикач S1 знаходиться у замкненому станi пiд час вимiру напруг E1 UD UR розимикаючись лише для вимiру струму в розривi кола. Виконати вимiри напруг i струму поступово зменшуючи напругу E1 вiд 5В до 0В контролючи зменшення струму. Перемкнути вимiрювальний прилад на вимiр струму.
31405. Дослiдження послiдовного RCL контуру 242 KB
  Змiнним опiром у верхнiй по схемi гiлцi з iндуктивнiстю L i ємнiстю C виставити максимальну напругу E1 гнiзда 1011. На iнших гiлках з опiрами виставити E2=E3=E4=E5=0 гнiзда 2021 3031 4041 5051. Вимiряти напругу Us на послiдовноз’єднаних iндуктивностi L i опорi R2 гнiзда 1121. Вимiряти напругу UL на iндуктивностi L гнiзда 1112.