Расчет стоимости потока работ

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

Введем следующие обозначения:

·  - общая расчетная стоимость реализации деятельности ;

· – количество экземпляров j-го ресурса, задействованного в реализации деятельности ;

·  – повременная стоимость использования экземпляра j-го ресурса;

·  – длительность использования экземпляра j-го ресурса

· - дополнительные затраты по реализации деятельности .

Тогда общая расчетная стоимость реализации деятельности будет рассчитываться по следующей формуле:

,                (5.1.)

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

Пример 1. Расчет стоимости реализации деятельности

Для реализации деятельности требуется один представитель заказчика, час рабочего времени которого оплачивается в размере 200 руб. (рис 5.8). Длительность реализации деятельности  составляет 30 минут, на протяжении которых ресурс задействован полностью. Дополнительные затраты при реализации деятельности  составляют 100 руб. Общая расчетная стоимость деятельности , рассчитанная по формуле 1.1. составит 1*200*0,5 + 100 = 200 руб.

Рис. 5.8. Пример расчета стоимости реализации деятельности.

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

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

,                                      (5.2)

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

Так в приведенном на рисунке 5.9 примере общая расчетная стоимость потока работ составит 200+100+150+100=550 (руб.)

Рис. 5.9. Общая расчетная стоимость потока работ с последовательно реализуемыми состояниями деятельности.

Пример 3. Параллельные потоки работ

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

                                      (5.3)

где:

- n - количество параллельных потоков, j=1..n,

- - длительность реализации j-го потока работ.

Например, для диаграммы, приведенной на рисунке 5.10., общая длительность потока работ составит 8 минут.

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

 Рис. 5.10. Диаграмма деятельности, содержащая параллельные потоки работ.

Пример 4. Альтернативные потоки

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

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

Так на рисунке 5.11. общая расчетная стоимость всего потока работ составит 0,2*100 + 0,8*10=28 (руб).

Рис. 5.11. Диаграмма деятельности, содержащая альтернативные потоки работ.

Пример 5. Потоки работ, содержащие сторожевые условия

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

 

Рис. 5.12. Диаграмма деятельности, содержащая сторожевые условия для параллельных потоков работ.

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

Выбор лучших альтернатив

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

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

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

· Изменяют набор используемых для реализации потока работ ресурсов. Как правило, идут по пути устранения состояния деятельности, реализации которых требует участия человека, заменяя их автоматизированными.

 

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

Общие сведения

Центральное место в ООАП занимает разработка логической модели системы в виде диаграммы классов. Нотация классов в языке UML проста и интуитивно понятна всем, кто когда-либо имел опыт работы с CASE-инструментариями. Схожая нотация применяется и для объектов — экземпляров класса, с тем различием, что к имени класса добавляется имя объекта и вся надпись подчеркивается.

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

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

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

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

Класс

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

Рисунок 6.1. Графическое представление класса на диаграмме.

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

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

Даже если секция атрибутов и операций является пустой, в обозначении класса она выделяется горизонтальной линией. Примеры графического изображения классов на диаграмме приведены на рис. 6.2. В первом случае для класса "Прямоугольник" (рис. 6.2, а) указаны только его атрибуты — точки на координатной плоскости, которые определяют его расположение. Для класса "Окно" (рис. 6.2, б) указаны только его операции, секция атрибутов оставлена пустой. Для класса "Счет" (рис. 6.2, в) дополнительно изображена четвертая секция, в которой указано исключение — отказ от обработки просроченной кредитной карточки.

 

Рисунок 6.2. Примеры изображения классов на диаграмме

Имя класса

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

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

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

В некоторых случаях необходимо явно указать, к какому пакету относится тот или иной класс. Для этой цели используется специальный символ разделитель — двойное двоеточие "::". Синтаксис строки имени класса в этом случае будет следующий: <Имя_Пакета>::<Имя_Класса>. Другими словами, перед именем класса должно быть явно указано имя пакета, к которому его следует отнести. Например, если определен пакет с именем "Банк", то класс "Счет" в этом банке может быть записан в виде: "Банк::Счет".

Атрибуты класса

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

