Разработка модели программного обеспечения информационной системы автоматизации работы рекламного агентства

Рис.16. Диаграмма последовательности для прецедента «Авторизоваться»

В данную диаграмму в качестве пограничного класса был добавлен класс «Форма авторизации». Он будет содержать необходимые методы и будет добавлен в конечную диаграмму классов (статическую модель). Инициаторами взаимодействия здесь являются три субъекта: менеджер, администратор и руководство агентства. Каждый, из которых, имеет свое определенное имя и пароль для входа в систему. Каждый из них имеет доступ только к определенной информации предназначающейся для определенного субъекта. Пограничный класс «СУ» осуществляет управление системой. А пограничный класс «СУБД» хранит в себе всю информацию которая находится в системе.

Рис. 17. Диаграмма последовательности для прецедента «Внести первоначальные сведения о клиенте»

Здесь пограничным классом является «Окно регистрации клиента», в которое администратором вводятся необходимые данные о клиенте.

Рис. 18. Диаграмма последовательности для прецедента «Заключить договор»

В данную диаграмму последовательности был внесен пограничный класс «Форма договора» и «Принтер». Благодаря «Принтеру» осуществляется распечатка договора.

Рис. 19. Диаграмма последовательности для прецедента «Зарегистрировать событие»

Менеджер вносит информацию о действии по отношению к каждому клиенту в Окно регистрации событий. Затем данные передаются в «СУ» и сохраняются в «СУБД».

Рис. 20. Диаграмма последовательности для прецедента «Контроль соблюдения договоров»

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

Рис. 21. Диаграмма последовательности для прецедента «Регистрация факта оплаты»

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

Рис. 22. Диаграмма последовательности для прецедента «Сформировать список свободных рекламных площадей»

В диаграмме последовательности представленной на рис.11 отражается работа системы при формировании списка свободных рекламных площадей.

5.2 Диаграммы коопераций

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

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

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

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

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

Рис. 23. Диаграмма кооперации для прецедента «Авторизоваться»

Рис. 24. Диаграмма кооперации для прецедента «Внести первоначальные сведения о клиенте»

Рис. 25. Диаграмма кооперации для прецедента «Заключить договор»

Рис. 26. Диаграмма кооперации для прецедента «Зарегистрировать событие»

Рис. 27. Диаграмма кооперации для прецедента «Осуществить текущий контроль за договорами»

Рис. 28. Диаграмма кооперации для прецедента «Регистрация факта оплаты»

Рис. 29. Диаграмма кооперации для прецедента «Сформировать список свободных рекламных площадей»

6. Моделирование состояний

Модель состояний (statechart model) служит детализированным описанием класса или, более точно, динамических изменений состояний класса.

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

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

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

Значения атрибутов объекта изменяются, однако не все подобные изменения приводят к переходу между состояниями.

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

Диаграмму состояний для класса «Событие» считаем строить не целесообразным, так как он включает в себя лишь одно состояние Зарегистрировано.

Построим диаграмму состояний для класса «Рекламная услуга» и представим ее на рисунке 30.

Рис. 30. Диаграмма состояний класса «Рекламная услуга»

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

Рис. 31. Диаграмма состояний класса «Рекламная площадь»

Первоначально объект находится в состоянии «Внесена в список». Система проверяет сроки окончания ее использования. Если срок истек то она переходит в состояние «Свободна». Если рекламная площадь предоставляется клиенту, то она переходит в состояние «Используется». Из него она автоматически переходит в состояние «Не оплачена». После того как клиент производит оплату, в зависимости от того оплатил он полностью или частично, объект переходит в состояния «Оплачено полностью» или «Оплачено частично». Из состояния «Оплачено частично», после завершения оплаты объект переходит в состояние «Оплачено полностью». Из состояния «Используется», после истечения договора, она возвращается в состояние «Свободна».

Рис. 32. Диаграмма состояний класса «Договор с клиентом»

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

Рис. 33. Диаграмма состояний класса «Клиент»

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

Рис. 34. Диаграмма состояний класса «Менеджер»

Диаграмма состояний класса «Менеджер». Первоначально объект находится в состоянии «Зарегистрирован».Администратором ему присвоены имя и пароль для входа в систему. Если он в данное время не работает с системой, то ему присваивается состояние «Вне системы». Если менеджер прошел авторизацию, то он переходит в состояние «Активен». Из этого состояния объект может перейти в состояние «Регистрирует событие», либо в состояние «Заключает договор», либо в состояние «Контроль договора». После выхода из системы объекту вновь переходит в состояние «Вне системы».

7. Проектирование статической структуры ИС

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

Рис.35. Статическая структура ИС

8. Модель базы данных системы

Рис. 36. Модель базы данных системы рекламного агентства

Заключение

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

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

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

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

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

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

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

Так же мы попытались построить схему модели базы данных.

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