n1

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

291

1

Система

приема

Персонал	Курсы
	лечения

		Отчет о	Регистр,	История
		пациен­	курса	болезни
		тах
Регистр,	Регистр,		Отчет о
	пациен­	Прием	курсах
врача	та
		:^s:

Новый Выписка прием

Рис. 4.3. Диафамма последовательности экранных форм

4.3. ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ АНАЛИЗ

Целью объектно-ориентированного анализа^ является транс­ формация функциональных требований к ПО в предваритель­ ный системный проект и создание стабильной основы архитекту­ ры системы. В процессе проектирования системный проект «пог­ ружается» в среду реализации с учетом всех нефункциональных требований.

^ Методической основой данного и следующего подраздела является технология Rational Unified Process.

292

Глава 4

Объектно-ориентированный анализ включает два вида дея­ тельности: архитектурный анализ и анализ вариантов использо­ вания. Изложение их методики будет сопровождаться примерами из системы регистрации учебного заведения, которая рассматри­ валась в главе 3.

4 . 3 . 1 . АРХИТЕКТУРНЫЙ АНАЛИЗ

Архитектурный анализ выполняется архитектором системы и включает в себя:

•утверждение общих стандартов (соглашений) моделирова­ ния и документирования системы;

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

•формирование набора основных абстракций предметной области (классов анализа);

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

Соглашения моделирования определяют:

•используемые диафаммы и элементы модели;

•правила их применения;

•соглашения по именованию элементов модели;

•организацию модели (пакеты).

Пример набора соглашений моделирования:

•Имена вариантов использования должны быть короткими глагольными фразами.

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

•Имена классов должны начинаться с заглавной буквы.

•Имена атрибутов и операций должны начинаться со строч­ ной буквы.

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

•Все классы и диафаммы, описывающие предварительный системный проект, помещаются в пакет с именем Analysis Model.

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

293

•Диафаммы классов, реализующих вариант использования, и диафаммы взаимодействия, отражающие взаимодействие объектов в процессе реализации сценариев варианта ис­ пользования, помещаются в кооперацию (см. подразд. 2.6) с именем данного варианта использования и стереотипом «use-case realization». Все кооперации помещаются в пакет с именем Use Case Realizations. Связь между вариантом ис­ пользования и его реализацией изображается на специаль­ ной диафамме трассировки (рис. 4.4).

^ _ „ „ _ _	„	^^.JBi>u
<i^»Ra«onal Rose^ сШГ8егед-^Ш^1«.тщ
^ Ре p t Vbw f$irrt^	|rows^ Report Q^mt teds	j^^d^lns ^^m

«realizes»	J
«use-case realization»	Войти в систему
Login	(from Use Case Model)
(from Use-Case Realization - Login)

Рис. 4.4. Фрагмент диаграммы трассировки

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

Архитектурные механизмы, по существу, представляют собой набор типовых решений, или образцов, принятых в качестве стандарта данного проекта.

Идентификация основных абстракций заключается в предва­ рительном определении набора классов системы (классов анали­ за) на основе описания предметной области и спецификации требований к системе (в частности, глоссария). Способы иденти-

294

Глава 4

фикации основных абстракций аналогичны способам идентифи­ кации сущностей в модели ERM.

Так, для системы регистрации идентифицировано пять клас­ сов анализа:

•Student (Студент);

•Professor (Профессор);

•Schedule (Учебный график);

•Course (Курс);

•CourseOffering (Предлагаемый курс). Классы анализа показаны на рис. 4.5.

фRational Rose - cour$i||||||i|

Student Professor

Schedule

CourseOffering Course

Рис. 4.5. Классы анализа системы регистрации

Архитектурные уровни образуют иерархию уровней представ­ ления любой крупномасштабной системы. В практике разработ­ ки таких систем существует ряд типовых решений — архитектур­ ных образцов, среди которых наиболее распространенным явля­ ется образец «Уровни» (Layers). Этот образец можно описать сле­ дующим образом:

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

295

Наименование образца:

«Уровни».

Контекст:

Крупномасштабные системы, нуждающиеся в декомпозиции.

Проблема:

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

•компоненты системы должны иметь возможность замены;

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

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

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

Решение:

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

уровни (сверху вниз):

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

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

•промежуточный (Middleware) - различные платформо-не- зависимые сервисы (библиотеки пользовательского интер­ фейса, брокеры запросов и др.);

•системный (System software) - ПО для вычислительной и се­ тевой инфраструктуры (ОС, сетевые протоколы и др.).

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

4 . 3 . 2 . АНАЛИЗ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

Анализ вариантов использования выполняется проектиров­ щиками и включает в себя:

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

296

Глава 4

•распределение поведения, реализуемого вариантом исполь­ зования, между классами (определение обязанностей клас­ сов);

•определение атрибутов и ассоциаций классов;

•унификацию классов анализа.

Идентификация классов, участвующих в реализации потоков событий варианта использования

В потоках событий варианта использования выявляются классы трех типов.

Граничные классы (Boundary) — служат посредниками при вза­ имодействии внешних объектов с системой. Как правило, для каждой пары «действующее лицо — вариант использования» оп­ ределяется один граничный класс. Типы граничных классов: пользовательский интерфейс (обмен информацией с пользовате­ лем без деталей интерфейса — кнопок, списков, окон), систем­ ный интерфейс и аппаратный интерфейс (используемые прото­ колы без деталей их реализации).

Классы-сущности (Entity) — представляют собой основные абстракции (понятия) разрабатываемой системы, рассматривае­ мые в рамках конкретного варианта использования. Источники выявления классов-сущностей: основные абстракции, созданные в процессе архитектурного анализа, глоссарий, описание потоков событий вариантов использования, суШности, описанные в мо­ дели бизнес-анализа (при наличии бизнес-модели).

Управляющие классы (Control) — обеспечивают координацию поведения объектов в системе. Они могут отсутствовать в некото­ рых вариантах использования, офаничивающихся простыми ма­ нипуляциями с хранимыми данными. Как правило, для каждого варианта использования определяется один управляющий класс. Примеры управляющих классов: менеджер транзакций, коорди­ натор ресурсов, обработчик ошибок.

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

Пример набора классов, участвующих в реализации вариан­ та использования «Зарегистрироваться на курсы», приведен на рис. 4.6.

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

297

4> Rational kosm:t6шйmш.JmШ$Ш1ШшШшШ

|§] ре gjdft 3ilew Fgrmat growse &i^Oft Q,t^ry lools ^.dd-lns ^Sndow

«boundary» «boundary» RegisterForCoursesForm CourseCataiogSystem

«control» RegistrationController

«entity»	«entity»	«entity»
Student	Schedule	CourseOfFering
il.		J

Рис. 4.6. Классы, участвующие в реализации варианта использования «Зарегистрироваться на курсы»

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

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

•граничные классы отвечают за взаимодействие с внешней средой системы (действующими лицами);

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

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

Более детальное распределение обязанностей (в виде опера­ ций классов) выполняется с помощью диаграмм взаимодействия (диаграмм последовательности и кооперативных диаграмм).

В процессе анализа конкретного варианта использования в первую очередь строится диаграмма последовательности (одна или более), описывающая основной поток событий и его подчи-

298

Глава 4

ненные потоки. Для каждого альтернативного потока событий строится отдельная диаграмма (из соображений простоты нагляд­ ного восприятия). Нецелесообразно описывать тривиальные по­ токи событий (например, в потоке участвует только один объект).

•^* Rational Rose

--z^rsefeg^jans^f^M^

^ W^^MM

TJ

: RegisterForCoursesForm

: RegistrationController

; Студент

. 1: // register for courses()

2: // is registration open?()

[ registratii open]

3: // display possible operationsO

1

4: // create schedule()

One Iof these i^ is executed:

5:V/ update schedule()

6:// deleted schedule()

->;

Sequence Diagram:		1 \
Register for Couijses /
Register for Couijses -
Basic Flow (Create
Schedule)	j

Sequence Diagram: Register for Couijses / Register for Couijses - Basic Flow (Update Scheduled

Sequence Diagram: Register^ for Courses /Re gjisteг for Courses - Basic Filow (Delete Schedule)

Рис. 4.7. Диаграмма последовательности «Зарегистрироваться на курсы» - Основной поток событий

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

2 9 9

На рис. 4.7-4.11 приведены диаграммы последовательности и кооперативные диаграммы для основного потока событий вари­ анта использования «Зарегистрироваться на курсы».

V Rational Rose - coursereg^naly^mdi-^ [ Ш Ш Ш [I3v 1v

Вк g.dlt: Щвщ Fs^'ntia!:.^ growse Щ^^роП Jpob ^d*lns ^ndow

5:// display course offerings()

6:// display blank schedule()

>

: RegisterForCoursesForm

: Каталог

1://create sdiediileO курсов 7: //select4 pnmaiy aha 2 alternate offenngs()

V

2: // get cd|urse offerings()

8: // create schedule With ofTeringsO

Registration Controller

A

: Студент

4: // get course offer!ngs()

10:// add schedulefScheduU

уh^ get coui^ offering^(forSemester)

9: // create with offerings()

Student

: Course CatalogSystem

: Schedule

Рис. 4.8. Кооперативная диаграмма «Зарегистрироваться на курсы» — под­ чиненный поток «Создать фафик»

300	Глава 4
4> Rational Rose ~ сом>^5егео:^)!1^у«1в^|Ш||ШШШШ1
01ft I d i V5«*» FSiTtti^t &u9m ^ ^«port tools uii^trt$ SiVlncfeH	Help
4: // display schedule(Schedule)
7: // display coufse offermgs()
>

:ReqisterForCoursesForm

1:// update sckedule()

8:// update offefmg selections! |

2:// get current scHedule(Student, forSemester)

5:// get course offerings!)

9:// update schedule with new selections!)

:Студент

:ReqistrationControlier

3:// get schedule(for^meste

6: //get course olferings(forS em ester) : Course Catalog System

; StMtlgnt

10: // update with new selections!)

: Schedule

IWlllf

-I

J

Рис. 4.9. Кооперативная диаграмма «Зарегистрироваться на курсы» • подчиненный поток «Обновить график»

На последней диаграмме (см. рис. 4.11) присутствует объект дополнительного класса-сущности PrimaryScheduleOfferinglnfo. Его назначение будет описано ниже, при рассмотрении связей между классами.

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