Диаграммы классов UML. Логическое моделирование

Логическое  моделирование компонентов

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

  
Рис.1. Логическая модель компонента.  
На диаграмме показаны два интерфейса, имеющиеся у компонента. Для стереотипа <> возможно использование стандартного графического изображения. В этом случае отношение реализации показывается в виде линии. Оба интерфейса реализуются классом «Управление счетами», который имеет также внутренние (закрытые) операции проверки (CheckPassword и CheckPermission).

Моделирование взаимодействия компонентов

При моделировании  взаимодействия удобно изображать компоненты в виде пакетов и показывать их интерфейсы (см. рис.2).

  
Рис.2. Диаграмма классов, показывающая взаимодействие компонент

Диаграммы компонентов

На диаграммах компонентов  показывается физическое разбиение  ПС на компоненты и другие программные  блоки, а также отношения зависимости  между ними. Можно, используя пакеты для обозначения узлов многозвенной ПС в одном пакете собрать компоненты, реализуемые на этом узле (см. рис.3).

  
Рис. 3. Диаграмма компонентов

 

RUP. Общие  сведения

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

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

Нетрудно заметить, что любой метод, основанный на UML, требует в дополнение к языку  только описание процесса, который  представляет собой совокупность методик, описывающих выполнение отдельных  его шагов. Как уже говорилось ранее, UML – это только язык. На его  основе можно создать много разных методов, которые будут существенно  различаться, несмотря на единую графическую  нотацию. Здесь есть полная аналогия с языками программирования: два  программиста, решающие одну и ту же задачу, напишут даже на одном языке  программирования разные программы.

В данной и последующих  статьях будет рассматриваться Rational Unified Process (RUP), вобравший в себя все  лучшее, что есть на сегодняшний  день в области организации разработки ПС, включая бизнес-моделирование, управление требованиями, анализ и проектирование, КБ разработку, тестирование, управление конфигурацией и управление изменениями.

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

RUP постоянно развивается  на основе единой базы знаний, пополняемой через интернет. Это  – полезный инструмент, применимый  к широкому спектру разрабатываемых  приложений.

Отличительные черты RUP

• RUP – это итеративный процесс (Controlled Interactive);
• Предполагает сквозное применение аппарата Use Cases (Use Case Driven);
• Особое внимание уделяется разработке архитектуры (Architecture Centric);
• Включает управление требованиями и изменениями (Requirements Configuration and Change Management);
• Опирается на КБ концепцию разработки ПС (Component Based Development).
• Базируется на визуальном моделировании (Visual Modeling Techniques);

Итерации

Классический водопадный жизненный цикл включает этапы анализа требований, проектирования, разработки, сборки и тестирования ПС, выполняемые последовательно. Главный недостаток такого подхода заключается в том, что любое внесение изменений в требования к ПС обходится достаточно дорого. Это происходит потому, что необходимость внесения изменений обнаруживается при таком подходе обычно к концу разработки поэтому требуется править модель всей системы и вносить изменения в программный код большого объема. Такой подход хорош для маленьких проектов и в тех случаях, когда требования к ПС строго определены и гарантированно не будут изменяться. К сожалению, таких проектов в реальной жизни немного.

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

• Изменения и уточнения требований выявляются уже в ранний период разработки, когда объем программного кода сравнительно небольшой, поэтому трудоемкость внесения изменений существенно ниже.
• Уже на ранней стадии процесса разработки имеется возможность привлечения специалистов заказчика для оценки промежуточных версий (прототипов) ПС. Как результат – значительно более высокая вероятность того, что конечный продукт будет делать именно то, чего ждет от него заказчик, то есть, гарантируется высокое качество ПС.
• Снижаются архитектурные и интеграционные риски. При итеративном подходе создается устойчивая архитектура, которая прорабатывается на стадиях исследования, а затем проверяется и уточняется в нескольких начальных итерациях. Каждая итерация предполагает интеграцию новых элементов в систему, то есть, количество интегрируемых элементов в каждой итерации невелико и легче прослеживается, чем при глобальной интеграции всех разработанных элементов ПС.
• Итеративный подход способствует более полному повторному использованию программных элементов. Анализ результатов каждой итерации позволяет архитекторам ПС выделить фрагменты, потенциально подлежащие повторному использованию, а в следующей итерации оформить их как повторно используемые коды. Это свойство очень хорошо сочетается с идеями ОО и КБ проектирования.

RUP – процесс,  направляемый вариантами использования

Понятие use case, введенное  в языке UML, является основой для  выполнения всех этапов жизненного цикла, рассматриваемых в RUP. Понятие «business use case» (вид деятельности) является ключевым при бизнес-анализе. На этапах анализа  требований, проектирования и реализации use cases выступают в качестве вариантов  использования системы (ВИ), являясь  той «печкой», от которой «танцуют»  аналитики и разработчики при  выполнении проектирования и реализации ПС. При анализе требований, выделив  ВИ, мы тем самым определяем требование или уровень иерархии требований к ПС. При детализации ВИ определяются объекты, и способы их взаимодействия, которые должны быть реализованы в программном коде.

Следует особо выделить роль ВИ в планировании итераций. Как  определить, какая функциональность должна быть реализована в очередной  итерации? Здесь на выручку приходят диаграммы ВИ. Каждому ВИ можно  приписать приоритет, определяющий, в какой итерации его следует  реализовать. Можно показать все  ВИ, реализуемые в очередной итерации, на отдельной диаграмме (или нескольких диаграммах).

RUP – процесс,  основанный на архитектуре

В основе RUP лежит  КБ разработка ПС, предусматривающая  разработку компонентов и сборку ПС из разработанных и готовых  компонент. В основе любого проекта  лежат кардинальные решения, определяющие принципы построения ПС, которые находят  свое отражение в архитектуре системы. Разработка архитектуры ПС в RUP преследует следующие цели:

• Описание организации ПС;
• Определение компонентов и их интерфейсов;
• Определение подсистем и объединение компонентов в подсистемы;
• Создание основы для повторного использования компонентов;
• Создание базиса для разработки;
• Контроль над проектом и поддержка целостности системы.

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

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

Реализационное  представление описывает организацию статических программных модулей (компонентов, файлов данных, исходного кода и др.) в терминах пакетов и уровней.

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

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

Use case представление содержит ключевые ВИ и сценарии.

Архитектурные представления  акцентируют внимание только на таких  элементах, которые имеют существенное влияние на структуру ПС, ее производительность, масштабируемость, устойчивость, сопровождаемость, возможность развития. К числу  таких элементов относятся:

• Классы, моделирующие основные объекты деятельности;
• Механизмы, определяющие поведение этих классов;
• Уровни и подсистемы;
• Интерфейсы;
• Основные процессы и управляющие потоки.

В RUP предусмотрено  создание отдельного документа, содержащего  описание архитектуры ПС.

Технологические процессы в RUP

В RUP определено 9 технологических процессов, для каждого из которых предложена методика выполнения. Технологические процессы делятся на две категории – основные процессы и процессы поддержки. К основным относятся:

• Бизнес-анализ,
• Управление требованиями,
• Анализ и проектирование,
• Реализация,
• Тестирование,
• Развертывание.

Вспомогательные процессы включают:

• Управление проектом,
• Управление конфигурацией,
• Управление средой.

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

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

 

RUP. Обследование  организации (бизнес-анализ)

Цели

Цели бизнес-анализа  заключаются в следующем:

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

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