Опубликован: 23.10.2005 | Доступ: свободный | Студентов: 4086 / 201 | Оценка: 4.44 / 4.19 | Длительность: 33:04:00
Специальности: Программист
Лекция 10:

Процесс разработки ПО

< Лекция 9 || Лекция 10: 12345 || Лекция 11 >
Аннотация: Центральный вопрос объектной технологии - ее воздействие на весь процесс разработки ПО. Пришло время рассмотреть влияние ОО-принципов на общую организацию проектов и их деление на этапы. Это часть более общей проблемы перспектив объектной технологии с позиций менеджмента. Вопросы менеджмента подробно изучаются в книге Object Success. В данной лекции обсуждаются лишь наиболее существенные идеи: кластеры как основная организационная единица, принципы параллельной разработки на основе кластерной модели жизненного цикла ПО, этапы и задачи такой модели, роль обобщения для повторного использования, принципы бесшовности и обратимости.
Ключевые слова: класс, кластер, группа, рекурсивное определение, синтаксический анализ, объединение, здравый смысл, идентификация, работ, член группы, модели жизненного цикла, ПО, распределение обязанностей, открытые спецификации, итеративность, спиральная модель, связь, Internet, деление, цикл разработки, жизненный цикл, verification, D-AMPS, этапы проектирования, анализ осуществимости, feasibility study, компонент, руководитель проекта, определение, эффективное управление, распределение ресурсов, контроль, удаленный терминал, этап жизненного цикла, обобщение, акционеры, Модель процессов, смета, абстрактный класс, постусловие, инвариант, предусловие, обработка исключений, иерархия наследования, цикла, электрическая схема, расширяемость, функциональный подход, диаграмма жизненного цикла, универсалии, анализ, ущерб, уровень абстракции, OMT

Кластеры

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

Кластер - это группа связанных классов или связанных кластеров (рекурсивное определение).

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

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

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

В отличие от пакетов кластеры - это не языковая конструкция, а инструмент управления. Они появляются в управляющих файлах Lace, используемых для сборки системы из компонентов. Успешное объединение классов в кластеры определяется главным образом здравым смыслом и опытом руководителя проекта. Этот момент заслуживает особого внимания, поскольку его роль часто недооценивается. Идентификация классов, то есть выбор надлежащих абстракций данных, - действительно трудная задача, удачное решение которой создает условия для благоприятного развития работ, а неудачное может привести к краху проекта. Группировка же классов в кластеры является организационной проблемой, она может быть решена различными способами в зависимости от доступных ресурсов и квалификации членов группы. Неоптимальное формирование кластеров может причинить неприятности и замедлить разработку, но не может стать причиной неудачи проекта.

Параллельная разработка

Одно из последствий деления на кластеры - уход от недостатков традиционной бескомпромиссной модели жизненного цикла ПО. Известная Модель Водопада, введенная в 1970 г., была реакцией против устаревшего подхода "раньше запрограммируйте, а потом опишите". Заслуга этого подхода выражается в распределении обязанностей, определении основных задач разработки ПО и в подчеркивании важности открытой спецификации.

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

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

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

Модель Водопада

Рис. 10.1. Модель Водопада

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

Вот как выглядит жизненный мини-цикл разработки кластера:

Жизненный цикл отдельного кластера

Рис. 10.2. Жизненный цикл отдельного кластера

Форма представления отражает бесшовный характер разработки. Вместо отдельных шагов в модели водопада данный процесс можно уподобить росту сталактита: каждый последующий шаг произрастает из предыдущего и добавляет собственный вклад.

Этапы и задачи

Жизненный цикл каждого кластера включает следующие этапы:

  • спецификация: идентификация классов (абстракций данных) кластера и их главных особенностей и ограничений;
  • проектирование: определение архитектуры классов и их отношений;
  • реализация: завершение классов во всех деталях;
  • верификация и Аттестация (Verification &amp; Validation): контроль классов кластера (статическая проверка, тестирование и другие методы);
  • обобщение: подготовка к повторному использованию (см. ниже).

Иногда трудно четко разграничить этапы проектирования и реализации. Поэтому возможны варианты модели, объединяющие эти этапы в один, - "проектирования-реализации".

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

< Лекция 9 || Лекция 10: 12345 || Лекция 11 >