Объектно-ориентированное проектирование Информационная система предприятия связи
Подождите немного. Документ загружается.
СФИС-2003-2
Кассир
Абонент
Заявление на установку
телефона
Оператор
Специалист
Оператор кросса
Паспортист
Директор
Оплата за услуги связи
Регистрация заявления
Заключение договора
на услуги связи
Подключение абонента
Проверка технич возможн. на
установку телефона
Формирование финансового
состояния
Проверка пользователя
Системный
администратор
Система
<<include>>
Администрирование
системы
Восстановление сбоев
системы
Рисунок 3 - Дополнительная диаграмма прецедентов
2.3 Диаграмма деятельности
На каком либо этапе жизненного цикла могут быть построены диаграммы
деятельности (activity diagrams). Они отражают динамику проекта и
представляют собой схемы потоков управления в системе от действия к
действию, а также параллельные действия и альтернативные потоки.
В конкретной точке жизненного цикла диаграммы деятельности могут
представлять потоки между функциями или внутри отдельной функции. На
разных этапах жизненного цикла они создаются для отражения
последовательности выполнения операции.
Диаграмма деятельности прецедента «Прием оплаты за услуги связи»
показана на Рисунке 4.
11
СФИС-2003-2
Начало
Сообцает свой
номер телефона
Гасит
задолженность
Получает
сдачу и чек
Конец
Вводит номер
телефона в систему
Информирует
абонента о долге
Вводит оплату в
систему
Выдает
сдачу и чек
Сообщает сумму
долга абонента
Регистрирует оплату
Вычисляет сдачу
Печать
чека
Печать отчета
о звонках
Отправка факта оплаты
на внешний сервер
да
неправильно введен номер
нет
да
Напечатать только чек
нет
СистемаКассирАбонент
Рисунок 4 - Диаграмма деятельности
12
СФИС-2003-2
3. Логическое представление
В соответствии с предметной областью Саровского цеха связи можно
выделить следующие сущности: Абонент (сведения об абонентах), Сотрудники
(работники цеха связи), Тариф, Отчёт, Договор, Тех.справка, Заявка.
Каждая сущность должна обладать некоторыми свойствами: иметь
уникальное имя (к одному и тому же имени должна применяться одна и та же
интерпретация), обладать одним или несколькими атрибутами, которые
принадлежат сущности, обладать одним или несколькими атрибутами, которые
однозначно идентифицируют каждый экземпляр сущности.
Например, при оплате Абонентом за услуги связи Кассиру необходимо
учитывать следующие параметры Абонента: телефонный номер абонента,
фамилия, имя, отчество, номер лицевого счёта абонента.
Последним шагом моделирования является идентификация атрибутов.
Атрибут (Рисунок 6) - любая характеристика сущности, значимая для
рассматриваемой предметной области и предназначенная для квалификации,
идентификации, классификации, количественной характеристики или
выражения состояния сущности. Атрибут представляет тип характеристик или
свойств, ассоциированных множеством реальных или абстрактных объектов
(людей, мест, событий, состояний, идеи и т.д.)
Уникальный идентификатор - это атрибут или совокупность атрибутов и
(или) связей, предназначенных для уникальной идентификации каждого
экземпляра данного типа сущности.
Рисунок 5 - Документация класса "Abonent"
13
СФИС-2003-2
Рисунок 6 - Атрибуты класса "Abonent"
Рисунок 7 - Методы класса "Abonent"
Далее определяются атрибуты и уникальные идентификаторы для других
классов-сущностей.
14
СФИС-2003-2
3.1 Диаграмма пакетов классов
Если в системе существует немного классов, управлять ими достаточно
легко. Многие системы состоят из большого количества классов, поэтому
необходим механизм, позволяющий разбить их на группы и облегчающий
управление и повторное использование.
Здесь оказывается полезной концепция пакетов.
Пакет (package) в логическом представлении модели - это набор классов и
других связанных пакетов. Путем объединения классов в пакеты мы можем по-
лучить представление модели на более высоком уровне. Изучая содержимое па-
кета, мы, наоборот, получаем более детальное представление.
Каждый пакет содержит интерфейс, реализуемый набором его
общедоступных классов (public classes), то есть тех, с которыми могут общаться
классы из других пакетов. Остальные классы пакета - это классы реализации
(implementation classes), которые не взаимодействуют с классами в других
пакетах.
Интерфейсы
Отчеты Списки Пользователи Кассиры Абоненты
Базовые
средсва
global
Базы данных Обработчик
ошибок
global
Рисунок 8 - Диаграмма пакетов классов
15
СФИС-2003-2
3.2 Диаграмма классов
В разрабатываемой системе проектируется несколько классов-сущностей,
которые используются для моделирования данных и поведения с длинным
жизненным циклом. Диаграмма классов и отношений между ними
представлена на Рисунке 9.
Абонент
L_sh : Integer
N_tel : Integer
Fam : String
lmj : String
Oth : Integer
Gorod : String
Uli : String
Dom : Integer
Korpus : Integer
Заявление на установку
телеф она
Кас сир
Оператор
Специалист
Оператор кросса
Паспортис т
Директор
Оплата за услуги связи
Регистрация заявления
Заключение договора
на услуги связи
Подключение абонента
Проверка технич возможн. на
установку телефона
Формирование финанс ового
сос тояния
Проверка пользователя
Системный
админис тратор
Система
<<include>>
Админис трирование
сис темы
Вос становление сбоев
сис темы
Рисунок 9 - Диаграмма классов
16
СФИС-2003-2
3.3 Диаграмма реализации для прецедентов
Диаграмма прецедентов представляет внешний вид системы. Выполнение
прецедентов отображается с помощью потока событий.
По методологии Rational Unified Process реализации прецедентов (use case
realizations) отражаются в логическом представлении модели Другими словами,
прецеденты в логическом представлении имеют те же имена, что и в
представлении use case, а также стереотип, указывающий на реализацию. В
языке UML реализация прецедентов изображается в виде пунктирного овала.
Логическое представление прецедентов обычно отображается на диаграмме
прецедентов (или наборе диаграмм) содержащейся в логическом представлении
модели.
Диаграмма реализации прецедентов разрабатываемой системы показана
на Рисунке 10.
Подключение_Абонента Заключение_договора на усл.
связи
Формирование_финансового
состояния
Администрирование системы Заявление_на установку
телефона
Восстановление_сбоев системы
Проверка_тех возм на установку
телефона
Проверка_пользователя
Регистрация_заявления абонента
Оплата_за услуги связи
Оплата за услуги связи
(f rom Use Case View)
<<realize>>
Рисунок 10 - Диаграмма реализации для прецедентов
17
СФИС-2003-2
3.4 Диаграмма последовательности
Диаграмма последовательности (sequence diagram) отображает
взаимодействие объектов, упорядоченное по времени. На ней показаны
объекты и классы, используемые в сценарии и последовательность сообщений,
которыми обмениваются объекты, для выполнения сценария. Диаграммы
последовательности обычно соответствуют реализациям прецедентов в
логическом представлении системы.
Каждый объект также имеет свою временную линию (timeline),
изображаемую пунктиром под объектом. Сообщения, передаваемые между
объектами, указываются стрелками, направленными от отправителя сообщения
к получателю сообщения.
На Рисунке 11 показана диаграмма последовательности “Оплата за услуги
связи” опишем кратко её: абонент сообщает свой номер телефона Кассиру,
кассир вводит № Абонент в систему, система проверяет правильность
введённого №, система сообщает Кассиру стоимость долга Абонента, Кассир
сообщает стоимость долга Абонента, кассир передаёт Абоненту кассовый чек и
сдачу.
: Абонент
: Кассир
: Управляющая
программа
Сообщает номер телефона
Ввести телефон (номер)
Проверить (номер)
Сообщает долг
Сообщает долг
Оплачивает долг
Регистрация оплаты
Подтвердить оплату
Вывод чека
Передает чек и сдачу
Рисунок 11 - Диаграмма последовательности действий
18
СФИС-2003-2
3.5 Диаграмма кооперации (взаимодействия).
Диаграмма взаимодействия - это альтернативный способ отображения
сценариев. Этот тип диаграммы показывает взаимодействие объектов
организованное вокруг самих объектов, и их связи друг с другом. Такой тип
диаграммы показывает взаимодействие объектов, организованное вокруг них, и
их связи друг с другом.
Преимущества диаграммы кооперации: легче увидеть, какие объекты
взаимодействуют между собой, проще показать альтернативные потоки,
наглядно показано взаимодействие большого числа объектов, удобно
отобразить дополнительную информацию, например конкретные
взаимодействующие объекты.
При всех своих преимуществах, диаграмма кооперации хуже отображает
последовательность действий. На Рисунке 12 показана диаграмма кооперации
для сценария “Оплата за услуги связи”.
: Абонент
: Кассир
: Управляющая
программа
1: Сообщает номер телефона
2: Ввести телефон (номер)
3: Проверить (номер)
4: Сообщает долг
5: Сообщает долг
6: Оплачивает долг
7: Регистрация оплаты
8: Подтвердить оплату
9: Вывод чека
10: Передает чек и сдачу
Рисунок 12 - Диаграмма кооперации (взаимодействия)
19
СФИС-2003-2
3.6 Диаграмма состояний
Классы, характеризующиеся выраженным динамическим поведением,
анализируются с помощью диаграмм состояний. На таких диаграммах
отображаются все состояния объекта, поступающие к объекту события и
результирующие действия. Считается, что переходы между состояниями и
сопровождающие их действия выполняются за нулевое время и не могут быть
прерваны. Пребывание объекта в определенном состоянии и сопутствующая
деятельность могут быть прерваны.
На Рисунке 13 показана диаграмма состояний для объекта Абонент.
В начальном состоянии происходит инициализация данных по №
Абонента, счетчик количества заявок устанавливается в ноль. По окончании
инициализации объект переходит в состояние определения № Абонента:
Если платёж Абонента уже был произведён, система перейдёт в конечное
состояние, если при вводе платежа произошла ошибка, система перейдет в
«Отмену», если платёж введён правильно система перейдёт в конечное
состояние.
Начальное состояние
Инициализация номера абонента
do/ Инициализировать номер абонента
Ввод оплаты
entry/ Регистрация платежа
Оплата произведена
do/ Долга нет
Отмена
Конечное состояние
Ввод оплаты
Оплачено
Рисунок 13 - Диаграмма состояний
20