Гради Буч - Объектно-ориентированный анализ и проектирование с примерами приложений на С++ (1158635), страница 51
Текст из файла (страница 51)
5-34 показан высший уровень диаграммы модулейдля нашей системы тепличного хозяйства. Раскрыв любую из показанныхсеми подсистем, мы обнаружим все ее модули.Рис. 5-34. Диаграмма модулей верхнего уровня для гидропоннойсистемыРассмотрим, как связаны физическая и логическая (рис. 5-7)архитектуры этой системы. Они практически изоморфны, хотя имеютсянебольшие различия. В частности, мы приняли решение отделить классыустройств нижнего уровня от категорий классов Климат и Удобрения, ипоместить соответствующие им модули в одну подсистему, названнуюУстройства.
Кроме того, мы разделили категорию классов Теплица на двеподсистемы, названные УправлениеКлиматом и ВнесениеУдобрений.Дополнительные понятияДругие типы модулей. Некоторые языки, прежде всего Ada,определяют типы модулей, отличные от простейших, показанных на рис. 5-32.Например, Ada предусматривает обобщенные пакеты, обобщенныеподпрограммы и задачи как раздельно компилируемые единицы. Поэтому естьоснования дополнить основные обозначения значками типов модулей,специфических для данного языка.Сегментация.
Для платформ, имеющих ограничения по адресацииили физической памяти, может быть принято решение генерировать код вразличных сегментах, или даже организовать оверлейную структуру. Чтобыотразить такую сегментацию обозначения диаграммы модулей можнодополнить, снабдив каждый модуль меткой, обозначающей соответствующийсегмент кода или данных.СпецификацииТак же, как диаграммы классов и объектов, каждый элементдиаграммы модулей может иметь спецификацию, которая определяет егополностью. Спецификации модулей и их зависимостей содержат только туинформацию, которая уже описана в этом разделе, поэтому мы не будем ихрассматривать.В интегрированной инструментальной среде, поддерживающей нашиобозначения, разумно использовать диаграммы модулей для визуализациипрограммных модулей системы.
"Раскрытие" модуля или подсистемы надиаграмме модулей открывает соответствующий физический файл иликаталог и наоборот.5.7. Диаграммы процессовСущественное: процессоры, устройства и соединенияДиаграммы процессов используются, чтобы показать распределениепроцессов по процессорам в физическом проекте системы. Отдельнаядиаграмма процессов показывает один ракурс структуры процессов системы.При разработке проекта мы используем диаграмму процессов, чтобы показатьфизическую совокупность процессоров и устройств, обеспечивающих работусистемы.Основные элементы диаграммы процессов - процессоры, устройства иих соединения.Процессоры. На рис. 5-35 показано обозначение процессора.Процессор - часть аппаратуры, способная выполнять программы.
Каждыйпроцессор должен иметь имя; никаких особых ограничений на именапроцессоров нет, так как они обозначают "железо", а не программы.Мы можем дополнить значок процессора списком процессов. Каждыйпроцесс в таком списке обозначает или главную программу (функцию main издиаграммы модулей) или имя активного объекта (из диаграммы объектов).Устройства. На рис.
5-35 показано обозначение устройства.Устройство - это часть аппаратной платформы, не способная выполнятьпрограммы (по крайней мере, вРис. 5-35. Значки процессора и устройстванашей логической модели). Как и процессорам, устройствам требуются имена,на которые не накладывается никаких существенных ограничений.Соединения. Процессоры и устройства должны сообщаться друг сдругом.
На диаграмме процессов мы изображаем соединения между ниминенаправлеными линиями. Соединение обычно представляетнепосредственную связь между аппаратурой, например, RS232, Ethernet, илидаже доступ к разделяемой памяти, но эта связь может быть и не прямой,например, "Земля-спутник". Соединения обычно считаютсядвунаправленными, но при необходимости к их обозначению можно добавитьстрелку, чтобы указать направление. Любое соединение может иметьнеобязательную именующую его метку.Пример. На рис.
5-36 представлен пример использования этихобозначений, описывающий физическую архитектуру тепличной системы. Мывидим, что разработчики решили использовать четыре компьютера, один вкачестве рабочего места оператора и по одному на каждую теплицу.Процессы, запущенные на выделенных теплицам компьютерах, не могутсообщаться друг с другом непосредственно, а только через рабочую станцию.Для простоты мы решили не показывать на этой диаграмме никакихустройств, хотя предполагаем, что система содержит большое числоисполнительных устройств и датчиков.Дополнительные понятияОбозначения. На рис. 5-35 показаны стандартные обозначения,которые мы используем для процессора и устройства, но разумно и дажежелательно учесть возможность их изменения. Например, можно было быввести специальные значки для встроенного микрокомпьютера (процессор),диска, терминала и выпрямителя тока (устройства), и использовать их надиаграммах процессов вместо стандартных.
Поступая таким образом, мыпредлагаем визуализацию физической платформы нашей реализации, котораяпредназначена непосредственно техникам и системщикам, а также конечнымпользователям системы, которые, вероятно, не являются специалистами вразработке программного обеспечения.Вложенность. Физическая конфигурация системы бывает оченьсложной и может представлять собой иерархию процессоров и устройств. Втаких случаях полезно иметь возможность выделить группы процессоров,устройств и соединений, так же, как категории классов представляютлогическое группирование классов и объектов. Мы изображаем такие группыименованными пунктирными прямоугольника-Рис.
5-36. Диаграмма процессов гидропонной системыми с закругленными углами. Мы можем раскрыть такой значок на диаграммепроцессов и обнаружить вложенные процессоры и устройства. Непредставляет затруднений определить соединения между этими группами.Процесс разработки организован как придется и нередко хаотичен. На этой стадииналаживание элементарного управления проектом - уже прогресс.Планирование процессов. Мыдолжны некоторым образом определить порядок выполнения процессов на каждом процессоре.Имеется пять основных способов планирования, и мы можем указать на диаграмме для каждогопроцессора, какой из них использован, добавив к его значку одно из следующих имен:Для более подробного описания диспетчеризации процессов на конкретном процессоребывает полезно привести диаграмму объектов или взаимодействий, особенно еслииспользуется алгоритмическое переключение.СпецификацииПо аналогии с элементами других диаграмм, процессоры, устройства и соединениямогут иметь спецификации, которые дают их исчерпывающее определение.
Всю информацию,включаемую в эти спецификации, мы уже обсудили в текущем разделе.5.8. Применение системы обозначенийРезультат объектно-ориентированного проектированияОбычно результатами анализа системы будут наборы диаграмм объектов (чтобывыразить поведение системы через сценарии), диаграмм классов (чтобы выразить роли иобязанности агентов по поддержанию заданного поведения системы) и диаграммы состояний ипереходов (чтобы показать упорядоченное событиями поведение этих агентов).Проектирование системы, в которое входит разработка ее архитектуры и реализации,порождает диаграммы классов, объектов, модулей, процессов, а также динамические ракурсыэтих диаграмм.Существует сквозная связь между этими диаграммами, позволяющая нам проследитьтребования от реализации обратно к спецификации. Начав с диаграмм процессов, можно найтиглавную программу, которая определена на некоторой диаграмме модулей. Эта диаграммамодулей содержит наборы классов и объектов, определения которых мы найдем на подходящихдиаграммах классов или объектов.
Наконец, определения отдельных классов указывают нанаши исходные требования, потому что эти классы, в общем, непосредственно отражаютсловарь предметной области.Описанной в этой главе системой обозначений можно пользоваться вручную, хотя,конечно, она просто напрашивается на автоматизацию. Автоматизированным инструментампроектирования можно поручить проверку целостности, ограничений и полноты документации.Они также помогают разработчику легко и быстро просматривать результаты анализа иразработки.
Например, глядя на диаграмму модулей, разработчик может пожелать выяснитьустройство конкретного механизма, и автоматизированный инструмент поможет ему отыскатьвсе классы, объявленные в каком-то модуле. А от диаграммы объектов, описывающейсценарий, в котором использован один из классов, разработчик может перейти к структуренаследования этого класса.
Наконец, если в сценарии есть активный объект, разработчик можетиспользовать автоматизированный инструмент проектирования, чтобы отыскать процессор,которому выделен соответствующий поток управления, и увидеть анимированное поведениеконечного автомата класса на этом процессоре.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
