М. Фаулер, К. Скотт - UML Основы (1114905), страница 11
Текст из файла (страница 11)
Как говорит Брэд Кайн (Вгат) Ка)п): «Анализ возможен только тогда, когда рядом находится эксперт предметной области (в противном случае это не анализ, а псевдоанализ)». В ходе выполнения проекта постарайтесь понять, как будут кооперироваться классы с целью обеспечения функциональности, требуемой каждым вариантом использования. Я полагаю, что для представления подобных взаимосвязей могут оказаться весьма полезными СВС-карточки и диаграммы взаимодействия. При этом будут выявлены ответственности и операции, которые могут быть представлены на диаграмме классов.
Построение Я9 Рассматривайте эти результаты как предварительный набросок и как средство для обсуждения с вашими коллегами различных подходов к проектированию. Только достигнув согласия в этих вопросах, можно приступать к написанию кода. Не прощающий ничего программный код неизбежно вскроет все недостатки проекта. Не бойтесь вносить изменения в проект в процессе его изучения. Если подобные изменения серьезны, то следует использовать специальные обозначения для последующего обсуждения идей со своими коллегами. После того как вы разработали программное обеспечение, для подготовки документации о проделанной работе может быть использован язык ПМ1 . Я пришел к выводу, что диаграммы языка ()МАЙ.
оказываются весьма полезными для достижения общего понимания системы. Однако должен подчеркнуть, что при этом вовсе не имею в виду построение детальных диаграмм для системы в целом. В этой связи уместно процитировать Уорда Каннингхема ( ч(тагс) Сппп1пя)таш), 1996 [16]: Ти(отельно подобранные и аккуратно написанные заметки могут легко заменить традиционную обширную проектную документацию. Последняя скорее затмевает суть, за исключением некопюрых отдельно взятык аспектов. Выделите эти аспекты ... и зобудыпе обо всем остальном.
Я полагаю, что подробную документацию следует разрабатывать на основе готового программного кода (подобно, например, дача1)ос). Чтобы обратить внимание на наиболее важные понятия, лучше подготовить дополнительную документацию. Считайте ее составной частью первого этапа знакомства с программой, перед тем как приступить к детальному изучению кода. Я предпочитаю представлять документацию в форме текста, достаточно краткого, чтобы прочесть его за чашкой кофе, и с использованием диаграмм языка 11М1, которые помогают придать наглядный характер обсуждению. Я использую диаграмму пакетов (см. главу 7) как своего рода логическую карту дорог системы.
Эта диаграмма помогает мне понять логические блоки системы и обнаружить зависимости между ними (держа их под контролем). Диаграмма развертывания (см. главу 10) может существенно улучшить понимание на этой стадии, поскольку позволяет представить общую физическую картину системы. Для каждого пакета предпочтительнее строить диаграмму классов уровня спецификации. При этом я не указываю каждую операцию в том или ином классе, а показываю только те ассоциации, ключевые атрибуты и операции, которые помогают мне понять основные идеи реализации.
Такая диаграмма классов служит своего рода оглавлением в форме графической таблицы. Если некоторый класс в течение своего жизненного цикла имеет сложное поведение, то для описания такого поведения я изображаю диаграмму состояния (см. главу 8). Но поступаю так только в том случае, Глава 2. Основы процесса разработки когда поведение действительно является достаточно сложным, что, кстати, встречается не так уж и часто. Обычно сложными бывают взаимодействия между классами, для описания которых я строю диаграммы взаимодействия.
В книгу также включаются некоторые фрагменты программного кода, достаточно важные для системы и написанные аккуратным стилем. Для особо сложных алгоритмов используется диаграмма деятельности (см. главу 9), но только в том случае, если она помогает понять алгоритм лучше, чем сам код. Коли я сталкиваюсь с часто повторяющимися понятиями, то для опи- сания их основных идей использую образцы (см.
врезку). Образцы Язык ~3МЬ позволяет описать объектно-ориентированный проект. С другой стороны, образцы фиксируют внимание на результатах этого процесса — на моделях примеров. Многие аналитики высказывают мнение о том, что целый ряд проблем при выполнении проектов вызван весьма слабым представлением разработчиков об отдельных проектных решениях, которые хорошо известны более опытным коллегам. Образцы как раз и служат для описания наиболее общих способов решения проблем. Они накапливаются у тех разработчиков, которые умеют находить в своих проектах повторяющиеся решения. Эти разработчики описывают каждое решение таким образом, чтобы другие люди могли изучить этот образец и понять, как его применить.
Рассмотрим следующий пример. Допустим, имеется несколько объектов, которые выполняются некоторым процессом на вашем персональном компьютере, при этом им необходимо взаимодействовать с другими объектами, которые выполняются в рамках другого процесса. Возможно, второй процесс также выполняется на вашем компьютере, а может быть, и где-нибудь еще. При этом вы хотите избавить объекты вашей системы от проблем, связанных с поиском других объектов в сети или с выполнением вызовов удаленных процедур. Для реализации такого пожелания можно создать внутри вашего локального процесса некий объект-заместитель (ргоху) для удаленного объекта.
Заместитель обладает тем же интерфейсом, что и удаленный объект. Ваши локальные объекты будут обращаться к заместителю, используя обычный механизм передачи сообщений внутри процесса. При этом заместитель отвечает за последующую передачу любых сообщений реальному объекту, где бы тот ни находился.
51 Построение На рис. 2.2 изображена некоторая диаграмма классов (см. главу 4), которая иллюстрирует структуру образца Заместитель. Рис. 2.2. Структура проектного образца Заместитель Заместители являются обычным средством, используемым в вычислительных сетях и других приложениях. Разработчиками уже накоплен большой опыт в использовании заместителей, в частности, как их можно применять, какие при этом можно получить преимущества, какими обладают ограничениями и как их следует реализовать. В книгах по методологии, подобных этой, такой опыт не обсуждается; все они рассматривают только способы графического изображения заместителя.
Хотя все это также полезно, тем не менее, обсудить опыт использования заместителей было бы более интересно. Начиная с 1990-х годов, некоторые разработчики стали обобщать свой опыт в этом направлении. Они объединились в сообщество, заинтересованное в написании образцов. Эти разработчики выступили в качестве спонсоров конференций и выпустили ряд книг. Наиболее известной из этих книг является книга »Банды четырех» (Гамма, Хелм, Джонсон и Влиссидес, 1995 120)), в которой детально рассматриваются 23 проектных образца.
Если вы хотите узнать что-либо о заместителях, именно эта книга является самым подходящим источником. В ней с десяток страниц посвящен каждому образцу, при этом детально описывается взаимодействие объектов, преимущества и недостатки этого образца, его модификации и особенности использования, а также даются полезные советы по его реализации на языках Зша11$а1)с и С++.
52 Глава 2. Основы процесса разработки Заместитель — это проектный образец, поскольку он описывает некоторый метод проектирования, Образцы также могут существовать и в других областях. Предположим, вы проектируете систему для управления рисками на финансовых рынках.
Вам необходимо знать, как с течением времени изменяется стоимость портфеля ценных бумаг. Это можно сделать, отслеживая цену каждой акции через определенные промежутки времени и отмечая ее изменение. Но вам также желательно иметь возможность оценивать степень риска в различных гипотетических ситуациях (например, «Что произойдет, если резко упадет цена на нефть7»). Для этого можно построить некий Сценарий, который содержит все множество цен на акции. После чего можно определить отдельные Сценарии для цен за прошедшую неделю, оптимистических прогнозов на следующую неделю, прогнозов на следующую неделю в предположении резкого падения цен на нефть и т.
д. Образец Сценарий (рис. 2.3) является образцом анализа, поскольку он описывает фрагмент модели предметной области. Рис. л.з. Образец Сценария для анализа Предназначенные для анализа образцы имеют большое значение, поскольку именно с них лучше всего начинать работу в новой предметной области. Я сам начал коллекционировать образцы для анализа, когда столкнулся с серьезными проблемами в некоторых новых предметных областях. Я знал, что являлся отнюдь не первым разработчиком, кто занимается их моделированием, но всякий раз был вынужден начинать с чистого листа бумаги. Интересной особенностью образцов для анализа является то, что они могут оказаться полезными в самый неожиданный момент.
Когда я начал работать над проектом корпоративной системы финансового анализа, мне чрезвычайно помогли образцы, накопленные мною ранее при выполнении проекта для системы здравоохранения. Дополнительную информацию об образце Сценарий или других образцах анализа можно найти в моей книге (Фаулер, 1997 ~18)). 53 Внедрение Образец — зто нечто гораздо большее, чем просто модель. Образец должен также включать обоснование, почему он именно такой, какой есть. Часто говорят, что образец является решением той или иной проблемы. Образец должен придать проблеме необходимую ясность, объяснить, почему он является решением данной проблемы„а также в каких ситуациях он работает или не работает.
Образцы очень важны, поскольку являются этапом, следующим за пониманием основ языка или метода моделирования. Образцы предлагают вам набор готовых решений, а также показывают, что делает модель хорошей и как ее построить. Они обучают на примерах.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
