31993

Побудова бази маркетингового дослідження за клієнт-серверною технологією

Дипломная

Информатика, кибернетика и программирование

0 Інші Об’єкти Реляційні дані XML Програма LINQ to SQL SQL Server LINQ запит SQL запит Записи Об’єкти Керуючий додаток синхронізації Служба синхронізації Служба синхронізації Сеанс синхронізації Сховище даних Сховище даних WEBсайт Сервіс синхронізації WEBСервіс Мобільний пристрій Сервер БД ЗМІСТ ВСТУП 9 Постановка задачі .22 Вибір системи керування базами даних . 55 Вибір технології доступу до даних . 69 Вибір технологій доступу до даних .

Украинкский

2013-09-01

1.93 MB

3 чел.

PAGE   \* MERGEFORMAT 7


.NET Language Integrated Query

LINQ    To Objects

LINQ    To Entities

LINQ    To XML

INQ    To Dataset

LINQ    To SQL

C# 3.0

VB 9.0

Інші

Об’єкти

Реляційні дані

XML

Програма

LINQ to SQL

SQL Server

LINQ запит

SQL запит

Записи

Об’єкти

Керуючий додаток синхронізації

Служба синхронізації

Служба синхронізації

Сеанс синхронізації

Сховище даних

Сховище даних

WEB-сайт

Сервіс синхронізації

WEB-Сервіс

Мобільний пристрій

Сервер БД

ЗМІСТ

ВСТУП ……………………………………………………………………………… 9

  1.  Постановка задачі …………………………………………………………... 11
    1.  Описання проблеми …………………………………………………. .11
      1.  Дослідження предметної області …………………………….. 11
      2.  Огляд існуючих інструментів автоматизації ………………... 14
    2.  Опис вимог до функціональності ……………………………….….. 14
    3.  Визначення основної функціональності …………………………….15
      1.  Функціональність серверної частини ……………………..…. 16
      2.  Функціональність клієнтської частини ……………………….16
  2.  Дослідження інструментів реалізації ………………………………………17
    1.  Аналіз методологій розробки програмного забезпечення ……….. 17
      1.   Методологія  Microsoft Solution Framework ……………….. 17
      2.   Ітеративна розробка ………………………………………….. 18
      3.  Методологія Rapid Application Development ……………….. 18
      4.  Методологія Rational Unified Process ……………………..… 19
      5.  Методологія Extreme Programming …………………………. 20
      6.  Agile – гнучка методологія розробки …………………….… 21
      7.  Висновок ……………………………………………………… 21
    2.  Порівняльний аналіз програмних технологій .NET та CORBA ….22
    3.  Вибір системи керування базами даних …………………………... 49
      1.  Визначення критеріїв порівняння …………………………... 49
      2.  Порівняльний аналіз СКБД MS SQL Server та Oracle …..… 55
    4.  Вибір технології доступу до даних ……………………………….. 60
      1.  Огляд технології Language Integrated Query (LINQ) ……... 62
      2.  Огляд технології ADO.NET Entity Framework ……………. 65
      3.  Огляд технології ADO.NET Data Services …………………. 67
      4.  Огляд технології Sync Framework ………………………….. 69
      5.  Вибір технологій доступу до даних ………………………... 71
    5.  Визначення інструментів для розробки проекту ……………….... 72
  3.  Реалізація проекту ………………………………………………………… 73
    1.  Загальна схема проекту ……………………………………………. 73
      1.  Компонент зберігання інформації (глобально) …………..... 73
      2.  Компонент взаємодії адмінчастини з базою даних ………..  74
      3.  Адміністративна частина ……………………………………. 74
      4.  Компонент зберігання інформації (локально) ………… ….. 75
      5.  Компонент взаємодії клієнтської частини з базою …… ….. 75
      6.  Клієнтська частина ………………………………………. …. 76
    2.  Сценарій роботи системи ………………………………………..… 78
    3.  Проектування бази даних ……………………………………….….82
      1.  Концептуальний рівень ……………………………………... 83
      2.  Логічний рівень ……………………………………………… 86
      3.  Фізичний рівень ……………………………………………... 87
    4.  Реалізація функціональності системи …………………………….  88
      1.  Визначення функціональних пріоритетів ………………….. 88
      2.  Об’єктна модель системи ………………………………….. 100
  4.  ВИСНОВОК ……………………………………………………………… 105
  5.  ЛІТЕРАТУРА ……………………………………………………………. 107
  6.  ДОДАТОК А. Лістинг коду основних компонентів ………………….. 109

ВСТУП

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

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

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

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

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

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

  1.  ПОСТАНОВКА ЗАДАЧІ

  1.  Описання проблеми

  1.   Дослідження предметної області

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

  •  Які проекти потрібно в першу черги розвивати і в яких напрямках;
  •  Що потрібно змінити, модернізувати;
  •  Які послуги варто призупинити/закрити;
  •  Які нововведення варто впровадити;
  •  Як найефективніше розподілити фінансування різних напрямків організації.

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

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

  1.  Визначення необхідності певної інформації;
  2.  Отримання інформації;
  3.  Аналіз;
  4.  Видача результатів.

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

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

Будь-яке маркетингове опитування потребує виконання певної послідовності дій (етапів). Ось основні з них:

  •  Концептуалізація – визначення мети дослідження, висування гіпотез, уточнення понять і знаходження їх операціональних відповідностей у даному опитуванні.
  •  Схематизація – встановлення процедур, які повинні бути застосовані під час опитування, і прийняття розв'язків про характер необхідної вибірки.
  •  Підготовка інструментарію – складання анкети або бланка інтерв'ю, визначення числа й порядку питань, підготовка необхідних наочних знарядь або будь-яких інших підсобних засобів.
  •  Планування – розгляд фінансових, адміністративних, матеріально-технічних і кадрових проблем, пов'язаних із проведенням опитування.
  •  Побудова вибірки – відбір передбачуваних респондентів відповідно до тем з методів, який краще підходить для цілей і засобів дослідження.
  •  Інструктаж – підготовка інтерв'юерів і іншого обслуговуючого опитування персоналу до роботи з респондентами й до обробки даних; постачання персоналу необхідними матеріальними засобами.
  •  Попереднє тестування – випробування обраного інструментарію на вибірці малих розмірів з метою перевірки правильності розуміння респондентами інструкцій і питань, а також перевірки відповідності їх відповідей очікуваному типу питань.
  •  Опитування – поштове, телефонне або очне опитування учасників вибірки із застосуванням пілотажного інструментарію.
  •  Спостереження за ходом опитування (моніторинг) – перевірка коректності застосування методики, що опитують, а також контроль за тим, щоб були опитані тільки учасники вибірки.
  •  Контрольна перевірка – перевірка (за допомогою додаткових контактів з респондентами) того, чи всі члени вибірки виявилися реально охоплені опитуванням і всі чи з них повернули свої анкети.
  •  Кодування – перетворення зібраних даних у числову форму.
  •  Обробка – підготовка даних для аналізу
  •  Аналіз – переробка даних за допомогою статистичних і інших засобів з метою одержання змістовних висновків.
  •  Складання звіту – виклад результатів аналізу у формі дослідницького звіту.

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

  1.   Огляд існуючих інструментів автоматизації

На даний момент існує програмне забезпечення, що реалізує певний функціонал в даній сфері. Наприклад, програма «Пріс». За її допомогою можна створювати опитування, вводити інформацію по проведених опитуваннях та аналізувати результати. Формат реалізації програми – Windows-додаток. Встановлюється безпосередньо на комп’ютер під керівництвом операційної системи Windows. Працює з файлами Excel. Ліцензія на один екземпляр програми коштує приблизно 250грн. Ще один з інструментів проведення опитувань – «Соцопрос». Програма також дозволяє створювати нові опитування, дані зберігає в базі даних Access, що також потребує додаткової інсталяції екземпляру Microsoft Office. Працює під керівництвом операційних систем сімейства Windows. Аналітичних функцій по обробці результатів опитування практично немає. Ліцензія одного екземпляру коштує також приблизно 250грн.

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

  1.  Опис вимог до функціональності

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

Кінцевий програмний продукт має задовольняти деякий ряд вимог:

  •  Система повинна передбачати отримання даних з певних джерел;
  •  Інформація має надходити до кінцевої точки незалежно від місцезнаходження джерела (мобільність);
  •  Кількість процесів отримання інформації, що виконуються одночасно повинні обмежуватись лише апаратними засобами системи (робота з багатьма джерелами);
  •  Використання технології «клієнт-сервер»;
  •  Отримання даних та первинна обробка здійснюються на клієнті;
  •  Основна обробка та аналіз даних виконується на сервері;
  •  Для збереження даних використовується СУБД;
  •  Клієнт повинен мати можливість приймати отримувати дані незалежно від наявності зв’язку із сервером;
  •  Система має передбачати інтерфейс для перегляду оброблених та проаналізованих даних, адміністрування та моніторингу протікаючи процесів;
  •  Термін – 2 місяці;
  •  Бюджет – 5000у.о.

1.3. Визначення основної функціональності

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

  •  Створення опитувань;
  •  Керування параметрами опитувань;
  •  Розподіл опитувань між інтерв’юерами;
  •  Моніторинг процесів;
  •  Імпорт опитувань, створених замовником в систему;
  •  Можливість отримання даних від джерела та збереження в системі;
  •  Безпечне зберігання інформації;
  •  Відображення результатів (статистики);
  •  Можливість автономної роботи (без постійного зв’язку з сервером);
  •  Реалізація безпеки даних (шифрування, авторизація);
  •  Синхронізація сервера з клієнтом.

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

1.3.1. Функціональність серверної частини

  •  Створення опитувань;
  •  Керування параметрами опитувань;
  •  Розподіл опитувань між інтерв’юерами;
  •  Моніторинг процесів;
  •  Імпорт опитувань, створених замовником в систему;
  •  Відображення  результатів (статистики);
  •  Реалізація безпеки даних.

1.3.2. Функціональність клієнтської частини

  •  Отримання інформації безпосередньо від джерела;
  •  Автономна робота;
  •  Первинна обробка даних;
  •  Перетворення інформації в потрібний формат;
  •  Пересилання даних на сервер.

  1.  ДОСЛІДЖЕННЯ ІНСТРУМЕНТІВ РЕАЛІЗАЦІЇ

2.1. Аналіз методологій розробки програмного забезпечення

2.1.1. MSF  (Microsoft Solutions Framework)

Основні принципи:

  •  Розподіл відповідальності при фіксації звітності
  •  Надання членам команди повноваженнями
  •  Концентрація на бізнес-пріорітетах
  •  Єдине бачення проекту
  •  Готовність до внесення змін
  •  Вільне спілкування

Етапи розробки:

  •  Вибірка концепції
  •  Планування
  •  Розробка
  •  Стабілізація
  •  Впровадження

Критерії використання:

  •  Складний проект
  •  Відносно великий бюджет
  •  Наявність відносно великої команди
  •  Недостатньо чітке формулювання вимог

2.1.2. Ітеративна розробка

Основні принципи:

  •  Зниження ризиків на ранніх стадіях проекту
  •  Ефективний зворотній зв’язок проектної команди із замовником
  •  Акцент зусиль на найбільш важливі та критичні напрямки проекту
  •  Безперервне ітеративне тестування
  •  Рівномірне навантаження на учасників проекту

Етапи розробки:

  •  Розробка вимог
  •  Аналіз та дизайн
  •  Реалізація
  •  Тестування
  •  Впровадження

Критерії використання:

  •  Довготривалий проект
  •  В кінці кожного етапу (ітерації) проект має бути готовим до використання
  •  Можливість підтримувати ефективний зв’язок із замовником

2.1.3. Rapid Application Development - швидка розробка додатків

Основні принципи:

  •  Використання інструментарію, направленого на мінімізацію часу розробки
  •  Створення прототипу для більш чіткого узгодження із замовником
  •  Мінімізація часу розробки за рахунок модернізації вже готових модулів
  •  Тісна співпраця розробників
  •  Управління проектом повинно мінімізувати довжину циклу розробки

Етапи розробки:

  •  Аналіз та планування вимог
  •  Проектування
  •  Розробка
  •  Впровадження

Критерії використання:

  •  Важлива швидкість розробки (до 90 днів)
  •  Невисока деталізація вимог до проекту
  •  Обмежений бюджет проекту
  •  Проект може бути розбитий на декілька функціональних компонентів
  •  ПЗ не має великої обчислювальної складності

2.1.4. RUP (Rational Unified Process)

Основні принципи:

  •  Швидка ідентифікація та безперервне усунення ризиків
  •  Концентрація на виконанні вимог замовника
  •  Очікування змін у вимогах, проектних рішеннях
  •  Компонентна архітектура, що реалізується та тестується на ранніх стадіях проекту
  •  Постійна підтримка якості на усіх етапах розробки
  •  Ключова роль в команді розробки належить архітекторам

Етапи розробки:

  •  Бізнес-моделювання
  •  Управління вимогами
  •  Аналіз та проектування
  •  Реалізація
  •  Тестування
  •  Впровадження

Критерії використання:

  •  Складний проект
  •  Нечітке описання вимог
  •  Основна частина роботи припадає на архітекторів

2.1.5. XP (Extreme Programming) - екстремальне програмування

Основні принципи:

  •  Розробка через тестування
  •  Гра в планування
  •  Замовник завжди поруч
  •  Парне програмування
  •  Безперервна інтеграція
  •  Рефакторінг
  •  Часті невеликі релізи
  •  Колективне володіння кодом
  •  Стандарт кодування

Етапи розробки:

  •  Планування релізу
  •  Розробка
  •  Випуск

Критерії використання:

  •  Стислі строки
  •  Невеликий проект
  •  Невелика команда розробників
  •  Різна кваліфікація членів команди

2.1.6 Agile - Гнучка методологія розробки

Основні принципи:

  •  Ітеративність та інкрементальність розробки
  •  Мінімізація ризиків
  •  Кожна ітерація завершується робочим продуктом
  •  Безпосереднє спілкування команди
  •  Зменшений обсяг письмової документації

Етапи розробки:

  •  Планування
  •  Аналіз вимог
  •  Проектування
  •  Кодування
  •  Тестування
  •  Документування
  •  Впровадження

Критерії використання:

  •  Нечітке описання вимог до проекту
  •  Необхідність на кожному етапі (ітерації) підтримувати проект в робочому стані
  •  Можливість команди спілкуватися безпосередньо між собою

2.1.7. Висновок

Виходячи з вимог до проекту, бюджет проекту невисокий. Відповідно, кількість членів команди також не буде великою. При терміні реалізації проекту в 2 календарні місяці потрібно вибрати ту методологію розробки програмного забезпечення, що дозволила б створити повноцінний продукт невеликою командою та в короткі строки. Також, враховуючи те, що проект відносно невеликий, в даному випадку можна виділи дві методології, що задовольнять цим вимогам: RAD (швидка розробка додатків) та XP (екстремальне програмування). Остання не вимагає більш-менш чіткого описання проекту, скоріше пропонує контролювати відповідність проекту вимогам за допомогою написання окремих тестів. В той самий час метод швидкої розробки дає можливість більш детально спроектувати етапи розробки, що дозволить дотримуватись певного плану в процесі роботи. Також, метод передбачає використання інструментальних засобів візуального моделювання та розробки, автоматичної генерації коду та готових компонентів, що можуть бути задіяні в даному проекті. Отже, найбільш актуальним в даному випадку методом розробки є RAD (швидка розробка додатків).

2.2. Порівняльний аналіз програмних технологій .NET та CORBA

Основними критеріями вибору програмних технологій для порівняння були висока надійність, стабільність технології та можливість швидкого створення повноцінних функціональних рішень. В кінцевому результаті для порівняння було вибрано дві сучасні програмні технології, що можуть бути використані для створення потужних інформаційних систем - .NET та CORBA. Дослідження буде проводитись за найбільш вагомими параметрами технології відносно даного проекту.

Доступ до реляційних баз даних.

  •  .Net

Основою доступу до баз даних технології .Net є бібліотека ADO.NET. З її допомогою можна отримати доступ до джерел даних використовуючи OLE DB провайдери, .Net провайдери або XML. З реляційними даними можна робити всі необхідні операції (вибірку, додавання, оновлення, видалення і т.д.).

В ADO.NET чітко розділяється доступ до даних і різні операції з даними за допомогою виділення різних функцій у компоненти, які можуть використовуватись окремо або разом. Результати вибірок можуть бути оброблені відразу, або можуть бути занесені в ADO.NET Dataset. Результати можуть бути сконструйовані із запитів до гетерогенних або розподілених баз даних. Причому, Dataset є частиною реляційної бази даних, що складається з колекції таблиць, і містить усі зв'язки цих таблиць, первинні ключі, індекси і т.д. Для обробки локальних даних або даних отриманих з XML, Dataset можна використовувати незалежно від провайдера даних (джерела даних).

ADO.NET підтримує нову програмну модель. Можна відзначити деякі ключові особливості моделі, такі як: можливість роботи з кешованими даними (disconnected data architecture), тісна інтеграція з XML (класи XML в. NET Framework і ADO.NET - частини архітектури системи), єдина модель відображення даних з можливістю комбінувати дані з різних і мінливих джерел даних, можливість оптимізації в ключових точках доступу до даних конкретних СКБД, багаторівнева архітектура додатків підтримується бібліотекою класів. Об'єкти класів ADO.NET можуть бути передані як за посиланням, так і за значенням. Розробники об'єктної моделі ADO.Net забезпечили сумісність із попередньою версією бібліотеки - ADO, тому програмістам не потрібно перенавчатись при переході на нову версію.

  •  Java-corba

Модель доступу до даным відрізняється від .Net тим, що замість Dataset і інших класів загального призначення, що здійснюють доступ до даних, створюються різні перехідники до конкретних структур реляційних і об'єктних баз даних. Наприклад, створюється клас, який представляє абсолютно конкретну таблицю або з'єднання таблиць бази даних. З реалізацій систем доступу до даних можна назвати служби доступу до об'єктно-реляційних баз даних на основі Oracle 8і. Але в цьому випадку знову ж, класи в програмі і їх екземпляри представляють собою зовсім конкретні об'єкти бази даних.

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

Очевидно, на практиці краще підхід прийнятий технологією .Net, тому що використання стандартних компонентів дозволяє швидше створити комерційні програмні продукти.

Доступ до об'єктів в інших процесах, на різних комп'ютерах і мережах.

  •  .Net

Підтримуються два типи додатків, що здійснюють міжпроцесорну взаємодію і видалений виклик об'єктів:

1. ASP.NET це інфраструктура, керована Internet Information Services (IIS). Підтримуються базові типи (класи). Додатки на основі технології ASP добре відомі розробникам програмного забезпечення, що використовували попередню версію бібліотеки.

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

Інфраструктура remoting - абстрактний опис процесу міжпроцесорних комунікацій. Забезпечена повна прозорість цього процесу. Пошук об'єктів, що перебувають поза доменом додатка проводиться за допомогою URL. Це активаційні URL, які самі унікальні й представляють унікальні типи (об'єктів). За допомогою активаційних URL можна безпомилково викликати саме ті типи об'єктів, які необхідні для виконання функцій додатка. Далі, об'єкти, які можуть бути передані за значенням або скопійовані, автоматично передаються між додатками в різних доменах або на різних комп'ютерах. Необхідно тільки позначити класи як serializable.

Реальна міць remoting полягає в можливості взаємодії об'єктів, що перебувають у різних доменах додатків або процесах з використанням різних транспортних протоколів, різних форматів сериализации, схем життєвого циклу об'єктів і способів створення об'єктів. До того ж, можливо втручатися в цей процес на будь-якій стадії (підключати додаткові модулі, змінювати параметри і т.д.). Підтримуються два стандартні канали передачі даних: Tcpchannel і Httpchannel. Також, можуть реєструватися будь-які інші канали. І по HTTP і по TCP каналам повідомлення можуть транспортуватися як із застосуванням протоколу SOAP, так і у двійковому форматі. Крім того, можна підключати свої форматери повідомлень для інших форматів передачі даних. Вибір каналу визначається такими факторами, як швидкість передачі даних, безпека й деякими більш дрібними технічними деталями. Наприклад, безпека Http-каналу забезпечується протоколом HTTPS, а безпека Tcp-каналу протоколом TCP/IP. Tcp-канал більш продуктивний, ніж Http-канал, тощо.

Для того, щоб об'єкт певного типу був доступний видалено, необхідно надати системі дистанційного доступу наступну інформацію:

1. Необхідний тип активації класу об'єкта (типу).

2. Повний опис метаданих типу.

3. Комунікаційний канал, який потрібно зареєструвати для обробки запитів до типу.

4. URL об'єкт, що унікально ідентифікує даний тип. У випадку серверної активації це URI, який унікальний для даного типу. У випадку клієнтської активації це унікальний URL, який буде привласнений екземпляру даного типу.

  •  Java-corba

Ціль створення CORBA полягає в забезпеченні доступу до об'єктів в інших процесах, на різних комп'ютерах і мережах. Повністю описати дану технологію тут неможливо. Якщо коротко, то основний процес, що відбувається при функціонуванні CORBA - це виклик різних операцій об'єктів. Аналізуючи відмінності об'єктних ідеологій .Net і CORBA можна зробити трохи несподіваний висновок, що в. Net у різних доменах розподілені класи, а в CORBA - об'єкти. Наприклад, більшість базових класів бібліотеки .Net - "nonremotable" об'єкти. Тобто, при створенні екземплярів даних класів вони не можуть передаватися через межі процесів, як у вигляді посилань так і за значенням. Це й зрозуміло, тому що базові класи "існують" в. Net Framework, а .Net Framework встановлюється на кожний комп'ютер, що працює з даною технологією. Тому немає необхідності робити ці класи "remotable" - вони можуть бути успішно створені на кожному локальному комп'ютері. Інша справа, класи, специфічні для додатка. Такі класи швидше за все будуть "remotable", їхня імплементація буде розташовуватися в модулях, що перебувають на обраних мережних комп'ютерах (при виборі комп'ютера - сервера повинна враховуватися кількість клієнтів, частота створення й час життя об'єктів і т.д.), відповідно, посилання на них будуть проводитися по URL. URL унікальні по своїй природі й класи, специфічні для додатка також унікальні. URL - аналог сурогатного первинного ключа в реляційних базах даних. Так проводиться пошук об'єктів в. Net. В CORBA же способи пошуку об'єктів більш розвинені. В CORBA, за промовчанням, передбачається, що об'єкти існують постійно, якщо є посилання (узяте з репозиторію об'єктів, конфігураційного файлу програми або, навіть, просто жорстко вбита в програму), то передбачається, що є й об'єкт. На практиці, звичайно, використовуються різні механізми активації-деактивації, контролю часу життя об'єктів. Пошук об'єктів може проводитися:

1. За допомогою служби імен. Ця служба містить деревоподібну базу даних об'єктів. Запит до служби містить ім'я необхідного об'єкта. На запит вертається посилання на об'єкт. Служба імен - це сервіс CORBA, який вказується при завантаженні відповідного ORB. Окремі служби імен можна поєднувати з об'єднанням їх баз даних.

2. За допомогою служби комерції. Служба комерції - це також сервіс, що вказується при конфігуруванні ORB. Містить базу даних посилань на об'єкти із прикріпленою до них інформацією про властивості цих об'єктів, що називається пропозиціями. Пропозиції в службі комерції публікують сервера, що обслуговують опубліковані об’єкти. Інформація про властивості об'єкта містить список пар ім'я-значення. Значення може бути встановлене, а може бути позначене як динамічне. Це означає, що замість значення встановлюється адреса Callback-функції. Динамічні значення використовуються для властивостей, що часто змінюються. Пошук у службі комерції проводиться запитами, схожими на SQL Select c пропозицією Where. Можна задати діапазон необхідних властивостей об’єднаних логічними операціями. У відповідь на такий запит може бути отриманий набір посилань на об'єкти.

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

Таким чином, .Net використовує спосіб пошуку об'єктів подібний служби імен CORBA, роль служби імен виконують Dns-сервера. Ще одна відмінність - те, що посилання на об'єкт .Net універсальна й унікальна в глобальному масштабі, а CORBA по первісному задуму використовує посилання специфічні для певного ORB. Можна зробити висновок, що пошук об'єктів .Net реалізований примітивніше, ніж в CORBA і має менші можливості - не можна одержувати набори об'єктів за умовами пошуку. Але, з іншого боку, перевагою технології .Net є те, що система пошуку об'єктів інтегрована в глобальне мережне оточення. 

Доступ до Internet.

  •  .Net

Підтримується багаторівнева, розширювана й керована архітектура Internet services. Можна  створювати модулі, що підключаються, для нових Internet-протоколів або ж використовувати "керовану" реалізацію Windows socket interface для роботи з мережею на рівні сокетов.

  •  Java-corba

Спостережувана картина подібна описаної для .Net при зовнішній несхожості. Також є можливість створення додатків (серверів і клієнтів), які будуть взаємодіяти через Internet або за допомогою протоколу IIOP, або застосовуючи технологію тунелювання протоколу HTTP або який-небудь ще з мережних протоколів CORBA. Основною проблемою, у відмінності від .Net, є подолання брандмауерів (Fierwall) при використанні протоколів,подібних IIOP. При створенні більшості існуючих брандмауерів не передбачалося існування протоколу IIOP. Була розроблена специфікація брандмауерів CORBA. Виробники брокерів об'єктних запитів пропонують Proxy- Брандмауерів, що використовують протокол IIOP, наприклад Wonderwall компанії IONA Technologies, або підтримку тунелювання HTTP (підтримуються Http-запити) для маскування IIOP повідомлень, що дозволяє останнім непомітно долати брандмауери, наприклад, продукт Gatekeeper компанії Inprise.

Ще однієї проблемою є так звана Interoperability - необхідність подолання меж доменів додатків при взаємодії різних серверів і клієнтів через Internet, якщо вони належать до різних ORB. Щоб подолати межі різних ORB, що інтерпретують виклики об'єктів (зокрема, посилання на об'єкти; об'єкти, передані за значенням і типи даних для різних ORB), по-різному через відмінності в мовах програмування на яких створені клієнти й сервери, доводиться створювати складні алгоритми трансформації цих викликів. На відміну від CORBA в. Net застосовується абсолютно однаковий механізм подолання границь процесів, у тому числі й меж доменів додатків.

Active Directory.

  •  .Net

Простір імен System.Directoryservices - "керована" версія Active Directory Services Interfaces (ADSI). Відповідно, дозволяє робити всі те ж саме - працювати з ієрархією об'єктів Active Directory, модифікувати властивості об'єктів і т.д.

  •  Java-corba

Аналогом Active Directory є служба комерції й, почасти, служба імен CORBA. У цьому зв'язку можна відзначити різний підхід прийнятий в обговорюваних технологіях до керування розподіленими мережними ресурсами. Так, CORBA надає широкі можливості для створення мережних ресурсів будь-якого типу й, відповідно, потужні можливості пошуку цих ресурсів. Фірма ж Microsoft окреслила коло найбільш підходящих кандидатів на роль таких ресурсів, (принтери, каталоги, користувачі, комп'ютери і т.д.) і створила всеосяжну систему керування саме ресурсами вищеописаного типу, яка по своїх можливостях перевершує служби CORBA.

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

Створення розкладів виконання процесів на сервері

  •  .Net

Використовуючи компонент Timer можна створювати події які будуть збуджуватися на сервері через певні інтервали.

  •  Java-corba

Можна припустити, що така ж можливість є й в CORBA. Але для цього потрібно створити черговий сервер додатків, або службу.

Розробка компонентів

  •  .Net

Уведене поняття компонента, яке майже повністю подібно поняттю Delphi. Причому існують, так само як і в Delphi, Соntrоl's, які походять від компонентів. Також, існують контейнери компонентів і контролів. Відмінність у тому, що це - двійковий стандарт і компоненти, створені на одній з мов програмування платформи .Net повністю сумісні з компонентами створеними на іншій мові.        

