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

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

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

Введение

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

Рекламное агентство осуществляет предоставление рекламных услуг клиентам. В распоряжении агентства находятся несколько видов рекламных услуг (реклама в Интернете, щитовая реклама, реклама в печатных изданиях и на CD дисках), которые предлагаются клиентам. Клиент в праве выбрать и заключить договор на предоставление нескольких видов рекламных услуг. Агентство заинтересовано в привлечении как можно большего количества клиентов и расширении спектра предоставляемых услуг, а также рекламных площадей. Задачи расширения спектра услуг и увеличения количества рекламных площадей решаются руководством агентства. Задачи привлечения клиентов и продажи услуг агентства возложены на менеджеров.

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

Основная рутинная работа агентства связана с поиском рекламодателей и заключением с ними договоров. Эта задача возложена на менеджеров.

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

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

Администратор системы осуществляет ее безопасность. Для этого он назначает всем пользователям системы (менеджерам) имена и пароли. В задачи администратора также входит назначение менеджерам клиентов и ввод реквизитов клиентов в систему.

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

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

1. Анализ требований

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

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

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

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

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

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

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

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

Данная работа выполняется в следующей последовательности:

· выявление вариантов использования,

· выявление классов-сущностей,

· моделирование видов деятельности,

· моделирование взаимодействий,

· моделирование состояний,

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

2. Выявление вариантов использования

2.1 Выделение субъектов (актеров) и прецедентов (видов деятельности)

Прецедент (use case) выполняет бизнес-функцию, которую может наблюдать внешний субъект и которая может быть впоследствии отдельно протестирована в процессе разработки.

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

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

Исходя из определения субъектов и требований, приведенных в задании, были выделены следующие субъекты:

Рис. 1. Субъекты (actors)

программный информационный прецедент

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

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

Таблица 1. Распределение требований по субъектам и прецедентам

№	Требования	Субъект	Прецедент
1	Менеджер должен определить список свободных в настоящее время рекламных площадей для дальнейшего заключения договора с клиентом. Этот список так же предоставляется системой.	Менеджер	Сформировать список свободных рекламных площадей.
2	При начале очередного действия, в отношении с клиентом, менеджер вносит информацию о нем в систему. Таким образом, он регистрирует в системе событие. При регистрации события фиксируется время и дата его совершения, а так же результаты. В результате звонка, менеджер может договориться с клиентом о заключении договора. Менеджер также может получить отказ от использования услуг данного рекламного агентства. В случае отказа, он и его причины должны фиксироваться в системе.	Менеджер	Зарегистрировать событие.
3	После согласования всех условий, указанных в договоре клиент заключает договор с агентством.	Менеджер, Руководство.	Подготовить договор. Заключить договор.
4	После заключения договора клиент обязан оплатить услуги предоставляемые агентством.	Менеджер	Регистрация факта оплаты.
5	После заключения договора, менеджер, а так же руководство агентства обязаны контролировать процесс создания и размещения рекламных материалов клиента, а так же оплату последним суммы, указанной в договоре.	Менеджер, Руководство.	Осуществить текущий контроль за договорами. Проверить факт оплаты. Проверить процесс создания материалов. Проверить процесс размещения материалов.
6	Каждый из пользователей системы должен пройти авторизацию для входа в систему и получения необходимых данных для него.	Менеджер, Руководство, Администратор.	Авторизоваться
7	Список рекламных площадей составляется руководством агентства.	Руководство	Составить список рекламных площадей
8	Список клиентов, с которыми необходимо работать менеджерам определяется руководством агентства. При этом руководство назначает каждому менеджеру определенных клиентов.	Руководство	Назначить клиента менеджеру
9	Руководство агентства предоставляет данные о рекламных площадях. Администратор вносит в систему всю необходимую информацию о площадях.	Администратор	Внести данные о рекламных площадях в систему.
10	Информация о клиентах и их реквизиты вводятся в систему администратором.	Администратор	Внести первоначальные сведения о клиенте.
11	Для того чтобы менеджер точно знал, с какими клиентами ему необходимо работать администратор должен внести данные в систему о сопоставленных клиентах для каждого менеджера.	Администратор	Внести в список, клиентов сопоставленных менеджеру
12	Администратор системы осуществляет ее безопасность. Для этого он назначает всем пользователям системы имена и пароли. С помощью имени и пароля каждый менеджер имеет возможность работы только с теми клиентами, ответственность за которых он несет.	Администратор	Обеспечить безопасность системы.

На основе перечисленных требований для рассматриваемой модели, были выделены следующие виды деятельности:



