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

[Введите текст]

Федеральное государственное бюджетное образовательное учреждение высшего образования «Югорский государственный университет»

Институт (НОЦ) технических систем и информационных технологий

Кафедра систем обработки информации, моделирования и управления

КУРСОВОЙ ПРОЕКТ

по дисциплине «Проектирование программного обеспечения»

на тему «Автоматизированная система контроля финансового аспекта операционной деятельности телекомпании»

Выполнила: студентка группы 1552б

/Киселева А.Д./

Руководитель проекта: д.т.н., профессор

Кутышкин А.В./

Ханты-Мансийск 2018



1. Анализ требований к программному обеспечению

1.1 Анализ задания на курсовое проектирование и разработка технического задания на проектирование

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

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

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

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

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

Техническое задание на проектирование и разработку программного обеспечения отслеживания финансового аспекта операционной деятельности телекомпании приведено в Приложении 1.

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

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

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

Данная диаграмма позволяет:

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

2. Сформулировать общие требования к функциональному поведению проектируемой системы.

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

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

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

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

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

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

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

Рассматривая описание предметной области, были выделены следующие прецеденты:

· Заказ рекламы - этот прецедент запускается клиентом для того, чтобы оформить заказ на рекламу в телевизионной компании

o Изменение рекламного времени - является расширением прецедента выбора рекламного времени. Клиент может изменить условия своего уже выбранного заказа

· Выбор рекламного времени - прецедент выбора подходящего рекламного времени на основе данных, собраны от клиента

· Опрос клиента - этот прецедент запускается сотрудником, чтобы собрать стандартные данные о клиенте и данные о предпочтительных условиях рекламы (длительность, время)

· Составление документа продажи рекламного времени - прецедент продажи рекламного времени клиенту и составление соответствующего документа

o Проверка данных о клиенте- включение для прецедента Составления документа продажи. Клиент проверяет данные заказа на корректность

o Составление отчетов о продаже рекламного времени - включение для прецедента Составления документа продажи. Прецедент составления отчета на основе документа продажи для учета финансовой стороны деятельности телекомпании

o Предоставление скидки - Прецедент расширения для Составления документа продажи. Скидка может назначаться сотрудником по определенным условиям и влиять на конечную цену

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

Рисунок-1.2.1

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

Для построенной диаграммы прецедентов были сформированы основной и альтернативный потоки, а также поток ошибок. Потоки событий представлены в Приложении 2

1.3 Разработка концептуальной модели предметной среды

Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования.

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

С этой точки зрения диаграмма классов является дальнейшим развитием концептуальной модели проектируемой системы.

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

На языке UML концептуальную модель удобно представлять в виде диаграммы классов. Операции (методы) в классах на этапе анализа отсутствуют.

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

В рамках курсового проекта рассматриваются классы, входящие в основной прецедент: «Составление отчетов. Данный прецедент является ключевым для проектируемого ПО, так как реализует целевые функции.

Взаимодействие объектов как эскиз диаграммы классов разрабатываемого ПО представлен на рисунке 1.3.1.

Рисунок- 1.3.1.



2. Проектирование программного обеспечения

2.1 Логическая модель проектируемого программного обеспечения

Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования.

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

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

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

Основными элементами нотации диаграмм классов являются следующие.

Объект - это некоторая сущность реального мира или концептуальная (абстрактная) сущность.

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

Состояние объекта - это одно из условий, в котором он может находиться.

Состояние обычно изменяется со временем и характеризуется набором свойств, которые называются атрибутами.

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

Поведение характеризуется операциями объекта.

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

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

В рамках прецедента имеется 3 граничных класса:

Показ - форма для ввода параметров показа рекламного ролика.

Реализует операции:

Сохранить данные о показе() - Сохраняет данные о показе рекламного ролика

Реализует атрибуты:

ID_Показа:Integer-уникальный идентификатор показа рекламного ролика

Название рекламного ролика- Наименование рекламного ролика для показа

Номер рекламного ролика- Номер рекламного ролика для показа

Дата начала показа- Дата, с которой начнется показ рекламного ролика в телеэфире

Дата завершения показа-Дата, с которой закончится показ рекламного ролика в телеэфире

Длительность рекламного ролика- Время (Минуты, секунды) которое займет показ рекламного ролика в телеэфире

Телепередача- Телепередача, во время которой будет производиться показ рекламного ролика

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

Реализует операции:

Открыть эфирное время() - открывает эфирную сетку

