Освой самостоятельно С++ за 21 день.
Шрифт:
При определении бюджета и сроков следует учесть два момента.
• Если вы определили, во сколько в среднем обойдется проект, то попросите немного больше, тогда, может быть, вам дадут ту сумму, на которую вы рассчитывали.
• Закон Либерти утверждает, что на все требуется больше времени, чем ожидалось,
даже если был учтен закон Либерти.
После того как время и бюджет будут установлены, определитесь с приоритетами. Вы все равно не уложитесь в срок, будьте к этому готовы. Важно, чтобы к тому моменту, когда нужно будет что-то показывать, у вас уже было что показать. Если вы строили мост, а время уже истекло, то позаботьтесь о том, чтобы была проложена хотя бы велосипедная дорожка.
Ко всем цифрам, зафиксированным в документации, следует относиться серьезно, но не "брать дурного в голову". В начале работ фактически невозможно точно оценить сроки выполнения проекта. Желательно приберечь для себя от 20 до 25% времени для маневра, если в ходе выполнения проекта возникнут неожиданности. В конце концов, для всех важен успех проекта и обоснованные колебания в сроках всегда допустимы.
Примечание:Мы вовсе не призываем к бесшабашному отношению к срокам, зафиксированным в документе. Просто реалии таковы, что на ранних этапах планирования невозможно точно определить, сколько времени и денег потребуется на разработку этого проекта. Приоритетом при этом должна быть максимальная реализация требований заказчика, что, вполне вероятно, может вызвать необходимость корректировки исходных цифр при выполнении проекта.
Визуализация
Визуализация является финальной частью документа требований. Такое модное название носят диаграммы, рисунки, изображения экранов, прототипы и другие визуальные средства, созданные для того, чтобы помочь в проектировании графического интерфейса пользователя создаваемого продукта.
При создании больших проектов бывает полезно разработать полный прототип проекта, чтобы лучше представить, как поведет себя система в тех или иных ситуациях. Часто графическое приложение к документации лучше всего справляется с функцией определения требований к проекту, так как позволяет наглядно увидеть, какой должна быть система и как она должна работать в конечном варианте.
Артефакты
К концу каждого этапа анализа и проектирования накапливается ряд документов, называемых артефактами. Приблизительный набор таких документов показан в табл. 18.1. Эти документы используются для организации взаимодействия и протоколирования отношений между заказчиком и исполнителем. Их подписание обеими сторонами гарантирует, что исполнитель четко понял и принял все требования заказчика и обязуется разработать в указанные сроки проект, который в окончательном варианте должен выполнять точно определенный ряд функций.
Таблица 18.1. Артефакты, составляющие документацию проекта
Проектирование
Во время анализа основное внимание уделяется рассмотрению домена и определению задач и требований к проекту, в то время как проектирование сосредоточено на поиске решений. Проектирование — это планирование практической реализации нашей идеальной модели средствами программирования. Результатом этого процесса является создание документа проекта приложения.
Документ проекта состоит из двух разделов: проекта классов и архитектуры приложения. Первый раздел, в свою очередь, содержит статический (описание различных классов, их структуры и характеристик) и динамический (описание взаимодействий
классов) подразделы.В разделе "Архитектура приложения" определяется время жизни различных объектов, их взаимоотношения, системы передачи объектов и другие механизмы реализации классов. Далее на этом занятии основное внимание уделяется проектированию классов, а все оставшиеся занятия посвящены рассмотрению различных структур архитектуры приложения.
Что такое классы
Изучая материалы этой книги, вы уже не раз делали попытку создавать классы в программах на языке C++. Но поскольку в данный момент речь идет не о разработке программы, а о ее проектировании, следует различать проекты классов и их реализацию средствами C++, хотя, безусловно, эти моменты тесно взаимосвязаны. Каждому классу в проекте будет соответствовать класс в программном коде, но все же не надо их путать. Ведь для реализации спроектированного класса можно использовать другой язык программирования, и даже в пределах C++ для реализации класса можно использовать различные средства программирования.
Далее не будем заострять на этом внимание, просто помните, что если планируется создать класс Кот с методом Мяу, то в программу будут добавлены класс Cat с методом
Meow, хотя реализовать их можно по-разному. Обратите внимание, что в тексте книги для классов проекта и классов программы использованы разные стили, чтобы помочь вам отличать их. Классы модели приложения отображаются в диаграммах UML, а классы C++ — в коде программы, который можно скомпилировать и запустить.
У начинающих программистов часто возникает проблема с определением необходимого количества классов для программы и функций, которые должен выполнять каждый отдельный класс. Один из наиболее упрощенных подходов к решению этой проблемы состоит в записи сценария для ситуации использования приложения. Затем можно попытаться создать классы для каждого сушествительного (объекта), упоминающегося в этом сценарии. Возьмем для примера приведенный ниже сценарий.
Клиент выбирает операцию снятия наличных с расчетного счета. На счете в банке имеется достаточная сумма, в ATM достаточно наличных и заправлена лента для квитанций, а сеть включена и работает. Кассовый аппарат ATM просит указать сумму, которая не должна превышать $300. Машина выдает указанную сумму и печатает квитанцию для клиента.
Из этого сценария можно извлечь такие классы:
• клиент;
• сумма;
• наличные;
• расчетный счет;
• счет;
• квитанция;
• лента для квитанций;
• банк;
• ATM;
• сеть;
• снятие со счета;
• машина.
Объединив синонимы и явно взаимосвязанные объекты, получаем следующий список:
• клиент;
• наличные (суммы на счете и снимаемая со счета);
• расчетный счет;
• счет;
• квитанции;
• ATM (кассовый аппарат);
• сеть.
Пока что неплохо для начала. Можно затем отобразить отношения между классами, как показано на рис. 18.12.
< image l:href="#"/>Рис. 18.12. Предварительная схема отношений между классами
Преобразования
Описанный в предыдущем разделе подход называется преобразованием объектов домена в объекты проекта. Большинству объектов домена в проекте соответствуют суррогаты. Термин "суррогат" вводится для того, чтобы отличать реальную квитанцию, выданную кассовым аппаратом, от виртуального объекта в программе, являющегося абстракцией, реализованной в программном коде.