Тема. 3. Методы проектирование сложных программных средств 1
3.2. Структурное проектирование программных средств. 1
3.3. Приобретение и поставка готовых программных компонент в процессе проектирования 5
Тема 4. Проектирование программных средств на основе концепции и стандартов открытых систем. 15 Тема. 3. Методы проектирование сложных программных средств
3.2. Структурное проектирование программных средств.
Гибкость модификации и расширяемость комплексов программ при их развитии обеспечивается рядом принципов и правил структурного построения ПС и их компонент, а также взаимодействия между ними. Эти правила направлены на стандартизацию и унификацию структуры и взаимодействия компонент разного ранга и назначения в пределах проблемной области (рис.2). Некоторая часть принципов и правил имеет достаточно общий характер и может применяться практически всегда. Другая часть отражает проблемную и машинную ориентированность класса ПС и подлежит отработке при проектировании для эффективного применения в соответствующей области.
Основные принципы и правила структурирования ПС и БД можно объединить в группы, которые отражают:
стандартизированную структуру ПС или БД определенного класса;
унифицированные правила структурного построения прикладных программных компонент и модулей;
стандартизированную структуру базы данных, обрабатываемых программами;
унифицированные правила структурного построения информационных модулей, заполняющих базу данных;
унифицированные правила структурного построения и организации межмодульного интерфейса прикладных программ;
унифицированные правила внешнего интерфейса и взаимодействия компонент прикладных ПС и БД с внешней средой, с операционной системой и другими типовыми средствами организации вычислительного процесса и контроля.
Рис. 3.1
Сущность структурного подхода к разработке ПО заключается в декомпозиции (разбиении) программ на функции. Все наиболее распространенные методологии структурного подхода базируются на ряде общих принципов. В качестве двух базовых принципов используются следующие:
принцип "разделяй и властвуй" - принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения;
принцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.
Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, поскольку игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к провалу всего проекта). Основными из этих принципов являются следующие:
принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечения от несущественных;
принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы;
принцип непротиворечивости - заключается в обоснованности и согласованности элементов;
принцип структурирования данных - заключается в том, что данные должны быть структурированы и иерархически организованы.
Методология структурного анализа и структурного проектирования ПС предполагает использование одного из стилей проектирования:
нисходящего (Top-of-Design);
восходящего (Bottom-of-Design).
При нисходящем проектировании («сверху–вниз») программа разбивается на функциональные подпрограммы, которые в свою очередь делятся на функции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до операторов конкретного языка программирования. При этом программа сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. Четкая реализация нисходящего проектирования приводит к спиральной модели разработки ПО, на каждом витке спирали блоки предыдущего уровня детализируются, используются обратные связи (альтернативой является так называемая каскадная модель, относящаяся к поочередной реализации частей системы).
При восходящем проектировании программы («снизу-вверх»), которое направлено от отдельных задач ко всей системе, целостность программы теряется, возникают проблемы при информационной стыковке отдельных компонентов.
Верхний уровень проектирования ПО часто называют концептуальным проектированием. Концептуальное проектирование выполняют в процессе предпроектных исследований, формулировки ТЗ, разработки эскизного проекта и прототипирования (согласно ГОСТ 34.601-90, эти стадии называют формированием требований к ИС, разработкой концепции ИС и эскизным проектом).
При концептуальном проектировании применяют ряд спецификаций среди которых центральное место занимают модели преобразования, хранения и передачи информации. Модели, полученные в процессе обследования предприятия, являются моделями его функционирования. В процессе разработки ИС модели, как правило, претерпевают существенные изменения (переход от «As Is» (как есть) к «То Be» (как должно быть) и в окончательном виде модель «То Be» рассматривают в качестве модели проектируемой АС.
Различают функциональные, информационные, поведенческие и структурные модели. Функциональная модель системы описывает совокупность выполняемых системой функций. Информационные модели отражают структуры данных — их состав и взаимосвязи. Поведенческие модели описывают информационные процессы (динамику функционирования), в них фигурируют такие категории, как состояние системы, событие, переход из одного состояния в другое, условия перехода, последовательность событий, осуществляется привязка ко времени. Структурные модели характеризуют морфологию системы (ее построение) — состав подсистем, их взаимосвязи.
Для описания функциональных моделей наибольшее распространение получили функциональные спецификации в виде диаграмм. Практически все способы функциональных спецификаций имеют следующие общие черты:
модель имеет иерархическую структуру, представляемую в виде диаграмм нескольких уровней;
элементарной частью диаграммы каждого уровня является конструкция вход-функция-выход;
необходимая дополнительная информация содержится в файлах поясняющего текста.
В большинстве случаев функциональные диаграммы являются диаграммами потоков данных (DFD — Data Flow Diagram). В DFD блоки (прямоугольники) соответствуют функциям, дуги — входным и выходным потокам данных. Поясняющий текст представлен в виде «словарей данных», в которых указаны компонентный состав потоков данных, число повторений циклов и т. п. Для описания структуры информационных потоков можно использовать нотацию Бэкуса-Наура.
Одна из нотаций для DFD предложена Е. Иорданом. В ней описывают процессы (функции), потоки данных, хранилища и внешние сущности, их условные обозначения показаны на рис. 3.2.
Рис. 3.2. Изображения элементов в нотации Е. Иордана
Разработка DFD начинается с построения диаграммы верхнего уровня, отражающей связи программной системы, представленной в виде единого процесса, с внешней средой. Декомпозиция процесса проводится до уровня, на котором фигурируют элементарные процессы, которые могут быть представлены одностраничными описаниями алгоритмов (миниспецификациями) на терминальном языке программирования.
Для описания информационных моделей наибольшее распространение получили диаграммы сущность-связь (ERD — Entity-Relation Diagrams), в которых предусмотрены средства для описания сущностей, атрибутов и отношений. Спецификации хранилищ данных в CASE, как правило, даются с помощью диаграмм сущность-связь. Стандартной методикой построения таких диаграмм является IDEF1X.
Поведенческие модели описывают процессы обработки информации. В инструментальных CASE-системах их представляют в виде граф-схем, диаграмм перехода состояний, таблиц решений, псевдокодов (языков спецификаций), процедурных языков программирования, в том числе языков четвертого поколения.