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

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

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

разрабатываться (при условии стабильности интерфейсов);

размещаться в распределенной среде;

изменяться без воздействия на остальные части системы;

• разделение системы на части из соображений ограничения

доступа к основным ресурсам;

• представление существующих продуктов или внешних сис-

тем (компонентов), которые не подлежат изменениям.

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

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

(design classes). По каждому классу анализа принимается одно из

двух решений:

• класс анализа отображается в проектный класс, если он

простой или представляет единственную логическую

абстракцию;

• сложный класс анализа может быть разбит на несколько

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

Объединение классов в подсистемы осуществляется, исходя

из следующих соображений:

• функциональная связь: объединяются классы, участвующие

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

щие только друг с другом;

• обязательность: совокупность классов, реализующая функ-

циональность, которая может быть удалена из системы или

заменена на альтернативную;

• связанность: объединение в подсистемы сильно связанных

классов;

• распределение: объединение классов, размещенных на

конкретном узле сети.

Примеры возможных подсистем:

• совокупность классов, обеспечивающих сложный комплекс

функций (например, обеспечение безопасности и защиты

данных);

• фаничные классы, реализующие сложный пользовательс-

кий интерфейс или интерфейс с внешними системами;

• различные продукты: коммуникационное ПО, доступ к ба-

зам данных, общие утилиты (библиотеки), различные при-

кладные пакеты.

При создании подсистем в модели выполняются следующие

преобразования:

• объединяемые классы помещаются в специальный пакет с

именем подсистемы и стереотипом <<subsystem>>;

322 Глава 4

• спецификации операций классов, образующих подсистему,

выносятся в интерфейс подсистемы

—

класс со стереотипом

<<Interface>>;

• описание интерфейса должно включать:

имя интерфейса, отражающее его роль в системе;

текстовое описание интерфейса размером в небольшой аб-

зац,

отражающее его обязанности;

описание операций интерфейса (имя, отражающее резуль-

тат операции, алгоритм выполнения операции, возвращае-

мое значение, параметры с

их

типами);

характер использования операций интерфейса и порядок их

выполнения документируется

с помощью

диаграмм взаимо-

действия, описывающих взаимодействие классов подсисте-

мы при реализации операций интерфейса, которые вместе с

диаграммой классов подсистемы объединяются в коопера-

цию

именем интерфейса

стереотипом <<interface realiza-

tion»;

• в подсистеме создается класс-посредник со стереотипом

<<subsystem ргоху>>, управляющий реализацией операций

интерфейса.

Все интерфейсы подсистем должны быть полностью опреде-

лены

процессе проектирования архитектуры, поскольку

они

бу-

дут служить в качестве точек синхронизации при параллельной

разработке системы.

В качестве примера (для системы регистрации) приведем

подсистему CourseCatalogSystem, которая создана вместо гранич-

ного класса CourseCatalogSystem. Диаграммы классов и взаимо-

действия, описывающие данную подсистему и ее интерфейс,

приведены на рис. 4.20—4.22. Классы DBCourseOfferring и

CourseOfferringList отвечают за взаимодействие с БД каталога

курсов

рамках

JDBC.

Объект CourseCatalogSystem Client на рис.

4.22 может принадлежать либо классу Close RegistrationController,

либо классу RegistrationController,

зависимости от

того,

в каком

из вариантов использования запрашивается каталог курсов.

Формирование архитектурных уровней

В процессе анализа было принято предварительное решение

о выделении архитектурных уровней (в случае системы регистра-

ции

—

четырех уровней в соответствии с образцом «Уровни»). В

процессе проектирования все элементы системы должны быть

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

323

Rational ЙЙШ'|1ШШШ|ШШ|11Я(:1|^^

^п:-

window йф

Pjirmafc |ruvi?sfe Export ^гу lodis Ш-tm

.^l<fl.xl

«control»

CI ose Re g istrati о n Co ntro 11 e г

(from Registration)

* II is registration open?0

* II close registrationQ

control»

Re g istrati 0 n Co ntro 11 e г

(from Registration)

getCurrentScheduleO

deleteCurrentScheduleQ

submitScheduieQ

g etCo u rse Offe ri n gsQ

•-course Catalog

JL.

«Interface»

I Co u rse Cata I о g Syste m

(from External System Interfaces)

-•- getCourseOfferingsQ : Course Offering List

* initializeO

Course Offering List

(from University Artifacts)

newQ

addO

«subsystem proxy»

Co u rse Cata 10 g Syste m

getCourseOfferingsO : Course Offering List

initializeO

2Ш

Рис.

4.20. Контекст подсистемы CourseCatalogSystem с точки зрения

архитектора

распределены поданным

уровням.

точки зрения модели это оз-

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

ствующим архитектурным уровням (пакетам со стереотипом

<<1ауег»).

сложной системе архитектурные уровни могут раз-

биваться на подуровни, количество и структура которых, как бы-

324

Глава

'4>Rati6riai Лб5ё^^Шт*ШЩШеШШШ№:^Ш

Щ|

gte

g<Mt

^т

.f^is^^j:^^im$iA ^?port ^<»»У' looJ^^

^^'^ Ш^^ .^^

nmlffi!

Ш1

«Interface»

I Со u rse Cata I о g Syste m

(from External System Interfaces)

* getCourseOfferingsQ

CourseOfferingList

+ initializeO

'-^

«subsystem proxy»

Course Catalog System

getCourseOfferingsQ : CourseOfferingList

initializeO

.--"^

CourseOfferingList

(from University Artifacts)

newQ

addO

~7Г

«entity»

Course Offering

(from University Artifacts)

DBCourseOfferring

ere ate 0

readQ

initializeO

Рис. 4.21.

Диаграмма классов подсистемы CourseCatalogSystem

с точки зрения проектировщика

ЛО сказано выше, зависят от сложности предметной области

среды реализации. Подуровни могут формироваться, исходя

из

следующих критериев:

• фуппировка элементов с максимальной связанностью;

• распределение

соответствии со структурой организации

(обычно это касается верхних уровней архитектуры);

• распределение

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

различными областями

компетенции разработчиков (предметная область, сети,

коммуникации, базы данных, безопасность и др.);

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

'^*';'"' *lsli£i

Rational Яо5е,*::соШ*^ШрЩ1Ш1111в

Ш № £<lit aev» (^tna^ Irowst EkepOJ't Xoc^ ё^'^Ш

CourseCatalogSystem Client

getCourseOfferingsO

: CourseCatalogSystem

read(strmg)

: D В Course Off erring

4: new() , ,

5:setData()//

: CourseOfferIng

3: new()

6: add (Course Offering)

: CourseOfferingList

Рис.

4.22. Кооперативная диаграмма, описывающая реализацию операции

интерфейса getCourseOfferings

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

темы;

• распределение в соответствии с различной степенью безо-

пасности и секретности.

Пример выделения архитектурных уровней и объединения

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

на рис. 4.23.

Данное представление отражает следующие решения, приня-

тые архитектором:

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

стереотипом <<1ауег»);

• в пакете Application создан пакет Registration, куда включе-

ны граничные и управляющие классы;

326

Глава 4

Browser

В "СЗ Logical View ^

Й "СЗ Design Model

Й'в1 <<1ауег>> Application

В"ИЙ Registration

Й-(!) CloseRegistrationController

Й'Ю CloseR egistrationForm

Й-Ю RegisterForCoursesForm

El"с!) RegistrationController

Ё]":4 Associations

^ Associations

Hi Architectural Mechanisms

Й- iii <<layer>> Business Services

Й-EiEI

BillingSystem

Й'Е^ CourseCatalogSystem

S "в1 External System Interfaces

El'Bl University Artifacts

El-Q Course

Й'-Q CourseOffering

Ф Ш CourseOfferingList

Й- Q Primary S cheduleO ff eringi nf о

Й'Q Professor

Й-Q Schedule

ElQ S cheduleO f f eringi nfo

Й-Q Student

gj...»^

Associations

z^ Associations

Й"СЗ «layer» Middleware

Й'СЗ com.odi

В'СЗ java.awt

Й'СЗ java.io

Й СЗ java.lang

Й'СЗ java.rmi

Й-D iava.sql zl

Рис.

4.23. Представление структуры модели в процессе проектирования

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

• граничные классы BillingSystem и CourseCatalogSystem пре-

образованы в подсистемы;

• в пакет Business Services, помимо подсистем, включены еще

два пакета: пакет External System Interfaces включает интер-

фейсы подсистем (классы со стереотипом <<Interface>>), а

пакет University Artifacts

—

все классы-сущности.

Проектирование структуры потоков управления

Проектирование структуры потоков управления выполняется

при наличии в системе параллельных процессов (параллелизма).

Цель проектирования — выявление существующих в системе

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

и отображения в среду реализации. Требование параллелизма

возникает в следующих случаях:

• необходимо распределение обработки между различными

процессорами или узлами;

