1vendrov_a_m_proektirovanie_programmnogo_obespecheniya_ekonom

Методические аспекты проектирования ПО

211

•проблема;

•решение;

•следствия.

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

Проблема — это описание решаемой задачи. Необходимо сформулировать задачу и ее контекст. Может описываться конк­ ретная проблема проектирования, например способ представле­ ния алгоритмов в виде объектов. Также может включаться пере­ чень условий, при выполнении которых имеет смысл применять данный образец.

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

Следствия — это описание области применения, достоинств и недостатков образца. Хотя при описании проектных решений о следствиях часто не упоминают, знать о них необходимо, чтобы можно было выбрать между различными вариантами и оценить преимущества и недостатки применения данного образца. Пос­ кольку в объектно-ориентированном проектировании повторное использование зачастую является важным фактором, то к резуль­ татам следует относить и влияние на степень гибкости, расширя­ емости и переносимости системы.

Образцы могут рассматриваться на различных уровнях абстракции и в различных предметных областях. Наиболее общи­ ми категориями образцов ПО являются:

•образцы бизнес-моделирования;

•образцы анализа;

•образцы поведения;

•образцы проектирования;

•архитектурные образцы;

•образцы профаммирования.

212

Глава 2

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

описание взаимодействия объектов и классов, адаптированных решения обшей задачи проектирования в конкретном контексте

В языке и ML образец представляется с помощью коопера­ ции со стереотипом «pattern». Кооперация (collaboration) опреде­ ляется как описание совокупности взаимодействующих объек­ тов, реализующих некоторое поведение (например, в рамках ва­ рианта использования или операции класса). Кооперация имеет статическую и динамическую части. В статической части (на ди­ аграмме классов) описываются роли, которые могут ифать объ­ екты и связи в экземпляре данной кооперации. Динамическая часть состоит из одной или более диафамм взаимодействия, по­ казывающих потоки сообщений, которыми обмениваются участники кооперации. Кроме того, любой образец содержит стандартную диаграмму классов под названием «Participants» («Участники»), на которой изображается сам образец в виде ко­ операции с его именем и набор классов, участвующих в реализа­ ции образца.

В качестве примера приведем образец бизнес-моделирования под названием Employment (Занятость).

Проблема заключается в моделировании различных форм за­ нятости в пределах организации. Данная задача решается в кон­ тексте системы планирования ресурсов предприятия.

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

На рис. 2.60 приведена диафамма «Участники» для данного образца. Она содержит кооперацию Employment и набор из пяти классов.

•Employee Profile (Служащий) — описание служащего с набо­ ром атрибутов.

•Organization Profile (Организация) - описание самой орга­ низации.

•Employment (Занятость) — описание связи между служащим

иорганизацией.

Методические аспекты проектирования ПО

213

•Position (Должность) — описание должности со своими ат­ рибутами (такими, как должностной оклад и должностные инструкции).

•Position Assignment (Назначение на должность) — описание связи между служащим и занимаемыми должностями.

-^ RationaJ R o s e : * ^ b W i ^ t t e » ^ n | ^ i i ' ^ ^ i ; J ? « ^ ^ ^ ^

[ ф» £dJt Jgew t^msA	Ifowsu 1^<чроЛ
	MM
	«business entity»
	Employment
«business entity»	«business entity»
Employee Profile	Organization Profile

«business entity»	«pattern»	«business entity»
	Employment
Position		Position Assignment
Ы		Ш

Рис. 2.60. Диаграмма «Участники» для образца Employment

Статическая часть образца (диафамма классов) показана на рис. 2.61.

Достоинства применения образцов при проектировании ПО заключаются в следующем:

•Возможность многократного использования. Повторное пользование решений из уже завершенных успешных про­ ектов позволяет быстро приступить к решению новых проб­ лем и избежать типичных ошибок. Разработчик получает прямую выгоду от использования опыта других разработчи­ ков, избежав необходимости вновь и вновь «изобретать ве­ лосипед».

•Применение единой терминологии. Профессиональное общ ние и работа в группе (команде разработчиков) требует на­ личия единого базового словаря и единой точки зрения на

214	Глава 2
•%^ Rationar R6se:iM^^^^i)!f М Ш Ш Ш Ш Ш Ш Ш
i В1« 6Л 8ew f»m<)t Efw»« Ейхи* ^ w	loeb Ш-tm Stentew ИяЬ

«business entity» Employee Profile

(from Participating Business Entities)

Name

Address

Birthdate

+profiIe

/1..П

«business entity»		Organization Profile
Employment	1..П	(from Participating Business Entities)
(from Participating Business Entities)		-Name
- Start date		-Address
- End date
		-Purpose
+based on		+responslble
employment
		for position	1..П
«business entity»	1..П	«business entity»		1
Position Assignment		Position
(from Participating Business Entities)		(from Participating Business Entities) |

Рис. 2.61. Статическая часть образца Employment

проблему Образцы предоставляют подобную общую точку зрения как на этапе анализа, так и при реализации проекта.

•Повышение эффективности труда отдельных исполнителей всей группы в целом. Это происходит из-за того, что начина­ ющие члены группы видят на примере более опытных раз­ работчиков, как образцы проектирования могут применять­ ся и какую пользу они приносят. Совместная работа дает но­ вичкам стимул и реальную возможность быстрее изучить и освоить эти новые концепции.

•Создание модифицируемого и гибкого ПО. Причина состоит в том, что образцы уже испытаны временем, поэтому их ис-

Методические аспекты проектирования ПО

215

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

• Ограничение пространства решений. Использование образ­ цов создает границы в рамках пространства решений проек­ тирования и реализации. Таким образом, образец настоя­ тельно рекомендует проектировщику границы, которых должна придерживаться реализация. Выход за эти границы нарушает строгое соблюдение образца и проектных реше­ ний и может привести к нежелательным последствиям. Тем не менее, образцы не подавляют творчество. Напротив, они описывают структуру или форму на некотором уровне абстракции. Проектировщики и разработчики все еще рас­ полагают многими возможностями для реализации образ­ цов в этих фаницах.

2.7. СОПОСТАВЛЕНИЕ И ВЗАИМОСВЯЗЬ СТРУКТУРНОГО И ОБЪЕКТНООРИЕНТИРОВАННОГО ПОДХОДОВ

Традиционно, до недавнего времени, у большинства разра­ ботчиков понятие «проектирование» ассоциировалось со струк­ турным проектированием по методу «сверху вниз» на основе функциональной декомпозиции, согласно которой вся система в целом представляется как одна большая функция и разбивается на подфункции, которые в свою очередь разбиваются на под­ функции и т.д. Эти функции подобны вариантам использования в объектно-ориентированной системе, которые соответствуют действиям, выполняемым системой в целом.

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

В ООП основная категория объектной модели — класс — объ­ единяет в себе на элементарном уровне как данные, так и опера­ ции, которые над ними выполняются. Именно с этой точки зре­ ния изменения, связанные с переходом от структурного подхода к ООП, являются наиболее заметными. Разделение процессов и

216

Глава 2

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

Поскольку данные по сравнению с процессами являются бо­ лее стабильной и относительно редко изменяющейся частью сис­ темы, отсюда следует главное достоинство ООП. Гради Буч сфор­

мулировал его следующим образом: объектно-ориентированные

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

Буч отметил также ряд следующих преимуществ ООП:

• объектная декомпозиция дает возможность создавать прог­ раммные системы меньшего размера путем использования общих механизмов, обеспечивающих необходимую эконо­ мию выразительных средств. Использование ООП сущест­ венно повышает уровень унификации разработки и пригод­ ность для повторного использования не только ПО, но и проектов, что в конце концов ведет к сборочному созданию ПО. Системы зачастую получаются более компактными, чем их не объектно-ориентированные эквиваленты, что оз­ начает не только уменьшение объема профаммного кода, но и удешевление проекта за счет использования предыду­ щих разработок;

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

•объектная модель вполне естественна, поскольку в первую очередь ориентирована на человеческое восприятие мира, а не на компьютерную реализацию;

•объектная модель позволяет в полной мере использовать выразительные возможности объектных и объектно-ориен­ тированных языков профаммирования.

К недостаткам ООП относятся некоторое снижение произво­ дительности функционирования ПО (которое, однако, по мере роста производительности компьютеров становится все менее за-

Методические аспекты проектирования ПО

217

метным) и высокие начальные затраты. Объектная декомпози­ ция существенно отличается от функциональной, поэтому пере­ ход на новую технологию связан как с преодолением психологи­ ческих трудностей, так и дополнительными финансовыми затра­ тами. При переходе от структурного подхода к объектному, как при всякой смене технологии, необходимо вкладывать деньги в приобретение новых инструментальных средств. Здесь следует учесть расходы на обучение методу, инструментальным средствам и языку профаммирования. Для некоторых организаций эти об­ стоятельства могут стать серьезными препятствиями.

Объектно-ориентированный подход не дает немедленной от­ дачи. Эффект от его применения начинает сказываться после разработки двух-трех проектов и накопления повторно использу­ емых компонентов, отражающих типовые проектные решения в данной области. Переход организации на объектно-ориентиро­ ванную технологию — это смена мировоззрения, а не просто изу­ чение новых CASE-средств и языков программирования.

Таким образом, структурный подход по-прежнему сохраняет свою значимость и достаточно широко используется на практике. На примере языка UML хорошо видно, что его авторы заимство­ вали то рациональное, что можно было взять из структурного подхода: элементы функциональной декомпозиции в диаграммах вариантов использования, диаграммы состояний, диафаммы де­ ятельности и др. Очевидно, что в конкретном проекте сложной системы невозможно обойтись только одним способом декомпо­ зиции. Можно начать декомпозицию каким-либо одним спосо­ бом, а затем, используя полученные результаты, попытаться рас­ смотреть систему с другой точки зрения.