Рис. 2. Варианты использования или прецеденты (use case)

2.2 Диаграмма прецедентов

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

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

Достоинства модели вариантов использования заключаются в том, что она:

· определяет пользователей и границы системы;

· определяет системный интерфейс;

· удобна для общения пользователей с разработчиками;

· используется для написания тестов;

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

· хорошо вписывается в любые методы проектирования (как объектно-ориентированные, так и структурные).

Варианты использования и субъекты, выделенные для данной модели, представлены в виде диаграммы прецедентов на рис. 3. Здесь отношение «include» (включается) это - отношение включения между двумя вариантами использования указывает, что некоторое заданное поведение для одного варианта использования включается в качестве составного компонента в последовательность поведения другого варианта использования. «Include» используется в том случае, когда один прецедент выполняется только в рамках другого прецедента и не может выполняться как самостоятельная единица. Такой способ позволяет произвести описание прецедента один раз, о затем указать, в каких еще прецедентах он используется. В нашем случае прецеденты Проверить факт оплаты, Проверить процесс размещения материалов и прецедент Проверить процесс создания материалов включается в прецедент Осуществить текущий контроль за договорами. А прецедент Подготовить договор включается в прецедент Заключить договор.

Рис. 3. Диаграмма прецедентов

2.3 Документирование прецедентов

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

Структура документа, описывающего прецеденты, состоит из следующих пунктов:

1. Краткое описание.

2. Участвующие субъекты.

3. Предусловия, необходимые для инициирования прецедента.

4. Детализированное описание потока событий, которое включает:

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

- альтернативные потоки для определения исключительных ситуаций.

5. Постусловия, определяющие состояние системы, по достижении которого прецедент завершается.

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

Таблица 2. Описательная спецификация прецедента Назначить клиента менеджеру

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

Таблица 3. Описательная спецификация прецедента Составить список рекламных площадей

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

Таблица 4. Описательная спецификация прецедента Обеспечить безопасность системы

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

Таблица 5. Описательная спецификация прецедента Внести первоначальные сведения о клиенте

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

Таблица 6. Описательная спецификация прецедента Внести в систему клиентов сопоставленных менеджеру

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

Таблица 7. Описательная спецификация прецедента Внести данные о рекламных площадях в систему

Краткое описание	Данный прецедент описывает процедура ввода администратором информации, сформированной руководством, о рекламной площади в систему.
Субъекты	Администратор
Предусловия	Наличие данных о рекламных площадях
Основной поток событий	Администратор получает список рекламных площадей от руководства и вносит их в систему. В системе будут указаны все необходимые данные о площадях: тип и размещение.
Альтернативные потоки	Отсутствуют
Постусловия	Если прецедент был успешным, информация о рекламной площади сохраняется в системе. В противном случае состояние системы остается неизменным.

Таблица 8. Описательная спецификация прецедента Зарегистрировать событие

Краткое описание	В процессе работы с клиентом, менеджер постоянно вносит информацию о действиях, совершенных по отношению к этому клиенту, в систему. При этом он регистрирует в системе событие. Данное действие осуществляется для дальнейшего накопления статистики о всех событиях совершенных менеджером в отношении каждого клиента. Любое событие фиксируется с указанием даты и времени его совершения, а также результатов.
Субъекты	Менеджер
Предусловия	Обращение к системе. Запрос списка действий совершенных по отношению к данному клиенту.
Основной поток событий	При начале очередного действия (звонок, посещение клиента, заключение договора и т.д.) менеджер вносит информацию о клиенте в систему. Так же существует возможность повторного ввода событий в систему по отношению к данному клиенту, то есть происходит постоянное добавление событий в отношении каждого клиента. При регистрации события фиксируется время и дата его совершения, а также результаты.
Альтернативные потоки	Отсутствуют
Постусловия	Результаты и все действия совершенные в отношении клиента запоминаются в системе, то есть накапливается статистика о всех событиях.

Таблица 9. Описательная спецификация прецедента Составить список свободных рекламных площадей

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

Таблица 10. Описательная спецификация прецедента Зарегистрировать факт оплаты

Краткое описание	Данный прецедент дает возможность зарегистрировать факт оплаты. То есть зарегистрировать в системе денежную сумму, которую внес клиент за предоставленные услуги агентством.
Субъекты	Менеджер
Предусловия	Клиент оплачивает сумму, указанную в договоре, либо некоторую ее часть.
Основной поток событий	Формируется платеж на данную сумму, обновляется сумма в договоре для определения дальнейшей суммы которую необходимо оплатить клиенту по договору. Распечатывается квитанция, и в системе регистрируется факт оплаты.
Альтернативные потоки	Если оплачена не вся сумма, то формируется отчет об оставшейся сумме.
Постусловия	Данные об оплате сохраняются в системе.

