Название: Базы знаний интеллектуальных систем - Гаврилова Т.А. Жанр: Информатика Рейтинг: Просмотров: 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), а также определение деталей каждой процедурной единицы. После выполнения этих этапов принимается решение о необходимости прототипирования системы на целевом языке. |
| Оглавление| |
- Акмеология
- Анатомия
- Аудит
- Банковское дело
- БЖД
- Бизнес
- Биология
- Бухгалтерский учет
- География
- Грамматика
- Делопроизводство
- Демография
- Естествознание
- Журналистика
- Иностранные языки
- Информатика
- История
- Коммуникация
- Конфликтология
- Криминалогия
- Культурология
- Лингвистика
- Литература
- Логика
- Маркетинг
- Медицина
- Менеджмент
- Метрология
- Педагогика
- Политология
- Право
- Промышленность
- Психология
- Реклама
- Религиоведение
- Социология
- Статистика
- Страхование
- Счетоводство
- Туризм
- Физика
- Филология
- Философия
- Финансы
- Химия
- Экология
- Экономика
- Эстетика
- Этика
Лучшие книги
Гражданский процесс: Вопросы и ответы
ЗАПАДНОЕВРОПЕЙСКОЕ ИСКУССТВО от ДЖОТТО до РЕМБРАНДТА
Коммуникации стратегического маркетинга
Консультации по английской грамматике: В помощь учителю иностранного языка.
Международные экономические отношения