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

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

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

• проблема;

• решение;

• следствия.

Сославшись на

имя

образца,

можно сразу описать проблему

проектирования, ее решения и их последствия. Присваивание

образцам имен позволяет проектировать на более высоком уров-

не абстракции. С помощью словаря образцов можно вести об-

суждение с коллегами, упоминать образцы в документации, в

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

Проблема

—

это описание решаемой задачи. Необходимо

сформулировать задачу и ее контекст. Может описываться конк-

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

ния алгоритмов в виде объектов. Также может включаться пере-

чень условий, при выполнении которых имеет смысл применять

данный образец.

Решение

- это описание элементов проектного решения, свя-

зей между ними и функций каждого элемента. Конкретное реше-

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

—

это

шаблон, применимый

самых разных ситуациях. Обычно дается

абстрактное описание задачи проектирования

того,

как она мо-

жет быть решена с помощью некоего весьма обобщенного соче-

тания элементов (классов и объектов).

Следствия —

это описание области применения, достоинств и

недостатков образца. Хотя при описании проектных решений о

следствиях часто не упоминают, знать о них необходимо, чтобы

можно было выбрать между различными вариантами и оценить

преимущества и недостатки применения данного образца. Пос-

кольку

объектно-ориентированном проектировании повторное

использование зачастую является важным фактором, то к резуль-

татам следует относить и влияние на степень гибкости, расширя-

емости и переносимости системы.

Образцы могут рассматриваться на различных уровнях

абстракции

и в

различных предметных

областях.

Наиболее общи-

ми категориями образцов ПО являются:

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

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

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

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

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

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

212 Глава 2

Даже в этом кратком списке категорий присутствует большое

количество уровней абстракции и ортогональных систем класси-

фикации. Например, под образцом проектирования понимается

описание взаимодействия объектов

классов,

адаптированных для

решения обшей задачи проектирования

конкретном

контексте.

В языке и ML образец представляется с помощью коопера-

ции со стереотипом «pattern».

Кооперация

(collaboration) опреде-

ляется как описание совокупности взаимодействующих объек-

тов,

реализующих некоторое поведение (например, в рамках ва-

рианта использования или операции класса). Кооперация имеет

статическую

динамическую части.

статической части (на ди-

аграмме классов) описываются роли, которые могут ифать объ-

екты и связи в экземпляре данной кооперации. Динамическая

часть состоит из одной или более диафамм взаимодействия, по-

казывающих потоки сообщений, которыми обмениваются

участники кооперации. Кроме того, любой образец содержит

стандартную диаграмму классов под названием «Participants»

(«Участники»), на которой изображается сам образец в виде ко-

операции с его именем и набор классов, участвующих

реализа-

ции образца.

качестве примера приведем образец бизнес-моделирования

под названием Employment (Занятость).

Проблема

заключается в моделировании различных форм за-

нятости в пределах организации. Данная задача решается в кон-

тексте системы планирования ресурсов предприятия.

Решение:

занятость моделируется как контракт между лич-

ностью и организацией, указывающий выполняемые обязаннос-

ти,

контрактные условия, даты начала и конца работы. Личность

характеризуется набором атрибутов (имя, адрес

и дата

рождения),

может занимать более чем

одну

должность

одной

той же орга-

низации.

На рис. 2.60 приведена диафамма «Участники» для данного

образца. Она содержит кооперацию Employment и набор из пяти

классов.

• Employee Profile (Служащий)

—

описание служащего с набо-

ром атрибутов.

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

низации.

• Employment (Занятость)

—

описание связи между служащим

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

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

213

• Position (Должность)

—

описание должности со своими ат-

рибутами (такими, как должностной оклад и должностные

инструкции).

• Position Assignment (Назначение на должность)

—

описание

связи между служащим и занимаемыми должностями.

-^ RationaJ Rose:*^bWi^tte»^n|^ii'^^i;J?«^^^^

