Сопоставление и взаимосвязь структурного и объектно-ориентированного подходов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ГЛАВА 3

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

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

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

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

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

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

3.1

ОСНОВНЫЕ ПОНЯТИЯ МОДЕЛИРОВАНИЯ

БИЗНЕС-ПРОЦЕССОВ

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

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

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

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

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

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

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

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

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

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

2. обеспечить понимание текущих проблем организации и возможностей их решения;

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

4. создать базу для формирования требований к будущей ИС организации.

Основная область применения бизнес-моделей — это реин­жиниринг бизнес-процессов. При этом предполагается построе­ние моделей текущей и перспективной деятельности, а также пла­на и программы перехода из первого состояния во второе. Любое современное предприятие является сложной системой, его дея­тельность включает в себя исполнение десятков тысяч взаимовлияющих функций и операций. Человек не в состоянии понимать, как такая система функционирует в деталях — это выходит за гра­ницы его возможностей. Поэтому главная идея создания моделей «AS-IS» и «AS-TO-BE» (см. подразд. 2.2) — понять, что делает (бу­дет делать) рассматриваемое предприятие и как оно функциони­рует (будет функционировать) для достижения своих целей.

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

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

Модель бизнес-процесса должна давать ответы на вопросы:

1. Какие процедуры (функции, работы) необходимо выпол­нить для получения заданного конечного результата?

2. В какой последовательности выполняются эти процедуры?

3. Какие механизмы контроля и управления существуют в рамках рассматриваемого бизнес-процесса?

4. Кто выполняет процедуры процесса?

5. Какие входящие документы/информацию использует каж­дая процедура процесса?

6. Какие исходящие документы/информацию генерирует процедура процесса?

7. Какие ресурсы необходимы для выполнения каждой про­цедуры процесса?

8. Какая документация/условия регламентирует выполнение процедуры?

9. Какие параметры характеризуют выполнение процедур и процесса в целом?

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

1. Факты - достоверные утверждения о бизнес-процессах, на­зываемых также инвариантами (оплачивается доставка каждого заказа; со стоимости доставки налог с продаж не берется).

2. Правила-ограничения — определяют различные ограниче­ния на выполняемые операции:

3. Управляющие воздействия и реакции на воздействия (когда заказ отменен и еще не доставлен, то его обработка заверша­ется).

4. Операционные ограничения — предусловия и постусловия (доставить заказ клиенту только при наличии адреса достав­ки).

5. Структурные ограничения (заказ включает по крайней мере один продукт).

6. Активаторы операций — правила, при определенных усло­виях приводящие к выполнению каких-либо действий (если срок хранения товара на складе истек, об этом надо уведо­мить ответственное лицо).

7. Правила вывода:

8. Правила-следствия — правила, устанавливающие новые факты на основе достоверности определенных условий (клиент получает положительный статус только при условии оплаты счетов в течение 30 дней).

9. Вычислительные правила — различные вычисления, выпол­няемые с использованием математических формул и алго­ритмов (цена нетто = цена продукта * (1 + процент налога / 100)).

10. Для моделирования бизнес-процессов необходимо исполь­зовать определенную методику, которая включает:

11. описание методов моделирования — способов представле­ния реальных объектов предприятия при помощи объектов модели;

12. последовательность шагов по сбору информации, ее обра­ботке и представлению в виде моделей;

13. типовые формы документов.

3.2.