Технології швидкого прототипування.
Технології швидкого прототипування розраховані головним чином на забезпечення швидкої розробки прототипів, а не на такі їхні системні характеристики, як продуктивність, зручність експлуатації або безвідмовність.
Існує три основні методи швидкої розробки прототипів.
Розробка з застосуванням динамічних мов високого рівня.
Використання мов програмування баз даних.
Збірка додатків з повторним використанням компонентів.
На практиці часто ці методи спільно використовуються в процесі розробки прототипів систем. Наприклад, мова програмування баз даних може застосовуватися для вилучення даних з їх наступною обробкою за допомогою компонентів, що повторно використовуються. Інтерфейс користувача системи можна розробити , використовуючи візуальне програмування.
В даний час розробка прототипів зазвичай спирається на набір інструментів, що підтримують принаймні два з цих методів. Наприклад, система Smalltalk VisualWorks підтримує мову дуже високого рівня і забезпечує повторне використання компонентів. Пакет Lotus Notes включає підтримку програмування баз даних за допомогою мови високого рівня і повторне використання компонентів, які можуть забезпечити операції над базою даних.
Більшість систем прототипуванния сьогодні підтримують візуальне програмування, при якому деякі частини або весь прототип розробляються в інтерактивному режимі. Замість послідовного написання програм розробник прототипу віддає перевагу роботі з графічними піктограмами, що представляють функції, дані або компоненти інтерфейсу користувача, та відповідними сценаріями управління цими піктограмами. Готова до виконання програма генерується автоматично з візуального представлення системи. Це спрощує розробку програми і зменшує витрати на прототипування.
Тема 12. Покомпонентна розробка. Компоненти і класи об'єктів.
Метод покомпонентної розробки ПЗ з повторним використанням компонентів з'явився наприкінці 1990-х років як альтернатива об'єктно-орієнтованому підходу до розробки систем, який не привів до повсюдного повторного використання програмних компонентів, як передбачалося спочатку.
Окремі класи об'єктів виявилися занадто деталізованими і специфічними: їх було потрібно зв'язувати з додатком або під час компіляції, або при компонуванні системи. Використання класів зазвичай передбачає наявність детальних даних про класи, що робить доступним вихідний код, а для комерційних продуктів вихідний код відкритий дуже рідко. Незважаючи иа ранні оптимістичні прогнози, значний розвиток ринку окремих програмних об'єктів і компонентів так і не відбувся.
Компоненти більш абстрактні, ніж класи об'єктів. Тому їх можна вважати незалежними постачальниками сервісів. Якщо система запитує який-небудь сервіс, то викликається компонент, який надає цей сервіс незалежно від того, де виконується компонент і якою мовою написаний.
Компоненти як постачальники послуг.
Погляд на компонент як на постачальника сервісів визначається двома основними характеристиками компонентів, які допускають їх повторне використання.
Компонент – це незалежно виконуваний програмний об'єкт. Вихідний код компонента може бути недоступний, тому такий компонент не компілюється спільно з іншими компонентами системи.
Компоненти оголошують свій інтерфейс і всі взаємодії з ними здійснюються за його допомогою. Інтерфейс компонента описується в термінах параметрезованих операцій, а внутрішній стан компонента завжди приховано.
Компоненти визначаються через свої інтерфейси. У більшості випадків компоненти можна описати у вигляді двох взаємопов'язаних інтерфейсів (див рис. 1):
інтерфейс постачальника сервісів, який визначає сервіси, що надаються компонентом;
інтерфейс запитів, який визначає, які сервіси доступні компоненту з системи, що використовує цей компонент.
Рисунок 1 – Інтерфейси компонента
Як приклад розглянемо компонент (рис. 2), який надає сервіси виведення документів на друк. У нашому прикладі підтримуються наступні сервіси: друк документів, перегляд стану черги на конкретному принтері, реєстрація та видалення принтерів з системи, передача документа з одного принтера на інший і видалення документа з черги на друк. Дуже важливо, щоб комп'ютерна платформа, на якій виконується компонент, надавала сервіс, який дозволяє отримати файл опису принтера (назвемо його ФайлОпПринтер), та сервіс, що передає команди на конкретний принтер (КомПринтер).
Рисунок 2 – Компонент служби друку