Материал: Технол_разраб_прогр_обесп_Гагарина_Кокарева

Область данных

Поел едовател ьн ый вызов

Параллельный вызов

Рис. 4.5. Типы вызовов модулей

Для моделирования условных и циклических вызовов применяются следующие узлы (рис. 4.6):

• условный узел применяется для моделирования конструкций IF-THEN-ELSE (на диаграмме из узла выходят два потока) и IF-THEN (из узла выходит один поток). Условный узел изображается в виде ромба, потоки — альтернативные вызовы — изображаются выходящими из него;

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

а б в

Рис. 4.6. Условные и циклические вызовы модулей: а — циклический; б — условный; в — однократный

Если необходимо показать, что подчиненный модуль вызывается однократно, это осуществляется указанием цифры «1» рядом со стрелкой, обозначающей вызов модуля-наследника.

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

7Т

Г Массив Массив ]

Сортировка

Рис. 4.8. Пример структурной карты Константайна Результат приведен на рис. 4.8.

4-/.5, Структурные карты Джексона

Техника структурных карт Джексона основана на методе структурного программирования Джексона, который выявляет соответствие между структурой потоков данных и структурой программы [39]. Основное внимание в методе сконцентрировано _на соответствии входных и выходных потоков данных. Структуры на диаграммах Джексона строятся из четырех основных компонентов, представленных на рис. 4.9:

• операция — блок кодов, имеющий один вход и один выход (рис. 4.9, а);

• следование — последовательное выполнение операций слева направо (рис. 4.9, б);

• выбор — выполнение одной из операций в зависимости от выполнения условия (рис. 4.9, в);

• итерация — многократное выполнение блока (рис. 4.9, г).

Операция

Рис. 4.9. Элементы структурных диаграмм Джексона

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

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

Программа

Цикл-пока не конец файла Прочитать запись

Сравнить заданные поля с критерием поиска Если совпали

Сохранить в выходной список Конец-если Конец-цикл Вывод результирующего списка Конец-программа

Программа поиска нужного принтера

Считывание записи из файла

Сравнение содержимого с заданным критерием

Вывод записей о принтерах

Рис. 4.10. Структурная карта Джексона

Полученная структурная карта Джексона приведена на рис. 4.10.

4./.6. CASE-технологии

CASE-технологии (Computer-Aided Software/System Engineering — разработка программного обеспечения/систем с использованием компьютерной поддержки) — это реализованные в виде программных продуктов технологические системы, ориентированные на создание сложных программных систем и поддержку их полного жизненного цикла или его основных этапов. В настоящее время CASE-технологии используются не только для производства ПП, но и как мощный инструмент решения исследовательских и проектных задач (структурный анализ предметной области, моделирование деловых предложений с целью решения задач оперативного и стратегического планирования и управления ресурсами) [53].

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

СА5Е-средства обладают следующими основными достоинствами:

• повышают качество создаваемого ПО с помощью средств автоматического контроля;

• ускоряют процесс проектирования и разработки;

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

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

• поддерживают технологии повторного использования компонентов ПО;

• поддерживают развитие и сопровождение разработки. При использовании САБЕ-технологий изменяются фазы жизненного цикла программного продукта, как показано в табл. 4.2.

Таблица 4.2. Сравнительная характеристика этапов жизненного цикла ПО

Наиболее просто автоматизируемыми оказались стадии «контроль проекта» и «кодогенерация», хотя все остальные этапы Жизненного цикла ПО также поддерживаются СА8Е-технология-ми. Кроме изменения содержания фаз, существенно изменилось Распределение трудозатрат по фазам, как показано в табл. 4.3.

Таблица 4.4 содержит сравнительную характеристику целей и содержания этапов жизненного цикла ПО при традиционной разработке и с помощью САБЕ-средств.

Таблица 4.4. Цели и содержание этапов жизненного цикла ПО

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

Чем же принципиально СА8Е-технология отличается от традиционной технологии разработки ПО? Девизом разработчиков

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

Большинство CASE-технологий основано на парадигме методология/метод/нотация/средство.

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

Метод определяет способ достижения той или иной цели.

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

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

Наиболее часто и эффективно в методологии структурного анализа используются следующие средства:

• DFD (Data Flow Diagrams) — диаграммы потоков данных совместно со словарями данных и спецификациями процессов;

• ERD (Entity-Relationship Diagrams) диаграммы «сущность—связь»;

• STD (State Transition Diagrams) — диаграммы переходов состояний.

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

• по типу целевых систем — для систем реального времени и для информационных систем;

• по отношению к школам — Software Engineering (SE) и Information Engineering (IE);

• по порядку построения моделей — процедурно-ориентированные, ориентированные на данные и информационно-ориентированные.

В табл. 4.5 приведены отличия информационных систем от систем реального времени.

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

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

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

Ниже приводится деление CASE-средств по функциональным характеристикам.

Анализ и проектирование

Данные средства применяются для проектирования и создания спецификаций программной системы, поддерживают SE и IE:

• CASE-аналитик (Эйтекс);

• POSE (Computer Systems Advisers);

• Design/IDEF (Meta Software);

• BPWin (Logic Works);

• SELECT (Select Software Tools); . CASE/4/0 (micro TOOl GmbH);

• и ряд других средств.

Проектирование баз данных и файлов

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

кода:

• ERWin (Logic Works);

• S-Designor (SPD);

• Designtr/2000 (Oracle);

• Sillverrun (Computer Systems Advisers).

Программирование

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

• COBOL 2/Workbench (Mikro Focus);

• DECASE (DEC);

• NETRON/CAP (Netron);

• APS (Sage Softwfre).

Сопровождение и реинжиниринг

К этим средствам относятся документаторы, анализаторы программ, средства реструктурирования:

• Adpac CASE Tools (Adpac);

• Scan/COBOL и Superstructure (Computer Data Systems);

• Inshtctor/Recoder (language Tecnologe).

4.1.7. Ускорение разработки программного обеспечения. Методология RAD

В связи с развитием CASE-технологий в рамках спиральной модели жизненного цикла ПО в последнее время широкое распространение получила методология быстрой разработки приложений RAD (Rapid Application Development). Процесс разработки при этом содержит три элемента [53]:

• небольшую команду программистов (от 2 до 10 человек), что облегчает управление проектом;

• короткий, но тщательно проработанный производственный график (от 2 до 6 мес), повышает эффективность работы;

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

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

Жизненный цикл ПО по методологии RAD состоит из четырех фаз:

• анализа и планирования требований;

• проектирования;

• реализации;

• внедрения.

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

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

По результатам анализа процессов принимается решение о количестве, составляющих ИС подсистем, поддающихся разработке одной командой разработчиков за приемлемое для RAD-проектов время — порядка 2—3 мес.

Результатом данной фазы должны быть:

• общая информационная модель системы;

• функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;

• точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;

• построенные прототипы экранов, отчетов, диалогов. Использование CASE-средств позволяет избежать искажения

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

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

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

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

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

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

Основные принципы методологии RAD:

• итерационная разработка приложений;

• необязательность полного завершения работ на каждом из этапов жизненного цикла;

• применение CASE-средств, обеспечивающих целостность данных;

• участие конечных пользователей в процессе разработки ИС;

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

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

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

• четкое планирование и контроль выполнения работ.

4.2. Проектирование программного обеспечения при объектном подходе

Задачи проектирования включают в себя две составляющие: логическое и физическое проектирование программных продуктов. Логическое проектирование заключается в разработке классов для реализации их экземпляров — объектов. Для этого требуется подробное описание полей и методов классов, а также связей между ними. Для этого используются статические диаграммы классов и объектов, динамические — последовательностей состояний и кооперации. Физическое проектирование предполагает построение программных компонентов из ранее определенных классов и объектов и размещение их на конкретных вычислительных устройствах. Разрабатываемые на этом этапе диаграммы — компонентов и развертывания [1].

4.2.1- Разработка структуры программного обеспечения при объектном подходе

На этапе проектирования уточняются поля и методы классов, а также отношения между классами. Все это находит отражение на диаграмме классов.

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

• управляющий класс (control class) отвечает за координацию действий других классов и контролирует последовательность выполнения действий варианта использования для данного ПО. На каждой диаграмме классов должен быть хотя бы один управляющий класс (рис. 4.11, а).

• класс-сущность (entity class) — пассивный класс, информация о котором должна храниться постоянно. Как правило, этот класс соответствует отдельной таблице базы данных. В этом случае его атрибуты являются полями таблицы, а операции — присоединенными или хранимыми процедурами (рис. 4.11, 5);

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

а б в

Рис. 4.11. Графическое изображение классов для моделирования программного

обеспечения:

