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

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

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

291

Система

приема

Персонал

Отчет

пациен-

тах

Регистр,

врача

Регистр,

пациен-

та

Курсы

лечения

Регистр,

курса

Прием

:^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).

<i^»Ra«onal Rose^ сШГ8егед-^Ш^1«.тщ

^_„„__

„ ^^.JBi>u

^ Ре pt Vbw

f$irrt^ |rows^ Report

Q^mt

teds j^^d^lns

^^m

«realizes»

«use-case realization»

(from Use-Case Realization - Login)

Войти в систему

(from Use Case Model)

Рис. 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»

RegisterForCoursesForm

«boundary»

CourseCataiogSystem

«control»

RegistrationController

«entity»

Student

«entity»

Schedule

«entity»

CourseOfFering

il.

Рис.

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

«Зарегистрироваться на курсы»

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

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

Квалифицированное распределение обязанностей между

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

рованного анализа. Исходя из назначения трех выделенных ти-

пов классов, можно кратко охарактеризовать распределение обя-

занностей между ними:

• граничные классы отвечают за взаимодействие с внешней

средой системы (действующими лицами);

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

данными;

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

анта использования.

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

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

(диаграмм последовательности и кооперативных диаграмм).

В процессе анализа конкретного варианта использования в

первую очередь строится диаграмма последовательности (одна

или более), описывающая основной поток событий и его подчи-

298

Глава 4

ненные потоки. Для каждого альтернативного потока событий

строится отдельная диаграмма (из соображений простоты нагляд-

ного восприятия). Нецелесообразно описывать тривиальные по-

токи событий (например, в потоке участвует только один объект).

•^* Rational Rose --z^rsefeg^jans^f^M^

^ W^^MM

: RegisterForCoursesForm : Registration Controller

; Студент

// register for courses()

of these i^

One I

is executed:

[ registratii

3: // display

4: // create schedule()

open]

possible operationsO

update schedule()

6: //

deleted

schedule()

->;

// is registration open?()

Sequence Diagram:

Basic Flow (Create

Schedule) j

Sequence Diagram:

Flow (Update Scheduled

Sequence Diagram: Register^

for Courses /Re gjiste г for

Courses - Basic Filow (Delete

Schedule)

Рис.

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

Основной поток событий

Анализ

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

На рис. 4.7-4.11 приведены диаграммы последовательности и

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

анта использования «Зарегистрироваться на курсы».

V Rational Rose

coursereg^naly^mdi-^ [ШШШ

[I3v

Вк g.dlt:

Щвщ

Fs^'ntia!:.^ growse

Щ^^роП

Jpob ^d*lns ^ndow

display course offerings()

display blank schedule()

: RegisterForCoursesForm

1://create

sdiediileO

7: //select4 pnmaiy aha 2 alternate offenngs()

get

create schedul

: Каталог

курсов

|urse offerings()

e With ofTeringsO

Registration Controller

: Студент

10:

add schedulefScheduU

get course

Student

get

coui^

offering^(forS em ester)

create with offerings()

: Schedule

offer! ngs()

: Course Catalog System

Рис.

4.8. Кооперативная диаграмма «Зарегистрироваться

на

курсы»

—

под-

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

300

Глава 4

Rational Rose ~

сом>^5егео:^)!1^у«1в^|Ш||ШШШШ1

01ft

Idi

V5«*» FSiTtti^t &u9m

^«port

tools uii^trt$ SiVlncfeH Help

// display schedule(Schedule)

7: // display coufse offermgs()

: ReqisterForCoursesForm

// update sckedule()

8: // update offefmg selections! |

: Студент

// get current scHedule(Student, forSemester)

5: // get course offerings!)

// update schedule with new selections!)

: ReqistrationControlier

3: // get schedule(for^meste

6: //get course olferings(forS em ester)

;

StMtlgnt

: Course Catalog System

10:

// update with new selections!)

: Schedule

IWlllf

-I

Рис.

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

•

подчиненный поток «Обновить график»

На последней диаграмме (см. рис. 4.11) присутствует объект

дополнительного класса-сущности PrimaryScheduleOfferinglnfo.

Его назначение будет описано ниже, при рассмотрении связей

между классами.

Обязанности каждого класса определяются исходя из сооб-

щений на диаграммах взаимодействия и документируются в