Объектно-ориентированное моделирование на основе UML

Размещено на http://www.allbest.ru/

Контрольная работа

«Объектно-ориентированное моделирование на основе UML»

Преподаватель: Коротков Е.А.

Студент: Белогурова Н.Г.

№ личного дела: 100.16/120413

4 курс БИ

Липецк 2015

Введение

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

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

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

1. Анализ предметной области, задачи которой подлежат автоматизации

валютный rational rose программный

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

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

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

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

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

1. СОЗДАНИЕ ДИАГРАММЫ ПРЕЦЕДЕНТОВ

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

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

На рисунке 1 приведена диаграмма использования(прецедентов), спроектированная в среде RationalRose.

Рисунок 1 «Диаграмма прецедентов»

2. СОЗДАНИЕ ДИАГРАММЫ КЛАССОВ

Class diagram (диаграммы классов) позволяет создавать логическое представление системы, на основе которого создается исходный код описанных классов.

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

Под поведением объекта в UML понимаются любые правила взаимодействия объекта с внешним миром и с данными самого объекта.

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

· Верхняя секция (секция имени) содержит имя класса и другие общие свойства (в частности, стереотип).

· В средней секции содержится список атрибутов

· В нижней - список операций класса, отражающих его поведение (действия, выполняемые классом).

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

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

Диаграмма классов представлена на рисунке 2.

Рисунок 2 «Диаграмма классов»

3. СОЗДАНИЕ ДИАГРАММЫ КООПЕРАЦИИ

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

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

Диаграмма коопераций представлена на рисунке 3.

Рисунок 3 «Диаграмма кооперации»

4. СОЗДАНИЕ ДИАГРАММЫ ПОСЛЕДОВАТЕЛЬНОСТИ

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

Диаграмма последовательности представлена на рисунке 4.

Рисунок 4 «Диаграмма последовательности»

5. СОЗДАНИЕ ДИАГРАММЫ СОСТОЯНИЙ

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

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

Диаграмма состояний представлении на рисунке 5.

Рисунок 5 «Диаграмма состояний»

5. СОЗДАНИЕ ДИАГРАММЫ ДЕЯТЕЛЬНОСТИ

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

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

Диаграмма деятельности представлена на рисунке 6.

Рисунок 6 «Диаграмма деятельности»

Литература

1. Боггс У., Боггс М.. UML и Rational Rose: Пер. с англ. - М.: Издательство "Лори", 2009.- 581 с, ил.

2. Буч Г., Рамбо Д., Джекобсон А. Язык UML для пользователя: Пер. с англ. - М.: ДМК, 2009.- 432 е., ил. (Серия "для программистов").

3. Ларман К. применение UML и шаблонов проектирования: Пер. с англ. - М.: Издательский дом "Вильяме", 2012. - 496 с, ил.

4. Кураев Е.А. Банковские системы: Издательский дом "Глория", 2013.-225 с.,ил (Валютные операции с вкладами)

5. Родионова В.М. Банковские операции: Под ред. Родионовой В.М.,2011.- 112с,ил (Валютные операции с вкладами)

Размещено на Allbest.ru