<квантор видимости><имя атрибута>: <тип атрибута> = <исходное значение>{строка-свойство}

Квантор видимости может принимать одно из трех возможных значений и, соответственно, отображается при помощи специальных символов:

· Символ "+" обозначает атрибут с областью видимости типа общедоступный (public). Атрибут с этой областью видимости доступен или виден из любого другого класса пакета, в котором определена диаграмма.

· Символ "#" обозначает атрибут с областью видимости типа защищенный (protected). Атрибут с этой областью видимости недоступен или невиден для всех классов, за исключением подклассов данного класса.

· Символ "-" обозначает атрибут с областью видимости типа закрытый (private). Атрибут с этой областью видимости недоступен для всех классов без исключения.

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

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

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

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

Можно привести следующие примеры задания имен и типов атрибутов классов:

· цвет: Color — здесь цвет является именем атрибута, Color — именем типа данного атрибута. Указанная запись может определять традиционно используемую RGB-модель (красный, зеленый, синий) для представления цвета. В этом случае имя типа Color как раз и характеризует семантическую конструкцию, которая применяется в большинстве языков программирования для представления цвета.

· видимость: Boolean — здесь видимость есть имя абстрактного атрибута, который может характеризовать наличие визуального представления соответствующего класса на экране монитора. В этом случае тип Boolean означает, что возможными значениями данного атрибута является одно из двух логических значений: истина (true) или ложь (false). При этом значение истина может соответствовать наличию графического изображения на экране монитора, а значение ложь — его отсутствию. Абстрактный характер данного атрибута обозначается курсивным текстом в записи данного атрибута.

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

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

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

· цвет: Color = (255, 0, 0) — в RGB-модели цвета это соответствует чистому красному цвету в качестве исходного значения для данного атрибута;

· видимость: Boolean = true — может соответствовать ситуации, когда в момент создания экземпляра класса создается видимое на экране монитора окно, соответствующее данному объекту.

· форма: Многоугольник = прямоугольник — речь идет о геометрической форме создаваемого объекта.

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

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

Например, если некоторый атрибут задан в виде форма: Прямоугольник, то это будет означать, что все объекты данного класса могут иметь несколько различных форм, каждая из которых является прямоугольником. Другим примером может служить задание атрибута в виде номер_счета: Integer, что может означать для объекта Сотрудник наличие некоторого подмножества счетов, общее количество которых заранее не фиксируется.

Строка-свойство служит для указания значений атрибута, которые не могут быть изменены в программе при работе с данным типом объектов. Фигурные скобки как раз и обозначают фиксированное значение соответствующего атрибута для класса в целом, которое должны принимать все вновь создаваемые экземпляры класса без исключения. Это значение принимается за исходное значение атрибута, которое не может быть переопределено в последующем. Отсутствие строки-свойства по умолчанию трактуется так, что значение соответствующего атрибута может быть изменено в программе. Например, строка-свойство в записи атрибута заработная_плата: Currency = {$500} может служить для обозначения фиксированной заработной платы для каждого объекта класса "Сотрудник" определенной должности в некоторой организации. С другой стороны, запись данного атрибута в виде заработная_плата: Currency = $500 означает уже нечто иное, а именно — при создании нового экземпляра Сотрудник (аналогия — прием на работу нового сотрудника) для него устанавливается по умолчанию заработная плата в $500. Однако для отдельных сотрудников могут быть сделаны исключения как в большую, так и в меньшую сторону, о чем необходимо позаботиться дополнительно в программе.

Операции класса

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

<квантор видимости><имя операции>(список параметров):

<выражение типа возвращаемого значения>{строка-свойство}

Квантор видимости, как и в случае атрибутов класса, может принимать одно из трех возможных значений и, соответственно, отображается при помощи специального символа. Символ "+" обозначает операцию с областью видимости типа общедоступный (public). Символ "#" обозначает операцию с областью видимости типа защищенный (protected). И, наконец, символ "-" используется для обозначения операции с областью видимости типа закрытый (private).

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

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

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

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

<имя параметра>: <выражение типа> = <значение параметра по умолчанию>.

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

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

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

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

