Б С Бусигін - Прикладна інформатика - страница 17

Страницы:
1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44  45  46  47  48  49  50  51  52  53  54  55  56  57  58  59  60  61  62  63  64  65  66  67  68  69  70  71  72  73  74  75  76  77  78  79  80  81  82  83 

Триярусна архітектура з сервером додатків (рос.-приложений) (three tier with an application server) забезпечує розміщення головного коду додатка для виконання не у середовищі клієнта, а на деякому обраному для використання хості, тобто комп'ютері вузла мережі. Сервер додатків не має і не керується GUI, а тільки виконує бізнес-логіку, обчислення і моделює машину пошуку даних. Перевагою такого підходу є зменшення компонентів програмногозабезпечення користувачів на комп'ютері клієнті і підвищення безпеки функціонування рішень у цілому (рис.6.19).

Рис. б.19. Триярусна архітектура з сервером додатків

Додатки стають більш масштабованими (рос. -масштабируемыми), а вартість (рос. -стоимость) розгортання і підтримки програмних продуктів і систем на одному сервері значно менше, ніж на багаточисельних клієнтах. Таким чином, така архітектура найбільш усього вживається (рос.-применима) при умовах необхідності виконання умов безпеки, масштабованості і зниження вартості роботи системи.

Триярусна архітектура з ORB (three tierwith an ORB architecture) для розподілених обчислень активно розвивається промисловими консорціумами на рівні стандартів, які підвищують інтероперабельність і кросплатформеність додатків, які розроблялися споконвічно (рос. -изначально) на різних мовах програмування для різних платформ. Головною проблемою для стандартів, що обговорюються, є визначення механізмів і елементів реалізації загальних для взаємодіючих систем об'єктних брокерів запитів (Object Request Broker, ORB). На даному етапі розробка клієнт/серверних систем з використанням технологій, що підтримують розподілені об'єкти має величезні перспективи в умовах повсюдного (рос.-повсеместного) розвитку і використання мережних, Інтернет і WWW технологій у суттєво гетерогенних середовищах. Крім підтримки інтероперабельності серед різних мов програмування і платформ, дана архітектура суттєво підвищує експлуатаційну надійність та зручність супроводження (maintainability), а також адаптованість (рос.-адаптируемость) (adaptability) програмного забезпечення, яке створюється . До найбільш розвинутих і тих, які частіше усього використовуються поточним часом відносяться дві наступні технології:

О Брокер запитів загальної об'єктної архітектури (Common Object Request Broker Architecture, CORBA).

© Компонентна об'єктна модель / Розподілена СОМ (COM/DCOM, Component Object Model/Distributed Component Object Model).

Промислові круги активно працюють над стандартами, котрі забезпечили би інтероперабельність поміж CORBA і COM/DCOM. Найбільш активним учасником даного процесу є консорціум Object Management Group (OMG), котрий розробив відображення відповідності (рос. -соответствия) даних і процесів поміж CORBA і COM/DCOM на рівні декількох програмних продуктів.

Розподілена/сумісна промислова архітектура (distributed/collaborative enterprise architecture) була розроблена у 1993 році. Ця програмна архітектура базується на технології застосування об'єктних брокерів запитів (Object Request Broker, ORB), які є продовженням розвитку архітектури CORBA, шляхом застосування сумісно (share) і повторно (reusable) уживаних (рос.-используемьгх) бізнес-моделей (а не просто об'єктів!) у масштабі розподілених підприємств (enterprise-wide scale). Переваги даного підходу містяться у тому, що стандартизовані бізнес-об'єктні моделі (business object models) і розподілені об'єктні обчислення (distributed object computing) комбінуються разом для забезпечення організаційної гнучкості для досягнення операційної і технологічної ефективності у масштабах цілих підприємств.

Глобальна XML архітектура Microsoft (Microsoft Global XML Architecture, MS GXA) є структурою і основою (framework) протоколу, який спроектовано для забезпечення моделі повної сумісності при побудові протоколів інфраструктурного рівня для Web-сервісів і Web-додатків. Web - сервіси - це прикладні сервіси, які уключають програми (додатки), програмування, дані і людські ресурси, котрі зроблені доступними з Web-серверів для Web-користувачів або інших Web-приєднаних програм. У доповнення до цієї головної структури протоколу, GXA визначає сімейство протоколів інфраструктури, які підключаються і котрі забезпечують для функціонуючих у GXA-середовищі додатків найбільш необхідними сервісами, такими, як безпека, надійність і підтримка багаторівневих і багатозв'язних служб погодження (рос.-согласования) їх роботи. GXA підтримує принципи, які об'єднують окремі протоколи GXA-інфраструктури у єдину зв'язану платформу для функціонування сервісів і додатків. Основною передумовою (рос.-предпосьлкой) GXA є ліквідація необхідності для розробників додатків перебудовувати платформу цілком для кожного нового додатку. Ця передумова домінує в моделях розробки на однокомп'ютерних робочих місцях, де 95% програмістів усього світу використовують різні платформи розробки. Традиційний світ однокомп'ютерної розробки ПЗ десятиріччями формалізував методи модуляризації програмного коду і даних, котрі дозволяли здійснити (рос. -осуществить) розподіл поміж додатком і платформою. Світ комунікаційних протоколів також створив свої принципи модулярізації, серед яких найбільш відомим є 7-и рівневий протокол OSI.

