Вендров А.М. Проектирование программного обеспечения экономических информационных систем

Подождите немного. Документ загружается.

Анализ и проектирование программного обеспечения

331

Rattondi

Rose

- <ошШ'ШШ^Ш

|>v^^С ^'>

шЩ!

х.|

dl Fife I<^^fe

5!$ew

ForitM^ Brow^<^ Iteport ^ery ВжЙ«^

да«|п* ^ndow Help ,^J.6!J..>c|

«process»

Course Catalog System Access

«thread»

CourseCache

0..П

«entity»

Course

(from University Artifacts)

«thread»

OfferingCache

0..П

«entity»

Course Offering

(from University Artifacts)

Рис.

4.26. Классы, связанные с потоками

• используемые образцы распределения (трехзвенная клиент-

серверная конфигурация, «толстый» клиент, «тонкий» кли-

ент, равноправные узлы (peer-to-peer) и т.д.);

• время отклика;

• минимизация сетевого трафика;

• мощность узла;

• надежность оборудования и коммуникаций.

Пример распределения процессов по узлам системы регист-

рации приведен на

рис.

4.28.

332

Глава 4

V '.^jmM

Qfi» fidft jr^

&t»*m

'шогц jpi^ Шы )йМо** m> jtJMM

RegistrationServer

«legacy»

BiiiingSystem

lii

Рис.

4.27. Сетевая конфигурация системы регистрации

шшшшввт

dfe«f^4i^t-ШйййШШ1Ш^

RegistrationServer

Course Cxtii og SystemAccess

Course

Regi strati

on Process

ose

Regi

strati on Process

III

ng SystemAccess

Рис.

4.28. Конфигурация системы регистрации с распределением

процессов по узлам

Анализ и проектирование программного обеспечения 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*»

// register for courses()

: MainStudentForm

open(string)

3: isRegistrationOpenO

displayAvaiLebleOperations()

: ReqisterForCoursesForm

4: open(string)

: Registration Controller

5: getStudent(string)

: CourseReqDBManaqer

Рис.

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

createSche^ldfel)

8: select 4 primary aiul 2 alterrjate()

: Student

2 j getCourseOfferings()

7: create schedule with offermgs(CourseOfferingList)

: Registration Controller

: Student

: getCourseOfferingsO .

: ICourseCatalogSystem

8: new(Semestef, CourseOfferingLlst)

Schedule

> .,i

Jtffi

Рис.

4.30. Кооперативная диаграмма «Зарегистрироваться на курсы»

подчиненный поток «Создать график»

Уточнение операций

атрибутов.

Обязанности классов, опре-

деленные

процессе анализа

документированные

виде опера-

ций «анализа», преобразуются в операции, которые будут реали-

зованы в коде. При этом:

• каждой операции присваивается краткое имя, характеризу-

ющее ее результат;