Вход в систему()-Авторизация сотрудника в системе

Содержит атрибуты:

Фамилия- Фамилия сотрудника телекомпании

Имя-Имя сотрудника телекомпании

Отчество-Отчество сотрудника телекомпании

Номер рекламного ролика-Номер рекламного ролика для ввода в системе

Логин-Логин для входа сотрудника в систему

Пароль-Пароль для входа сотрудника в систему

Оформление рекламного ролика-Оформление заказа

Квитанция-документ удостоверяющий принятие денег

ID_Квитанции-уникальный идентификатор квитанции

Наименование получателя-наименование получателя

Номер счета плательщика-номер счета заказчика

ФИО плательщика- ФИО заказчика

Реализует операции:

Отобразить форму квитанции()-Отображение формы квитанции

Сохранить квитанцию()-Сохранение

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

В рамках прецедента было выделено 3 сущности:

Клиент- пользователь системы, человек, заказывающий рекламный ролик в телекомпании.

Содержит атрибуты:

Фамилия-Фамилия клиента

Имя-Имя клиента

Отчество-Отчество клиента

Номер телефона-Номер телефона клиента

ID_Клиента- уникальный идентификатор клиента

Серия паспорта-Паспортные данные клиента

Номер паспорта-Паспортные данные клиента

Реализует операции:

Сохранить данные клиента()-сохранение

Рекламный ролик- видео ролик, показ которого заказывает клиент у телекомпании

Содержит атрибуты:

ID_Рекламного ролика-уникальный идентификатор рекламного ролика

Номер рекламного ролика- Номер рекламного ролика для показа

Номер договора- Номер договора в системе

Дата заключения договора-Дата, с которой начинается сотрудничество между телекомпанией и заказчиком

Дата начала показа- Дата, с которой начнется показ рекламного ролика в телеэфире

Длительность рекламного ролика- Время (Минуты, секунды) которое займет показ рекламного ролика в телеэфире

Телепередача- Телепередача, во время которой будет производиться показ рекламного ролика

Дата завершения показа- Дата, с которой закончится показ рекламного ролика в телеэфире

Реализует операции:

Сохранить данные о рекламном ролике()-сохранение

Заказ-предложение заказчика показать рекламный ролик в телеэфире

Содержит атрибуты:

ID_Заказа-Уникальный идентификатор заказа

Дата оформления заказа-Дата оформления заказа(показа рекламного ролика в телеэфире)

Оплачено-Сообщение об оплате

Номер рекламного ролика- Номер рекламного ролика для показа

Цена рекламного ролика-Итоговая сумма показа рекламного ролика в телеэфире

Открыть/закрыть рекламный ролик-Открыть/закрыть форму заказа рекламного ролика

Реализует операции:

Сохранить заказ()-сохранение

Договор-документ ,регистрирующий факт продажи рекламного ролика

Содержит атрибуты:

ID_Договора-Уникальный идентификатор договора

Серия паспорта-Паспортные данные клиента

Номер паспорта-Паспортные данные клиента

Имя сотрудника телекомпании-Имя сотрудника

Номер договора- Номер договора в системе

Дата заключения договора-Дата, с которой начинается сотрудничество между телекомпанией и заказчиком

Номер рекламного ролика- Номер рекламного ролика для показа

Оплачено-Сообщение об оплате

Сумма-Итоговая сумма показа рекламного ролика

Заключение/расторжение договора- Дата заключения и расторжения договора

Срок договора- Срок действие договора

Предоставление скидки-бонус

Реализует операции:

Отобразить форму договора()-Отображение формы договора

Сохранить договор()-Сохранение

Отчетность-отчет по продаже рекламного ролика в телеэфире

Содержит атрибуты:

Дата заключения договора-Дата, с которой начинается сотрудничество между телекомпанией и заказчиком

Номер договора- Номер договора в системе

Сумма платежа-Итоговая сумма продажи рекламного ролика

Номер рекламного ролика- Номер рекламного ролика для показа

ФИО клиента-ФИО заказчика

ФИО сотрудника-ФИО сотрудника телекомпании

Дата формирования отчета-Дата составления отчета

Реализует операции:

Отобразить форму отчета()- отображение формы отчета

Получить данные()-запрос данных

Сохранить отчет()-Сохранение

Сформировать отчет()-формирование отчета

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

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

Был выделен один управляющий класс - подтверждение данных

Содержит операции, обеспечивающие необходимое взаимодействие.

Подтвердить данные о рекламном ролике()-подтверждение данных