Теперь рассмотрим взаимосвязь между структурным и объ­ ектно-ориентированным подходами. Основой взаимосвязи явля­ ется общность ряда категорий и понятий обоих подходов (про­ цесс и вариант использования, сущность и класс и др.). Эта взаи­ мосвязь может проявляться в различных формах. Так, одним из возможных вариантов является использование структурного ана­ лиза как основы для объектно-ориентированного проектирова­ ния. При этом структурный анализ следует прекращать, как толь­ ко структурные модели начнут отражать не только деятельность организации (бизнес-процессы), а и систему ПО. После выпол­ нения структурного анализа можно различными способами приступить к определению классов и объектов. Так, если взять

218 Глава 2

какую-либо отдельную диаграмму потоков данных, то кандидата­ ми в классы могут быть элементы структур данных.

Другой формой проявления взаимосвязи можно считать интег­ рацию объектной и реляционной технологий. Реляционные СУБД являются на сегодняшний день основным средством реализации крупномасштабных баз данных и хранилищ данных. Причины этого достаточно очевидны: реляционная технология используется достаточно долго, освоена офомным количеством пользователей и разработчиков, стала промышленным стандартом, в нее вложе­ ны значительные средства и создано множество корпоративных БД в самых различных отраслях, реляционная модель проста и имеет строгое математическое основание; существует большое разнообразие промышленных средств проектирования, реализа­ ции и эксплуатации реляционных БД. Вследствие этого реляцион­ ные БД в основном используются для хранения и поиска объектов в так называемых объектно-реляционных системах.

Объектно-ориентированное проектирование имеет точки соприкосновения с реляционным проектированием. Например, как было отмечено выше, классы в объектной модели могут неко­ торым образом соответствовать сущностям (в качестве упражне­ ния можно предложить детально проанализировать все сходства и различия диаграмм «сущность-связь» и диаграмм классов). Как правило, такое соответствие имеет место только на ранней ста­ дии разработки системы. В дальнейшем, разумеется, цели объ­ ектно-ориентированного проектирования (адекватное модели­ рование предметной области в терминах взаимодействия объек­ тов) и разработки реляционной БД (нормализация данных) рас­ ходятся. Таким образом, единственно возможным средством пре­ одоления данного разрыва является построение отображения между объектно-ориентированной и реляционной технология­ ми, которое в основном сводится к отображению между диаграм­ мами классов и реляционной моделью.

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

! Следует запомнить

1.Главным способом преодоления сложности разработки больших систем ПО является правильная декомпозиция.

Методические аспекты проектирования ПО

219

2.Сущность структурного подхода к разработке ПО заключа­ ется в его декомпозиции (разбиении) в соответствии с вы­ полняемыми функциями.

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

v^ Основные понятия

Модель, архитектура.

Внешняя сущность, процесс, накопитель данных, поток дан­ ных, сущность, связь, атрибут.

Класс, объект, абстрагирование, инкапсуляция, модульность, иерархия, наследование, вариант использования, действующее лицо, компонент, интерфейс.

Стереотип, образец, кооперация.

?Вопросы для самоконтроля

1.В чем заключаются основные принципы структурного под­ хода?

2.Что общего и в чем различия между методом SADT и моде­ лированием потоков данных?

3.В чем заключаются достоинства и недостатки структурного подхода?

4.В чем заключаются основные принципы объектно-ориен­ тированного подхода?

5.В чем состоят достоинства и недостатки объектно-ориен­ тированного подхода?

6.Чем язык UML принципиально отличается от моделей SADT, DFD и ERM?

7.Каковы принципиальные различия и что общего между структурным и объектно-ориентированным подходами?

МОДЕЛИРОВАНИЕ БИЗНЕСПРОЦЕССОВ И СПЕЦИФИКАЦИЯ ТРЕБОВАНИЙ

Прочитав эту главу, вы узнаете:

•Что представляет собой моделирование бизнес-процессов и с цификация требований к ПО.

•В чем заключается структурный (процессный) подход к модели ванию бизнес-процессов.

•В чем заключается объектно-ориентированный подход к моде рованию бизнес-процессов и спецификации требований.

3.1 ОСНОВНЫЕ ПОНЯТИЯ МОДЕЛИРОВАНИЯ БИЗНЕС-ПРОЦЕССОВ

Моделирование бизнес-процессов является важной состав­ ной частью проектов по созданию крупномасштабных систем ПО. Отсутствие таких моделей является одной из главных при­ чин неудач многих проектов.

Бизнес-процесс определяется как логически завершенный на­ бор взаимосвязанных и взаимодействующих видов деятельности, поддерживающий деятельность организации и реализующий ее политику, направленную на достижение поставленных целей. Международный стандарт ISO 9000 определяет организацию как группу работников и необходимых средств с распределением от­ ветственности, полномочий и взаимоотношений. По-другому организацию можно определить как систематизированное, соз­ нательное объединение действий людей, преследующих дости­ жение конкретных целей. Организация может быть корпоратив­ ной, государственной или частной.