Сплоченность (информатика)

В компьютерном программировании под связностью понимается степень принадлежности элементов внутри модуля друг другу . ^[1] В каком-то смысле это мера силы связи между методами и данными класса и некоторой объединяющей целью или концепцией, которой служит этот класс. В другом смысле это мера силы связи между методами класса и данными.

Сплоченность является порядковым типом измерения и обычно описывается как «высокая сплоченность» или «низкая сплоченность». Модули с высокой связностью, как правило, предпочтительнее, поскольку высокая связность связана с несколькими желательными характеристиками программного обеспечения, включая надежность , возможность повторного использования и понятность. Напротив, низкая сплоченность связана с нежелательными характеристиками, такими как сложность поддержки, тестирования, повторного использования или понимания.

Сплоченность часто противопоставляется связности . Высокая сплоченность часто коррелирует со слабой связью , и наоборот. ^[2] Программные метрики связанности и связности были изобретены Ларри Константином в конце 1960-х годов как часть структурированного проектирования и основаны на характеристиках «хороших» практик программирования, которые снижали затраты на обслуживание и модификацию. Структурированный дизайн, сплоченность и связь были опубликованы в статье Стивенса, Майерса и Константина (1974). ^[3] и книга Юрдон и Константин (1979). ^[1] Последние два впоследствии стали стандартными терминами в разработке программного обеспечения .

Высокая сплоченность [ править ]

В объектно-ориентированном программировании класс считается обладающим высокой связностью, если методы, обслуживающие этот класс, во многих аспектах схожи. ^[4] В высокосплоченной системе читаемость кода и возможность его повторного использования повышаются, в то время как сложность остается управляемой.

Сплоченность увеличивается, если:

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

Преимущества высокой сплоченности (или «сильной сплоченности») заключаются в следующем:

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

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

Типы сплоченности [ править ]

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

Случайное сплочение (худшее)

Случайная связность — это когда части модуля группируются произвольно. Единственная связь между частями заключается в том, что они сгруппированы вместе (например, класс «Утилиты»). Пример:

/*
Groups: The function definitions
Parts: The terms on each function
*/
Module A {
  /*
  Implementation of r(x) = 5x + 3
  There is no particular reason to group functions in this way,
  so the module is said to have Coincidental Cohesion.
  */ 
  r(x) = a(x) + b(x) 
  a(x) = 2x + 1
  b(x) = 3x + 2
}

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

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

Процедурная сплоченность: Процедурная связность — это когда части модуля группируются, поскольку они всегда следуют определенной последовательности выполнения (например, функция, которая проверяет права доступа к файлу, а затем открывает файл).

Коммуникационная/информационная сплоченность: Коммуникационная связность — это когда части модуля группируются, поскольку они работают с одними и теми же данными (например, модуль, который работает с одной и той же записью информации).

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

Функциональная сплоченность (лучшая)

Функциональная связность — это когда части модуля группируются, поскольку все они способствуют выполнению одной четко определенной задачи модуля (например, лексический анализ строки XML). Пример:

/*
Groups: The function definitions
Parts: The terms on each function
*/
Module A {
  /*
  Implementation of arithmetic operations
  This module is said to have functional cohesion because 
  there is an intention to group simple arithmetic operations
  on it. 
  */
  a(x, y) = x + y
  b(x, y) = x * y
}

Module B {
  /*
  Module B: Implements r(x) = 5x + 3
  This module can be said to have atomic cohesion. The whole
  system (with Modules A and B as parts) can also be said to have functional
  cohesion, because its parts both have specific separate purposes. 
  */
  r(x) = [Module A].a([Module A].b(5, x), 3)
}

Идеальная когезия (атомарная)

Пример.

/*
Groups: The function definitions
Parts: The terms on each function
*/
Module A {
  /* 
  Implementation of r(x) = 2x + 1 + 3x + 2
  It's said to have perfect cohesion because it cannot be reduced any more than that.
  */
  r(x) = 2x + 1 + 3x + 2
}

Хотя сплоченность является шкалой рангового типа, ранги не указывают на устойчивое развитие улучшения сплоченности. Исследования Ларри Константина , Эдварда Юрдона и Стива МакКоннелла ^[5] указывают на то, что первые два типа сплоченности являются худшими, коммуникативная и последовательная сплоченность очень хороши, а функциональная сплоченность превосходит.

См. также [ править ]

Ссылки [ править ]

↑ Перейти обратно: Перейти обратно: ^а ^б Юрдон, Эдвард ; Константин, Ларри Лерой (1979) [1975]. Структурное проектирование: основы дисциплины проектирования компьютерных программ и систем . Юрдон Пресс. Бибкод : 1979sdfd.book.....Y . ISBN 978-0-13-854471-3 .
^ Ингено, Джозеф (2018). Справочник архитектора программного обеспечения . Пакт Паблишинг . п. 175. ИСБН 978-178862406-0 .
^ Стивенс, Уэйн П .; Майерс, Гленфорд Дж .; Константин, Ларри Лерой (июнь 1974 г.). «Структурированный дизайн». IBM Systems Journal . 13 (2): 115–139. дои : 10.1147/sj.132.0115 .
^ Марсич, Иван (2012). Программная инженерия . Университет Рутгерса .
^ МакКоннелл, Стив (июнь 2004 г.) [1993]. Код завершен (2-е изд.). Пирсон Образование. стр. 168-171 . ISBN 978-0-7356-1967-8 .

Внешние ссылки [ править ]

[Yourdon_1979-1] Перейти обратно: Перейти обратно: ^а ^б Юрдон, Эдвард ; Константин, Ларри Лерой (1979) [1975]. Структурное проектирование: основы дисциплины проектирования компьютерных программ и систем . Юрдон Пресс. Бибкод : 1979sdfd.book.....Y . ISBN 978-0-13-854471-3 .

[Ingeno_2018-2] Ингено, Джозеф (2018). Справочник архитектора программного обеспечения . Пакт Паблишинг . п. 175. ИСБН 978-178862406-0 .

[Stevens_1974-3] Стивенс, Уэйн П .; Майерс, Гленфорд Дж .; Константин, Ларри Лерой (июнь 1974 г.). «Структурированный дизайн». IBM Systems Journal . 13 (2): 115–139. дои : 10.1147/sj.132.0115 .

[Marsic_2012-4] Марсич, Иван (2012). Программная инженерия . Университет Рутгерса .

[McConnell-5] МакКоннелл, Стив (июнь 2004 г.) [1993]. Код завершен (2-е изд.). Пирсон Образование. стр. 168-171 . ISBN 978-0-7356-1967-8 .

[1]

[2]

[3]

[4]

[5]