Модульна композиція

Метод відповідає критерію Модульної Композиції, якщо він забезпечує розробку елементів програмного продукту, вільно об'єднуються між собою для отримання нових систем, можливо, в середовищі, що відрізняється від тієї, для якої ці елементи спочатку розроблялися.

Композиція визначає процес, зворотний декомпозиції: елементи програмного продукту витягуються з того контексту, для якого вони були спочатку призначені, для використання їх знову в іншому контексті.

Метод модульного проектування полегшує цей процес, створюючи автономні елементи програмного продукту досить незалежними від спочатку поставленої задачі, що робить таке вилучення можливим.

Композиція безпосередньо пов'язана з повторним використанням. Цей критерій відображає стару мрію - перетворити процес конструювання програмного продукту в роботу по складанню кубиків так, щоб будувати програми з фабрично виготовлених елементів.

· Приклад 1: Бібліотеки підпрограм. Бібліотеки підпрограм створюються як набори компонованих елементів. Однією з областей, де вони успішно використовуються, є чисельні обчислення, засновані на ретельно підготовлених бібліотеках підпрограм для розв'язання задач лінійної алгебри, методу скінченних елементів, диференціальних рівнянь і ін.

· Приклад 2: Угоди, прийняті в командному мовою Shell операційної системи UNIX. Основні команди системи UNIX оперують з вхідним потоком послідовних символів і видають результат, який має таку ж стандартну структуру. Потенційна можливість композиції підтримується оператором | командного мови "Shell". Запис A | B означає композицію програм. Спочатку запускається програма A, її результати надходять на вхід програми B, що починає свою роботу після закінчення роботи програми А. Таке системне угоду сприяє композиції програмних засобів.

· Контрприклад: препроцесор. Загальноприйнятим способом розширення мови програмування, а іноді і подолання його недоліків, є використання "препроцесора", що приймає вхідні дані в розширеному синтаксисі і відображає їх в стандартній для цієї мови формі. Типові препроцесори для Fortran'а і C підтримують графічні примітиви, розширені керуючі структури або операції над базами даних. Однак зазвичай такі розширення не є взаємно сумісними; що не дозволяє поєднувати два таких препроцесора, і доводиться вибирати між, наприклад, графікою або базою даних.

Композиція не залежить від декомпозиції. Фактично ці критерії часто суперечать один одному. Наприклад, метод спадного проектування, задовольняє, як уже було показано, критерієм декомпозиції, зазвичай призводить до створення таких модулів, які нелегко поєднувати з модулями, отриманими з інших джерел. При такій декомпозиції модулі зазвичай тісно пов'язані з тими специфічними вимогами, які привели до їх розробки, і не можуть бути пристосовані до використання в інших умовах. Метод спадного проектування не дає рекомендацій з розробки модулів, які відповідають загальним вимогам. У ньому немає коштів такої розробки, він не дозволяє ні уникнути, ні хоча б виявити програмну надмірність модулів, одержуваних в різних частинах ієрархії.

Як композиція, так і декомпозиція є частиною вимог до модульного методу проектування. Неминуча суміш двох підходів до проектування: зверху-вниз і знизу-вгору. На цей принцип додатковості звернув увагу Рене Декарт майже чотири століття тому, як видно з зіставлення двох правил його Міркувань. наведених в епіграфі цієї лекції.

Схожі статті