Наприклад, можна створювати похідні класи компонентів створених на різних мовах програмування. Але, втім, це ж можна сказати й про будь-які об'єкти в. Net. Одне ж з основних призначень компонентів - підтримка середовищ розробки додатків.

  •  Java-corba

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

Виходить, компонент взаємодіє із зовнішнім світом через який-небудь свій об'єкт.

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

Інтернаціоналізація додатків

  •  .Net

Підтримується наступний 3- х стадійний процес створення інтернаціоналізованих додатків:

1. Глобалізація.

2. Тестування на можливість локалізації

3. Локалізація.

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

  •  Java-corba

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

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

Одержання інформації про типи під час виконання додатків

  •  .Net

Простір імен Reflection підтримує набір функцій для роботи з метаданими. В. Net збірки містять модулі, модулі містять типи, типи містять члени. Reflection надає об'єкти, що інкапсулюють збірки, модулі й типи. За допомогою Reflection можна:

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

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

3. Дізнаватись найменування, параметри, модифікатори доступу (public, private і т.д.), і деталі реалізації (abstract, virtual) конструктора. Далі, можна викликати конструктор якого-небудь типу (класу). Те ж саме можна проробляти з кожним з методів.

4. Одержувати інформацію про ім'я, модифікатори доступу (public, private і т.д.) деталях реалізації (static і т.д.) якого-небудь поля, читати або встановлювати значення поля. Те ж саме можна робити з подіями, властивостями, параметрами.

  •  Java-corba

Визначення інтерфейсів об'єктів під час виконання CORBA одержує двома способами: або витягаючи метадані, які перебувають у статично лінкованому Stub клієнта, або пошуком інтерфейсів у сховище інтерфейсів (Interface Repository).

Інтерфейси у сховищі перебувають у вигляді об'єктів. Основними властивостями об'єктів є ім'я й ідентифікатор. Пошук інтерфейсів може проводитися по імені. Репозиторій інтерфейсів (Interface Repository) використовується для перевірки типів сигнатур викликів незалежно від виду служби керування інтерфейсами (DII або ж інформація про типи з Stub), також, при перевірці графа спадкування інтерфейсів, при створенні мостів між різними ORB. У кожному разі в остаточному підсумку опису інтерфейсів представлені мовою IDL. При використанні DII генерується запит до об'єкта на виконання якої-небудь операції. Запит містить посилання на об'єкт, і інформацію для виклику, таку як ім'я операції, параметри, порушувані виключення, що вертають значення, контекст виклику. Метадані для створення опису операції беруться з опису IDL, а значення параметрів - надаються викликаючим клієнтом.

Одним з основних відмінності представлення метаданих в. Net і CORBA є спосіб зберігання цих  метаданих. В. Net метадані зберігаються абсолютно децентралізовано. В CORBA застосовується комбінація децентралізованого й централізованого зберігання метаданих. Метадані .Net більш всеосяжні, у той час як метадані CORBA - це описи інтерфейсів з деякими можливостями опису інших структур і атрибутів об'єктів. Динамічна генерація метаданих застосовується як в. Net так і в CORBA але розуміється по-різному. Звичайний стан метаданих в. Net у простому, елементарному випадку це статично лінковані в збірку метадані, які використовуються при маніпулюванні об'єктами. В CORBA навпаки, звичайний процес генерації описів Idl-інтерфейсів під час виконання програми. З одного боку, методика керування метаданими CORBA видається більш гнучкою, але це очевидно, помилкове враження, тому що, по-перше, постійна генерація метаданих, імовірно, буде знижувати загальну продуктивність (цей процес подібний, наприклад, постійній конвертації яких-небудь даних з одного формату в іншій ), по-друге, в. Net при необхідності можна застосовувати точно таку ж методику. Але вся справа в тому, що необхідність виникає не так уже й часто. Таким чином, очевидно, на прикладі .Net ми бачимо просто більш оптимізовану версію того самого процесу керування метаданими. Крім того, у силу оптимізації в. Net надається можливість реалізувати більш розвинену модель метаданих, що дозволяє описувати більше типів різних сутностей. Але, імовірно, до недоліків моделі метаданих .Net можна віднести сугубо децентралізований спосіб їх зберігання. Не перешкодила б і стандартна можливість централізованого зберігання. Хоча натяки на це є вже зараз, наприклад, MetaData Services на платформі MS SQL Server.

Динамічна генерація виконуваних модулів

  •  .Net

Класи простору імен System.Reflection.Emit дозволяють редагувати метадані, створювати збірки, модулі й типи під час виконання. Reflection можна використовувати для створення браузерів об'єктів, компіляторів, серіализації об'єктів і т.д.

  •  Java-corba

В CORBA такого поняття не існує.

Розширення метаданих

  •  .Net

Для анотації типів, полів, методів і властивостей CLR дозволяє додавати описи, подібні ключових слів, які називаються атрибутами. Атрибути зберігаються разом з метаданими файлів .NET Framework і можуть бути використані для опису коду під час виконання або ж для зміни поведінки додатка під час виконання. Хоча в. NET Framework визначений ряд основних атрибутів, можна додавати визначення нових атрибутів. Атрибути також використовуються різними середовищами розробки, наприклад дизайнерами компонентів, середовищами розробки додатків подібними Delphi.

  •  Java-corba

В CORBA такого поняття не існує.

Генерація вихідного коду на різних мовах програмування під час проектування.

  •  .Net

Можна вважати, що спеціальним засобом проектування для платформи .Net є Microsoft Visio. За допомогою Visio можна розробити й реалізувати всі види діаграм, передбачені стандартом OMG UML. Далі, по схемах генерується вихідний код на мовах програмування, підтримуваних CLR. Також, можлива генерація моделі по вихідному коду. Причому, потрібно врахувати, що Visio інтегрується в Microsoft Office і Microsoft Visual Studio .Net.

  •  Java-corba

Моделі бізнес-процесів створюються за допомогою таких програмних продуктів, як Rational Rose, Select, Forte, Dynasty, Powertier компанії Persistense Software і Microsoft Visio. Підтримується генерація коду на будь-якій мові програмування.

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

Генерація й компіляція вихідного коду на різних мовах програмування під час виконання

  •  .Net

За допомогою .NET Framework SDK можна під час виконання додатка генерувати вихідний текст  програми кількома мовами програмування. Генерація проводиться по якійсь моделі, створеній за певними стандартами. Ця технологія називається Code Document Object Model (Codedom).

Структура моделі (графа) вихідного тексту незалежна від мови програмування й містить усі  елементи, характерні для більшості основних мов програмування. Модель вихідного коду може бути створена програмно, під час виконання. Потім по ній може бути генерований вихідний код, який, у свою чергу, може бути скомпільований, а потім отримана збірка може бути запущена. Наприклад, Codedom використовують: ASP.NET, для створення графів об'єктів, які потім компілюються в збірки, які, потім формують Html-сторінки й елементи керування; простору імен System.Codedom і System.Codedom.Compiler і т.д. Можна підключати додаткові модулі для будь-яких мов програмування.

  •  Java-corba

В CORBA такого поняття не існує.

Групування даних у колекції

  •  .Net

Підтримуються колекції з усіма стандартними властивостями й методами: енумераторами і т.д.

  •  Java-corba

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

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

Обробка й порушення подій

  •  .Net

Події в. Net Framework представлені делегатами. Делегат це клас, який може містити посилання на метод. На відміну від інших класів, у делегата є сигнатура й він може містити посилання тільки на ті методи, які відповідають сигнатурі. Делегат - еквівалентний вказівнику на type-safe function або callback.

  •  Java-corba

Очевидно, аналогією подій .Net є асинхронні виклики CORBA із застосуванням Callback функцій. Хоча є специфікації й реалізації так званих "служб подій" CORBA, але це поняття скоріше є аналогією системи обміну повідомленнями Message Queue технології .Net.

Обробка й порушення виняткових ситуацій

  •  .Net

Усі операції в. NET Framework у випадку помилки під час виконання збуджують виняткові ситуації. Обробка виключень CLR проводиться з використанням наступних принципів:

1. Незалежність обробки від мови, що спровокувала виключення й, також, мови,що обробляє виключення.

2. Не вимагає від мов якогось певного синтаксису обробки виключень.

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

  •  Java-corba

Класичний випадок виникнення виняткової ситуації - помилка на сервері при виконанні запиту  клієнта. Для цього в CORBA, як відзначалося вище, при формуванні запиту до сервера в описі операції виробленої над серверним об'єктом може вказуватись [rises(except1,…exception)]. Це список користувацьких виняткових ситуацій. Далі, при одержанні у відповіді (responce) виняткової ситуації організується її обробка.

Можна зробити висновок, що й .Net і CORBA забезпечують подібну функціональність при обробці виняткових ситуацій.

 

Взаємодія зі стороннім кодом.

  •  .Net

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

У випадку взаємодії .Net і COM виникає проблема подібна обговорюваної в підрозділі,  присвяченому Java-corba (див. нижче). Але ця проблема набагато "м'якше" з кількох причин:

1. Взаємодію доводиться налагоджувати не часто, тому що в основному все можна зробити із застосуванням .Net.

2. Якщо й доведеться налагоджувати взаємодію, то це набагато легше зробити між двома родинними продуктами COM-.Net, ніж між Com-java-CORBA.

  •  Java-corba

По суті, можлива взаємодія з кожним, як процедурним, так і об'єктно-орієнтованим стороннім  кодом. Але тільки виникає питання, чого це буде коштувати? Можна дати швидка відповідь - потрібно буде створити значну кількість саморобних перехідників, що будуть гальмувати процес. Стандартно ж реалізована взаємодія тільки з COM. У цьому зв'язку можна помітити, що якщо засновувати розробку корпоративної системи на CORBA, те неминуче доведеться налагоджувати взаємодію з Com-додатками. Як говорилося вище - користувачів Windows - більшість. Основна технологія для міжпроцесорної взаємодії, застосовувана в Windows - COM. Отже, неминуча інтеграція існуючих користувачів Windows у корпоративну систему на основі CORBA сполучена з налагодженням взаємодії з різними Com-службами Windows і Com-додатками. Але, COM - це застаріла технологія, яку Microsoft не збирається розбудовувати. Таким чином, маючи лише одну легальну можливість з'єднати воєдино різнорідні системи ми свідомо будемо опиратися на застарілу, отже й поступово втрачаючу підтримку фірми-розробника, технологію.

Асинхронні виклики й взаємодія додатків за допомогою повідомлень.

  •  .Net

Можливе асинхронне програмування з використанням моделей:

1. Callback.

2. Poll Completed.

3. Begin Invoke, End Invoke.

4. Begin Invoke, Wait Handle, End Invoke.

