Диаграммы взаимодействий в объектно-ориентированном подходе

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

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 07.11.2009
Размер файла 30,6 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Содержание

Введение

1. ТЕОРЕТИЧЕСКАЯ ЧАСТЬ. Основные принципы и возможности диаграмм взаимодействия в объектно-ориентированном подходе

1.1 Ведение в объектно-ориентированную методологию разработки систем

1.2 Сущность объектно-ориентированного подхода

1.3 Сущность диаграммы взаимодействия в объектно-ориентированном подходе

1.4 Примеры диаграмм взаимодействия

2. ПРАКТИЧЕСКАЯ ЧАСТЬ. Построение диаграммы взаимодействия в объектно-ориентированном подходе для прецедента бизнес модели в сфере обслуживания общественного питания на примере "Обслуживание в ресторане".

2.1 Описание предметной области организации в сфере общественного питания

2.2 Постановка задачи при построении диаграммы взаимодействий в объектно-ориентированном подходе для прецедента бизнес модели в сфере обслуживания общественного питания на примере "Обслуживание в ресторане"

2.3 Предоставление диаграммы взаимодействий в объектно-ориентированном подходе для прецедента бизнес модели в сфере обслуживания общественного питания на примере "Обслуживание в ресторане"

Заключение

Список литературы

Введение

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

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

* Выяснение структуры и взаимосвязи существующих объектов в бизнес модели.

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

* Описание взаимодействия объектов модели при выполнении потока событий.

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

1. для моделирования временной упорядоченности потоков управления.

2. для моделирования структурной организации потоков управления.

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

1. ТЕОРЕТИЧЕСКАЯ ЧАСТЬ

"Основные принципы и возможности диаграмм взаимодействия в объектно-ориентированном подходе"

1.1 Введение в объектно-ориентированную методологию разработки систем

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

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

-объектно-ориентированный анализ;

-объектно-ориентированное проектирование;

-объектно-ориентированное программирование.

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

В данном определении можно выделить три части:

1) объектно-ориентированное программирование использует в качестве элементов конструкции объекты, а не алгоритмы;

2) каждый объект является реализацией определенного класса;

3) классы организованы иерархически.

Объектно-ориентированное проектирование. Методы

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

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

1) объектно-ориентированное проектирование ведет к объектно-ориентированной декомпозиции;

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

На результатах ООА формируются модели, на которых основывается объектно-ориентированное проектирование; объектно-ориентированное проектирование в свою очередь создает основу для окончательной реализации системы с использованием методологии объектно-ориентированного программирования. Главными достоинствами ООМ по сравнению со структурными методами являются:

-возможность преодолеть ограничения, связанные со сложностью

разрабатываемых систем;

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

-применение как при анализе и проектировании информационных

систем, так и систем реального времени и аппаратно-программных

комплексов;

-обеспечение возможности повторного использования

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

-поддержка итеративного, а не лавинообразного, как в структурном подходе, процесса проектирования;

-естественная работа с разнородной информацией, используемой в

мультимедиа системах;

-создание более открытых систем;

-полное использование описательных возможностей объектно- ориентированных языков программирования.

1.2 Сущность объектно-ориентированного подхода

Принципиальное различие между структурным и объектно-ориентированным подходом заключается в способе декомпозиции системы. Объектно-ориентированный подход использует объектную декомпозицию, при этом статическая структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. Каждый объект системы обладает своим собственным поведением, моделирующим поведение объекта реального мира. Понятие "объект" впервые было использовано около 30 лет назад в технических средствах при попытках отойти от традиционной архитектуры фон Неймана и преодолеть барьер между высоким уровнем программных абстракций и низким уровнем абстрагирования на уровне компьютеров. С объектно-ориентированной архитектурой также тесно связаны объектно-ориентированные операционные системы. Однако наиболее значительный вклад в объектный подход был внесен объектными и объектно-ориентированными языками программирования: Simula, Smalltalk, C++, Object Pascal. На объектный подход оказали влияние также развивавшиеся достаточно независимо методы моделирования баз данных, в особенности подход "сущность-связь".

