Меню
Главная
Авторизация/Регистрация
 
Главная arrow Информатика arrow Архитектура и проектирование программных систем

Проектирование архитектуры программных систем

Методология проектирования

По мнению авторов фундаментальных монографий [19, 20, 24, 41], всякую методологию проектирования программных систем можно представить набором желаемых характеристик результата проектирования и руководящих принципов процесса проектирования. Выше уже отмечалось, что формирование желательных целей проектирования сводится к определению требований и целей проектирования. Что касается принципов проектирования, то они определяют сам процесс проектирования и методы проектирования.

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

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

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

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

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

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

  • 1. В процесс разработки программной системы вовлекается все большее количество людей. Регулярные контакты между исполнителями снижают вероятность разногласий, касающихся того, кто и что должен делать, и уменьшают возможность серьезных последствий, возникающих в подобных ситуациях.
  • 2. Полезное время жизни программы (рабочая стадия) начинается с момента передачи потребителю. Однако работа над программой не заканчивается. Работа по модификации и сопровождению программы может потребовать больше времени, чем время, потраченное на ее разработку. При этом неразумно начинать работу с полной переделки программы. Лучше внести изменения в уже существующую структуру программы. Поэтому важно, чтобы структура программы допускала возможность такой модификации. Для этого необходимо, чтобы части программы были независимы друг от друга, с тем чтобы изменение в одной части могло быть сделано без изменений других частей.
  • 3. Со временем модификация программ, время жизни которых достаточно велико, выполняется уже не разработчиками программ. Все эти факторы предполагают структурирование программ таким образом, чтобы они были легко понимаемыми.

Таким образом, большие программные системы целесообразно разрабатывать путем декомпозиции задачи.

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

Абстракция - эффективный способ декомпозиции, осуществляемый посредством изменения списка детализации. Когда разработчик абстрагируется от проблемы, он предполагает игнорирование ряда подробностей, с тем чтобы сделать задачу более простой. Задачи абстрагирования и последующей декомпозиции типичны для процесса создания программной системы: декомпозиция используется для разбиения программы на компоненты (модули), которые затем могут быть объединены, позволив решить основную задачу; абстрагирование предполагает продуманный выбор компонентов. Разработчики выполняют последовательно то один, то другой из этих процессов до тех пор, пока не сведут исходную задачу к набору простых подзадач, которые несложно решить.

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

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

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

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

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

Одним из способов задания спецификаций являются комментарии в виде пары утверждений. Первое утверждение (начальное условие) задает на входе процедуры истинность или ложность некоторого условия (или нескольких условий). Второе утверждение (конечное условие) задает некоторое условие, которое предполагается истинным по завершении данной процедуры. Например, это может выглядеть так: Имя_процедуры (список параметров)

// все параметры > О // возвращает наибольшее значение {

тело процедуры

}?

При анализе спецификации для уяснения смысла обращения к процедуре следует придерживаться двух четких правил:

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

Абстракция через спецификацию по сравнению с абстракцией через параметризацию имеет следующие преимущества:

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

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

 
Посмотреть оригинал
Если Вы заметили ошибку в тексте выделите слово и нажмите Shift + Enter
< Пред   СОДЕРЖАНИЕ ОРИГИНАЛ   След >
 

Популярные страницы