[ ф» £dJt Jgew

t^msA

Ifowsu

1^<чроЛ

«business entity»

Employment

«business entity»

Employee Profile

«business entity»

Position

«pattern»

Employment

«business entity»

Organization Profile

«business entity»

Position Assignment

Рис.

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

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

рис.

2.61.

Достоинства применения образцов при проектировании ПО

заключаются в следующем:

•

Возможность многократного

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

Повторное ис-

пользование решений из уже завершенных успешных про-

ектов позволяет быстро приступить

решению новых проб-

лем и избежать типичных ошибок. Разработчик получает

прямую выгоду от использования опыта других разработчи-

ков,

избежав необходимости вновь и вновь «изобретать ве-

лосипед».

•

Применение единой

терминологии.

Профессиональное обще-

ние и работа в группе (команде разработчиков) требует на-

личия единого базового словаря и единой точки зрения на

214

Глава 2

•%^

Rationar R6se:iM^^^^i)!f МШШШШШШШ

В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»

Employment

(from Participating Business Entities)

- Start date

- End date

+based on

employment

«business entity»

Position Assignment

(from Participating Business Entities)

1..П

Organization Profile

(from Participating Business Entities)

-Name

-Address

-Purpose

+responslble

for position

1..П

«business entity» 1

Position

(from Participating Business Entities) |

Рис.

2.61.

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

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

зрения как на этапе анализа, так и при реализации проекта.

•

Повышение эффективности труда отдельных исполнителей

всей группы

целом.

Это происходит из-за того, что начина-

ющие члены группы видят на примере более опытных раз-

работчиков, как образцы проектирования могут применять-

ся

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

вичкам стимул и реальную возможность быстрее изучить и

освоить эти новые концепции.

•

Создание модифицируемого

гибкого

ПО.

Причина состоит в

том, что образцы уже испытаны временем, поэтому их ис-

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

пользование позволяет создавать структуры, допускающие

модификацию в большей степени, чем это возможно в слу-

чае решения, первым пришедшего на ум.

•

Ограничение пространства

решений.

Использование образ-

цов создает границы

рамках пространства решений проек-

тирования и реализации. Таким образом, образец настоя-

тельно рекомендует проектировщику границы, которых

должна придерживаться реализация. Выход за эти границы

нарушает строгое соблюдение образца и проектных реше-

ний и может привести к нежелательным последствиям. Тем

не менее, образцы не подавляют

творчество.

Напротив, они

описывают структуру или форму на некотором уровне

абстракции. Проектировщики и разработчики все еще рас-

полагают многими возможностями для реализации образ-

цов в этих фаницах.

2.7.

СОПОСТАВЛЕНИЕ И ВЗАИМОСВЯЗЬ

СТРУКТУРНОГО И ОБЪЕКТНО-

ОРИЕНТИРОВАННОГО ПОДХОДОВ

Традиционно, до недавнего времени, у большинства разра-

ботчиков понятие «проектирование» ассоциировалось со струк-

турным проектированием по методу «сверху вниз» на основе

функциональной декомпозиции, согласно которой вся система в

целом представляется как одна большая функция и разбивается

на подфункции, которые в свою очередь разбиваются на под-

функции и т.д. Эти функции подобны вариантам использования

в объектно-ориентированной системе, которые соответствуют

действиям, выполняемым системой в целом.

Главный недостаток структурного проектирования заключа-

ется в следующем: процессы

данные существуют отдельно друг

от

друга,

причем проектирование ведется от процессов

данным.

Таким образом, помимо функциональной декомпозиции, суще-

ствует также структура данных, находящаяся на втором плане.

ООП основная категория объектной модели

—

класс

—

объ-

единяет в себе на элементарном уровне как

данные,

так и опера-

ции, которые над ними выполняются. Именно с этой точки зре-

ния изменения, связанные с переходом от структурного подхода

к ООП, являются наиболее заметными. Разделение процессов и

216 Глава 2

данных преодолено, однако остается проблема преодоления

сложности системы, которая решается путем использования ме-