Концептуальной основой объектно-ориентированного подхода является объектная модель. Основными ее элементами являются:

* абстрагирование;

* инкапсуляция;

* модульность;

* иерархия.

Кроме основных элементов имеются еще три дополнительных элемента, не являющиеся строго обязательными:

* типизация,

* параллелизм,

* устойчивость.

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

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

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

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

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

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

Устойчивость -- свойство объекта существовать но времени (вне зависимости от процесса, породившего данный объект) и/или в пространстве (при перемещении объекта из адресного пространства, в котором он был создан).

Основные понятия объектно-ориентированного подхода - объект и класс.

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

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

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

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

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

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

1.3 Сущность диаграммы взаимодействия в объектно-ориентированном подходе

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

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

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

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

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

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

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

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

Как правило, диаграммы взаимодействий содержат:

* объекты;

* связи;

* сообщения.

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

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

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

Во-первых, на них показана линия жизни объекта. Это вертикальная пунктирная линия, отражающая существование объекта во времени. Большая часть объектов, представленных на диаграмме взаимодействий, существует на протяжении всего взаимодействия, поэтому их изображают в верхней части диаграммы, а их линии жизни прорисованы сверху донизу. Объекты могут создаваться и во время взаимодействий. Линии жизни таких объектов начинаются с получения сообщения со стереотипом create. Объекты могут также уничтожаться во время взаимодействий; в таком случае их линии жизни заканчиваются получением сообщения со стереотипом destroy, а в качестве визуального образа используется большая буква X, обозначающая конец жизни объекта. (Обстоятельства жизненного цикла объекта можно указывать с помощью ограничений new, destroyed и transient,)

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

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

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

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

У диаграмм кооперации есть два свойства, которые отличают их от диаграмм последовательностей.

Первое - это путь. Для описания связи одного объекта с другим к дальней концевой точке этой связи можно присоединить стереотип пути (например, local, показывающий, что помеченный объект является локальным по отношению к отправителю сообщения). Имеет смысл явным образом изображать путь связи только в отношении путей типа local, parameter, global и self(но не associations).

Второе свойство - это порядковый номер сообщения. Для обозначения временной последовательности перед сообщением можно поставить номер (нумерация начинается с единицы), который должен постепенно возрастать для каждого нового сообщения (2, 3 и. т.д.). Для обозначения вложенности используется десятичная нотация Дьюи (1 - первое сообщение; 1.1- первое сообщение, вложенное в сообщение 1; 1.2 - второе сообщение, вложенное в сообщение 1и т.д.). Уровень вложенности не ограничен. Для каждой связи можно показать несколько сообщений (вероятно, посылаемых разными отправителями), и каждое из них должно иметь уникальный порядковый номер.

Чаще всего придется моделировать неветвящиеся последовательные потоки управления. Однако можно моделировать и более сложные потоки, содержащие итерации и ветвления (для этого более удобна диаграмма деятельности). Итерация представляет собой повторяющуюся последовательность сообщений. Для ее моделирования перед номером сообщения в последовательности ставится выражение итерации, например * [i := 1. . n](или просто *, если надо обозначить итерацию без дальнейшей детализации). Итерация показывает, что сообщение (и все вложенные в него сообщения) будет повторяться в соответствии со значением заданного выражения. Аналогично условие представляет собой сообщение, выполнение которого зависит от результатов вычисления некоторого булевского выражения. Для моделирования условия перед порядковым номером сообщения ставится выражение, например [х>0]. У всех альтернативных ветвей будет один и тот же порядковый номер, но условия на каждой ветви должны быть заданы так, чтобы два из них не выполнялись одновременно (не перекрывались).

UML не определяет никакого особенного формата для выражений в квадратных скобках при описании итераций и ветвлений; можно использовать псевдокод или синтаксис какого-либо конкретного языка программирования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для более строгого и формального описания потока управления необходимо присоединить к каждому сообщению пред- и постусловия.

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

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

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

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

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

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

Хорошо структурированная диаграмма взаимодействий обладает следующими свойствами:

* акцентирует внимание только на одном аспекте динамики системы;

* содержит только такие прецеденты и актеры, которые важны для понимания этого аспекта;

* содержит только такие детали, которые соответствуют данному уровню абстракции, и только те дополнения, которые необходимы для понимания системы;

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

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

* необходимо дать ей имя, соответствующее ее назначению;

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

* расположить элементы так, чтобы свести к минимуму число пересечений;

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

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

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

1.4 Примеры диаграмм взаимодействия

Диаграммы взаимодействия (interaction diagrams) являются моделями, описывающими поведение взаимодействующих групп объектов. Как правило, диаграмма взаимодействия охватывает поведение объектов в рамках только одного варианта использования. На такой диаграмме отображается ряд объектов и те сообщения, которыми они обмениваются между собой. Проиллюстрируем данный подход на примере достаточно простого варианта использования, который описывает следующее поведение:

* Окно Ввода Заказа посылает Заказу сообщение "приготовиться".

* Заказ посылает данное сообщение каждой Строке заказа в данном Заказе.

* Каждая Строка заказа проверяет состояние определенного Запаса товара:

Если данная проверка удовлетворяется (результат -- true), то Строка заказа удаляет соответствующее количество товара из Запаса. В противном случае количество Запаса снижается до уровня повторного заказа, и Запас запрашивает новую поставку товара.

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

На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии (рис. 2.1). Эта вертикальная линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия. Такую форму представления впервые ввел Ивар Якобсон.

Каждое сообщение представляется в виде стрелки между линиями жизни двух объектов. Сообщения появляются в том порядке, как они показаны на странице -- сверху вниз. Каждое сообщение помечается, как минимум, именем сообщения; при желании можно добавить также аргументы и некоторую управляющую информацию и, кроме того, можно показать само делегирование (self-delegation) -- сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни. Из всей возможной управляющей информации два ее вида имеют существенное значение. Во-первых, это условие, показывающее, когда посылается сообщение (например, [нужен Повторный Заказ = "true"]). Сообщение посылается только при выполнении данного условия. Другой полезный управляющий маркер -- это маркер итерации, показывающий, что сообщение посылается много раз для множества объектов-адресатов (например,* приготовиться). Диаграммы последовательности очень просты и наглядны (в этом заключается самое большое их достоинство) и существенно помогают разобраться в процессе поведения системы. Диаграмма (см. рис. 2.1) содержит возврат, означающий не новое сообщение, а возврат из сообщения. На диаграмме возврат отличается от обычных сообщений тем, что его стрелка не сплошная, а имеет вид пары линий. Диаграммы последовательности можно также использовать для представления параллельных процессов. На рис. 2.2 изображен ряд объектов, участвующих в проверке банковской транзакции. В момент создания Транзакции она порождает Координатор Транзакции в целях координации проверок, выполненных Транзакцией.

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

* создавать новую ветвь процесса (в этом случае оно связано с самой верхней частью активизации);

* создавать новый объект;

* устанавливать связь с уже выполняющейся ветвью процесса.

Удаление объекта показано с помощью большого знака "X". Объекты могут выполнить самоуничтожение или могут быть уничтожены посредством еще одного сообщения. Используя механизм активизаций, можно более четко показать смысл само делегирования. Без них, или без такого обозначения с помощью столбиков, которое здесь используется, довольно трудно определить, где же выполняются следующие после само делегирования вызовы -- то ли в вызывающем методе, то ли в вызываемом методе. Активизации вносят ясность в этот вопрос.

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