• определяется полная сигнатура операции (в соответствии с

нотацией, принятой

языке UML;

336 Глава 4

• создается краткое описание операции, включая смысл всех

ее параметров;

• определяется видимость операции: public, private или pro-

tected;

• определяется область действия операции: экземпляр (опе-

рация объекта) или классификатор (операция класса);

• может быть составлено описание алгоритма выполнения

операции (с использованием диафамм деятельности в виде

блок-схем, а также диафамм взаимодействия различных

объектов при выполнении операции).

Уточнение атрибутов классов заключается в следующем:

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

чанию (необязательное);

• учитываются соглашения по именованию атрибутов, при-

нятые в проекте и языке реализации;

• задается видимость атрибутов: public, private или protected;

• при необходимости определяются производные (вычисляе-

мые) атрибуты.

Пример уточнения операций и атрибутов приведен на

рис.

4.31.

Моделирование состояний для

классов.

Если некоторый объект

всегда одинаково реагирует на событие, то он считается независи-

мым от

состояния

по отношению к этому событию. В отличие от

него зависимые от состояния объекты по-разному реагируют на

одно и то же событие в зависимости от своего состояния. Обыч-

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

симых от состояния, а системы управления технологическими

процессами (системы реального времени) зачастую содержат

множество таких объектов.

Если в системе присутствуют зависимые от состояния объек-

ты со сложной динамикой поведения, то для них можно постро-

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

ду ними. Эта модель представляется в виде диафамм состояний.

В качестве примера, связанного с системой регистрации, рас-

смотрим поведение объекта класса CourseOffering. Диафамма

состояний строится в несколько этапов:

Идентификация

состояний.

Признаками для выявления сос-

тояний являются изменение значений атрибутов объекта или соз-

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

CourseOffering может находиться в состоянии Open (прием на курс

Анализ и проектирование программного обеспечения 337

Rational

Ло5ё:^;:СЬУ|^^еШ|Ш1Ш||1И|Ш1И

Sef |clt ^ew

Formal: irows« Ee?P<5rt QuKsry tools fi^d-Ins ^i'rttJow

йеЬ

name

string

- address: string

«class>> - nextAvaillD : int

-studentID : int

- dateofBirth : Date

«entity»

Student

getTuitionO : double

addSchedule(theSchedule : Schedule)

getScheduIe(forSemester: Semester): Schedule

* deieteSchedule(forSemester: Semester)

+ h asP re re quisites(forCourse Offering : CourseOffering): boolean

# passed(theCourseOffering : CourseOffering) : boolean

«class» + getNextAvaillDQ : int

getStudentlDO : int

getNameQ : string

getAddressQ : string

Рис. 4.31.

Класс Student с полностью определенными операциями

и атрибутами

открыт) до тех пор, пока количество зарегистрировавшихся на не-

го студентов не превышает 10, а как только оно станет равным 10,

объект переходит в состояние Closed (прием на курс закрыт). Кро-

ме того, объект CourseOffering может находиться в состоянии

Unassigned (его никто не ведет, т.е. отсутствует связь с каким-либо

объектом Professor) или Assigned (такая связь существует).

Идентификация

событий.

События связаны, как правило, с

выполнением некоторых операций. Так, в классе CourseOffering в

результате распределения обязанностей при анализе варианта ис-

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

операции

—

addProfessor и remove Professor, связанные с выбором

курса некоторым профессором (созданием новой связи) и отка-

338

Глава 4

зом от выбранного курса (разрывом связи). Этим операциям ста-

вятся

соответствие

два

события

—

addProfessor

removeProfessor.

Идентификация переходов между

состояниями.

Переходы

вызываются событиями. Таким образом, состояния 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 е(е gdk iJew

fiiffft^

|^<^«

•

gjjsport

/numStudents»0

closeRegistration

Open

Unassigned

remove a professor/

Assigned

adti student /numStudents

numStudei^s

Closed

Cancelled

pas Professor assigneq

' close

Committed

иЦ

remove student / numStudents « numStudents -1

Lil

Рис. 4.33.

Диаграммы состояний с композитными состояниями

тоянии. Оно позволяет композитному состоянию Open запоми-

нать,

какое из вложенных состояний (Unassigned или Assigned)

было текущим в момент выхода из Open, для того, чтобы любой

из переходов в Open (add student или remove student) возвращался

именно в это вложенное состояние, а не в начальное состояние.

Построение диафамм состояний может оказать следующее

воздействие на описание классов:

• события могут отображаться в операции класса (например,

события, связанные

изменением количества

студентов,

за-

писавшихся на курс, могут быть отображены в операции

addStudent и removeStudent класса CourseOffering);

340

Глава 4

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

тали выполнения операций;

• описание состояний и переходов может помочь при опреде-

лении атрибутов класса (например, значение количества

студентов, записавшихся на курс (numStudents), может быть

добавлено в класс CourseOffering в качестве производного

атрибута).

Уточнение связей между

классами.

В процессе проектирова-

ния связи между классами (ассоциации, агрегации и обобщения)

подлежат уточнению.

• Ассоциации между граничными и управляющими классами

отражают связи, динамически возникающие между соотве-

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

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

они преобразуются в зависимости.

V Rational Rose - сжиг5егед^е«1<9[ЛшЛ-шШ|1^1ШЙШШ^

! Bfe-;i!;lfc Шт fmmgk. 8wwwa>

,Ы^.

ji, =чу

. .jiffi

ilifttf I Jul

8«>ert Омегу. lools §#^ln* ^ЩФн

миф]

«control»

Re g istrati 0 n Co ntro 11 e г

(from Registration)

^registrant

\ ->

«Interface»

ICourseCatalogSystem

(from Extornal System lnterf»o»s)

0..1

^currentSchedule

«entity»

Student

(from University Artifacts)

0..1

0..П

«entity»

Schedule

(from University Artifacts)

0..2

_Y_

«entity»

CourseOffering

(from University Artifacts)

+a Item ate Courses

0..4

0..П

•i-primaiyCourses

bj-

Рис. 4.34. Пример преобразования ассоциаций и агрегаций