Оцінка потрібних ресурсів

Рівні

Рівнева система може розглядатись як упорядкована множина віртуальних світів, кожен з яких побудовано на базі понять, які підтримуються його підсистемами: підсистеми одного рівня забезпечують реалізацію підсистем наступного рівня. Об’єкти кожного рівня можуть бути незалежними, хоч зрідка об’єкти різних рівнів можуть відповідати один одному. Кожна підсистема знає про підсистеми нижчих рівнів і нічого не знає про вищі рівні. Залежність клієнт–сервер існує між більш верхнім (клієнт) та більш нижчими рівнями (сервери). При цьому кожен рівень може мати свій власний набір класів та операцій. Кожен рівень реалізується через класи та операції нижчих рівнів. Рівневі архітектури бувають двох видів: відкриті та замкнені. У замкненій архітектурі кожний рівень будується на базі безпосередньо наступного за ним рівня. Це скорочує залежності між рівнями та спрощує внесення змін. У відкритій архітектурі кожний рівень будується на базі всіх наступних за ним рівнів. Це зменшує потребу у перевизначенні операцій на кожному рівні та забезпечує ефективніший і компактніший код. Проте відкрита архітектура не задовольняє принцип зберігання інформації, оскільки зміни в якійсь підсистемі можуть потребувати відповідних змін у підсистемах вищих
рівнів.

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

Система з рівневою архітектурою при перенесенні на іншу платформу потребує переписування лише одного (найнижчого) рівня. Приклад системи з рівневою архітектурою подано на рис. 71.

Рис. 71. Приклад системи з рівневою архітектурою

7.2. Розділи, топологія системи та асинхронізація

Розділи поділяють систему на кілька незалежних чи мало пов’язаних одна з одною підсистем, кожна з яких забезпечує один з видів послуг. Наприклад, операційна система комп’ютера включає систему файлів, управління процесами, управління віртуальною пам’яттю та управління пристроями.

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

Рис. 72. Типова структура системи

Коли всі підсистеми всіх рівнів названі, необхідно показати інформаційні потоки між підсистемами, побудувавши ДПД. Це дозволить зрозуміти топологію системи. Топологія системи визначається сукупністю потоків інформації у системі, наприклад, у компілятора конвеєрна топологія. Можна уявити собі топологію зірки (рис. 72)
і т. ін.; потрібно прагнути, щоб топологія системи була якомога простішою.

В аналізованій моделі, як і в реальному світі та програмному забезпеченні, усі об’єкти незалежні і мають працювати асинхронно. Проте в реалізації не всі об’єкти мають працювати незалежно й асинхронно — кілька об’єктів можуть виконуватися на одному процесорі, якщо вони не можуть бути одночасно активними. Одна з найважливіших цілей розробки системи — з’ясувати, які об’єкти мають бути активними одночасно (паралельно), а які бувають активними лише в різний час. Ці останні об’єкти можуть бути пов’язані в одну послідовність управління (задачу).

Для визначення асинхронності (паралельного існування) об’єктів застосовується динамічна модель. Два об’єкти є істотно асинхронними, якщо в них можуть наставати події в один і той самий час, коли вони не взаємодіють. Якщо події не синхронізуються, такі об’єкти не можуть бути пов’язані в одну послідовність управління.

Рис. 73. Топологія зірки

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

Асинхронні об’єкти можуть виконуватися і на одному пристрої (процесорі), якщо він має систему переривань та підтримує режим розділення часу. Нерідко необхідність виконувати об’єкти на різних пристроях випливає з постановки задачі. Приклад, у задачі про банківську мережу заздалегідь зрозуміло, на яких пристроях мають працювати відповідаючі об’єкти.

7.3. Розподіл підсистем за процесорами
та задачами

Кожний асинхронний (незалежний) об’єкт повинен бути приписаний до одного з пристроїв апаратури: універсального процесора чи спеціалізованого функціонального пристрою. Розробник системи має:

· оцінити потрібну продуктивність та потрібні ресурси;

· вибрати спосіб реалізації підсистем (апаратний чи програмний);

· розподілити програмні підсистеми за процесорами, прагнути задовольнити їх вимоги щодо продуктивності і водночас скоротити міжпроцесорні комунікації.

Оцінка потрібних ресурсів

Рішення щодо застосування кількох процесів звичайно зумовлюється прагненням дістати вищу продуктивність, ніж її може забезпечити один процесор. Кількість потрібних процесів залежить від обсягу обчислень та продуктивності комп’ютера. Розробник системи може оцінити потрібну продуктивність процесорів (що становить постійне навантаження) як добуток кількості транзакцій за секунду на час виконання одної транзакції (у прикладі з банківською мережею транзакція — це проведення). Така оцінка не обчислює накладних витрат, пов’язаних із випадковими змінами навантаження та декотрими іншими факторами. Її належить уточнити.

<== попередня сторінка	\|	наступна сторінка ==>
Уравнение Р. Майера	\|	Заміна програм апаратурою

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.004 сек.