Юринець В.Є., Юринець Р.В. Автоматизовані інформаційні системи. Електронний посібник

Подождите немного. Документ загружается.

623

Об’єктна модель. Об’єктна модель подання даних оперує

такими поняттями, як клас і об’єкт. Класи визначають структуру даних

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

Представники класу (об’єкти) мають певну структуру і можуть місти-

ти інші об’єкти, утворюючи довільну ієрархічну структуру. Об’єкти

можуть успадковувати

властивості, вміст і поведінку об’єктів, які в

них містяться. Прикладами об’єктів слугують документи, картинки,

папки й облікові записи користувачів. Клас контенту не зберігає в собі

реальних даних – таку інформацію містять об’єкти (екземпляри класу).

Визначивши один клас, можна створити багато його представників

(контент об’єктів).

У CMS-системах дані зазвичай

зберігаються в реляційній або

об’єктній базах даних. У першому випадку об’єктна модель даних

відображається на реляційну модель бази даних. Зв’язки між об’єк-

тами створюються, наприклад, за допомогою таблиць виду id,

from_object, from_object_version, to_object. На рис. 4.4 наведено

можливу структуру класу “Стаття” і його представника.

Серед об’єктно-орієнтованих CMS-систем можна зустріти

каркаси. Класичний

приклад – Zope CMF. Взагалі, Zope – провідний

вільно поширюваний сервер програм, що спеціалізується на управлінні

контентом у порталах і програмах користувачів. На основі цього

серверу програм побудований каркас управління контентом Zope CMF,

за допомогою якого, у свою чергу, створено низку CMS-систем,

зокрема, Plone.

Ще одна дуже поширена CMS цього класу – eZ Publish. Вона

належить і до каркасів, і до ЕСM. Системи цього сімейства

засновані

на вільно поширюваному продукті eZ Publish. Наявність двох ліцензій –

GPL і професійної – дає змогу створювати комерційні продукти на основі

каркаса eZ Publish, забезпечуючи цій системі підтримку як

співтовариства Open Source, так і професійних розробників.

До цього класу можна віднести і систему APC ActionApps, яка

дає змогу зареєстрованим користувачам обновляти контент їх сайту з

допомогою лише браузера. Особливість цієї системи полягає

в тому,

що вона має виведення, яке налаштовується. APC ActionApps інте-

грується в існуючі системи, дозволяючи спростити структуру й авто-

матизувати роботу складних порталів і Web-сайтів. Крім того, механізм

624

content роoling і наявність інструментів редагування роблять цю

систему придатною для розподілених команд, що спільно готують

публікацію контенту.

Microsoft Content Management Server (MCMS) є системою управ-

ління Web-контентом, яка дає можливість створювати, розгортати і

підтримувати динамічно змінні Web-сайти. Завдяки тісній інтеграції з

Visual Studio.NET і підтримці функцій управління вихідними кодами.

MCMS дає змогу розробникам створювати сайти, якими потім можуть

управляти

і підтримувати як ІТ-фахівці, так і бізнес-користувачі. Перші

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

документів і безпекою, тоді як другі – створювати власний контент,

управляти ним і публікувати його, використовуючи знайомі програми,

такі як Word або Internet Explorer.

Рис. 4.4. Приклад організації контенту за допомогою об’єктної моделі даних

625

Об’єктна модель підтримує розробку в середовищі Visual Studio

.Net і .Net Framework. Можливе об’єднання через Microsoft Solutions

for Internet Business (MSIB) Content Connector з сервером Microsoft

Commerce Server для створення рішень у галузі електронної комерції.

Зазвичай, системи, засновані на об’єктно-орієнтованій моделі

даних, найфункціональніші, гнучкі, але, водночас, і найскладніші.

Мережна модель. Ця модель подання даних спирається на тео-

рію графів: структура інформації

подається у вигляді вузлів з поз-

наченими зв’язками між ними. Фундаментом системи може слугува-

ти як мережна, так і традиційна реляційна СУБД, на яку відображена

мережна модель опису даних. У реляційних таблицях зберігається

інформація про вузли, їх атрибути і зв’язки між ними. Зв’язок відріз-

няється від атрибуту тим, що

в ньому зберігається посилання на інший

вузол, а в атрибуті – власне значення. Для видобування даних з направ-

леного графа здебільшого використовують рекурсивні процедури

оброблення. На рис. 4.5 наведено варіант організації структури даних

сайту у вигляді графа.

Приклад системи такого типу – Communiware. Ця система є

інструментарієм нового покоління для створення вертикальних Web-

сайтів і порталів.

Модульна

модель. У схожих системах контент розділено на окремі

модулі за типами вмісту. Структура даних залежить від модуля, і вся

робота з контентом зосереджена всередині модуля. Модулі незалежні і

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

описуються за допомогою фіксованого набору характеристик – типи

документів суворо фіксовані. Розширювати функціональність можна за

рахунок додавання

нового модуля, заміни або редагування існуючого коду.

Зазвичай, немає жодної системи зв’язків між документами різних модулів

і між документами одного і того ж модуля. Стандартний набір типів

контенту (модулів) такий: посилання, статті, файли, новини, розділи, форум.

Незважаючи на очевидну обмеженість моделі даних, системи

на її основі найпопулярніші завдяки своїй простоті. Для

прикладу, можна

пригадати такі системи, як PHPNuke, Mambo і Xoops.

У модульних CMS-систем є один загальний недолік – суворо

фіксована в межах модуля структура вмісту. Проте, для розширення

626

їх функціональності можна скористатися зовнішніми модулями, яких в

Інтернеті чимало. Очевидна перевага цих систем – можливість

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

короткий час.

4.7.14. Вільно поширювані CMS-системи

Розглянемо такі CMS-системи: eZ Publish 3.2, APC ActionApps,

Mambo 4.0.14 і Xoops (версії 2.0.5 і 2.0.6). Кожна з них позиціонується

розробниками як система для створення будь-якого сайту (від

корпоративного порталу до домашньої сторіночки) і управління його

вмістом. Система eZ Publish призначена також для створення та

управління вмістом Internet-магазину, сайту новин, фотогалереї або

форуму. APC ActionApps має унікальну властивість додавання

динамічних розділів на існуючому сайті і здатна

управляти вмістом

багатьох сайтів. Але все-таки правильніше говорити, що CMS-системи

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

Перш ніж почати використання певної CMS, необхідно визначи-

тися, з якими типами контенту хочете працювати – чи будуть на сайті

статті, фільми, новини, форуми тощо. Зазвичай CMS-системи постав-

ляються з деякою кількістю готових до роботи

вбудованих типів

Рис. 4.5. Приклад організації контенту за допомого мережної моделі даних

627

контенту, а частину з них дають змогу редагувати вбудовані типи

контенту або створювати нові (eZ Publish, APC ActionApps). Але є і

системи, в яких усі типи контенту суворо фіксовані (Xoops, Mambo).

Кожному користувачеві системи має бути приписана якась роль,

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

можуть об’єднуватися в різні групи з визначеними правами.

Деякі

системи дають змогу створювати нові групи і встановлювати права,

відмінні від прав існуючих груп (eZ Publish, ActionApps, Xoops), і ця

властивість іноді виявляється дуже корисною.

Обираючи CMS-систему, завжди хочеться отримати максимум

функціональності при мінімумі витрат, та і на підтримку бажано

затрачати якомога менше часу і зусиль. Аби бодай якось наблизитися

до цього ідеалу, потрібно спершу визначити

необхідний мінімум завдань,

які має вирішувати система. Під час створення документ наділяють

набором характеристик, які визначають поточний етап його життєвого

циклу, тому варто звернути увагу на таке: наскільки гнучка структура

контенту конкретної системи, наскільки простий процес створення

контенту, як він упорядковується, як відбувається управління робочим

потоком документів і чи можливе використовування контенту спільно

іншими інформаційними системами.

Переваги систем із гнучкою структурою контенту очевидні. Вони

дають змогу за потреби розширювати і додавати нові типи контенту

засобами самих систем, не займаючись, наприклад, пошуком осторонь

придатної функціональності. З іншого боку, за наявності багатьох вільно

поширюваних модулів (типів контенту) можна працювати і з система-

ми, що мають фіксовану структуру

контенту. Проте, в цьому випадку

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

модулів може виявитися неповною.

Наступний важливий момент – каталогізація і впорядковування

контенту. В eZ Publish весь контент сайту подають у вигляді дерева

вузлів (вузли – це інкапсуляції контент-об’єктів). Упорядковування

контенту усередині дерева проводиться за допомогою контейнерів

(папки), під які поміщаються відповідні

об’єкти (як у файловій системі).

Для задавання місце розміщення об’єкта (визначення вузлів, які з ним

асоціюються) використовується властивість location. З її допомогою

під час створення або редагування об’єкта можна визначити, де

628

додатково буде відображатися об’єкт, окрім місця його створення. В

додаванні до ієрархічної структури, дерево контент-вузлів може бути

поділеним на логічні розділи (секції).

Для впорядковування контенту в ActionApps використовують

розширювану систему категорій: у системі спочатку є набір категорій,

а адміністратор може їх змінювати або додавати власні. Застосовують

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

моделювати ієрар-

хічну структуру (в категорії може бути одна або декілька підкатегорій).

У Mambo і Xoops теж застосовують системи категорій, але оскільки

ці продукти побудовані за модульним принципом, наявність або

відсутність системи категорій залежить від модуля. Скажімо, для

модуля “статті” існують категорії, а для модуля “форум” – ні. Але яку

б категорію в модулі “статті”

не створювали, структура документів у

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

категорії суто смисловий. Якщо в модулі використовують систему

категорій, можна створювати нові категорії, знищувати або змінювати

тип доступу для існуючих.

Механізм каталогізації eZ Publish видається функціональнішим і

розвинутішим, але дуже складним для розуміння. Застосування ж для

цієї

мети категорій, як у решті систем, значно звичніше і зрозуміліше,

але не дає можливості вирішити, наприклад, проблему відображення

документа водночас у двох категоріях.

Тепер звернемо увагу на те, як CMS-системи управляють потоком

документів, чи дають вони змогу створювати різні версії одного

документа і чи дають можливість адміністраторам стежити за

процесом публікації документів.

Реальний контент eZ Publish, який зберігається всередині контент-

об’єктів, може існувати в одній або декількох версіях. Щоразу, коли

контент редагується, створюється його нова версія, а стара залишається

незайманою. Ця система версій дає змогу користувачам повертати/

відміняти зміни, а щоб запобігти переповнюванню бази даних старими

невживаними версіями, адміністратор може встановити обмеження на

кількість версій для

контент-класу. Власне версія документа в eZ Publish

описується за допомогою таких характеристик: номер версії, статус

документа (чернетка, опублікована, архівна), мова, творець, дата зміни.

Автоматично контролюється авторство документів: не можна

629

редагувати чужі документи, можна лише створювати їхні копії і

редагувати їх. Контролюється і статус документа; декілька версій

документа не можна опублікувати водночас, оскільки статус

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

різних мов різні версії документа. Документи із статусом “архівні” не

можна редагувати і публікувати (для редагування створюється їхня копія

–

чернетка).

У системі ActionApps підтримується основний процес ухвалення:

автор документа має право на його публікацію. Відмінність від eZ

Publish полягає в тому, що документ публікується відразу після його

додавання до системи. При цьому статус документа ActionApps може

змінюватися таким чином: активний (асtive), очікуючий розгляду

(реnding), застарілий (expired), у процесі написання (hold bin), очікуючий

вилучення (trash bin). Кожний документ, будучи створеним, відразу

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

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

Поняття версії документа в ActionApps не застосовується, втім, як і в

Xoops, і в Mambo.

У системах Xoops і Mambo немає загальної системи категорій й

уніфікованого способу опису документів. Опис залежить від модуля

(тип контенту), до якого належить

документ. Але таких понять, як

версія документа, нємає. У Xoops не застосовується і поняття стату-

су документа, але деякі документи (залежно від модуля) можна зано-

сити до архіву. У системі Mambo документ має статус опублікованого,

архівного, схваленого або такого, що перебуває в процесі редагування.

Архівні статті можна редагувати. Статті, додані користувачами,

мають бути

схвалені адміністратором. Загалом опис документів у

системах Mambo і Xoops недостатньо повний і не відповідає навіть

основам стандарту Dublin Core (один з найпоширеніших наборів

елементів для опису структури документів, яке створюється вже

протягом декількох років міжнародною групою Dublin Core Initiative,

dublincore.org). Отже, для цих систем “відрізаний” один зі шляхів

вирішення проблем спільного і повторного використовування контенту,

організації розподілених сховищ даних.

Найрозвинутішу систему управління документами надає eZ Pub-

lish. Версія 3.2 цієї системи підтримує основний процес ухвалення (право

630

публікації документа має лише його автор), роботу з версіями і

трансляціями документів, найпростіше відстежування ревізій.

Важливо, як дані системи використовують контент спільно з

іншими інформаційними системами. Найрозвинутіші можливості щодо

цього має ActionApps: забезпечується обмін інформацією усередині

самої системи і з іншими сайтами APC ActionApps (у термінах цієї

системи таку властивість називають content роoling). Обмін інформа-

цією здійснюють

редактори або адміністратор. Також підтримуються

відображення категорій і полів для загального контенту, імпорт і

експорт контенту з інших баз даних. Нарешті, ActionApps (як і eZ Publish

і Xoops) підтримує використовування заголовків RSS.

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

циклом контенту в CMS-системах. Під час створення документа, він

наділяється набором характеристик (статус, автор, дата застарівання

тощо), відповідних поточному етапу

його життєвого циклу. Потім

документ може бути модифіковано, як і його опис, за допомогою засобів

CMS. Якщо автор документа не володіє достатніми правами, документ

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

За певних умов (наприклад, було встановлено дату застарівання

документа або його зрідка читають) документ може бути занесений

до архіву. Взагалі кажучи

, такі документи заносять до архіву для

полегшення і прискорення доступу до актуальних документів, але деякі

системи (наприклад, Mambo) просто дублюють інформацію до архіву.

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

ми та відредагованими (це залежить від системи). Як архівні, так і

актуальні документи, можна експортувати на інші сайти, в інші інфор-

маційні

системи, конвертувати в інші формати тощо.

4.7.15. Комерційні системи

Програмні продукти, які далі будемо розглядати, спрямовані

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

класифіковані як ЕСM-системи. Оскільки ці системи – комерційні, не

завжди можна з’ясувати, які моделі даних використовуються під час

їх побудови. Крім того, ЕСM, у принципі, складно класифікувати за

запропонованим сценарієм, оскільки вони, зазвичай, складаються з

631

наборів різних сервісів і програм, кожне з яких може використовувати

свою модель даних.

Documentum – провідний постачальник програмного забез-

печення для інтегрованого управління документами і контентом. У

галузі управління документами його найближчими суперниками є Open

Text, IBM і FileNet, а у сфері управління контентом – Vignette, Stellent

і Interwoven.

У галузі управління документами рішення від Documentum надійні

завдяки можливостям реплікації контенту й

управління ним на дуже

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

а також підтримці перетворень складно структурованих документів,

розширюваності репозиторію і підтримці XML. Реалізація Collabora-

tion Edition в Documentum 5 і придбання цією компанією eRoom

примусило вважати Documentum прямим конкурентом Open Text і In-

terwoven. Важливі переваги Documentum полягають у глибокому знанні

процесів управління потоком документів, контролю версій і управління

архівами. Проте, рішення Documentum можуть

виявитися менш

ефективними, ніж деякі рішення-конкуренти, при обробленні

представлення документів на великих Web-сайтах.

Система Documentum має об’єктно-реляційну архітектуру (тобто

об’єктна модель даних відображається на реляційну базу даних), тому

в нашій класифікації може бути віднесена до об’єктних CMS-систем.

FileNet. Цей постачальник, що фокусується на ЕСM, довго був

лідером на такому

ринку, а купивши компанію eGail FileNet, вийшов на

ринок WCM. Це дало змогу FileNet запропонувати широкий спектр

послуг організаціям, що реалізовують рішення для управління

контентом. Дотепер компанія фокусується переважно на управлінні

процесами і підтримці контенту транзакції. 2003 р. FileNet розробила

архітектуру P8, яка підтримує середовища Microsoft і Java.

Пропонуються такі пакети: Business Process Manager – автоматизація

складних бізнес-процесів; Content Manager – управління, сумісне

використовування і доступ до документів або

інших форм контенту;

Web Content Manager – автоматизація створення, ухвалення і публікації

контенту на Web-сайтах; Image Manager – управління фіксованими

типами контенту, включаючи зображення, факси тощо.

632

IBM. Система IBM Content Manager дає змогу організаціям

отримувати, зберігати, управляти і поширювати всі форми цифрового

контенту, включаючи відскановані текстові документи, XML, HTML і

мультимедіа. Недавно IBM перепроектувала цей програмний продукт,

удосконали вши його, додавши в нього функції управління документами,

у тому числі можливості контролю версій і підтримки ODMA. Це дало

змогу позиціонувати Content Manager як повне інтегроване рішення

для управління документами, призначене

для споживачів, які хочуть

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

Інший ключовий момент – WCM-можливості. Корпорація анон-

сувала об’єднання Content Manager з WebSphere Portal, який забезпечує

можливості публікації в Web. Тепер Content Manager буде репозиторієм

для WebSphere-порталу. Content Manager також з’єднаний з WebSphere

Portal за допомогою портлетів, які дають можливість користувачеві

отримувати доступ до контенту всіх типів. Після придбання компанії

Tarian Software, постачальника рішень для

управління записами, IBM

розширила спектр свого ЕСM-інструментарію за рахунок засобів

управління життєвим циклом контенту. Модель даних Content Man-

ager – об’єктно-орієнтована.

Open Text Livelink – це документо-орієнтований продукт, який,

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

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

календарі і можливості управління процесом робіт. Livelink підтримує

Java, ActiveX, PDF і HTML. Ця система була розроблена

для корпо-

ративних intranet-середовищ, не підтримує інтеграцію з репозиторіями

Microsoft Exchange, а її інтеграція з Lotus Notes/Domino можлива тільки

в одному напрямі. Livelink підтримує пошукові запити на природній

мові і кластеризацію результатів за темами, засоби управління потоком

документів і модулі взаємодії в режимі реального часу. Архітектура

системи — модульна, що дає змогу віднести Open Text Livelink до

систем модульного типу.

Interwoven – один

із провідних постачальників засобів WCM.

Платформа для управління контентом Interwoven 5 спрямована на

великі компанії зі списку Fortune 500 і організації, які потребують

контролю за критично важливими бізнес-процесами. Платформа