а — управляющий класс; б — класс-сущность; в — граничный класс Отношения между классами

Кроме внутреннего устройства или структуры классов, на диаграмме классов необходимо отобразить различные отношения между ними. Основными отношениями или связями в языке UML являются [48]:

• отношение зависимости (dependency relationship);

• отношение ассоциации (association relationship);

• отношение обобщения (generalization relationship);

• отношение реализации (realization relationship).

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

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

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

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

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

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

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

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

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

К таким свойствам относятся:

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

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

В рассмотренном ранее примере (см. рис. 4.12) кратность «1» для класса «Группа» означает, что каждый студент может учиться только в одной группе. Кратность «1..*» для класса «Студент» означает, что в каждой группе могут учиться несколько студентов, общее число которых заранее неизвестно и ничем не ограничено, но всегда больше нуля.

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

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

Лицо

Компания

Рис. 4.15. Графическое изображение исключающей ассоциации между тремя

классами

Отношение агрегации

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

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

Агрегация является частным случаем ассоциации и изображается в виде пустой ассоциации с незакрашенным ромбом со стороны «целого» (рис. 4.16).

Целое

Часть

Рис. 4.16. Графическое изображение отношения агрегации в языке иМЬ

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

Персональный компьютер

I

I

Системный блок

Монитор

Клавиатура

Мышь

Рис. 4.17. Диаграмма классов для иллюстрации отношения агрегации на примере структуры персонального компьютера

Отношение композиции

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

Графически отношение композиции изображается сплошной линией, один из концов которой представляет собой закрашенный внутри ромб. Этот ромб указывает на тот из классов, который представляет собой класс-композицию или «целое» (рис. 4.18).

Рис. 4.18. Графическое изображение отношения композиции в языке УМЬ

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

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

Окно_ программы

Полоса прокрутки

Заголовок

Рис. 4.19. Диаграмма классов для иллюстрации отношения композиции на примере класса окна программы

Отношение обобщения

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

Класс-предок <^

Класс-потомок

Рис. 4.20. Графическое изображение отношения обобщения в языке УМЬ

Пример отношения обобщения показан на рис 4.20. Здесь абстрактный класс «Геометрическая фигура» выступает в качестве суперкласса (класса-предка) для подклассов (классов-потомков), соответствующих конкретным геометрическим фигурам «Прямоугольник», «Окружность», «Эллипс» и др.

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

Геометрическая фигура

I

Прямоугольник

Окружность

Эллипс

Рис. 4.21. Пример графического изображения обобщения классов

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

Для того чтобы проиллюстрировать описанные выше типы отношений, рассмотрим следующий пример:

Пример 4.4. Разработать диаграмму классов для некоей компании — класс «Компания», которая состоит из нескольких отделов — класс «Отдел», каждый из которых располагается в своем офисе — класс «Офис», имеет штаб-квартиру класс «Штаб-квартира» и содержит штат сотрудников — класс «Person», сведения о которых содержатся в системе кадрового учета. Каждый из вышеприведенных классов обладает своими атрибутами и операциями и связан с другими классами определенным типом отношений.

Полученная диаграмма приведена на рис. 4.22.

Агрегирование

Кратность

Местонахождение

1..*

Офис

address: String voice: Number

Штаб-квартира

Имя

Обобщение

• Атрибуты

• Операции

getPhoto() getSoundBite() getContactlnformationO getPersonalRecordsQ

КонтактнаяИнформация

address: String

Интерфейс

ЗаписьКадровогоУчета

Зависимость

taxID

empoloymentHistory salary

«interface» ISecurelnformation

Рис. 4.22. Диаграммы классов

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

Интерфейсы

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

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

Объекты

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

Объект (object) — это отдельный экземпляр класса, который создается на этапе выполнения программы. Он имеет свое собственное имя и конкретные значения атрибутов. Имя объекта представляет собой строку текста «имя объекта» «имя класса», разделенную двоеточием. Для графического изображения объектов используется такой же символ прямоугольника, как и для классов, но имя объекта в отличие от имени класса выделяется подчеркиванием. Пример обозначения объектов приведен на рис. 4.24.

S: Студент

f • Функция

name = "Иванов" ball = 4.5

а

б

Рис. 4.24. Обозначения объектов

Пример диаграммы объектов компании, состоящей из нескольких отделов — объекты dl, d2, d3 класса «Department», приведен на рис. 4.25.

4,2,2- Диаграммы кооперации

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

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