Для створення черг повідомлень (наприклад, повідомлень, що містять вилучені виклики  клієнтами методів об'єктів створених на сервері) використовується Microsoft Message Queuing. За допомогою цього компонента можна виконувати запити, що втримуються в повідомленнях, які були відкладені, наприклад через того, що був відключений мобільний комп'ютер або обладнання або сервер був занадто завантажений і не міг обробити запити. Messagequeue - розвинена служба обміну повідомленнями, яка інтегрується з COM+ і, отже, запити на виклики видалених процедур можуть бути включені в довгочасні розподілені транзакції. Також, служба взаємодіє з багатьма основними сервісами ОС Windows.

  •  Java-corba

В CORBA асинхронне програмування й взаємодія за допомогою повідомлень практично не  розділяється. Починаючи з більш примітивних способів асинхронних викликів (Callback) і закінчуючи службами подій і груповим обміном повідомлень CORBA підтримує практично ті ж можливості асинхроного програмування, що й .Net.

Основним елементом служби подій є канал подій. Це об'єкт, відповідальний за доставку подій  (повідомлень, запитів) усім зацікавленим у них клієнтам. Канали подій - ті ж об'єкти, тому їх можна шукати за допомогою служб імен і комерції й динамічно підключати, коли це необхідно. Канали можна конфігурувати, створюючи об'єднання каналів або повне об'єднання каналів. Канали можуть зберігати повідомлення в Persistent Storage. Більш просунуті розв'язки будуються з використанням служби повідомлення. У цьому випадку на канали подій можуть накладатися різні фільтри й умови, передбачатися повідомлення про доставку повідомлення і т.д.

Груповий обмін повідомленнями - ще один спосіб обміну повідомленнями заснований на  можливостях групового мовлення протоколу IP. Реалізоване в програмному продукті Orbixtalk.

Можна зробити висновок, що реалізації служб повідомлень мають достатні можливості як в. Net так і в CORBA. Але .Net не надає незалежну від платформи службу повідомлень і це означає, що всі переваги цієї служби .Net проявляються при використанні ОС Windows.

Транзакції

  •  .Net

CLR підтримує два типи транзакцій: автоматичні й неавтоматичні. Для того, щоб транзакції починалися автоматично, необхідно щоб класи були зареєстровані в Windows 2000 Component Services. Неавтоматичні транзакції підтримують Microsoft Activex Data Objects (ADO), OLE DB, Open Database Connectivity (ODBC), Microsoft Message Queuing (MSMQ).

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

Термін "serviced component" уведений в. Net Framework для позначення компонентів, які підготовані для використання разом з COM+. Таким чином, значно збільшується міць технології .Net відносно керування групами об'єктів, шляхом включення їх у добре структурований і керований транзакційний процес. Але дана технологія, очевидно, залежить від платформи.

  •  Java-corba

Технологія CORBA має високорозвинену інфраструктуру транзакційних служб. OMG визначив службу об'єктних транзакцій OTS (Object Transaction Service) як ту, що грає ключову роль у розподіленій обробці транзакцій на основі CORBA.

Монітори обробки транзакцій (Tp-монітори) забезпечують основу для побудови, виконання й керування програмним забезпеченням систем обробки транзакцій. Tp-монітор це набір інструментів і бібліотек, які використовуються для побудови транзакційних додатків, середовище, у якому ці додатки будуть виконуватися, а також набір інструментів для керування активною системою.

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

Стандарт X/Open Reference Model for Distributed Transaction Processing (DTP) визначає стандартні  інтерфейси взаємодії компонентів Tp-моніторів. Якщо модель X/Open DTP визначає процедурні інтерфейси, що обмежують доступ на рівні процедур, то служба об'єктних транзакцій OTS визначає розподілені, об'єктно-орієнтовані інтерфейси для компонентів Tp-систем. Комерційні реалізації Tp-моніторів слідують цій тенденції, створюючи монітори транзакцій об'єктів на основі технології CORBA поверх існуючої технології Tp-моніторів, заснованої на моделі X/Open DTP. Наприклад, реалізація Orbixots компанії IONA Techologies базується на програмному продукті Encina компанії Transarc, а проміжне програмне забезпечення M3 компанії BEA Systems - на програмному продукті TUXEDO. Специфікація CORBA OTS розроблялася таким чином, щоб повністю сполучатися з моделлю X/Open DTP, завдяки чому відкриття технології може виглядати як процес еволюції, а не як повна заміна існуючої технології. Таким чином, реалізації служби CORBA OTS дозволяють використовувати всі переваги існуючої, перевіреної технології Tp-моніторів у сучасному об'єктно-орієнтованому середовищі CORBA.

З можливостей, які підтримує служба CORBA OTS можна назвати:

1. Створення транзакційних об'єктів.

2. Розподілені транзакції за участю об'єктів служб OTS реляційних СУБД Oracle, Sybase, Informix, Mqseries, об'єктно-орієнтованих СУБД Versant і Object Design, інструментів для доступу до баз даних Roguewave і Persistence Software.

3. Прикладні й системні транзакції.

4. Імітація вкладених транзакцій.

5. Транзакції керовані клієнтом і транзакції керовані сервером.

6. Довго триваючі  транзакції й сеанси користувачів у дволанкових та триланкових середовищах.

Таким чином, можна зробити висновок, що служби транзакцій CORBA не відстають, а в деяких місцях навіть перевершують підтримку транзакцій технологією .Net. Зокрема, одним з більших переваг є кросплатформена підтримка транзакцій. На відміну від CORBA COM+ очевидно на справжній момент існує тільки на платформі Windows, отже ґрунтуючись на технології .Net неможливо створити розподілений кросплатформений додаток, повністю керуючий своїми транзакціями. Такий додаток зможе здійснювати тільки часткове керування транзакціями. Крім того до цієї ж проблеми можна віднести вирівнювання навантаження й організацію пулу об'єктів, тому що ці завдання також виконуються на основі COM+. В CORBA служби вирівнювання навантаження й організації пулів об'єктів кросплатформені.

Збір сміття

  •  .Net

Проводиться як автоматичний збір сміття на рівні CLR, так і збір сміття за викликом з коду програми.

  •  Java-corba

Збір сміття не відбувається (за винятком Java).

Домени додатків і програмні модулі

  •  .Net

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

Збірки - це будівельні блоки .NET Framework. Збірки - елементарні одиниці, що використовуються при встановленні додатків, контролі їх версії, повторному використанні, визначенні області активації об'єктів і визначенні рівня доступу. CLR одержує зі складань інформацію, необхідну для конструювання типів. Складання це колекції типів і ресурсів, що зберігаються в одному місці з метою спільного використання. Таким чином, вони являють собою логічні одиниці функціональності.  Для CLR типи не існують поза контекстом збірок. Збірки можуть складатися з одного або декількох файлів. Найпростіший випадок - коли збірки зберігаються в одному каталозі й інші додатки не мають доступу до них. У такому випадку, встановлення і видалення додатка зводиться до копіювання й видалення каталогу, що містить збірку. Але, збірки, також можуть бути доступні й розділятися багатьма додатками, у тому числі й видаленими. У цьому випадку вони повинні мати строге ім’я (strong name) і можуть бути занесені в глобальний кеш збірок (GAC), який є на кожній машині із установленим .Net Framework.

  •  Java-corba

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

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

 

Безпека, захист і рівні доступу в додатках

  •  .Net

.Net Framework підтримує два типи розмежування рівнів доступу: розмежування рівня доступу до  коду й ролі. Обидва типи засновані на інфраструктурі, що надає CLR. Частину рівнів доступу можна визначити як "допуски". Їх три типи: code access permission, identity permissions і role-based security permission. Code access permission використовуються для захисту ресурсів і операцій від неавторизованого використання. Identity permissions використовуються для ідентифікації збірок. Role-based security permission засновані на встановленні приналежності користувача певної ролі.

Також, в. Net Framework підтримується type safety і security які визначаються під час Jit-компіляції. Виконання умов type safety і security гарантує те, що код додатка зможе одержати доступ тільки до тих областей пам'яті, які авторизовані для доступу.

Security policy це набір правил, CLR, який вирішує що можна дозволити робити виконуваному коду.

Також підтримується три види principals, аутентификация й авторизація.

До складу .Net Framework включений простір імен Cryptography.

Для забезпечення мережної безпеки можуть використовуватися протоколи SSL, Kerberos, HTTPS, TCP/IP.

  •  Java-corba

На сьогодні консорціумом OMG розроблено чотири специфікації CORBA, що мають відношення до безпеки:

1. Специфікація служби безпеки CORBA. Створена на основі існуючих технологій безпеки, таких як служба безпеки DCE (Distributed Computing Environment), протокол Kerberos для аутентифікації в розподілених системах, шифрування, розроблене в Массачусетському технологічному інституті (MTI), а також загальний засіб доступу до служб безпеки, прикладний інтерфейс API загальної служби безпеки (Generic Security Service API - GSS API).

2. Специфікація безпечної взаємодії (протокол Seciop CORBA).

3. Специфікація інтеграції CORBA ORB-SSL.

4. Специфікація брандмауерів CORBA.

Як відзначалося вище (див. "Доступ до Internet"), реалізація специфікації брандмауерів CORBA викликає утруднення, тому найбільш реальний у середовищі CORBA протокол SSL.

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

Серіалізація об'єктів

  •  .Net

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

  •  Java-corba

Часткова серіалізація проводиться при передачі об'єктів за значенням, але передається тільки значення "стану" об'єкта - це значення властивостей об'єкта. Сам же об'єкт створюється на стороні клієнта способом, характерним для мови програмування клієнта з наступним присвоєнням його властивостям переданих значень. У цьому процесі виникають проблеми невідповідності Idl-опису властивостей і реальних властивостей, характерних для мови (наприклад, типів даних). Проблему намагаються розв'язати, але не завжди успішно. Така ж проблема виникає при серіалізації об'єктів зі збереженням їх у будь-якому сховищі об'єктів (об'єктній базі даних, тощо). .Net вигідно відрізняється в цьому змісті від CORBA, тому що об'єкти передаються у двійковому виді незалежно від мови - CLR розуміє їх завжди.

Робота з базовими типами

  •  .Net

На рівні CLR для базових типів підтримується конвертація, усі види форматування, операції з рядками і їх розбір. Інтерпретація не базових типів цілком залежить від метаданих.

  •  Java-corba

Є типи даних IDL, а є типи даних, характерні для мови програмування. Отже, проводиться  меппінг/ремеппінг типів даних, не завжди успішний. Усі стандартні операції з типами даних - у мовах програмування клієнтів і серверів. Отже, вони в загальному випадку - різні.

Введення / виведення

  •  .Net

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

  •  Java-corba

Специфікацій CORBA, що описують стандартне введення / виведення не існує. Ці завдання виконуються засобами операційної системи, на якій реалізовані сервери й клієнти. Отже, про кросплатформеність можна говорити тільки на рівні загальної архітектури CORBA. Але це занадто дорога ціна для тих, хто захоче її реалізувати, тому що все доведеться робити практично з нуля. Крім того, і однаковості роботи з уведенням / виведенням також немає, тому що різні мови програмування роблять це по-різному.

Потрібно врахувати, що фірма Microsoft у даний момент розробляє нову, об'єктну файлову систему, яку збирається інтегрувати в Windows .Net з відповідною підтримкою з боку .Net Framework. Можна зробити висновок, що дана область не покривається CORBA і всі переваги на стороні .Net.

Висновки

Порівняння двох технологій: .Net Framework і Java-corba показує, що кожна із цих технологій має свої переваги і свої недоліки. Хоча, все-таки, .Net на тлі CORBA виглядає більш сучасною й  придатною до використання технологією. Можна зробити висновок, що застосування технологій визначається конкретними умовами, що існують у тієї або іншій організації. Зокрема, це основна операційна система, яка використовується на робочих місцях користувачів, капітальні вкладення в інші технології зроблені раніше і т.д.

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

2.3. Вибір системи керування базами даних

2.3.1. Визначення критеріїв порівняння

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

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

Моделювання даних

  •  Модель даних, що використовується

Існує багато моделей даних, найбільш поширені – ієрархічна, мережева, реляційна, об’єктно-реляційна, об’єктна. Питання про використання тої чи іншої моделі повинен вирішуватись на начальному етапі проектування інформаційної системи.

  •  Тригери та збережені процедури

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

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

  •  Засоби пошуку

Деякі сучасні системи мають вбудовані додаткові засоби контекстного пошуку.

  •  Передбачені типи даних

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

Особливості архітектури і функціональні можливості

  •  Мобільність

Мобільність – це незалежність системи від середовища, в яків вона працює.

Середовищем в даному випадку являється як програмне (операційна система), так і апаратне забезпечення.

  •  Масштабованість

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

  •  Розподіленість

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

  •  Мережеві можливості

Багато систем дозволяють використовувати широкий діапазон мережевих протоколів і служб для роботи та адміністрування.

Контроль роботи системи

  •  Контроль використання пам’яті комп’ютера

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

  •  Автоматичне налаштування

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

Особливості розробки додатків

  •  Засоби розробки

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

  •  Засоби проектування

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

  •  Багатомовна підтримка

 Підтримка великої кількості національних мов розширяє область застосування системи та додатків, побудованих на її основі.

  •  Можливості розробки web-додатків

При розробці різних додатків часто виникає необхідність використання можливостей середовища internet. Середовища розробки різних виробників мають великий вибір інструментів для побудови додатків під web.

  •  Підтримка мов програмування

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

Продуктивність

  •  Рейтинг tpc (transactions per cent)

Для тестування продуктивності використовуються різноманітні засоби та існує багато тестових рейтингів. Одним з найбільш популярних та об’єктивних являється tpc-аналіз продуктивності систем. Фактично, tpc-аналіз розглядає композицію СКБД та апаратного забезпечення, на якій система працює. Показник tpc – це відношення кількості запитів, що обробляються за деякий проміжок часу до вартості всієї системи.

  •  Можливість паралельної архітектури

Для забезпечення паралельної обробки даних існує, як мінімум, два підходи: розпаралелювання обробки послідовності запитів на декілька процесорів, або використання декількох комп’ютерів-клієнтів, працюючих з однією СКБД, які об’єднують в так званий паралельний сервер.

  •  Можливість оптимізації запитів

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

Надійність

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

  •  Відновлення після збоїв

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

  •  Резервне копіювання

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

  •  Відкат змін

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

  •  Багаторівнева система захисту

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

Вимоги до робочого середовища

  •  Підтримка апаратних платформ
  •  Мінімальні вимоги до обладнання
  •  Максимальний розмір пам’яті, що адресується

Оскільки майже усі сучасні системи використовують свою файлову систему, важливим фактором являється те, який максимальний об’єм фізичної пам’яті вони можуть використовувати.

  •  Операційні системи, під керуванням яких здатна працювати СКБД.

Змішані критерії

  •  Якість і повнота документації. На жаль, не всі системи мають повну та докладну документацію.
  •  Локалізованість. Можливість використання національних мов не у всіх системах реалізована повністю
  •  Модель формування вартості. Як правило, виробники СКБД використовують певні моделі формування вартості. Наприклад, вартість одного й того ж продукту може суттєво змінюватись в залежності від того, скільки користувачів буде з ним працювати.
  •  Стабільність виробника
  •  Поширеність СКБД.

2.3.2. Порівняльний аналіз СКБД MS SQL Server та Oracle

В даному випадку, виходячи з наведених вище критеріїв, можна звернути увагу на дві СКБД: Microsoft SQL Server та Oracle.

Основа для порівняння

Як Microsoft® SQL Server, так і Oracle являються поширеними системами керування базами даних, що надають багатий набір функцій для розробки й розгортання. Тому для того, щоб порівнювати ці СКБД, потрібно досліджувати їх в контексті продуктивності розробника. Виходячи з того, що програмною платформою проекту було вибрано технологію .NET, потрібно надати увагу питанню взаємодії СКБД з цією технологією, та її інструментами проектування і розробки. На даному етапі має сенс виділити наступні критерії порівняння:

  •  Інтеграція з Microsoft Visual Studio і платформою Microsoft .NET

Microsoft Visual Studio є найбільш популярним інструментом розробки додатків на ринку на сьогоднішній день. В результаті Oracle і Microsoft інтегрували свої пропозиції в сфері баз даних (Oracle SQL Server, відповідно) з Visual Studio і платформою .NET. Інтеграція з Visual Studio і .NET CLR (загальномовним середовищем виконання) являє собою одне з найбільших досягнень у продуктивності розроблювача баз даних за останні десять років.

  •  Підтримка розробки додатків, орієнтованих на служби (Service Oriented Architecture (SOA))

Наступаюче покоління мережних, з'єднаних і розподілених додатків буде засновано на концепціях Service Oriented Architecture (SOA). SOA у корені змінить процес проектування, розробки й розгортання додатків. Бази даних будуть відігравати важливу роль в Service Oriented Architecture. Тому Oracle і SQL Server містять кілька нових функцій для розробки додатків, заснованих на SOA. Ці функції включають:

XML: Здатність ефективно зберігати, розбирати, перевіряти, опитувати й обновляти XML документи в базі даних.

Web-служби: Здатність надавати об'єкти бази даних (таблиці, збережені процедури, тощо) як Web-служби, також як і можливість викликати зовнішні Web-служби з бази даних.

Asynchronous Message Queuing: Здатність гарантовано доставляти повідомлення, точно один раз, іншим мережним і розподіленим додаткам, незважаючи на системні відмови.

Event Notification: Здатність поширювати важливі бізнес події великій кількості користувачів і обладнань, у форматі, зрозумілому одержувачу, ефективним способом.

