1vendrov_a_m_proektirovanie_programmnogo_obespecheniya_ekonom
.pdfАнализ и проектирование программного обеспечения |
333 |
4 . 4 . 2 . ПРОЕКТИРОВАНИЕ ЭЛЕМЕНТОВ СИСТЕМЫ
Проектирование элементов системы выполняется проекти ровщиками и включает в себя:
•уточнение описания вариантов использования;
•проектирование классов;
•проектирование баз данных.
Уточнение описания вариантов использования
Уточнение описания вариантов использования заключается в модификации их диаграмм взаимодействия и диаграмм классов с учетом вновь появившихся на шаге проектирования классов и подсистем, а также проектных механизмов. Так, например, диаг раммы взаимодействия варианта использования «Зарегистриро ваться на курсы», изображенные на рис. 4.7 и 4.8, примут вид, по казанный на рис. 4.29 и 4.30.
Объект класса CourseRegBDManager на рис. 4.29 играет роль интерфейса с объектной базой данных системы регистрации (предполагается, что данные о студентах, графиках и профессо рах будут храниться в объектной БД).
Проектирование классов
Проектирование классов включает следующие действия:
•детализация проектных классов;
•уточнение операций и атрибутов;
•моделирование состояний для классов;
•уточнение связей между классами.
Детализация проектных классов. Каждый фаничный класс преобразуется в некоторый набор классов, в зависимости от сво его назначения.. Это может быть набор элементов пользовательс кого интерфейса, зависящий от возможностей среды разработки, или набор классов, реализующий системный или аппаратный интерфейс.
Классы-сущности с учетом соображений производительнос ти и защиты данных могут разбиваться на ряд классов. Основани ем для разбиения является наличие в классе атрибутов с различ ной частотой использования или видимостью. Такие атрибуты, как правило, выделяются в отдельные классы.
334 |
Глава 4 |
ф Ratlcmaf ЙЙ^^|;::1Ш»ШШ1ИШЙШШ1ШШ |
|
^ет Format |
^nm$tt B,epoft ХоЫ$ ^t^Ihsf EHdcw*» |
1: // register for |
courses() |
|
: MainStudentForm |
|
2: open(string) |
3: isRegistrationOpenO displayAvaiLebleOperations()
>
: ReqisterForCoursesForm
4: open(string)
: Registration Controller
5: getStudent(string)
: CourseReqDBManaqer
JM
Рис. 4.29. Кооперативная диаграмма «Зарегистрироваться на курсы» • основной поток событий
Классы, реализующие простую передачу информации от гра ничных классов к сущностям, могут быть удалены. Сохраняются классы, выполняющие существенную работу по управлению по токами событий (управление транзакциями, распределенная об работка и т.д.).
Полученные в результате уточнения классы подлежат непос редственной реализации в коде системы.
Анализ и проектирование программного обеспечения |
335 |
||||
%- Rational RoS« •^;^Шi»?il«i-eaiШjйШ^4«Ш:^:tШШШШi^^ |
Щ Д ' - М ^ |
|
|||
щ EUt вМ: !№« fSfi«* |
. |
ШМЯ11 B>«tM i<Ki^ t^M |
щпкт |
М> -l<?l |
|
. _ . . |
™- |
. |
- - ^ 1 |
|
|
4:displayCour5eOfferings()
5:displayBlankScheduleO
>
;RggisterFprCourgesFofm
1:createSche^ldfel)
8:select 4 primary aiul 2 alterrjate()
2 j getCourseOfferings()
7: create schedule with offermgs(CourseOfferingList)
: Student |
: Registration Controller |
|
: getCourseOfferingsO .
: Student |
: ICourseCatalogSystem |
|
|
|
8: new(Semestef, CourseOfferingLlst) |
|
: Schedule |
Ш > .,i |
Jtffi |
Рис. 4.30. Кооперативная диаграмма «Зарегистрироваться на курсы» подчиненный поток «Создать график»
Уточнение операций и атрибутов. Обязанности классов, опре деленные в процессе анализа и документированные в виде опера ций «анализа», преобразуются в операции, которые будут реали зованы в коде. При этом:
•каждой операции присваивается краткое имя, характеризу ющее ее результат;
•определяется полная сигнатура операции (в соответствии с нотацией, принятой в языке UML;
336 |
Глава 4 |
•создается краткое описание операции, включая смысл всех
еепараметров;
•определяется видимость операции: public, private или pro tected;
•определяется область действия операции: экземпляр (опе рация объекта) или классификатор (операция класса);
•может быть составлено описание алгоритма выполнения операции (с использованием диафамм деятельности в виде блок-схем, а также диафамм взаимодействия различных объектов при выполнении операции).
Уточнение атрибутов классов заключается в следующем:
•кроме имени атрибута, задается его тип и значение по умол чанию (необязательное);
•учитываются соглашения по именованию атрибутов, при нятые в проекте и языке реализации;
•задается видимость атрибутов: public, private или protected;
•при необходимости определяются производные (вычисляе мые) атрибуты.
Пример уточнения операций и атрибутов приведен на рис. 4.31.
Моделирование состояний для классов. Если некоторый объект всегда одинаково реагирует на событие, то он считается независи мым от состояния по отношению к этому событию. В отличие от него зависимые от состояния объекты по-разному реагируют на одно и то же событие в зависимости от своего состояния. Обыч но в экономических ИС содержится очень мало объектов, зави симых от состояния, а системы управления технологическими процессами (системы реального времени) зачастую содержат множество таких объектов.
Если в системе присутствуют зависимые от состояния объек ты со сложной динамикой поведения, то для них можно постро ить модель, описывающую состояния объектов и переходы меж ду ними. Эта модель представляется в виде диафамм состояний.
В качестве примера, связанного с системой регистрации, рас смотрим поведение объекта класса CourseOffering. Диафамма состояний строится в несколько этапов:
1. Идентификация состояний. Признаками для выявления сос тояний являются изменение значений атрибутов объекта или соз дание и уничтожение связей с другими объектами. Так, объект CourseOffering может находиться в состоянии Open (прием на курс
Анализ и проектирование программного обеспечения |
3 3 7 |
ф Rational Ло5ё:^;:СЬУ|^^еШ|Ш1Ш||1И|Ш1И
Ш Sef |clt ^ew Formal: irows« Ee?P<5rt QuKsry tools fi^d-Ins ^i'rttJow йеЬ
«entity» Student
n a m e : string
- address: string
«class>> - nextAvaillD : int -studentID : int
- dateofBirth : Date
getTuitionO : double addSchedule(theSchedule : Schedule)
getScheduIe(forSemester: Semester): Schedule * deieteSchedule(forSemester: Semester)
+hasPrerequisites(forCourseOffering : CourseOffering): boolean
#passed(theCourseOffering : CourseOffering) : boolean «class» + getNextAvaillDQ : int
getStudentlDO : int getNameQ : string getAddressQ : string
i i
Рис. 4.31. Класс Student с полностью определенными операциями и атрибутами
открыт) до тех пор, пока количество зарегистрировавшихся на не го студентов не превышает 10, а как только оно станет равным 10, объект переходит в состояние Closed (прием на курс закрыт). Кро ме того, объект CourseOffering может находиться в состоянии Unassigned (его никто не ведет, т.е. отсутствует связь с каким-либо объектом Professor) или Assigned (такая связь существует).
2. Идентификация событий. События связаны, как правило, с выполнением некоторых операций. Так, в классе CourseOffering в результате распределения обязанностей при анализе варианта ис пользования «Выбрать курсы для преподавания» определены две операции — addProfessor и removeProfessor, связанные с выбором курса некоторым профессором (созданием новой связи) и отка-
338 |
Глава 4 |
зом от выбранного курса (разрывом связи). Этим операциям ста вятся в соответствие два события — addProfessor и removeProfessor.
3. Идентификация переходов между состояниями. Переход вызываются событиями. Таким образом, состояния Unassigned и Assigned соединяются двумя переходами (рис. 4.32).
%> Rational Rose -icoufscfeiy^lliii^•^•iffiiiliirtffi.imiijl
' Q^'t, ISf^ Ш^Ш Ш^т Heft? fl^.,|iyi.x)
Unassigned
add a professor remove aprofessor
Assigned
Рис. 4.32. Переходы между состояниями
Дальнейшая детализация поведения объекта CourseOffering приведет к построению диафаммы состояний, показанной на рис. 4.33. На данной диаграмме использованы такие возможнос ти моделирования состояний, как композитные состояния (com posite state) и историческое состояние (history state). В данном случае композитными состояниями являются Open и Closed, а вложенными состояниями — Unassigned, Assigned, Cancelled (курс отменен). Full (курс заполнен) и Committed (курс включен в расписание). Композитные состояния позволяют упростить ди аграмму, уменьшая количество переходов, поскольку вложенные состояния наследуют все свойства и переходы композитного сос тояния.
Историческое состояние (обозначенное на диаграмме ок ружностью с буквой «Н») — это псевдосостояние, которое восста навливает предыдущее активное состояние в композитном сое-
Анализ и проектирование программного обеспечения |
339 |
;ШЙШйШ:;й0«е:^:^*шигШёШйе$1сргт
13 е(е gdk1iJew fiiffft^ |^<^« • gjjsport
/numStudents»0
closeRegistration
Open |
|
Closed |
|
Unassigned |
close |
Cancelled |
иЦ |
|
|
||
|
|
|
remove a professor/
pas Professor assigneq
' close
Assigned
Committed
adti student /numStudents = numStudei^s
remove student / numStudents « numStudents -1
Lil
Рис. 4.33. Диаграммы состояний с композитными состояниями
тоянии. Оно позволяет композитному состоянию Open запоми нать, какое из вложенных состояний (Unassigned или Assigned) было текущим в момент выхода из Open, для того, чтобы любой из переходов в Open (add student или remove student) возвращался именно в это вложенное состояние, а не в начальное состояние.
Построение диафамм состояний может оказать следующее воздействие на описание классов:
• события могут отображаться в операции класса (например, события, связанные с изменением количества студентов, за писавшихся на курс, могут быть отображены в операции addStudent и removeStudent класса CourseOffering);