Подтвердить данные о показе()-подтверждение данных

Подтвердить данные о заказе()-подтверждение данных

Подтвердить данные клиента()-подтверждение данных

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

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

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

Рисунок-2.1.1

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

2.2 Моделирование поведения проектируемого программного обеспечения

2.2.1 Диаграмма деятельности

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

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

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

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

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

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

Синхронизация - Это способ показать, что две или более ветвей потока выполняются параллельно.

Деятельности, помещенные между двумя жирными линиями на диаграмме деятельности, исполняются синхронно, одновременно.

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

В данном случае описываем диаграмму деятельности для формирования отчета.

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

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

Рисунок-2.2.1

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

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

Основной элемент диаграмм взаимодействия - это объект.

Объектом описывают сущность содержащую в себе данные и поведение.

Существует два типа диаграмм взаимодействия - диаграммы последовательности (или последовательности действий) и диаграммы кооперации.

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

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

Сценарий - это экземпляр потока событий. В данной диаграмме использовался основной поток событий.

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

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

На диаграмме взаимодействия присутствуют следующие элементы:

1. Линия жизни объекта (object lifeline) - вертикальная пунктирная линия на диаграмме последовательности, которая представляет существование объекта в течение определенного периода времени.

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

Фокус управления изображается тонким прямоугольником, расположенным на линии жизни (рис. 1).

Рис. 1

3. Сообщение (message) -- спецификация передачи информации от одного элемента модели к другому с ожиданием выполнения определенных действий со стороны принимающего элемента (рис. 2).

Рис. 2

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

Диаграмма последовательности представлена в Приложение 3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цель самой кооперации состоит в том, чтобы специфицировать особенности реализации отдельных наиболее значимых операций в системе.

Кооперация определяет структуру поведения системы в терминах взаимодействия участников этой кооперации.

Кооперация может быть представлена на двух уровнях.

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

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

Объекты. Объект (object) является отдельным экземпляром класса, который создается на этапе выполнения программы. Он может иметь свое собственное имя и конкретные значения атрибутов.

Связи. Связь (link) является экземпляром или примером произвольной ассоциации.

Связь как элемент языка UML может иметь место между двумя и более объектами.

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

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

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

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

Сообщения. При построении диаграммы кооперации они имеют некоторые дополнительные семантические особенности.

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

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

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

2.2.4 Диаграмма состояний

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

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

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

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

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

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

Диаграмму состояний часто рассматривают в контексте конечного автомата. Тогда можем сказать, что диаграмма состояний (Statechart diagram) показывает автомат, фокусируя внимание на потоке управления от состояния к состоянию.

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

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

Для поиска состояний класса можно просматривать атрибуты этого класса. Хорошим индикатором состояний является такой атрибут класса как «статус».

Диаграмма состояний изображается в виде графа с вершинами и ребрами.

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

Под именем состояния могут размещаться действия (рис. 1).

Рис. 1

Кроме обычных состояний на диаграмме состояний могут размещаться псевдосостояния.

Псевдосостояние (pseudo-state) - вершина в конечном автомате, которая имеет форму состояния, но не обладает поведением.

Примерами псевдосостояний, которые определены в языке UML, являются начальное и конечное состояния.

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

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

Графически начальное состояние в языке UML обозначается в виде закрашенного кружка, из которого может только выходить стрелка-переход (рис. 2).

Рис. 2

Конечное состояние (final state) - разновидность псевдосостояния, обозначающее прекращение процесса изменения состояний конечного автомата (рис. 2).

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

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

Действие Действие (Action) - это одиночное вычисление, которое приводит к смене состояния или возврату значения.

В общем случае действие имеет следующий формат:

<метка действия / выражение действия>

Входное действие (entry action) - действие, которое выполняется в момент перехода в данное состояние.

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

Действие выхода (exit action) - действие, производимое при выходе из данного состояния.

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

Внутренняя деятельность (do activity) - выполнение объектом операций или процедур, которые требуют определенного времени.

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

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

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

При нормальном завершении внутренней деятельности генерируется соответствующее событие.

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

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

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

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

Срабатывание <перехода> (fire) - выполнение перехода из одного состояния в другое.

На диаграмме состояний переход изображается сплошной стрелкой.

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

<имя события>(<список параметров, разделенных запятыми>)[<сторожевое условие>]/<выражение действия>.

Событие (Event) - это то, что вызывает переход из одного состояния в другое. У события могут быть аргументы, которые записываются в скобках.

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

