Новини освіти і науки:

G+

Тлумачний словник
Авто
Автоматизація
Архітектура
Астрономія
Аудит
Біологія
Будівництво
Бухгалтерія
Винахідництво
Виробництво
Військова справа
Генетика
Географія
Геологія
Господарство
Держава
Дім
Екологія
Економетрика
Економіка
Електроніка
Журналістика та ЗМІ
Зв'язок
Іноземні мови
Інформатика
Історія
Комп'ютери
Креслення
Кулінарія
Культура
Лексикологія
Література
Логіка
Маркетинг
Математика
Машинобудування
Медицина
Менеджмент
Метали і Зварювання
Механіка
Мистецтво
Музика
Населення
Освіта
Охорона безпеки життя
Охорона Праці
Педагогіка
Політика
Право
Програмування
Промисловість
Психологія
Радіо
Регилия
Соціологія
Спорт
Стандартизація
Технології
Торгівля
Туризм
Фізика
Фізіологія
Філософія
Фінанси
Хімія
Юриспунденкция

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

При розподілі підсистем за процесорами належить мати на увазі таке:

· деякі задачі потребують для свого вирішення дій на певних пристроях (наприклад, обробку банківської картки належить виконувати на АТМ);

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

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

7.4. Управління сховищами даних

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

У базах даних належить розміщувати дані, які задовольняють одну з таких умов:

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

· дані, які можуть ефективно керувати командами СУБД;

· дані, які повинні переноситися на багато платформ;

· дані, для яких потребується доступ з боку кількох прикладних програм.

У файлах треба розміщати дані, які відповідають одному з таких умов:

· дані, яких багато, але які погано піддаються структуризації;

· дані з низькою інформаційною щільністю (наприклад, дампи);

· «сирі» дані, які підготовлені для баз даних;

· «літаючі» дані, які зберігаються короткий час, а потім вилучаються.

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

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

Відомі три методи внутрішнього управління:

1) послідовне управління процедурами;

2) послідовне управління подіями;

3) паралельне асинхронне управління.

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

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

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

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

Термінація. Термінація полягає у вивільненні всіх зовнішніх ресурсів, зайнятих задачами системи.

Обвал. Обвал — це незапланована термінація системи. Обвал може виникати внаслідок помилок користувача, браку ресурсів чи зовнішньої аварії. Наслідком обвалу можуть бути і помилки в програмному забезпеченні системи.

7.5. Архітектури прикладних систем

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

· система пакетної обробки — обробка даних проводиться один раз для кожного набору вхідних даних;

· системи безперервної обробки — обробка даних проводиться безперервно над змінними вхідними даними (рис. 73);

· системи з інтерактивним інтерфейсом — системи, які управляють зовнішніми впливами (рис. 74);

· системи динамічного моделювання — системи, які моделюють поведінку об’єкта зовнішнього світу;

· системи реального часу — системи, де переважають суворі часові обмеження;

· системи управління транзакціями — системи, які забезпечують сортування та оновлення даних;

· типовою системою управління транзакціями є СУБД.

Рис. 73. Система безперервної обробки: машинна графіка

Рис. 74. Система з інтерактивним інтерфейсом: АТМ

При розробці системи пакетної обробки необхідно виконати такі кроки:

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

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

· Складаємо об’єктну модель кожної фази (вона має таку саму структуру, що й модель всієї системи в цілому: фаза розбивається на підфази); яка розробляє кожну підфазу.

При розробці системи безперервної обробки необхідно виконати такі кроки.

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

· Визначаємо класи проміжних об’єктів між кожною парою послідовних фаз; кожна фаза знає про об’єкти, розташовані на об’єктній діаграмі до та після неї (ці об’єкти подають відповідно вхідні та вихідні дані фази).

· Подаємо кожну фазу як послідовність змін значень елементів вихідної структури даних в залежності від значень елементів вхідної структури даних та значень, які дістають із сховища даних (значення вихідної структури даних формується частинами).

При розробці системи з інтерактивним інтерфейсом необхідно виконувати такі кроки:

· Виділяємо об’єкти, які формують інтерфейс.

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

