К. М. Лавріщева програмна інженерія підручник Київ, 2008
 Скачать 5.23 Mb.
|
|
Керування вимогами – RequisitePro. Цей інструмент дозволяє виявляти, формувати і структурувати набори вимог у наочній формі. Для кожної вимоги 236 Розділ 8 зберігається історія створення, що дозволяє відслідковувати внесені зміни у попередні вимоги. Усі документи і дані, що пов’язані з вимогами, зберігаються у централізованій базі проекту. Там же зберігаються сценарії, функціональні і нефункціональні специфікації вимог, плани їхнього трасування та тестування. Керування проектом і версіями – ClearCase. Це система керування програмним проектом. Вона зберігає всі проектні рішення, структури й інші артефакти у репозитарії. В ньому зберігаються вихідні тексти об'єктних і програмних модулів, а також усі зміни, що були внесені в проект та в сформовані версії. Ця система дозволяє виводити характеристики змінених файлів у графічній формі і надавати всі зміни у вигляді дерева версій. Дана система забезпечує контроль робіт команди розробників, а також обмін даними між різними розробниками проекту, що географічно розташовані на відстані один від одного. При одержанні останньої версії ПС проводиться їхній контроль, керування робочим простором за допомогою унікального інваріантного підходу. Є можливість прискорити цикли розробки ПС і створити нові, надійні в експлуатації продукти ПС, а також допрацьовувати і підтримувати раніше реалізовані продукти без зміни середовища, інструментів і методу розробки. Кожен учасник проекту може мати доступ, як до усіх файлів проекту, так і до тільки що визначеної його частини з використанням системи фільтрів, яка заховує непотрібну інформацію. Розробник може виходити з загального складу розробки проекту, а також після усіх внесених змін повернутися знову у проект. ClearCase здійснює автоматичне злиття версій, контроль конфігурацій і версій на основі збереження всієї історії і кожного файлу проекту, включаючи міграцію файлів між незалежними проектами. Змінювання систем – ClearQuest. Її мета – архівація всіх змін та створення БД засобами SQL, MS Access, Sybase SQL Anywhere або Oracle. SQL-запити можуть додаватися до вже готової БД. Тобто ClearQuest забезпечує: – керування змінами об’єктів у ході процесу розроблення ПС; – оптимізацію шляху проходження запитів і зв'язаних з ними форм і процедур; – зв'язок об'єктів, розділених територіально через World Wide Web; – упровадження надійного і перевіреного процесу або зміну вже існуючого процесу для задоволення специфічним вимогам; – візуальний аналіз проекту з графічним подання інформації і звітів; – інтеграцію з засобами ClearCase з метою створювання зв'язку між запитами та розвитком коду; – зв'язок з Sybase, Oracle, Microsoft; – інтеграцію з засобами тестування (TeamTest, VisualTest, Purify, PureCoverage, Quantify і Robot); – створення звітів за допомогою Crystal Reports; – інтеграцію COM з MS Word і MS Excel. Інструменти вимірювання продукту – Rational Quantify. Цей інструмент призначений для ідентифікації «вузьких місць» у ПС, що розробляється, виявлення частин застосування, що сповільнюють швидкість його виконання, та обліку продуктивності. Він може генерувати список усіх викликуваних у процесі роботи функцій ПС в табличній формі, указуючи тимчасові характеристики та статистику за усіма викликах (зовнішнім і внутрішнім). Це створюється за допомогою Розділ 8 237 технології OCI (Object Code Insertion) шляхом підрахунку циклів, вставки лічильників у код тестованої програми для фіксації виконаних циклів. Накопичена статистична інформація щодо викликів може бути використана для побудови графіків і зведених таблиць у середовищі Microsoft Excel. Інакше кажучи, даний інструмент може надавати точну інформацію про продуктивність створеної ПС та вузькі місця виконаних функцій, викликів, бібліотек тощо. Для підвищення продуктивності ПС до складу інструменту входять наступні засоби: – Call Graph призначений для графічного подання даних, що використовуються у критичних функціях і вимагають найбільшого часу їхнього виконання; – Function List і Function Detail забезпечують видачу візуальних даних у табличній формі у вікнах, в які можна безпосередньо вносити зміни до коду і построкове переглядати дані в анотованих копіях цих вікон; – можливій вихід у середовище DCE, систему Solaris і бібліотеки SunOS IBM; – збирання даних про продуктивність в усіх використовуваних інструментах; – використання мов (C, C++, Fortran, Ada і Java). Тестування ПС – Visual Test. Цей інструмент забезпечує функціональне тестування незалежно від мови реалізації компонентів ПС для Windows, а також компонентів Active, DLL, сервера автоматизації OLE (OLE Automation server). Він має інтерфейс із Microsoft Visual Studio, в якому можливо створювати, розширювати можливості компонентів та КПВ, а також пристосовувати їх з інших проектів. Інший засіб Rational Robot дозволяє тестування графічного інтерфейсу більше ніж у GUI, а також тестувати сотні і тисячі властивостей всіх об'єктів ПС в цілому і кожний окремо. Він працює в двох режимах: в автоматичному і ручному. У ручному режимі користувач сам задає сценарій тестування у спеціальної мові, а в автоматичному режимі генерують необхідні скріпти для подальшого повторного тестування ПС. LoadTest – засіб автоматизованого тестування характеристик розподілених мережних застосувань для платформ Windows і Unix. При тестуванні продуктивності допускається завантаження сервера для великої кількості віртуальних користувачів. Наприклад, можна установити таймер для одного користувача, щоб визначити час виконання запиту при його посилці на той же самий сервер або в той же самий час їх множину. Для перевірки продуктивності ПС можуть створюватися навантажувальні, стресові, конкуруючі і конфігураційні тести. Якщо клієнт/серверна система має розподілену архітектуру, то завантажувальне тестування може бути використане для перевірки правильності вибраних методів з метою конструювання системи. Крім того виміряється час виклику серверної частини. Графічний інтерфейс дає вимір часу відзиву системи в конкретному клієнтському застосуванні. Pure Coverage призначений для виявлення ділянок коду, пропущених для тестування застосування у Windows NT та компонентів, опис яких подано у мовах Visual Basic, Visual C++ або Java. Цей інструмент збирає статистику про ті ділянки програми, що під час тестування не були пройдені, виявляє рядки, що не виповнюються, й аналізує причини їхнього невиконання. Керування якістю. Для поліпшення якості ПС використовується набір інструментальних засобів: Visual Test, Rational Quantify, Purify, Pure Coverage. 238 Розділ 8 Інструмент Visual Test використовується для тестування компонентів і їхніх інтерфейсів на рівні опису МП, а інструменти Rational Robot і LoadTest підтримують тестування завантажених застосувань у клієнт-серверному середовищі. Вони збирають дані для оцінювання деяких показників якості, наприклад, надійності. Засоби інженерії і реінженерії. Інструмент Rational Rose Professional призначений для прямого і зворотного проектування ПС з урахуванням обраної МП. Результат проектування – шаблон інформаційної системи, який необхідно запрограмувати на підходящій МП. Інструмент Rose Enterpriseпризначений для проектування архітектури підприємства з використанням багатьох перерахованих вище інструментів. Rose DataModeler призначений для проектування ПС і БД без кодогенерації. Rose RealTime – спеціалізована версія для проведення повної кодогенерації і реінженерії ПС на мовах С и С++ з використанням діаграм UML. Інструменти аналізу стану середовища – Purify. Це інструмент призначений для збирання даних про будь-які втрати пам'яті (наприклад, неповернення з блоку), зупинки виконання програм за станом середовища, пов’язаним з помилкою типу run–time. Розробник ПС має можливість не тільки знати стан її виконання (попередження, помилки), а й переходити до відповідних внутрішніх викликів інших компонентів. Інструмент документування – SoDa. Призначений для автоматизації документів і підготовки звітів по заздалегідь установленому шаблону, по якому компілюється документація з текстовими і графічними даними, а також з використанням стандартних шаблонів, створених за допомогою Wizard і меню Word. 8.3.4. Засоби підтримки процесу RUP RUP (Rational Unified Process) – це уніфікований процес побудови моделей і з них ПС. Функціональні можливості системи, що створюється, визначаються прецедентами, кожний з яких відображає спосіб використання ПС. Опис прецеденту визначає те, що відбудеться у системі, коли він буде виконаний. Прецедент – це набір екземплярів, а кожний екземпляр – це послідовність дій з виконання задачі системи і отримання відповідного результату, який чекає деякий суб'єкт або користувач. Як претендент може бути будь-яка інша система, взаємодіюча з даною ПС [17]. Модель – це структура предметної області, її елементи, що виділяються на ранніх процесах її проектування. Коли обговорюється система і вимоги до неї, наприклад, з кінцевим користувачем або замовником, модель повинна описувати те, що система повинна робити, абстрагуючи від різних подробиць на рівні, що вище рівень МП, з метою задовольняння потреб проектувальників. Формалізація моделей у RUP забезпечується засобами UML і дає можливість строго описувати вимоги, що перетворяться до готового продукту. Головною моделлю є модель варіантів використання, на основі якої розробляються моделі аналізу, проектування, реалізації системи тощо (рис.8.10). Кожна модель відповідає моделі варіантів використання, в які входять вхідні дані для пошуку і специфікації класів, для підбора і специфікації тестів, а також планування ітерацій розробки й інтеграції ПС. Модель аналізу забезпечує Розділ 8 239 специфікацію вимог до системи й опис варіантів використання як кооперації між концептуальними класифікаторами. Модель проектування забезпечує створення статичної структури й інтерфейсів системи, а також реалізацію варіантів використання у вигляді набору кооперацій між підсистемами, класами й інтерфейсами. Модель реалізації містить у собі компоненти системи у вхідно МП. Інші моделі – модель тестування і модель розміщення компонентів призначені для їхнього виконання в операційному середовищі комп'ютерів. Рис. 8.10. Зв'язок моделей у системі RUP Артефакти однієї моделі зв'язані між собою і повинні бути сумісні один з одним. Відношення між моделями є не цілком формальними, оскільки частини моделей специфіковані мовою метамоделі, а інші описані неформально, природною мовою. Специфікації діаграм UML – формальні. Моделі задаються відповідними діаграмами use case. Вони взаємозалежні, семантично перетинаються і визначають систему як єдине ціле. Варіант використання може мати відношення залежності до кооперації в моделі проектування, що задає реалізацію. Моделі, визначені на кожній ітерації процесу RUP, уточнюються або розширюють моделі попередніх ітерацій процесу. Варіанти використання специфікують тип відношень між діючою особою (актором), користувачем і системою. На високому рівні абстракції вони представляються упорядкованою послідовністю дій або альтернатив. Крім цього, варіант використання – це різновид класифікатора, операції якого – повідомлення, одержувані екземплярами конкретного варіанта використання. Методи задають реалізацію операцій у термінах послідовностей дій, виконуваних екземплярами прецеденту або варіанта використання. Приклад. Нехай uc – варіант використання (uс – use case), операція якого виконується над обліковим записом і має наступне визначення: uc.operations = <op1> , op1.name = запит і відновлення облікового запису, 240 Розділ 8 op1.method.body = {< перевірка ідентифікації користувача, наявності сервісу, запиту про борги, відновлення облікового запису >, < перевірка ідентифікації користувача на відхилення облікового запису >, < перевірка ідентифікації користувача на наявність сервісу і відхилення облікового запису>, < перевірка ідентифікації користувача і перевірка наявності сервісу або запиту про борги, на оплату, відновлення облікового запису >}. Тіло методу – процедура реалізації операцій у вигляді послідовності дій op.method.body. Між іменами дій варіанта використання й іменами дій у кооперації установлюється відображення, що забезпечує гнучкість у процесі розроблення і модифікації імен дій. Між кооперацією і варіантом використання створюється відношення реалізації. Варіант використання, що реалізується кооперацією, забезпечує взаємодію і поведінку. Якщо кооперація має більш складне поводження, ніж задане варіантом використання, то цей варіант використання – часткова специфікація поведінки кооперації. Варіанти використання специфікують дії, видимі за межами системи, але не специфікують внутрішніх дій (створення і видалення екземплярів класифікаторів, взаємодія між екземплярами класифікаторів і т.д.). З практичної точки зору RUP представляється упорядкованим набором процесів: формування вимог, аналіз, проектування, реалізація й іспит кроків і процесів ЖЦ, що виконуються ітеративно. Кожен етап процесу має завершення, що називається черговою ітерацією. Остання ітерація – це випуск продукту. На кожній ітерації цикл робіт може повторюватися, починаючи зі збирання й уточнення вимог. Етап формування вимоги. На цьому процесі проводиться збирання функціональних, технічних і прикладних вимог до проекту. На основі вимог замовника і користувачів система описується так, щоб досягти розуміння між користувачами і проектною групою. Інформація збирається з урахуванням особливостей існуючих систем і документів, підготовлених замовником, і містить у собі: – модель ПрО; – модель схем використання з описом функціональних і загальних вимог у формі результатів опитування, наборів діаграм і детального опису кожної схеми; – дизайн і прототип інтерфейсу користувача для кожного актора; – список вимог, що не відносять до конкретних схем використання. Етап аналізу. Сформульовані вимоги уточнюються і відображаються в моделі сценаріїв використання. Крім того, створюється аналітична модель системи, що містить у собі формалізми для аналізу внутрішньої структури системи, визначення класів і перетворення цієї моделі на проектні концепції і схеми їхньої реалізації. Основу моделі аналізу становлять діаграми класів, взаємодії, що задають можливі сценарії варіантів використання системи в термінах взаємодії об'єктів на процесі аналізу. Етап проектування слугує для уточнення класів і опису їхніх чотирьох рівнів: користувальницького інтерфейсу, бізнес-рішень, рівня доступу і рівня даних. Створювана проектна модель системи складається зі структури підсистем, їхнього розподілу між рівнями, інтерфейсів класів і об'єктів, зв'язків класів з вузлами розгортання (модель розгортки). Розділ 8 241 На процесі реалізації виконується побудова прототипу з компонентів; створення тестів за схемами використання; тестування й інтеграція компонентів; перевірка архітектури; перехід до наступної ітерації. При кожній ітерації тестова модель уточнюється шляхом виключення неактуальних тестів, створення схеми регресійного тестування і додавання тестів для компонентів, що збираються. Кожен тест створюється за допомогою варіантів використання і реалізує конкретний метод перевірки функцій системи на вхідних даних. 8.3.5. Середовище розроблення систем – CORBA Система CORBA підтримує об’єктно-орієнтовану парадигму програмування. Її основу становить OMA-архітектура, як базис побудови конкретних прикладних розподілених систем. Цей базис містить у собі сервіси і послуги, компоненти яких мають стандартний інтерфейс для взаємодії один з одним і визначаються як компоненти верхнього і проміжного рівнів [18, 19]. Компоненти верхнього рівня — сервісні, надають сервіс для об'єктів і доступ до них різних зовнішніх застосувань. Наприклад, компонент-система керування складними документами надає розробнику або користувачу стандартний спосіб доступу до документів цієї системи для маніпулювання ними. Компоненти проміжного рівня надають сервіс застосуванням для доступу до розподілених системних засобів комунікації, інтеграції, маркетингу й ін. Еталонна модель надає механізм інтеграції різних компонентів системи в профілі, що повинні узгоджуватися зі стандартною архітектурою і складати деяку готову конфігурацію готової програмної системи. До складу еталонної моделі входять набори компонентів по кожним її системам і засобам, а саме: – брокер об'єктних запитів (Object Request Broker — ORB), що забезпечує взаємодію об'єктів; – загальні об'єктні сервіси (Common Object Services), що забезпечують сервіс всім об'єктам, а також в керуванні змінами, реалізаціями, контролем, транзакціями т.п.; – загальні засоби обслуговування (Common Facilities) або загальні послуги, що надають ряд загальних прикладних функцій, що можуть поєднуватися в різні конфігурації в залежності від заданих вимог (наприклад, засобу печатки, БД і електронна пошта); – об'єктні застосування (Application Objects), до яких відносять і їхні компоненти, що реалізують задачі й об'єкти користувача для функціонування в об’єктно-орієнтованому середовищі, і над якими можуть вироблятися операції типу — відкрити, перемістити і помістити. Три компоненти (загальні об'єктні сервіси, загальні засоби обслуговування й об'єктні застосування) відповідають розбивці ПС на функції — базові для більшості застосувань або досить загальні для широкого класу ПС. Ці компоненти взаємодіють між собою через брокер ORB. Об'єктні застосування і загальні засоби обслуговування забезпечують функції і сервіси за допомогою об'єктних інтерфейсів, а також дозволяють адаптуватися до нових поколінь мереж, мов і середовищ. 242 Розділ 8 У загальному випадку об'єкти можуть видавати, обробляти запити і надавати сервіси для інших об'єктних застосувань або для загальних засобів, що підтримують механізм повторного використання класів і об'єктів. Для зв'язку об’єктно-орієнтованого застосування із сервісними або загальними засобами обслуговування використовуються адаптери інтерфейсів або посередники. Еталонна модель не накладає яких-небудь обмежень на структуру і реалізацію об'єктних ПС або загальних засобів. Об'єкти можуть забезпечувати подання інформації, взаємодію з користувачем, виконання прикладних функцій, постійне збереження даних або різні комбінації перерахованих можливостей. При реалізації сервісів більш низького рівня використовуються сервіси, що підтримуються операційними системами і середовищами, а також базовими сервісами, наданими мережними обчислювальними системами. Технологія обробки запитів брокером ORB дозволяє прикладній програмі запитувати сервіси в іншої програмі, викликаючи методи вилучених об'єктів. Для реалізації взаємодії об'єктів і програм (клієнта і сервіра) використовується мова інтерфейсу IDL для сторони сервера або клієнта або для обох. З боку клієнта потрібна специфічна IOR форма (Interoperable Object Reference), що підтримує іменування сервера. Браузер CORBA переглядає імена сервісів і генерує код для вставки його у файл класу клієнта. Для сторони сервера він доповнює код, що зв'язує екземпляри сервентів з іменами сервісів і вставити його у файл класу сервера. IDL файл компілюється, отримана програма запускається для виконання [2, 18]. Інтеграція компонентів в системі CORBA виконується за такими засобами: – Client class викликає метод, що буде виконаний сервером; – Stub class забезпечує конвертування даних методом, що ініціює роботу клієнта в Wire форматі, використовуваному при зв'язуванні на стороні клієнта мережі; – ORB class керує методами передачі даних і викликами методів між процесами, а також зв’язками з сервером та адаптером (рис.8.11); – Server class створює сервент і посилання ORB, що він записує в стандартний вихідний файл; – Implementation class містить у собі ділову логіку сервера, екземпляр класу сервент, що реєструється в ORB для запуску іншого процесу клієнтом; – Skeleton class конвертує ініціюючий метод з Wire форматом у формат, що може прочитати екземпляр сервента. – адаптер POA (Portable Object Adapter) для породження порожнього сервера (Empty), основного сервера (ServerMain), простого Simple та клієнта (ClientMain). Для ініціалізації компонентів використовується три параметри (value, title, type), кожний з яких задається змінною строкового типу: Розділ 8 243 Транслятори з мов програмування Об’єктний адаптер Бібліотека об’єктів Ядро брокера ORB Сервер реалізацій Методи і схеми Програми клієнта Клієнт- stub Опис об’єктів Репозитарій інтерфейсів Розділ реклами Репозитарій реалізацій Процедури реалізації об’єктів Рис. 8.11. Головні функції брокера ORB в ОМА-архітектуре Інтерфейси об'єктів у IDL-мові запам'ятовуються в репозитарії інтерфейсів (Interface Repository), а реалізації об'єктів – у репозитарії реалізацій (Implementation Repository). Незалежність інтерфейсів від реалізацій об'єктів дозволяє них використовувати статично і динамічно різними застосуваннями [2, 18, 19]. Об'єкт-клієнт і об'єкт-сервер обмінюються між собою за допомогою запитів, кожний з яких виповнюється брокером ORB. Інтерфейс клієнта (Сlient Interface) забезпечує взаємодію з об'єктом- сервером через ORB і складається з трьох інтерфейсів: – stub-інтерфейсу, що містить у собі опис зовні видимих параметрів і операцій об'єкта в IDL-мові, утворить статичну частину програми клієнта і зберігається в репозитарію інтерфейсів; – інтерфейсу динамічного виклику DII (Dynamic Invocation Interface) об'єкта, обумовленого під час виконання програми клієнта, використовуючи опис інтерфейсу з репозитарії інтерфейсів; – інтерфейсу сервісів SI (Services Interface), що містить у собі набір сервісних функцій, які клієнт запитує у сервера через брокера. Stub-інтерфейс – клієнтський інтерфейс, забезпечує взаємозв'язок клієнта з ORB. Прикладна програма клієнта через посередника stub, як статичної частини програми клієнта, посилає в запиті параметри, яким зіставляються відповідні описи інтерфейсу з репозитарієм інтерфейсів. Інтерфейс DII забезпечує доступ до об'єктів і їхніх інтерфейсів під час виконання. Цей інтерфейс стає відомим під час виконання і доступний при обробленні викликів ORB. У кожнім виклику вказується тип об'єкта, тип запиту і параметри. Таку інформацію посилає прикладна програма або вона витягається з репозитарію інтерфейсів. 244 Розділ 8 Інтерфейс SI підтримується об'єктним адаптером (Object-Adapter) в часті забезпечення такого сервісу: генерація й інтерпретація посилань, виклик методів, захист, активізація (пошук і виконання об'єкта), відображення посилань і їхню реєстрацію. Існує кілька видів адаптерів: – базовий адаптер (Basic Object Adapter) може забезпечити виконання об'єктів незалежно від брокера; – бібліотечний адаптер (Library Adapter) забезпечує виконання об'єктів з бібліотеці об'єктів або із прикладної програми клієнта; – адаптер БД (Database Adapter) забезпечує доступ до об’єктно-орієнтованої БД. Загальні об'єктні сервіси забезпечують базові операції для моделювання і збереження об'єктів, визначають сукупність кореневих операцій, що можуть реалізовувати або успадковувати всі класи. Сервіси специфікують COSS (Common Object Services Specification) і забезпечують набір об'єктів, що виконують операції з визначенням подій, іменуванням, взаємодією і керуванням рівнобіжними обчисленнями й ін. Ці операції стають доступними застосуваннями через ORB або інші інтерфейси. Інакше кажучи, об'єктні сервіси не припускають єдиного інтерфейсу або реалізації. Вони є операціями, що служать як «цеглинка» при розширенні або додаванні функцій, наданих загальними засобами системи CORBA. Наприклад, об'єктні сервіси можуть виконувати керування трансакціями, зв'язками об'єктів. До операцій загального об'єктного сервісу відносять: – керування екземплярами і класами об'єктів; – збереження об'єктів, їхніх станів і методів; – забезпечення цілісності, несуперечності і вірогідності стану об'єктів як усередині одного об'єкта, так і серед об'єктів класу; – забезпечення безпеки і захисту об'єктів і даних; – реалізацію запитів і рівнобіжне їхнє виконання; – забезпечення життєвого циклу об'єктів ( утворення, знищення, переміщення, копіювання); – обслуговування черг запитів і ін. Даний сервіс підтримує роботу з об'єктами, їхнє існування і незалежність від систем, що до них звертаються. Загальні засоби обслуговуванняпризначені для багатьох прикладних доменів, вони полегшують побудову застосувань, що функціонують під керуванням ORB. Для кінцевих користувачів ці засоби забезпечують уніфіковану семантику загальних компонентів і взаємодію з іншими об'єктами через брокера ORB і об'єктний інтерфейс. Вони підрозділені на такі компоненти: 1) інтерфейс користувача (User Interface); 2) керування інформацією (Information Managment); 3) керування системами (Systems Managment); 4) керування завданнями (Task Managment). Дамо загальну характеристику цим засобам. 1. Інтерфейс користувача підтримує архітектуру структур документів для застосування в різних областях, а саме: – менеджер вікон (Windows manager) і емулятор програм (Emulator program); Розділ 8 245 – система керування роботами (A work managment system) для керування розділами і візуалізацією дисків; – автоматизація завдань і процесів (Task and process automatisation) та видання електронних таблиць (spreadsheep) і макросів діалогу. Ці компоненти утворять проміжна ланка між системою і сервісом відображення результатів на дисплей. 2. Керування інформацією відповідає відомим засобам керування інформацією в інформаційних системах і містить у собі: – обмін даними; – доступ до даних (читання, запис, збереження й ін.); – кодування і представлення даних; – посилка транзакцій і облік часу обробки; – моделювання інформації й ін. До засобів керування відносять також: утилізацію, контроль доступу, підтримка конфігурацій і метаданих і т.п. 3. Керування системами обслуговування (CORBA-facilities), що входять до складу функцій адміністратора розподіленими системами. Основа засобу — це адміністрування застосуваннями при звертанні до загальних засобів обслуговування і до засобів сервісу CORBA. Фактично це керування виконує адміністратор розподілених систем. 4. Керування завданнями складається з засобів виконання завдань, зв'язаних з об'єктами, інтерфейсами, що мають опис у IDL системи CORBA, і доступ до об'єктів через scripts і макроси. |