Министерство образования Республики Беларусь

Белорусский государственный университет

информатики и радиоэлектроники

Кафедра информационных технологий автоматизированных систем

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА
к расчетной работе
по курсу “Объектно-ориентированное программирование и проектирование”
на тему “ Объектно-ориентированный анализ и проектирование
программного обеспечения. Программное обеспечение для управления
контактами с клиентами”

Выполнил студент гр. № 000000 _____________

(подпись)

Руководитель _____________
(подпись)

Минск 2010
 Содержание

Минск 2010Содержание................................................................................................................1
Содержание....................................................................................................................................2
Введение.........................................................................................................................................3
1. Постановка задачи.....................................................................................................................4
1.1. Цель разработки..................................................................................................................4
1.2. Постановка задачи заказчиком..........................................................................................4
1.3. Глоссарий проекта..............................................................................................................5
1.4. Анализ и определение требований...................................................................................6
2. Проектирование программного продукта...............................................................................8
2.1. Описание модели вариантов использования...................................................................8
2.1.1. Диаграмма вариантов использования............................................................................8
2.2. Описание модели анализа системы..................................................................................8
2.2.1. Диаграммы деятельности................................................................................................8
2.2.3. Диаграммы состояний...................................................................................................10
2.3. Описание модели реализации..........................................................................................10
2.3.1. Диаграмма компонентов...............................................................................................10
3. Процесс генерации программного кода............................................................................12
Заключение...................................................................................................................................13
Список литературы......................................................................................................................14
Приложения..................................................................................................................................15
Приложение 1. Диаграмма вариантов использования.........................................................15
Приложение 2. Диаграмма кооперации для прецедента «Создание задания»..................16
Приложение 3. Диаграмма последовательности для прецедента «Создание
задания(create task)»................................................................................................................16
Приложение 4. Диаграмма состояний системы....................................................................17
Приложение 5. Диаграмма классов........................................................................................18

2
Введение

