Метод Буча, омт и uml

Важный вопрос визуального моделирования — выбор графической нотации для описания различных аспектов системы. Нотация должна быть понятна всем заинтересованным сторонам, иначе модель не будет полезна. Множество разработчиков предлагали свои варианты решения этого вопроса. Из них наибольшую поддержку получили метод Буча, технология объектного моделирования (ОМТ, Object Modeling Technology) и унифицированный язык моделирования (UML, Unified Modeling Language). Rational Rose 98i поддерживает все эти нотации. Однако большинством производителей и такими ко­митетами по стандартам, как ANSI и Object Management Group (OMG), был принят стандарт UML.

Метод Буча назван по имени его изобретателя, Гради Буча (Grady Booch), работающего в корпора­ции Rational Software руководителем по науке (Chief Scientist). Он написал несколько книг, в которых обсуждаются необходимость и преимущества визуального моделирования, и разработал нотацию гра­фических символов для описания различных аспектов модели.

Нотация ОМТ была разработана Джеймсом Рамбо (Dr. James Rumbaugh), написавшим несколько книг о системном анализе и проектировании. В книге "System Analysis and Design" Рамбо рассматрива­ет значимость моделирования систем с помощью компонентов реального мира, называемых объекта­ми. Предложенная им нотация ОМТ получила широкое признание, ее поддерживают такие стандартные промышленные инструменты моделирования программного обеспечения, как Rational Rose и Select ОМТ. ОМТ использует более простую графику моделирования систем по сравнению с методом Буча. Примеры объектов и связей в нотации ОМТ.

Рис. 6 Нотация UML

Унифицированный язык моделирования (UML) является результатом совместных усилий Гради Буча, Джеймса Рамбо, Ивара Якобсона (Ivar Jacobson), Ребекки Вирс-Брок (Rebecca Wirfs-Brock), Питера Йордона (Peter Yourdon) и многих других. Якобсон первым описал процесс выявления и фик­сации требований к системе в виде совокупностей транзакций, называемых вариантами использова­ния (use case). Детально мы рассмотрим варианты использования в разделе "Основы Rose" в главе 3. Якобсон также разработал метод проектирования систем под названием "Объектно-ориентирован­ное проектирование программного обеспечения" (Object Oriented Software Engineering, OOSE), кон­центрирующий внимание на анализе. Буч, Рамбо и Якобсон, о которых обычно говорят как о "трех друзьях" (three amigos), работают в корпорации Rational Software. Их деятельность связана в основ­ном со стандартизацией и усовершенствованием языка UML. Символы UML сильно напоминают но­тации Буча и ОМТ, но содержат также элементы из других нотаций. На рис. 6 показан пример нотации UML.

Планирование конструирования

Выбор метода (методологии) конструирования является ключевым аспектом для планирования конструкторской деятельности. Такой выбор значим для всей конструкторской деятельности, а также необходимых условий её осуществления, определяя порядок соответствующих операций и уровень выполнения заданных условий, перед тем как начнется конструирование или составляющие его действия. Например, модульное тестирование в ряде методов является частью работ, после написания соответствующего функционального кода, в то время, как ряд гибких (agile) практик, например, XP (кстати, первыми начавшие использовать такие методы верификации кода), требуют написания Unit-тестов до того, как пишется соответствующий код, требующий тестирования.

Используемый подход к конструированию влияет на возможность уменьшения (в идеале - минимизации) сложности, готовности к изменениям и конструировании с возможностью проверки.

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

Заметьте – не распределяют, а распределяются, подразумевая процесс, приводящий к обеспечению явной связи между задачей и ресурсами. В нечетко регламентированных и неформальных методах, таких, как XP, члены проектной группы сами принимают на себя ответственность по решению определенных задач, а “владение” кодом является совместным на основе сотрудничества, как одного из ключевых принципов работы проектной команды.

Определение результата

В процессе планирования должен быть заранее определен результат выполнения каждой задачи. То есть какие активы(артифакты) мы должны получить по выполнении следующей задачи проекта. Также необходимо оценить можно ли использовать(повторно) уже готовое решение или придется решать задачу собственными силами.

Оценка усилий и ожиданий

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

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

Распределение ресурсов

Для решения задач необходимо веделение ресурсов,а именно оборудования, средств и людей. Это подразумевает распределение обязанностей и ответственности. Ресурсы как правило ограничены. Для анализа и распределения ресурсов по задачам чаще всего используются диаграммы Ганта.

Управление рисками

Должы выполняться следующие задачи:

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

• Оценка наиболее критических рисков и выработка мер, которые позволят их избежать.

• Смягчение рисков, а также планируемость обстоятельсв, связанных с риском.

• Выработка стратегий, касающихся рисков и управление профилями рисков.

Управление планом проекта

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

План проекта реализуется в результате выполнения задач, представленных в проекте.

Реализация плана

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

Управление контрактами с поставщиками

Этот процесс включает заключение, выполнение и контроль над договорами. Реализация процесса измерения обеспечивает выявление количественных показателей полученных результатов.

Процесс мониторинга

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

Процесс контроля

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