Головна

IDL-опису бібліотека типу

  1.  Олександрія та її бібліотека
  2.  бібліотека
  3.  бібліотека КОМПЕЛ
  4.  бібліотека КОМПЕЛ
  5.  бібліотека КОМПЕЛ
  6.  бібліотека КОМПЕЛ

Для визначення інтерфейсів застосовують спеціальну мову - мова опису інтерфейсів (Interface Definition Language - IDL). Крім інформації про інтерфейси, IDL-опис може містити інформацію про бібліотеку типу.

Бібліотека типу визначає важливі для клієнта характеристики СОМ-об'єкту: ім'я його класу, підтримувані інтерфейси, імена та адреси елементів інтерфейсу.

Розглянемо приклад наведеного нижче IDL-опису об'єкта для роботи з файлами. Воно складається з 3 частин. Перші дві частини описують інтерфейси IРаботаСФайламі і IПреобразованіеФорматов, третя частина-бібліотеку типу ФайлиБібл. По перших двох частинах компілятор MIDL генерує код посередників і заглушок, по третій частині - код бібліотеки типу:

--- 1-я частина

[Object,

uuid (E7CDODOO-1827-11CF-9946-444553540000)]

interface IРаботаСФайламі; IUnknown

{Import "unknown.idl"

HRESULT ОткритьФайл ([in] OLECHAR ім'я [31]);

HRESULT ЗапісатьФайл ([in] OLECHAR ім'я [31]);

HRESULT ЗакритьФайл ([in] OLECHAR ім'я [31]); }

--- 2-я частина

[Object.

uuid (5FBDD020-1863-11CF-9946-444553540000)]

interface IПреобразованіеФорматов: IUnknown

{HRESULT ПреобразоватьФормат ([in] OLECHAR ім'я [31],

[In] OLECHAR формат [31]); }

--- 3-тя частина

[Uuid ??(B253E460-1826-11CF-9946-444553540000),

version (1.0)]

library ФайлиБібл

{Importlib ( "stdole32.tlb");

[Uuid ??(B2ECFAAO-1827-11CF-9946-444553540000)]

coclass СоФайли

{Interface IРаботаСФайламі;

interface IпреобразованіеФорматов; }

}

Опис бібліотеки типу починається з її унікального імені (записується після службового слова uuid), потім вказується номер версії бібліотеки.

Після службового слова library записується символьне ім'я бібліотеки (ФайлиБібл).

Далі в операторі importlib вказується файл зі стандартними визначеннями IDL - stdole32.tlb.

Тіло опису бібліотеки включає тільки один елемент - СОМ-клас (coclass), на основі якого створюється СОМ-об'єкт.

На початку опису СОМ-класу наводиться його унікальне ім'я (це і є ідентифікатор класу - CLSID), потім символьне ім'я - СоФайли. У тілі класу перераховані імена підтримуваних інтерфейсів - РаботаСФайламі і IПреобразованіеФорматов.

Як показано на рис, доступ до бібліотеки типу виконується за стандартним інтерфейсу ITypeLib, а доступ до окремих елементів бібліотеки - по інтерфейсу ITypelnfo.

29. CASE-технологія, особливості життєвого циклу, склад, основні функції CASE-систем, засоби автоматизації програмування.

Сучасні CASE-засоби охоплюють велику область підтримки численних технологій проектування ІС: від простих засобів аналізу і документування до повномасштабних засобів автоматизації, що покривають весь життєвий цикл ПО.

Найбільш трудомісткими етапами розробки ІС є етапи аналізу та проектування, в процесі яких CASE-засоби забезпечують якість прийнятих технічних рішень та підготовку проектної документації. При цьому велику роль відіграють методи візуального представлення інформації. Це передбачає побудову структурних чи інших діаграм у реальному масштабі часу, використання різній кольорової палітри, наскрізну перевірку синтаксичних правил. Графічні засоби моделювання предметної області дозволяють розробникам в наочному вигляді вивчати існуючу ІС, перебудовувати їх у відповідність з поставленими цілями і наявними обмеженнями.

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

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

-потужні графічні засоби для опису і документування ІС, що забезпечують зручний інтерфейс з розробником і розвиваючі його творчі можливості;

-інтеграція окремих компонент CASE-засобів, що забезпечує керованість процесом розробки ІС;

-використання спеціальним чином організованого сховища проектних метаданих (сховища).

Інтегрований CASE-засіб (або комплекс засобів, що підтримують повний ЖЦ ПО) містить такі компоненти:

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

-Графічний кошти аналізу та проектування, щоб забезпечити створення і редагування ієрархічно пов'язаних діаграм (DFD, ERD і ін.), що утворюють моделі ІС;

-засоби розробки додатків, включаючи мови 4GL і генератори кодів;

-засоби конфігураційного управління;

-засоби документування;

-засоби тестування;

-засоби управління проектом;

-засоби реінжинірингу.

Всі сучасні CASE-засоби можуть бути класифіковані в основному за типами та категоріями. Класифікація за типами відбиває функціональну орієнтацію CASE-засобів на ті чи інші процеси ЖЦ. Класифікація за категоріями визначає ступінь інтегрованості по виконуваних функцій і включає окремі локальні засоби, вирішальні невеликі автономні завдання (tools), набір частково інтегрованих засобів, що охоплюють більшість етапів життєвого циклу ІС (toolkit) і повністю інтегровані засоби, що підтримують весь ЖЦ ІС і пов'язані спільним репозиторієм . Крім цього, CASE-засоби можна класифікувати за такими ознаками:

-Застосовується методологій і моделям систем і БД;

-ступеня інтегрованості з СУБД;

-Доступні платформ.

30. Перспективи розвитку технології програмування, технологічна зрілість організацій-розробників ПЗ, ліцензування організацій-розробників ПЗ.

Модель технологічної зрілості (СММ) - це опис стадій еволюції, які проходять організації-розробники в міру того, як вони (організації) визначають, реалізують, вимірюють, контролюють і вдосконалюють процеси створення ПО. Ця модель допомагає організації вибрати адекватну стратегію вдосконалення цих процесів, надаючи методичну основу для визначення поточного рівня їх досконалості і виявлення проблем, критичних для якості розроблюваного ПЗ.

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

1. Початковий рівень (initial level) - описаний в стандарті в якості основи для порівняння з наступними рівнями. На підприємстві такого рівня організації не існує стабільних умов для створення якісного програмного забезпечення. Результат будь-якого проекту цілком і повністю залежить від особистих якостей менеджера та досвіду програмістів, причому успіх в одному проекті може бути повторений тільки в разі призначення тих же менеджерів і програмістів на наступний проект. Більш того, якщо ці менеджери або програмісти йдуть з підприємства, то різко знижується якість вироблених програмних продуктів. У стресових ситуаціях процес розробки зводиться до написання коду і його мінімального тестування.

2. Повторюваний рівень (repeatable level) - на підприємстві впроваджені технології управління проектами. При цьому планування і управління проектами ґрунтується на накопиченому досвіді, існують стандарти на розроблювальний програмне забезпечення (причому забезпечується дотримання цих стандартів) і спеціальна група забезпечення якості. У разі необхідності організація може взаємодіяти з субпідрядниками. У критичних умовах процес має тенденцію скочуватися на початковий рівень.

3. Певний рівень (defined level) - характеризується тим, що стандартний процес створення і супроводу програмного забезпечення повністю документований (включаючи і розробку ПО, і управління проектами). Мається на увазі, що в процесі стандартизації відбувається перехід на найбільш ефективні практики і технології. Для створення і підтримки подібного стандарту в організації повинна бути створена спеціальна група. Нарешті, обов'язковою умовою для досягнення даного рівня є наявність на підприємстві програми постійного підвищення кваліфікації і навчання співробітників. Починаючи з цього рівня, організація перестає залежати від якостей конкретних розробників, і процес не має тенденції скочуватися на рівень нижче в стресових ситуаціях.

4. Керований рівень (managed level) - в організації встановлюються кількісні показники якості, як на програмні продукти, так і на процес в цілому. Таким чином, більш досконале управління проектами досягається за рахунок зменшення відхилень різних показників проекту. При цьому осмислені варіації в продуктивності процесу можна відрізнити від випадкових варіацій (шуму), особливо в добре освоєних областях.

5. Оптимізуючий рівень (optimizing level) - характеризується тим, що заходи щодо поліпшення застосовуються не тільки до існуючих процесів, а й для оцінки ефективності введення нових технологій. Основним завданням всієї організації на цьому рівні є постійне поліпшення існуючих процесів. При цьому поліпшення процесів в ідеалі повинно допомагати попереджати можливі помилки або дефекти. Крім того, повинні вестися роботи по зменшенню вартості розробки програмного забезпечення, наприклад за допомогою створення і повторного використання компонентів. Сертифікаційна оцінка відповідності усіх ключових областей проводиться за 10-бальною шкалою. Для успішної кваліфікації даної ключової області необхідно набрати не менше 6 балів. Оцінка ключовий області здійснюється за наступними показниками:

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

- Наскільки широко дана область застосовується в організації, наприклад, оцінці в 4 бали відповідає фрагментарне застосування;

- Успішність використання даної області на практиці, наприклад, оцінці в 0 балів відповідає повна відсутність будь-якого ефекту, а оцінка в 8 балів виставляється при наявності систематичного і вимірного позитивного результату практично у всій організації.

SPICE.Стандарт SPICE успадкував багато рис більш ранніх стандартів, в тому числі і вже згадуваних ISO 9001 і СММ. Найбільше SPICE нагадує СММ. Точно так же, як і в СММ, основним завданням організації є постійне поліпшення процесу розробки програмного забезпечення. Крім того, в SPICE теж використовується схема з різними рівнями можливостей (в SPICE визначено 6 різних рівнів), але ці рівні застосовуються не тільки до організації в цілому, а й до окремо взятих процесів.

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

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




 Оціночна тестування |  Завдання служби супроводу програмного вироби |  опис інтерфейсу |  Реалізація інтерфейсу |  Сервери СОМ-об'єктів |  Створення СОМ-об'єктів |  Повторне використання СОМ-об'єктів |

© um.co.ua - учбові матеріали та реферати