Query Notification: Здатність додатка підписатися й одержувати повідомлення про зміни в базі даних, які впливають на результати зазначеного запиту.

  •  Гнучкість розгортання

Споживачам потрібна гнучкість розгортання додатків на тій редакції СУБД, яка найбільше підходить для поточних вимог, заснованих на кількості користувачів, обсягах даних і кількості апаратного забезпечення й необхідних функцій. Більше того, споживачі люблять можливість повторного розгортання той же самого додатка пізніше з невеликими змінами або взагалі без них. Для того щоб задовольнити цій вимозі, усі редакції СУБД повинні підтримувати той самий основний набір функцій прикладного програмування (API). Це особливо важливо для незалежних постачальників програмного забезпечення (Independent Software Vendors - ISVS) готові додатки, що створюють, які прагнуть розробити додаток один раз і віддати замовникам для розгортання на будь-якій редакції СУБД. Якщо ні, то доведеться розробляти додатки для кожної редакції, що потребує більше часу й коштів. Як Oracle, так і SQL Server задовольнили ці вимоги, пропонуючи кілька редакцій, кожна з різною функціональністю й ціною.

Інтеграція з Visual Studio

На даний момент Oracle надає тільки базову інтеграцію з Visual Studio. Він надає компонент для Visual Studio, що називається Oracle Developer Tools for Visual Studio .NET. Oracle не надає деяких важливих функцій, що впливають на продуктивність розробника, включаючи:

Oracle не дозволяє налагоджувати збережені процедури, написані мовою PL/SQL, з Visual Studio. Розробники змушені використовувати сторонні інструменти, такі як Jdeveloper.

Visual Studio пропонує корисну можливість, що називається Проект SQL Server, яка спрощує розробку додатків SQL Server через керування всіма об'єктами бази даних (збережені процедури, тригери, користувацькі функції, користувацькі об'єкти, агрегати й діаграми класів) в одній зв'язаній сутності. Проекти SQL Server також дозволяють розроблювачам одержати переваги від функцій Visual Studio Team Services (VSTS), таких як контроль версій, тощо.

В Oracle немає еквівалента Проекту SQL Server, що є відчутним недоліком для продуктивності розробника.

• Автоматичне розгортання через Visual Studio. Після того, як об'єкти бази даних SQL Server були розроблені в проекті SQL Server, їх можна розгорнути в базі даних SQL Server шляхом одного кліку миші. Розгортання в один клік застосовується й до збірок .NET. Інтеграція Oracle з Visual Studio не підтримує таку можливість.

• Інтеграція з BI (Business Intelligence – бізнес-логіка) технологіями. Усі BI технології SQL Server, включаючи SQL Server Analysis Services, Reporting Services, і Integration Services, інтегровані з Visual Studio. Однак, жодна з BI технологій Oracle, такі як Oracle OLAP option, Oracle Data Mining Option, Oracle Reports, або Oracle Warehouse Builder не інтегрована з Visual Studio жодним чином. Отже, розробник .NET, що бажає вмонтувати можливості Oracle BI у свій додаток, буде змушений вивчити ще один інструмент, такий як Jdeveloper, що негативно позначиться на продуктивності праці.

Основним моментом є те, що SQL Server повністю інтегрується з Visual Studio, у той час як інтеграція Oracle неповна. З SQL Server, розробнику .NET не потрібно ніяких інструментів, крім Visual Studio для всіх аспектів розробки додатків. З іншого боку, Oracle вимагає використання інструмента Jdeveloper або інструментів інших виробників на додаток до Visual Studio, що приводить до неоптимального досвіду, збільшення часу навчання й зниженню продуктивності розробника.

Інтеграція с. NET

На перший погляд, здається, що як Oracle, так і SQL Server 2005 пропонують той самий тип інтеграції з Microsoft .NET CLR. Однак при більш докладному розгляді стає ясно, що SQL Server розміщає .NET CLR усередині процесу, а Oracle планує розмістити її поза процесом.

Розміщення усередині процесу означає, що .NET CLR виконується в просторі процесу SQL Server. Тому виклики логіки бази даних (збережених процедур, тригерів, користувацьких функцій), реалізованих у керованому коді, не приводять до витрат міжпроцесорної взаємодії. Через те, що Oracle планує розміщати .NET CLR поза процесом, продуктивність суттєво втрачається. Зверніть увагу, що як SQL Server, так і .NET CLR мають свої моделі керування потоками й пам'яттю. Моделі SQL Server інтегровані с. NET CLR, що дозволяє розробнику .NET краще налаштовувати додатки.

Розробка SOA додатків

Як Oracle, так і SQL Server надають той самий набір функцій, що дозволяє розробляти засновані на SOA додатка. Однак є відмінність у легкості використання. SQL Server містить легкі у використанні функції, що входять у сервер баз даних, що й легко інтегруються. В Oracle ця функціональність розподілена по декільком продуктам (сервер баз даних і сервер додатків) і не дуже добре інтегрована. Більше того, безліч функцій прикладного програмування засновані на стандартах Java (такі, як Java Messaging Service) і не представляють користі для .NET розробника. SQL Server надає добре спроектовану, краще інтегрувальну й більш продуктивну платформу для розробки SOA додатків, ніж Oracle.

Гнучкість розгортання

Хоча і Oracle і SQL Server пропонують кілька редакцій СКБД, тільки SQL Server надає те ж середовище розробки (.NET), інструментарій (Visual Studio) і інтерфейси прикладного програмування для всіх редакцій. В результаті, розробникам потрібно створити додаток тільки один раз, вони можуть розгорнути його на будь-яких редакціях SQL Server - Mobile, Express, Workgroup, Standard або Enterprise Edition - без необхідності перекодувати або змінити додаток. Oracle має недоліки двох типів:

Oracle не пропонує безкоштовну версію своєї СУБД. Найдешевшою версією є Oracle Lite. SQL Server Express Edition безкоштовний.

Oracle Lite не підтримує PL/SQL, основна мова, використовуваний розроблювачами баз даних Oracle для реалізації збережених процедур, тригерів, і методів об'єктів. Отже, може бути неможливо розгорнути на Oracle Lite додатка, розроблені на іншій редакції Oracle - Standard One, Standard і Enterprise. SQL Server не має подібних обмежень.

Таким чином, виходячи з результатів порівняння вищезазначених СКБД, значна перевага на стороні Microsoft SQL Server. У всіх трьох випадках дослідження показало, що ця система значно краще підходить для даного проекту.

2.4. Вибір технології доступу до даних

Архітектура системи реалізована таким чином, що в ній існує розподіл функціональності по різним рівням:

  •  Інтерфейс
  •  Веб-сервіси
  •  Дані

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

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

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

  •  Типізовані запити
  •  Типізовані результати
  •  Об’єктне представлення схеми зберігання
  •  Загальне рішення для цілого ряду проектів
  •  Створення концептуальної об’єктної моделі
  •  Явне декларативне представлення схеми об’єктно-реляційного співставлення (ORM) між концептуальною моделлю та моделлю зберігання.

В рамках платформи .NET та Microsoft SQL Server існує декілька технологій доступу до даних. Кожна з них має свої переваги і недоліки в контексті кожної окремо взятої задачі. З найбільш наближених до даної системи можна виділити три наступні технології:

  •  LINQ
  •  ADO .NET Entity Framework
  •  ADO .NET Data Services
  •  Sync Framework

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

  1.  Огляд технології Language Integrated Query (LINQ – мова інтегрованих запитів)

  •  Однакові типізовані запити до різних джерел даних
  •  Методи розширення інтерфейсу колекцій IEnumerable (Select, OrderBy, GrouBy, Join, Where)
  •  Результат вертається у вигляді об’єктної колекції (IEnumerable<T>)
  •  Intellisence, підсвічення коду, перевірка на етапі компіляції
  •  Спеціальний синтаксис виражень запитів
  •  Інтегрований в мову програмування доступ до даних
    •  Пов’язує таблиці та записи з класами та об’єктами
    •  Побудований на ADO .NET та .NET Transactions
  •  Відповідності (Mapping)
    •  Визначаються атрибутами чи в зовнішньому XML-файлі
    •  Відношення відповідають властивостям
    •  Можливість відкладеного чи одночасного завантаження даних через відношення
  •  Постійність (Persistence)
    •  Автоматичне відстеження змін
    •  Оновлення через SQL або збережені процедури

Окрім того, LINQ підтримує різні мови програмування, і, що важливо, має змогу працювати з даними різного формату. На Рис. 1 показана схема взаємодії LINQ з різними джерелами даних:

 Рисунок 1. Взаємодія LINQ з різними джерелами даних

Можливості LINQ в роботі з даними представлені в Таблиці 1:

             Таблиця 1. Можливості LINQ при роботі з даними

Обмеження

Where

Вибірка

Select, SelectMany

Сортування

OrderBy, ThenBy

Групування

GroupBy

Об’єднання

Join, GroupJoin

Квантифікація

Any, All

Розбиття на частини

Take, Skip, TakeWhile, SkipWhile

Вибір елементів

First, Last, Single, ElementAt

Агрегатні функції

Count, Sum, Min

Конвертація

ToArray, ToList, ToDictionary

Приведення до типу

OfType<T>, Cast <T>

Виходячи з того, що дані будуть зберігатись в СКБД SQL Server, є сенс використовувати LINQ to SQL. Рис. 2 відображає схему взаємодії програмного коду з базою даних через LINQ to SQL.

Рисунок 2. Архітектура LINQ to SQL 

 В процесі роботи, LINQ перетворює об’єкти SQL Server в об’єкти тієї мови програмування, на якій реалізується клієнтський сценарій роботи з базою даних. В даному випадку – C#. В таблиці 2 наведені дані про перетворення типів.

Таблиця 2. Перетворення типів

Database

DataContext

Table

Class

View

Class

Column

Property

Relationship

Field/Property

Stored Procedure

Method

2.4.2. Огляд технології Entity Framework

Особливості технології:

  •  Інфраструктура формування концептуального об’єктного представлення даних за допомогою сутностей (Entities)
  •  Реалізація класичних задач ORM
  •  Абстрагування від схеми зберігання
  •  Гнучке співставлення

Технологія Entity Framework являє собою набір технологій ADO.NET додатків, що забезпечують розробку, пов'язану з обробкою даних. Архітекторам і розробникам додатків, орієнтованих на обробку даних, доводиться враховувати необхідність досягнення двох зовсім різних цілей. Вони повинні моделювати сутності, зв'язки й логіку розв'язуваних бізнес-завдань, а також працювати з ядрами СКБД, використовуваними для збереження й одержання даних. Дані можуть розподілятися по декільком системам зберігання даних, у кожній з яких застосовуються свої протоколи, але навіть у додатках даних, що працюють із однієї системою зберігання, необхідно підтримувати баланс між вимогами системи зберігання даних і вимогами написання ефективного й зручного для обслуговування коду додатка.

В Entity Framework розробники одержують можливість працювати з даними, представленими у формі конкретних об'єктів і властивостей, таких як клієнти і їх адреси, не будучи змушеними звертатися до базових таблиць бази даних, де зберігаються ці дані. Така можливість з'являється завдяки переходу на більш високий рівень абстракції, на якому розробники можуть працювати з даними, застосовуючи менший обсяг коду для створення й супроводу додатків, орієнтованих на роботу з даними. Платформа Entity Framework є компонентом .NET Framework, тому додатки Entity Framework можна запускати на будь-якому комп'ютері, на якому встановлений .NET Framework 3.5.

Доступ до даних сутностей і їх зміна

 

Ціль Entity Framework - надати додаткам можливість читання й зміни даних, представлених у вигляді сутностей і зв'язків у концептуальній моделі. У службах об'єктів використовується модель EDM (Entity Data Model модель сутностей даних) для перетворення запитів об'єктів до типів сутностей, представлених у концептуальній моделі, у запити, що залежать від джерела даних. Результати запитів перетворяться в об'єкти, якими управляють служби об'єктів. Платформа Entity Framework надає наступні способи виконання запитів до моделі EDM і повернення об'єктів.

  •  LINQ to Entities. Здійснює підтримку LINQ для виконання запитів до типів сутностей, які визначені в концептуальній моделі.
  •  Entity SQL – це незалежний від типу сховища діалект SQL, який працює безпосередньо із сутностями концептуальної моделі й підтримує такі функції моделі EDM, як наслідування і зв'язки. Мова Entity SQL використовується як з об'єктними запитами, так і із запитами, що виконуються за допомогою постачальника Entityclient.
  •  Методи конструктора запитів. Дозволяють створювати запити Entity SQL, використовуючи методи запитів у стилі LINQ.

Платформа Entity Framework містить у собі постачальник даних Entityclient. Постачальник управляє з'єднаннями, переводить запити сутностей у запити, що залежать від джерела даних, і повертає модуль читання даних, який використовується службами об'єктів для матеріалізації даних сутності у вигляді об'єктів. Якщо матеріалізація об'єктів не потрібно, постачальник Entityclient може також використовуватися як стандартний постачальник даних ADO.NET, який дозволяє додаткам виконувати запити Entity SQL і отримувати призначені тільки для читання дані, що вертаються модулем читання даних.

На Рис. 3 показано архітектуру технології Entity Framework

Рисунок 3. Архітектура Entity Framework

2.4.3. Огляд технології ADO.NET Data Services

ADO.NET Data Services (кодова назва "Astoria") – платформа для Microsoft Data Services, націлена, в першу чергу, на використання таких сучасних технологій, як Ajax і Silverlight, онлайн  сервісів. Суть ADO.NET Data Services полягає в тому, щоб представити дані у вигляді сервісу, який може бути використаний Інтернет-клієнтами в корпоративних мережах і через Інтернет, з використанням URI. Для створення такого сервісу даних необхідно створити ADO.NET Entity Data Model (EDM), тобто описати всі об'єкти предметної області й задати зв'язки між ними (створити EDM можна автоматично на основі схеми бази даних). Після цього, створивши сервіс і запустивши його на виконання, можна звертатися до бази даних через URI. За допомогою HTTP методів GET, POST, PUT і DELETE, можна відповідно одержати, створювати, оновлювати та видаляти записи бази даних. При цьому обмін даними здійснюється за допомогою форматів XML і JSON.

Технологія отримує доступ до даних за допомогою веб-сервісів. Вони можуть бути двох типів:

  •  REST (Representational State Transfer – передача стану представлення)

Згідно REST, мережевий ресурс повинен підтримувати всього чотири операції: GET, PUT, POST і DELETE (з тими ж значеннями, як у протоколі HTTP). Дані повинні передаватися у вигляді невеликої кількості стандартних форматів (наприклад HTML, XML, JSON). Мережевий протокол (як і HTTP) повинен підтримувати кешування, не повинен залежати від мережевого шару, не повинен зберігати інформацію про стан між парами " запит-відповідь". Такий підхід забезпечує масштабованість системи й дозволяє їй еволюціонувати з новими вимогами.

  •  SOAP/WS-* (Simple Object Access Protocol – простий протокол доступу до об’єктів)

У випадку з SOAP/WS-* фактично маємо справу з виконанням операцій на віддаленому хості. Обмінюючись Soap-повідомленнями, клієнт фактично "просить" сервер виконати ту або іншу операцію, передаючи йому при цьому параметри (якщо це необхідно). У відповідь на це, сервер відправляє клієнту Soap-повідомлення, у якому знаходиться або оцінка про успішне виконання операції і результат, або повідомлення про помилку.

Крім того, передавати Soap-повідомлення можна потенційно через будь-який транспорт (WCF, наприклад, вміє це робити поверх http, tcp, named pipes, msmq, та ін).

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

2.4.4. Огляд технології Sync Framework

Microsoft Sync Framework – це багатофункціональна платформа синхронізації, що забезпечує спільну роботу й автономний доступ для додатків, служб і пристроїв. Платформа Sync Framework надає технології і засоби, що дозволяють отримати доступ до даних з різних місць розташування, забезпечує спільне використання даних і роботу з ними в автономному режимі. За допомогою Sync Framework розробники можуть створювати системи синхронізації, які дозволяють інтегрувати будь-який додаток з будь-якими даними з будь-якого сховища, що використовує будь-який протокол у будь-якій мережі. Наприклад, програми особистої інформаційної системи (PIM) можуть використовувати Sync Framework для поширення даних PIM на всіх учасників. Бізнес-додатки зі спільним доступом до даних, наприклад до документів, можуть використовувати Sync Framework , щоб надати можливість усім учасникам отримувати оновлення й вірно обробляти пов'язані з ними конфлікти. Програми керування  мультимедіа, що виконуються на персональних комп'ютерах і керуючі мобільними пристроями, можуть використовувати Sync Framework для швидкого оновлення пристроїв.

Sync Framework включає наступні технології:

  •  Базові компоненти Sync Framework.

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

  •  Служби Microsoft Sync Services for ADO.NET.

Використовуються для автономної й спільної синхронізації баз даних.

  •  Служба сховища метаданих.

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

  •  Служби Sync Services for File Systems.

Використовуються для синхронізації файлів і папок у файловій системі.

  •  Служби Sync Services for Feedsync.

Використовуються для синхронізації Rss-каналів і каналів Atom у локальному сховищі.

Архітектура Sync Framework дозволяє спільно використовувати дані будь-якій кількості пристроїв, служб і додатків, сприймаючи сховища даних, механізми передачі й схеми як набір будівельних блоків. Будівельними блоками Sync Framework є середовище виконання, служби Metadata Services і постачальник. Середовище виконання забезпечує синхронізацію для постачальників. Постачальники використовують служби Metadata Services для обробки й зберігання метаданих.

На рисунку 4 показана високорівнева архітектура Sync Framework. Синхронізація здійснюється шляхом надання об'єкту сеансу синхронізації доступу до інтерфейсів постачальника зі сховища даних. Наприклад, сховище даних адресної книги й сховище даних обладнання синхронізують загальні контакти. Сеанс синхронізації з'єднує обох постачальників і викликає API-інтерфейс для визначення змін і необхідності їх застосування за допомогою служб Metadata Services.

Рисунок 4. Архітектура Sync Framework

2.4.5. Вибір технологій доступу до даних

Для доступу до даних на мобільному пристрої під управлінням Windows Mobile найкращим варіантом є технологія Sync Framework. Таким чином, на мобільному пристрої створюватиметься локальна полегшена копія бази даних, з якою користувач буде мати змогу працювати локально, без доступу до сервера і основної бази даних. Йому потрібно буде лише іноді синхронізувати локальне сховище з глобальним і таким чином отримувати, або відправляти оновлені дані.

Що стосується доступу до слою даних з адміністративної частини системи, то тут має сенс використовувати технологію LINQ, тому що для даної структури і розміру бази даних важливо мати можливість створювати типізовані запити до бази даних та отримувати типізовані результати. Концептуальне представлення сховища не має сенсу для бази даних такого розміру.  Більша частина даних буде кешуватись, тому немає ніякої вигоди у використанні ADO.NET Data Services.

2.5. Визначення інструментів для розробки проекту 

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

  •  Програмна технологія: Microsoft .NET 3.5
  •  Система керування базами даних: Microsoft SQL Server 2008
  •  Платформа розробки компактного пристрою: Compact Framework  + SQL Server Compact 3.5
  •  Платформа розміщення веб-додатіків: Microsoft Windows Server 2003
  •  Платформа розміщення клієнтського додатку: Microsoft Windows Mobile 6.5
  •  Інтегроване середовище розробки: Microsoft Visual Studio 2008 SP1
  •  Технологія доступу до даних: Language Integrated Query
  •  Технологія розробки адміністративної частини: ASP .NET 3.5 + AJAX
  •  Основна мова програмування адміністративної частини: C# + JavaScript
  •  Основна мова програмування клієнтської частини: C#

3. РЕАЛІЗАЦІЯ ПРОЕКТУ

3.1. Загальна схема проекту

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

3.1.1. Компонент зберігання інформації (глобально)

Реалізація:

  •  База даних

Розташування:

  •  сервер бази даних (DataBase Server).

Функції:

  •  зберігання інформації
    •  захист даних на рівні сервера бази даних
    •  частина логіки системи (рівень бази даних).

Доступ:

  •  адміністратори бази даних  - необмежений,
    •  адміністратори системи – читання та запис (обмежений),
    •  користувачі – читання та запис (обмежений)

Взаємодія:

  •  Компонент взаємодії серверної частини з базою даних
    •  Компонент взаємодії клієнтської частини за базою даних

3.1.2. Компонент взаємодії адміністративної частини з базою даних

Реалізація:

  •  Веб-сервіс

Розташування:

  •  сервер додатків (Application Server)

Функції:

  •  додатковий захисний рівень даних від несанкціонованого доступу
    •  окремий рівень абстракції для гнучкості системи у випадках змін функціональності
    •   авторизація користувачів системи
    •  Прямий доступ до бази даних (читання, запис)

Доступ:

  •  всі користувачі (функція авторизації),
    •  адміністратори системи (усі функції, після вдалої авторизації)
    •  користувачі системи (деякі функції, після вдалої авторизації)

Взаємодія:

  •  Компонент зберігання інформації
    •  Адміністративна частина

3.1.3. Адміністративна частина

Реалізація:

  •  WEB-сайт

Розташування:

  •  сервер додатків  (Application Server).

Функції:

  •  Відображення інформації
    •  Створення опитувань
    •  Керування опитуваннями
    •  Керування користувачами
    •  Редагування довідкової інформації
    •  Моніторинг процесу роботи

Доступ:

  •  Адміністратори системи (повна функціональність)
    •  Зареєстровані користувачі системи (обмежена функціональність)

Взаємодія:

  •  Компонент взаємодії адміністративної частини з базою даних

3.1.4. Компонент зберігання інформації (локально)

Реалізація:

  •  Файл з розширенням .mdf

Розташування:

  •  Файлова система мобільного пристрою

Функції:

  •  Збереження даних локально (без відправки на сервер)
    •  Відтворення структури глобального сховища локально

Взаємодія:

  •  Клієнтська частина

3.1.5. Компонент взаємодії клієнтської частини з базою даних

Реалізація:

  •  WEB-сервіс

Розташування:

  •  сервер додатків  (Application Server).

Функції:

  •  Взаємодія з сервером бази даних (читання, запис)
    •  Взаємодія з локальним сховищем клієнтської частини (читання, запис)
    •  Синхронізація даних між глобальним та локальним сховищами

Доступ:

  •  Зареєстровані користувачі системи

Взаємодія:

  •  Сервер бази даних (глобальне сховище)
    •  Клієнтська частина (локальне сховище)

3.1.6. Клієнтська частина

Реалізація:

  •  Програма Windows Mobile

Розташування:

  •  Мобільний пристрій (файлова система)

Функції:

  •  Отримання інформації безпосередньо від джерела
    •  Первинна обробка отриманих даних
    •  Підготовка даних до занесення у сховище (форматування)
    •  Збереження даних локально
    •  Автономна робота (без прив’язки до місця)
    •  Синхронізація з сервером бази даних (в обидві сторони)

Доступ:

  •  Зареєстровані користувачі системи

Взаємодія:

  •  Компонент взаємодії клієнтської частини з базою даних
    •  Компонент зберігання інформації (локально)

Таким чином, можна виділити три концептуальні рівні проекту:

  1.  Інтерфейс користувача (WEB-сайт, програма Windows Mobile)
  2.  Сервіси
  3.  База даних

Графічне представлення схеми проекту наведене в рис. 5

Рисунок 5. Загальна схема проекту

3.2. Сценарій роботи системи

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

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

Конструктор опитувань

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

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

В залежності від того, відкрите питання, чи закрите, воно може мати один, або декілька варіантів відповідей. «Відповідь» - поняття, що закінчує ланцюг «Опитування» - «Питання» -«Відповідь». Якщо питання, до якого належить відповідь (відповіді) було відкритим – то варіантів відповідей просто не буде. Опитуваний сам створює свій варіант. Якщо питання було закритого типу – воно повинно мати два або більше варіантів відповідей.

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

Клієнтська програма

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

Монітор опитувань

Цей компонент можна розділити на декілька більш дрібних за функціональним призначенням.

  •  Перегляд опитувань

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

  •  Перегляд деталей опитування

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

  •  Назва опитування
  •  Стан
  •  Дата створення
  •  Дата активації
  •  Дата закінчення
  •  Термін дії
  •  Інтерв’юери, що беруть (брали або будуть брати) участь в опитуванні
  •  Кількість опитаних респондентів

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

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

  •  Перегляд інтерв’юерів

Призначення – відображення інтерв’юерів, існуючих в системі на даний момент. Потрібно надати наступну інформацію:

  •  П.І.Б.
  •  Вік
  •  Стать
  •  Опитування, що були проведені інтерв’юером (кількість опитаних по кожному)
  •  Опитування, що проводяться інтерв’юером на даний момент (кількість опитаних по кожному)

3.3. Проектування бази даних

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

Проектування бази даних буде проходити в 3 етапи:

  •  Концептуальний рівень
    •  Сутності
    •  Атрибути
    •  Зв’язки
  •  Логічний рівень
    •  Записи
    •  Елементи даних
    •  Зв’язки між записами
  •  Фізичний рівень
    •  Групування даних
    •  Індекси
    •  Методи доступу

Концептуальне проектування – збір, аналіз та редагування вимог до даних. Для цього здійснюються наступні дії:

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

Логічне проектування – перетворення вимог до даних в структури даних. На виході отримуємо СКБД-орієнтовану структуру бази даних і специфікації прикладних додатків. На цьому етапі іноді моделюють бази даних, застосовуючи до різних СКБД та проводять порівняльний аналіз моделей.

Фізичне проектування – визначення особливостей зберігання даних, методів доступу до даних, тощо.

3.3.1. Концептуальний рівень

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

  •  Опитування
    •  Найменування
    •  Дата створення
    •  Дата активації
    •  Дата закінчення
    •  Стан
    •  Ким створений

Пов’язана із сутностями «Стан опитування» (один-до-багатьох), «Користувачі системи» (один-до-багатьох)

  •  Питання
    •  Питання (текст)
    •  Чи обов’язкове
    •  Декілька варіантів відповідей
    •  Тип (закрите/відкрите)

Пов’язана із сутностями «Опитування» (один-до-багатьох), «Тип питання» (один-до-багатьох)

  •  Варіант відповіді
    •  Варіант відповіді (текст)

Пов’язана із сутністю «Питання» (один-до-багатьох)

  •  Користувач системи
    •  Ім’я
    •  Прізвище
    •  По-батькові
    •  Стать
    •  Дата народження
    •  Група користувачів

Пов’язана із сутністю «Групи користувачів» (один-до-багатьох)

  •  Респондент
    •  Ім’я
    •  Вік
    •  Стать
    •  Сфера діяльності
    •  Додаткова інформація

Пов’язана із сутністю «Варіанти відповідей» (багато-до-багатьох)

  •  Сфери діяльності
    •  Назва

Пов’язана із сутністю «Респондент» (один-до-багатьох)

  •  Стан опитування
    •  Назва

Пов’язана із сутністю «Опитування» (один-до-багатьох)

  •  Група користувачів
    •  Назва

Пов’язана із сутністю «Користувачі» (один-до-багатьох)

  •  Тип питання
    •  Назва

Пов’язана із сутністю «Питання» (один-до-багатьох)

3.3.2. Логічний рівень

Логічне представлення бази даних відображене на рисунку 6.

Рисунок 6. Структура бази даних

3.3.3. Фізичний рівень

 Цілісність даних

Забезпечення цілісності даних є важливою задачею при проектуванні й експлуатації систем обробки даних (СОД).

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

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

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

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

Проблема забезпечення цілісності по зв'язку (і по існуванню) по-різному виглядає при додаванні нового запису у пов’язану таблицю, при коректуванні записів, при видаленні пов’язаних записів. Наприклад, якщо видаляється запис із основної таблиці, то можливі наступні варіанти: 

  •  Запис в основній таблиці можна видаляти тільки в тому випадку, якщо немає пов'язаних з нею записів у підлеглій таблиці;
  •  При видаленні запису основної таблиці видаляються всі пов'язані з нею записи в залежній таблиці (так зване каскадне видалення);
  •  Якщо це просте обмеження по зв'язку, а не обмеження по існуванню, то можливий варіант, коли при видаленні запису основної таблиці значення відповідного поля пов'язаних з нею записів повинні бути замінені на "порожньо".

