2. Язык UML. Руководство пользователя. Буч_ Рамбо_ Якобсон (2-е издание) (2006) (1185732), страница 25
Текст из файла (страница 25)
Моделирование схемы базы данныхПрямое и обратное проектированиеОбщиепринципыи назначениемоделирования обсуждаютсяв главе 1.Как бы ни было важно моделирование, вы должны помнить,что главный продукт разработчиков – всеFтаки программное обеспечение, а не диаграммы. Конечно, назначение модели состоит в том,чтобы представить ПО, которое своевременно удовлетворяет изменяющиеся нужды его пользователей и требования бизнеса. По этойпричине важно, чтобы создаваемые модели и их практическое воплощение четко соответствовали друг другу, причем с минимумомзатрат (а лучше – совсем без таковых) на поддержание их в синхронизированном виде.ДиаграммыВ ряде случаев модели, которые вы создаете, вообще не отрадеятельнос- жаются в коде.
Например, если вы моделируете бизнесFпроцесс,ти обсужда- используя диаграмму деятельности, то многие ее элементы (деютсяятельности) касаются людей, а не компьютеров. А иногда задача зав главе 20.ключается в моделировании системы, части которой на выбранномвами уровне абстракции представляют собой элементы аппаратного обеспечения (хотя на другом уровне абстракции лучше показатьсовокупность компьютеров и программного обеспечения).И все же разрабатываемые вами модели чаще преобразуютсяв код. UML не регламентирует никакого конкретного отображенияна конкретный объектноFориентированный язык программирования,128Диаграммы классовно проектировался, подразумевая такую возможность. Особенноэто касается диаграмм классов, содержимое которых ясно отображается на все распространенные объектноFориентированные языки программирования, в частности Java, C++, Smalltalk, Eiffel, Ada,ObjectPascal и Forte.
Кроме того, UML предусматривает отображение на коммерческие объектные языки, такие как Visual Basic.Стереотипыи помеченные значенияобсуждаются в главе 6.На заметку. Отображение UML на конкретные языки реализации для прямого и обратного проектирования выходитза круг тем, обсуждаемых в этой книге. На практике вам придется иметь дело со стереотипами и помеченными значениями, настроенными специально под используемый вамиязык программирования.Прямое проектирование (forward engineering) – это процесстрансформации модели в код посредством отображения на язык реализации.
В результате прямого проектирования происходит потеряинформации, поскольку модели, описанные на UML, семантическибогаче, чем любой современный объектноFориентированный языкпрограммирования. Фактически это главная причина существованиямоделей наряду с кодом. Структурные средства, например кооперации, и поведенческие, например взаимодействия, могут быть ясновизуализированы с помощью UML, но не так ясно – в исходном коде.Чтобы осуществить прямое проектирование диаграммы классов, необходимо: Идентифицировать конкретные правила отображения классов в код для выбранного вами языка (или языков) реализации.
Эти правила будут касаться проекта в целом либо всейвашей организации. Если требуется, в зависимости от семантики выбранных языков установить ограничения на некоторые средства UML.Например, UML позволяет моделировать множественноенаследование, а Smalltalk допускает только одиночное. Выможете либо запретить разработчикам моделировать множественное наследование (что делает вашу модель зависимой от языка), либо разработать идиому, которая трансформирует эти богатые средства в язык реализации (чтонесколько усложняет отображение). Использовать помеченные значения для указания параметров реализации на вашем целевом языке программирования.Вы можете делать это на уровне индивидуальных классов,если нужен тонкий контроль, или же на более высоком уровне (например, на уровне коопераций или пакетов).
Использовать инструменты для генерации кода.Типичные приемы моделированияОбразцыобсуждаются в главе 6.129На рис. 8.4 вы видите простую диаграмму классов, представляющую реализацию образца цепочки обязанностей (responsibilitypattern). Эта конкретная реализация включает три класса: Client(Клиент), EventHandler (ОбработчикСобытий) и GUIEventHandler (ОбработчикСобытийGUI)4. Классы Client и EventHandler – абстрактные,GUIEventHandler – конкретный. К EventHandler относится обычная операция, предусмотренная этим образцом, – handleRequest (обработатьЗапрос), хотя к его реализации добавлено два закрытых атрибута.«Java Target»«Java Target»«Java Target»Рис. 8.4.
Прямое проектированиеВсе эти классы предполагают отображение на язык Java, какотмечено в их стереотипе. Прямое проектирование классов даннойдиаграммы на Java достаточно просто при использовании инструментальных средств. Прямое проектирование класса EventHandlerна Java генерирует следующий код:public abstract class EventHandler {EventHandler successor;private Integer currentEventID;private String source;EventHandler() {}public void handleRequest() {}}Обратное проектирование (reverse engineering) – это процесстрансформации кода в модель.
Обратное проектирование порождает избыток информации, часть которой представлена на болеенизком уровне детализации, чем нужно для построения удобной4Graphical User Interface – графический интерфейс пользователя. – Прим. ред.130Диаграммы классовмодели. В то же время обратное проектирование неполно: при прямом проектировании модели в код происходит потеря информации, поэтому невозможно точновосстановить модель из кода, если только используемый вами инструмент не кодирует информацию в виде комментариев к исходному коду, которые выходят запределы семантики языка реализации.Чтобы осуществить обратное проектирование диаграммы классов, необходимо: Идентифицировать правила отображения для выбранного языка или языков реализации – это вам понадобится сделать для всего проекта или всейорганизации.
Используя какоеFлибо инструментальное средство, указать код, которыйнужно подвергнуть обратному проектированию. Применяйте инструментдля генерирования новой модели или модификации существующей, в отношении которой ранее применялось прямое проектирование. Не стоит ожидать, что обратное проектирование породит единственную компактнуюмодель на основе большого фрагмента кода. Вам придется выбирать небольшие фрагменты кода и строить из них модель. Просматривая модель, создать диаграмму классов с помощью какогоFлибоинструментального средства.
Например, вы можете начать с одного или нескольких классов, а затем расширять диаграмму, прорабатывая конкретныесвязи или включая соседние классы. Показывайте или скрывайте деталидиаграммы в соответствии с вашими намерениями. Вручную добавить к модели информацию о проектировании, чтобы показать те аспекты дизайна, которые пропущены или скрыты в исходномкоде.Советы и подсказкиСоздавая диаграммы классов на UML, помните, что каждая из них – это лишьграфическое изображение статического представления дизайна системы. Ни однадиаграмма классов не обязана включать все, что касается представления дизайна системы.
Однако диаграммы классов в совокупности сообщают пользователюполную информацию, необходимую для статического представления системы;хотя каждая из них представляет только один ее аспект.Хорошо структурированная диаграмма классов: сфокусирована на одном аспекте статического представления дизайна системы; содержит только те элементы, которые существенны для понимания данного аспекта; обеспечивает детализацию, соответствующую уровню абстракции диаграммы, включая только дополнения, важные для понимания; не настолько упрощена, чтобы создать у читателя ложное представлениео важной семантике.Советы и подсказки131Когда вы рисуете диаграмму классов: присваивайте ей имя, соответствующее ее назначению; избегайте пересечения линий или хотя бы минимизируйте его; организуйте элементы так, чтобы семантические близкие сущности располагались рядом; используйте примечания и цвета в качестве меток, акцентирующих внимание на важных деталях диаграммы; постарайтесь не показывать слишком много видов связей.
Вообще, на каждой диаграмме классов должен доминировать только один вид связей.Часть IIIРасширенное структурноемоделированиеГлава 9.Расширенные классыГлава 10. Расширенные связиГлава 11. Интерфейсы, типыи ролиГлава 12. ПакетыГлава 13. ЭкземплярыГлава 14. Диаграммы объектовГлава 15. КомпонентыВведениеГлава 9.
Расширенные классыВ этой главе:Классификаторы, особенности атрибутов и операций, разныевиды классовМоделирование семантики классаВыбор правильного типа классификатораКлассы – это наиболее важные строительные блоки любой объектноFориентированной системы. Однако они представляют собой всего лишь одну из разновидностей более общих строительных блоковUML – классификаторов.
Классификатором называется механизмописания структурных и поведенческих свойств элемента системы.К классификаторам относятся классы, интерфейсы, типы данных,сигналы, компоненты, узлы, варианты использования и подсистемы.Классификаторы (и в особенности классы) помимо простыхОбщиесвойств – атрибутов и операций, описанных в части II данной книсвойстваги, – имеют много расширенных.
Вы можете моделировать множесклассовобсуждают- твенность, видимость, сигнатуры, полиморфизм и другие характеся в главе 4.ристики. В UML моделировать семантику класса можно так, чтобыописать его значение на любом уровне формализации по вашемуусмотрению.Существует несколько видов классификаторов и классов; важно выбрать такой, который наилучшим образом моделирует вашуабстракцию реального мира.135материал будет диктовать последующие проектные решения – скажем, выбор между деревом и сталью повлияет на массу строения,которую нужно поддерживать.Продолжая работать над проектом, вы будете уточнять базовыепроектные решения и добавлять детали, существенные для инженераFпроектировщика, чтобы он проверил безопасность конструкций, и для строителя, – чтобы выполнил сборку.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
