Связывающие классы линии показывают взаимодействие между классами. Так, класс Account (счет) связан с классом ATM Screen (экран ATM), потому что они непосредственно взаимодействуют друг с другом. Класс Card Reader (устройство для чтения карточек) не связан с классом Cash Dispenser (кассовый аппарат), поскольку они не общаются друг с другом непосредственно. Обратите внимание, что слева от некоторых атрибутов и операций имеются маленькие зн&чки в виде висячего замка. Они указывают, что атрибут или операция класса закрыта (private). Доступ к закрытым атрибутам или операциям возможен только из содержащего их класса. Account Number, PIN и Balance — закрытые атри­буты класса Account. Кроме того, закрытыми являются операции Deduct Funds и Verify Funds.

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

55. Объектно - ориентированное проектирование программного обеспечения на этапе технического проектирования (с использованием диаграмм взаимодействия и состояния).

Техническое проектирование [preliminary design ] – Стадия работ по проектированию АС, которая включает:

· Разработку проектных решений по системе и её частям;

· Разработку документации на АС и её части;

· Разработку и оформление документации на поставку изделий для комплектования АС и/или технических требований (технических заданий) на их разработку;

· Разработка заданий на проектирование в смежных частях проекта объекта автоматизации.

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

Диаграммы взаимодействия (interaction diagrams) описывают поведение взаимодействующих групп объектов.

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

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

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

Сообщение-запрос (interrogative) – это сообщение, запрашивающее выдачу некоторой информации об объекте-получателе.

Императивное (imperative) сообщение – это сообщение, запрашивающее у объекта-получателя выполнение некоторых действий.

Существует два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams).

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

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

На диаграмме Состояний показывают именно эту информацию.

На рис.приведен пример диаграммы Состояний для банковского счета.

На данной диаграмме показаны возможные состояния счета, а также процесс перехода счета из одного состояния в другое. Например, если клиент требует закрыть открытый счет, последний пере­ходит в состояние "Закрыт". Требование клиента называется событием (event), именно события вызы­вают переход из одного состояния в другое.

Рис.5 Диаграмма Состояний для класса Account

Когда клиент снимает деньги с открытого счета, счет может перейти в состояние "Превышение кредита". Это происходит, только если баланс по счету меньше нуля, что отражено условием [отрицательный баланс] на нашей диаграмме. Заключенное в квадратные скобки условие (guard condition) определяет, когда может или не может произойти переход из одного состояния в другое.

Ha диаграмме имеются два специальных состояния — начальное (start) и конечное (stop). Начальное состояние выделяется черной точкой, оно соответствует состоянию объекта в момент его создания. Конечное состояние обозначается черной точкой в белом кружке, оно соответствует состоянию объекта непосредственно перед его уничтожением. На диаграмме Состояний может быть одно и только одно начальное состояние. В то же время может быть столько конечных состояний, сколько вам нужно, или их может не быть вообще.

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

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

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

56. Объектно - ориентированное проектирование программного обеспечения на этапе рабочего проектирования (с использованием диаграмм деятельности и компонентов).