1vendrov_a_m_proektirovanie_programmnogo_obespecheniya_ekonom

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

321

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

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

•представление существующих продуктов или внешних сис­ тем (компонентов), которые не подлежат изменениям.

Первым действием архитектора при выявлении подсистем является преобразование классов анализа в проектные классы (design classes). По каждому классу анализа принимается одно из двух решений:

•класс анализа отображается в проектный класс, если он простой или представляет единственную логическую абстракцию;

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

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

•функциональная связь: объединяются классы, участвующие в реализации варианта использования и взаимодействую­ щие только друг с другом;

•обязательность: совокупность классов, реализующая функ­ циональность, которая может быть удалена из системы или заменена на альтернативную;

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

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

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

•совокупность классов, обеспечивающих сложный комплекс функций (например, обеспечение безопасности и защиты данных);

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

•различные продукты: коммуникационное ПО, доступ к ба­ зам данных, общие утилиты (библиотеки), различные при­ кладные пакеты.

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

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

322

Глава 4

•спецификации операций классов, образующих подсистему, выносятся в интерфейс подсистемы — класс со стереотипом <<Interface>>;

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

имя интерфейса, отражающее его роль в системе; текстовое описание интерфейса размером в небольшой аб­ зац, отражающее его обязанности; описание операций интерфейса (имя, отражающее резуль­

тат операции, алгоритм выполнения операции, возвращае­ мое значение, параметры с их типами); характер использования операций интерфейса и порядок их

выполнения документируется с помощью диаграмм взаимо­ действия, описывающих взаимодействие классов подсисте­ мы при реализации операций интерфейса, которые вместе с диаграммой классов подсистемы объединяются в коопера­ цию с именем интерфейса и стереотипом <<interface realiza­ tion»;

•в подсистеме создается класс-посредник со стереотипом <<subsystem ргоху>>, управляющий реализацией операций интерфейса.

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

В качестве примера (для системы регистрации) приведем подсистему CourseCatalogSystem, которая создана вместо гранич­ ного класса CourseCatalogSystem. Диаграммы классов и взаимо­ действия, описывающие данную подсистему и ее интерфейс, приведены на рис. 4.20—4.22. Классы DBCourseOfferring и CourseOfferringList отвечают за взаимодействие с БД каталога курсов в рамках JDBC. Объект CourseCatalogSystem Client на рис. 4.22 может принадлежать либо классу CloseRegistrationController, либо классу RegistrationController, в зависимости от того, в каком из вариантов использования запрашивается каталог курсов.

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

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

овыделении архитектурных уровней (в случае системы регистра­ ции — четырех уровней в соответствии с образцом «Уровни»). В процессе проектирования все элементы системы должны быть

Анализ и проектирование программного обеспечения		323
4^ Rational ЙЙШ'|1ШШШ|ШШ|11Я(:1|^^	^п:-
Pjirmafc |ruvi?sfe Export ^гу	lodis Ш-tm
window йф	.^l<fl.xl

«control»

CIoseRe gistratiо nCo ntro11eг

(from Registration)

*II is registration open?0

*II close registrationQ

<< control»

Registrati0nContro11eг

(from Registration)

getCurrentScheduleO deleteCurrentScheduleQ submitScheduieQ

getCourse Offe ringsQ

•-courseCatalog

JL.

«Interface»

ICourseCataIоgSystem

(from External System Interfaces)

-•- getCourseOfferingsQ : CourseOfferingList * initializeO

~K	. ^	A
	CourseOfferingList
	(from University Artifacts)
	newQ
	addO
	IT
«subsystem proxy»
Co urse Cata 10gSystem
getCourseOfferingsO : CourseOfferingList
initializeO
iL		2Ш

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

распределены поданным уровням. С точки зрения модели это оз­ начает распределение проектных классов по пакетам, соответ­ ствующим архитектурным уровням (пакетам со стереотипом <<1ауег»). В сложной системе архитектурные уровни могут раз­ биваться на подуровни, количество и структура которых, как бы-

3 2 4			Глава 4
: '4>Rati6riai Лб5ё^^Шт*ШЩШеШШШ№:^Ш
^ Щ|	gte g<Mt ^т .f^is^^j:^^im$iA ^?port	^<»»У' looJ^^	^^'^ Ш^^ . ^ ^ nmlffi! Ш1
	«Interface»
	IСоurseCataIоgSystem
	(from External System Interfaces)
