2. Учебный пример: электронный ежедневник. Общее описание программы
Программа "Электронный ежедневник" предназначена для персональных компьютеров. Она должна заменить бумажную записную книжку. Ежедневник предназначен для ведения базы данных дел, запланированных на разные даты и время. Предполагается, что значительная часть дел является встречами и телефонными переговорами с другими людьми, поэтому ежедневник должен также позволять работать с базой данных людей.
Ежедневник должен позволять планировать расписание встреч и других дел на длительный период. Пользователь программы может просматривать встречи по дням, искать дела по теме и по людям, заполнять записи о новых встречах на заданные дни или подбирать свободное время для новых дел, а также просматривать базу данных людей и пополнять ее в диалоговом режиме.
Как обычно и бывает, первоначальное описание системы двусмысленно и не слишком полно. На данном примере рассмотрим, как будет выполняться уточнение проекта и разбиение его на компоненты, которые можно поручить различным разработчикам. Основой объектно-ориентированного проектирования является характеристика программного обеспечения в терминах поведения, т.е. в терминах действий, которые должны быть выполнены.
Сначала поведение характеризуется на очень абстрактном уровне, т.е. поведение программы в целом. Затем описывается поведение различных компонент. Затем, только тогда, когда все аспекты поведения будут выделены и описаны, программисты-разработчики приступят к написанию исходного текста.
3. Основные этапы проектирования программной системы
Сначала надо выполнить анализ функционирования (поведения) системы. Это объясняется тем, что поведение системы обычно известно задолго до остальных ее свойств.
Предшествовавшие методы разработки ПО концентрировались на таких идеях, как характеристики основных данных или же общая структура вызова функций. Но структурные элементы программы могут быть определены только после интенсивного анализа задачи. Поэтому формирование формальной спецификации на первом этапе часто заканчивается созданием документа, который не понимают ни программисты, ни клиенты.
Но поведение – это нечто, что может быть описано в момент возникновения идеи программы и выражено в терминах, имеющих значение как для программиста, так и для клиента.
В разработке системы с использованием объектно-ориентированного проектирования можно выделить несколько основных этапов, на каждом из которых главную роль играет все более детальный анализ поведения системы.
Уточнение спецификации (постановки задачи)
Исходные спецификации обычно двусмысленны и непонятны во всем, кроме наиболее общих положений. На этом этапе надо уточнить, чем будет конечный продукт и обсудить структуру будущей программной системы. Уточненная спецификация передается для дальнейшего обсуждения клиенту.
Идентификация компонент
Создание сложной системы, вроде здания или автомобиля, упрощается с помощью разбиения проекта на структурные единицы. Аналогично, разработка программ облегчается после выделения в них отдельных компонент. Компонента – это просто абстрактная единица, которая может выполнять определенную работу (т.е. иметь определенные обязанности). На этом этапе нет необходимости знать в точности то, как задается компонента и как именно она будет выполнять свою работу. В конечном счете компонента может быть преобразована в отдельную функцию, структуру или класс, или же в совокупность других компонент (шаблон).
Разработка документации
Разработку документации следует начинать уже на первых этапах разработки проекта. Документация включает в себя два основных документа: руководство пользователя и проектную документацию. Эти документы начинают разрабатываться задолго до написания исходного текста. В руководстве пользователя описывается взаимодействие с системой с точки зрения пользователя. Это руководство может служить для проверки того, как концепция разработчиков соответствует мнению клиента.
В проектной документации протоколируются основные решения, принятые при планировании программы. Сначала в ней приводится глобальное описание системы, а затем совершается переход к уровню отдельных компонент. Чересчур детальное описание внутреннего устройства компонент может затруднить понимание системы в целом.
Выбор представления данных
На данном этапе команда разработчиков разделяется на группы, отвечающие за конкретные компоненты программы. Теперь надо решить, как перейти от описания компоненты к конкретному коду. Главное здесь – проектирование структур данных, которые будут использоваться каждой компонентой для хранения внутренней информации, а также преобразование описания поведения компонент в алгоритмы.
Реализация компонент
Если предыдущие этапы выполнены корректно, то каждая обязанность или поведение будут кратко охарактеризованы, выбраны структуры данных и сформированы алгоритмы. Теперь надо записать их на языке программирования. На этом этапе детально разрабатываются конкретные компоненты. Для программистов, работающих над проектом, крайне важно понимать, как отдельный фрагмент кода подключается к более высокому уровню, и уметь работать в составе группы. При реализации каждой компоненты надо проверить, правильно ли она работает, если вызвать ее с корректными входными значениями.
Интеграция компонент
Когда индивидуальные компоненты разработаны и протестированы, они должны быть интегрированы в конечный продукт. Это делается поэтапно, начиная с элементарной основы (макета системы), к которой постепенно добавляются новые элементы. Для еще не реализованных частей применяются заглушки. Постепенно заглушки заменяются настоящим кодом и проводится тестирование. Этот процесс называется тестированием системы в целом.
Если ошибка, проявляющаяся в одной из компонент, оказывается вызвана некорректным кодом в другой, то эта ошибка исправляется и тестирование повторяется. Этот процесс называется регрессионным тестированием.
Сопровождение и развитие
С передачей продукта пользователю работа разработчиков не завершается. Практически всегда требуется дополнительное сопровождение программного обеспечение. Это вызвано необходимостью исправлять ошибки, изменением требований к системе в связи с появлением новых технических и государственных стандартов, переходом на новую аппаратную платформу, изменением запросов пользователей (м.б., в связи с появлением конкурирующих продуктов).
|
