4.4. АВТОМАТИЗАЦІЯ ПРОТОТИПУВАННЯ ІНФОРМАЦІЙНИХ СИСТЕМ

4.4.1. Характеристика сучасних систем прототипування

Прототипування — це етап процесу розробки ІС, що полягає у створенні прототипу — макета («чорнової», пробної версії) системи з базовою функціональністю з метою перевірки придатності запропонованих концепцій, архітектурних та/або технологічних рішень, а також подання системи замовнику для оцінювання на ранніх стадіях її життєвого циклу. За результатами аналізу прототипу приймають рішення щодо подальшої розробки. Оскільки вартість змін вимог до реалізації системи низька, а часу витрачається значно менше, але при цьому гарантується отримання достовірної інформації про вимоги до системи з боку замовника за рахунок його залучення до розробки, переваги прототипування очевидні. Найбільший ефект прототипування дає при розробленні систем з розвиненим користувацьким інтерфейсом, бо вможливлює оцінювання сприйняття його користувачем.

Розрізняють такі типи прототипування:

— швидке (rapid prototyping, throw away prototyping) — у найкоротші терміни створюється прототип, який жодним чином не ввійде до складу готової системи. Швидке прототипування необов’язково виконується в рамках тієї ж платформи і тих самих технологій, що й майбутня система. Прототипи різняться між собою рівнем точності відтворення реальної ІС — її вигляду, взаємодії з користувачем і часових характеристик. Крайнім випадком є паперове прототипування, коли нариси інтерфейсу виконуються на папері від руки. Інший метод передбачає використання програм розробки графічного користувацького інтерфейсу (GUI Builder) для створення прототипу, ззовні схожого на цільову систему, але з відсутніми її функціями (click dummy). Для підготовки прототипу графічного інтерфейсу користувача можуть використовуватися просто HTMLфайли. Для прототипування програмного забезпечення використовують мови високого рівня абстракції (Java, Perl, Python, Haskell або ін.), а при реалізації — іншу, машинноорієнтовану (С, C++) для підготовки акуратного документованого коду;

Критеріями для вибору конкретного інструментального засобу прототипування є висока швидкість створення першої версії прототипу та внесення до нього змін, а також функціональні можливості, достатні для підготовки прототипу заданої якості:

— естетичного;

— деталізованого — такого, що містить не набір блоків на рівні «чорної скриньки», а всі потрібні елементи з дрібними деталями;

— з підтримкою бодай мінімальної інтерактивності — здатного реагувати на дії користувача та емулювати реальні події;

— доступного всім учасниками проекту — замовнику, керівництву, розробнику, дизайнеру;

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

— з можливістю внесення змін — прототип може оновлюватися під час обговорення та опрацювання зауважень.

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

Серед графічних редакторів можна виокремити:

— Microsoft Visio — редактор діаграм і блоксхем для Windows, що використовує векторну графіку;

— OmniGroup OmniGraffle — редактор діаграм, блоксхем та ілюстрацій для Мас OS X;

Альтернативою використання графічних редакторів є прототипування у певному середовищі розробки програм (наприклад Delphi) або сайтів (Dreamweaver). Крім того, існують спеціалізовані засоби створення інтерактивного контенту, наприклад Macromedia Flash або Norpath Studio. Перевагою є можливість створення інтерактивних прототипів, але процес відбувається куди повільніше — системи програмування вибагливі до результатів, а системи вебдизайну зручні лише для простих проектів. Крім того, ці системи не є універсальними: Delphi не використовується для проектування вебінтерфейсів, a Dreamweaver — для інтерфейсів програмного забезпечення, вбудовані елементи керування Flash не збігаються за розмірами з такими самими елементами Windows або MacOS.

У системі повною мірою реалізовано принцип «перетягни і кинь» (drag and drop) — панель віджетів (widget, прикраса) містить посилання, зображення, текст, гіперпосилання, лінії, меню, дерева, елементи форм, таблиці та багато інших елементів, що їх можна перетягти і розмістити в потрібному місці, змінити розмір і відформатувати, а також анотувати і визначити такі можливі дії, як встановлення зв’язку, умовне зв’язування, контроль вкладень імітації, показ або приховування елемента тощо. Підтримується імітація RIAдодатків (Rich Internet Application, «багатих Інтернетдодатків»). Axure RP на основі діаграм може генерувати як HTMLпрототипи, так і специфікації у форматі Microsoft Word. Вікно поділяється на шість основних ділянок: карта сайта (ієрархічний список сторінок), віджети, майстри (шаблони та колекції віджетів, що їх можна повторно використовувати), ділянка сторінки (головна ділянка проектування), коментарі і дії на сторінці, анотації та дії для віджетів.

Одним із важливих завдань, що вирішується за допомогою Axure RP Pro, є забезпечення інтерактивності створюваного прототипу передусім для тестування прототипу майбутніми користувачами. Для мінімального тестування достатньо працюючих посилань, на основі яких перевіряються навігація і структура системи, і вікон, що випливають, для відтворення відповіді системи на певні запити. Наприклад, при тестуванні Webсайта користувач може заповнити реєстраційну форму, а система має надіслати йому на email електронне повідомлення з кодом підтвердження і з подальшими інструкціями щодо роботи. Оскільки насправді електронна пошта на етапі тестування прототипу відсутня, для її емуляції використовують випливаюче вікно з текстом повідомлення та інструкціями, згідно з якими користувач продовжить тестування сайта.

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

Перевагами системи є схожість інтерфейсу з Microsoft Office, проектування блоксхем схоже на роботу в Microsoft Visio, «чистий аркуш» для створення webсторінок — на форми підготовки ресурсів Delphi, а створення прецедентів взаємодії з користувачем — із правилами для повідомлень у Microsoft Outlook Express. Важливими є також наявність якісної документації і навчальних матеріалів, технічна підтримка і порівняно низька вартість.

Недоліками Axure RP Pro є відсутність роботи зі сценаріями, тобто неможливо автоматично згенерувати карту ймовірних шляхів проходження користувача сайтом. Розробник може визначати лише 10 змінних, що зберігаються між сторінками завдяки фреймам, за відсутності емуляції бази даних і сесій неможливо проаналізувати роботу системи за умов, наближених до реальних. У системі не передбачено роботу кількох користувачів з одним проектом на сервері.

iRise ставить за мету створення прототипу, настільки близького до готового продукту, що користувач не може їх відрізнити. iRise Manager — засіб керування вимогами, що дає можливість створювати, зберігати, редагувати і видаляти дані щодо вимог. Studio генерує симуляцію iDoc, яку можна переглянути за допомогою iRise Reader. Таким чином створюється інтегроване середовище розробки, в якому можуть працювати бізнесаналітики і створювати шаблони Webсторінок з основними потоками і програмною логікою за рахунок імітації даних. Хоча існуючі засоби розробки мовою Java (IBM Rational Rapid Developer, BEA WebLogic Workshop тощо) суттєво спрощують процес, від користувача все одно вимагаються знання і вміння з програмування. iRise Studio таких вимог не висуває. Непрограмісти отримують потужний інструмент проектування сценаріїв і сторінок, використання бібліотеки віджетів, динамічного програвання, взаємодії з даними, логіки рішень, анотування, керування вимогами.

Для підтримки розробки програмних систем із масовим виробництвом копій, таких як текстові процесори, застосують принципи і методи традиційного виробництва. Розробка зводиться до складання програмної систем із наперед визначених компонентів. Традиційне кодування застосовується лише для створення нових компонентів і сервісів. Подібні складені додатки є кінцевим результатом функціонування фабрик програмного забезпечення, які інтегрували критичні інновації для забезпечення високоавтоматизованого підходу до розробки програм:

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

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

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

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

Названі інновації застосовують для:

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

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

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

— фіксація проектних рішень у формі, що безпосередньо породжує виконувані програми.

Докладніше організацію фабрик ПЗ описано у п. 4.4.3.

4.4.2. Розробка проектних рішень і прототипів за допомогою Serena Prototype Composer

Serena Prototype Composer — це потужний засіб планування, моделювання, обгрунтування проектних рішень і розробки прототипів додатків, який можуть використовувати бізнесаналітики, консультанти із додатків та проектувальники для визначення проекту, процесів, робіт, користувацьких інтерфейсів, дій, рішень, даних. Моделі можуть створюватися на основі наявних ресурсів, таких як Webдодатки, і публікуватися як виконувані прототипи або специфікації та описи вимог у стандартному XMLформаті (WordProcessingML), що їх можна переглянути і відредагувати за допомогою Microsoft Word. Під час опису проекту записується його стисла характеристика, вимоги (рис. 4.11), їхні зв’язки між собою та з елементами моделі (процесами, діями, кроками, даними). У разі інтеграції Prototype Composer із засобом керування вимогами Dimensions RM або інтегрованим середовищем розробки Microsoft Visual Studio Team System типи вимог пов’язуються, відповідно, з класами та типами елементів роботи з цих систем.

На основі створених моделей із використанням передбачених у системі або наперед підготовлених у Microsoft Word XMLшаблонів Prototype Composer автоматично генерує специфікації вимог і документи, що описують змодельований додаток з високорівневими графічними зображеннями процесів, картами дій, сторінками користувацького інтерфейсу, а також докладними списками полів даних.

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

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

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

Для проектування користувацьких інтерфейсів можуть використовуватися як можливості самого Prototype Composer, так і наявні Webсторінки. У першому разі поетапно розробляється сторінка інтерфейсу: додається крок інтерфейсу на карті потоку роботи (див. вище), сторінка підганяється за розмірами, встановлюються опції сторінки, додаються панелі для структуризації сторінки, додаються елементи контролю, змінюються їхні мітки і властивості, визначається поведінка зі зміни розмірів. Сторінку інтерфейсу також можна створити автоматично на підставі попередньо визначених кроків і дії зв’язку (див. далі).

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

У Prototype Composer передбачено такі основні типи дій:

— обчислення (Calculate). Підтип «числовий» (Numeric Calculate) подає крок, що оцінює формулу і розраховує на основі вхідних даних єдиний можливий результат. Підтип «рядковий» (String Calculate) — це крок комбінування входів для створення результативного рядка;

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

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

Для перевірки розроблених моделей у Prototype Composer передбачено механізми рецензування. В особи, яка запитує рецензію, і в рецензента має бути встановлена система. Рецензент, зокрема, працює з файлом запиту на рецензію, що його автоматично відкриває Prototype Composer для показу елементів, що їх слід перевірити. Рецензування можна організувати двома способами:

1)за електронною поштою — метод перевірки, згідно з яким визначається особа, якій пересилається електронний лист із вкладеним файлом огляду проекту. Рецензія у відповідь також надсилається електронною поштою. Надісланий файл Prototype Composer відкриває у спеціальному режимі, який дає змогу прочитати і розпорядитися рецензіями. У системі два способи рецензування за електронною поштою:

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

— «автономне» рецензування — всі файли, необхідні для рецензування, упаковуються і надсилаються електронною поштою разом із файлом огляду проекту, що корисно за відсутності у рецензента доступу до файлів проекту в каталозі, що спільно використовується;

2)рецензування за допомогою Business Mashups — системи керування проблемами програмного забезпечення. У разі інтеграції з цією системою підтримується потік робіт з циклу рецензування. У Business Mashups створюється список рецензентів, для кожного з яких визначається нове завдання. Кожне завдання має доданий файл огляду проекту. Сервер Business Mashups — це центральне сховище для всіх файлів, що спільно використовується.

Крім Business Mashups, PrototypeComposer може бути інтегрований з системою керування вимогами DimensionsRM і Microsoft Visual Studio Team System (VSTS). У першому випадку публікуються вимоги, елементи моделі, сценарії та документи. Вимоги з DimensionsRM можна імпортувати в PrototypeComposer, а згодом вимоги в обох системах можуть бути синхронізовані між собою.

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

4.4.3. Організація фабрик програмного забезпечення

Фабрика програмного забезпечення — це лінійка програмних продуктів, що конфігурує розширювані інструменти, процеси і вміст із використанням шаблона фабрики ПЗ, ґрунтовного на схемі фабрики ПЗ, для автоматизації розробки і підтримки варіантів початкового продукту шляхом адаптації, складання і конфігурування основаних на каркасі компонентів (рис. 4.16).

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

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

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

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

Відображення можуть бути таких видів:

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

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

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

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

Сформовану схему фабрики ПЗ можна розглядати як рецепт для побудови сімейства програмних продуктів. Для побудови конкретного програмного продукту її слід сконфігурувати.

Реальна реалізація члена сімейства продуктів передбачає реалізацію схеми фабрики ПЗ шляхом визначення предметноорієнтованої мови (DSL, domainspecific language), шаблонів, каркасів та інструментів, які в ній описані, спакуваши їх і забезпечиши доступ до них для розробників продукту. Разом ці активи становлять шаблон фабрики ПЗ. Цей шаблон містить код і метадані, що їх можна завантажити у розширювані інструменти, подібні інтегрованим середовищам розробки (IDE) або інструментальному комплексу забезпечення життєвого циклу для автоматизації розробки і підтримки членів сімейства. Таким чином, код і метадані конфігурують інструментальні засоби аналогічно тому, як шаблон документа, завантажений в інструмент персонального використання типу Microsoft Word або Excel, конфігурує його для вироблення документа специфічного типу.

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

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

Концепції фабрик ПЗ активно реалізує компанія Microsoft. При цьому слід наголосити, що сам термін трактується вужче — як структурований набір програмних артефактів, що встановлюється у середовище розробки й полегшує роботу архітекторів і розробників з прогнозованого, ефективного та якісного створення додатків певного типу. Фабрики ПЗ Microsoft базуються на розширеннях Visual Studio Guidance Automation Extensions (GAX) та Guidance Automation Toolkit (GAT). Перше з них забезпечує виконання у середовищі розробки спеціальних пакетів (guidance packages), призначених для автоматизації створення різних програмних артефактів. GAT — це набір засобів зі створення таких пакетів.

Команда Microsoft Patterns and Practices Team розробляє такі набори програмних артефактів під загальною назвою фабрик ПЗ, що містять набори компонентів для повторного використання і бібліотеки, шаблони рішень для Visual Studio, майстри і розширення, пояснення («Howto topics»), автоматизовані тести, розширену документацію з архітектури і приклади реалізації:

1)Smart Client Software Factory призначений для спрощення створення складних додатків в архітектурі Smart Client на основі набору рішень з розробки додатків з великим і функціональним інтерфейсом, що використовує можливості Windows Desktop; об’єднання в рамках одного клієнтського додатка кількох серверних бізнесдодатків та обміну даними між ними; відображення інформації, що надходить з різних джерел, в інтегрованому інтерфейсі; використання локальних ресурсів і сховищ для підтримки працездатності додатка у випадках відсутності мережного з’єднання; простих механізмів розгортання і конфігурування додатків. Цей набір керівництв базується на попередніх розробках — бібліотеці функціональних блоків Enterprise Library 2.0 і наборі тісно пов’язаних блоків для створення складних користувацьких інтерфейсів Composite User Interface Application Block, призначених для використання при створенні додатків на основі платформи Microsoft .NET;

2)Web Client Software Factory призначений для підтримки розробки композитних багатих Webдодатків на основі ASP.NET 2.0 і асинхронних JScript та XML (AJAX). Аналогічно Smart Client Software Factory — це модульні (основані на плагінах) Webдодатки підприємства. Web Client Software Factory спрямований на вирішення таких задач, як навігація за сайтом, аутентифікація та авторизація;

3)Web Service Software Factory (часто — Service Factory) призначений для спрощення розробки Webсервісів на основі технології ASMX (частина ASP.NET) і підтримки пов’язаних з цієї розробкою завдань: дизайн повідомлень та інтерфейсів до сервісів, оброблення виняткових ситуацій (exceptions), створення бізнесоб’єктів, перетворення повідомлень для роботи з бізнесоб’єктами, дизайн, створення та використання рівня доступу до даних, можлива міграція на Windows Communication Foundation (WCF) тощо. Керівництва зі створення додатків на основі Webсервісів доступні у форматах документації, пакетів для автоматизації створення програмних артефактів і прикладів. Service Factory призначений для використання як архітекторами, так і розробниками, що відповідають за окремі компоненти сервісного додатка або за додаток у цілому. Розробники одтримують шаблони початкових кодів для реалізації сервісів на основі ASMX;

Література

1. Ветров Ю. Интерактивньїе прототипи. Действующая модель пользовательского интерфейса. часть 1. Классификация — http://www.jvetrau.com/2007/12/04/ interaktivnyieprototipyideystvuyuschayamodelpolzovatelskogointerfeysachast1klassifikatsiya/; часть 2. Подходьі к процессу — http://www.jvetrau.com/2007/12/05/ interaktivnyieprototipyideystvuyuschayamodelpolzovatelskogointerfeysachast2podhodyikprotsessu/; часть 3. Особенности процесса. — http://www.jvetrau.com/2007/ 12/06/interaktivnyieprototipyideystvuyuschayamodel

polzovatelskogointerfeysachast3osobennostiprotsessa/

2. Гринфилд Док., Шорт К, Кук С. и др. Фабрики разработки програми: потоковая сборка типових приложений, моделирование, структури и инструменти. — М.: Издательский дом «Вильямс», 2007. — 592 с.