*	getCourseOfferingsQ : CourseOfferingList
+ initializeO
	^	'-^	CourseOfferingList
			(from University Artifacts)
			newQ
	«subsystem proxy»	. - - " ^	addO
		~7Г
	CourseCatalogSystem

getCourseOfferingsQ : CourseOfferingList initializeO

«entity» CourseOffering

(from University Artifacts)

JL

DBCourseOfferring

ereate0 readQ

initializeO

m

Рис. 4.21. Диаграмма классов подсистемы CourseCatalogSystem с точки зрения проектировщика

ЛО сказано выше, зависят от сложности предметной области и среды реализации. Подуровни могут формироваться, исходя из следующих критериев:

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

•распределение в соответствии со структурой организации (обычно это касается верхних уровней архитектуры);

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

Анализ и проектирование программного обеспечения		325
4* Rational Яо5е,*::соШ*^ШрЩ1Ш1111в	'^*';'"' *lsli£i
Ш № £<lit aev» (^tna^ Irowst EkepOJ't	Xoc^ ё^'^Ш

CourseCatalogSystem Client

1: getCourseOfferingsO

t

:CourseCatalogSystem

2:read(strmg)

V

:DВCourseOfferring

		3: new()
4: new()	, ,	6: add(CourseOffering)
5:setData()//
: CourseOfferIng		: CourseOfferingList

Ы

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

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

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

Пример выделения архитектурных уровней и объединения элементов модели в пакеты для системы регистрации приведен на рис. 4.23.

Данное представление отражает следующие решения, приня­ тые архитектором:

•вьщелены три архитектурных уровня (созданы три пакета со стереотипом <<1ауег»);

•в пакете Application создан пакет Registration, куда включе­ ны граничные и управляющие классы;

3 2 6

Глава 4

Browser

В "СЗ Logical View

^

Й"СЗ Design Model

Й' в 1 <<1ауег>> Application В"ИЙ Registration

Й-(!) CloseRegistrationController

Й' Ю CloseR egistrationForm

Й- Ю RegisterForCoursesForm El"с!) RegistrationController

Ё]":4 Associations

^Associations

H i Architectural Mechanisms Й- i i i <<layer>> Business Services

Й-EiEI BillingSystem

Й'Е^ CourseCatalogSystem

S "в1 External System Interfaces E l ' B l University Artifacts

El - Q Course

Й'-Q CourseOffering

Ф Ш CourseOfferingList

Й- Q PrimaryS cheduleO fferingi nfо

Й ' Q		Professor
Й - Q		Schedule
E l Q		S cheduleO fferingi 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 — процесс, управляющий всеми функци­ ями студента-пользователя в системе. Для каждого студен­ та, начинающего регистрироваться на курсы, создается один объект данного класса.

•CourseRegistrationProcess - процесс, управляющий непосре­ дственно регистрацией студента. Для каждого студента, на­ чинающего регистрироваться на курсы, также создается один объект данного класса.

•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» CourseRegistrationProcess

JL

«process»

CourseCataIоgSystemAccess

1	1

« t h r e a d » CourseCache

« t h r e a d » QfferingCache

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

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

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

Распределенная сетевая конфигурация системы моделируется с помощью диафаммы размещения. Пример такой диафаммы для системы регистрации (без процессов) приведен на рис. 4.27.

330				Глава 4
ф Rational Rose - coursereg J e s i g n , f « ^ - К ^ Ш Ш ^ Ш И Я
@j efe ^dtt ^H F^rnat |row$«	&®port, ^ry			Iool$ 6dd-ln$ Шг\^кн t^lp
<< process»		-^		MainStudentForm
StudentApplication				(from Regtstrati on)
				°-4
				«boundary»
			RegIste rFоrCo ursesFоrm
				(from Registration)
				1
				1 V
«process»				«control»
		-^	Re g Istrati оn Contro Her
CourseRegistrationProcess
	1			(from Registration)
		1
^	1	1		«subsystem proxy»
«process»
				Cou rseCata10 gSystem

Cou rse Cata 10 g Syste mAccess	(from CourseCatalogSysiem)

SL

«Interface» {Course Catalog System

(from External System irrterfaces)

Ш2^^Ш^

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

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