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