Автор работы: Пользователь скрыл имя, 16 Мая 2013 в 12:24, курсовая работа
Целью курсовой работы является изучение принципов моделирования информационных систем, создание программного изделия, предназначенного для автоматизации Рекламного агентства. Оно позволяет значительно повысить производительность труда за счет автоматизации некоторых функций, которые раньше выполнялись вручную.
Для достижения цели следует выполнить следующие задачи:
Выбор CASE-средства для моделирования информационной системы.
Разработать диаграммe вариантов использования.
Провести анализ предметной области. Для этого нужно рассмотреть структуру всей организации, установить конкретные задачи, выполняемые каждым сотрудником;
В процессе функционирования объектно-ориентированных систем одни объекты могут находиться в активном состоянии, непосредственно выполняя определенные действия, или состоянии пассивного ожидания сообщений от других объектов. Чтобы явно выделить подобную активность объектов, в языке UML применяется специальное понятие, получившее название фокуса управления (focus of control). Фокус управления изображается в форме вытянутого узкого прямоугольника, верхняя сторона которого обозначает начало получения фокуса управления объекта (начало активности), а его нижняя сторона - окончание фокуса управления (окончание активности). Прямоугольник располагается ниже обозначения соответствующего объекта и может заменять его линию жизни, если на всем ее протяжении он является активным.
Периоды активности объекта могут чередоваться с периодами его пассивности или ожидания. В этом случае у такого объекта имеются несколько фокусов управления. Важно сознавать, что получить фокус управления может только существующий объект, у которого в этот момент имеется линия жизни. Если же некоторый объект был уничтожен, то вновь возникнуть в системе он уже не может. Вместо него лишь может быть создан другой экземпляр этого же класса, который, строго говоря, будет являться другим объектом.
В отдельных случаях инициатором взаимодействия в системе может быть актер или внешний пользователь. В этом случае актер изображается на диаграмме последовательности самым первым объектом слева со своим фокусом управления. Чаще всего актер и его фокус управления будут существовать в системе постоянно, отмечая характерную для пользователя активность в инициировании взаимодействий с системой. При этом актер может иметь собственное имя или оставаться анонимным.
Иногда некоторый объект может инициировать рекурсивное взаимодействие с самим собой. Наличие во многих языках программирования специальных средств построения рекурсивных процедур требует визуализации соответствующих понятий в форме графических примитивов. На диаграмме последовательности рекурсия обозначается небольшим прямоугольником, присоединенным к правой стороне фокуса управления того объекта, для которого изображается это рекурсивное взаимодействие.
В UML каждое взаимодействие описывается совокупностью сообщений, которыми участвующие в нем объекты обмениваются между собой. Сообщение (message) представляет собой законченный фрагмент информации, который отправляется одним объектом другому. Прием сообщения инициирует выполнение определенных действий, направленных на решение отдельной задачи тем объектом, которому это сообщение отправлено.
Первоначальным и необходимым условием для нашей информационной системы является факт оформления заказа. Диаграмма последовательности для процесса ввода заказа нового клиента представлена на рисунке 4.
Координатор при создании (1: создание нового заказа) заказа выбирает такую форму какую ему нужно заполнить, для нового заказа «ввод заказа». Затем вносит параметры заказа на рекламу (2: Определение новых параметров).
Затем необходимо отправить запрос в бухгалтерию для расчета стоимости заказа на рекламную компанию (3: расчет). После полученного расчета стоимости координатор переходит к оформлению договора (4: оформление). Диаграмма последовательности для процесса ввода заказа на рисунке 5.
Далее координатору необходимо выдать задание дизайнеру. Для этого координатор собирает информацию о продукции, с помощью которой определяет наиболее эффективный вид рекламы. После чего уточняет средства размещения. С учетом определенных выше параметров составляется бюджет на рекламную компанию. Затем вся собранная информация передается в виде задания дизайнеру. Диаграмма последовательности для процесса выдачи задания дизайнеру на рисунке 6.
Не менее важным чем предыдущие пункты является составление отчета о рекламной компании. В отчет входят следующие пункты: записывается вид рекламы, описывается основная идея рекламной компании, определяет сроки выполнения рекламной компанией, рассчитывается общая стоимость рекламной компании (сюда входят дополнительные расходы и расчет эффективности рекламной компании, то есть анализ выгодности и прибыльности рекламной компании), создается макет и уже на основании всего выше изложенного создается отчет. Диаграмма последовательности для процесса составления отчета о рекламной компании на рисунке 7.
Рисунок 4 - Диаграмма последовательности для процесса оформления клиентом заказа
Рисунок 5 - Диаграмма последовательности для процесса ввод заказа
Рисунок 6 - Диаграмма последовательности для процесса выдача задания дизайнеру
Рисунок 7 - Диаграмма последовательности для процесса составления отчета о рекламной компании
Главная особенность диаграммы кооперации заключается в возможности графически представить не только последовательность взаимодействия, но и все структурные отношения между объектами, участвующими в этом взаимодействии.
Прежде всего, на диаграмме кооперации в виде прямоугольников изображаются участвующие во взаимодействии объекты, содержащие имя объекта, его класс и, возможно, значения атрибутов. Далее, как и на диаграмме классов, указываются ассоциации между объектами в виде различных соединительных линий. При этом можно явно указать имена ассоциации и ролей, которые играют объекты в данной ассоциации. Дополнительно могут быть изображены динамические связи - потоки сообщений. Они представляются также в виде соединительных линий между объектами, над которыми располагается стрелка с указанием направления, имени сообщения и порядкового номера в общей последовательности инициализации сообщений.
В отличие от диаграммы последовательности, на диаграмме кооперации изображаются только отношения между объектами, играющими определенные роли во взаимодействии. На этой диаграмме не указывается время в виде отдельного измерения. Поэтому последовательность взаимодействий и параллельных потоков может быть определена с помощью порядковых номеров. Следовательно, если необходимо явно специфицировать взаимосвязи между объектами в реальном времени, лучше это делать на диаграмме последовательности.
Понятие кооперации (collaboration) является одним из фундаментальных понятий в языке UML. Оно служит для обозначения множества взаимодействующих с определенной целью объектов в общем контексте моделируемой системы. Цель самой кооперации состоит в том, чтобы специфицировать особенности реализации отдельных наиболее значимых операций в системе. Кооперация определяет структуру поведения системы в терминах взаимодействия участников этой кооперации.
Диаграмма кооперации уровня спецификации показывает роли, которые играют участвующие во взаимодействии элементы. Элементами кооперации на этом уровне являются классы и ассоциации, которые обозначают отдельные роли классификаторов и ассоциации между участниками кооперации.
Диаграмма кооперации уровня примеров представляется совокупностью объектов (экземпляры классов) и связей (экземпляры ассоциаций). При этом связи дополняются стрелками сообщений. На данном уровне показываются только объекты, имеющие непосредственное отношение к реализации операции или классификатора. При этом вовсе не обязательно изображать все свойства или все ассоциации, поскольку на диаграмме кооперации присутствуют только роли классификаторов, но не сами классификаторы. Таким образом, в то время как классификатор требует полного описания всех своих экземпляров, роль классификатора требует описания только тех свойств и ассоциаций, которые необходимы для участия в отдельной кооперации.
Отсюда вытекает важное следствие. Одна и та же совокупность объектов может участвовать в различных кооперациях. В зависимости от рассматриваемой кооперации, могут изменяться как свойства отдельных объектов, так и связи между ними. Именно это отличает диаграмму кооперации от диаграммы классов, на которой должны быть указаны все свойства и ассоциации между элементами диаграммы.
Кооперация на уровне спецификации изображается на диаграмме пунктирным эллипсом, внутри которого записывается имя этой кооперации. Такое представление кооперации относится к отдельному варианту использования и детализирует особенности его последующей реализации. Символ эллипса кооперации соединяется отрезками пунктирной линии с каждым из участников этой кооперации, в качестве которых могут выступать объекты или классы. Каждая из этих пунктирных линий помечается ролью (role) участника. Роли соответствуют именам элементов в контексте всей кооперации. Эти имена трактуются как параметры, которые ограничивают спецификацию элементов при любом их появлении в отдельных представлениях модели.
Простой класс на диаграмме кооперации обозначается прямоугольником класса, внутри которого записывается строка текста. Эта строка текста называется ролью классификатора (classifier role). Роль классификатора показывает особенность использования объектов данного класса. Обычно в прямоугольнике показывается только секция имени класса, хотя не исключается возможность указания секций атрибутов и операций.
Если кооперация допускает обобщенное представление, то на диаграммах могут быть указаны отношения обобщения соответствующих элементов. Этот способ может быть использован для определения отдельных коопераций, которые являются частным случаем или специализацией другой кооперации. Такая ситуация изображается обычной стрелкой обобщения, направленной от символа дочерней кооперации к символу кооперации-предка. Роли дочерних коопераций могут быть специализациями ролей коопераций-предков.
В отдельных случаях возникает необходимость явно указать тот факт, что кооперация является реализацией некоторой операции или классификатора. Это можно представить одним из двух способов.
Во-первых, можно соединить символ кооперации пунктирной линией со стрелкой обобщения с символом класса, реализацию операции которого специфицирует данная кооперация.
Во-вторых, можно просто изобразить символ кооперации, внутри которого указать всю необходимую информацию, записанную по определенным правилам. Эти правила определяют формат записи имени кооперации, после которого записывают двоеточие и имя класса. За именем класса следует двойное двоеточие и имя операции.
Подобное общее представление кооперации на уровне спецификации используется на начальных этапах проектирования. В последующем каждая из коопераций подлежит детализации на уровне примеров, на котором раскрывается содержание и структура взаимосвязей ее элементов на отдельной диаграмме кооперации. В этом случае в качестве элементов диаграммы кооперации выступают объекты и связи, дополненные сообщениями.
После создания диаграмм последовательностей, были получены новые объекты такие как стоимость заказа, сроки выполнения, бухгалтерия и другие. Для всех этих объектов создадим классы, и сгруппируем их в пакеты. В качестве языка программирования выберем язык C++, это позволит добавить классам параметры операций, типы данных и типы возвращаемых значений. На рисунках 8, 9, 10 представлены полученные диаграммы классов сгруппированные по пакетам: границы, управление и сущности.
Рисунок 8 – Диаграмма классов для пакета границы
Рисунок 9 – Диаграмма классов для пакета сущности
Рисунок 10 – Диаграмма классов для пакета управление
В процессе проектирования диаграммы последовательностей были немного изменены. Объекты были наделены классами, а сообщения стали методами этих классов. На основе уже изменённых диаграмм последовательностей создадим диаграммы коопераций. Они приведены на рисунках 11-15.
Рисунок 11 – Клиент
Рисунок 12 – Ввод заказа
Рисунок 13 – Выдача задания дизайнеру
Рисунок 14 – Составление отчета
Рисунок 15 – Расчет стоимости рекламной компании
Каждая диаграмма состояний в UML описывает все возможные состояния одного экземпляра определенного класса и возможные последовательности его переходов из одного состояния в другое, то есть моделирует все изменения состояний объекта как его реакцию на внешние воздействия.
Диаграммы состояний чаще всего используются для описания поведения отдельных объектов, но также могут быть применены для спецификации функциональности других компонентов моделей, таких как варианты использования, актеры, подсистемы, операции и методы.
Диаграмма состояний является графом специального вида, который представляет некоторый автомат. Вершинами графа являются возможные состояния автомата, изображаемые соответствующими графическими символами, а дуги обозначают его переходы из состояния в состояние. Диаграммы состояний могут быть вложены друг в друга для более детального представления отдельных элементов модели.
В метамодели UML автомат является пакетом, в котором определено множество понятий, необходимых для представления поведения моделируемой сущности в виде дискретного пространства с конечным числом состояний и переходов.
Длительность нахождения системы в любом из возможных состояний существенно превышает время, которое затрачивается на переход из одного состояния в другое. Предполагается, что в пределе время перехода может быть равно нулю (если дополнительно не оговорено другое), то есть смена состояний объекта может происходить мгновенно.
В языке UML под состоянием понимается абстрактный метакласс, используемый для моделирования отдельной ситуации, в течение которой выполняются некоторые условия. Состояние может быть задано в виде набора конкретных значений атрибутов класса или объекта. Изменение отдельных значений атрибутов будет отражать изменение состояния моделируемого класса или объекта.