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

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

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

Рис. 1 Графическое изображение узла на диаграмме размещения

В первом случае имя узла записывается в форме: <Имя типа узла > без подчеркивания и начинается с заглавной буквы. Во втором - имя узла -экземпляра записывается в виде: <имя узла ':' Имя типа узла >, а вся запись подчеркивается. Имя типа узла указывает на разновидность узлов, присутствующих в модели системы. Так, на представленном рисунке (рис. 1, а) узел с именем Видеокамера относится к общему типу и никак не конкретизируется. Второй узел (рис. 1, б) является узлом -экземпляром конкретной модели сканера.

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

Рис. 2. Графическое изображение узла-экземпляра с дополнительной информацией в форме помеченного значения

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

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

Рис. 3. Варианты графического изображения узлов-экземпляров с размещаемыми на них компонентами

В качестве дополнения к имени узла могут использоваться различные текстовые стереотипы, которые явно специфицируют назначение этого узла. Для этой цели были предложены следующие текстовые стереотипы: "processor" (процессор), "sensor" (датчик), "modem" (модем), "net" (сеть), "printer" (принтер) и другие, смысл которых понятен из контекста.

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

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

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

Рис. 4. Варианты изображения графических стереотипов узлов

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

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

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

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

На автоматизированном рабочем месте сотрудника с помощью браузера необходимо зайти на заранее настроенный адрес веб-сервиса.

Также на другом персональном компьютере под управлением операционной системы Windows Server находится веб-сервер IIS и база данных MSSQL. Взаимодействие клиента с веб-сервером осуществляется по протоколу HTTP.

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

Рисунок 3.2.1 - Диаграмма размещения



Заключение

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

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

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

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

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

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



Список литературы

1. Руководство UML проектирования [Электронный ресурс]. URL: staruml.sourceforge.net/docs/user-guide(ru)/user-guide.pdf

2. Маглинец Ю.А. Анализ требований к информационным системам [Электронный ресурс]. URL: http://ivan-shamaev.ru/wp-content/uploads/2013/06/Information-systems-analysis-and-requirements-analysis.pdf

3. Научно-образовательный портал CLAIM [Электронный ресурс]. URL: it-claim.ru/Education/Course/ISDevelopment/Lecture_3.pdf

4. Элементы графической нотации диаграммы вариантов использования [Электронный ресурс]. URL: www.intuit.ru/studies/courses/32/32/lecture/1004

5. Моделирование на UML. Ф.Новиков, Д.Иванов. [Электронный ресурс]. URL: http://book.uml3.ru/sec_1_7

6. Проектирование программного обеспечения информационной системы [Электронный ресурс]. URL: swsys.ru/index.php?page=article&id=341

7. Лекция 5: Элементы графической нотации диаграммы классов [Электронный ресурс]. URL: intuit.ru/studies/courses/32/32/lecture/1008

8. Лекция 3: Виды диаграмм UML [Электронный ресурс]. URL: intuit.ru/studies/courses/1007/229/lecture/5954

9. Элементы графической нотации диаграммы компонентов [Электронный ресурс]. URL: www.intuit.ru/studies/courses/32/32/lecture/1022

10. Диаграммы развертывания . [Электронный ресурс]. URL: intuit.ru/studies/courses/32/32/lecture/1024

11. Протокол PPTP [Электронный ресурс]. URL: intuit.ru/studies/courses/32/32/lecture/1024 https://ru.wikipedia.org/wiki/PPTP

12. Леоненков А. Самоучитель UML. СПб.: БХВ-Петербург, 2004 - 432 с.



Приложение 1

«СОГЛАСОВАНО»

Представитель заказчика

(Руководитель курсового проектирования)

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

Техническое задание на проектирование программного обеспечения «Мониторинг финансовой деятельности телевизионной компании по предоставлению рекламного времени клиентам»

1. Введение

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

2. Основание для разработки

2.1. Основанием для данной работы служит задание на курсовой проект

2.2. Наименование работы: «Мониторинг финансовой деятельности телевизионной компании по предоставлению рекламного времени клиентам».

2.3. Исполнители: Киселева А.Д.

2.4. Соисполнители: нет

3. Назначение разработки

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

4.Технические требования

4.1. Требования к структуре и функционированию системы.

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

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

4.2. Требования к функциональным характеристикам.

4.2.1. Состав выполняемых функций.

Разрабатываемое программное обеспечение должно обеспечивать:

- Фиксирование в базе данных стандартных данных о клиентах телевизионной компании;

- Демонстрация возможных вариантов эфирного времени;

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

- Составление документа (договора) по каждому факту продажи рекламного ролика;

- Формирование отчетов (документа о продаже рекламного ролика).

4.2.2. Организация входных и выходных данных.

Исходные данные в систему поступают в виде информации о клиентах. Стандартные данные для клиентов:

