А.М. Вендров - Объектно-ориентированный анализ и проектирование (1158627), страница 11
Текст из файла (страница 11)
В каждой зонепоказываются потоки событий одного из вариантов использования,а связь между разными потоками изображается в виде переходовили потоков объектов).1.4.6. Диаграммы компонентовДиаграммы компонентов моделируют физический уровень системы.На них изображаются компоненты ПО и связи между ними. На такойдиаграмме обычно выделяют два типа компонентов: исполняемыекомпоненты и библиотеки кода.54Каждый класс модели (или подсистема) преобразуется в компонентисходного кода. Между отдельными компонентами изображаютзависимости, соответствующие зависимостям на этапе компиляции иливыполнения программы.На рис.
1.21 изображена одна из диаграмм компонентов длябанковской системы.Рис. 1.21. Диаграмма компонентов для клиентской части системыНа этой диаграмме показаны компоненты клиентской части системы.В данном случае система разрабатывается на языке С++.
У каждого классаимеется свой собственный заголовочный файл (файл с расширением .h) ифайл тела класса (файл с расширением .срр). Например, класс ATM Screenпреобразуется в компоненты ATM Screen: тело и заголовок класса.Выделенный темным компонент называется спецификацией пакета(package specification) и соответствует файлу тела класса ATM Screen.Невыделенный компонент также называется спецификацией пакета, носоответствует заголовочному файлу класса.
Компонент ATM.exeназывается спецификацией задачи и моделирует поток управления (threadof processing) - исполняемую программу.Компоненты соединены зависимостями. Например, класс Card Readerзависит от класса ATM Screen. Это означает, что, для того, чтобы класс55Card Reader мог быть скомпилирован, класс ATM Screen должен ужесуществовать. После компиляции всех классов может быть созданисполняемый файл ATMClient.exe.Банковская система содержит два потока управления и, такимобразом, получаются два исполняемых файла. Один из них - этоклиентская часть системы, она содержит компоненты Cash Dispenser, CardReader и ATM Screen. Второй файл - это сервер, включающий в себякомпонент Account.
Диаграмма компонентов для сервера показана на рис.1.22.Рис. 1.22. Диаграмма компонентов для сервераКак видно из примера, в модели системы может быть несколькодиаграмм компонентов, в зависимости от числа подсистем илиисполняемых файлов. Каждая подсистема является пакетом компонентов.Диаграммы компонентов применяются теми участниками проекта, ктоотвечает за компиляцию и сборку системы.
Они нужны там, гденачинается генерация кода.1.4.7. Диаграммы размещенияДиаграмма размещения отражает физические взаимосвязи междупрограммными и аппаратными компонентами системы. Она являетсяхорошим средством для того, чтобы показать размещение объектов икомпонентов в распределенной системе.56Каждый узел на диаграмме размещения представляет собойнекоторый тип вычислительного устройства - в большинстве случаев,часть аппаратуры. Эта аппаратура может быть простым устройством илидатчиком, а может быть и мэйнфреймом.Диаграмма размещения показывает физическое расположение сети иместонахождение в ней различных компонентов.
Ее основные элементы:• узел (node) - вычислительный ресурс - процессор или другоеустройство (дисковая память, контроллеры различных устройств ит.д.). Для узла можно задать выполняющиеся на нем процессы;• соединение (connection) - канал взаимодействия узлов (сеть).Например, банковская система состоит из большого количестваподсистем, выполняемых на отдельных физических устройствах, илиузлах. Диаграмма размещения для такой системы показана на рис.
1.23.Рис. 1.23. Диаграмма размещения для банковской системыИз данной диаграммы можно узнать о физическом размещениисистемы. Клиентские программы будут работать в нескольких местах наразличных сайтах. Через закрытые сети будет осуществляться их57сообщение с региональным сервером системы. На нем будет работать ПОсервера. В свою очередь, посредством локальной сети региональныйсервер будет сообщаться с сервером банковской базы данных,работающим под управлением Oracle.
Наконец, с региональным серверомсоединен принтер.Диаграмма размещения используется менеджером проекта,пользователями, архитектором системы и эксплуатационным персоналом,чтобы понять физическое размещение системы и расположение ееотдельных подсистем.1.4.8. Механизмы расширения UMLМеханизмы расширения UML предназначены для того, чтобыразработчики могли адаптировать язык моделирования к своимконкретным нуждам, не меняя при этом его метамодель.
Наличиемеханизмов расширения принципиально отличает UML от таких средствмоделирования, как IDEF0, IDEF1X, IDEF3, диаграмм потоков данных имоделей «сущность-связь». Перечисленные языки моделирования можноопределить как сильно типизированные (по аналогии с языкамипрограммирования), поскольку они не допускают произвольнойинтерпретации семантики элементов моделей. UML, допуская такуюинтерпретацию (в основном за счет стереотипов), является слаботипизированным языком. К его механизмам расширения относятся:• стереотипы;• тегированные (именованные) значения;• ограничения.Стереотип - это новый тип элемента модели, который определяетсяна основе уже существующего элемента. Стереотипы расширяют нотациюмодели, могут применяться к любым элементам модели и представляютсяв виде текстовой метки (рис. 1.16) или пиктограммы.Стереотипы классов - это механизм, позволяющий разделять классына категории.
Например, основными стереотипами, используемыми впроцессе анализа системы, являются: Boundary (граница), Entity(сущность) и Control (управление).Граничными классами (boundary classes) называются такие классы,которые расположены на границе системы и всей окружающей среды.
Онивключают все формы, отчеты, интерфейсы с аппаратурой (такой какпринтеры или сканеры) и интерфейсы с другими системами.Классы-сущности (entity classes) отражают основные понятия(абстракции) предметной области и, как правило, содержат хранимуюинформацию. Обычно для каждого класса-сущности создают таблицу вбазе данных.58Управляющие классы (control classes) отвечают за координациюдействий других классов. Обычно у каждого варианта использованияимеется один управляющий класс, контролирующий потоки событий этоговарианта использования.
Управляющий класс отвечает за координацию, носам не несет в себе никакой функциональности - остальные классы непосылают ему большого количества сообщений. Вместо этого он сампосылает множество сообщений. Управляющий класс просто делегируетответственность другим классам, по этой причине его часто называютклассом-менеджером.В системе могут быть и другие управляющие классы, общие длянескольких вариантов использования. Например, класс SecurityManager(менеджер безопасности) может отвечать за контроль событий, связанныхс безопасностью.
Класс TransactionManager (менеджер транзакций)занимается координацией сообщений, относящихся к транзакциям с базойданных. Могут быть и другие менеджеры для работы с другимиэлементами функционирования системы, такими как разделение ресурсов,распределенная обработка данных или обработка ошибок.Помимо упомянутых стереотипов, разработчики ПО могут создаватьсвои собственные наборы стереотипов, формируя тем самымспециализированные подмножества UML (например, для описания бизнеспроцессов, Web-приложений, баз данных и т.д.).
Такие подмножества(наборы стереотипов) в стандарте языка UML носят название профилейязыка.Именованное значение - это пара строк "тег = значение", или "имя =содержимое", в которых хранится дополнительная информация о какомлибо элементе системы, например, время создания, статус разработки илитестирования, время окончания работы над ним и т.п.Ограничение - это семантическое ограничение, имеющее видтекстового выражения на естественном или формальном языке (OCL Object Constraint Language), которое невозможно выразить с помощьюнотации UML.Одних графических средств, таких как диаграмма классов илидиаграмма состояний, недостаточно для разработки точных инепротиворечивых моделей сложных систем.
Существует необходимостьзадания дополнительных ограничений, которым должны удовлетворятьразличные компоненты или объекты модели. Традиционно подобныеограничения описывались с помощью естественного языка. Однако, какпоказала практика системного моделирования, такие сформулированныена естественном языке ограничения страдают неоднозначностью инечеткостью.Для преодоления этих недостатков и придания рассуждениям строгогохарактера были разработаны различные формальные языки. Однакотрадиционные формальные языки требуют для своего конструктивногоиспользования знания основ математической логики и теории59формального вывода.
С одной стороны, это делает формальные языкиестественным средством для построения математических моделей, а, сдругой стороны, существенно ограничивает круг потенциальныхпользователей, поскольку разработка формальных моделей требуетспециальной квалификации.Другая особенность традиционных формальных языков заключается вприсущей им "бедной" семантике. Базовые элементы формальных языковимеют слишком абстрактное содержание, что затрудняет ихнепосредственную интерпретацию в понятиях моделей конкретныхтехнических систем и бизнес-процессов.
Поскольку процесс объектноориентированного анализа и проектирования направлен на построениеконструктивных моделей сложных систем, которые должны бытьреализованы в форме программных систем и аппаратных комплексов, этоявляется серьезным недостатком. Необходимо применение такогоформального языка, базовые элементы которого адекватно отражаютсемантику основных конструкций объектной модели.Именно для этих целей и был разработан язык ОСL. По своей сути онявляется формальным языком, более простым для изучения, чемтрадиционные формальные языки. В то же время язык ОСL специальноориентирован на описание бизнес-процессов и бизнес-логики, посколькубыл разработан в одном из отделений корпорации IВМ.ОСL представляет собой формальный язык для описанияограничений, которые могут быть использованы при определенииразличных компонентов языка UML.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