Таблица 11. Описательная спецификация прецедента Осуществить текущий контроль за договорами

Краткое описание	Благодаря наличию данного прецедента у руководства агентства и у менеджера имеется возможность контролировать условия договоров, то есть осуществлять проверку выполнения работ и оплаты по определенным договорам. При этом в системе должны быть предусмотрены режимы показа договоров, по которым не были соблюдены все условия (оплата, создание, размещение материалов).
Субъекты	Менеджер, Руководство
Предусловия	Начало прецедента совпадает с необходимостью подготовки и проверки первоначальных условий договора. Затем производится выборка необходимого договора в котором должна быть произведена проверка.
Основной поток событий	При проверке договора последовательно проверяется соблюдение всех условий (оплата, создание, размещение материалов).
Альтернативные потоки	Если какое-либо из условий не соблюдено, создается отчет.
Постусловия	Системой создаются отчеты по всем договорам, по которым не выполнены какие-либо из условий

Таблица 12. Описательная спецификация прецедента Проверить факт оплаты

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

Таблица 13. Описательная спецификация прецедента Проверить процесс создания материалов

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

Таблица 14. Описательная спецификация прецедента Проверить процесс размещения материалов

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

Таблица 15. Описательная спецификация прецедента Подготовить договор

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

Таблица 16. Описательная спецификация прецедента Заключить договор

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

Таблица 17. Описательная спецификация прецедента Авторизоваться

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

3. Выявление классов-сущностей

Классы-сущности определяют существо любой информационной системы. Это классы, которые определяют модель базы данных для прикладной области. Классы-сущности представляют постоянно хранимые объекты базы данных. Анализ требований направлен преимущественно на выявление классов-сущностей. Однако, для функционирования системы требуются также классы другого типа. Пользователям системы необходимы классы, которые определяют GUI-объекты (например, такие как экранные формы), называемые пограничными классами (boundary classes) (классами представления (view classes)). Чтобы функционировать надлежащим образом, системе также необходимы классы, которые управляют программной логикой - управляющие классы (control classes).

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

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

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

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

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

Выделенный класс менеджер содержит в себе следующие атрибуты: Наименование - Фамилия Имя Отчество менеджера; Телефон - номер телефона менеджера; Пароль - имя и пароль менеджера. Каждый менеджер должен иметь имя и пароль для входа в систему.

Класс «Менеджер» непосредственно будет связан с классом «Клиент» связью «один ко многим», так как один менеджер может работать со множеством клиентов.

Так же необходимо выделить класс «Список клиентов», который формируется на основе класса «Клиент». Класс «Список клиентов» будет содержать один атрибут Клиент, тип которого так же является классом «Клиент». В класс «Список клиентов» будет включаться вся информация, которая содержится в классе «Клиент». Класс «Клиент» и «Список клиентов» связаны так называемой связью агрегация. Агрегация - это отношение вида часть - целое между классом, который представляет собрание компонент, и классами, представляющими компоненты. В нашем случае используется агрегация по ссылке, которая называется просто агрегацией. Используется связь «один ко многим», так как список клиентов может содержать в себе одного или множество клиентов. Класс «Список клиентов» включает в себя операцию «Выборка». Благодаря которой из списка клиентов будут выбираться клиенты для каждого определенного менеджера.

Считаем также, что в системе должны присутствовать такие классы как «Рекламная площадь» и «Рекламная услуга», которые связаны между собой отношением «один ко многим», то есть на одной рекламной площади может размещаться одна или несколько рекламных услуг. Класс «Рекламная площадь» содержит в себе следующие атрибуты: Тип - то место, где будет располагаться реклама; Место расположения - адрес места расположения выбранной рекламной услуги; Дата начала размещения услуги; Дата завершения размещения услуги; Статус - площадь может быть “свободна” или “занята” в определенный период времени; Клиент - то есть тот клиент, за которым будет закреплена данная площадь. Атрибут Клиент имеет тип «Клиент». Класс включает в себя операцию Проверка срока. Благодаря этой операции в системе будет проверяться срок размещения рекламной услуги на определенной площади для установления статуса площади. Класс «Рекламная площадь» так же связана с классом «Клиент» отношением «многие к одному». Это значит, что одна или множество площадей могут быть заняты, одновременно, рекламой для одного клиента.

