Диаграмма компонентов uml требования к функциям. Элементы графической нотации диаграммы компонентов. Компоненты, артефакты и узлы

24.11.2023

Цель работы:

изучение диаграмм пакетов, диаграммы компонентов и диаграммы размещения,
изучение их применения в процессе проектирования.

Диаграммы пакетов (package diagrams)

Один из важнейших вопросов методологии создания программного обеспечения - как разбить большую систему на небольшие подсистемы? Именно с этой точки зрения изменения, связанные с переходом от структурного подхода к объектно-ориентированному, являются наиболее заметными. Одна из идей заключается в группировке классов в компоненты более высокого уровня. В UML такой механизм группировки носит название пакетов (package).

Диаграммой пакетов является диаграмма, содержащая пакеты классов и зависимости между ними. Строго говоря, пакеты и зависимости являются элементами диаграммы классов, т. е. диаграмма пакетов - это всего лишь форма диаграммы классов. Однако на практике причины построения таких диаграмм различны.

Зависимость между двумя элементами имеет место в том случае, если изменения в определении одного элемента могут повлечь за собой изменение в другом. Что касается классов, то причины зависимостей могут быть самыми разными: один класс посылает сообщение другому; один класс включает часть данных другого класса; один класс ссылается на другой как на параметр операции. Если класс меняет свой интерфейс, то любое сообщение, которое он посылает, может стать неправильным.

В идеальном случае только изменения в интерфейсе класса должны воздействовать на другие классы. Искусство проектирования больших систем включает в себя минимизацию зависимостей, которая снижает воздействие изменений и требует меньше усилий на их внесение.

На рис. 14.1 мы имеем дело с классами предметной области, моделирующими деятельность организации и сгруппированными в два пакета: «Клиенты» и «Заказы».

Рис. 14.1. Классы предметной области, моделирующие деятельность организации

«Приложение сбора заказов» имеет зависимости с обоими пакетами предметной области. «Пользовательский интерфейс сбора заказов» имеет зависимости с «Приложением сбора заказов» и «Библиотекой GUI».

Зависимость между двумя пакетами существует в том случае, если имеется какая-либо зависимость между любыми двумя классами в пакетах. Например, если любой класс в пакете «Список рассылки» зависит от какого-либо класса в пакете «Клиенты», то между соответствующими пакетами существует зависимость.

Пакеты являются жизненно необходимым средством для больших проектов. Их следует использовать в тех случаях, когда диаграмма классов, охватывающая всю систему в целом и размещенная на единственном листе бумаги формата А4, становится трудночитаемой.

Пакеты не дают ответа на вопрос, каким образом можно уменьшить количество зависимостей в разрабатываемой системе, однако они помогают выделить эти зависимости. Сведение к минимуму количества зависимостей позволяет снизить связанность компонентов системы. Но эвристический подход к этому процессу далек от идеала.

Пакеты особенно полезны при тестировании. Каждый пакет при тестировании может содержать один или несколько тестовых классов, с помощью которых проверяется поведение пакета.

Диаграммы компонентов (component diagrams)

Компоненты на диаграмме компонентов представляют собой физические модули программного кода (рис. 14.2). Обычно они в точности соответствуют пакетам на диаграмме пакетов (см. рис. 14.1); таким образом, диаграмма компонентов отражает выполнение каждого пакета в системе.

Рис. 14.2.

Зависимости между компонентами должны совпадать с зависимостями между пакетами. Эти зависимости показывают, каким образом одни компоненты взаимодействуют с другими. Направление данной зависимости показывает уровень осведомленности о коммуникации. Если на панелях инструментов диаграмм размещения отсутствуют некоторые значки, то их можно настроить вызвав диалоговое окно View/Toolbar/Configure/Toolbars/Component Diagrams

Таблица 14.1. Описание кнопок панели инструментов диаграмм компонентов Rational Rose

Кнопка	Описание	Название
	Выбор элемента модели	Select tool
	Ввод текста	Text Box
	Комментарий	Note
	Связь комментария с элементом	Anchor Note to Item
	Компонент	Component
	Пакет	Package
	Зависимость	Dependency
	Тело задания	Task Body
	Спецификация задания	Task Specification
	Тело пакета	Package Body
	Спецификация пакета	Package Specification
	Главная программа	Main Program
	Спецификация подпрограммы	Subprogram Specification
	Тело попдпрограммы	Subprogram Body

Диаграммы размещения (deployment diagrams)

Диаграмма размещения отражает физические взаимосвязи между программными и аппаратными компонентами системы. Она является хорошим средством для того, чтобы показать маршруты перемещения объектов и компонентов в распределенной системе.

Каждый узел на диаграмме размещения представляет собой некоторый тип вычислительного устройства - в большинстве случаев часть аппаратуры. Эта аппаратура может быть простым устройством или датчиком, а может быть и большим компьютером.

На рис. 14.3 изображен персональный компьютер (ПК), связанный с UNIX-сервером посредством протокола TCP/IP. Соединения между узлами показывают коммуникационные каналы, с помощью которых осуществляются системные взаимодействия.

Рис. 14.3.

На практике данные диаграммы применяются не слишком часто. В целом эти диаграммы полезно применять, чтобы выделить особенные физические характеристики данной системы. По мере распространения распределенных систем важность данных диаграмм возрастает.

Таблица 14.2. Описание кнопок панели инструментов диаграмм размещения Rational Rosee

Примеры

Проводить сравнение диаграмм пакетов, компонентов и размещения в общем случае бессмысленно, так как эти диаграммы не существуют сами по себе, а являются интерпретацией некоторой диаграммы классов, для которой и уместно проводить сравнение с другими диаграммами классов.

Диаграммы пакетов содержат один тип элементов - пакет и один тип связей - зависимость, поэтому численная оценка для диаграммы пакетов не столь важна, как для диаграммы классов.

На рис. 14.4 изображена диаграмма пакетов подсистемы «Служба занятости в рамках вуза» системы «Дистанционное обучение». Численная оценка для нее равна:

Рис. 14.4. Диаграмма пакетов

Диаграммы компонентов и размещения строятся и используются на этапе реализации и сопровождения, когда базовая архитектура системы уже обычно определена; поэтому они однозначно получаются из диаграммы классов и для них достаточно привести по одному примеру.

Рис. 14.5 . Диаграмма компонентов

