1. Основные понятия и определения

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

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

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

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

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

Для таких методов характерно:

• разбиение информации на уровни абстракции с ограничением числа элементов на каждом из уровней (обычно от 3 до 6-7);

• ограниченный контекст, включающий лишь существенные на каждом уровне детали;

• двойственность данных и операций над ними;

• использование строгих формальных правил записи;

• последовательное приближение к конечному результату.

2. Структурный системный анализ предприятия как основа формирования информационной системы

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

Основные задачи ССА можно сформулировать следующим образом:

• Выработка первоначального плана.

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

• Анализ существующей системы.

Исследуются все существующие системы в сфере действия проектируемой ИС. Кратко формулируются выявленные проблемы.

• Определение требований.

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

• Разработка эскизного проекта.

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

• Анализ данных.

На этом этапе формулируется логическое определение всех данных ИС. Проверяется полнота их описаний и соответствие требованиям предметной области.

• Детальная проработка системы.

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

• Составление плана разработки.

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

• Подготовка спецификаций и сводного отчета.

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

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

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

• анализ данных, предназначенный для полного и однозначного определения данных (сущностей) и их взаимосвязи;

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

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

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

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

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

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

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

• принцип упрятывания – заключается в упрятывании несущественной на конкретном этапе информации;

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

• принцип полноты – заключается в контроле на присутствие лишних элементов;

• принцип непротиворечивости – заключается в обоснованности и согласованности элементов;

• принцип логической независимости – заключается в концентрации внимания на логическом проектировании для обеспечения независимости от физического проектирования;

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

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

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

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

Для реализации перечисленных принципов CСА требуются методики и процедуры (технологические схемы).

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

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

Структуры потоков данных и определения их компонентов хранятся и анализируются в словаре данных.

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

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

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

Для описания отношений между данными методологии используют диаграммы «сущность-связь» (ERD – Entity-Relationship Diagrams). ERD предназначены для разработки моделей данных и обеспечивают стандартный способ определения данных и отношений между ними. Фактически с помощью ERD идентифицируются объекты, важные для предметной области (сущности), и их отношения с другими объектами. Сущность представляет собой множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, предметов), обладающих общими свойствами (атрибутами) или характеристиками. Отношение в самом общем виде представляет собой связь между двумя и более сущностями. Для идентификации требований, в соответствии с которыми сущности вовлекаются в отношения, используются связи. Каждая связь соединяет сущность и отношение, и направлена только от отношения к сущности.

Для описания зависящего от времени поведения системы или моделирования реакции на событие используются диаграммы переходов состояний (STD – State Transition Diagrams). Моделируемая система в любой заданный момент времени находится точно в одном из конечного множества состояний. С течением времени она может изменить свое состояние, при этом переходы между состояниями должны быть точно определены. С помощью STD можно моделировать последующее функционирование системы на основе ее предыдущего и текущего функционирования.

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

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

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