Словарь данных

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

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

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

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

ERD-диаграммы (диаграммы «сущность-связь»

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

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

STD-диаграммы (диаграммы переходов состояний)

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

Инструментальные средства проектирования ис

Современный рынок программных средств насчитывает около 300 различных CASE-средства.

Комплекс средств, поддерживающих полный ЖЦ ПО содержит следующие компоненты:

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

• Графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и других), образующих модели АИС;

• Средства разработки приложений, включая языки 4GL и генераторы кодов;

• Средства конфигурационного управления;

• Средства документирования;

• Средства тестирования;

• Средства управления проектом;

• Средства реинжиниринга.

Требования к инструментальным средствам:

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

2. Крупный проект нельзя реализовать в одиночку. Вывод – при реализации крупных проектов необходимо иметь средства координации и управления коллективом разработчиков.

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

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

Кратко рассмотрим одну из многих технологий разработки ИС, основывающуюся на решениях фирм Logic Works и Rational Software. Эта технология является на сегодняшний день одной из лучших по критерию стоимость/эффективность.

Для проведения анализа и реорганизации бизнес-процессов Logic Works предлагает CASE-средство верхнего уровня – Bpwin. Оно поддерживает методологии IDEF0 (SADT), IDEF3 (WorkFlow Diagram) и DFD (DataFlow Diagram) создания функциональной модели ИС.

Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии (модель «как есть» - AS IS) и идеального положения вещей – то есть модели «как должно быть» – TO BE.

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

BPwin позволяет переключаться на любой ветви SADT модели на DFD или IDEF3 и создавать смешанные модели ИС. В частности это обусловлено тем, что DFD диаграммы являются более удобными для моделирования документооборота, так как включают понятия хранилищ данных. Методология IDEF3 позволяет описывать логику взаимодействия компонентов системы.

На основе модели BPwin можно построить модель данных.

Для построения модели данных Logic Works предлагает CASE-средство – ERwin. Процесс преобразования BPwin-модели в модель данных полностью не автоматизирован. Для облегчения построения модели данных на основе функциональной модели предложен механизм двунаправленной связи BPwin–Erwin (1, рис). ERwin имеет два уровня представления модели данных – логический и физический.

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

Физический уровень – это модель, привязанная к конкретной СУБД. Erwin позволяет проводить процессы прямого и обратного проектирования БД (2, рис).

Erwin интегрируется с популярными средствами разработки клиентской части – PowerBuilder, SQLWindows, Visual Basic, Delphi (3, рис). Это позволяет автоматически генерировать код приложения, который готов к компиляции и выполнению (4, рис).

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

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

Фирма Logic Works разработала систему Model Mart – хранилище моделей. К этому хранилищу открыт доступ всем участникам проекта создания ИС (5, рис).

Model Mart удовлетворяет всем требованиям, предъявляемым к средствам разработки крупных ИС, а именно:

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

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

• Управление доступом. Для каждого участника проекта определяются права доступа только к определенным моделям. Права доступа могут быть определены как для групп, так и для отдельных участников проекта.

Rational Rose – это средство объектно-ориентированного проектирования. Оно позволяет строить модели в различных нотациях (ОМТ, UML, Буч) и генерировать на основе полученной модели приложения на языках программирования C++, Visual Basic, PowerBuilder, Java, Ada, Smalltalk и др. (6, рис).

Модель Erwin Translation Wizard позволяет перегружать объектную модель Rational Rose в модель данных ERwin (и обратно) и, с помощью ERwin, сгенерировать схему БД (7, рис).