Концептуальные основы CASE-технологии. Классификация CASE-средств. Концептуальное и логическое проектирование БД. Физическое проектирование БД.

⇐ ПредыдущаяСтр 28 из 31Следующая ⇒

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

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

· ассемблеров, дампов памяти, анализаторов;

· компиляторов, интерпретаторов, трассировщиков;

· символических отладчиков, пакетов программ;

· систем анализа и управления исходными текстами;

· CASE-средств анализа требований, проектирования спецификаций и структуры, редактирования интерфейсов ( первая генерация CASE-I );

· CASE-средств генерации исходных текстов и реализации интегрированного окружения поддержки полного жизненного цикла (ЖЦ) разработки ПО( вторая генерация CASE-II ).

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

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

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

А) B)

Рис. 14.1. Модели жизненного цикла ПО

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

CASE-средства подразделяются на логическое проектирование БД и физическое проектирование.

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

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

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

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

· повышение качества программного продукта,

· сокращение стоимости проекта,

· поставка системы в запланированные сроки.

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

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

На физическом уровне – данные, напротив, зависят от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация обо всех объектах БД. Они подразделяются на:

Иерархические БД состоят из упорядоченного набора деревьев; более точно, из упорядоченного набора нескольких экземпляров одного типа дерева.

Тип дерева состоит из одного “ корневого” типа записи и упорядоченного набора из нуля или более типов поддеревьев (каждый из которых является некоторым типом дерева). Сетевые модели создавались для мало ресурсных ЭВМ.

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

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

· каждая ячейка в таблице представляет точно один элемент данных; нет повторяющихся групп;

· каждая таблица имеет однородные столбцы; все элементы в любом из столбцов одного и того же вида;

· каждому столбцу назначено определенное имя;

· все строки различны; дублировать строки не разрешается;

· и строки, и столбцы не зависят от последовательности; просмотр в различной последовательности не может изменить информационное содержание отношения;

· каждая строка олицетворяет уникальный элемент данных, который ею и описывается;

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

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

КЛАССИФИКАЦИЯ CASE – СРЕДСТВ. Все CASE-средства делятся на типы, категории и уровни. Классификация по типам отражает функциональную ориентацию CASE-средств в технологическом процессе.

1) АНАЛИЗ И ПРОЕКТИРОВАНИЕ. Средства данной группы используются для создания спецификаций системы и ее проектирования; они поддерживают широко известные методологии проектирования. К таким средствам относятся: CASE.Аналитик (Эйтэкс), ProKit*Workbench (McDonnell Douglas), MicroStep (Meta Systems), BPWin (Logic Works), SELECT (Select Software Tools), и др. Их целью является определение системных требований и свойств, которыми система должна обладать, а также создание проекта системы, удовлетворяющей этим требованиям и обладающей соответствующими свойствами. На выходе продуцируются спецификации компонент системы и интерфейсов, связывающих эти компоненты, а также “калька” архитектуры системы и детальная “калька” проекта, включающая алгоритмы и определения структур данных.

2) ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ И ФАЙЛОВ. Средства данной группы обеспечивают логическое моделирование данных, автоматическое преобразование моделей данных в Третью Нормальную Форму, автоматическую генерацию схем БД и описаний форматов файлов на уровне программного кода: ERWin, Designer2000 (Oracle) и др.

3) ПРОГРАММИРОВАНИЕ. Средства этой группы поддерживают этапы программирования и тестирования, а также автоматическую кодогенерацию из спецификаций, получая полностью документированную выполняемую программу: COBOL 2/Workbench (Mikro Focus), DECASE (DEC), APS (Sage Software).

4) СОПРОВОЖДЕНИЕ И РЕИНЖИНИРИНГ. К таким средствам относятся документаторы, анализаторы программ, средства реструктурирования и реинжениринга: Adpac CASE Tools (Adpac), SuperStructure (Computer Data Systems). Их целью является корректировка, изменение, анализ, преобразование и реинжениринг существующей системы.

5) ОКРУЖЕНИЕ. Средства поддержки платформ для интеграции, создания и придания товарного вида CASE-средствам: Multi/Cam (AGS Management Systems), Design/OA (Meta Software).

6) УПРАВЛЕНИЕ ПРОЕКТОМ. Средства, поддерживающие планирование, контроль, руководство, взаимодействие, т.е. функции, необходимые в процессе разработки и сопровождения проектов: Project Workbench.

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

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

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

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

⇐ Предыдущая 22 23 24 25 26 272829 30 31 Следующая ⇒