Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (Базовые составляющие объектно-ориентированного подхода).pdf

– асинхронное сообщение (англ. asynchronous message). Клиент посылает сообщение серверу и, не дожидаясь ответа, продолжает выполнять следующие операции;

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

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

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

UML регламентирует также два часто встречаемых вида сообщений - на создание и уничтожение объектов. Первое отображается как возвращающее сообщение со стереотипом «create», второе - как синхронное сообщение со стереотипом «destroy». После получения сообщения на уничтожение объекта его линия жизни заканчивается символом X.

Каждое сообщение должно иметь имя по одному из следующих вариантов:

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

- указание стереотипа для некоторых стандартных действий:

- «create» (англ. – создать) – возвращающее сообщение, требующее создания объекта;

- «destroy» (англ. – уничтожить) – синхронное сообщение с требованием уничтожить соответствующий объект;

- «call» (англ. – вызвать) – синхронное сообщение, требующее выполнения операции принимающего объекта;

- «send» (англ. – послать) – асинхронное сообщение, обозначающее посылку сигнала серверу;

- «return» (англ. – возвратить) или «reply» (англ. – ответить)– возвращающее сообщение;

- указание спецификации вызываемого метода объекта-получателя в формате:

[переменная =] имя([список параметров]) [:возвращаемое значение].

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

Имя сообщения (обязательный параметр) – имя вызываемого метода объекта-получателя.

Список аргументов – список аргументов, разделенных запятыми и передаваемых для выполнения метода.

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

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

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

3.4.6 Назначение и состав диаграммы коммуникации

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

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

ЗАКЛЮЧЕНИЕ

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

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

Другим важным достоинством объектно-ориентированного подхода является более тесная связь между разрабатываемыми моделями и исходным кодом программ. Если в структурных методологиях прямое и обратное проектирование возможно лишь при использовании диаграмм сущность-связь (ERD), то CASE-средства, поддерживающие UML, эти операции позволяют выполнять, как минимум, с тремя видами диаграмм: классов, последовательности и коммуникации.

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

СПИСОК ЛИТЕРАТУРЫ

1. ГОСТ Р ИСО/МЭК 12207–02. Информационная технология. Процессы жизненного цикла программных средств.

2. Буч, Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++ / Г. Буч. – М.: Бином, 2001. – 560 с.

3. Буч, Г. Язык UML. Руководство пользователя / Г. Буч, Дж. Рамбо, А. Якобсон. - СПб.: Питер, 2004. - 432 с.

4. Леоненков, А.В. Самоучитель UML 2 / А.В. Леоненков. – СПб.: БХВ - Петербург, 2007. – 576с.

5. Леоненков, А.В. Объектно-ориентированный анализ и проектирование с использованием UML / А.В. Леоненков. – www.intuit.ru.

6. Якобсон, А. Унифицированный процесс разработки программного обеспечения / А. Якобсон, Г. Буч, Дж. Рамбо. - СПб.: Питер, 2002. - 496 с.

7. Крачтен, Ф. Введение в Rational Unified Process / Ф. Кратчен. - М.: Издательский дом «Вильямс», 2002. - 240 с.

8. Ларман, К. Применение UML и шаблонов проектирования: Уч. Пос / К. Ларман. - М.: Издательский дом «Вильямс», 2001. - 496 с.

9. Гранд, М. Шаблоны проектирования в Java / М. Гранд. - М.: Новое знание, 2004. - 559 с.

10. Терра-Лексикон: Иллюстрированный энциклопедический словарь. – М.: ТЕРРА, 1998. - 672 с.