Posibniki.com.uaІнформатикаАвтоматизоване проектування інформаційних систем4.4. АВТОМАТИЗАЦІЯ ПРОТОТИПУВАННЯ ІНФОРМАЦІЙНИХ СИСТЕМ


< Попередня  Змiст  Наступна >

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


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

 

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

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

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

— еволюційне (evolutionary prototyping, breadboard prototyping) — послідовне створення макетів, що поступово наближаються до реальної готової системи. Цей підхід застосовують за відсутності необхідних вимог до системи, вони формуються впродовж її реалізації. При цьому час і зусилля не марнуються, а в деяких випадках користувач розпочинає використовувати систему до досягнення її повної готовності;

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

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

Для розробки прототипів застосовують методи розробки динамічних систем (Dynamic systems development method, DSDM), операційного прототипування (Operational prototyping), розробки еволюційних систем (Evolutionary systems development), еволюційної швидкої розробки (Evolutionary rapid development, ERD), Scrum.

Послідовність робіт зі створення прототипу може варіювати залежно від особливостей модельованого додатку (див. приклад у табл. 4.1).

ОСОБЛИВОСТІ ПРОТОТИПУВАННЯ WEB-ДОДАТКІВ

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

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

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

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

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

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

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

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

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

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

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

— Adobe Creative Suite. Adobe Photoshop, растровий графічний редактор, та Adobe Illustrator, векторний графічний редактор, залишаються стандартами у сфері графічного дизайну, в тому числі графічного користувацького інтерфейсу і Webсторінок. Adobe InDesign — провідна видавнича система (DTP), — є одним з найпопулярніших засобів прототипування (див. приклад на рис. 4.6). Для підготовки HTMLпрототипів можна використовувати можливості менш популярного Adobe ImageReady;

Приклад екрану прототипу, створеного в Adobe InDesign

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

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

Axure RP Pro (раніше — Ubiquity RP) — широковідомий засіб створення структурних схем сторінок (wireframe, website wireframe), швидкого прототипування і специфікацій, зорієнтований на настільні та Webдодатки. Axure RP Pro є прикладом функціональної простоти, користувач оперує не поняттями проектів або діаграм, а сторінками, що організовані в дерево (рис. 4.7).

Ієрархія сторінок у вікні Axure RP Pro

У системі повною мірою реалізовано принцип «перетягни і кинь» (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, iRise Server, iRise Reader та iRise iDoc (рис. 4.8).

Схема взаємодії продуктів сімейства iRise

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

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

До функцій сервера також входить відстежування вимог, дефектів, контрольних прикладів та іншої інформації щодо проекту, для отримання якої потрібний лише Webбраузер. Сервер також забезпечує взаємодію і синхронізацію робіт між собою за допомогою операцій checkin/out, а також синхронізацію із сервером керування вимогами. Кожен елемент екрана прототипу пов’язаний з певною вимогою (вказівкою до проектування), визначеною на окремій панелі. На цій основі можна відстежити виконання вимог і обґрунтувати будьяке проектне рішення. Для кожної характеристики доступна інформація про її статус, включно з відповідальною особою. Авторизовані користувачі можуть редагувати вимоги, позначати дефекти та визначати тестові сценарії.

Зимітований додаток можна експортувати у файли формату PDF або відокремлені HTMLфайли. Можливість генерування коду або моделей UML (див. тему 5) не передбачена, але сформовані вимоги можна передати до інших засобів, зокрема IBM Rational RequisitePro (див. п. 3.5) та Borland Together ControlCenter за допомогою плагінів.

Слід також зазначити, що iRise належить до дуже дорогих систем.

ProtoShare (розробник — Site9, Inc.) позиціонується як система забезпечення групової роботи, призначена для створення, перегляду та вдосконалення прототипів webсайтів і webдодатків. За її допомогою окремі особи і компанії не тільки можуть розробляти структурні схеми Webсторінок і прототипи додатків, а й переглядати їх та коментувати у режимі реального часу. Саме акцент на обговоренні прототипу (рис. 4.9), та формалізації процесу його затвердження є відмітною рисою системи.

Організація дискусій у ProtoShare

ProtoShare базується на HTML, CSS та Javascript і доступна в онлайн режимі як SaaSсистема (SoftwareasaService, програмне забезпечення як сервіс ) або як самопровідний засіб (selfhosted ) для підприємства. Підстави для такого визначення створюють схеми, доступні для клацання, та креативні огляди (creative reviews) — структурні схеми демонструють навігацію за сайтом за допомогою динамічних меню, a WYSIWYGінтерфейс надає можливість будьякому користувачеві за допомогою операцій «перетягни і кинь» організувати вибрані компоненти на полотні, встановити їх розмір і розташування, і подати для розгляду іншим учасникам команди для перегляду і коментування.

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

Перевагою і водночас недоліком ProtoShare є те, що це Webдодаток. З одного боку, це зумовлює відсутність необхідності у встановленні додаткового програмного забезпечення і кросплатформовість — забезпечено сумісність с операційними системами Windows і Мас OS, а також браузерами Internet Explorer, Firefox, Safari, Chrome та ін. З іншого боку, система працює доволі повільно.

Серед інших засобів визначення та імітації додатків слід назвати потужну вільну систему Serena Prototype Composer (див. докладніше п. 4.4.2), Intuitect Professional, який можна використовувати як додаток до Microsoft Visio Professional 2003, Justinmind Prototyper, Simunication Enterprise Simulator, Sofea Profesy.

Прикладом CASEзасобу, що використовується для прототипування, є AREW (Advanced Requirements Engineering Workstation, раніше — Requirements Engineering Environment, середовище інжинірингу вимог), призначене для швидкого подання, побудови і виконання моделей критичних аспектів складних систем. Раніше його застосовували у військовоповітряних силах. Цей інтегрований набір засобів підтримує специфікацію вимог, імітування, прототипування користувацького інтерфейсу, відображення вимог на архітектуру технічного забезпечення і генерування коду. Моделі можуть розроблятися з різним рівнем абстрагування залежно від аспектів, що досліджуються.

AREW складається з трьох частин — CASEзасобу підтримки швидкого прототипування proto, системи швидкого прототипування інтерфейсу RIP (Rapid Interface Prototyping System) та користувацького інтерфейсу до RIP і proto. Автоматизується методологія збирання вимог, що розроблена лабораторією Rome Laboratory і передбачає виконання трьох етапів: добування вимог з різних джерел, їх специфікація і перевірка узгодженості; аналіз вимог на предмет виявлення конфліктів, технічних та економічних можливостей їх реалізації; перевірка відповідності вимог потребам користувачів.

Іншим об’єктноорієнтованим засобом, який поєднує функції візуалізації і швидкого прототипування, є середовище розробки програмного забезпечення LYMB (розробник — General Electric Research and Development Center). Структуру середовища унаочнено нарис. 4.10.

Структура LYMB

Основні характеристики LYMB:

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

— швидке створення прототипів досягається шляхом комбінації середовища інтерпретації та класів об’єктів, що компілюються для швидкого виконання;

— портативне середовище, зорієнтоване на робочі станції Unix, включаючи HP, Sun, SGI, DEC, IBM. Також розробляється версія для використання на персональних комп’ютерах з операційними системами Windows;

— вбудований механізм розподілу додатків за мережею серверів і клієнтів.

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

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

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

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

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

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

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

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

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

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

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

Докладніше організацію фабрик ПЗ описано у п. 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 типи вимог пов’язуються, відповідно, з класами та типами елементів роботи з цих систем.

Список вимог Prototype Composer

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

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

Prototype Composer підтримує спільне використання файлів проекту кількома користувачами, зберігаючи їх у мережі і виконуючи прості функції синхронізації checkin/checkout (див. про забезпечення паралельної розробки п. 6.2.6).

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

Карта потоку процесу (process flow map) — це графічне відображення логіки бізнеспроцесу. Спеціальний редактор подає її як набір функцій, розташованих на горизонтальних «плавальних доріжках» (swimlanes), що відповідають задіяним аудиторіям, з лініями потоків, кроками прийняття рішень і дій, що визначають логіку переходів між роботами. Таким способом подаються потоки між аудиторіями.

Кожен крок процесу на карті представлено іконкою, що відповідає його типу і функції (див. рис. 4.12).

Карта потоків процесу Prototype Composer

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

Кроки на карті роботи Prototype Composer

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

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

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

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

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

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

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

— зв’язку (Connect). Підтип «здійснити» (Connect Execute) подає виконання певної функції у зовнішній системі, наприклад оброблення замовлення, отриманого через інтернетмагазин, у наявній ERPсистемі. Підтип «пошук» (Connect Lookup) — перегляд інформації у зовнішній базі даних або іншій системі, наприклад пошук даних про працівника у системі обліку кадрів. Підтип «оновлення» (Connect Update) подає крок, що використовується для коригування інформації у зовнішній базі даних або іншій системі, наприклад, профілю клієнта у CRMсистемі. Відмінності між вказаними підтипами є концептуальними, при реалізації вони мають однакову кількість входів і виходів;

- ручна (Manual) — традиційна робота, що виконується без прямої взаємодії з ІС. Єдиний визначений у системі підтип «завдання» (Task) використовується для створення списку завдань, які треба виконати.

Рішення у Prototype Composer використовують для визначення бізнесправил, на підставі яких у процесах і роботах обираються потоки (рис. 4.14). У спеціальному редакторі для кожного рішення створюється список гілок, для кожної з них встановлюється правило, виконання якого перевіряє система. Остання гілка подає варіант «в іншому випадку», навіть якщо користувач назвав її інакше, і перевірка відповідного правила завжди дає результат «істина». Під час симуляції або прототипування правила перевіряються по порядку згори вниз, вибирається потік відповідно до найпершої гілки, для якої правило виявилось істинним.

З кожною роботою асоціюються певні групи і поля даних. Усі дані поділяють натри категорії (рис. 4.15):

— робочі дані (working data) — це дані, автоматично створені на основі виходів дій, що лежать на потоці роботи. Кожен раз при розміщенні нового кроку, що має виходи, на карті роботи або при визначенні нового виходу для наявного кроку, відповідні групи даних і поля даних автоматично записуються як дані роботи. Ці поля даних можна визначити як входи для наступних кроків;

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

— виходи (outputs) задаються користувачем. Виходи кроків подають дані, що виробляються роботою під час її виконання. Поля виходів роботи мають бути увідповіднені даним роботи для визначення джерел їх значень під час симуляції та прототипування.

Визначення рішень у Prototype Comproser

Входи, робочі дані та виходи роботи

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

Для перевірки розроблених моделей у 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, у ній стовпці визначають обмеження, а рядки — рівні абстракції.

 

Таблиця 4.2

 

ПРИКЛАД СІТКИ

ДЛЯ КАТЕГОРИЗАЦІЇ АРТЕФАКТІВ РОЗРОБКИ

 

― Сценарії і варіанти використання

― Бізнесцілі і наміри

― Бізнес-сутності і відношення

― Бізнес-процеси

― Виробництво служб

― Розподіл служб

― Якість стратегії служб

― Моделі робочих потоків

― Визначення ролей

― Схеми повідомлень і специфікації документів

― Взаємодія служб

― Визначення служб

― Об’єктні     моделі

― Типи                     логічних серверів

― Відображення служб

― Специфікації процесу

― Схеми баз даних

― Стратегія доступу до даних

― Детальний дизайн

― Дизайн, залежний від технології

― Фізичні                        сервери

― Встановлене програмне                           забезпечення

― Організація мережі

 

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

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

Схема фабрики програмного забезпечення

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

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

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

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

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

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

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

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

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

Реальна реалізація члена сімейства продуктів передбачає реалізацію схеми фабрики ПЗ шляхом визначення предметноорієнтованої мови (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;

4) Mobile Client Software Factory призначений для створення складних Windows Mobile бізнесдодатків. Такі додатки можуть взаємодіяти з серверними додатками через різноманітні засоби комунікацій, такі як WiFi та GPRS, й успішно забезпечувати роботу в умовах переривчастого зв’язку.

 

Резюме

 

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


Література

 

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 с.

3. Коноплицкий П. Прототипирование webсайтов. Собирая воєдино. — http://www.amazedev.com/prototipirovaniewebproektovsobirayavoedino/

4. Офіційні матеріали з фабрик ПЗ компанії Microsoft — http:// msdn.microsoft.com/enus/library/bb977473(v=MSDN. 10).aspx

5. Офіційні сайти розробників проблемноорієнтованих інформаційних систем:

http://cognexus.org/ http://projects.kmi.open.ac.uk/osc/compendium/

6. Офіційні сайти розробників засобів проектування користувацького інтерфейсу:

http://office.microsoft.com/enus/visio http://www.axure.com http://www.adobe.com/products/photoshop/photoshop http://www.elegancetech.com/LS/LS.aspx http://www.irise.com/products/diagram.php http://justinmind.com/wireframe http://www.protoshare.com/

http://www. serena.com/products/prototypecomposer/ http://www.simunication.com/ http://www.sofeainc.com/

http://www.intuitect.com/products/intuitectprofessional.php http://www.omnigroup.com/applications/omnigraffle/

7. Сергеев A. Axure RP Pro — средство для прототипирования. — http://guicci.ru/2006/12/08/axurerpprosredstvodlyaprototipirovaniya/

8. Федоров A. Software Factories — бнстрьій способ создания шаблонов приложений // КомпьютерПресс. — 2007, — № 2.

9. Garrett J. J. The Elements of User Experience. — http://www.jjg. net/elements/pdf/elements.pdf

10. McDowell Sc. Visio Replacement? You Be the Judge. An Introduction to the Newest Simulation Tools. — http://www.boxesandarrows.com/ view/ vis io rep laceme


< Попередня  Змiст  Наступна >
Iншi роздiли:
5.2. АВТОМАТИЗАЦІЯ АНАЛІЗУ ТА ПРОЕКТУВАННЯ ЗА ДОПОМОГОЮ IBM RATIONAL ROSE
5.2.2. Функціональне моделювання
5.2.3. Моделювання взаємодії обєктів
5.2.4. Логічна модель системи
4.2. АВТОМАТИЗОВАНА ПІДТРИМКА ГРУПОВОГО ПРОЕКТУВАННЯ
Тема 4. АВТОМАТИЗОВАНА ПІДТРИМКА ПРИЙНЯТТЯ ПРОЕКТНИХ РІШЕНЬ
3.5. КЕРУВАННЯ ВИМОГАМИ ЗА ДОПОМОГОЮ IBM RATIONAL REQUISITEPRO
3.4. ХАРАКТЕРИСТИКА СУЧАСНИХ ЗАСОБІВ АВТОМАТИЗОВАНОГО КЕРУВАННЯ ВИМОГАМИ
3.3. АВТОМАТИЗОВАНЕ КЕРУВАННЯ ЗМІНАМИ ВИМОГ
Дисциплiни

Англійська моваБанківська справаБухгалтерський облікЕкономікаМікроекономікаМакроекономікаЕтика та естетикаІнформатикаІсторіяМаркетингМенеджментПолітологіяПравоСтатистикаФілософіяФінанси

Бібліотека підручників та статтей Posibniki