Вендров А.М. Проектирование программного обеспечения экономических информационных систем
Подождите немного. Документ загружается.
Анализ и проектирование программного обеспечения 311
Пример:
Используем тот же пример, что и для предыдущего образца
(см.
рис.
4.13).
Согласно образцу «High Cohesion», наилучшим ре-
шением также является вариант 2, поскольку при этом класс
RegistrationController делегирует обязанность создания нового
объекта класса Shedule классу Student, и у самого класса
RegistrationController будет на одну обязанность меньше (т.е. его
сцепление будет сильнее).
Следствия:
Как правило, класс с сильным сцеплением содержит сравни-
тельно небольшое число методов, которые функционально тесно
связаны между собой, и не выполняет слишком много функций.
Он взаимодействует с другими классами для выполнения более
сложных
задач.
Высокая степень однотипной функциональности
в сочетании с небольшим числом операций упрощают поддержку
и модификацию класса, а также возможность его повторного ис-
пользования.
Образец High Cohesion, как и другие понятия объектно-ори-
ентированной технологии проектирования, имеет аналогию
в
ре-
альном мире. Известно, что человек, выполняющий большое
число разнородных обязанностей (особенно тех, которые можно
легко распределить между другими людьми), работает не очень
эффективно. Особенно это касается менеджеров, которые не
умеют распределять обязанности между своими подчиненными.
Слабая связанность и сильное сцепление
—
основные прин-
ципы проектирования ПО. Объектное проектирование пол-
ностью с ними согласуется, поскольку одним из его базовых
принципов является модульность.
Однако существуют
ситуации,
когда слабое сцепление оказы-
вается оправданным. Одна из таких ситуаций возникает в том
случае, когда обязанности или код группируются в одном классе
или компоненте
для
упрощения его поддержки одним человеком.
Другой пример слабого сцепления имеет отношение к распреде-
ленным серверным объектам. Поскольку быстродействие систе-
мы определяется производительностью удаленных объектов и их
взаимодействием, иногда желательно создать несколько крупных
серверных объектов со слабым сцеплением, предоставляющих
интерфейс многим операциям. Это приведет к уменьшению чис-
ла удаленных вызовов и, как следствие, к повышению произво-
дительности.
312 Глава 4
Набор обязанностей классов, полученный в результате их
распределения, должен быть проанализирован на предмет выяв-
ления и устранения следующих проблем:
• дублирования одинаковых обязанностей в различных
классах;
• противоречивых обязанностей в рамках класса;
• классов
с
одной обязанностью или вообще без обязанностей;
• классов, взаимодействующих с большим количеством дру-
гих классов.
Определение атрибутов
и
ассоциаций классов
Атрибуты классов анализа определяются, исходя из знаний о
предметной области, требований к системе, глоссария и бизнес-
модели. В процессе анализа атрибуты определяются только для
классов-сущностей, и они имеют тот же смысл, что и в модели
ERM. Атрибуты должны быть простыми, т.е. выразимыми с по-
мощью простых
типов
данных (одной
из
распространенных оши-
бок является моделирование сложного понятия предметной об-
ласти в виде атрибута). Так, после определения атрибутов для
классов-сущностей, показанных на рис. 4.12, они примут следу-
ющий вид (рис. 4.14).
Связи между классами (ассоциации) определяются
в два
этапа:
1.
Начальный набор связей определяется на основе анализа
кооперативных диаграмм. Если два объекта взаимодействуют
(обмениваются сообщениями), между ними на кооперативной
диафамме должна существовать связь (путь взаимодействия),
которая преобразуется
в
двунаправленную ассоциацию
между
со-
ответствующими классами. Если сообщения между некоторой
парой объектов передаются только в одном направлении, то для
соответствующей ассоциации вводится направление навигации.
2.
Анализируются
и
уточняются ассоциации между классами-
сущностями. Задаются мощности ассоциаций, могут использо-
ваться множественные ассоциации, агрегации, обобщения и ас-
социации-классы.
Следует избегать использования избыточных ассоциаций и
сосредоточиться на тех ассоциациях, для которых данные о связи
должны сохраняться
в
течение некоторого времени.
Это
достаточ-
но важный момент. Если модель содержит N различных классов
анализа, то между ними можно установить N*(N-1) ассоциацию,
большинство из которых будет просто создавать «визуальный
Анализ и проектирование программного обеспечения
313
i> Rational Rose - соиг5егей^пЫу*^^^Н»Я
Щ File giU "^m Format grow^e Report ^u^ty Tools .
«entity»
Student
name
address
studentID
// add scheduieQ
// get scheduieQ
// delete scheduieQ
// has prerequisitesQ
«entity»
Schedule
semester
«entity»
Course Offering
number : String = "
startTime : Time
endTime : Time
days:
Enum
/ numStudents: Int
100"
// add studentQ
// remove studentQ
//still open?0
// deleteQ
// submitQ
//saveQ
// any conflicts?Q
// create with offeringsQ
// update with newselectionsQ
Рис.
4.14. Классы с операциями «анализа» и атрибутами
шум»
и
ухудшать наглядность
диаграмм.
Поэтому
при
добавлении
ассоциаций нужно придерживаться принципа минимализма.
Результаты определения связей между классами, принимаю-
щими участие в реализации варианта использования «Зарегист-
рироваться на курсы», показаны на
рис.
4.15
—
4.17.
На рис. 4.15 показаны только классы-сущности. Агрегация
между классами Student
и
Schedule отражает
тот
факт,
что каждый
фафик является собственностью конкретного студента, принад-
лежит только
ему.
Предполагается также, что
в
системе будет хра-
ниться не только график текущего семестра, а все графики сту-
дента за разные семестры. Между классами Schedule и
CourseOffering введено две ассоциации, поскольку конкретный
курс может входить в график студента в качестве основного (не
314
Глава 4
•ф-
Rational Rose
-хо^%т:т^ЫуШтШ^^ШМ^^^МШШ^^
F|^«t grows» |.epart g^ry 'J0k
jdd-l^
Pxlow Help .y.j.#|xl
«entity»
Student
name
address
IstudentlD
5
1
0..П
«entity»
Schedule
0..П
0..П
saltern ate Courses
«entity»
FulltlmeStudent
(from Analysis Model)
- gradDate
«entity»
ParttlmeStudent
Jfro
rn
Anal
ysi^
Model)
- maxNumCourses
•^pnma
0..2
«entity»
Course Offering
Рис. 4.15. Диаграмма классов-сущностей
более четырех курсов) и альтернативного (не более двух курсов).
К классу Student добавлены два новых подкласса —
FulltimeStudent (студент очного отделения) и ParttlmeStudent
(студент вечернего отделения).
На рис. 4.16 показаны ассоциации-классы, представляющие
свойства связей между классами Schedule и CourseOffering. Ассо-
циация, связывающая график и альтернативный курс, имеет
только один атрибут
—
статус курса в конкретном графике (sta-
tus),
который может принимать значения «включен в фафик»,
«отменен», «внесен
в
список курса» и «зафиксирован
в
графике».
Если курс в процессе закрытия регистрации переходит из аль-
тернативного в основные, то к соответствующей ассоциации до-
бавляется атрибут «оценка» (grade). Таким образом, ассоциация-
класс PrimaryScheduleOfferinglnfo наследует свойства ассоциа-
ции-класса ScheduleOfferinglnfo (атрибуты и операции, содержа-
щиеся в этом классе, относятся как к основным, так и к альтер-
нативным курсам) и добавляет свои собственные (оценка и
окончательное включение курса в график могут иметь место
только для основных курсов), что и показано с помощью связи
обобщения.
Анализ
и
проектирование программного обеспечения
315
^
Rational
ftdse::!
Шиг^1ШММ|Яв^
Idft iew? fgrmat irowse Export jQtuery loote ^tM-lns №dow
MM
«entity»
PrimaryScheduleOfferinglnfo
grade
//
Is
enrolled in?0
// mark
as
enrolled
InQ
// mark
as
committedQ
«entity»
Schedule
0..П
0..П
\ + primary Courses
0..4
-^-„^^Ite rn ate Co u rses
«entity»
Course Offering
/0..2
Ч.
«entity»
ScheduleOfferinglnfo
status
// mark asselectedQ
// mark as cancelledQ
//
is
selected?0
Рис.
4.16. Пример ассоциаций-классов
На
рис.
4.17 показана полная диаграмма классов варианта ис-
пользования «Зарегистрироваться
на
курсы»
(без
атрибутов
и
операций). Ассоциации между граничными
и
управляющими
классами,
а
также между управляющими классами
и
классами-
сущностями введены
на
основе анализа кооперативных диаг-
рамм
и в
отличие
от
устойчивых структурных (семантических)
связей между сущностями отражают связи, динамически возни-
кающие между соответствующими объектами
в
потоке управле-
ния (в процессе работы приложения). Поскольку для ассоциаций
316
Глава 4
^ Rationd КЪ5^;:|;с0ШШ^ё|ШййШШШ|Ш^
т-'
\ £1е lidit tmt %nf«^ |m«v$» g<spoit
^uery lads ^dd-In5 ^ndow Цф ^
^Л|
«boundary»
RegisterForCoursesform
\K
<<control»
Registration Controller
0..П
«boundaiy»
Course CatalogSystem
0..1
-•-curretrtSchedule
0..1
«entity»
Student
4^
1 0..П
«entity»
Schedule
0..1
0..П
«entity»
Course Offering
Каталог курсов
(from Use Case Mc )
^prlma/y Courses
0..4
+alternateCourses
Ы
Рис.
4.17. Полная диаграмма классов (без атрибутов и операций)
ЭТО
не свойственно, в дальнейшем (в процессе проектирования)
они могут быть преобразованы в зависимости.
Унификация классов анализа
Унификация классов анализа заключается в проверке создан-
ных классов на предмет выполнения следующих условий:
• имя и описание каждого класса «анализа» должно отражать
сущность его роли в системе. Имена должны быть уникаль-
ными;
Анализ и проектирование программного обеспечения 317
• классы с одинаковым поведением, или представляющие од-
но и то же явление, должны объединяться;
• классы-сущности с одинаковыми атрибутами должны объе-
диняться (даже если их поведение отличается). Объединен-
ный класс будет обладать общим поведением.
При обновлении классов должны, при необходимости, об-
новляться описания вариантов использования.
4.4.
ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ
ПРОЕКТИРОВАНИЕ
Целью объектно-ориентированного проектирования являет-
ся адаптация предварительного системного проекта (набора
классов «анализа»), составляющего стабильную основу архитек-
туры системы, к среде реализации с учетом всех нефункциональ-
ных требований.
Объектно-ориентированное проектирование включает два
вида деятельности:
• проектирование архитектуры системы;
• проектирование элементов системы.
Их изложение будет сопровождаться примерами из системы
регистрации учебного заведения.
4.4.1.
ПРОЕКТИРОВАНИЕ АРХИТЕКТУРЫ СИСТЕМЫ
Проектирование архитектуры системы выполняется архитек-
тором системы и включает в себя:
• идентификацию архитектурных решений и механизмов, не-
обходимых для проектирования системы;
• анализ взаимодействий между классами анализа, выявление
подсистем и интерфейсов;
• формирование архитектурных уровней;
• проектирование структуры потоков управления;
• проектирование конфигурации системы.
Идентификация архитектурных
решений и
механизмов
В
процессе проектирования определяются детали реализации
архитектурных механизмов, обозначенных в процессе анализа.
318
Глава 4
Поскольку практически все механизмы
—
это некоторые типовые
решения (образцы), они документируются в проекте (модели) с
помощью кооперации со стереотипом «mechanism», при этом
структурная часть механизма описывается с помощью диафамм
классов, а поведение
—
с помощью диаграмм взаимодействия.
В
качестве примера рассмотрим механизм хранения данных в
БД. Предположим, что в проекте системы регистрации в качест-
ве языка программирования используется Java. Поскольку суще-
ствующая система каталога курсов функционирует на основе ре-
ляционной СУБД, таким механизмом, обеспечивающим
доступ
к
^
Rational
Rose - соиг^ёгед^^ёйюп^ГгкЯ^ ТШзй ШЩГШй!^^
^^'±:^^;;
п^<
\ф Ш W^ J^t-mat
Wtmi^
ppott
S!M«ry
loofe.Mi-Jf^
Wi^m ^b^
«role»
PersistencyClient
(from SamplePersistenpy Client)
«role»
P e rsiste ntCI assL ist
(from Sample Persistent
CI
ass)
+ newO
* add(c : Re rsiste ntCI ass)
"~7^
«role»
DBCIass
+ ere ate 0 : Pe rsiste ntCI ass
* re ad (search Criteria : string): Pe rsiste ntCiassL ist
+ update(c : Pe rsiste ntCI ass)
+ delete (c : Pe rsiste ntCI ass)
-i>-
ResuitSet
(from Java sql)
getStringO: string
IT
1
0..П
Statement
(from Java sql)
executeQuery(sqi: string): ResultSet
executeUpdate(sql: string) : int
«role»
Pe rsiste ntCI ass
(from Sample Persistent
CI
ass)
getDataQ
setDataQ
commando
newQ
_2^
DriverManager
(from Java sql)
+ getConnection(url,
user,
pas^ : Connection
Connection
(from Java sql)
createStatementQ : Statement
4
Рис.
4.18.
Диаграмма
классов
кооперации,
описывающей JDBC
Анализ и проектирование программного обеспечения 319
этой внешней базе данных, должен быть JDBC (Java Database
Connectivity). На рис. 4.18 показана диаграмма классов образца,
описывающего JDBC.
Все классы, изображенные на данной диаграмме, можно раз-
делить на две группы:
• Собственно классы JDBC (DriverManager, Connection,
Statement, ResultSet), которые отвечают за реализацию зап-
роса к БД (выполнение оператора SQL). Эти классы при-
надлежат к архитектурному уровню Middleware и входят в
соответствующий пакет.
• Классы со стереотипом <<го1е>>, являющиеся «заполните-
лями» (placeholders) реальных классов, создаваемых разра-
ботчиком системы. Они выполняют следующее назначение:
DBClass
—
отвечает за чтение и запись данных. Класс такого
типа создается для каждого устойчивого (persistent) класса, или,
иначе говоря, класса, данные которого
будут
храниться в некото-
рой БД
(в
данном случае -
в
таблицах реляционной БД). Напри-
мер,
в системе регистрации на курсы в процессе анализа в соот-
ветствии с образцом Information Expert определено, что класс-
сущность Course должен отвечать за сохранение информации об
учебных курсах
в
базе данных. Однако при этом, как было сказа-
но
в
данном образце, возникает проблема перегруженности клас-
са лишними обязанностями, поскольку класс Course должен не-
посредственно содержать вызовы сервисов
JDBC.
Разделение ос-
новных функций системы на уровни (применение образца
«Уровни»)
в
данном случае означает, что обязанности взаимодей-
ствия с БД выносятся из класса Course в класс DBCourse.
PersistencyClient - класс, запрашивающий создание, чтение,
обновление или удаление данных.
PersistentClass
—
класс-сущность, объекты которого содержат
необходимые данные.
PersistentClassList - список объектов, являющихся результа-
том запроса к БД ~ выполнения операции DBClass.read().
Выполнение операций, реализуемых механизмом JDBC (опе-
раций класса DBClass), документируется с помощью диаграмм
взаимодействия. Одна из таких диаграмм
—
кооперативная диаг-
рамма, показывающая выполнение операции создания новых
данных (create), приведена на
рис.
4.19.
Из диаграммы на рис. 4.19 видно, что для создания новых
данных (нового класса) объект PersistencyClient запрашивает
320
Глава
4
-
Rational
Ro^f •ШЩШМшЯИ
ЭДЗ
0«^
Ш
Ш*^
№Ш
grows* EepoJl;
Tools
.JfijxJ
s
Jflxl
: Persistency CI lent
1:
createO
: DBClass
2:
new()
3: getDataO
5: executelJpdate(string)
: PersistentClass
4: cгeate^tatement()
Statement
Connection
il.
2Ш
Рис.
4.19. Диаграмма выполнения операции create
DBClass. DBClass создает новый объект PersistentClass и загружа-
ет в
него
данные.
Затем DBClass создает новый оператор SQL, ис-
пользуя операцию createStatement() класса Connection.
В
резуль-
тате выполнен^1я этого оператора данные помещаются в БД.
Выявле1ше подсистем
и
интерфейсов
Декомпозиция системы
на
подсистемы реализует принцип
модульности
(см.
подразд. 2.4.1). Целями такой декомпозиции
являются:
• повышение уровня абстракции системы;
• декомпозиция системы на
части,
которые могут независимо:
конфигурироваться или поставляться;