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

Рассмотрим недостатки пакета Rational Rose в соответствии в данными, приведенными в работе [37].

Средство моделирования Rational Rose в последнее время получает все большее распространение для целей анализа деятельности предприятий. Подтверждение этому факту легко найти в Internet, проанализировав требования, которые формулируют различные компании к кандидатам на разработку информационных систем. В большинстве случаев в состав требований обязательно включается знание Rational Rose и языка моделирования UML.

Кроме того, часто приходится слышать и читать, что UML и Rational Rose являются универсальными средствами, которые вполне подходят и для моделирования бизнес-процессов. Так, на сайте компании «Интерфейс Ltd» (партнера фирмы Rational Software) приводятся следующие слова вице-президента Rational Роджера Оберга: «Rational Rose стала стандартом при разработке приложений и бизнес-моделировании». Там же, в свое время, было опубликовано следующее сообщение: «Корпорация Rational Software объявила о выходе Rational Rose 2000е – новой версии CASE-средства визуального проектирования информационных систем, позволяющего моделировать как компоненты программного обеспечения, так и бизнес-процессы». Там же опубликована статья А. Новичкова «Эффективная разработка программного обеспечения с использованием технологий и инструментов компании Rational», в конце которой приводится рекомендация: «Есть смысл приобретать AnalystStudio для проведения бизнес-моделирования. Для данных целей набор содержит все необходимое». На сайте другого партнера фирмы Rational Software, компании «АйТи», утверждается: «Rational Rose 2000 предназначено для создания сложных коммерческих приложений и корпоративных информационных систем и ориентировано на аналитиков, разработчиков архитектуры и программистов».

При этом AnalystStudio – это набор продуктов фирмы Rational Software, рекомендованный аналитикам и включающий в себя Rational Rose, как основной продукт, и Rational Unified Process, Rational Requisite PRO, Rational ClearQuest и Rational SoDA, как дополнительные.

По мнению автора работы [37], «предложение использовать Rational Rose в такой неоправданно широкой области – серьезное заблуждение. Во всяком случае, на рынке CASE-средств давно присутствуют и успешно используются инструменты, существенно лучше реализующие потребности аналитика при описании и анализе деятельности предприятия». При этом в качестве более пригодного для моделирования бизнеса инструмента называется пакет BPwin, а по поводу Rational Rose указываются следующие недостатки.

Rational Rose не поддерживает ни одну из известных методологий моделирования и анализа бизнес-процессов. Методика построения бизнес-моделей, содержащаяся в дополнительном наборе рекомендаций или методике RUP, которая сопровождает пакет Rational Rose, предлагает диаграммы вариантов использования или прецедентов (Use Case) и диаграммы деятельности (Activity) для описания бизнес-процессов. Однако эти диаграммы позволяют описать лишь малую часть сведений, которые нужны для моделирования бизнес-процессов и которые представляются, например, средствами IDEF0. Кроме того, дуги Use Case и Activity диаграмм не имеют тех смысловых типов, которые были указаны для дуг SADT.

По мнению автора работы [37], некие синтаксические соглашения, диктуемые системой при разработке Use Case и Activity-диаграмм, не объединены в законченную и понятную систему. Этим диаграммам (что, наверное, главное) не дается никакой интерпретации, объясняющей, как их применять при моделировании. Действительно, что означает, что два процесса соединены стрелкой – просто последовательность их исполнения или, например, то, что второй процесс обрабатывает некоторые (какие?) результаты деятельности первого. А может быть, наоборот, для работы первого процесса необходима некая (какая?) информация, которую подготавливает второй? Точно так же непонятно, как интерпретировать связи «процесс-состояние», «состояние-состояние» и др. Поэтому Rational Rose допускает построение синтаксически корректных Activity-диаграмм, не просто не имеющих смысла с точки зрения моделируемого объекта, но вообще не поддающихся объяснению с позиции здравого смысла [37].

По этим причинам пользователям Rational Rose при разработке Use Case и Activity-диаграмм приходится придумывать свои оригинальные синтаксические соглашения и давать свою интерпретацию имеющимся, чтобы отразить всю существенную для анализируемого процесса информацию. Например, чтобы имитировать три вида характерных для SADT входящих в процесс стрелок – вход, механизм, управление – можно каждую из них подкрашивать своим цветом, а для того, чтобы отличить входящие документы от исходящих, можно использовать пунктирные и сплошные стрелки. Другими словами, пользователь Rational Rose вынужден разрабатывать свои формализмы для получения методики построения моделей и анализа бизнес-процессов. При этом, возможно, придется не только разрабатывать свою методику, но и отклоняться от стандартов UML. Зачем это делать, если существует апробированная и признанная во всем мире IDEF0 (а также другие стандартные, средства и языки, например IDEF3), а преимущества стандартного подхода совершенно очевидны.

Даже если удастся придумать, как реализовать в Rational Rose соглашения IDEF0, или разработать свою методологию анализа бизнес-процессов, не уступающую IDEF0 и органично реализуемую в Rational Rose, то система все равно не научится «читать» разработанные модели. Дело в том, что это в ней не заложено изначально, а, следовательно, обработка и анализ моделей будут целиком на плечах аналитика. Или же придется разрабатывать свои процедуры выдачи отчетов, которые будут ориентированы на отсутствующие в стандартном UML (но имеющиеся в IDEF0) синтаксические соглашения. Но и это еще не все, поскольку не будет решена задача поддержки и контроля синтаксиса для разработанной пользователем методологии, и, следовательно, не будет никакой гарантии корректности разработанной модели.

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

Вопросы для повторения

1. В чем суть основных шагов по моделированию и анализу системы в терминах UML?

2. Что такое «прецедент»?

3. Какие существуют отношения между прецедентами?

4. Что такое «кооперация»? Что такое «взаимодействие»?

5. Какие существуют отношения между классами?

6. Что такое «сообщение»?

7. Как выглядит и для чего применяется диаграмма активности?

8. Что такое рациональный Унифицированный Процесс создания ПО? Объясните, почему РУП является итеративным и инкрементным процессом.

9. Что такое фазы РУП? Что такое рабочие процессы РУП?

10. Каковы основные цели в фазе «Исследование»?

11. Какие основные диаграммы используются в фазе «Исследование»?

12. Что такое модель анализа? Что такое модель проектирования?

13. Чем отличается объектно-ориентированный анализ от объектно-ориентированного проектирования?

14. В чем состоит суть дихотомии «интерфейс/реализация»?

15. Что такое каноническая форма представления системы?

16. Каким образом описываются структурные свойства и поведение объектов?

17. Каковы особенности объектной декомпозиции, отличающие ее от алгоритмической?

18. Чем отличаются друг от друга П-модель и О-модель организации?

19. Что такое субъект бизнес-системы и чем он отличается от актера?

20. Какие существуют CASE-средства, поддерживающие UML?


Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:  



double arrow
Сейчас читают про: