1vendrov_a_m_proektirovanie_programmnogo_obespecheniya_ekonom
.pdfАнализ и проектирование программного обеспечения |
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
«entity» Student
name address studentID
//add scheduieQ
//get scheduieQ
//delete scheduieQ
//has prerequisitesQ
«entity» Schedule
semester
grow^e Report ^u^ty Tools .
«entity» CourseOffering
number : String = "100" startTime : Time endTime : Time
days: Enum
/ numStudents: Int
//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 |
«entity» |
|
|
name |
|
|
|
|
Schedule |
0..П |
|
address |
1 |
0..П |
|
IstudentlD |
|
||
|
0..П |
|
|
5 |
|
salternateCourses |
|
|
|
||
|
•^pnma |
|
|
|
|
|
|
|
|
|
0..2 |
«entity» |
|
«entity» |
«entity» |
FulltlmeStudent |
|
ParttlmeStudent |
CourseOffering |
(from Analysis Model) |
|
Jfro rn Anal ysi^ Model) |
|
- gradDate |
- maxNumCourses |
|
|
Рис. 4.15. Диаграмма классов-сущностей
более четырех курсов) и альтернативного (не более двух курсов). К классу Student добавлены два новых подкласса — FulltimeStudent (студент очного отделения) и ParttlmeStudent (студент вечернего отделения).
На рис. 4.16 показаны ассоциации-классы, представляющие свойства связей между классами Schedule и CourseOffering. Ассо циация, связывающая график и альтернативный курс, имеет только один атрибут — статус курса в конкретном графике (sta tus), который может принимать значения «включен в фафик», «отменен», «внесен в список курса» и «зафиксирован в графике». Если курс в процессе закрытия регистрации переходит из аль тернативного в основные, то к соответствующей ассоциации до бавляется атрибут «оценка» (grade). Таким образом, ассоциациякласс PrimaryScheduleOfferinglnfo наследует свойства ассоциа ции-класса ScheduleOfferinglnfo (атрибуты и операции, содержа щиеся в этом классе, относятся как к основным, так и к альтер нативным курсам) и добавляет свои собственные (оценка и окончательное включение курса в график могут иметь место только для основных курсов), что и показано с помощью связи обобщения.
Анализ и проектирование программного обеспечения |
3 1 5 |
^ Rationalftdse::!Шиг^1ШММ|Яв^
Idft iew? fgrmat irowse Export jQtuery loote
« e n t i t y » PrimaryScheduleOfferinglnfo
grade
//Is enrolled in?0
//mark as enrolled InQ
//mark as committedQ
\ +primaryCourses
« e n t i t y » 0..П |
|
Schedule |
0..4 |
|
^tM-lns №dow
MM
« e n t i t y » Course Offering
0..П -^-„^^Ite rnate Cou rses
/ 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» |
|
«boundaiy» |
|
Registration Controller |
Course CatalogSystem |
||
|
|
0..П |
|
|
|
|
0..1 |
|
|
|
0..1 |
|
|
-•-curretrtSchedule |
|
|
|
0..1 |
|
«entity» |
|
|
«entity» |
Student |
4^ |
|
Schedule |
|
0..П |
Каталог курсов |
|
|
1 |
(from Use Case Mc ) |
|
|
|
0..П |
|
^prlma/yCourses 0..4
«entity»
CourseOffering +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^ |
п^< |
« r o l e » PersistencyClient
(from SamplePersistenpy Client)
« r o l e »
Pe rsiste ntCI assL ist
(from Sample Persistent CI ass)
+ newO
* add(c : Re rsiste ntCIass)
"~7^
« r o l e » |
1 |
|
|
DBCIass |
|
0..П
+ere ate 0 : Pe rsistentCI ass
*read (search Criteria : string): Pe rsiste ntCiassList
+update(c : Persiste ntCI ass)
+delete (c : Pe rsiste ntCI ass)
-i>-
ResuitSet
« r o l e »
Persiste ntCI ass
(from Sample Persistent CI ass)
getDataQ setDataQ commando newQ
(from Java sql) |
|
|
|
_ 2 ^ |
|
getStringO: string |
DriverManager |
|
I T |
(from Java sql) |
|
+ getConnection(url, user, pas^ : Connection |
||
|
||
Statement |
|
|
(from Java sql) |
|
|
executeQuery(sqi: string): ResultSet |
|
|
executeUpdate(sql: string) : int |
|
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 запрашивает
3 2 0 |
|
Глава 4 |
- Rational R o ^ f • Ш Щ Ш М ш Я И |
.JfijxJ |
|
ЭДЗ 0«^ |
grows* EepoJl; |
Toolss |
Ш Ш*^ № Ш |
Jflxl |
|
|
|
|
:PersistencyCIlent
1:createO
: DBClass |
2: new() |
|
3: getDataO |
||
|
: PersistentClass
4:cгeate^tatement()
5:executelJpdate(string)
Statement Connection
il. |
2Ш |
Рис. 4.19. Диаграмма выполнения операции create
DBClass. DBClass создает новый объект PersistentClass и загружа ет в него данные. Затем DBClass создает новый оператор SQL, ис пользуя операцию createStatement() класса Connection. В резуль тате выполнен^1я этого оператора данные помещаются в БД.
Выявле1ше подсистем и интерфейсов
Декомпозиция системы на подсистемы реализует принцип модульности (см. подразд. 2.4.1). Целями такой декомпозиции являются:
•повышение уровня абстракции системы;
•декомпозиция системы на части, которые могут независимо: конфигурироваться или поставляться;