§ Фамилия (представителя организации)

§ Имя (представителя организации)

§ Отчество (представителя организации)

§ Банковские реквизиты

§ Телефон

§ Название организации

§ Реквизиты организации

В качестве данных рекламы указывается:

§ Время показа

§ Длительность

§ Тема

В документе (договор) по каждому факту продажи эфирного времени указываются:

§ Представитель организации

§ Выбранное эфирное время

§ Срок показа

§ Длительность рекламного ролика

§ Возможная скидка

§ Стоимость рекламного ролика, включая скидку (телекомпании).

§ Реквизиты организации

Выходные данные:

· Документ о продаже рекламного ролика

· Отчет о продаже рекламного ролика

Система формирует финансовый отчет за период времени, с указанием скидок.

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

4.3 Требования к надежности

Для обеспечения надежности необходимо:

· Проверять корректность получаемых данных от клиентов.

· Создавать резервные копии базы данных

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

· Обеспечивать защиту персональных данных клиентов

4.4 Условия эксплуатации и требования к составу и параметрам технических средств

Наличие компьютера, рекомендуемые технические характеристики:

· Наличие оперативной памяти 512MB и выше

· Процессор с 64х разрядной архитектурой

· Наличие сетевой карты.

4.5 Требования к информационной и программной совместимости

Программа должна работать на платформах Windows 7 и выше.

4.6 Требования к транспортировке и хранению

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

4.7 Специальные требования.

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

5. Требования к программной документации

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

6. Технико-экономические показатели

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

7. Порядок контроля и приемки

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

8. Календарный план работ

Название этапа	Сроки этапа	Контролируемые результаты завершения этапа
1. Изучение предметной области. Проектирование системы. Разработка предложений по реализации системы.		Предложения по работе системы. Акт сдачи-приёмки
2. Разработка программного обеспечения для отслеживания финансового аспекта деятельности телевизионной компании		Программное обеспечение для отслеживания финансовой стороны работы телевизионной компании.
3. Тестирование и отладка ПО Сдача курсового проекта		Готовое ПО Программная документация. Акт сдачи-приёма работ

Разработала студентка гр. 1552б ____________ /Киселева А.Д./



Приложение 2

Поток событий

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

Основной поток событий.

1. Поток начинается с авторизации сотрудника.

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

3. Сотрудник выбирает опцию оформления заказа.

4. Программное обеспечение открывает форму с регистрацией клиента.

А1. Клиент не зарегистрирован.

А2. Клиент зарегистрирован.

5. Сотрудник перепроверяет данные клиента и подтверждает их.

6. Программное обеспечение открывает форму ввода данных о клиенте.

7. Сотрудник заносит основные данные о клиенте в программное обеспечение.

8. Сотрудник узнаёт у клиента стандартные данные для рекламного ролика и заносит их в программное обеспечение.

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

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

11. Клиент просматривает варианты эфирного времени.

А3. Клиент выбирает эфирное время.

А4. Клиент продолжает просматривать эфирное время.

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

А5. Клиент подтверждает заказ.

А6. Клиент не подтверждает заказ.

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

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

А7. Оплата прошла успешно.

А8. Недостаточно наличных средств.

А9. Счет клиента не найден.

А10. Недостаточно денег на счете.

Е1. Платежная система недоступна.

15. Программное обеспечение составляет отчёт.

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

Альтернативные потоки.

А1. Клиент не зарегистрирован.

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

А2. Клиент зарегистрирован.

1. Поток переходит на восьмой этап основного потока.

А3. Клиент выбирает эфирное время .

1. Поток переходит на двенадцатый этап основного потока.

А4. Клиент продолжает просматривать эфирное время.

1. Поток остаётся на одиннадцатом этапе основного потока, пока не наступит альтернативный поток А3.

А5. Клиент подтверждает заказ.

1. Поток переходит на тринадцатый шаг основного потока.

А6. Клиент не подтверждает заказ.

1. Поток возвращается на одиннадцатый шаг основного потока.

А7. Оплата прошла успешно.

1. Поток переходит на пятнадцатый шаг основного потока.

А8. Недостаточно наличных средств.

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

2. Поток возвращается к шестнадцатому шагу основного потока.

А9. Счёт клиента не найден.

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

2. Поток возвращается к шестнадцатому шагу основного потока.

А10. Недостаточно денег на счете.

1. Программное обеспечение выводит сообщение о том, что на счете пользователя недостаточно средств для совершения операции.

2. Поток возвращается к шестнадцатому шагу основного потока.

Потоки ошибок.

Е1. Платежная система недоступна

1. Система выводит сообщение о недоступности платежной системы.

2. Поток возвращается к четырнадцатому шагу основного потока.



Приложение 3

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



Приложение 4

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

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

...