Название: Базы знаний интеллектуальных систем - Гаврилова Т.А.

Жанр: Информатика

Рейтинг:

Просмотров: 1254


Модульность является следующим фундаментальным свойством, помогающим управлять сложностью систем ПО. Она реализуется целенаправленным конструированием. В самом общем плане модули могут быть функциональными (процедурно-ориентированными) или декларативными (объектно-ориентированными). Связность модулей определяется как мера их взаимной зависимости. В идеале должны разрабатываться слабо связанные модули. Другой мерой, применимой к модульности, является прочность, которая определяет, насколько сильно связаны элементы внутри модуля.

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

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

Принципы технологии разработки ПО не должны применяться случайно — необходимо выполнять структуризацию системы определенным образом и, что самое важное, поскольку происходит деление системы на модули, применять согласованные критерии декомпозиции. Можно выделить три основных подхода к разработке ПО, обеспечивающие такие критерии: нисходящее структурное проектирование [Йордан, 1979]; проектирование, структурированноепо данным [Jackson, 1975], и объектно-ориентированное проектирование [Booch, 1986].

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

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

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

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

Такой подход получил название объектно-ориентированного [Booch, 1986]. Здесь учитывается важность трактовки объектов ПО как активных элементов, причем каждый объект наделен своим собственным набором допустимых операций. Легко убедиться, что объектно-ориентированная парадигма поддерживает основные принципы технологии разработки ПО.

 

Подпись: Под жизненным циклом разработки ПО традиционно понимается упорядоченная совокупность этапов, обеспечи-вающих создание качественного программного продукта. В общем случае в жизненный цикл разработки включают-ся следующие стадии: техническое задание, эскизный проект, технический проект, рабочий проект и внедрение.6.1.2. Модели процесса разработки ПО

В литературе существует множество нареканий на несовершенство данного разбиения [Липаев и др., 1983], но смысл его в целом достаточно ясен — борьба со сложностью процесса разработки программных продуктов за счет структуризации этапов и локализации на каждом из них только тех задач, которые могут и должны решаться именно здесь. Если перечисленные выше этапы укрупнить, останутся стадии проектирования, реализации и сопровождения.

Проектирование предполагает составление формальных и/или формализованных спецификаций.

Реализация — преобразование этих спецификаций в программный код (автоматическое и/или автоматизированное).

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

Ключевой стадией в жизненном цикле процесса разработки ПО является проектирование. Ошибки и просчеты, допущенные здесь, — самые «дорогие». Поэтому основные усилия в области технологии программирования направлены на автоматизацию проектирования программных комплексов. При этом базисными понятиями являются модель программы и модель системы.

Существуют различные подходы к разработке таких моделей [Миллс, 1970]. Однако с точки зрения целей настоящей книги нас будут интересовать, в первую очередь, те из них, которые имеют непосредственное продолжение в инструментальных средствах и интегрированных инструментальных средах. Поэтому ниже основное внимание будет уделено моделям программ, которые используются в так называемых WorkBench-системах (наиболее близким по семантике к этому термину является словосочетание «станок для производства ПО»).

Одну из таких моделей предлагает W/0 (Warnier/Orr) методология [Orr et al., 1977]. Она объединяет методологию Warnier по использованию логических

структур данных и логических конструкции программ и систем и методологию DSSD (Data Structured System Development) Oppa, базисом которой является аксиома о логическом соответствии между эвристической структурой программ и данных, обрабатываемых этими программами. На практике такая методология предполагает, что в распоряжении проектировщика системы имеется представительный набор процедурных шаблонов для достаточно широкого класса программируемых задач.

В настоящее время DSSD-методология «переросла» из методологии разработки программ в методологию разработки систем. При этом выделены явно уровень программирования (programming level) и системный уровень (system level). Применяются в DSSD два концептуальных представления — диаграммы входов (Entity diagrams), обеспечивающие определение системного контекста, и модифицированные W/O-диаграммы (Assembly-line Diagrams), специфицирующие функциональное развитие системы [McClure, 1979].

Следующим подходом к созданию моделей программ (по идее достаточно близким к W/O-методологии) является логическое моделирование Гэйиа [Cane et al., 1979]. Сам метод ориентирован на создание систем обработки данных. Логическая модель системы проектируется в процессе последовательного применения следующих семи этапов: описание природы предметной области с помощью диаграмм потоков данных (Data Flow Diagram); выделение первичной модели данных (списка элементов данных в каждом информационном узле); проверка того, что DFD действительно отражает структуру данных, хранимых в системе; сведение полученной на предыдущем этапе информации в двумерные таблицы, которые в дальнейшем нормализуются; коррекция DFD с учетом результатов нормализации предыдущего этапа; разбиение полученной в результате выполнения предыдущих этапов модели на «процедурные единицы» (procedure units), а также определение деталей каждой процедурной единицы. После выполнения этих этапов принимается решение о необходимости прототипирования системы на целевом языке.


Оцените книгу: 1 2 3 4 5