Условия записываются в квадратных скобках.

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

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

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

Была составлена диаграмма состояний для элемента «Отчет».

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

После его формирования возможны два варианта события с отчетом: сотрудник его сохраняет или нет. В таком случае отчет расформировывается.

Диаграмма состояний для элемента «Отчет» представлена на рисунке 2.2.4.1.

Рисунок 2.2.4.1 - Диаграмма состояний элемента «Отчетность»



3. Проектирование физической структуры программного обеспечения

3.1 Проектирование компоновки программного обеспечения

Диаграмма компонентов отражает общие зависимости между компонентами, рассматривая последние в качестве классификаторов.

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

Компонент предназначен для представления физической организации ассоциированных с ним элементов модели.

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

Компонентом может быть исполняемый код отдельного модуля, командные файлы или файлы, содержащие интерпретируемые скрипты.

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

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

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

Этот символ является базовым обозначением компонента в языке UML.

Рис. 1

а) для компонента уровня типов указывается имя типа.

б) для компонента уровня экземпляра - собственное имя компонента и имя типа.

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

Модуль (module) -- часть программной системы, требующая памяти для своего хранения и процессора для исполнения.

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

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

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

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

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

Если компонент представляется на уровне типа, то записывается только имя типа с заглавной буквы в форме:

<Имя типа>.

Если же компонент представляется на уровне экземпляра, то его имя записывается в форме:

<имя компонента: Имя типа>.

При этом вся строка имени подчеркивается.

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

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

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

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

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

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

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

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

Рис. 2.

Кроме того, интерфейс на диаграмме компонентов может быть изображен в виде прямоугольника класса со стереотипом << interface>> и секцией поддерживаемых операций (рис.2б). Как правило, этот вариант обозначения используется для представления внутренней структуры интерфейса.

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

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

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

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

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

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

Предоставляемый интерфейс выглядит как кружок, соединенный линией с компонентом («леденец на палочке») (рис.4).

Требуемый интерфейс - полукруг, так же соединенный с компонентом («гнездо») (рис.3).

Рис. 3

Второй способ - изображение интерфейса в его расширенной форме (возможно, с указанием его операций) (рис.4).

Компонент, который реализует интерфейс, соединяется с ним посредством полной связи реализации.

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

Рис.4

Реализация интерфейса в виде, представленном на рис. 4 в пакете StarUML не предусмотрена.

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

Порт. Порт (port) - это своеобразное «окно» в инкапсулированный компонент.

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

Один компонент может взаимодействовать с другим через определенный порт.

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

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

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

Инкапсуляция и независимость, обеспечиваемая портами, повышают степень заменяемости компонента.

Порт схематически представлен маленьким квадратом на боковой грани компонента - это отверстие в границе инкапсуляции

компонента.

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

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

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

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

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

Порты - это часть компонента.

Экземпляры портов создаются и уничтожаются вместе с экземпляром компонента, которому они принадлежат.

Порты также могут иметь множественность; это означает возможность существования нескольких экземпляров порта внутри экземпляра компонента.

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

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

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

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

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

В этом случае рисуют стрелку от компонента-клиента к импортируемому интерфейсу (рис. 5).

Рис. 5

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

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

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

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

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

Ниже приводится фрагмент зависимости подобного рода, когда исполнимый компонент Control .exe зависит от соответствующих классов (рис. 6).

Рис. 6.

В этом случае из диаграммы компонентов не следует, что классы реализованы данным компонентом.

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

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

Верхняя секция служит для записи имени компонента и, возможно, дополнительной информации, а нижняя секция - для указания реализуемых данным компонентом классов (рис. 7).

Рис. 7.

В случае, если компонент является экземпляром и реализует три отдельных объекта, он изображается в форме компонента уровня экземпляров (рис. 8).

Рис. 8.

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

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

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

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

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

Рассмотрим результаты проектирования физической структуры проектируемого ПО и взаимосвязи ее компонентов (элементов) с аппаратными средствами среды.

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

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

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

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

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

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

- Визуализации общей структуры исходного кода программной системы;

- Спецификации исполнимого варианта программной Системы;

- Обеспечения многократного использования отдельных фрагментов программного кода.

Далее были выделены следующие компоненты Системы:

- База Данных;

- Обращение к БД;

- Интерфейсы.

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

Рисунок-3.1.1



3.2 Проектирование размещения элементов программного обеспечения

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

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

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

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

3.3 Компоненты диаграммы размещения

...