∙Основная проблема в процессе разработки программного обеспечения — управление проектом и обмен информацией между группами и внутри групп.
В то время как начинающий студент обычно знакомится с программированием «в малом», особенности многих объектно-ориентированныхязыков наилучшим образом понимаются при встрече с проблемами, типичными для программирования «в большом». Тем самым
некоторое представление о трудностях, возникающих при разработке больших систем, является полезным для понимания ООП.
2.3. Почему надо начинать с функционирования?
Из-зачего процесс проектирования начинают с анализа функционирования или поведения системы? Простой ответ состоит в том, что поведение системы обычно известно задолго до остальных ее свойств.
Предшествовавшие методы разработки программного обеспечения концентрировались на таких идеях, как характеристики основных данных или же общая структура вызова функций. Но структурные элементы приложения могут быть определены только после интенсивного анализа задачи. Соответственно процесс формальной спецификации часто заканчивался созданием документа, который не понимали ни программисты, ни клиенты. Но поведение— это нечто, что может быть описано в момент возникновения идеи программы и(в отличие от формальной спецификации системы) выражено в терминах, имеющих значение как для программиста, так и для клиента.
Мы проиллюстрируем проектирование на основе обязанностей (илиRDD-
проектирование — Responsibility-Driven-Design) на учебном примере.
2.4. Учебный пример: проектирование на основе обязанностей
Представьте себе, что вы являетесь главным архитектором программных систем в ведущей компьютерной фирме. В один прекрасный день ваш начальник появляется в офисе с идеей, которая, как он надеется, будет очередным успехом компании. Вам поручают разработать систему под названиемInteractive Intelligent Kitchen Helper (Интерактивный разумный кухонный помощник) (рис. 2.1)
Рис. 2.1. Внешний вид программы «Интерактивный разумный кухонный помощник»
Задача, поставленная перед вашей командой программистов, сформулирована в нескольких скупых словах(написанных начем-то, что оказывается использованной обеденной салфеткой, причем почерком, принадлежащим вашему начальнику).
2.4.1. Интерактивный разумный кухонный помощник
Программа «Интерактивный разумный кухонный помощник» (Interactive Intelligent Kitchen Helper, IIKH) предназначена для персональных компьютеров. Ее цель— заменить собой набор карточек с рецептами, который можно встретить почти в каждой кухне. Но помимо ведения базы данных рецептов, IIKH помогает в планировании питания на длительный период— например, на неделю вперед. Пользователь программыIIKH садится за компьютер, просматривает базу данных рецептов и в диалоговом режиме определяет меню на весь требуемый период.
Как это обычно бывает при первоначальном описании многих программных систем, спецификация дляIIKH в значительной степени двусмысленна в отношении ряда важных пунктов. Кроме того, проект и разработка программной системыIIKH потребует совместных усилий нескольких программистов. Тем самым первоначальная цель команды разработчиков состоит в том, чтобы сделать ясными двусмысленные места и наметить разбиение проекта на компоненты, с тем чтобы распределить их между отдельными членами команды.
Краеугольным камнем в ООП является характеристика программного обеспечения в терминах поведения, то есть в терминах действий, которые должны быть выполнены. Мы
увидим воплощение в жизнь этого принципа на многих уровнях процесса разработки IIKH. Первоначально команда попытается охарактеризовать на очень высоком уровне абстрагирования поведение приложения в целом. Затем она займется описанием поведения различных программных подсистем. И только тогда, когда все аспекты поведения будут выделены и описаны, программисты-разработчикиприступят к этапу кодирования. В следующих разделах мы будем отслеживать этапы работы команды программистов при создании данного приложения.
2.4.2. Работа по сценарию