Независимо от используемой схемы нумерации на диаграмме можно разместить такого же рода управляющую информацию, как и на диаграмме последовательности. На рис. 2.3 можно увидеть различные формы схемы именования объектов, принятые в UML. Общая форма имеет вид <Имя Объекта: Имя Класса>, где-либо имя объекта, либо имя класса может отсутствовать. При отсутствии имени объекта остается двоеточие, чтобы было понятно, что это имя класса, а не объекта.

2. ПРАКТИЧЕСКАЯ ЧАСТЬ

Построение диаграммы взаимодействий в объектно-ориентированном подходе для прецедента бизнес модели в сфере обслуживания общественного питания на примере "Обслуживание в ресторане".

2.1 Описание предметной области организации в сфере общественного питания.

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

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

В соответствии с ГОСТ Р 50762-95 "Общественное питание. Классификация предприятий", утвержденному Постановлением Госстандарта России от 5 апреля 1995 года №198 (далее ГОСТ Р 50762-95) установлена следующая классификация типов предприятий общественного питания:

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

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

? кафе - предприятие, оказывающее услуги по организации питания и отдыха потребителей с предоставлением ограниченного по сравнению с рестораном ассортимента продукции. Реализует фирменные, заказные блюда, изделия и напитки;

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

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

Кроме того, в ГОСТ Р 50647-94 дополнительно выделены следующие объекты сферы общественного питания:

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

* столовая - раздаточная - столовая, реализующая готовую продукцию, получаемую от других организаций общественного питания;

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

То есть, как видно из приведенного списка, классификация предприятий общественного питания зависит от таких факторов, как:

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

? техническая оснащенность предприятия общественного питания;

? квалификация персонала;

? качество и методы обслуживания;

? виды предоставляемых услуг.

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

При определении класса предприятия учитывают следующие факторы:

* уровень обслуживания;

* изысканность интерьера;

* номенклатура предоставляемых услуг.

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

Обязательные требования:

* вывеска световая с элементами оформления;

* оформление залов и помещений с использованием изысканных декоративных элементов;

* наличие эстрады и танцевальной площадки;

* наличие банкетного зала и отдельных кабин;

* система кондиционирования воздуха с автоматическим поддержанием оптимальных параметров температуры и влажности;

* мебель повышенной комфортности, соответствующая интерьеру помещений;

* столы с мягким покрытием;

* кресла (диваны, банкетки) мягкие (в холле и вестибюле);

* кресла мягкие с подлокотниками в обеденном зале;

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

* фарфорофаянсовая посуда с монограммой или художественно - оформленная (допускается из керамики, дерева и т.п.);

* сортовая стеклянная посуда из хрусталя, художественно оформленная посуда из выдувного стекла;

* скатерти фирменные белые или цветные;

* салфетки полотняные индивидуального пользования;

* смена столового белья после обслуживания посетителей;

* меню и прейскурант с эмблемой предприятия на национальном и русском языках типографским способом;

* обложка меню с эмблемой или рисунком из мелованной бумаги, картона, кожзаменителя;

* печатная реклама (пригласительные карточки, буклеты);

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

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

* выполнение особых пожеланий по изготовлению блюд на виду у потребителя;

* обслуживание официантами, барменами, метрдотелями, имеющими специальное образование и прошедшими профессиональную подготовку;

* наличие у обслуживающего персонала форменной одежды с эмблемой и обуви;

* выступление вокально-инструментальных ансамблей, солистов.

* наличие у обслуживающего персонала санитарной одежды.

Подтверждение соответствия предприятия общественного питания выбранному типу и классу производится органами по сертификации, аккредитованными Комитетом Российской Федерации по стандартизации, метрологии и сертификации в установленном порядке.

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

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

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

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

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

Услуги, предоставляемые потребителям организациями общественного питания, можно подразделить на:

o услуги питания;

o услуги по изготовлению кулинарной продукции и кондитерских изделий;

