ГЛАВА 10 Диаграмма компонентов (component diagram)
ГЛАВА 10 Диаграмма компонентов (component diagram)
Все рассмотренные ранее диаграммы отражали концептуальные аспекты построения модели системы и относились к логическому уровню представления. Особенность логического представления заключается в том, что оно оперирует понятиями, которые не имеют самостоятельного материального воплощения. Другими словами, различные элементы логического представления, такие как классы, ассоциации, состояния, сообщения, не существуют материально или физически. Они лишь отражают наше понимание структуры физической системы или аспекты ее поведения.
Основное назначение логического представления состоит в анализе структурных и функциональных отношений между элементами модели системы. Однако для создания конкретной физической системы необходимо некоторым образом реализовать все элементы логического представления в конкретные материальные сущности. Для описания таких реальных сущностей предназначен другой аспект модельного представления, а именно физическое представление модели.
Чтобы пояснить отличие логического и физического представлений, рассмотрим в общих чертах процесс разработки некоторой программной системы. Ее исходным логическим представлением могут служить структурные схемы алгоритмов и процедур, описания интерфейсов и концептуальные схемы баз данных. Однако для реализации этой системы необходимо разработать исходный текст программы на некотором языке программирования (C++, Pascal, Basic/VBA, Java). При этом уже в тексте программы предполагается такая организация программного кода, которая предполагает его разбиение на отдельные модули.
Тем не менее исходные тексты программы еще не являются окончательной реализацией проекта, хотя и служат фрагментом его физического представления. Очевидно, программная система может считаться реализованной в том случае, когда она будет способна выполнять функции своего целевого предназначения. А это возможно, только если программный код системы будет реализован в форме исполняемых модулей, библиотек классов и процедур, стандартных графических интерфейсов, файлах баз данных. Именно эти компоненты являются необходимыми элементами физического представления системы.
Таким образом, полный проект программной системы представляет собой совокупность моделей логического и физического представлений, которые должны быть согласованы между собой. В языке UML для физического представления моделей систем используются так называемые диаграммы реализации (implementation diagrams), которые включают в себя две отдельные канонические диаграммы: диаграмму компонентов и диаграмму развертывания. Особенности построения первой из них рассматриваются в этой главе, а второй – в следующей.
Диаграмма компонентов, в отличие от ранее рассмотренных диаграмм, описывает особенности физического представления системы. Диаграмма компонентов позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный, бинарный и исполняемый код. Во многих средах разработки модуль или компонент соответствует файлу. Пунктирные стрелки, соединяющие модули, показывают отношения взаимозависимости, аналогичные тем, которые имеют место при компиляции исходных текстов программ. .Основными графическими элементами диаграммы компонентов являются компоненты, интерфейсы и зависимости между ними.
Диаграмма компонентов разрабатывается для следующих целей:
• Визуализации общей структуры исходного кода программной системы.
• Спецификации исполнимого варианта программной системы.
• Обеспечения многократного использования отдельных фрагментов программного кода.
• Представления концептуальной и физической схем баз данных.
В разработке диаграмм компонентов участвуют как системные аналитики и архитекторы, так и программисты. Диаграмма компонентов обеспечивает согласованный переход от логического представления к конкретной реализации проекта в форме программного кода. Одни компоненты могут существовать только на этапе компиляции программного кода, другие – на этапе его исполнения. Диаграмма компонентов отражает общие зависимости между компонентами, рассматривая последние в качестве классификаторов.
Примечание 72
Более 800 000 книг и аудиокниг! 📚
Получи 2 месяца Литрес Подписки в подарок и наслаждайся неограниченным чтением
ПОЛУЧИТЬ ПОДАРОКДанный текст является ознакомительным фрагментом.
Читайте также
Элемент <component>
Элемент <component> Внутри элемента <component> описывается один компонент-сценарий (СОМ-объект). Необязательный атрибут id определяет идентификатор объекта (это может понадобиться в том случае, когда в одном WSC-файле находится несколько
Создание макета файла DateArc.wsc с помощью Windows Script Component Wizard (JScript)
Создание макета файла DateArc.wsc с помощью Windows Script Component Wizard (JScript) Из листинга 10.1 можно понять, что создание компонента-сценария связано с написанием большого количества вспомогательного кода (нужно заполнить элементы <registration>, <property>, <method> и <events>, написать
ГЛАВА 4 Диаграмма вариантов использования (use case diagram)
ГЛАВА 4 Диаграмма вариантов использования (use case diagram) Визуальное моделирование в UML можно представить как некоторый процесс поуровневого спуска от наиболее обшей и абстрактной концептуальной модели исходной системы к логической, а затем и к физической модели
ГЛАВА 5 Диаграмма классов (class diagram)
ГЛАВА 5 Диаграмма классов (class diagram) Центральное место в ООАП занимает разработка логической модели системы в виде диаграммы классов. Нотация классов в языке UML проста и интуитивно понятна всем, кто когда-либо имел опыт работы с CASE-инструментариями. Схожая нотация
ГЛАВА 6 Диаграмма состояний (statechart diagram)
ГЛАВА 6 Диаграмма состояний (statechart diagram) Рассмотренная выше диаграмма классов представляет собой логическую модель статического представления моделируемой системы. Речь идет о том, что на данной диаграмме изображаются только взаимосвязи структурного характера, не
ГЛАВА 7 Диаграмма деятельности (activity diagram)
ГЛАВА 7 Диаграмма деятельности (activity diagram) При моделировании поведения проектируемой или анализируемой системы возникает необходимость не только представить процесс изменения ее состояний, но и детализировать особенности алгоритмической и логической реализации
ГЛАВА 9 Диаграмма кооперации (collaboration diagram)
ГЛАВА 9 Диаграмма кооперации (collaboration diagram) Как отмечалось в предыдущей главе, особенности взаимодействия элементов моделируемой системы могут быть представлены на диаграммах последовательности и кооперации. Если первая служит для визуализации временных аспектов
ГЛАВА 11 Диаграмма развертывания (deployment diagram)
ГЛАВА 11 Диаграмма развертывания (deployment diagram) Физическое представление программной системы не может быть полным, если отсутствует информация о том, на какой платформе и на каких вычислительных средствах она реализована. Конечно, если разрабатывается простая программа,
Диаграмма состояний TCP
Диаграмма состояний TCP Последовательность действий TCP во время установления и завершения соединения можно определить с помощью диаграммы состояний TCP (state transition diagram). Ее мы изобразили на рис. 2.4. Рис. 2.4. Диаграмма состояний TCPДля соединения определено 11 различных
Глава 6. Установка основных компонентов системы
Глава 6. Установка основных компонентов системы Вступление В этой главе мы всерьез займемся установкой системы LFS. Сначала мы войдем в созданную в предыдущей главе мини-систему Linux, создадим несколько вспомогательных вещей и перейдем к поочередной инсталляции всех
C — значит Component
C — значит Component Вы уже составили список атрибутов? Добро пожаловать в мир компонентов! Компоненты — это «существительные» нашего продукта. Это наши кирпичи, из которых построена вся система. Компоненты — это, к примеру, корзина и система оформления заказов в
13.1.4. Диаграмма видов сложности
13.1.4. Диаграмма видов сложности Выше были показаны две различные шкалы для анализа сложности. Данные шкалы фактически перпендикулярны друг другу. Рис. 13.1 может помочь при выяснении связей. В каждом из девяти блоков на рисунке приведен общий источник определенного вида
13.1.4. Диаграмма видов сложности
13.1.4. Диаграмма видов сложности Выше были показаны две различные шкалы для анализа сложности. Данные шкалы фактически перпендикулярны друг другу. Рис. 13.1 может помочь при выяснении связей. В каждом из девяти блоков на рисунке приведен общий источник определенного вида
Глава 2. Палитра компонентов
Глава 2. Палитра компонентов Размещение компонентовНевидимые компонентыЕсли вам часто приходится заниматься ремонтом какой-либо вышедшей из строя техники, то вы знаете, как приятно всегда иметь под рукой нужный винт, болт или гайку. Легко представить радость создания
Диаграмма классов
Диаграмма классов На рисунке приведена диаграмма классов модуля ABCObjects. Класс SpriteABC описан в модуле ABCSprites, однако, приведен на диаграмме как один из