· Структуру програми визначаємо за її динамічною моделлю; для реалізації інтерактивного інтерфейсу використовуємо паралельне управління (багатозадачний режим) чи механізм подій (переривання), а не процедурне управління, коли час між виводом чергового повідомлення користувачеві та його відповіддю система проводить в режимі очікування.

· Із численних подій виділяємо фізичні (апаратні, прості) події та стараємося при організації взаємодій використовувати насамперед їх.

При розробці системи динамічного моделювання необхідно виконати такі кроки:

· За об’єктною моделлю визначаємо активні об’єкти; ці об’єкти мають атрибути з періодично оновлюваними значеннями.

· Визначаємо дискретні події, такі події відповідають дискретним взаємодіям об’єкта (наприклад, ввімкнення постачання) та реалізуються як операції об’єкта.

· Визначаємо безперервні залежності (наприклад, залежності атрибутів від часу); значення таких атрибутів повинні періодично оновлюватися у відповідності із залежністю.

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

· Розробка системи реального часу аналогічна розробці системи з інтерактивним інтерфейсом.

При розробці системи управління транзакціями необхідно виконати такі кроки:

· Відображуємо об’єктну модель на базу даних.

· Визначаємо асинхронно працюючі пристрої та ресурси з асин-
хронним доступом; у разі потреби визначаємо нові класи.

· Визначаємо набір ресурсів (у тому числі — структур даних), до яких потрібен доступ в час транзакції (учасники транзакції).

· Розробляємо паралельне управління транзакціями; системі може знадобитися кілька разів повторити невдалу транзакцію, перш ніж видати відмову.

7.6. Архітектура системи управління
банківською мережею

Система управління банківською мережею, що розглядається нами як приклад, є гібридною системою: це, по-перше, система з інтерактивним інтерфейсом (інтерактивні впливи здійснюються за допомогою касових терміналів та АТМ), а по-друге, це система управління транзакціями, оскільки вона забезпечує виконання проведення, які і є транзакціями.

Архітектура системи управління банківською мережею показана на рис. 75. Система має три основні підсистеми: підсистему обслуговування АТМ, підсистему «консорціум» та підсистему «банк». Система має топологію зірки, в центрі якої — підсистема «консорціум», а на променях підсистеми «АТМ» та «банк» (очевидно, що до складу системи входить одна підсистема «консорціум» та по кілька підсистем «АТМ» і «банк»).

Постійні сховища даних (рахунки клієнтів та банківська звітна документація) є у підсистем «банк», які працюють на комп’ютерах банків. Оскільки важливо зберігати цілісність даних та забезпечити паралельне обслуговування кількох проведень (транзакцій), сховища даних реалізовані на основі баз даних банків (доступ до даних здійснюється через СУБД, яка, зокрема, забезпечує синхронізацію доступу до даних.

Рис. 75. Архітектура системи управління
банківською мережею

Асинхронна паралельність виникає у зв’язку з необхідністю паралельного обслуговування кількох незалежно працюючих АТМ та касових терміналів. Кожний термінал може одночасно обслуговувати лише одне проведення (транзакцію), але кожне проведення пов’язане також із центральним комп’ютером консорціуму та комп’ютером одного з банків, які мають одночасно обслуговувати кілька проведень. Як видно з рис. 75 кожне проведення розподілене за трьома пристроями; програмне забезпечення, що керує виконанням проведення, також складається з трьох частин; кожна із цих частин може бути реалізована у вигляді окремого класу.

7.7. Розробка об’єктів

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

Розробка об’єктів припускає виконання таких кроків:

· Розглядаючи разом три моделі, дістаємо операції над класами.

· Розробляємо алгоритми, які реалізують здобуті операції.

· Оптимізуємо шляхи доступу до даних.

· Реалізуємо управління взаємодіями із зовнішніми об’єктами.

· Уточнюємо структуру класів, щоб підвищити ступінь успадкування.

· Розроблюємо залежності.

· Визначаємо подання об’єктів.

<== попередня сторінка	\|	наступна сторінка ==>
Заміна програм апаратурою	\|	Спільний розгляд трьох моделей

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

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