ханизма пакетов.

Поскольку данные по сравнению с процессами являются бо-

лее стабильной

относительно редко изменяющейся частью сис-

темы, отсюда следует главное достоинство ООП. Гради Буч сфор-

мулировал его следующим образом:

объектно-ориентированные

системы более открыты

легче поддаются внесению

изменений^

поскольку их конструкция базируется на устойчивых

формах.

Это

дает возможность

системе

развиваться постепенно и не приводит

к полной ее переработке даже в случае существенных изменений

ис-

ходных

требований.

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

• объектная декомпозиция дает возможность создавать прог-

раммные системы меньшего размера путем использования

общих механизмов, обеспечивающих необходимую эконо-

мию выразительных средств. Использование ООП сущест-

венно повышает уровень унификации разработки и пригод-

ность для повторного использования не только ПО, но и

проектов, что в конце концов ведет

сборочному созданию

ПО.

Системы зачастую получаются более компактными,

чем их не объектно-ориентированные эквиваленты, что оз-

начает не только уменьшение объема профаммного кода,

но и удешевление проекта за счет использования предыду-

щих разработок;

• объектная декомпозиция уменьшает риск создания слож-

ных систем ПО, так как она предполагает эволюционный

путь развития системы на базе относительно небольших

подсистем. Процесс интеграции системы растягивается на

все время разработки, а не превращается в единовременное

событие;

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

очередь ориентирована на человеческое восприятие мира, а

не на компьютерную реализацию;

• объектная модель позволяет в полной мере использовать

выразительные возможности объектных и объектно-ориен-

тированных языков профаммирования.

К недостаткам ООП относятся некоторое снижение произво-

дительности функционирования ПО (которое, однако, по мере

роста производительности компьютеров становится все менее за-

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

метным) и высокие начальные затраты. Объектная декомпози-

ция существенно отличается от функциональной, поэтому пере-

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

ческих трудностей, так

дополнительными финансовыми затра-

тами. При переходе от структурного подхода к объектному, как

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

приобретение новых инструментальных средств. Здесь следует

учесть

расходы на обучение методу, инструментальным средствам

и языку профаммирования. Для некоторых организаций эти об-

стоятельства могут стать серьезными препятствиями.

Объектно-ориентированный подход не дает немедленной от-

дачи. Эффект от его применения начинает сказываться после

разработки двух-трех проектов

накопления повторно использу-

емых компонентов, отражающих типовые проектные решения в

данной области. Переход организации на объектно-ориентиро-

ванную технологию

—

это смена мировоззрения, а не просто изу-

чение новых CASE-средств и языков программирования.

Таким образом, структурный подход по-прежнему сохраняет

свою значимость

достаточно широко используется на практике.

На примере языка UML хорошо видно, что его авторы заимство-

вали то рациональное, что можно было взять из структурного

подхода: элементы функциональной декомпозиции

диаграммах

вариантов использования, диаграммы состояний, диафаммы де-

ятельности и др. Очевидно, что в конкретном проекте сложной

системы невозможно обойтись только одним способом декомпо-

зиции. Можно начать декомпозицию каким-либо одним спосо-

бом, а затем, используя полученные результаты, попытаться рас-

смотреть систему

другой точки зрения.

Теперь рассмотрим взаимосвязь между структурным и объ-

ектно-ориентированным подходами. Основой взаимосвязи явля-

ется общность ряда категорий и понятий обоих подходов (про-

цесс и вариант использования, сущность

класс

др.).

Эта взаи-

мосвязь может проявляться в различных формах. Так, одним из

возможных вариантов является использование структурного ана-

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

ния. При этом структурный анализ следует прекращать, как

толь-

ко структурные модели начнут отражать не только деятельность

организации (бизнес-процессы), а и систему ПО. После выпол-

нения структурного анализа можно различными способами

приступить к определению классов и объектов. Так, если взять

218 Глава 2

какую-либо

отдельную

диаграмму

потоков