На рис. 14.5 изображена диаграмма компонентов, построенная на основе диаграммы пакетов, изображенной на рис. 14.4. На рис. 14.6 изображена диаграмма размещения подсистемы «Служба занятости в рамках вуза». Оценка для данной диаграммы компонентов равна:

Оценка для диаграммы размещения равна:

Рис. 14.6. Диаграмма размещения

Упражнения

Упражнение 1. Создание диаграммы размещения системы регистрации

Распределенная конфигурация системы моделируется с помощью диаграммы размещения. Ее основные элементы:

узел (node) - вычислительный ресурс (процессор или другое устройство (дисковая память, контроллеры различных устройств и т.д.). Для узла можно задать выполняющиеся на нем процессы;
соединение (connection) - канал взаимодействия узлов (сеть).

Пример: сетевая конфигурация системы регистрации (без процессов) (рис. 14.7).

Ри с. 14.7. Сетевая конфигурация системы регистрации

Распределение процессов по узлам сети производится с учетом следующих факторов:

используемые образцы распределения (трехзвенная клиент - серверная конфигурация, «толстый» клиент, «тонкий» клиент, равноправные узлы (peer-to-peer) и т.д.);
время отклика;
минимизация сетевого трафика;
мощность узла;
надежность оборудования и коммуникаций. Пример: распределение процессов по узлам (рис. 14.8).

Рис.

14.8. Сетевая конфигурация системы регистрации с распределением

Для того чтобы открыть диаграмму размещения, надо дважды щелкнуть мышью по представлению Deployment View (представлению размещения) в браузере.
Для того чтобы поместить на диаграмму процессор:

На панели инструментов диаграммы нажмите кнопку Processor.
Щелкните по диаграмме размещения в том месте, куда хотите поместить процессор.
Введите имя процессора.

В спецификациях процессора можно ввести информацию о его стереотипе, характеристиках и планировании. Стереотипы применяются для классификации процессоров (например, компьютеров под управлением UNIX или ПК). Характеристики процессора - это его физическое описание. Оно может, в частности, включать скорость процессора и объем памяти.

Поле планирования (scheduling) процессора содержит описание того, как осуществляется планирование его процессов

Preemptive (с приоритетом). Высокоприоритетные процессы имеют преимущество перед низкоприоритетными.
Non preemptive (без приоритета). У процессов не имеется приоритета. Текущий процесс выполняется до его завершения, после чего начинается следующий.
Cyclic (циклический). Управление передается между процессами по кругу. Каждому процессу дается определенное время на его выполнение, затем управление переходит к следующему процессу.
Executive (исполнительный). Существует некоторый вычислительный алгоритм, который и управляет планированием процессов.
Manual (вручную). Процессы планируются пользователем.

Для того чтобы назначить процессору стереотип.

Перейдите на вкладку General.
Введите стереотип в поле Stereotype.

Для введения характеристик и планирования процессора

Откройте окно спецификации процессора.
Перейдите на вкладку Detail.
Введите характеристики в поле характеристик.
Укажите один из типов планирования.

Для того чтобы показать планирование на диаграмме:

Выберите пункт Show Scheduling в открывшемся меню.

Для того чтобы добавить связь на диаграмму:

На панели инструментов нажмите кнопку Connection.
Щелкните по узлу диаграммы.
Проведите линию связи к другому узлу.

Для того чтобы назначить связи стереотипа:

Откройте окно спецификации связи.
Перейдите на вкладку General.
Введите стереотип в поле Stereotype (Стереотип).

Для того чтобы добавить процесс:

Щелкните правой кнопкой мыши по процессору в браузере.
Выберите пункт New > Process в открывшемся меню.
Введите имя нового процесса.

Для того чтобы показать процессы на диаграмме:

Щелкните правой кнопкой мыши по процессору.
Выберите пункт Show Processes в открывшемся меню.

Контрольные вопросы

Какую проблему проектирования призваны решить диаграммы пакетов?
В чем отличие диаграмм пакетов от диаграмм классов?
В чем смысл зависимости между элементами диаграммы пакетов?
Что такое интерфейс класса?
По каким признакам классы группируются в пакеты?
Какие виды элементов модели представлены на диаграмме компонентов?
Как связаны между собой диаграммы пакетов и диаграммы компонентов?
Что показывает диаграмма размещения?
Какие сущности.отображаются на диаграммах-размещения?
10. В каких случаях необходимо применение диаграмм размещения?

олный проект программной системы представляет собой совокупность моделей логического и физического уровней, которые должны быть согласованы между собой. В языке UML для физического представления моделей систем используются диаграммы реализации (implementation diagrams), которые включают в себя диаграмму компонентов и диаграмму развертывания.

Диаграмма компонентов, в отличие от ранее рассмотренных диаграмм, описывает особенности физического представления системы. Она позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный и исполняемый код. Основными графическими элементами диаграммы компонентов являются компоненты, интерфейсы и зависимости между ними.

Диаграмма компонентов разрабатывается для следующих целей:

визуализации общей структуры исходного кода программной системы;

спецификации исполняемого варианта программной системы;

обеспечения многократного использования отдельных фрагментов программного кода;

представления концептуальной и физической схем баз данных.

В разработке диаграмм компонентов участвуют как системные аналитики и архитекторы, так и программисты. Диаграмма компонентов обеспечивает согласованный переход от логического представления к конкретной реализации проекта в форме программного кода. Одни компоненты могут существовать только на этапе компиляции программного кода, другие на этапе его исполнения. Диаграмма компонентов отражает общие зависимости между компонентами, рассматривая последние в качестве классификаторов.

Компоненты

Для представления физических сущностей в языке UML применяется специальный термин - компонент (component). Компонент реализует некоторый набор интерфейсов и служит для общего обозначения элементов физического представления модели. Для графического представления компонента используется специальный символ - прямоугольник со вставленными слева двумя более мелкими прямоугольниками. Внутри большого прямоугольника записывается имя компонента и, при необходимости, некоторая дополнительная информация. Изображение этого символа может незначительно варьироваться в зависимости от характера ассоциируемой с компонентом информации.

Имя компонента подчиняется общим правилам именования элементов модели в языке UML и может состоять из любого числа букв, цифр и некоторых знаков препинания.

Отдельный компонент может быть представлен на уровне типа или на уровне экземпляра. Графическое изображение в обоих случаях одинаковое, но правила записи имени компонента отличаются. Если компонент представляется на уровне типа, то в качестве его имени записывается только имя типа с заглавной буквы. Если же компонент представляется на уровне экземпляра, то в качестве его имени записывается <имя компонента>":"<имя типаХ>. При этом вся строка имени подчеркивается.

В качестве простых имен принято использовать имена исполняемых файлов (с указанием расширения ехе после точки-разделителя), динамических библиотек (расширение dll), Web-страниц (расширение html), текстовых файлов (расширения txt или doc) или файлов справки (hip), файлов баз данных (DB) или файлов с исходными текстами программ (расширения h, cpp для языка C++, расширение java для языка Java), скрипты (pi, asp) и другие.

Поскольку конкретная реализация логического представления модели системы зависит от используемого программного инструментария, то и имена компонентов определяются особенностями синтаксиса соответствующего языка программирования.

В отдельных случаях к простому имени компонента может быть добавлена информация об имени объемлющего пакета и о конкретной версии реализации данного компонента. В этом случае номер версии записывается как помеченное значение в фигурных скобках. В других случаях символ компонента может быть разделен на секции, чтобы явно указать имена реализованных в нем интерфейсов.

Поскольку компонент как элемент физической реализации модели представляет отдельный модуль кода, иногда его комментируют с указанием дополнительных графических символов, иллюстрирующих конкретные особенности его реализации. Эти дополнительные обозначения для примечаний не специфицированы в языке UML, однако их применение упрощает понимание диаграммы компонентов, повышая наглядность физического представления.

В языке UML выделяют три вида компонентов:

развертывания, которые обеспечивают непосредственное выполнение системой своих функций. Такими компонентами могут быть динамически подключаемые библиотеки с расширением dll, Web-страницы на языке разметки гипертекста с расширением html и файлы справки с расширением hlp;

рабочие продукты. Как правило, это файлы с исходными текстами программ, например, с расширениями h или срр для языка C++;

исполнения, представляющие собой исполняемые модули - файлы с расширением ехе.

Эти элементы иногда называют артефактами, подчеркивая при этом их законченное информационное содержание, зависящее от конкретной технологии реализации соответствующих компонентов.

Другим способом спецификации различных видов компонентов является явное указание его стереотипа компонента перед именем. В языке UML для компонентов определены следующие стереотипы:

библиотека (library) - определяет первую разновидность компонента, который представляется в форме динамической или статической библиотеки;

таблица (table) - также определяет первую разновидность компонента, который представляется в форме таблицы базы данных;

файл (file) - определяет вторую разновидность компонента, который представляется в виде файлов с исходными текстами программ;

документ (document) - определяет вторую разновидность компонента, . который представляется в форме документа;

исполнимый (executable) - определяет третий вид компонента, который может исполняться в узле.

Интерфейсы

Следующим элементом диаграммы компонентов являются интерфейсы. В общем случае, интерфейс графически изображается окружностью, которая соединяется с компонентом отрезком линии без стрелок. Имя интерфейса должно начинаться с заглавной буквы "I" и записываться рядом с окружностью. Семантически линия означает реализацию интерфейса, а наличие интерфейсов у компонента означает, что данный компонент реализует соответствующий набор интерфейсов.

Другим способом представления интерфейса на диаграмме компонентов является его изображение в виде прямоугольника класса со стереотипом «интерфейс» и возможными секциями атрибутов и операций. Как правило, этот вариант обозначения используется для представления внутренней структуры интерфейса, которая может быть важна для реализации.

При разработке программных систем интерфейсы обеспечивают не только совместимость различных версий, но и возможность вносить существенные изменения в одни части программы, не изменяя другие ее части. Таким образом, назначение интерфейсов существенно шире, чем спецификация взаимодействия с пользователями системы (актерами).

Зависимости

В общем случае отношение зависимости также было рассмотрено ранее. Напомним, что зависимость не является ассоциацией, а служит для представления только факта наличия такой связи, когда изменение одного элемента модели оказывает влияние или приводит к изменению другого элемента модели. Отношение зависимости на диаграмме компонентов изображается пунктирной линией со стрелкой, направленной от клиента (зависимого элемента) к источнику (независимому элементу).

Зависимости могут отражать связи модулей программы на этапе компиляции и генерации объектного кода. В другом случае зависимость может отражать наличие в независимом компоненте описаний классов, которые используются в зависимом компоненте для создания соответствующих объектов. Применительно к диаграмме компонентов зависимости могут связывать компоненты и импортируемые этим компонентом интерфейсы, а также различные виды компонентов между собой.

В первом случае рисуют стрелку от компонента-клиента к импортируемому интерфейсу. Наличие стрелки означает, что компонент не реализует соответствующий интерфейс, а использует его в процессе своего выполнения. Причем на этой же диаграмме может присутствовать и другой компонент, который реализует этот интерфейс.

Другим случаем отношения зависимости на диаграмме компонентов является отношение между различными видами компонентов. Наличие подобной зависимости означает, что внесение изменений в исходные тексты программ или динамические библиотеки приводит к изменениям самого компонента. При этом характер изменений может быть отмечен дополнительно.

На диаграмме компонентов могут быть также представлены отношения зависимости между компонентами и реализованными в них классами. Эта информация имеет значение для обеспечения согласования логического и физического представлений модели системы. Если требуется подчеркнуть, что некоторый компонент реализует отдельные классы, то для обозначения компонента используется расширенный символ прямоугольника. При этом прямоугольник компонента делится на две секции горизонтальной линией. Верхняя секция служит для записи имени компонента, а нижняя секция - для указания дополнительной информации.

Внутри символа компонента могут изображаться другие элементы графической нотации, такие как классы (компонент уровня типа) или объекты (компонент уровня экземпляра). В этом случае символ компонента изображается таким образом, чтобы вместить эти дополнительные символы.

Объекты, которые находятся в отдельном компоненте-экземпляре, изображаются вложенными в символ данного компонента. Подобная вложенность означает, что выполнение компонента влечет выполнение соответствующих объектов.

Разработка диаграммы компонентов предполагает использование информации как о логическом представлении модели системы, так и об особенностях ее физической реализации. До начала разработки необходимо принять решения о выборе вычислительных платформ и операционных систем, на которых предполагается реализовывать систему, а также о выборе конкретных баз данных и языков программирования.

После этого можно приступать к общей структуризации диаграммы компонентов. В первую очередь, необходимо решить, из каких физических частей (файлов) будет состоять программная система. На этом этапе следует обратить внимание на такую реализацию системы, которая обеспечивала бы не только возможность повторного использования кода за счет рациональной декомпозиции компонентов, но и создание объектов только при их необходимости.

Речь идет о том, что общая производительность программной системы существенно зависит от рационального использования вычислительных ресурсов. Для этой цели необходимо большую часть описаний классов, их операций и методов вынести в динамические библиотеки, оставив в исполняемых компонентах только самые необходимые для инициализации программы фрагменты программного кода.

После общей структуризации физического представления системы необходимо дополнить модель интерфейсами и схемами базы данных. При разработке интерфейсов следует обращать внимание на согласование (стыковку) различных частей программной системы. Включение в модель схемы базы данных предполагает спецификацию отдельных таблиц и установление информационных связей между таблицами.

Завершающий этап построения диаграммы компонентов связан с установлением и нанесением на диаграмму взаимных связей между компонентами, а также отношений реализации. Эти отношения должны иллюстрировать все важнейшие аспекты физической реализации системы, начиная с особенностей компиляции исходных текстов программ и заканчивая исполнением отдельных частей программы на этапе ее выполнения. Для этой цели можно использовать различные виды графического изображения компонентов.

При разработке диаграммы компонентов следует придерживаться общих принципов создания моделей на языке UML. В частности, необходимо использовать уже имеющиеся в языке UML компоненты и стереотипы. Для большинства типовых проектов этого набора элементов может оказаться достаточно для представления компонентов и зависимостей между ними.

Если проект содержит некоторые физические элементы, описание которых отсутствует в языке UML, то следует воспользоваться механизмом расширения и использовать дополнительные стереотипы для отдельных нетиповых компонентов или помеченные значения для уточнения их отдельных характеристик.

Следует обратить внимание, что диаграмма компонентов, как правило, разрабатывается совместно с диаграммой развертывания, на которой представляется информация о физическом размещении компонентов программной системы по ее отдельным узлам.

На схеме компонентов показаны части конструкции программной системы. Схема компонентов помогает визуализировать высокоуровневую структуру системы и поведение служб, предоставляемых и потребляемых этими элементами через интерфейсы. Чтобы создать UML-схему компонентов, в меню Архитектура щелкните Создать схему.

Схему компонентов можно использовать, чтобы описать конструкцию системы, реализуемую на любом языке и в любом стиле. Нужно только определить части конструкции, взаимодействующие с другими частями через ограниченный набор входных и выходных каналов. Можно использовать компоненты любого масштаба, взаимосвязанные любым способом.

В следующей таблице описаны элементы, которые можно использовать на схеме компонентов, и их основные свойства.

Фигура	Элемент	Описание и основные свойства
	Компонент	Допускающий повторное использование функциональный элемент системы. Компонент предоставляет и потребляет поведение через интерфейсы и может использовать другие компоненты. Можно скрывать или отображать внутренние части компонента с помощью элемента управления "развернуть/свернуть" (9). Компонент - это вид класса. Является неявно создаваемым экземпляром. Если значение true (по умолчанию), компонент существует только как артефакт конструкции. Во время выполнения существует только ее часть.
	Предоставленный порт интерфейса	Представляет группу сообщений или вызовов, реализуемых компонентом и доступных для использования другими компонентами или внешними системами. Порт - это свойство компонента, имеющее в качестве типа интерфейс.
	Требуемый порт интерфейса	Представляет группу сообщений или вызовов, отправляемых компонентом другим компонентам или внешним системам. Компонент предназначен для соединения с компонентами, которые предоставляют хотя бы эти операции. Порт имеет в качестве типа интерфейс.
	Зависимость	Может использоваться для указания, что требуемый интерфейс одного компонента может соответствовать предоставленному интерфейсу другого компонента. Зависимости также можно использовать в более общем случае при работе с элементами модели, чтобы показать, что конструкция одного зависит от конструкции другого.
		Атрибут компонента, тип которого, как правило, является другим компонентом. Часть используется при внутреннем проектировании ее родительского компонента. Графически части изображаются вложенными в родительский компонент. Чтобы создать часть существующего типа компонента, перетащите компонент из Проводника по моделям UML в компонент-владелец. Чтобы создать часть нового типа, выберите инструмент Компонент и щелкните компонент-владелец. Например, компонент Car имеет части engine:CarEngine, backLeft:Wheel, frontRight:Wheel и т. д. Несколько частей могут иметь один и тот же тип, и разные компоненты могут иметь части одного типа. Тип. Тип части, определяемый в другом месте модели. Как правило, типом является другой компонент. Кратность. По умолчанию используется значение 1. Можно задать значение 0..1, чтобы указать, что часть может иметь значение null, или задать значение *, чтобы указать, что часть является коллекцией экземпляров данного типа. Также в качестве значения можно задать любое выражение, которое можно оценить в числовом диапазоне.
	Сборка части	Соединение между требуемыми портами интерфейса одной части и предоставленными портами интерфейса другой. Реализация сборки части для разных компонентов может различаться. Соединенные части должны иметь один родительский компонент.
	Делегирование	Связывает порт с интерфейсом одной из частей компонента. Указывает, что сообщения, отправленные компоненту, обрабатываются этой частью, или что сообщения, отправленные этой частью, отсылаются из родительского компонента.
(не показана)	Обобщение	Указывает, что один компонент наследуется от другого. Части и интерфейсы наследуются.
	Элемент управления "развернуть/свернуть"	Позволяет скрывать или отображать внутренние части компонента.
(не показана)

Сегодня процесс создания сложных программных приложений невозможно представить без разделения на этапы жизненного цикла. Под жизненным циклом программы будем понимать совокупность этапов:

Анализ предметной области и создание ТЗ (взаимодействия с заказчиком)
Проектирование структуры программы
Кодирование (набор программного кода согласно проектной документации)
Тестирование и отладка
Внедрение программы
Сопровождение программы
Утилизация

Остановимся детально на процессе проектирования. В ходе проектирования архитектором или опытным программистом создается проектная документация, включающая текстовые описания, диаграммы, модели будущей программы. В этом нелегком деле нам поможет язык UML.

UML - является графическим языком для визуализации, описания параметров, конструирования и документирования различных систем (программ в частности). Диаграммы создаются с помощью специальных CASE средств, например Rational Rose (http://www-01.ibm.com/software/rational/) и Enterprise Architect (http://www.sparxsystems.com.au/). На основе технологии UML строится единая информационная модель. Приведенные выше CASE средства способны генерировать код на различных объектно-ориентированных языках, а так же обладают очень полезной функцией реверсивного инжиниринга. (Реверсивный инжиниринг позволяет создать графическую модель из имеющегося программного кода и комментариев к нему.)

Рассмотрим типы диаграмм для визуализации модели (это must have, хотя типов гораздо больше):

Диаграмма вариантов использования (use case diagram)

Проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью, так называемых прецедентов. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой.

Диаграмма классов (class diagram)

Диаграмма классов служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру (поля, методы…) и типы отношений (наследование, реализация интерфейсов …). На данной диаграмме не указывается информация о временных аспектах функционирования системы. С этой точки зрения диаграмма классов является дальнейшим развитием концептуальной модели проектируемой системы. На этом этапе принципиально знание ООП подхода и паттернов проектирования.

Диаграмма состояний (statechart diagram)

Главное предназначение этой диаграммы - описать возможные последовательности состояний и переходов, которые в совокупности характеризуют поведение элемента модели в течение его жизненного цикла. Диаграмма состояний представляет динамическое поведение сущностей, на основе спецификации их реакции на восприятие некоторых конкретных событий.

Диаграмма последовательности (sequence diagram)

Для моделирования взаимодействия объектов в языке UML используются соответствующие диаграммы взаимодействия. Взаимодействия объектов можно рассматривать во времени, и тогда для представления временных особенностей передачи и приема сообщений между объектами используется диаграмма последовательности. Взаимодействующие объекты обмениваются между собой некоторой информацией. При этом информация принимает форму законченных сообщений. Другими словами, хотя сообщение и имеет информационное содержание, оно приобретает дополнительное свойство оказывать направленное влияние на своего получателя.

Диаграмма кооперации (collaboration diagram)

На диаграмме кооперации в виде прямоугольников изображаются участвующие во взаимодействии объекты, содержащие имя объекта, его класс и, возможно, значения атрибутов. Как и на диаграмме классов, указываются ассоциации между объектами в виде различных соединительных линий. При этом можно явно указать имена ассоциации и ролей, которые играют объекты в данной ассоциации.
В отличие от диаграммы последовательности, на диаграмме кооперации изображаются только отношения между объектами, играющими определенные роли во взаимодействии.

Диаграмма компонентов (component diagram)

Диаграмма компонентов, в отличие от ранее рассмотренных диаграмм, описывает особенности физического представления системы. Диаграмма компонентов позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный, бинарный и исполняемый код. Во многих средах разработки модуль или компонент соответствует файлу. Пунктирные стрелки, соединяющие модули, показывают отношения взаимозависимости, аналогичные тем, которые имеют место при компиляции исходных текстов программ. Основными графическими элементами диаграммы компонентов являются компоненты, интерфейсы и зависимости между ними.

Диаграмма развертывания (deployment diagram)

Диаграмма развертывания предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения (runtime). При этом представляются только компоненты-экземпляры программы, являющиеся исполнимыми файлами или динамическими библиотеками. Те компоненты, которые не используются на этапе исполнения, на диаграмме развертывания не показываются.
Диаграмма развертывания содержит графические изображения процессоров, устройств, процессов и связей между ними. В отличие от диаграмм логического представления, диаграмма развертывания является единой для системы в целом, поскольку должна всецело отражать особенности ее реализации. Эта диаграмма, по сути, завершает процесс ООАП для конкретной программной системы и ее разработка, как правило, является последним этапом спецификации модели.

На этом закончим обзорный экскурс по диаграммам в частности и проектированию в общем. Стоит отметить, что процесс проектирования уже давно стал стандартом разработки ПО, но часто приходится сталкиваться с великолепно написанной программой, которая из за отсутствия нормальной документации обрастает ненужным побочным функционалом, костылями, становится громоздкой и теряет былое качество. =(

Я убежден, что программист в первую очередь это кодер – он НЕ должен общаться с заказчиком, НЕ должен задумываться об архитектуре системы, не должен изобретать интерфейс к программе, он только должен кодировать – реализовывать алгоритмы, функционал, внешний вид, юзабилити, но не более…. Проектировщик же должен начиная от абстрактных диаграмм (описывающих предметную область) до диаграмм представляющих структуру данных, классов и процессов их взаимодействия, детально шаг за шагом все расписать. То есть сложность работы и зарплата проектировщика должна быть на порядок выше чем у программиста == кодера. Простите за крамолу....

Язык UML - это графический язык моделирования общего назначения, предназначенный для спецификации, визуализации, проектирования и документирования всех артефактов, создаваемых при разработке программных систем.

Существует много хороших книг в которых описано в деталях про UML (местами даже очень подробно), мне хотелось бы собрать в одном месте основные понятия про диаграммы, сущности и связи между ними для быстрого вспоминания, что-то наподобие шпаргалки.

В заметке используется материалы из книжек: Иванов Д. Ю., Новиков Ф. А. Унифицированный язык моделирования UML и Леоненков. Самоучитель по UML .

Для начала определимся с редактором. Под Linux я перепробовал разные UML-редакторы, больше всего мне понравился UMLet , хоть он и написан на Java но шевелится весьма проворно и большинство заготовок сущностей в нем есть. Еще есть ArgoUML кроссплатформенный UML-редактор, написан тоже на Java, функционально-богат но подтормаживает больше.

Я остановился на UMLet , установим его под Arch Linux и Ubuntu :

# под Arch Linux yaourt -S umlet # под Ubuntu sudo apt-get install umlet

В UML все сущности можно разбить на такие типы:

структурные;
поведенческие;
группирующие;
аннотационные;

В UML используются четыре основных типа отношений:

Зависимость (dependency) - указывает на то, что изменение независимой сущности каким-то образом влияет на зависимую сущность. Графически отношение зависимости изображается в виде пунктирной линии со стрелкой, направленной от зависимой сущности к независимой.

Ассоциация (association) - имеет место, если одна сущность непосредственно связана с другой (или с другими - ассоциация может быть не только бинарной). Графически ассоциация изображается в виде сплошной линии с различными дополнениями, соединяющей связанные сущности.

Обобщение (generalization) - это отношение между двумя сущностями, одна из которых является частным (специализированным) случаем другой. Графически обобщение изображается в виде линии с треугольной не закрашенной стрелкой на конце, направленной от частного (подкласса) к общему (суперклассу).

Реализации - отношение реализации указывает, что одна сущность является реализацией другой. Графически реализация изображается в виде пунктирной линии с треугольной не закрашенной стрелкой на конце, направленной от реализующей сущности к реализуемой.

В UML 2 определено 13 типов диаграмм. По стандартам каждая диаграмма должна иметь рамку с прямоугольником (правый нижний угол скошенный) в левом верхнем углу, в котором указывается идентификатор диаграммы (тег) и название.

Диаграммы для изображения структуры системы :

Диаграмма компонентов (component diagram, тег component );
Диаграмма размещения (deployment diagram, тег deployment );
Диаграмма классов (class diagram, тег class );
Диаграмма объектов (object diagram, тег object );
Диаграмма структуры внутренней (composite structure diagram, тег class );

Диаграммы для изображения поведения системы :

Диаграмма синхронизации (interaction diagram, тег timing );
Диаграмма деятельности (activity diagram, тег activity );
Диаграмма последовательности (sequence diagram, тег sd );
Диаграмма коммуникации (communication diagram, тег comm );
Диаграмма автомата (state machine diagram, тег state machine );
Обзорная диаграмма взаимодействия (interaction overview diagram, тег interaction );

Особняком стоят диаграммы:

Диаграмма использования(use case diagram, тег use case);
Диаграмма пакетов (package diagram, тег package );

Диаграмма использования

Диаграмма использования (use case diagram) - это наиболее общее представление функционального назначения системы.

Рассматривая диаграмму вариантов использования в качестве модели системы, можно ассоциировать ее с моделью черного ящика. Каждый вариант использования определяет последовательность действий, которые должны быть выполнены проектируемой системой при взаимодействии ее с соответствующим актером.

На диаграмме использования применяются два типа основных сущностей: варианты использования и действующие лица, между которыми устанавливаются следующие основные типы отношений.

Отношение ассоциации - это отношение устанавливает, какую конкретную роль играет актер при взаимодействии с экземпляром варианта использования. Отношение ассоциации обозначается сплошной линией между актером и вариантом использования. Эта линия может иметь дополнительные условные обозначения, такие, например, как имя и кратность.

Отношение расширения - определяет взаимосвязь экземпляров отдельного варианта использования с более общим вариантом, свойства которого определяются на основе способа совместного объединения данных экземпляров. Так, если имеет место отношение расширения от варианта использования А к варианту использования В, то это означает, что свойства экземпляра варианта использования В могут быть дополнены благодаря наличию свойств у расширенного варианта использования А.

Отношение расширения между вариантами использования обозначается пунктирной линией со стрелкой (вариант отношения зависимости), направленной от того варианта использования, который является расширением для исходного варианта использования.

Отношение обобщения служит для указания того факта, что некоторый вариант использования А может быть обобщен до варианта использования В. В этом случае вариант А будет являться специализацией варианта В. При этом В называется предком или родителем по отношению А, а вариант А - потомком по отношению к варианту использования В.

Графически данное отношение обозначается сплошной линией со стрелкой в форме не закрашенного треугольника, которая указывает на родительский вариант использования.

Отношение обобщения между вариантами использования применяется в том случае, когда необходимо отметить, что дочерние варианты использования обладают всеми атрибутами и особенностями поведения родительских вариантов.

Отношение включения между двумя вариантами использования указывает, что некоторое заданное поведение для одного варианта использования включается в качестве составного компонента в последовательность поведения другого варианта использования.

Отношение включения, направленное от варианта использования А к варианту использования В, указывает, что каждый экземпляр варианта А включает в себя функциональные свойства, заданные для варианта В.

Графически данное отношение обозначается пунктирной линией со стрелкой (вариант отношения зависимости), направленной от базового варианта использования к включаемому.

Диаграмма классов

Диаграмма классов (class diagram) - основной способ описания статической структуры системы.

На диаграмме классов применяется один основной тип сущностей: классы (включая многочисленные частные случаи классов: интерфейсы, примитивные типы, классы-ассоциации и т.д.), между которыми устанавливаются следующие основные типы отношений: зависимости, ассоциации, обобщения, реализации.

Отношение зависимости в общем случае указывает некоторое семантическое отношение между двумя элементами модели или двумя множествами таких элементов, которое не является отношением ассоциации, обобщения или реализации. Отношение зависимости используется в такой ситуации, когда некоторое изменение одного элемента модели может потребовать изменения другого зависимого от него элемента модели.

Отношение зависимости графически изображается пунктирной линией между соответствующими элементами со стрелкой на одном из ее концов, при этом стрелка направлена от класса-клиента зависимости к независимому классу или классу-источнику.

Над стрелкой могут находится специальные ключевые слова (стереотипы):

"access" - служит для обозначения доступности открытых атрибутов и операций класса-источника для классов-клиентов;
"bind" - класс-клиент может использовать некоторый шаблон для своей последующей параметризации;
"derive" - атрибуты класса-клиента могут быть вычислены по атрибутам класса-источника;
"import" - открытые атрибуты и операции класса-источника становятся частью класса-клиента, как если бы они были объявлены непосредственно в нем;
"refine" - указывает, что класс-клиент служит уточнением класса-источника в силу причин исторического характера, когда появляется дополнительная информация в ходе работы над проектом.

Отношение ассоциации соответствует наличию некоторого отношения между классами. Данное отношение обозначается сплошной линией с дополнительными специальными символами, которые характеризуют отдельные свойства конкретной ассоциации. В качестве дополнительных специальных символов могут использоваться имя ассоциации, а также имена и кратность классов-ролей ассоциации. Имя ассоциации является необязательным элементом ее обозначения.

Отношение агрегации имеет место между несколькими классами в том случае, если один из классов представляет собой некоторую сущность, включающую в себя в качестве составных частей другие сущности. Применяется для представления системных взаимосвязей типа "часть-целое".

Отношение композиции является частным случаем отношения агрегации. Это отношение служит для выделения специальной формы отношения "часть-целое", при которой составляющие части в некотором смысле находятся внутри целого. Специфика взаимосвязи между ними заключается в том, что части не могут выступать в отрыве от целого, т. е. с уничтожением целого уничтожаются и все его составные части.

Отношение обобщения является отношением между более общим элементом (родителем или предком) и более частным или специальным элементом (дочерним или потомком). Применительно к диаграмме классов данное отношение описывает иерархическое строение классов и наследование их свойств и поведения. При этом предполагается, что класс-потомок обладает всеми свойствами и поведением класса-предка, а также имеет свои собственные свойства и поведение, которые отсутствуют у класса-предка.

Диаграмма автомата

Диаграмма автомата (state machine diagram) или диаграмма состояний в UML 1 (state chart diagram) - это один из способов детального описания поведения в UML. В сущности, диаграммы автомата, как это следует из названия, представляют собой граф состояний и переходов конечного автомата нагруженный множеством дополнительных деталей и подробностей.

Диаграмма состояний описывает процесс изменения состояний только одного класса, а точнее - одного экземпляра определенного класса, т. е. моделирует все возможные изменения в состоянии конкретного объекта. При этом изменение состояния объекта может быть вызвано внешними воздействиями со стороны других объектов или извне. Именно для описания реакции объекта на подобные внешние воздействия и используются диаграммы состояний.

На диаграмме автомата применяют один основной тип сущностей - состояния, и один тип отношений - переходы, но и для тех и для других определено множество разновидностей, специальных случаев и дополнительных обозначений. Автомат представляет динамические аспекты моделируемой системы в виде ориентированного графа, вершины которого соответствуют состояниям, а дуги - переходам.

Начальное состояние представляет собой частный случай состояния, которое не содержит никаких внутренних действий (псевдосостояния). В этом состоянии находится объект по умолчанию в начальный момент времени. Оно служит для указания на диаграмме состояний графической области, от которой начинается процесс изменения состояний.

Конечное (финальное) состояние представляет собой частный случай состояния, которое также не содержит никаких внутренних действий (псевдосостояния). В этом состоянии будет находиться объект по умолчанию после завершения работы автомата в конечный момент времени.

Диаграмма деятельности

При моделировании поведения проектируемой или анализируемой системы возникает необходимость не только представить процесс изменения ее состояний, но и детализировать особенности алгоритмической и логической реализации выполняемых системой операций.

Диаграмма деятельности (activity diagram) - еще один способ описания поведения, который визуально напоминает старую добрую блок-схему алгоритма. Используется для моделирования процесса выполнения операций.

Основным направлением использования диаграмм деятельности является визуализация особенностей реализации операций классов, когда необходимо представить алгоритмы их выполнения.

На диаграмме деятельности применяют один основной тип сущностей - действие, и один тип отношений - переходы (передачи управления). Также используются такие конструкции как развилки, слияния, соединения, ветвления. Рекомендуется в качестве имени простого действия использовать глагол с пояснительными словами.

Диаграмма последовательности

Диаграмма последовательности (sequence diagram) - это способ описания поведения системы "на примерах".

Фактически, диаграмма последовательности - это запись протокола конкретного сеанса работы системы (или фрагмента такого протокола). В объектно-ориентированном программировании самым существенным во время выполнения является пересылка сообщений между взаимодействующими объектами. Именно последовательность посылок сообщений отображается на данной диаграмме, отсюда и название.

На диаграмме последовательности применяют один основной тип сущностей - экземпляры взаимодействующих классификаторов (в основном классов, компонентов и действующих лиц), и один тип отношений - связи, по которым происходит обмен сообщениями.

Возможные виды сообщений (изображение взято у larin.in):

Диаграмма коммуникации

Диаграмма коммуникации (communication diagram) - способ описания поведения, семантически эквивалентный диаграмме последовательности. Фактически, это такое же описание последовательности обмена сообщениями взаимодействующих экземпляров классификаторов, только выраженное другими графическими средствами.

Таким образом, на диаграмме коммуникации также как и на диаграмме последовательности применяют один основной тип сущностей - экземпляры взаимодействующих классификаторов и один тип отношений - связи. Однако здесь акцент делается не на времени, а на структуре связей между конкретными экземплярами.

Диаграмма компонентов

Диаграмма компонентов (component diagram) - показывает взаимосвязи между модулями (логическими или физическими), из которых состоит моделируемая система.

Основной тип сущностей на диаграмме компонентов - это сами компоненты, а также интерфейсы, посредством которых указывается взаимосвязь между компонентами. На диаграмме компонентов применяются следующие отношения:

реализации между компонентами и интерфейсами (компонент реализует интерфейс);
зависимости между компонентами и интерфейсами (компонент использует интерфейс);

Диаграмма размещения

Диаграмма размещения (deployment diagram) наряду с отображением состава и связей элементов системы показывает, как они физически размещены на вычислительных ресурсах во время выполнения.

На диаграмме размещения, по сравнению с диаграммой компонентов, добавляется два типа сущностей: артефакт, который является реализацией компонента и узел (может быть как классификатор, описывающий тип узла, так и конкретный экземпляр), а также отношение ассоциации между узлами, показывающее, что узлы физически связаны во время выполнения.

Диаграмма объектов

Диаграмма объектов (object diagram) - является экземпляром диаграммы классов.

На диаграмме объектов применяют один основной тип сущностей: объекты (экземпляры классов), между которыми указываются конкретные связи (чаще всего экземпляры ассоциаций). Диаграммы объектов имеют вспомогательный характер - по сути это примеры (можно сказать, дампы памяти), показывающие, какие имеются объекты и связи между ними в некоторый конкретный момент функционирования системы.

Диаграмма внутренней структуры (composite structure diagram) используется для более подробного представления структурных классификаторов, прежде всего классов и компонентов.

Структурный классификатор изображается в виде прямоугольника, в верхней части которого находится имя классификатора. Внутри находятся части (parts). Частей может быть несколько. Части могут взаимодействовать друг с другом. Это обозначается с помощью соединителей (connectors) различных видов. Место на внешней границе части, к которому присоединяется соединитель, называется портом (port). Порты располагаются также на внешней границе структурного классификатора.

Обзорная диаграмма взаимодействия (interaction overview diagram) является разновидностью диаграммы деятельности с расширенным синтаксисом: в качестве элементов обзорной диаграммы взаимодействия могут выступать ссылки на взаимодействия (interaction use), определяемые диаграммами последовательности.

Диаграмма синхронизации

Диаграмма синхронизации (timing diagram) представляет собой особую форму диаграммы последовательности, на которой особое внимание уделяется изменению состояний различных экземпляров классификаторов и их временной синхронизации.

Диаграмма пакетов

Диаграмма пакетов (package diagram) - единственное средство, позволяющее управлять сложностью самой модели.

Основные элементы нотации - пакеты и зависимости с различными стереотипами.

Модель сущность-связь (ER-модель)

Аналогом диаграммы классов (UML) может быть ER-модель , которая используется при проектировании баз-данных (реляционной модели).

Модель сущность-связь (ER-модель) - модель данных, позволяющая описывать концептуальные схемы предметной области. ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями. wikipedia

Любой фрагмент предметной области может быть представлен как множество сущностей, между которыми существует некоторое множество связей.

Основные понятия:

Сущность (entity) - это объект, который может быть идентифицирован неким способом, отличающим его от других объектов, например, КЛИЕНТ 777 . Сущность фактически представляет из себя множество атрибутов.

Набор сущностей (entity set) - множество сущностей одного типа (обладающих одинаковыми свойствами).

Связь (relationship) - это ассоциация, установленная между несколькими сущностями.

Домен (domain) - множество значений (область определения) атрибута.

Существует три типа бинарных связей:

один к одному - одиночный экземпляр сущности одного класса связан с одиночным экземпляром сущности другого класса, напимер, НАЧАЛЬНИК - ОТДЕЛ;
1 к N или один ко многим - одиночный экземпляр сущности одного класса связан со многими экземплярами сущности другого класса, например, ОТДЕЛ - СОТРУДНИК;
N к M или многие ко многим - многие экземпляры сущности одного класса связаны со многими экземплярами сущности другого класса, например, СОТРУДНИК - ПРОЕКТ;

Словарь основных понятий по UML

Объект (object) - сущность, обладающая уникальностью и инкапсулирующая в себе состояние и поведение.

Класс (class) - описание множества объектов с общими атрибутами, определяющими состояние, и операциями, определяющими поведение.

Интерфейс (interface) - именованное множество операций, определяющее набор услуг, которые могут быть запрошены потребителем и предоставлены поставщиком услуг.

Кооперация (collaboration) - совокупность объектов, которые взаимодействуют для достижения некоторой цели.

Действующее лицо (actor) - сущность, находящаяся вне моделируемой системы и непосредственно взаимодействующая с ней.

Компонент (component) - модульная часть системы с четко определенным набором требуемых и предоставляемых интерфейсов.

Артефакт (artifact) - элемент информации, который используется или порождается в процессе разработки программного обеспечения. Другими словами, артефакт - это физическая единица реализации, получаемая из элемента модели (например, класса или компонента).

Узел (node) - вычислительный ресурс, на котором размещаются и при необходимости выполняются артефакты.

Поведенческие сущности предназначены для описания поведения. Основных поведенческих сущностей всего две: состояние и действие.

Состояние (state) - период в жизненном цикле объекта, находясь в котором объект удовлетворяет некоторому условию и осуществляет собственную деятельность или ожидает наступления некоторого события.

Действие (action) - примитивное атомарное вычисление.

Автомат является пакетом, в котором определено множество понятий, необходимых для представления поведения моделируемой сущности в виде дискретного пространства с конечным числом состояний и переходов.

Классификатор (classifier) - это дескриптор множества однотипных объектов.

Дополнительное чтиво

Фаулер М. UML. Основы, 3-е издание
Буч Г., Рамбо Д., Якобсон И. Язык UML. Руководство пользователя

Показать разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами.

В качестве физических компонент могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т. п.

План действий

После ознакомления с разделами («Пример», «Применение») вы можете попробовать свои силы в самостоятельном составлении диаграмм компонентов.

Как применять метод проектирования

Диаграммы компонентов следует применять, когда система разделяется на компоненты и надо показать их взаимоотношения посредством интерфейсов или схему компонентов в низкоуровневой структуре системы.

Пример использования

В объектно-ориентированном сообществе идут дебаты о том, в чем состоит различие между компонентом и обычным классом . Мы не станем обсуждать здесь этот спорный вопрос, но покажем нотацию языка UML, используемую, чтобы отличить их друг от друга.

В UML 1 был отдельный символ для компонента (рис. 14.1). В UML 2 этого значка нет, но можно обозначить прямоугольник класса похожим значком. Или можно воспользоваться ключевым словом «component » (компонент ).

Кроме этого значка компоненты не принесли с собой никаких новых обозначений. Компоненты связываются между собой с помощью предоставляемых или требуемых интерфейсов, при этом шарово-гнездовая нотация обычно применяется только на диаграммах классов. Можно также разбивать компоненты на части с помощью диаграмм составных структур.

На рис. 14.2 показан пример простой диаграммы компонентов. В этом примере компонент Till (Касса) может взаимодействовать с компонентом Sales Server (Сервер продаж) с помощью интерфейса sales message (Сообщение о продажах). Поскольку сеть ненадежна, то компонент Message Queue (Очередь сообщений) установлен так, чтобы касса могла общаться с сервером, когда сеть работает, и разговаривать с очередью сообщений, когда сеть отключена. Тогда очередь сообщений сможет поговорить с сервером, когда сеть снова станет доступной. В результате очередь сообщений предоставляет интерфейс для разговора с кассой, и требует такой же интерфейс для разговора с сервером. Сервер разделен на два основных компонента: Transaction Processor (Процессор транзакций) реализует интерфейс сообщений, а Accounting Driver (Драйвер счетов) общается с Accounting System (Система ведения счетов) .

Вопрос о сущности компонента является предметом бесконечных споров. Вот одно из наиболее продуманных суждений, обнаруженных нами:

Компоненты – это не технология. Технические специалисты считают их трудными для понимания. Компоненты – это скорее стиль отношения клиентов к программному обеспечению. Они хотят иметь возможность покупать необходимое им программное обеспечение частями, а также иметь возможность обновлять его, как они обновляют свою стереосистему. Они хотят, чтобы новые компоненты работали так же, как и прежние, и обновлять их согласно своим планам, а не по указанию производителей. Они хотят, чтобы системы различных производителей могли работать вместе и были взаимозаменяемыми. Это очень разумные требования. Одна загвоздка: их трудно выполнить.
Ральф Джонсон (Ralph Johnson), http://www.c2.com/cgi/wiki?DoComponentsExist

Важно то, что компоненты представляют элементы, которые можно независимо друг от друга купить и обновить. В результате разделение системы на компоненты является в большей мере маркетинговым решением, чем техническим. Прекрасное руководство по данному вопросу представляет книга Хохмана . Она также напоминает о том, что следует остерегаться разделения системы на слишком мелкие компоненты, поскольку очень большим количеством компонентов трудно управлять, особенно когда производство версий поднимает свою уродливую голову; отсюда пошло выражение «ад DLL» или «dll hell» . В ранних версиях языка UML компоненты применялись для представления физических структур, таких как DLL. Теперь это не актуально; в настоящее время эта задача решается при помощи артефактов (artifacts ).

Подписывайтесь на новости сайта, форму подписки вы можете найти в правой колонке сайта.

Если вы хотите научиться работать на фрилансе профессионально, приглашаем на курс « ».