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

Современные CASE-средства классифицирую по следующим признакам:

1. по поддерживаемым методологиям проектирования: структурно-ориентированные, объектно-ориентированные и комплексно-ориентированные;

2. по поддерживаемым графическим нотациям построения диаграмм: с фиксированной нотацией, с отдельными нотациями и наиболее распространенными нотациями;

3. по степени интеграции: tools (отдельные локальные средства), toolkit (набор не интегрированных средств, охватывающих большинство этапов разработки ИС) и workbench (полностью интегрированные средства, связанные общей базой проектных данных – репозитарием);

4. по режиму коллективной разработки проекта: не поддерживающие коллективную разработку, ориентированные на режим реального времени разработки проекта, ориентированные на режим объединения подпроектов;

5. по типу и архитектуре вычислительной техники: ориентированные на ПЭВМ, ориентированные на локальную, глобальную или смешанную вычислительную сеть.

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

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

4.3. Функционально-ориентированное проектирование ис

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

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

Эти методологии позволяют создавать практически единый интегрированный структурный проект ИС.

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

Методология структурного анализа и моделирования подразумевает сначала создание модели AS IS, ее анализ, выявление альтернатив, улучшение бизнес-процессов, дающее в результате модель TO BE.

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

Иногда модели AS IS и TO BE отличаются очень существенно. В этих случаях необходима третья, «промежуточная» модель, а возможно и несколько последовательно меняющихся моделей, описывающих процесс перехода в желаемое состояние.

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

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

При этом созданная модель сохраняет целостное представление, в котором все составляющие компоненты взаимосвязаны.

Примечание: В настоящее время известно порядка 90 разновидностей структурного системного анализа.

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

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

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

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

В структурном анализе используются в основном три группы моделей, которые:

• иллюстрируют функции, выполняемые системой;

• описывают отношения между данными;

• описывают поведение системы во времени.

Наиболее распространенными моделями этих групп являются:

• BFD (Business Function Diagram) – диаграмма бизнес-функций (иерархии функций);

• DFD (Data Flow Diagrams) – диаграммы потоков данных;

• ERD (Entity-Relationship Diagrams) – ER-модель данных предметной области (информационно-логические модели «сущность-связь);

• STD (State Transition Diagrams) – диаграммы переходов состояний (матрицы перекрестных ссылок);

• SSD (System Structure Diagram) – диаграмма структуры программного приложения.

Все они содержат графические и текстовые средства моделирования. Графические средства обеспечивают удобство демонстрирования основных компонент модели.

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

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

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

Модель хранилища данных раскрывается с помощью диаграмм «сущность-связь» (ERD-диаграммы).

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

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