данных,

то кандидата-

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

Другой формой проявления взаимосвязи можно считать интег-

рацию объектной

реляционной

технологий.

Реляционные СУБД

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

крупномасштабных баз данных и хранилищ данных. Причины

этого достаточно

очевидны:

реляционная технология используется

достаточно долго, освоена офомным количеством пользователей

и разработчиков, стала промышленным стандартом, в нее вложе-

ны значительные средства и создано множество корпоративных

БД в самых различных отраслях, реляционная модель проста и

имеет строгое математическое основание; существует большое

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

ции

эксплуатации реляционных

БД.

Вследствие

этого

реляцион-

ные БД

основном используются

для

хранения и поиска объектов

в так называемых объектно-реляционных системах.

Объектно-ориентированное проектирование имеет точки

соприкосновения с реляционным проектированием. Например,

как

было

отмечено выше, классы

объектной модели могут неко-

торым образом соответствовать сущностям (в качестве упражне-

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

и различия диаграмм «сущность-связь»

диаграмм классов). Как

правило, такое соответствие имеет место только на ранней ста-

дии разработки системы. В дальнейшем, разумеется, цели объ-

ектно-ориентированного проектирования (адекватное модели-

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

тов) и разработки реляционной БД (нормализация данных) рас-

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

одоления данного разрыва является построение отображения

между объектно-ориентированной и реляционной технология-

ми,

которое

основном сводится к отображению

между

диаграм-

мами классов и реляционной моделью.

Взаимосвязь между структурным и объектно-ориентирован-

ным подходами достаточно четко просматривается в методиках

анализа и проектирования, которые будут рассмотрены в после-

дующих главах.

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

Главным способом преодоления сложности разработки

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

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

Сущность структурного подхода к разработке ПО заключа-

ется в его декомпозиции (разбиении) в соответствии с вы-

полняемыми функциями.

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

ботке ПО заключается в объектной декомпозиции. При

этом статическая структура системы описывается в терми-

нах объектов и связей между ними, а поведение системы

описывается в терминах обмена сообщениями между объ-

ектами.

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

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

Внешняя сущность, процесс, накопитель данных, поток дан-

ных, сущность, связь, атрибут.

Класс, объект, абстрагирование, инкапсуляция, модульность,

иерархия, наследование, вариант использования, действующее

лицо,

компонент, интерфейс.

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

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

чем заключаются основные принципы структурного под-

хода?

Что общего и

чем различия между методом SADT и моде-

лированием потоков данных?

чем заключаются достоинства

недостатки структурного

подхода?

В чем заключаются основные принципы объектно-ориен-

тированного подхода?

В чем состоят достоинства и недостатки объектно-ориен-

тированного подхода?

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

SADT, DFD и ERM?

Каковы принципиальные различия и что общего между

структурным и объектно-ориентированным подходами?

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

ПРОЦЕССОВ И СПЕЦИФИКАЦИЯ

ТРЕБОВАНИЙ

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

•

Что представляет собой моделирование бизнес-процессов

и спе-

цификация требований

ПО.

•

В чем заключается структурный (процессный)

подход к моделиро-

ванию

бизнес-процессов.

• В

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

модели-

рованию бизнес-процессов и спецификации

требований.

3.1

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

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

Моделирование бизнес-процессов является важной состав-

ной частью проектов по созданию крупномасштабных систем

ПО.

Отсутствие таких моделей является одной из главных при-

чин неудач многих проектов.

Бизнес-процесс определяется как логически завершенный на-

бор взаимосвязанных и взаимодействующих видов деятельности,

поддерживающий деятельность организации и реализующий ее

политику, направленную на достижение поставленных целей.

Международный стандарт ISO 9000 определяет

организацию

как

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

ветственности, полномочий и взаимоотношений. По-другому

организацию можно определить как систематизированное, соз-

нательное объединение действий людей, преследующих дости-

жение конкретных целей. Организация может быть корпоратив-

ной, государственной или частной.