Для повышения производительности системы одни операции могут выполняться параллельно или одновременно, а другие — только последовательно. В этом случае для указания параллельности выполнения операции используется строка-свойство вида “{concurrency = имя}”, где имя может принимать одно из следующих значений: последовательная (sequential), параллельная (concurrent), охраняемая (guarded). При этом придерживаются следующей семантики для данных значений:

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

· параллельная (concurrent) — данная операция в силу своих особенностей может выполняться параллельно с другими операциями в системе, при этом параллельность должна поддерживаться на уровне реализации модели.

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

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

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

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

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

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

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

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

· +нарисовать(форма: Многоугольник = прямоугольник, цвет_заливки: Color = (0, 0, 255)) — может обозначать операцию по изображению на экране монитора прямоугольной области синего цвета, если не указываются другие значения в качестве аргументов данной операции.

· запросить_счет_клиента(номер_счета: Integer): Currency — обозначает операцию по установлению наличия средств на текущем счете клиента банка. При этом аргументом данной операции является номер счета клиента, который записывается в виде целого числа (например, "123456"). Результатом выполнения этой операции является некоторое число, записанное в принятом денежном формате (например, $1 500.00).

· выдать_сообщение():{"Ошибка деления на ноль"} — смысл данной операции не требует пояснения, поскольку содержится в строке-свойстве операции. Данное сообщение может появиться на экране монитора в случае попытки деления некоторого числа на ноль, что недопустимо.

Отношения между классами

Кроме внутреннего устройства или структуры классов на диаграмме указываются различные отношения. При этом совокупность типов таких отношений фиксирована в языке UML и предопределена семантикой этих типов отношений. Базовыми отношениями в языке UML являются:

· Отношение зависимости (dependency relationship)

· Отношение ассоциации (association relationship)

· Отношение обобщения (generalization relationship)

· Отношение реализации (realization relationship)

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

Отношение зависимости

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

Отношение зависимости графически изображается пунктирной линией между соответствующими элементами со стрелкой на одном из ее концов. На диаграмме классов данное отношение связывает отдельные классы между собой, при этом стрелка направлена от класса-клиента зависимости к независимому классу или классу-источнику, как показано на рис. 6.3. На данном рисунке изображены два класса: Класс_А и Класс_Б, при этом Класс_Б является источником некоторой зависимости, а Класс_А — клиентом этой зависимости.

Рисунок 6.3. Графическое изображение отношения зависимости на диаграмме классов

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

Рисунок 6.4. Графическое представление зависимости между несколькими классами

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

· "access" — служит для обозначения доступности открытых атрибутов и операций класса-источника для классов-клиентов;

· "bind" — класс-клиент может использовать некоторый шаблон для своей последующей параметризации;

· "derive" — атрибуты класса-клиента могут быть вычислены по атрибутам класса-источника;

· "import" — открытые атрибуты и операции класса-источника становятся частью класса-клиента, как если бы они были объявлены непосредственно в нем;

· "refine" — указывает, что класс-клиент служит уточнением класса-источника в силу причин исторического характера, когда появляется дополнительная информация в ходе работы над проектом.

При генерации кода для классов, между которыми установлено отношение зависимости, Rational Rose не добавляет к ним никаких новых атрибутов.

В качестве примера предположим, что между классами Жилец и Дом существует отношение зависимости, как показано на рис. 6.5. При генерации кода для этих классов к ним не добавляются новые атрибуты, но со­здаются специфические для языка операторы, необходимые для поддержки связи. Например, на язы­ке C++ в код войдут операторы  #include.

Рисунок 6.5. Пример отношения зависимости.

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

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

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

Зависимость между пакетами

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

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

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

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

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

Чтобы разбить циклическую зависимость, разделите пакет на два. В нашем примере можно взять классы пакета В, от которых зависит А, и переместить их в третий пакет С. Тогда зависимости паке­тов будут выглядеть так, как показано на рис. 6.6.

Рисунок 6.6. Зависимость между пакетами.

Отношение ассоциации

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

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

В качестве простого примера отношения бинарной ассоциации рассмотрим отношение между двумя классами — классом "Компания" и класс