Класс «Рекламная услуга» включает в себя следующие атрибуты: Тип - вид рекламной услуги (реклама в Интернете, щитовая реклама, реклама в печатных изданиях и на CD дисках, а так же дизайн рекламных материалов); Рекламная площадь - та площадь, где в данное время будет находиться определенный вид рекламы, тип данного атрибута является классом «Рекламная площадь».

Каждый менеджер в процессе работы совершает определенный набор действий по отношению к клиенту, с которым он работает. Эти действия обязательно должны быть зарегистрированы. Поэтому необходимо так же в диаграмму классов включить такой класс как «Событие». Который будет содержать следующие атрибуты: Тип - вид события (звонок, посещение клиента); Клиент - клиент по отношению к которому будет совершаться событие; Дата - дата и время совершения события; Результаты - результат всех действий проведенных менеджером в отношении клиента (заключение договора, отказ клиента от договора). Класс «Событие» связан с классом «Клиент» отношением «многие к одному». Одно или множество событий может быть совершено по отношению к одному клиенту.

В качестве классов-сущностей считаем целесообразным выделить: «Платеж за услугу» и «Договор с клиентом».

Атрибуты класса «Платеж за услугу»: Договор - договор, к которому прикрепляется платеж, тип этого атрибута является классом, с которым связан платеж, то есть класс «Договор с клиентом»; Сумма - сумма, которую должен оплатить клиент за услугу в настоящее время; Дата - дата совершения платежа. Атрибуты класса «Договор с клиентом»: Номер договора; Клиент - клиент с которым заключается договор; Дата - дата заключения договора; Условия договора; Список услуг - услуги, которые выбрал клиент; Список площадей - площади, на которых будет располагаться реклама клиента; Срок выполнения услуги; Общая сумма - вся стоимость выполненных услуг; Внесенная сумма - сумма которую внес клиент за услуги на определенный момент времени. Клиент может внести всю сумму сразу, а может вносить ее по частям. Класс «Договор с клиентом» имеет связи с большей частью выделенных классов- сущностей. «Договор с клиентом» связан с классом «Платеж за услугу» и имеет кратность ассоциации «один ко многим». По одному договору может формироваться один платеж, если вся сумма указанная в договоре внесена сразу, или несколько раз если сумма вносится клиентом по частям. Так же данный класс связан с классами «Рекламная площадь» и «Рекламная услуга» кратностью ассоциаций «многие ко многим». Так же класс «Договор с клиентом» связан с классом «Менеджер» отношением «многие к одному». Один менеджер может оформить несколько договоров, либо вообще не оформлять договор в случае, если клиент отказался от заключения договора с агентством.

Представим все описанные классы-сущности и связи между ними, в виде диаграммы классов:



Рис. 4. Диаграмма классов-сущностей

4. Моделирование видов деятельности

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

Модель видов деятельности (activity model) может представлять в графической форме поток событий для прецедента. Этот тип модели был введен только в более поздние версии UML и позволил преодолеть разрыв между высокоуровневым представлением поведения системы с помощью моделей прецедентов и намного более низким уровнем представления поведения с помощью моделей взаимодействий (диаграмм последовательностей и диаграмм кооперации).

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

Диаграмма видов деятельности показывает шаги вычисления. Каждый шаг соответствует состоянию (state), в котором что-либо выполняется. Поэтому шаги выполнения называются состояниями вида деятельности. Диаграмма описывает, какие шаги выполняются последовательно, а какие - параллельно. Передача управления от одного состояния вида деятельности к другому называется переходом (transition).

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

Модели видов деятельности могут быть особенно полезны для определения потоков видов деятельности в процессе выполнения прецедентов.

Диаграмма видов деятельности строится для каждого варианта использования. Построим диаграмму деятельности для нашей системы.

Диаграмма видов деятельности для прецедента «Внести первоначальные сведения о клиенте» имеет следующий вид:

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

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

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

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

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

Следующая диаграмма видов деятельности отражает прецедент «Зарегистрировать событие».

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

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

Следующая диаграмма видов деятельности представленная на рис. 8. отображает прецедент «Осуществить текущий контроль за договорами».



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

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

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



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

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

Прецедент «Проверить процесс размещения материалов» представлен в виде диаграммы видов деятельности на следующем рисунке 10.



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

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

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



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

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

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



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

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

Следующая диаграмма видов деятельности представлена для прецедента «Авторизоваться».



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

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

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



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

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

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



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

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

5. Моделирование взаимодействий

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

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

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

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

5.1 Диаграммы последовательности

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