o услуги по организации потребления и обслуживания;

o услуги по реализации продукции;

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

? услуги питания ресторанов;

? услуги питания баров;

? услуги питания кафе;

? услуги питания столовых;

? услуги питания закусочных.

К услугам по изготовлению кулинарной продукции и кондитерских изделий относятся такие виды услуг как:

? изготовление кулинарной продукции и кондитерских изделий по заказам потребителей;

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

? изготовление кулинарной продукции и кондитерских изделий на дому.

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

? организация и обслуживание торжеств и ритуальных мероприятий;

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

? доставка продукции и обслуживание потребителей на рабочих местах и на дому;

? услуги официанта на дому;

? доставка кулинарной продукции и кондитерских изделий в номера гостиниц;

? организация комплексного питания и прочие.

К услугам по реализации продукции в общественном питании относятся:

? реализация продукции и изделий кухни через магазины - кулинарии и буфеты;

? отпуск обедов на дом.

Услуги по организации досуга включают в себя:

* организацию музыкального обслуживания;

* проведение концертов и других подобных мероприятий;

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

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

2.2 Постановка задачи при построении диаграммы взаимодействий в объектно-ориентированном подходе для прецедента бизнес модели в сфере обслуживания общественного питания на примере "Обслуживание в ресторане".

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

2.3 Предоставление диаграммы взаимодействия в объектно-ориентированном подходе для прецедента бизнес модели в сфере обслуживания общественного питания на примере "Обслуживание в ресторане"

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

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

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

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

Заключение

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

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


Подобные документы

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

    курсовая работа [2,3 M], добавлен 10.05.2015

  • Унифицированный язык моделирования. Методы объектно-ориентированного анализа и проектирования. Создание диаграммы последовательности и диаграммы сотрудничества. Главная диаграмма классов. Добавление связей между классами. Зависимость между пакетами.

    курсовая работа [2,7 M], добавлен 23.06.2011

  • Особенности объектно-ориентированного проектирования. Основные понятия объектно-ориентированного подхода. Основы языка UML, варианты его использования. Диаграммы классов и взаимодействия. Разработка диаграммы прецедентов (вариантов использования).

    курсовая работа [1,1 M], добавлен 13.05.2014

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

    реферат [273,2 K], добавлен 09.06.2009

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

    курсовая работа [262,5 K], добавлен 10.07.2014

  • Использование объектно-ориентированного программирования - хорошее решение при разработке крупных программных проектов. Объект и класс как основа объектно-ориентированного языка. Понятие объектно-ориентированных языков. Языки и программное окружение.

    контрольная работа [60,1 K], добавлен 17.01.2011

  • Анализ объектно-ориентированного программирования, имитирующего способы выполнения предметов. Основные принципы объектно-ориентированного программирования: инкапсуляция, наследование, полиморфизм. Понятие классов, полей, методов, сообщений, событий.

    контрольная работа [51,7 K], добавлен 22.01.2013

  • Анализ проблематики построения объектно-ориентированного канала связи. Основные понятия протокола Modbus. Возможности CodeSys для реализации объектно-ориентированного подхода. Разработка методики кроссплатформенной библиотеки для интеграции устройств.

    курсовая работа [38,6 K], добавлен 15.06.2013

  • Создание программы "Ликероводочный завод" на основе объектно-ориентированного подхода: проектирование иерархии классов и интерфейсов на основе выделенных сущности. Применение принципа инкапсуляции к классам. Тестирование готового программного продукта.

    курсовая работа [573,2 K], добавлен 23.06.2012

  • История судоку, правила игры и цель головоломки. Разработка диаграммы классов. Реализация программы в объектно-ориентированном стиле по принципам модульности, иерархичности, ограничения доступа. Алгоритм генерации случайного игрового поля судоку.

    курсовая работа [315,9 K], добавлен 01.02.2013

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.