Головною ціллю GXA є:

О створення більш загальної моделі для структурування протоколу; Ф розробка сімейства протоколів платформного рівня для розробників додатків, які використовують Web-сервіси і Web-додатки. Так же, як операційна система:

О забезпечує засоби загального використання (рос.-употребления) для роботи програмістам, програмним системам і додаткам; Ф управління процесами і потоками; Ф забезпечує контроль доступу до ресурсів та їх розподіл; Ф управляє пам'яттю,так і GXA забезпечує комплекс загальних засобів, які потрібні у широкому спектрі розробки і використання Web-сервісів і Web-додатків. Мова XML використовується тут для організації і використання даних. SOAP служить для передачі даних у мережах, WSDL застосовується для опису доступних даних, а UDDI використовується для перелічення (рос.-перечисления) доступних сервісів (рис.6.20.).

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

Рис. 6.20. Типова архітектура Web-сервісів

Підводячи підсумки слід додати, що вищевказані архітектури не єдині (рос. -единственные) і не останні. Зараз активно розвивається архітектура безпровідних комунікацій (wireless architecture) на базі адресних сервісів (location services). Ця і деякі інші архітектури розподілених обчислень підтримуються двома потужними архітектурами і відповідними технологіями: Jini™ від Sun Microsystems і .NET™ від Microsoft (див. підрозділ 6.6).

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

6.5 Як проектуються додатки і рішення?

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

Ці нові системи разом з існуючими успадкованими системами (legacy systems) визначають (рос.-предоставляют) критичні для функціонування організацій засоби зберігання, організації, отримання і обробки інформації у тому числі і на урядовому рівні8,. Потенційно, ці системи можуть стати джерелом детальної різнопланової інформації, яка сприяє (рос.-способствует) прийняттю кращих рішень.

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

У софтверній індустрії з урахуванням складності і великого об'єму виконуваних при реалізації крупних додатків додаткових заходів часто останні йменують рішеннями9. Свій великий досвід у розробці бізнес-рішень спеціалісти корпорації Microsoft узагальнили у вигляді комплекса документів з опису Дисципліни розробки рішень (Microsoft Solution Framework, MSF10). MSF містить в собі набір моделей і чітко визначених проектних віх, котрі можна розглядати як рекомендації, рівно як я керівництво по плануванню, веденню і управлінню проектами у сфері інформаційних технологій. Ці моделі — результат інтеграції у єдину систему найбільш успішних і багаторазово застосованих практик, виявлених у процесі аналізу досвіду розробки програмних продуктів, накопиченого не тільки Microsoft, але й її замовниками і партнерами.

Вони не є єдиними (рос.-единственніми) у своєму роді, але на відміну від багатьох інших можуть бути отримані безкоштовно на російській мові.

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

8 B2G, G2C, G2G. Ці абревіатури обозначають нові сфери бізнесу, в котрі, тим чи іншим чином, залучаеться (рос.-вовлечена) держава (Government) і розкриваються як Business-to-Government, Government-to-Citizens, Government-to-Government. Є наслідком включення Держави у процес електронізації усіх видів діяльності. Концепція Electronic Government була оголошена у США на самому високому урядовому рівні першого липня 1997 року.

9 Брандт Д. Architectures. Экзамен - экстерном. (экзамен 70-100). СПБ.: Питер, 2001. - 432 с.

10 Матеріали Microsoft MSF: (http://www.microsoft.com/msf и http://www.microsoft.com/rus/msf )

137

1. Аналіз вимог (рос.-требований)

2. Визначення технічної архітектури

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

Тобто, додаток обов'язково пишеться під конкретний процес і відповідає його бізнес-правилам.

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

6.5.1.Підготовчий етап: аналіз вимог. Розробка рішення починається з аналізу вимог. Цей високорівневий процес збору інформації повинен відповісти на питання: що потрібно зробити, чому це потрібно зробити і який очікується результат. Після чого можна підвести підсумки і зафіксувати вимоги у документації. Повний аналіз вимог дає інформацію, яка описує: О границі проекту;

Ф суть        проблеми (потреби користувачів);

Ф потрібний рівень безпеки; Ф продуктивність (рос.-производитель-ность) додатку;

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

3. Розробка моделі даних

5. Розгортання

4. Розробка додатків

6. Супроводження

Рис. 6.21. Процес розробки прикладної інформаційної системи

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

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

6.5.3.Розробка моделі даних. Технічна архітектура дає уявлення о вимогах до даних, однак вона не дає ніяких вказівок про те, якими повинні бути елементи даних і як їх слід організовувати. Це визначається моделлю даних,котра, в свою чергу, визначається метаданими (metadata), тобто даними о даних. Модель даних визначає усі елементи даних, тобто сутності (entities), а також характеристики — атрибути (attributes) — кожної з них і організацію цих сутностей. Для організації даних існують спеціальні правила нормалізації даних (data normalization rules). Окрім цього модель даних визначає зв'язки (relationships) поміж сутностями, а також спеціальні правила, обмеження (constraints), які використовуються для забезпечення цілісності (integrity) даних.

6.5.4.Разробка проектних частин додатків і рішень. Наступна задача, після того як були розроблені технічна архітектура і модель даних, це розробка проектних частин додатків рішення, тому що власне розробка додатків має на увазі три різних видів діяльності:

О розробку концептуального і логічного проектів додатків; © проектування інтерфейсу і служб користувача; © розробку фізичного проекту.

Більшість людей вважає, що основна діяльність при розробці додатку полягає у написанні і відлагодженню (рос.-отладке) коду (рис. 6.22). Хоча процес написання і відлагодження коду і уявляє собою невід'ємну частину процесу розробки, ця діяльність не може початися до тих пір, поки не будуть готові концептуальний, логічний і фізичний проекти додатків.

Вікно Редактора коду VB з кодом < скриптової мови Visul Basic for Application (VBA) MS Excel (справа) і команди меню відлагодження • (Debug - дебаггер)

Отже, проектування додатків починається з розробки концептуального проекту, котрий базується на бізнес-вимогах і як правило містить сценарії, моделі послідовності дій/процес (workflow/process model) і моделі задача/послідовність (task/ sequence model).

Логічний проект, який витікає далі з концептуального проекту, дає абстрактний високорівневий опис додатку. Логічна модель розбиває додаток на функціональні модулі, які відповідають бізнес-компонентам додатку. Центральною задачею логічного проектування є вичленення і специфікація бізнес-об'єктів, їх властивостей і методів. У термінах MSF моделі додатка ці бізнес-об'єкти звуться службами. Логічний проект визначає служби додатку (application services), що дає додаток. Використання моделей, отриманих у результаті концептуального і логічного проектування, дозволяє дивитися на додаток у термінах бізнес-компонентів і програмної архітектури. Як правило, оцінка логічного проекту робиться по семі ключовим факторам. Більш точні критерії оцінки визначаються конкретним рішенням, однак для логічного проекту найбільш складними є обмеження на:

О продуктивність (рос.-производительность) (performance),

0 супроводжуваність (рос.-сопровождаемостъ) (maintainability),

Ф розширяємість (рос.-расширяемость) (extensibility),

О доступність (availability),

О масштабуємість (рос.-масштабируемость) (scalability)

О безпека (рос.-безопасность) (security),

О відмовостійкість (рос.-отказоустойчивость) (failure-resistance).

До інших, що також впливають на логічний проект вимогам, відносяться:

О практичність (usability)

0 гнучкість (рос.-гибкость) (flexibility)

Ф інтероперабельність (interoperability)

О кросплатформеність (crossplatform)

© переносимість (мобільність, портабельність) (mobility)

О адаптованість (рос.-адаптируемость) (adaptability)

6.5.5.Проектування інтерфейсу і служб користувача. Інтерфейс користувача (UI) уявляє служби для організації повнофункціональної роботи з додатком. Це означає, що він дає засоби (рос.-средства) для виконання наступних

операцій:__

О переміщення компонентів; О виводу даних;

0 уводу даних; © маніпулювання з даними;

Ф уявлення даних;__© допомоги користувачу (help)._

У залежності від фізичної реалізації, інтерфейс користувача може бути частиною додатку, а може бути окремим клієнтським додатком. Крім того, він може бути й набором кодів, що містять сценарії Web-сторінок, які потім відображаються у браузере. Під «користувачем» додатка як правило розуміється людина, яка користується додатком. Тому під інтерфейсом користувача розуміються форми, елементи управління (меню, кнопки, вікна і т.д.), звіти (рос.-отчеты) та інші об'єкти, що даються кінцевому користувачу для взаємодії з додатком. Однак «користувач» додатку не обов'язково означаєлюдину: будь який додаток також можна розглядати, як користувача. В цьому випадку під інтерфейсом користувача розуміється засіб взаємодії поміж програмами, який забезпечує сумісну роботу додатків.

Страницы:
1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44  45  46  47  48  49  50  51  52  53  54  55  56  57  58  59  60  61  62  63  64  65  66  67  68  69  70  71  72  73  74  75  76  77  78  79  80  81  82  83 


Похожие статьи

Б С Бусигін - Прикладна інформатика