Дж. Рамбо, М. Блаха - UML 2.0 - Объектно-ориентированное моделирование и разработка (1158633), страница 86
Текст из файла (страница 86)
На этом этапе формируется в первую очередь модель взаимодействия, однако модели классов и состояний тоже не остаются без изменений. 358 Глава 1б ° Резюме процесса разработки 16.3. Проектирование Анализ отвечает на вопрос «что делает приложение», а проектирование говорит «как это делается». Добившись полного понимания устройства приложения на этапе анализа, вы можете переходить к построению практического решения, которое можно будет впоследствии поддерживать. Модель для проектирования может быть совершенно независимой от аналитической модели, но чаще всего оптимальный подход состоит в перенесении классов аналитической модели в проектную модель.
После этого проектирование сводится к детализации модели и к принятию решений. Проектирование делится на два этапа: проектирование системы и проектирование классов. 16.3.1. Проектирование системы Цель проектирования системы — выработать высокоуровневую стратегию (архитектуру) решения задачи по созданию приложения. Выбор архитектуры — это важное решение, обладающее широким спектром последствий. Этот выбор основывается на предьявляемых требованиях и на предыдущем опыте. Проектировщик системы должен определить политику, которая будет направлять действия на следующем этапе. 16.3.2. Проектирование классов Проектирование классов сводится к расширению и корректировке аналитических моделей реального мира.
При этом модель подготавливается к реализации. Проектировщики классов формируют завершенные определения классов и ассоциаций, а также выбирают алгоритмы для операций. Реализация В первой и второй части мы описали объектно-ориентированные концепции и процедуры анализа и проектирования, в ходе которых эти концепции применяются. В третьей части речь пойдет об оставшихся этапах процесса разработки программного обеспечения. Мы обсудим конкретные детали реализации систем с использованием С++, Дача и баз данных.
Объектно-ориентированные модели можно применять с любыми языками, но в этой книге мы не будем рассматривать языки, не относящиеся к числу объектно-ориентированных, потому что большинство разработчиков в наше время такие языки не используют. В главе 17 обсуждаются вопросы реализации, не зависящие от выбора языка. Речь пойдет о методах реализации ассоциаций, потому что большинство языков не имеют встроенной поддержки элементов этого типа. В главе 18 рассматриваются принципы реализации объектно-ориентированного проекта на С++ и 1ача.
Мы выбрали именно эти языки потому, что они наиболее популярны среди языков программирования. В главе 19 показано, как можно реализовать проект при помощи базы данных. Опять же, мы рассматриваем реляционную базу данных потому, что базы такого типа доминируют на рынке. Логично предположить, что объектно-ориентированный проект можно реализовать и в объектно-ориентированной базе данных, но такие базы недостаточно широко распространены и используются только в особых случаях. В главе 20 приведены рекомендации по стилю программирования на любом языке.
В конце концов решением любой задачи становится код программы, а потому от стиля кодирования зависит легкость обслуживания и возможность расширения системы. Третья часть книги завершает рассказ о том, как нужно разрабатывать приложения с помощью объектно-ориентированных концепций. В четвертой части мы расскажем о вопросах проектирования программного обеспечения, относящихся к большим и сложным приложениям.
ф ~!Дф Моделирование реализации Реализация (ппр1ешепта11оп) — это последний этап разработки, на котором приходится иметь дело со спецификой языков программирования. Реализация должна быть очевидной, почти автоматической, потому что все сложные решения нужно было принять на этапе проектирования. Вам предстоит перевести эти решения на язык программирования.
Добавление деталей в процессе написания кода неизбежно, но эти детали не должны затрагивать большие участки программы. 17.1. Обзор реализации Пришло время пожинать плоды своих трудов. На этапе реализации вы сможете воспользоваться результатами тщательной подготовки к решению задачи, которая была проведена раньше, на этапах анализа и проектирования. В первую очередь нужно заняться вопросами реализации, не зависящими от выбранного языка.
Это мы называем моделированием реализации (1шр1ешепгаг1оп шоде11пя). Данный этап состоит из следующих шагов; 1. Уточнение классов (раздел 17.2). 2. Уточнение обобщений (раздел 17.3). 3. Реализация ассоциаций (раздел 17А). 4. Подготовка к тестированию (раздел 17.5). Первые два шага мотивируются теорией преобразований. Преобразование (сгапз(огшаг1оп) — это отображение из области моделей в диапазон моделей.
при моделировании нужно ориентироваться на требования заказчика, но при этом смотреть на вещи с абстрактной математической точки зрения. 17.2. Уточнение классов 361 17.2. Уточнение классов Регвепнете!пге Регвблгпясе! пге регвалыате Ьотедббгевв ЬотеРЬоле регвопмете ЬотеАббгевв ЬотеРЛале Рис. 17.1. Разбиение класса ° Слияние классов. Слияние — это процедура, обратная разбиению.
Если бы мы начинали с классов РегзопНоте7п7о и РегтопОД~се7п~о с рис. 17.1, мы могли бы объединить их. На рис. 17.2 показан другой пример с ассоциациями. В данном случае нельзя сказать, что одно представление само по себе лучше другого, потому что с математической точки зрения они идентичны друг другу. Кроме того, нужно учитывать влияние принятых решений на ассоциации и обобщения. Рис.
17.2. Слияние классов ° Разбиение и слияние атрибутов. Описанные выше приемы можно применять и к атрибутам, что демонстрирует рис. 17.3. Иногда бывает полезно подкорректировать классы, прежде чем приступать к написанию кода, чтобы упростить разработку или повысить производительность. Не забывайте, что цель реализации состоит в том, чтобы воплотить в жизнь модели, полученные на этапах анализа и проектирования. Не изменяйте проектную модель, если для этого нет достаточно веских причин. Если же такие причины есть, вы можете рассмотреть следующие возможности.
° Разбиение класса. На рис. 17.1 мы можем объединить рабочий и домашний адреса в одном классе или разделить эту информацию между двумя классами. Оба подхода вполне допустимы. Если данных много, нх лучше разделить. Если данных не слишком много, их можно объединить. Разбиение класса может быть усложнено обобщениями и ассоциациями. Например, если класс Регзоп (Человек) был суперклассом для каких-то других классов, то после его разбиения подклассам будет сложно получить всю информацию. Придется либо допустить множественное наследование, либо устанавливать ассоциацию между классами РегзопНоте1п~о и РетзопОЯ1се!пуо. Если же класс Репюп будет связан с другими классами какими-либо ассоциациями, вам придется решать, как их можно изменить.
Зб2 Глава 17 ° й1оделнрованне реализации РьепеннгпЬег рьопенигпЬег Рис. 17.3. Разбиение н слияние атрибутов ° Превращение атрибута в класс или класса в атрибут. Как показано на рнс. 17А, мы можем представить адрес в виде атрибута, одного класса илн нескольких родственных классов. Нижний вариант может быть полезен для предварительной загрузки данных в приложение. Рнс. 17.4. Превращение атрибута в класс н класса в атрибут Пример с банкоматом. Мы можем разделить Сизготег.асцгея (Клиент. адрес) на несколько классов, если планируем осуществлять предварительную загрузку данных об адресах клиентов. Например, мы можем загрузить значения сггу (город), згагергоипсе (штатОбласть) н розга/Сог(е (нндекс) для удобства сотрудников службы поддержки.
Мы можем выделить атрибут Ассоилдгуре в отдельный класс. Это упростит программирование специального поведения. Например, можно запрограммировать разные меню для вкладов до востребования и срочных вкладов. В любом случае, наша модель не так уж велика, и мы готовили ее достаточно аккуратно, так что вряд ли сможем внести в нее много полезных изменений на данном этапе. 17.3. Уточнение обобщений Корректировать можно не только классы, но и обобщения.
Иногда бывает полезно удалить одно обобщение или добавить другое перед переходом к непосредственному кодированию. 17.1. Реализация ассоциаций 363 На рис. 17.5 показана модель перевода, взятая из одного приложения, которым недавно занимались авторы этой книги. Служба перевода преобразует тгапз!агюпСопсерг (ПереводимоеПонятие) в Рптазе (Фраза) на требуемом языке. Ма7ог Аапяиаяе (ОсновнойЯзык) — это обычный язык (английский, французский и т. п.).
Мгпо~Еапйиояе — это диалект языка (американский английский, австралийский английский и т. п.). Все подлежащие переводу записи в базе данных приложения имеют идентификатор гтапз(агюпСопсерг(Р. Переводчик сначала пытается найти фразу, соответствующую понятию, в указанном МгпогХапяиаяе, а затем, если не удается, переходит к соответствующему Мглот1.апдиаде.
ра Рис. 17.5. Добавление н удаление обобщений Для простоты реализации мы удалили обобщение и использовали модель, представленную в правой части рисунка. Поскольку служба перевода отделена от модели приложения, нам не пришлось рассматривать никаких дополнительных обобшеннй, и упрошение не вызвало проблем. Пример с банкоматом. В разделе 13.1.1 мы отметили, что модель классов предметной области банкомата охватывает два приложения: собственно банкомат и кассовый терминал. На этапе анализа мы не стали беспокоиться на этот счет, потому что нам нужно было понять бизнес-требования, а клиента в принципе не волнует структура предоставляемых сервисов. Кроме того, нам нужно было обеспечить одинаковое поведение обоих приложений.
Однако на этапе реализации мы должны отделить приложения друг от друга и ограничить объем работы. На рис. 17.6 мы удалили из модели классов часть, относящуюся к кассовому аппарату, в результате чего исчезли оба обобщения. На рис. 17.6 представлена полная модель классов банкомата.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
