21. Диаграмма деятельности (действий). Диаграмма компонентов.

Диаграмма деятельности (действий)

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

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

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

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

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

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

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

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

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

22. Диаграмма развертывания. Преимущества и недостатки объектно-ориентированного подхода.

Диаграмма развертывания

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

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

Преимущества и недостатки объектно-ориентированного подхода

Преимущества этого подхода:

• интуитивная близость произвольной предметной области;

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

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

• высокий уровень абстракции;

• возможность повторного использования описаний (основана на обращении к полям и методам извне описания классов, а также на использовании механизма наследования);

• параметризация методов обработки объектов (основана на использовании механизма интерфейсов).

К недостаткам объектно-ориентированного подхода к программированию возможно отнести сложность тестирования и верификации программ.

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

Преимущества объектно-ориентированного подхода:

• Сокращение числа возможных ошибок. Типичными ошибками при решении различных задач являются несогласованные параметры подпрограмм и несогласованное изменение атрибутов;

• Повторное использование. Предполагается какой-либо вариант многократного использования уже существующего проекта или его части в новом проекте. Его можно разделить на две категории:

  • повторного использования существующего кода для решения модифицированной задачи;

  • повторное использование и для решения других задач в данной предметной области.

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

Недостатки объектно-ориентированного подхода:

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

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