На данном этапе, если только это не было сделано раньше, происходит разделение команды разработчиков на группы, каждая из которых отвечает за конкретные компоненты программы. Задача теперь состоит в переходе от описания компоненты к конкретному коду. Главное здесь— проектирование структур данных, которые будут использоваться каждой из подсистем для хранения внутренней информации, необходимой для выполнения предписанных обязанностей.
Именно на этом этапе в игру вступают классические структуры данных, используемые в информатике. Выбор структуры данных является важным, центральным моментом с точки зрения проектирования. Если представление данных выбрано правильно, то код, используемый компонентой при выполнении ее обязанностей, становится почти самоочевидным.
Структуры данных должны точно соответствовать рассматриваемой задаче.
Неправильный выбор структуры может привести к сложным и неэффективным программам.
На этом же этапе описание поведения компонент должно быть преобразовано в алгоритмы. Реализованные функции затем сопоставляются с потребностями компоненты,
являющейся клиентом данного фрагмента, чтобы гарантировать, что все ее запросы
оказываются выполненными и что все необходимые для ее работы данные являются доступными.
2.10. Реализация компонент
Когда проект в целом определен и разбит на подсистемы, следующим шагом является реализация компонент. Если предыдущие этапы были выполнены корректно, каждая обязанность или поведение будут кратко охарактеризованы. Задачей данного этапа является воплощение желаемых действий на компьютерном языке. В следующем разделе мы опишем некоторые из наиболее типичных эвристических подходов, используемых с этой целью.
Если это не было сделано ранее (например, как часть этапа спецификации всей системы), то теперь можно решить, как будут устроены внутренние детали отдельных компонент. В случае нашего примера на данном этапе следует подумать, как пользователь будет просматривать базу данных рецептов.
По мере того как программные проекты с большим числом разработчиков становятся нормой, все реже встречается ситуация, когдаодин–единственныйпрограммист отвечает за всю систему. Наиболее важные для программиста качества— это способность понимать, как отдельный фрагмент кода подключается к более высокому программному уровню, и желание работать совместно с остальными членами команды.
Часто в процессе реализации одной компоненты становится ясно, что некоторая информация или действия должны быть присвоены совсем другой компоненте, которая работала бы «за сценой», не видимо для пользователя. Такие компоненты иногда называют суфлерами. Мы встретим соответствующие примеры в некоторых последующих главах.
Важной частью анализа и кодирования на этом этапе является полная характеризация и документирование необходимых предварительных условий, которые требуются программной компоненте для выполнения задания. Также следует проверить, правильно ли работает программная компонента, если вызвать ее с правильными входными значениями. Это подтвердит корректность алгоритмов, использованных при реализации компоненты.
2.11. Интеграция компонент
Когда индивидуальные подсистемы разработаны и протестированы, они должны быть интегрированы в конечный продукт. Это делается поэтапно. Начиная с элементарной основы, к системе постепенно добавляются(и тестируются) новые элементы. При этом для еще не реализованных частей используются так называемые заглушки(stubs) — подпрограммы безкакого-либоповедения или с ограниченной функциональностью.
Например, при разработке программыIIKH было бы разумным начать интегрирование с компонентыGreeter. Чтобы протестировать ее в изоляции от остальных блоков программы, потребуются заглушки для управляющего кода базы данных с рецептамиRecipe Database и блока управления планированием питанияMeal Plan. Заглушки просто должны выдавать информационные сообщения и возвращать управление. Таким образом, команда разработчиков компонентыGreeter сможет протестировать различные аспекты
данной компоненты (например, проверить, вызывает ли нажатие клавиши нужную реакцию). Отладку отдельных компонент часто называют тестированием блоков.
Затем заглушки заменяются более серьезным кодом. Например, вместо заглушки для компонентыRecipe Database можно вставить реальную подсистему, сохранив заглушки для остальных фрагментов. Тестирование продолжается до тех пор, пока не станет ясно, что система работает правильно. Этот процесс называют тестированием системы в целом.
Когда все заглушки заменены работающими компонентами, приложение завершено. Процесс тестирования заметно облегчается, если число связей между компонентами невелико— в этом случае не придется писать множествопрограмм-заглушек.