• система управляется потоком событий (event-driven system);

• вычисления в системе обладают высокой интенсивностью;

• в системе одновременно работает много пользователей.

Например, система регистрации курсов обладает свойством

параллелизма, поскольку она должна допускать одновременную

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

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

Понятие

процесс (process)

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

• это ресурсоемкий поток управления, который может выпол-

няться параллельно с другими процессами;

• он выполняется в независимом адресном пространстве и в

случае высокой сложности может разделяться на два потока

или более;

• объект любого класса должен существовать внутри хотя бы

одного процесса.

Поток (thread)

—

это облегченный поток управления, кото-

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

ках одного и того же процесса в общем адресном пространстве.

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

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

• если курс окажется заполненным в то время, когда студент

формирует свой учебный фафик, включающий данный

курс,

то он должен быть извещен об этом (необходим неза-

328 Глава 4

висимый процесс, управляющий доступом к информации

конкретных курсов);

• существующая база данных каталога курсов не обеспечива-

ет требуемую производительность (необходим процесс про-

межуточной обработки

—

подкачки данных).

Реализация процессов и потоков обеспечивается средствами

операционной системы.

Для моделирования структуры потоков управления исполь-

зуются так называемые активные классы^

—

классы со стереоти-

пами <<process>> и <<thread>>. Активный класс владеет

собственным процессом или потоком и может инициировать уп-

равляющие воздействия. Связи между процессами моделируют-

ся как зависимости. Потоки могут существовать только внутри

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

лируются как композиции. Модель потоков управления поме-

щается в пакет Process View. В качестве примера на рис. 4.24

—

4.26 приведены фрагменты диаграммы классов, описывающей

структуру процесса регистрации студента на курсы. Активные

классы, показанные на этих диафаммах, выполняют следующее

назначение:

• StudentApplication

—

процесс, управляющий всеми функци-

ями студента-пользователя в системе. Для каждого студен-

та, начинающего регистрироваться на курсы, создается

один объект данного класса.

• Course Registration Process - процесс, управляющий непосре-

дственно регистрацией студента. Для каждого студента, на-

чинающего регистрироваться на курсы, также создается

один объект данного класса.

• CourseCatalogSystemAccess

—

управляет доступом к системе

каталога курсов. Один и тот же объект данного класса ис-

пользуется всеми пользователями при доступе к каталогу

курсов.

• CourseCache и OfferingCache используются для асинхрон-

ного доступа к данным в БД с целью повышения произво-

дительности системы. Они представляют собой кэш для

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

из БД.

^ Буч

Г.

др.

Язык UML. Руководство пользователя.: Пер. с

англ.

Г.

Буч,

Дж. Рамбо,

А.

Джекобсон. - М.: ДМК, 2000.

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

329

ф На1ШШ(;Ш1ШИ11Я1111Й1

ЩЛ

Fife Edft View Format Browse Rjeporl: Query

bote m^lm ijndw Help ^ -.jglxi

«process»

StudentApplication

_iL

<<process»

Course Registration Pro cess

«process»

Co u rse Cata I о g Syste m Access

«thread»

CourseCache

«thread»

QfferingCache

Рис. 4.24. Процессы и потоки

Проектирование конфигурации системы

Если создаваемая система является распределенной, то необ-

ходимо спроектировать ее конфигурацию в вычислительной среде,

т.е.

описать вычислительные ресурсы, коммуникации между ними

и использование ресурсов различными системными процессами.

Распределенная сетевая конфигурация системы моделируется

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

системы регистрации (без процессов) приведен на

рис.

4.27.

330

Глава

Rational

Rose

coursereg Jesign,f«^-К^ШШ^ШИЯ

efe ^dtt ^H

F^rnat

|row$« &®port,

^ry

Iool$ 6dd-ln$ Шг\^кн

t^lp

<< process»

StudentApplication

MainStudentForm

(from Regtstrati on)

°-4

«boundary»

Re g Iste rF о rCo u rsesF о rm

(from Registration)

«process»

CourseRegistrationProcess

1 1

«control»

Re g Istrati о n Co ntro Her

(from Registration)

«process»

Co u rse

Cata

10 g

Syste

Access

1 1

«subsystem proxy»

Co u rse Cata 10 g Syste m

(from CourseCatalogSysiem)

«Interface»

{Course Cata log System

(from External System irrterfaces)

Ш2^^Ш^

Рис.

4.25.

Классы, связанные с процессами

Распределение процессов, составляющих структуру потоков

управления,

по

узлам сети производится

учетом следующих

факторов: