На чем основана работа программы

Итак, от общих тем перейдем непосредственно к тому, что умеет делать CASE Rational Rose. Являясь объектно-ориентированным инструментом моделирования, Rose базируется на UML (Universal Modeling Language) - универсальном языке моделирования, который был разработан компанией Rational именно с целью создания наиболее оптимального и универсального языка для описания как предметной области, так и конкретной задачи в программировании. Любая задача программируется при помощи определенных диаграмм. UML поддерживает построение следующих диаграмм:

• Activity diagram (диаграммы описаний технологий, процессов, функций).
• Use case diagram (диаграммы функций).
• Class diagram (диаграммы классов).
• State diagram (диаграммы состояний);
• Sequence diagram (диаграммы последовательностей действий);
• Collaboration diagram (диаграммы взаимодействий
• Component diagram (диаграммы компонент);
• Deployment diagram (диаграммы топологии).

Соответственно, Rational Rose 2000 является инструментом, который позволяет строить указанные диаграммы при проектировании программных систем. К сожалению, объем статьи не позволяет описать назначение всех диаграмм и спецификаций! Но мы попробуем разобраться в инструменте с точки зрения разработчика, для простоты используя только один тип диаграмм - Class Diagramm.

Все разработчики сталкиваются с ситуацией, когда приходится проектировать большие классы. При ручном вводе и объявлении имеется ряд подводных камней: во-первых, постановщик задач, как правило, описывает "что нужно" на словах, в крайнем случае, с минимальным бумажным сопровождением; во-вторых, разработчик, создающий систему, опять-таки в большинстве случаев игнорирует все комментарии, которыми необходимо сопровождать программный код. Что же получается в итоге? Постановщик задач путается в программе, разработчик сам не помнит, что к чему, а если на его место взят новый сотрудник: Тут на ум приходит еще одно традиционное для России высказывание разработчика: "мне проще все написать заново". И ведь пишут: Тормозя производство программного продукта. Дело в том, что к разработке ПО относятся как к искусству, а необходимо относиться, как к производственному процессу со строгим распределением ролей, полномочий и пр: