і виконання процедур бізнес-логіка, запитаних клієнтом, і збір статистики по клієнту. Зберігання адрес процедур бізнес-логіки зручно організувати у вигляді асоціативного масиву, де імені процедури, включающему також ім'я модуля, в якому вона міститься, відповідає адреса експортується з DLL функції, отриманий на етапі завантаження сервера. Метод, що забезпечує передачу даних від клієнта серверу і повернення результатів, також може належати сокету. Однак якщо обробка на стороні сервера займає значний проміжок часу, розробка клієнта вимагатиме застосування багатопоточності, в іншому випадку, користувальницький інтерфейс клієнта буде блокований на час здійснення виклику даного методу.
Взаємодія з базою даних відбувається через інтерфейс ODBC, що дає нам повну свободу у виборі сервер управління базою даних (СКБД). Інтерфейс ODBC був розроблений фірмою Microsoft в якості уніфікованого засоби для доступу до реляційних баз даних, керованих різними СУБД. Для користувачів він представляється у вигляді сукупності функцій і джерел даних. Під джерелами даних тут маються на увазі об'єкти є сполучною ланкою між базами даних та їх додатками. Джерела даних здійснюють взаємодію з базами даних через ODBC-драйвери. Такі драйвери поставляються фірмами-розробниками СУБД. Створення та налагодження джерел здійснюється користувачами, а інтерфейсні функції надає фірма Microsoft. Після настроювання джерела даних, його ім'я використовується в додатках як псевдонім для звернення до відповідної бази даних.
На боці СУБД передбачається зберігати дві бази даних. Одна містить безпосередньо інформацію підприємства, доступ до якої ми плануємо оптимізувати за допомогою модулів обробки нереляційних запитів. Інша база даних являє метаінформацію про користувача інтерфейсах клієнтських додатків.
Реалізація адміністрування серверу може бути здійснена кількома способами:
засоби адміністрування і належний їм інтерфейс користувача є частиною сервера;
інтерфейс користувача може бути винесений в окремий додаток.
Перевагою першого підходу є простота реалізації - не вимагається забезпечення взаємодії декількох додатків, а сам сервер повинен бути виконаний у вигляді звичайного EXE-модуля. Недолік такого підходу в тому, що адміністрування сервера можливо тільки на тій машині, де він виконується. Крім того, контроль над виконанням сервера, у випадку реалізації його у вигляді звичайного виконуваного модуля, бере на себе менеджер об'єктів COM, через що сервер може періодично розвантажуватися і запускатися знову. Щоб уникнути цього, слід реалізувати серверну частину системи у вигляді служби Windows. Однак наділяти сервіси інтерфейсом користувача не рекомендується.
Другий підхід дозволяє здійснювати віддалене адміністрування сервера додатків, а реалізація сервера у вигляді сервісу зручна тим, що дозволяє вручну контролювати час його життя (запуск і зупинку). Засоби адміністрування, при даному підході, являють собою особливу клієнтську програму, що створює на сервері екземпляр компонента, що забезпечує управління внутрішніми процесами і надає дані про його стан - керуючий блок.
Розроблена архітектура (малюнок 1.2) дозволяє досить повно використовувати можливості, що надаються технологією COM, для забезпечення високого рівня продуктивності сервера пріложеній і масштабованості навантаження на сервер.
Малюнок 1.2 - Архітектура системи
.4 Декомпозиція системи
Ключовим етапом об'єктно-орієнтованого аналізу при розробці програмних систем є об'єктна декомпозиція. Її мета полягає в розбитті розроблюваної системи на окремі класи понять або об'єкти. Результатом декомпозиції є модель предметної області - візуальне уявлення (у відповідній нотації), в термінах задачі, класів і сутностей реального світу, складових проектовану систему. Існує кілька типів моделей, що відображають логічне (структура класів, структура об'єктів) і фізичне (архітектура модулів, архітектура процесів) пристрій розроблюваної системи. Моделі також можуть розкривати статичні (успадкування, агрегація, асоціація і т.д.) або динамічні (набір подій, за допомогою яких компоненти системи впливають один на одного) відносини між об'єктами. Модель необхідна для виявлення, класифікації та формалізації відомостей про всі аспекти предметної області, що визначають властивості системи.
На етапі аналізу користуються концептуальними моделями, які оперують основними поняттями предметної області, атрибутами обраних понять і статичними відносинами між ними. Основним поняттям предметної області ставлять у відповідність класи, що представляють собою сукупність загальних ознак певної групи об'єктів. Визначення концептуальних класів може проводитися за допомогою лі...