Унифицированный язык моделирования UML (Unified Modeling

Language) – это преемник того поколения методов объектно-
ориентированного анализа и проектирования, которые появились в конце 80-
х и начале 90-х годов. Создание UML фактически началось в конце 1994
г., когда Гради Буч и Джеймс Рамбо начали работу по объединению их
методов Booch [Буч-1999] и OMT (Object Modeling Technique) под эгидой
компании Rational Software. К концу 1995 г. они создали первую
спецификацию объединенного метода, названного ими Unified
Method, версия 0.8. Тогда же в 1995 г. к ним присоединился
создатель метода OOSE (Object-Oriented Software Engineering) Ивар Якобсон.
Таким образом, UML является прямым объединением и унификацией
методов Буча, Рамбо и Якобсона, однако дополняет их новыми
возможностями.
UML находится в процессе стандартизации, проводимом
консорциумом OMG (Object Management Group), в настоящее время он
принят в качестве стандартного языка моделирования и получил широкую
поддержку. UML принят на вооружение практически всеми крупнейшими
компаниями – производителями программного обеспечения (Microsoft,
IBM, Hewlett-Packard, Oracle, Sybase и др.). Кроме того, практически все
мировые производители CASE-средств, помимо Rational Software (Rational
Rose), поддерживают UML в своих продуктах (Paradigm Plus (CA), System
Architect (Popkin Software), Microsoft Visual Modeler и др

3
1. Постановка задачи

1.1. Цель разработки

Цель расчетной работы – закрепление и углубление знаний,

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

1.2. Постановка задачи заказчиком

Вариант 6. Управление контактами с клиентами

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

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

1.3. Глоссарий проекта

1. Система – программная система для управления контактами с

клиентурой компании.
2. Сотрудник (автор) – человек, работающий с системой, создающие
события.
3. Сотрудник (исполнитель) – человек, работающий с системой,
выполняющий или следящий за исполнением события.
4. Менеджер – человек, работающий с системой , а также следящий за
выполнением событий.

5
1.4. Анализ и определение требований

Система состоит из сотрудников, менеджеров, которые создают

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

Поля таблицы «Task»:

1. description
2. datacreate
3. value

Поля таблицы «Event»:

1. description
2. create_dt
3. due_dt
4. completed_dt
5. priority

Поля таблицы «Employee»:

1. «pk» emp_id
2. surname
3. name

Поля таблицы «Contant»:

1. «pk» contact_id
2. surname
3. name
4. phone
5. fax
6. email

Поля таблицы «Org»:

1. «pk» org_id
2. org_name
3. phone
4. fax
5. email
6. current

Поля таблицы «Postal address»:

1. street
2. po_box
3. city
4. post_code
5. country
6
 Поля таблицы «Courier address»:
1. street
2. city
3. country

Целесообразно спроектировать базу данных со следующей структурой:

Необходимые функции системы:

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

7
2. Проектирование программного продукта

2.1. Описание модели вариантов использования

2.1.1. Диаграмма вариантов использования

Были выбраны следующие актеры и прецеденты.

Актёры:
Менеджер – человек, работающий с системой. Этот актер инициирует
все прецеденты.
Рядовой рабочий – человек, работающий с системой. Этот актер
инициирует следующие прецеденты.
Исполнитель – человек, работающий с системой. Этот актер выполняет
следующие прецеденты.

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

2.2. Описание модели анализа системы

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

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

этапе.

Вариант использования «Планирование »

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

1. Пользователь выбирает, какое действие выполнить.
1.1. Работа с заданиями
1.1.1. Добавить задание.
1.1.1.1. Система запрашивает данные о контакте.
1.1.1.2. Пользователь вводит данные об адресе.
1.1.1.3. Если имя введено, новая запись добавляется в базу.
1.1.2. Изменить исполнителя задания

8
 1.1.2.1. Исполнитель следит за выполнением задания.
1.1.2.2. Система запрашивает новые данные о задания и контакте.
1.1.2.3. Пользователь вводит данные о задании.
1.1.2.4. Система проверяет, о ходе задания.
1.1.3. Удалить задание.
1.1.3.1. Пользователь выбирает задание из списка.
1.1.3.2. Система проверяет, дату окончание задание.
1.1.3.3. Если после даты окончания прошло больше 12 месяцов,
задание удаляется из базы.
1.2. Работа с мероприятиями.
1.2.1. Добавить связь.
1.2.1.1. Система проверяет, имеется ли хотя бы 2 записи в
таблице персон.
1.2.1.2. Если имеется, пользователь выбирает участников и тип
связи.
1.2.1.3. Система проверяет, возможна ли связь между
выбранными персонами.
1.2.1.4. Если возможна, в базу добавляется новая запись.
1.2.2. Удалить связь.
1.2.2.1. Пользователь выбирает нужную связь.
1.2.2.2. Из базы удаляется запись о связи.

Альтернативные потоки событий:

1. При удалении персоны выясняется, что удаляемая персона состоит в
связях.
1.1. Выводится сообщение об ошибке, и прецедент завершается.
2. При добавлении связи выясняется, что таблица персон содержит
менее двух записей.
2.1. Выводится сообщение об ошибке и прецедент завершается.

Предусловия.
1. Система должна находиться в состоянии «Ожидание действий от
пользователя».

Постусловия.
1. Система возвращается в состояние «Ожидание действий от
пользователя».

Вариант использования «Запрос к базе»

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

1. Пользователь выбирает, какой запрос выполнить.
1.1. Исходными данными для запроса служит одна персона.
1.1.1. Пользователь выбирает нужный запрос в контексном меню
9
 для нужной персоны.
1.2. Исходными данными для запроса служит 2 персоны.
1.2.1. Пользователь выбирает нужных персон из списка.
2. Система выполняет поиск в базе по запросу.
3. Система отображает результат запроса.

Предусловия.
1. Система должна находиться в состоянии «Ожидание действий от
пользователя».

Постусловия.
1. Система возвращается в состояние «Ожидание действий от
пользователя».

2.2.3. Диаграммы состояний

Система может находиться в следующих состояниях:

1. Ожидание действий от пользователя.
2. Ввод данных о новом задании.
3. Изменение данных о задании.
4. Ввод данных о задании.
5. Изменение исполнителя.
6. Выполнение задании.

Поскольку выполнение запросов и поиск информации в базе системой

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

2.3. Описание модели реализации

2.3.1. Диаграмма компонентов

На диаграмме компонентов представлены компоненты данного

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

Компонент Описанный класс

Task.h/cpp CTask
10
Relationship.h/cpp CRelationship
ContactDoc.h/cpp CContactDoc
ContactView.h/cpp CContactView
MFC Библиотека MFC, подключенная к проекту

11
3. Процесс генерации программного кода

Была выполнена генерация кода программы с помощью IBM Rational

Software Architect по инструкции по кодогенерации UML модели в C++.
В результате были получены *.h и *.cpp файлы для следующих классов из
модели проектирования: CTask, CRelationship, CContactDoc, CContactView.

12
Заключение

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

Rational Software Architect, ставшая основой для написания программы в
среде Microsoft Visual Studio 2008 на языке C++.
Проект не отвечает признаку успешного проекта «написан в срок».
Конечная система реализует все заданные заказчиком требования.
Реализованная программа может иметь практическое применение для
составления семейных или иных не слишком сложных генеалогических
деревьев.
Дальнейшее развитие системы может включать в себя расширение
сроков существования рода (существующее ограничение – 14.09.1752 –
31.12.9999), более строгую проверку непротиворечивости создаваемых
связей, улучшение алгоритмов поиска информации в базе данных,
добавление графической визуализации деревьев.

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

1. Вендров А.М., Малышко В.В. Объектно-ориентированный анализ и

проектирование с использованием языка UML. М.: Издательский отдел
факультета ВМиК МГУ, 2002
2. Леоненков А.В. Самоучитель UML 2. БХВ-Петербург, 2007 г.

14
Приложения

Приложение 1. Диаграмма вариантов использования.

Employer Customer Plan Event

employer

<<include>>
Maintain organization
Customer
Manager
<<extend>>

<<extend>> Create task

Maintain contact Complete event

15
Приложение 2. Диаграмма кооперации для прецедента «Создание
задания»

3: create task for cohtact()

2: get schudule(task,create_dt,desctiprion ) : Contact
1: create task( )
: Org : Employment 4: give task(contact, task)

: Customer : Task
Manager

6: check and searh for doing task

: Event

5: get address(customer)

: Courier
Address

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

«Создание задания(create task)»

: Org : Task : Contact : Courier : Employment : Event

: Customer
Address
Manager
1://create task( )

plan task

2:// get schudule(task,create_dt,desctiprion )

3://create task for cohtact()

Create task for

custimer fir doing ...
4://give task(contact, task)

5://get address(customer)

6://check and searh for doing task

7://finish task()

Message to manager about

sucssessfull finisned task

16
Приложение 4. Диаграмма состояний системы
Startstate

Waiting

do/ Waiting event from employee

...

Get event( true )

Get event( false )

Get event

event Getcontact( contct_id )[ true ]/ Savecont()

...

[ cost=value, created_dt=date, emlp ]

Waiting actions Getorg() Give

Datacreate()
employee

Savedtcreate()
Insert data
create
Savecost()

Insert cost
Getcost()

17
Приложение 5. Диаграмма классов.

Postal Adress Courier Address

street : String direction : String
po_box : String city : String
city : String country : String
post_code : String
country : String 0..1 0..1 1..*

0..1

1..*
0..1
Org Contact
<<pk>> org_id : Integer 0..1 0..1 <<pk>> concact_id : Integer
org_name : String surname : String
phone : String name : String
fax : String phone : String
1 org_con *
email : String Task fax : String
current : Boolean email : String
description : String
1 created_dt : Date
value : Currency
0..* 0..*
Getevent()
Datacreate()
Getcost()
Getcontact()
1 Getorg()
Savedtcreate() 0..*
Savecost()
Sendtask2emlp()
1..*
1
Event
created 1 Employment
description : String 0..*
created_dt : Date <<pk>> emploeee_id : String
0..* 1
due_dt : Date name : String
due
completed_dt : Date surname : String
priority : Byte 0..* 0..1
completed

18