A Reuse Definition, Assessment, and Analysis Framework for UML

Оригинал: D. Needham, R. Caballero, S. Demurjian, F. Eickhoff, J. Mehta and Y. Zhang, “A Reuse Definition, Assessment, and Refactoring Framework for UML”. Advances in UML/XML based Software Evolution, H. Yang (ed.) IRM Press, May 2005, pp 281-302

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

Компоненты программного обеспечения, которые могут быть повторно использованы расхваливались на протяжении более 30 лет, но их преимущества, такие как снижения риска, ограничение издержек, улучшение времени выхода на рынок, повышение качества, поддержка быстрого прототипирования и другие, трудно доказать на практике. Сегодня компонентно-ориентированные языки программирования и их надежные API поддерживают фактическое повторное использование стандартных компонентов (графический интерфейс, связь, базы данных и т.д.), но менее успешны в потенциале повторного использования компонент. Была разработана комплексная метрика, модель и инструмент с формальной основой, направленной на определение, оценку возможности повторного использования, а также анализ программного обеспечения(кода). В этой работе предлагаются методы, которые помечают компоненты/классы для указания уровня возможности повторного использования, который может варьироваться от общего (способного решать проблемы в различных контекстах) к определенному (одноразового использования - не будет повторно использоваться). Учитывая такое распределение уровней классов/компонентов, показатели повторного использования могут объективно классифицировать и измерять зависимости(соединения) в рамках и среди классов/компонентов, выявляя связи, которые способствуют и препятствуют будущему повторному использованию. Может быть введен алгоритм, автоматизирующий оценку повторного использования и рефакторинга. Эта структура поддерживается инструментом Design Reusability Evaluation (DRE).

Модель повторного использования основана на оценке общности классов и связей между классами. Класс может быть помечен как общий, который может быть повторно использован, так и определенный, только для конкретного приложения. Например, в приложении для розничной торговли, поставщик будет иметь общий уровень, а поставщик автомобильных запчастей будет иметь менее общий AutomotiveItem (используемый только в этом контексте), и отдельные розничные торговцы будут иметь конкретный WalmartItem (используемый только конкретной компанией). Уровень общности класса Сi определяется Gi, где Gi = 0, когда Сi – самый общий класс в приложении, Gi = N (N > 0), когда Сi – самый определенный (конкретизированный). Общность классов и отношения между классами являются важной частью схемы для анализа возможности повторного использования, при этом используются следующие параметры: иерархия классов, самый близкий класс, который меньше всего может быть повторно использован, а также связи между не имеющими отношения классами.

Диаграмма вариантов использования, показанная на рисунке, позволяет начать определение и оценку повторного использования. Определение повторного использования связано со следующими свойствами:

1. Общность родительского класса против общности его дочерних классов
2. Общность класса равно общности наименее способного к повторному использованию класса, связанного с данным
3. Несвязанные классы с зависимостями между ними мешают возможности повторного использования

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

После определения вариантов использования можно начинать моделировать классы. Потенциал повторного использования определяется набором метрик, учитывающих связи между классами. Дадим следующее определение. Вариант использования UCA связан с набором классов СA = {C1, C2, …, Cn} для некоторого n, если UCA использует функциональность СА. Разработчикам остается определить, какие классы участвуют в варианте использования UCA и принадлежат СА. Повторное использование UCA означает повторное использование всех классов, входящих в СА. Рассматривая различные классы и связи между ними, можно определить потенциал повторного использования.

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

Авторы статьи дали определение повторного использования, оценки и механизма оценивания UML, тем самым показав, что повторное использование является важной частью в ранней и всех стадиях проектирования и процесса разработки. Основное внимание было уделено потенциалу будущего повторного использования. В частности, был предложен широкий набор формальных свойств и соответствующих руководящих принципов рефакторинга для определения повторного использования, оценки и анализа для использования диаграмм прецедентов, диаграммы классов, моделирование поведения диаграммы, и диаграммы компонентов. Механизм повторного использования и расширение UML были перенесены в Together Control Center. Исследования, представленные в статье, а также усилия по прототипированию являются большим шагом на пути к беспрепятственной поддержки повторного использования в UML и Java для разработчиков программного обеспечения, инженеров и разработчиков.