Видалення записів залежної таблиці не може привести до порушення обмеження цілісності по зв'язку або існуванню.

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

3.4. Реалізація функціональності системи

3.4.1. Визначення функціональних пріоритетів

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

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

База даних

 

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

  •  Додавання користувача в базу даних
  •  Додавання респондента в базу даних
  •  Створення опитувань (питань, варіантів відповідей)
  •  Отримання даних користувача
  •  Отримання існуючих опитувань (і їх питань, варіантів відповідей)

Веб-сервіс

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

  •  Додавання користувача в базу даних
  •  Додавання респондента в базу даних
  •  Створення опитувань (питань, варіантів відповідей)
  •  Отримання даних користувача
  •  Отримання існуючих опитувань (і їх питань, варіантів відповідей)
  •  Перевірка даних на «правильність»
  •  Створення «обгортки» бази даних в форматі, зрозумілому рівню інтерфейсу

Веб-сайт

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

  •  Створення користувачів (адміністраторів, респондентів)
  •  Створення опитувань (питань, варіантів відповідей), визначення їх параметрів
  •  Отримання даних користувача
  •  Отримання інформації про існуючі опитування (їх питання, варіанти відповідей)
  •  Отримання статистичної інформації по існуючим опитуванням (скільки людей опитано, процентне співвідношення варіантів відповідей, тощо)
  •  Співставлення

Сервіс синхронізації

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

Клієнтська програма

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

  •  Авторизація користувача (інтерв’юера)
  •  Отримання опитувань з бази даних (що належать даному користувачу)
  •  Створення респондентів, їх параметрів (ім’я, вік, стать, тощо)
  •  Заповнення даних опитування (співставлення відповідей конкретному респонденту)
  •  Збереження результатів опитування

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

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

Друга ітерація

Нижче наведені зміни, що мають бути внесені в різні компоненти проекту під час другої ітерації.

База даних

  •  Створення тригерів (захист від помилкового видалення, оновлення)
  •  Налаштування резервного копіювання бази даних
  •  Створення функцій авторизації користувачів

Веб-сервіс

 

  •  Створення функцій авторизації користувачів
  •  Розширення об’єктної моделі бази даних (створення додаткових методів взаємодії з базою даних)

Веб-сайт

  •  Реалізація авторизації користувачів
  •  Розширення можливостей перегляду статистики (фільтрація по різним параметрам, групам)
  •  Контроль роботи інтерв’юерів (збір статистики)

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

Рисунок 7. Загальна інформація по завантаженню користувачів

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

Рисунок 8. Перелік опитувань

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

Рисунок 9. Перегляд загальної інформації по опитуванню.

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

Рисунок 10.  Респонденти, що однаково відповіли на запитання

Можлива ситуація, коли адміністратору потрібно дізнатись, як відповідала на запитання конкретного опитування конкретна людина. Це може знадобитись для аналізу складних опитувань, що містять перевірочні питання, тощо (Рис. 11)

Рисунок 11. Відповіді респондента на опитування

Зі сторони інтерв’юера ситуація набагато простіша. Йому лише потрібно вибрати одне з опитувань, що йому назначив адміністратор (рис. 12), заповнити основні анкетні дані по респонденту (рис. 13) і, власне, провести процедуру опитування, вибираючи ті пункти (варіанти відповідей), що повідомляє йому респондент (рис. 14).

Рисунок 12. Перелік опитувань інтерв’юера

Рисунок 13. Створення респондента

Рисунок 14. Процес проведення опитування

3.4.2. Об’єктна модель системи

Система складається с чотирьох проектів, пов’язаних в одне рішення (Solution). Проекти відповідають абстрактним компонентам системи – веб-сервіс, веб-сайт, Windows Mobile програма та сервіс синхронізації даних. На рис. 15 відображена загальна схема об’єктної моделі системи.

Рисунок 15. Об’єктна модель системи

В самому початку ієрархії знаходиться рішення, яке містить у собі чотири проекти:

  1.  Core

Основна задача проекту – підвищити рівень абстракції при взаємодії клієнтського коду з базою даних. Таким чином, за допомогою цього проекту надається можливість систематизувати потоки даних, що проходять від клієнтів до сервера і в зворотному напрямку. Містить наступні об’єкти:

  •  PollsService – веб-сервіс, містить в собі веб-методи, що працюють напряму з базою даних.
  •  PollsData - об’єктна обгортка структури бази даних, підвищує рівень абстракції представлення бази даних.
  •  Userклас, містить методи для роботи з користувачами системи.
  •  Pollклас, містить методи для роботи з опитуваннями.
  •  Respondentклас, містить методи для роботи з респондентами.
  •  Questionклас, містить методи для роботи з питаннями.

  1.  PollsAdmin

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

  •  AnswerItem – елемент, відображає варіант відповіді на запитання конкретного опитування, кількість респондентів, що вибрали саме цю відповідь та відсоткове співвідношення щодо інших варіантів відповідей.
  •  LoginControl – елемент управління, виконує функцію авторизації користувачів в системі.
  •  PollPreviewелемент, відображає стислу інформацію про опитування.
  •  PollsList – елемент-контейнер, містить у собі набір елементів PollPreview.
  •  PollsResultsелемент, відображає результати конкретного опитування (перелік питань, варіанти відповідей на кожне з них та статистику по відповідям на кожен з варіантів).
  •  QuestionItemелемент, відображає інформацію про конкретне питання.
  •  QuestionResелемент, відображає інформацію про результати відповідей на конкретне питання.
  •  MasterPage – основна сторінка, від якої унаслідуються усі інші. Містить у собі елементи, що використовують усі інші сторінки (логотип із заголовком, елемент авторизації, головне меню, стилі оформлення, тощо).
  •  Defaultдомашня сторінка, з неї починається користування сайтом. Відображає логотип, запит авторизації та головне меню.
  •  Answers сторінка, на якій відображено варіанти відповідей на обране питання (використовується в конструкторі опитувань).
  •  Pollsсторінка містить у собі перелік опитувань (стислий вигляд) та інтерфейс для створення нового опитування (конструктор опитувань)
  •  PollDetails – сторінка відображає повну інформацію про конкретне опитування (дата проведення, стан, перелік інтерв’юерів, перелік питань та варіантів відповідей на них, відсоткове співвідношення кількості опитаних до конкретного варіанту відповіді.
  •  Questionsсторінка, що відображає перелік питань конкретного опитування (використовується в конструкторі опитувань).
  •  Respondents – сторінка, що відображає перелік респондентів, що вибрали один і той самий варіант відповіді.
  •  RespAnswersсторінка, що відображає відповіді конкретного респондента на усі запитання обраного опитування.
  •  Users – сторінка, що відображає перелік користувачів, зареєстрованих в системі, їх заплановані, закриті опитування та опитування, що проводяться в даний момент, кількість опитаних респондентів по кожному з них. Призначена для визначення продуктивності роботи різних користувачів системи.

  1.  PollsClient

Розміщується на мобільному пристрої інтерв’юера. Призначення – отримувати інформацію безпосередньо від джерела, зберігати локально і періодично відправляти на сервер. Надає інтерв’юеру мобільності (територіальну свободу та незалежність від потреби мати постійний зв’язок із серверною частиною. Містить наступні об’єкти:

  •  Pollsлокальна база даних, являється копією основної бази даних (деяких її таблиць). Призначена для зберігання інформації у файловій системі мобільного пристрою.
  •  PollDataCache – компонент, що містить у собі методи та логіку процесу синхронізації сховищ даних.
  •  LoginForm – вікно із полями для вводу облікових даних інтерв’юера. Виконує функцію авторизації користувача на мобільному пристрої.
  •  PollFormосновне вікно програми, в ньому виводяться питання та варіанти відповідей на них.
  •  RespFormвікно додавання інформації про нового респондента в систему.
  •  QuestItemелемент управління, відображає та обробляє варіанти відповідей на конкретне питання.

  1.  PollsSyncLib

Проект являє собою бібліотеку, що містить у собі схему локального кешу даних та сервіс синхронізації. Містить наступні об’єкти:

  •  PollDataCache – компонент, що містить у собі методи та логіку процесу синхронізації сховищ даних.
  •  SyncContract – контракт синхронізації, описує правила синхронізації клієнта з сервером.

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

ЗАГАЛЬНІ ВИСНОВКИ

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

  •  Ефективний пошук інформаційних джерел
  •  Продуктивні методи здобуття інформації
  •  Швидка обробка даних
  •  Використання отриманих даних на благо організації

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

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

В заключній частині, за допомогою вибраного інструментарію, було реалізовано складний програмний продукт, проведено його тестування. Розроблена система дозволяє створювати повноцінні маркетингові опитування із задаванням усіх необхідних для сучасних вимог параметрів та отримувати дані від джерела за допомогою мобільних пристроїв і в лічені секунді передавати ці дані безпосередньо в базу даних підприємства. Таким чином, зі звичайного алгоритму проведення опитувань просто видаляються такі етапи, як розповсюдження анкет (в паперовому варіанті) по інтерв’юерах та імпорт отриманих на паперах даних в базу даних за допомогою операторів. Такий спосіб реалізації дозволяє зекономити приблизно 50% часу, затраченого на опитування від самого початку і до кінця. Окрім економії часу, зникає необхідність в послугах, наприклад, операторського складу організації, що позитивно відгукається на фінансовій сфері компанії.

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

ЛІТЕРАТУРА

Павлова, Е.А. Технологии разработки современных информационных систем на платформе .NET – Интернет-университет информационных технологий, [Текст]. – 2009. – 112с.

Пауэлл, Т. Ajax. Настольная книга программиста [Текст] – Эксмо. – 2009. – 720с.

Сандерсон, С. ASP.NET MVC Framework с примерами на C# для профессионалов. [Текст] – Вильямс, 2009. – 608с.

Мак-Дональд, М. Microsoft ASP.NET 3.5 с примерами на C# 2008 и Silverlight 2 для профессионалов, – Вильямс, 2009. – 1408с.

Дэвис С.Р. C# 2005 для "чайников" / Дэвис С.Р., Сфер Ч.; "Вильямс", [Текст] – 2006. – 576 с.

Эндрю Троелсен. Язык программирования C# 2008 и платформа .NET 3.5.  – [Текст] "Вильямс"  2009. – 1344 с.

Мот, Д. Microsoft Mobile и .NET Compact Framework. Руководство разработчика [Текст]. – Питер, 2009. – 672с.

Салмре, И. Программирование мобильных устройств на платформе .NET Compact Framework [Текст]. – Вильямс, 2006. – 736с.

Камерон, Р. ASP.NET 3.5, компоненты AJAX и серверные элементы управления для профессионалов [Текст]. – Вильямс, 2009. – 608с.

Шмидт, Б. Основы Windows Workflow Foundation [Текст]. – ДМК Пресс, 2008. – 352с.

Паркер Т. .NET. Сетевое программирование для профессионалов [Текст]. – Лори, 2005. – 400с.

Леве, Д. Создание служб WCF [Текст]. – Питер, 2008. – 592с.

Вульф, Б. Шаблоны интеграции корпоративных приложений [Текст]. – Вильямс, 2007. – 672с.

Шафер, Д.Ф. Управление программными проектами. Достижение оптимального качества при минимуме затрат [Текст]. – Вильямс, 2004. – 1136с.

Ратц, Д LINQ: язык интегрированных запросов в C# 2008 для профессионалов [Текст]. – Вильямс, 2008. – 560с.

Основы проектирования реляционных баз данных: [Электрон. ресурс]. – Режим доступа: http://www.intuit.ru.

Сравнение SQL Server с Oracle Database : [Электрон. ресурс]. – Режим доступа: http://www.microsoft.com/sqlserver/2008.

SQL Server 2008: Безопасность: [Электрон. ресурс]. – Режим доступа:  http://sysdba.org.ua.

Википедия, Microsoft SQL Server: [Электрон. ресурс]. – Режим доступа: http://www.ru.wikipedia.org.

Кросс-платформенная разработка – Windows Mobile и Windows: [Электрон. ресурс]. – Режим доступа: http://mobile-developer.ru.

Microsoft Sync Framework: Синхронизация данных: [Электрон. ресурс]. – Режим доступа: http://msdn.microsoft.com.

ДОДАТОК А

Лістинг коду основних компонентів

PollsService.cs

public class PollsService : System.Web.Services.WebService

   {

       [WebMethod]

       public PollsData.PollsDataTable GetPolls(int state)

       {

           return new PollsAdapter().GetData(state);

       }

       [WebMethod]

       public PollsData.UsersDataTable GetInterviewersByPoll(int pollId)

       {

           return new UsersAdapter().GetInterviewersByPoll(pollId);

       }

       [WebMethod]

       public PollsData.QuestionsDataTable GetQuestionsByPollId(int pollId)

       {

           return new QuestionsAdapter().GetQuestionsByPollId(pollId);

       }

       [WebMethod]

       public void AddPoll(string name, int createdById, DateTime activateDate, DateTime? expiredDate)

       {

           new PollsAdapter().AddPoll(name, createdById, activateDate, expiredDate);

       }

       [WebMethod]

       public void AddQuestion(string question, bool required, bool multiAnswer, int questionTypeId, int pollId)

       {

           new QuestionsAdapter().AddQuestion(question, required, multiAnswer, questionTypeId, pollId);

       }

       [WebMethod]

       public PollsData.AnswersDataTable GetAnswersByQuestionId(int questionId)

       {

           return new AnswersAdapter().GetAnswersByQuestionId(questionId);

       }

       [WebMethod]

       public void AddAnswer(string answer, int questionId)

       {

           new AnswersAdapter().AddAnswer(answer, questionId);

       }

   }

}

Core.Poll.cs

public class Poll

   {

       public static void AddPoll(string name, int createdById, DateTime activateDate, DateTime expiredDate)

       {

           using (PollsService service = new PollsService())

           {

               service.AddPoll(name, createdById, activateDate, expiredDate);

           }

       }

       public static PollsData.PollsRow GetPoll(int pollId)

       {

           using (PollsService service = new PollsService())

           {

               PollsData.PollsDataTable table = service.GetPoll(pollId);

               if (table.Rows.Count > 0)

               {

                   return table[0];

               }

           }

           return null;

       }

       public static PollsData.PollsDataTable GetPolls(int state)

       {

           using (PollsService service = new PollsService())

           {

               return service.GetPolls(state);

           }

       }

       public static PollsData.QuestionsDataTable GetQuestionsByPollId(int pollId)

       {

           using (PollsService service = new PollsService())

           {

               return service.GetQuestionsByPollId(pollId);

           }

       }

       public static PollsData.AnswersDataTable GetAnswersByQuestionid(int questionId)

       {

           using (PollsService service = new PollsService())

           {

               return service.GetAnswersByQuestionId(questionId);

           }

       }

       public static void AddQuestion(string question, bool required, bool multiAnswer, int questionTypeId, int pollId)

       {

           using (PollsService service = new PollsService())

           {

               service.AddQuestion(question, required, multiAnswer, questionTypeId, pollId);

           }

       }

       public static void AddAnswer(string answer, int questionId)

       {

           using (PollsService service = new PollsService())

           {

               service.AddAnswer(answer, questionId);

           }

       }

       public static PollsData.PollsRow GetPollByQuestionId(int questionId)

       {

           using (PollsService service = new PollsService())

           {

               PollsData.PollsDataTable table = service.GetPollByQuestionId(questionId);

               

               if (table.Count > 0)

               {

                   return table[0];

               }

           }

           return null;

       }

       public static PollsData.PollsRow GetPollByAnswerId(int answerId)

       {

           using (PollsService service = new PollsService())

           {

               PollsData.PollsDataTable table = service.GetPollByAnswerId(answerId);

               if (table.Count > 0)

               {

                   return table[0];

               }

           }

           return null;

       }

   }

Core.User.cs

public static PollsData.UsersRow GetUser(int userId)

       {

           using (PollsService service = new PollsService())

           {

               PollsData.UsersDataTable table = service.GetUser(userId);

               if (table.Count > 0)

               {

                   return table[0];

               }

           }

           return null;

       }

       public static PollsData.UsersRow GetUserByCredentials(string login, string password)

       {

           using (PollsService service = new PollsService())

           {

               PollsData.UsersDataTable table = service.GetUserByCredentials(login, password);

               if (table.Count > 0)

               {

                   return table[0];

               }

           }

           return null;

       }

       public static PollsData.UsersDataTable GetUsersByGroup(int userGroupId)

       {

           using (PollsService service = new PollsService())

           {

               return service.GetUsersByGroup(userGroupId);

           }

       }

       public static PollsData.UsersDataTable GetInterviewersByPoll(int pollId)

       {

           using (PollsService service = new PollsService())

           {

               return service.GetInterviewersByPoll(pollId);

           }

       }

       public static void SetInterviewerForPoll(int pollId, int interviewerId)

       {

           using (PollsService service = new PollsService())

           {

               service.SetInterviewerForPoll(pollId, interviewerId);

           }

       }

       public static void DeleteInterviewerFromPoll(int pollId, int interviewerId)

       {

           using (PollsService service = new PollsService())

           {

               service.DeleteInterviewerFromPoll(pollId, interviewerId);

           }

       }

   }

PollDetails.cs

public partial class PollDetails : System.Web.UI.Page

   {

       public PollsData.PollsRow poll = null;

       protected void Page_Load(object sender, EventArgs e)

       {

           int pollId = 0;

           if (!string.IsNullOrEmpty(Request["pollId"]))

           {

               int.TryParse(Request["pollId"], out pollId);

           }

           poll = Poll.GetPoll(pollId);

           if (poll == null) { return; }

           this.PollResultsList1.PollId = poll.Id;

           if (!IsPostBack)

           {

               var ai =

                   from c in Core.User.GetUsersByGroup(2)

                   select new { Id = c.Id, FullName = c.FirstName + " " + c.LastName };

               InterviewersList.DataSource = ai;

               InterviewersList.DataBind();

               InterviewersList.SelectedIndexChanged -= new EventHandler(InterviewersList_SelectedIndexChanged);

               foreach (var i in Core.User.GetInterviewersByPoll(poll.Id))

               {

                   ListItem item = InterviewersList.Items.FindByValue(i.Id.ToString());

                   if (item != null)

                   {

                       item.Selected = true;

                       item.Attributes["style"] = "color:Black;";

                   }

               }

               InterviewersList.SelectedIndexChanged += new EventHandler(InterviewersList_SelectedIndexChanged);

           }

       }

       protected void InterviewersList_SelectedIndexChanged(object sender, EventArgs e)

       {

           var ai =

              from c in Core.User.GetInterviewersByPoll(poll.Id)

              select new { Id = c.Id, FullName = c.FirstName + " " + c.LastName };

           foreach(ListItem item in InterviewersList.Items)

           {

               if (item.Selected && ai.Where(x => x.Id.ToString() == item.Value).Count() == 0)

               {

                   Core.User.SetInterviewerForPoll(poll.Id, int.Parse(item.Value));

               }

               if (!item.Selected && ai.Where(x => x.Id.ToString() == item.Value).Count() > 0)

               {

                   Core.User.DeleteInterviewerFromPoll(poll.Id, int.Parse(item.Value));

               }

           }

           Response.Redirect(Request.RawUrl);

       }

   }

PollsCache.SyncContract

 public partial class PollsCacheSyncService : object, IPollsCacheSyncContract {

       

       private PollsCacheServerSyncProvider _serverSyncProvider;

       

       public PollsCacheSyncService() {

           this._serverSyncProvider = new PollsCacheServerSyncProvider();

       }

       

       [System.Diagnostics.DebuggerNonUserCodeAttribute()]

       public virtual SyncContext ApplyChanges(SyncGroupMetadata groupMetadata, DataSet dataSet, SyncSession syncSession) {

           return this._serverSyncProvider.ApplyChanges(groupMetadata, dataSet, syncSession);

       }

       

       [System.Diagnostics.DebuggerNonUserCodeAttribute()]

       public virtual SyncContext GetChanges(SyncGroupMetadata groupMetadata, SyncSession syncSession) {

           return this._serverSyncProvider.GetChanges(groupMetadata, syncSession);

       }

       

       [System.Diagnostics.DebuggerNonUserCodeAttribute()]

       public virtual SyncSchema GetSchema(Collection<string> tableNames, SyncSession syncSession) {

           return this._serverSyncProvider.GetSchema(tableNames, syncSession);

       }

       

       [System.Diagnostics.DebuggerNonUserCodeAttribute()]

       public virtual SyncServerInfo GetServerInfo(SyncSession syncSession) {

           return this._serverSyncProvider.GetServerInfo(syncSession);

       }

   }

   

   [ServiceContractAttribute()]

   [XmlSerializerFormat()]

   public interface IPollsCacheSyncContract {

       

       [OperationContract()]

       SyncContext ApplyChanges(SyncGroupMetadata groupMetadata, DataSet dataSet, SyncSession syncSession);

       

       [OperationContract()]

       SyncContext GetChanges(SyncGroupMetadata groupMetadata, SyncSession syncSession);

       

       [OperationContract()]

       SyncSchema GetSchema(Collection<string> tableNames, SyncSession syncSession);

       

       [OperationContract()]

       SyncServerInfo GetServerInfo(SyncSession syncSession);

   }

}

PollsCache.Polls.sql

IF @@TRANCOUNT > 0

set ANSI_NULLS ON

set QUOTED_IDENTIFIER ON

GO

BEGIN TRANSACTION;

IF @@TRANCOUNT > 0

IF NOT EXISTS (SELECT * FROM dbo.sysobjects WHERE id = OBJECT_ID(N'[dbo].[Polls_Tombstone]'))

BEGIN

CREATE TABLE [dbo].[Polls_Tombstone](

   [Id] Int NOT NULL,

   [DeletionDate] DateTime NULL

) ON [PRIMARY]

END

GO

IF @@ERROR <> 0

    ROLLBACK TRANSACTION;

IF @@TRANCOUNT > 0

ALTER TABLE [dbo].[Polls_Tombstone] ADD CONSTRAINT [PKDEL_Polls_Tombstone_Id]

  PRIMARY KEY CLUSTERED

   ([Id])

   ON [PRIMARY]

GO

IF @@ERROR <> 0

    ROLLBACK TRANSACTION;

IF @@TRANCOUNT > 0

IF EXISTS (SELECT * FROM dbo.sysobjects WHERE id = OBJECT_ID(N'[dbo].[Polls_DeletionTrigger]') AND type = 'TR')

  DROP TRIGGER [dbo].[Polls_DeletionTrigger]

GO

CREATE TRIGGER [dbo].[Polls_DeletionTrigger]

   ON [dbo].[Polls]

   AFTER DELETE

AS

SET NOCOUNT ON

UPDATE [dbo].[Polls_Tombstone]

   SET [DeletionDate] = GETUTCDATE()

   FROM deleted

   WHERE deleted.[Id] = [dbo].[Polls_Tombstone].[Id]

IF @@ROWCOUNT = 0

BEGIN

   INSERT INTO [dbo].[Polls_Tombstone]

   ([Id], DeletionDate)

   SELECT [Id], GETUTCDATE()

   FROM deleted

END

GO

IF @@ERROR <> 0

    ROLLBACK TRANSACTION;

COMMIT TRANSACTION;

PollsCache.Users.sql

IF @@TRANCOUNT > 0

set ANSI_NULLS ON

set QUOTED_IDENTIFIER ON

GO

BEGIN TRANSACTION;

IF @@TRANCOUNT > 0

IF NOT EXISTS (SELECT * FROM dbo.sysobjects WHERE id = OBJECT_ID(N'[dbo].[Users_Tombstone]'))

BEGIN

CREATE TABLE [dbo].[Users_Tombstone](

   [Id] Int NOT NULL,

   [DeletionDate] DateTime NULL

) ON [PRIMARY]

END

GO

IF @@ERROR <> 0

    ROLLBACK TRANSACTION;

IF @@TRANCOUNT > 0

ALTER TABLE [dbo].[Users_Tombstone] ADD CONSTRAINT [PKDEL_Users_Tombstone_Id]

  PRIMARY KEY CLUSTERED

   ([Id])

   ON [PRIMARY]

GO

IF @@ERROR <> 0

    ROLLBACK TRANSACTION;

IF @@TRANCOUNT > 0

IF EXISTS (SELECT * FROM dbo.sysobjects WHERE id = OBJECT_ID(N'[dbo].[Users_DeletionTrigger]') AND type = 'TR')

  DROP TRIGGER [dbo].[Users_DeletionTrigger]

GO

CREATE TRIGGER [dbo].[Users_DeletionTrigger]

   ON [dbo].[Users]

   AFTER DELETE

AS

SET NOCOUNT ON

UPDATE [dbo].[Users_Tombstone]

   SET [DeletionDate] = GETUTCDATE()

   FROM deleted

   WHERE deleted.[Id] = [dbo].[Users_Tombstone].[Id]

IF @@ROWCOUNT = 0

BEGIN

   INSERT INTO [dbo].[Users_Tombstone]

   ([Id], DeletionDate)

   SELECT [Id], GETUTCDATE()

   FROM deleted

END

GO

IF @@ERROR <> 0

    ROLLBACK TRANSACTION;

COMMIT TRANSACTION;


 

А также другие работы, которые могут Вас заинтересовать

712. Анализ динамики обменного курса рубля 58.5 KB
  Используя средства Microsoft Excel и статистические показатели, научиться оценивать динамику реального курса рубля. Установление валютного курса (в результате торгов или государственными органами). Осуществление взаимного обмена валютами при торговле товарами и услугами, при движении капиталов и кредитов.
713. Правовое обеспечение связей с общественностью 182 KB
  Нормативные акты о свободе человека, о правах, которые устанавливает правовое положение государственных органов. Специальные категории персональных данных: расовая, национальная принадлежности, политических взглядов, религиозных убеждений, состояние здоровье и интимной жизни. Формы организационного взаимодействия организаций.
714. Средства массовой информации в контексте деятельности государства 138 KB
  Понятие и роль средств массовой информации в обществе. Политика государства в сфере деятельности СМИ. Роль электронных СМИ в информационном обеспечении деятельности органов государства. Проблемы взаимодействия СМИ и государства в России.
715. Клиническая картина острого отравления лекарственными средствами 63.5 KB
  Клиническая картина острого отравления. Дифференциальная диагностика отравлений лекарственными средствами. Тяжелые клинические проявления психоневрологических расстройств при острых отравлениях - токсическая кома и острый интоксикационный психоз.
716. Понятие и виды объектов гражданских прав 154 KB
  Объекты гражданских прав. Понятие имущества в гражданском законодательстве. Вещи как объекты гражданского оборота: понятие и научно-правовая классификация. Индивидуально-определённые вещи и вещи с родовыми признаками. Ценные бумаги: понятие и общая классификация. Ограниченные, свободные в обороте, изъятые вещи.
717. Жизненный путь и политическая деятельность Джузеппе Гарибальди 92.5 KB
  Детство, юность и первые шаги на политическом поприще. Влияние Джузеппе Гарибальди на мировую моду. Борьба за объединение Италии. Революция 1848 года и её разгром.
718. Особенности экологического менеджмента 102.5 KB
  Внедрение системы экологического менеджмента на предприятии. Создание экологичного производства. Аудит системы экологического менеджмента.
719. Проектування програмних засобів на мові Assembler та в інтерпретаторі Shell 106 KB
  Системне програмування в shell інтерпретаторі. Операційна система Windows. Системне програмування в MASM. Операційна система Linux (Ubuntu). Засоби підготування текстів.
720. Причины и условия преступности 382.5 KB
  Понятие и классификация причин и условий преступности. Сущность детерминации преступности. Основные криминологические концепции причин и условий преступности.