2. Язык UML. Руководство пользователя. Буч_ Рамбо_ Якобсон (2-е издание) (2006) (1185732), страница 81
Текст из файла (страница 81)
Точно так же при обратном проектированииисходного кода, двоичной библиотеки или исполняемой программы вы на самом деле выполняете обратное проектирование артефакта или набора артефактов, которые, в свою очередь, отображаются на классы или кооперации.Приступая к прямому проектированию (созданию кода из модели) класса или кооперации, вы должны решить, во что нужно ихпреобразовывать: в исходный код, двоичную библиотеку или исполняемую программу. Логическую модель имеет смысл превратитьв исходный код, если вас интересует управление конфигурациейфайлов, которые затем будут переданы среде разработки. Если жевас интересует управление артефактами, которые фактически будут развернуты в составе работающей системы, то логические модели следует непосредственно преобразовать в двоичные библиотекиили исполняемые программы.
Иногда нужно и то, и другое. Классуили кооперации можно поставить в соответствие как исходный код,так и двоичную библиотеку или исполняемую программу.Чтобы выполнить прямое проектирование диаграммы артефактов, необходимо: Идентифицировать классы и кооперации, которые реализует каждый артефакт. Выразить эту реализацию при помощисвязи материализации. Выбрать форму представления каждого артефакта. Это может быть либо исходный код (форма, поддающаяся управлению средствами разработки), либо двоичная библиотекаили исполняемая программа (форма, которая может бытьвключена в работающую систему). Использовать инструментальные средства для прямого проектирования модели.Обратноепроектированиедиаграммклассовобсуждаетсяв главе 8.Обратное проектирование диаграммы артефактов (создание модели из кода) – не идеальный процесс, поскольку при этом всегдапроисходит потеря информации.
По исходному коду можно обратно спроектировать классы – это в общемFто тривиальная задача.Обратное проектирование артефактов из исходного кода выявляетсуществующие между файлами зависимости компиляции. Если жеговорить о двоичных библиотеках, то самое большее, на что можно рассчитывать, – обозначить библиотеку как артефакт, а затем,используя обратное проектирование, раскрыть его интерфейсы.Это второе по распространенности действие, которое выполняется над диаграммами артефактов. Такой подход может быть полезен при ознакомлении с новыми плохо документированнымиТипичные приемы моделирования425библиотеками. Максимум, что можно сделать в отношении исполняемой программы, – обозначить ее как артефакт, а затем дизассемблировать ее код, но вряд ли стоит этим заниматься, если только выне пишете на языке ассемблера.Чтобы выполнить обратное проектирование диаграммы артефактов, необходимо: Выбрать целевое представление.
Исходный код можно реконструировать в артефакты, а затем в классы. Двоичные библиотеки можно подвергнуть обратному проектированию, чтобыраскрыть их интерфейсы. Исполняемые программы поддаютсяобратному проектированию в наименьшей степени. Используя инструментальные средства, указать код, который следует подвергнуть обратному проектированию.Использовать инструменты для генерации новой моделиили модификации существующей, для которой ранее быловыполнено прямое проектирование. Опрашивая модель и используя инструментальное средство,создать диаграмму артефактов – например, начать с одногоили нескольких артефактов, а затем расширить диаграмму, следуя по связям или переходя к соседним артефактам.Отображать или скрывать детали этой диаграммы артефактов в соответствии с вашими установками.В качестве примера на рис.
30.6 показана диаграмма артефактов, которая представляет результат обратного проектирования артефакта ActiveX vbrun.dll. Видно, что он реализует 11 интерфейсов.«manifest»«manifest»«manifest»«manifest»«manifest»«manifest»«manifest»«manifest»«manifest»«manifest»«manifest»Рис. 30.6. Обратное проектирование диаграммы артефактовДиаграммы артефактов426Имея перед глазами такую диаграмму, можно понять семантикуартефакта, перейдя к раскрытию его интерфейсных классов.Чаще всего при обратном проектировании исходного кода, а иногда и двоичных библиотек и исполняемых программ, прибегаютк помощи системы управления конфигурацией. Это означает, чтовы будете работать с конкретными версиями файлов и библиотек,совместимых друг с другом.
В таких случаях полезно включатьпомеченное значение, указывающее версию артефакта, – ее можетпредоставить система управления конфигурацией. Таким образом,можно использовать UML для визуализации истории артефактапри смене версий системы.Глава 31.
Диаграммы размещенияВ этой главеСоветы и подсказкиПри создании диаграмм артефактов на UML следует помнитьо том, что каждая такая диаграмма – это графическое представлениестатического представления реализации системы. А это значит, чтони одна отдельная диаграмма артефактов не должна отражать все,что известно о представлении реализации системы. Все диаграммыартефактов, взятые в совокупности, представляют систему с точкизрения реализации, но каждая в отдельности описывает лишь одинаспект.Хорошо структурированная диаграмма артефактов обладает следующими свойствами: сосредоточена на выражении какогоFто одного аспекта статического представления реализации системы; содержит только те элементы, которые существенны для понимания данного аспекта; представляет уровень детализации, соответствующий ее уровню абстракции, включая лишь те дополнения, которые важны для понимания на этом уровне; не настолько лаконична, чтобы неверно информировать читателя о важной семантике.Изображая диаграмму артефактов, необходимо руководствоваться следующими принципами: присваивать диаграмме имя, описывающее ее назначение; располагать элементы так, чтобы минимизировать количество пересекающихся линий; пространственно организовывать элементы так, чтобы семантически близкие сущности оказывались рядом; использовать примечания и цветовые выделения для привлечения внимания к важным моментам диаграммы; осторожно применять элементы со стереотипами.
Выделятьнебольшой набор общих для проекта (или организации)пиктограмм и использовать их согласованно.Диаграммыартефактов – второй виддиаграммдля моделированияфизическихаспектовобъектноNориентированныхсистем –обсуждаютсяв главе 30.Моделирование встроенных системМоделирование клиентсерверных системМоделирование полностью распределенных системПрямое и обратное проектированиеДиаграммы размещения – это один из двух видов диаграмм, используемых при моделировании физических аспектов объектноFориентированной системы. Такая диаграмма представляет конфигурацию узлов, где производится обработка информации, и показывает,какие артефакты размещены на каждом узле.Диаграммы размещения используются для моделирования статического представления системы с точки зрения размещения.В основном под этим понимается моделирование топологии аппаратных средств, на которых работает система.
По существу, диаграммы размещения – это просто диаграммы классов, сосредоточенныена системных узлах.Диаграммы размещения важны не только для визуализации,специфицирования и документирования встроенных, клиентFсерверных и распределенных систем, но и для управления исполняемыми системами с использованием прямого и обратного проектирования.ВведениеПри создании программной системы вы как разработчик программного обеспечения обращаете внимание в первую очередь на архитектуру и размещение своих программ в вычислительной среде.Но в качестве системного инженера вы заинтересованы главнымобразом в аппаратных и программных средствах системы и в том,как достичь оптимального их сочетания. Иными словами, разработчики программного обеспечения имеют дело с неосязаемыми артефактами вроде модели и кода, а разработчики систем – еще и с аппаратурой, вполне осязаемой.Диаграммы размещения428Хотя основное назначение языка UML – визуализация, специфицирование, конструирование и документирование программных артефактов, он применим также и для работы с аппаратнымиартефактами.
Из этого не следует, что UML – универсальный языкописания аппаратных средств наподобие VHDL. Однако он все жеспособен моделировать многие аппаратные аспекты системы, чегоразработчику программного обеспечения достаточно для описания платформы, на которой система будет работать, а системномуинженеру – для сопряжения программных и аппаратных средств.В UML представление о структуре программной системы дают диаграммы классов и компонентов. Для специфицирования поведенияпрограмм применяются диаграммы последовательности, коммуникации, состояния и деятельности.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
