Структурные методы анализа и проектирования ИС
Методология структурного анализа и проектирования ПО определяет руководящие указания для оценки и выбора проекта разрабатываемого ПО, шаги работы, которые должны быть выполнены, их последовательность, правила распределения и назначения операций и методов. Структурные методологии предлагают методику трансляции проектных спецификаций в модель реализации, в дальнейшем используемую при кодогенерации.
Структурные методы являются строгой дисциплиной системного анализа и проектирования. Структурные методологии жестко регламентируют фазы анализа требований и проектирования спецификаций. Методы структурного анализа и проектирования стремятся преодолеть сложность больших систем путем расчленения их на части («черные ящики») и иерархической организации этих «черных ящиков». Выгода в использовании «черных ящиков» заключается в том, что их пользователю не требуется знать, как они работают, необходимо знать лишь их входы и выходы, а также назначение (т.е. функции, которые они выполняет).
Таким образом, первым шагом упрощения сложной системы является ее разбиение на «черные ящики», при этом такое разбиение должно удовлетворять следующим критериям:
· каждый «черный ящик» должен реализовывать единственную функцию системы;
· функция каждого «черного ящика» должна быть легко понимаема независимо от сложности ее реализации;
· связь между «черными ящиками» должна вводиться только при наличии связи между соответствующими функциями системы
· связи между «черными ящиками» должны быть простыми, насколько это возможно, для обеспечения независимости между ними.
Второй важной идеей, лежащей в основе структурных методов, является идея иерархии. Для понимания сложной системы недостаточно разбиения ее на части, необходимо эти части организовать определенным образом, а именно в виде иерархических структур.
Кроме того, структурные методы широко используют визуальное моделирование, служащее для облегчения понимания сложных систем.
Структурным анализом принято называть метод исследования системы, начинающий с ее общего обзора, который затем детализируется, приобретая иерархическую структуру со все большим числом уровней. Для таких методов характерно:
· разбиение системы на уровни абстракции с ограничением числа элементов на каждом из уровней (обычно от 3 до 6—7);
· ограниченный контекст, включающий лишь существенные на каждом уровне детали;
· использование строгих формальных правил записи;
· последовательное приближение к конечному результату.
Все наиболее распространенные методы структурного подхода базируются на ряде общих принципов. Принципами структурного подхода являются (слайд 4):
· принцип «разделяй и властвуй» — принцип решения трудных проблем путем разбиения их на множество меньших независимых задач, легких для понимания и решения;
· принцип иерархического упорядочения — принцип организации составных частей системы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.
· принцип абстрагирования — выделение существенных аспектов системы и отвлечение от несущественных;
· принцип формализации – применение строго методического подхода к решению проблемы;
· принцип упрятывания – упрятывание несущественной на конкретном этапе информации: каждая часть «знает» только необходимую ей информацию;
· принцип концептуальной общности – следование единой философии на всех этапах ЖЦ (структурный анализ – структурное проектирование – структурное программирование – структурное тестирование);
· принцип полноты – контроль за присутствием лишних элементов
· принцип непротиворечивости — обоснованность и согласованность элементов системы;
· принцип логической независимости – концентрация внимания на логическом проектировании для обеспечения независимости от физического проектирования;
· принцип независимости данных – модели должны быть проанализированы и спроектированы независимо от процессов их логической обработки, а также от их физической структуры и распределения;
· принцип структурирования данных — данные должны быть структурированы и иерархически организованы;
· принцип доступа конечного пользователя – пользователь должен иметь средства доступа к базе данных, которые он может использовать непосредственно (без программирования).
В структурном анализе основным методом разбиения на уровни абстракции является функциональная декомпозиция, заключающаяся в декомпозиции (разбиении) системы на функциональные подсистемы, которые, в свою очередь, делятся на подфункции, те — на задачи и так далее до конкретных процедур. При этом система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы «снизу вверх» от отдельных задач ко всей системе целостность теряется, возникают проблемы при описании информационного взаимодействия отдельных компонентов.
Определим ключевые понятия структурного анализа (слайд 5) .
Операция – элементарное (неделимое) действие, выполняемое на одном рабочем месте.
Функция – совокупность операций, сгруппированных по определенному признаку.
Бизнес-процесс — связанная совокупность функций, в ходе выполнения которой потребляются определенные ресурсы и создается продукт (предмет, услуга, научное открытие, идея), представляющая ценность для потребителя.
Подпроцесс – это бизнес-процесс, являющийся структурным элементом некоторого бизнес-процесса и представляющий ценность для потребителя.
Бизнес-модель – структурированное графическое описание сети процессов и операций, связанных с данными, документами, организационными единицами и прочими объектами, отражающими существующую или предполагаемую деятельность предприятия.
В структурном анализе и проектировании используются различные модели, описывающие:
· функции, которые система должна выполнять;
· процессы, обеспечивающие выполнение указанных функций;
· данные, необходимые при выполнении функций, и отношения между этими данными;
· организационные структуры, обеспечивающие выполнение функций;
· материальные и информационные потоки, возникающие в ходе выполнения функций.
Модель — это совокупность символов (математических, графических и т.п.), которая адекватно описывает некоторые свойства моделируемого объекта и отношения между ними.
Модель – это абстракция физической системы, рассматриваемая с определенной точки зрения и представленная на некотором языке или в графической форме.
Модель является лишь одним из многих возможных толкований системы. Это толкование должно устраивать пользователя в данной ситуации, в данный момент времени. Для модели в общем случае характерны четыре свойства:
· уменьшенный масштаб (размер) модели, точнее, ее сложность, степень которой всегда меньше, чем у оригинала. При построении модели сознательно вводятся упрощения;
· сохранение ключевых соотношений между разными частями;
· работоспособность, т.е. возможность в принципе работать, как оригинал-моделируемый объект (во всяком случае, похожим образом);
· адекватность действительным свойствам оригинала (степень достоверности).
Важно также подчеркнуть, что любая модель отражает точку зрения той или иной группы проектировщиков. Каждой модели присущи свои цели и задачи, и поэтому объект бизнеса, представляющий собой сложный комплексный организм, как правило, описывается некоторым набором моделей, в совокупности образующих общую модель данной бизнес-системы.
Нотации — система условных обозначений, принятая в конкретной модели.
Средства — аппаратное и программное обеспечение, реализующее выбранную методологию, в том числе построение соответствующих моделей с принятой для них нотацией.
Среди многообразия средств, предусмотренных для проведения структурного анализа, наиболее часто и эффективно применяются (слайд 6):
· DFD (Data Flow Diagrams) — диаграммы потоков данных в нотациях Гейна-Сарсона, Йордона-Де Марко и других, обеспечивающие требования анализа и функционального проектирования информационных систем;
· STD (State Transition Diagrams) — диаграммы перехода состояний, основанные на расширениях Хартли и Уорда-Меллора для проектирования систем реального времени;
· ERD (Entity-Relationship Diagrams) — диаграммы «сущность-связь» в нотациях Чена и Баркера;
· структурные карты Джексона и/или Константайна для проектирования межмодульных взаимодействий и внутренней структуры объектов;
· FDD (Functional Decomposition Diagrams) — диаграммы функциональной декомпозиции;
· SADT (Structured Analysis and Design Technique) — технология структурного анализа и проектирования;
· семейство IDEF (Integration Definition for Function Modeling):
Современные структурные методологии анализа и проектирования классифицируются по следующим признакам:
· по отношению к школам - Software Еngineering (SE) и Information Engineering (IЕ);
· по порядку построения модели - процедурно-ориентированные, ориентированные на данные и информационно-ориентированные;
· по типу целевых систем - для систем реального времени (СРВ) и для информационных систем (ИС).
SE является нисходящим поэтапным подходом к разработке ПО, начинающейся с общего взгляда на его функционирование. Затем про изводится декомпозиция на подфункции и процесс повторяется для подфункций до тех пор пока они не станут достаточно малы для их реализации кодированием. В результате получается иерархическая, структурированная, модульная программа. SE является универсальной дисциплиной разработки ПО, успешно применяющейся как при разработке систем реального времени, так и при разработке информационных систем.
IE более новая дисциплина. Она имеет более широкую область применения, чем SE: IE является дисциплиной построения систем вообще, а не только систем ПО, и включает этапы более высокого уровня (например, стратегическое планирование), однако на этапе проектирования систем ПО эти дисциплины аналогичны. С другой стороны, IE более узкая дисциплина, чем SE, т.к. IE используется только для построения информационных систем, а SE - для всех типов систем.
Разработка ПО основана на модели ВХОД-ОБРАБОТКА-ВЫХОД: данные входят в систему, обрабатываются или преобразуются и выходят из системы. Такая модель используется во всех структурных методологиях. При этом важен порядок построения модели. Традиционный процедурно-ориентированный подход регламентирует первичность проектирования функциональных компонент по отношению к проектированию структур данных: требования к данным раскрываются через функциональные требования. При подходе, ориентированном на данные, вход и выход являются наиболее важными - структуры данных определяются первыми, а процедурные компоненты являются производными от данных. Информационно-ориентированный подход, как часть IE-дисциплины, отличается от подхода, ориентированного на данные, тем, что позволяет работать с неиерархическими структурами данных.
Основная особенность систем реального времени заключается в том, что они контролируют и контролируются внешними событиями; реагирование на эти события во времени - основная и первоочередная функция таких систем. Главные отличия информационных систем от систем реального времени приведены на слайде 7, средствами поддержки этих особенностей и различаются соответствующие структурные методологии.
На слайде 8 классифицированы наиболее часто используемые методологии в соответствии с вышеперечисленными признаками
Во всех перечисленных методологиях проектирования информационных систем в различных комбинациях используются приведенные на слайде 9 техники структурных диаграмм.
Необходимо отметить что для проектирования систем реального времени используются специальные типы структурных диаграмм: диаграммы потоков управления, диаграммы переходов состояний, контекстные графы, матрицы состояний/событий, таблицы решений и др. Однако многие из них являются вариациями структурных диаграмм для проектирования информационных систем. Более того, известные методологии проектирования систем реального времени (в частности, методологии Хатли и Уорда-Меллора) базируются на перечисленных методологиях проектирования информационных систем, расширяя их соответствующими диаграммными техниками.