Рассмотрим недостатки пакета 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?