Державний вищий навчальний заклад

"Українська академія банківської справи Національного банку України"

Кафедра економічної кібернетики

ДО ЗАХИСТУ

Завідувач кафедри

економічної кібернетики

канд. техн. наук, доцент

_____________ К.Г. Гриценко

"___"_______________ 2012 р.

ВИПУСКНА РОБОТА

на здобуття освітньо-кваліфікаційного рівня бакалавр

за напрямом 6.030502 "Економічна кібернетика"

галузі знань 0305 "Економіка та підприємництво"

Тема роботи: "Автоматизація генерації документів на основі

користувацьких шаблонів"

Виконав студент 4 курсу, група ЕК-81 __________________ В.І. Акіменко

"___"_____________ 2012 р.

Керівник випускної роботи ______________ В.С.Домбровський

"___"_____________ 2012 р.

Тема роботи затверджена наказом по академії від "___"____ 2012 р., №___

Суми – 2012

ЗМІСТ

ВСТУП ................................................................................................................. 8

РОЗДІЛ 1 ГЕНЕРАЦІЯ ДОКУМЕНТІВ НА ОСНОВІ КОРИСТУВАЦЬКИХ

ШАБЛОНІВ ЯК ОБ'ЄКТ АВТОМАТИЗАЦІЇ ................................................ 11

1.1 Характеристика основних принципів генерації документів на основі

користувацьких шаблонів ............................................................................. 11

1.2 Аналіз стану автоматизації у сфері електронного документообігу .... 17

1.3 Основні вимоги до системи автоматизованої генерації документів на

основі шаблонів користувачів ...................................................................... 21

РОЗДІЛ 2 РОЗРОБКА ПРОЕКТУ АВТОМАТИЗОВАНОЇ СИСТЕМИ

ГЕНЕРАЦІЇ ДОКУМЕНТІВ НА ОСНОВІ ШАБЛОНІВ .............................. 27

2.1 Нормативно-правове забезпечення електронного документо-обігу27

2.2 Алгоритм вирішення задачі автоматизації генерації документів на

основі користувацького введення ................................................................ 29

2.3 Вибір архітектури та технології автоматизованої системи .............. 51

2.4 Програмне та апаратне забезпечення ................................................. 55

РОЗДІЛ 3 РЕАЛІЗАЦІЯ ПРОТОТИПУ АВТОМАТИЗОВАНОЇ СИСТЕМИ

ГЕНЕРАЦІЇ ДОКУМЕНТІВ НА ОСНОВІ КОРИСТУВАЦЬКИХ

ШАБЛОНІВ ....................................................................................................... 57

3.1 Структура та особливості реалізації інформаційного забезпечення

системи генерації документів на основі користувацьких шаблонів......... 57

3.2 Проектування інтерфейсу користувача .............................................. 64

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

системи ............................................................................................................ 71

ВИСНОВКИ ....................................................................................................... 79

ПЕРЕЛІК ВИКОРИСТАНИХ ДЖЕРЕЛ ......................................................... 82

ДОДАТКИ .......................................................................................................... 85

8

ВСТУП

Генерація документів – процес створення документації та заповнення

її інформацією. Цей процес є масовим по своїй природі, адже всі

господарські дії потрібно супроводжувати відповідними документами.

Кожен офісний працівник стикається із потребою періодично

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

записки, заяви, накази та ін. Процес створення та заповнення даного роду

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

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

працівника.

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

варіюватися від чотирьох хвилин до більше ніж однієї години. Особливо

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

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

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

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

Подібна затримка в часі має свої економічні наслідки. По-перше,

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

наслідок чого підприємство недоотримає корисної віддачі від основного

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

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

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

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

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

зазнає збитки через недоотримані податки з прибутку підприємств.

Таким чином проблема неефективного використання часу та робочої

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

9

значення. Саме на подолання даної проблеми і направлене дослідження у

даній випускній роботі.

Отже, об'єктом дослідження є процес генерації електронних

документів.

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

документів на основі користувацьких шаблонів.

Мета випускної роботи полягає в розробці автоматизованої системи

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

Для досягнення поставленої мети необхідно виконати наступні

задачі:

– охарактеризувати основні засади генерації документів на

основі користувацьких шаблонів;

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

сьогоднішній день;

– сформувати основні вимоги до автоматизованої системи

генерації документів на основі користувацьких шаблонів;

– дослідити нормативно-правове забезпечення, що формує

правову основу процесу генерації документів на підприємстві;

– розробити алгоритм вирішення поставленої задачі;

– обрати архітектуру та технологію для розробки

автоматизованої системи;

– визначити програмне та апаратне забезпечення вирішення

задачі;

– розробити структуру та визначити особливості реалізації

інформаційного забезпечення системи;

– спроектувати інтерфейс користувача;

– визначити очікуваний економічний ефект від впровадження

автоматизованої системи генерації документів на основі користувацьких

шаблонів.

10

Методологічну основу роботи сформували сучасні концепції

економічної кібернетики. В процесі її виконання використані методи

наукового дослідження: аналіз, синтез, індукція, дедукція, зіставлення,

порівняння.

Інформаційно-фактологічну базу дослідження сформували

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

електронної документації на підприємстві, наприклад, Закон України "Про

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

2003 року [19]. Крім цього фактологічну базу було сформовано на основі

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

Херсонській регіональній філії ДП "Центр державного земельного

кадастру" [24].

11

РОЗДІЛ 1 ГЕНЕРАЦІЯ ДОКУМЕНТІВ НА ОСНОВІ КОРИСТУВАЦЬКИХ

ШАБЛОНІВ ЯК ОБ'ЄКТ АВТОМАТИЗАЦІЇ

1.1 Характеристика основних принципів генерації документів на

основі користувацьких шаблонів

Автоматизація у широкому розумінні – це використання людиною

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

досягнення власних цілей. Ще з давніх часів люди використовували

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

підвищення його ефективності.

Автоматизація у більш вузькому розумінні – це один з напрямів

науково-технічного прогресу, спрямований на застосування

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

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

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

істотно зменшують міру цієї участі чи трудомісткість виконуваних

операцій [21, с. 20].

У сучасному розумінні автоматизація – це перш за все використання

інформаційних технологій, які здатні спростити певний виробничий

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

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

праці, витіснення її ручних форм, підвищення її продуктивності. Зараз

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

людини, цей процес є глобальним.

Автоматизація виробництва покликана зменшити фізично важку,

монотонну працю, переклавши її на плечі машин. Автоматизація

управління спрямована на використання комп’ютерів та інших технічних

засобів обробки та передачі інформації в керуванні виробництвом,

господарчими процесами.

12

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

притаманний всім офісним працівникам, як генерація та заповнення

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

документації, які використовуються на сучасних підприємствах. До таких

форм документації належать: звіти, заяви, накази, акти, укази, і т.д. З

розвитком суспільства та ІТ-технологій постійно покращувались засоби

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

потрібно було вести. Зараз майже весь процес документогенерації

відбувається у електронній формі.

Процес генерації документів є складовою частиною документообігу.

Документообіг – це рух документів в організації починаючи з моменту їх

створення або одержання до завершення виконання або відправлення. Це

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

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

взаємозв'язку [13].

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

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

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

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

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

сфері діловодства та підвищити оперативність виконання. Це дозволяє

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

уніфікувати шляхи руху, порядок обробки різних їх категорій.

У розрізі поняття документообігу вирізняють електронний

документообіг. Електронний документообіг (обіг електронних документів)

– це сукупність процесів створення, оброблення, правлення, передавання,

одержання, зберігання, використання та знищення електронних

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

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

документів [15].

13

Головним елементом електронного документообігу є сам

електронний документ. Електронний документ – це документ, інформація

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

реквізити документа. Електронний документ може бути створений,

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

форму. Візуальною формою подання електронного документа є

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

у формі, придатній для приймання його змісту людиною [14].

Оригіналом електронного документа вважається електронний

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

електронного документа кільком адресатам або його зберігання на кількох

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

вважається оригіналом електронного документа. Якщо автором

створюються ідентичні за документарною інформацією та реквізитами

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

оригіналом і має однакову юридичну силу.

Метою функціонування даної автоматизованої системи є саме

автоматизація створення електронних документів. Тобто об'єктом у

даному разі виступає один етап документообігу.

Для подальшого спрощення, під терміном "документогенерація"

будемо вважати процес створення та заповнення документів необхідною

інформацією.

Користувацьким шаблоном називається шаблон, який був

заздалегідь створений людиною для полегшення подальшого

багатократного заповнення певного документа. Для одного документа

може бути створено декілька шаблонів.

На нашу думку, документогенерацію можна класифікувати по

декільком критеріям:

– за формою:

1) електронна;

14

2) машинописна;

3) писемна.

– за наявністю готового шаблону:

1) на основі шаблонів;

2) без шаблону.

– за періодичністю:

1) періодична;

2) неперіодична.

Для кращого розуміння основних засад генерації документів на

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

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

найрозповсюдженішим.

Отже, генерація документів на основі шаблонів відбувається у

декілька етапів:

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

нового документа;

– потім працівник шукає та відкриває шаблон потрібного

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

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

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

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

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

час та сили;

– на наступному етапі працівник шукає потрібні поля та вносить

в них необхідну інформацію шляхом друку на клавіатурі, або копіюванням

інформації з певного джерела;

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

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

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

місці;

15

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

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

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

заповнені одразу декількох взаємопов'язаних документів. Як правило,

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

своєму оформленні. У такому разі працівник змушений виконувати велику

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

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

Слід також зазначити, що даний процес генерації документів є

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

підприємства. У своїй основі він дуже простий, але віднімає у

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

що, як правило, об'єми документації, необхідної для заповнення, є дуже

великими, а сам процес є монотонним та рутинним.

Особливістю даної галузі досліджень є те, що з генерацією

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

кожній фірмі будь-якого типу та форми власності потрібно створювати та

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

що дає перспективи автоматизації даного процесу, деякі – одноразово, і

автоматизовувати даний вид діяльності не має сенсу.

На всіх етапах даного процесу відбуваються певні витрати часу, але

як предмет автоматизації можуть бути лише другий, третій, та п'ятий

етапи. На першому та четвертому етапі програмні засоби поки що не

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

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

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

діловодства .

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

під час проходження виробничої практики у "Херсонська регіональна філія

Державне підприємство "Центр державного земельного кадастру" [24],

16

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

документації на різних етапах не є рівномірними. Так, на другому етапі,

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

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

Найбільшу увагу складає третій етап генерації документа на основі

користувацького шаблону, оскільки на нього витрачається більше часу ніж

на всі інші чотири етапи разом. Саме заповнення необхідної інформації у

визначені місця документа є дуже трудо- та часовитратним. Згідно

спостережень, працівники Херсонської регіональної філії Державне

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

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

середнього об'єму. Кількість таких документів варіюється в залежності від

посади працівника.

Наприклад, інженери та провідні інженери мають складати комплекс

технічної документації по кожній земельній ділянці. У цей комплекс

входять одинадцять документів. Після узгодження технічної документації

у відповідних органах обласної і районної влади складається "Державний

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

при наявності заздалегідь зібраних даних, витрачає на заповнення

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

що є дуже великим показником.

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

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

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

помилок.

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

та держави в цілому. На дану роботу витрачаються людські ресурси, у

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

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

17

цих ресурсів є теж великими, що має негативний вплив на економічний

стан держави.

Отже, з огляду на наведені вище факти, процес генерації документів

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

найголовнішим предметом автоматизації є третій етап загальної схеми

процесу, а саме етап створення та заповнення шаблону інформацією. На

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

найбільше часу.

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

був складним, і потребував значних витрат часу та великої уваги. Саме

тому люди завжди намагались цей процес автоматизувати.

1.2 Аналіз стану автоматизації у сфері електронного документообігу

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

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

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

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

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

документації. Це пов'язано з тим, що сама документація зараз ведеться

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

Довгий час у сфері автоматизації створення та заповнення

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

зроблений на етапі переходу до електронної документації, коли програмні

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

інформаційні та виробничі системи.

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

функція автоматичного створення певних документів. Даний функціонал

18

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

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

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

централізованого сховища. Всі потрібні шаблони є вже наперед заданими,

що інколи є проблемою. Після отримання інформації з бази даних,

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

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

належать "1С: Підприємство" та ін.

Нажаль не у всі спеціалізовані інформаційні та виробничі системи

вбудований функціонал з генерації та автоматичному заповненню певних

документів звітності. Крім цього, не на всіх підприємствах дані системи

використовуються, через їх високу вартість, або недоцільність. Також слід

враховувати той факт, що є багато видів документації, які не входять у

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

потребують автоматизації, через високі трудо- та часовитрати на своє

заповнення.

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

Система автоматизації документообігу – це організаційно-технічна

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

поширення електронних документів в комп'ютерних мережах, а також що

забезпечує контроль над потоками документів в організації [22]. До

найпотужніших систем електронного документообігу в Україні належать:

– cистема електронного документообігу та автоматизації бізнес-

процесів Megapolis.DocNet (www.inbase.com.ua);

– система електронного документообігу "MasterDoc"

(www.bkc.com.ua);

– система електронного документообігу "ДІЛО"

(www.eos.com.ua);

– програмно-методичний комплекс класу управління

документами ІНТАЛЄВ (www.intalev.ua);

19

– система електронного документообігу FossDoc

(www.fossdoc.com.ua).

Розглянемо функціональні можливості cистеми електронного

документообігу та автоматизації бізнес-процесів Megapolis.DocNet. Даний

продукт має назву Megapolis.Документообіг. Це комплексне програмне

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

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

Megapolis.Документообіг є однією з кращих українських систем

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

органах державної влади України. Нашою компанією реалізоване більше

50 проектів з впровадження системи Megapolis.Документообіг у різних

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

господарство [4].

В 2006 році система Megapolis.Документообіг стала переможцем у

всеукраїнському конкурсі-виставці «Кращий вітчизняний товар 2006

року», у номінації «Розробка інформаційних систем і програмного

забезпечення».

Megapolis.Документообіг має експертний висновок ДСТСЗІ СБУ,

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

у сфері технічного захисту інформації в Україні. Реалізовані послуги

відповідають вимогам документа НД ТЗІ 2.5-004-99 «Критерії оцінки

захищеності інформації в комп'ютерних системах від несанкціонованого

доступу» і забезпечують рівень гарантій Г-2.

Основними цілями впровадження системи Megapolis.Документообіг

є підвищення прозорості, керованості та ефективності роботи організації

за рахунок:

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

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

– значного підвищення швидкості обробки паперових

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

20

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

розпізнавання та механізмів електронному цифровому підпису;

– впровадження регламентів автоматизованої роботи з

документами;

– поступового перехід до повністю безпаперового

документообігу.

Функціональний склад системи включає:

– звернення громадян;

– діловодство та контроль виконавчої дисципліни;

– підготовка документів;

– архівна справа;

– електронний архів;

– адміністрування та безпека;

– web-Модуль;

– модуль побудови звітів;

– електронний цифровий підпис.

Дана система автоматизації документообігу містить широкий

функціонал та привітний графічний інтерфейс користувача. Проте, слід

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

дуже витратливим та недоцільним саме через її масштабність та складність

впровадження. Для вирішення конкретної задачі генерації документів на

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

спеціалізованими системами.

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

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

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

конкретний вид документації. На даний момент, провівши ґрунтовний

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

свідчить про складність реалізації даної системи, або про ще

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

21

Другий фактор має силу через те, що багато людей стикаються лише

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

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

переймаються про автоматизацію цього процесу. Хоча слід зазначити, що

скоротивши даний процес у часі до однієї хвилини, можна було б

підвищити ефективність праці працівника, або отримати сім хвилин

додаткового вільного часу з кожного документа.

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

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

Автоматизація документогенерації для таких працівників підвищить

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

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

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

Таким чином, створення автоматизованої системи генерації

документів на основі користувацьких шаблонів є економічно доцільним та

бажаним.

1.3 Основні вимоги до системи автоматизованої генерації документів

на основі шаблонів користувачів

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

генерації документів можемо сформувати ряд вимог до проекту, що

розробляється в рамках випускної роботи. Для цього спочатку

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

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

Отже, нам бачиться надійний та зручний додаток для швидкої

генерації документів та їх наборів. Генерація документів має бути

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

22

у нашій програмі. У шаблонах повинен міститися статичний текст та

посилання на певні міста, де потрібно вставити відповідне значення.

Назвемо такі міста динамічними полями.

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

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

джерелом інформації. Отже, можливість одночасного заповнення

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

додатку, його особливістю. Відсутність конкурентів на даному вузькому

ринку дає гарні передумови для розробки даного додатку.

Дана програмна система має орієнтуватись на всіх, заінтересованих у

швидкій генерації статично-динамічного тексту користувачів. Основною

сферою користування програмним додатком має стати персональне

використання, оскільки виконання такої вузької задачі централізовано на

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

без добре сформованої системи захисту. Більш розгорнуте та детальне

бачення проекту дивіться у додатку А.

Отже, вимоги – це можливості або умови, яким повинна відповідати

система чи проект. Основне завдання етапу визначення вимог – знайти,

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

буде зрозуміла і клієнтам і розробникам [16, с. 89].

Тобто, необхідно розробити перший пакет вимог до системи. Далі, у

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

уточнюватись і доповнюватись. Даний підхід дозволить максимально

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

уніфікованого підходу до розробки програмного забезпечення, який і

планується використовувати.

Більш детальну інформацію про уніфікований підхід та ітеративну

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

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

вимог високого рівня. Ці вимоги є більш абстрактними, забезпечення їх

23

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

переглядаються під час подальшої розробки, хоча і така ситуаціє не

виключена. До них відносяться:

– програмний продукт має виконувати свою головну функцію, а

саме генерацію документів та їх наборів;

– програмний продукт має бути орієнтований на користувача і

задовольняти його потреби, пов'язані зі сферою роботи програми;

– програмний продукт має бути економічно ефективним.

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

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

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

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

програмних продуктів, є система FURPS+.

Система FURPS+ є акронімом, який складається з п'яти слів:

Functionality, Usability, Reliability, Performance, Supportability. Дана система

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

запропонована у компанії Hewlett-Packard, та вперше опублікована

вченими Робертом Граді та Деборою Касвел у 1987 році. Зараз ця система

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

багатьох компаніях [2].

Суть поділу полягає в тому, що всі вимоги до проекту програмної

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

безпосередньо можливостей системи та її властивостей, та

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

надійності, продуктивності, та можливості підтримки.

Отже, за даною моделлю було складено перший пакет вимог до

програмного продукту:

– функціональні вимоги:

1) Користувацьке введення. Весь процес генерації та

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

24

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

користувача, та надати додатку необхідної гнучкості.

2) Персоналізація. Для кращої диференціації інформації

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

3) Експорт/імпорт інформації. Потрібно реалізувати

систему переносу інформаційної бази програми з одного комп'ютера

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

разі переміщення.

4) Створення користувацьких шаблонів. Користувач

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

5) Підтримка форматів. Програмний додаток має бути

орієнтований на роботу з файлами у форматі *.doc та *docx, як із

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

6) Швидкість роботи. Програмний додаток має швидко

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

створення документації, є причиною створення даного додатку.

7) Гнучкість архітектури. Програмна архітектура системи

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

структуру додатку без негативного впливу на інші частини даної

структури.

– вимоги зручності:

1) Простота використання та орієнтованість на певний

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

щоб він не ускладнював певну обрану задачу, а дуже добре з нею

справлявся.

2) Інтуїтивність інтерфейсу користувача. Користувач

повинен легко, на інтуїтивному рівні, розуміти, що йому необхідно

зробити, щоб отримати бажаний результат.

25

3) Повна зрозумілість. Дана вимога потребує, щоб у

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

які мають допомагати у кращому розумінні роботи програми.

– вимоги надійності:

1) Частота збоїв. Частота збоїв має бути зведена до

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

пред'явлена зрозуміла коротка інформація про проблему та

інструкції щодо її подолання.

2) Стійкість бази даних. Процес взаємодії із базою даних

має бути спроектований таким чином, щоб при жодних обставинах

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

– вимоги продуктивності:

1) Час відгуку. Час відгуку має зведений до мінімуму, або

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

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

з пакетом MS Word під час генерації документів залежить від

показників робочої станції).

2) Точність. Програмна система має безпомилково

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

користувач.

3) Доступність. Робота з програмним додатком має бути

доступна для користувача у будь-який час.

4) Використання ресурсів. Програмний додаток не повинен

використовувати більше 100 КБ оперативної пам'яті робочої станції

та давати навантаження більше ніж на 1% від загальної потужності

середньостатистичного процесору рівня Intel Pentium 2 ГГц.

– вимоги можливості підтримки:

1) Конфігурування. Програмна система має підтримувати

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

користувача.

26

2) Он-лайн підтримка. Для відповідей на питання, у

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

Таким чином був сформований перший пакет вимог до системи

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

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

під час зворотного зв'язку із замовниками.

27

РОЗДІЛ 2 РОЗРОБКА ПРОЕКТУ АВТОМАТИЗОВАНОЇ СИСТЕМИ

ГЕНЕРАЦІЇ ДОКУМЕНТІВ НА ОСНОВІ ШАБЛОНІВ

2.1 Нормативно-правове забезпечення електронного документо-

обігу

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

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

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

рівні.

Законодавчо відносини, пов'язані з інформацією, інформаційно-

комунікаційними технологіями, визначено пріоритетними. Так, Угодою

між Україною і ЄС про наукове і технологічне співробітництво

(04.07.2002) [23] технології інформатизації суспільства визначені серед

одинадцяти напрямів співробітництва. Законом України "Про пріоритетні

напрями розвитку науки і техніки" [20] серед семи п’ятим пріоритетом

визначено нові комп'ютерні засоби та технології інформатизації

суспільства.

За останнє десятиріччя в Україні ухвалено низку законів та

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

сфери інформаційних відносин, зокрема і електронного документообігу.

Нормативно-правову базу побудовано на принципах інформаційної

відкритості та свободи, гарантованості інформаційної безпеки особистості,

суспільства, держави згідно Конституції України. Законодавство регулює

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

вільного обміну інформацією й окремими обмеженнями на її поширення.

Закон України "Про електронні документи та електронний

документообіг" [19] був прийнятий у травні 2003 року. Цей Закон

встановлює основні організаційно-правові засади електронного

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

28

У контексті Закону електронний документ розглядається як

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

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

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

оброблення, відправлення, передавання, одержання, зберігання,

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

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

підтвердженням факту одержання таких документів.

Склад та порядок розміщення обов'язкових реквізитів електронних

документів визначається законодавством. Електронний документ може

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

засобами у візуальну форму.

Візуальною формою подання електронного документа є

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

у формі, придатній для приймання його змісту людиною. Юридична сила

електронного документа не може бути заперечена виключно через те, що

він має електронну форму [10].

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

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

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

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

підприємницькій діяльності.

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

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

досягається за рахунок того, що даний програмний додаток не втручається

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

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

користувач може робити із сформованим документом будь-які інші

операції.

29

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

інформацією є також повністю під контролем користувача, адже саме він

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

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

потрібно розмістити відповідну інформацію.

2.2 Алгоритм вирішення задачі автоматизації генерації документів

на основі користувацького введення

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

розробка програмного додатку буде проходити згідно уніфікованого

процесу. Дана практика визнана кращою для розробки програмних систем,

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

Rational Unified Process (RUP) є ітеративним процесом розробки

програмного забезпечення створеним Rational Software – підрозділом IBM

з 2003 року. RUP не є єдиним, конкретним розпорядчим процесом, а

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

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

процесу, які підходять під їх потреби [5].

До 1997 року, Rational Software придбав Verdix, Objectory, Requisite,

SQA, Performance Awareness, та Pure-Atria. Поєднання баз досвіду цих

компаній привело до вироблення семи «кращих практик» сучасної

програмної інженерії:

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

– управляти вимогами;

– використовувати компонентну архітектуру;

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

– постійно перевіряти якість;

30

– контролювати зміни;

– підлаштовуватись.

RUP визначає життєвий цикл проекту, що складається з чотирьох

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

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

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

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

позначає досягнення цілі.

– Початкова фаза. Первинною ціллю є адекватна оцінка системи,

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

встановлюються бізнес випадки, які включають бізнес-контекст, фактори

успіху (очікувані доходи, визнання на ринку, і т.д.), а також фінансовий

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

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

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

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

1) зацікавленими сторонами досягається згода з визначення

масштабів і оцінки вартості/термінів;

2) розуміння вимог;

3) достовірність оцінок.

Якщо проект не пройде цей етап, що називається віхою життєвого

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

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

– Фаза уточнення. Основна мета полягає в пом'якшенні

ключових ризиків, виявлених на основі аналізу до кінця цієї фази. Фаза

уточнення – фаза де проект починає набувати форми. На цьому етапі

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

базову форму.

Ця фаза має пройти віху життєвого циклу архітектури (LCA),

задовольняючи такі критерії:

31

1) модель прецедентів повинна бути завершена на 80%;

2) повинен бути зроблений опис архітектури програмного

забезпечення в процесі розробки;

3) переглянуті випадки та список ризиків;

4) створені прототипи програмної системи.

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

він був скасований або змінений. Тим не менше, після закінчення цього

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

набагато складніші та згубні, при здійсненні.

Системна архітектура є ключовим елементом розробки, що

отримується з аналізу предметної області.

– Фаза конструювання. Основна мета полягає в створенні

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

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

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

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

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

Цей етап дає створює перший реліз програмного забезпечення. Його

завершення позначає віха початкової боєготовності.

– Фаза впровадження. Основна мета полягає в переведенні

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

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

кінцевих користувачів та обслуговуючого персоналу, бета-тестування

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

Продукт також перевіряються на відповідність рівню якості,

встановленого в початковій фазі.

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

розробки завершується.

32

На кожному з цих етапів йде робота у розрізі шести інженерних

дисциплін Схематично процес розробки можна зобразити як на

рисунку 2.1.

Рисунок 2.1 – Загальна схема RUP

– Дисципліни бізнес-моделювання. Бізнес-моделювання

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

і як використати це бачення для виділення процесу, ролей та обов'язків.

– Дисципліни вимог. Вимоги пояснюють, як виявити запити

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

осягають створювану систему й надають детальні вимоги до того, що

система повинна робити.

– Дисципліна аналізу та проектування. Метою аналізу і

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

створення системи, яка:

1) виконує задачі та функції описані в описах прецедентів;

2) виконує всі свої вимоги;

33

3) легко змінюється, коли змінюються функціональні

вимоги.

Проектування дає в результаті модель проектування, а аналіз

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

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

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

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

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

компонентами у реалізації. Він також містить опис того, як об'єкти цих

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

– Дисципліна реалізації. Метою реалізації є:

1) визначити організацію коду з точки зору реалізації

підсистем, які організовані в шари;

2) реалізація класів та об'єктів у термінах компонентів

(вихідних файлів, виконуваних файлів, та інших).

Системи реалізуються через реалізацію компонентів. Процес описує

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

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

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

– Дисципліна тестування. Цілі тестування:

1) перевірити взаємодії між об'єктами;

2) перевірити належну інтеграцію всіх компонентів

програмного забезпечення;

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

4) визначити та переконатись що дефекти будуть розглянуті

до розгортання програмного забезпечення;

5) переконатись, що всі дефекти виправлені, повторно

перевірені та закриті.

Раціональний уніфікований процес пропонує ітеративний підхід, а це

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

34

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

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

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

системи. Для кожного з цих вимірів критеріїв якості, процес описує як

пройти життєвий цикл планування, проектування, виконання і оцінки

тесту.

– Дисципліна розгортання. Метою розгортання є успішно робити

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

користувачів. Вона охоплює широке коло заходів, у тому числі

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

програмного забезпечення та бізнес-додатків, розповсюдження

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

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

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

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

до розгортання в кінці фази конструювання. Процеси розгортання та

середовища із RUP містять менше деталей, ніж інші робочі процеси.

Отже, на початковій фазі найголовнішими артефактами є:

– документ "Бачення проекту";

– модель прецедентів;

– додаткова специфікація;

– словник термінів;

– план ітерації;

– план на наступну ітерацію.

На фазі розвитку, головними артефактами є:

– модель предметної області;

– модель проектування;

– описання програмної архітектури;

– модель даних;

– модель тестування;

35

– модель реалізації;

– прототипи інтерфейсу користувача.

На фазах конструювання та передачі (впровадження), зазначені вище

артефакти доповнюються та дороблюються, також складаються декілька

специфічних для цих фаз документів, таких як "Звіт з альфа-тестування" та

"Звіт з бета-тестування". Головна робота виконується саме на стадії

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

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

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

меж [16, с. 159].

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

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

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

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

думку розробників артефактів.

Для демонстрації алгоритму вирішення задачі автоматизації

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

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

розвитку.

Модель прецедентів допомагає визначитись із варіантами

використання системи. Іншими словами, за допомогою цієї моделі, і

користувачу, і розробникам має стати зрозуміло, що має робити система.

Дана модель, як правило, складається із діаграми прецедентів, та їх

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

Як ми можемо бачити з наведеного рисунку, система

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

має виконувати десять основних дій:

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

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

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

36

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

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

автоматично заповнює необхідні документи перевіреними даними.

Створення документного набору

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

Додавання документу у документний набір

Управління документом у документному наборі

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

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

Конфігурування системи користувачем

Генерація набору документів

Система Patternius

Офісний працівник (користувач)

<<виконавець>>Система Microsoft Word

Запуск системи

Авторизація користувача

Рисунок 2.2 – Діаграма прецедентів

– створення документного набору. Документним набором є

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

інформації. Наприклад, для заповнення "Службової записки про

37

відрядження" та "Заяви про відрядження" в учбових закладах

використовується одна й та сама інформація. Для того, щоб не вводити

повторно ті самі дані, можна створити документній набір, додати в нього

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

основі введених даних.

Слід зазначити, що джерела інформації не мають бути обов'язково

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

приріст продуктивності при заповнені документів. Чим більша схожість

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

– управління документним набором. У даний прецедент входять

такі функції, як видалення документного набору, зміна його назви, зміна

шляху збереження згенерованих файлів, та ін.

– додавання документу у документний набір. Завдяки даному

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

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

генерувати одночасно.

– управління документом у документному наборі. У даний

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

набору, зміна його назви, та ін.

– додавання динамічного поля у документ. Динамічне поле – це

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

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

документів користувацькі шаблони.

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

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

позиції динамічного поля, зміна його назви, та ін.

– конфігурування системи користувачем. Користувач має мати

змогу налаштовувати певні аспекти роботи системи.

38

– авторизація користувача. Одним із варіантів використання

системи є авторизація користувача в ній. Даний прецедент є в основі

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

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

має бути виконана при запуску системи.

Ще одним корисним інструментом, який допомагає зрозуміти

алгоритм вирішення задачі автоматизації генерації документів на основі

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

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

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

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

побачити на рисунку 2.3. Даний тип діаграми не містить у собі програмних

класів.

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

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

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

об'єкти, які при невеликій мірі абстракції можуть ними стати. Вони не

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

що виконуються певним об'єктом зазначаються у назві зв'язку з іншими

об'єктами, також вказується напрямок читання зв'язку.

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

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

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

який складається із аутентифікації та самої авторизації користувача у

системі. Аутентифікація користувача – це процес розпізнання системою чи

може даний користувач виконати вхід. Авторизація користувача – це

процес видачі відповідних прав користувачу.

З діаграми, наведеної на рисунку 2.3, видно, що один користувач

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

чином з користувачем пов'язано багато об'єктів Login та Registration.

39

User

-DateTime-LoginName-Password-SecretQuestion-SecretAnswer

Registration

-Location-LoginCollection-RegisterCollection

UserDataStore

-DateTime-IsGood : bool-Id-LoginName-Password

Login

1

*

User-Starts-Registration4

*

1

User-Starts-Login4

*1

3 UserDataStore-Verifies-Login

*

1

3 UserDataStore-Saves-Registration

-SaveGenerationFile : bool = true-Name-FatherName-DateOfBirth-Status

UserPreferences

1

1

Registration-Contains-UserPreferences

-Date-Type-Success

HistoryRecord

1

1..*

UserDataStore-Creates-HistoryRecord4

Рисунок 2.3 – Діаграми концептуальних класів прецеденту "Авторизація

користувача"

Кожен об'єкт Registration містить у собі один об'єкт UserPreferences,

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

авторизації користувача об'єкти Login та Registration передаються деякому

одному об'єкту UserDataStore, який зберігає введені дані, та повертає

результат операції авторизації. Також, об'єкт UserDataStore створює один

або декілька об'єктів HistoryRecord, за допомогою яких відбувається

ведення історії запитів до програмного середовища.

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

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

40

програмної системи та не перевантажені технічною інформацією, що дає

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

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

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

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

процесів, призначена для формалізації і опису бізнес-процесів, яка

називається IDEF0 [18].

В основі даної методології лежать чотири основні поняття:

– функціональний блок;

– інтерфейсна дуга;

– декомпозиція;

– глосарій.

Першим є поняття функціонального блоку (Activity Box).

Функціональний блок графічно зображується у вигляді прямокутника і

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

За вимогами стандарту назва кожного функціонального блоку має бути

сформульовано в дієслівному способі (наприклад, "виробляти послуги", а

не "виробництво послуг").

Кожна з чотирьох сторін функціонального блоку має своє певне

значення (роль), при цьому:

– верхня сторона має значення "Управління" (Control);

– ліва сторона має значення "Вхід" (Input);

– права сторона має значення "Вихід" (Output);

– нижня сторона має значення "Механізм" (Mechanism).

Кожен функціональний блок у рамках єдиної розглянутої системи

повинен мати свій унікальний ідентифікаційний номер.

Другим ключовим поняттям методології IDEF0 є поняття

інтерфейсної дуги (Arrow). Також інтерфейсні дуги часто називають

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

41

який обробляється функціональним блоком або надає інший вплив на

функцію, відображену даними функціональним блоком.

Графічним відображенням інтерфейсної дуги є односпрямована

стрілка. Кожна інтерфейсна дуга повинна мати своє унікальне

найменування (Arrow Label). На вимогу стандарту, найменування повинне

бути іменником.

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

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

об'єктами можуть бути елементи реального світу (деталі, вагони,

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

інструкції тощо).

У залежності від того, до якої з сторін підходить дана інтерфейсна

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

"джерелом" (початком) і "приймачем" (кінцем) кожної функціональної

дуги можуть бути тільки функціональні блоки, при цьому "джерелом"

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

що залишилися.

Третім основним поняттям стандарту IDEF0 є декомпозиція

(Decomposition). Принцип декомпозиції застосовується при розбитті

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

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

Декомпозиція дозволяє поступово і структуровано представляти

модель системи у вигляді ієрархічної структури окремих діаграм, що

робить її менш перевантаженою й легко засвоюються.

Модель IDEF0 завжди починається з представлення системи як

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

що тягнуться за межі даної області. Така діаграма з одним функціональним

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

ідентифікатором "А-0".

42

Останнім з понять IDEF0 є глосарій (Glossary). Для кожного з

елементів IDEF0: діаграм, функціональних блоків, інтерфейсних дуг

існуючий стандарт передбачає створення та підтримку набору відповідних

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

об'єкт, відображений даним елементом. Цей набір називається глосарієм і є

описом суті цього елемента. Наприклад, для керуючої інтерфейсної дуги

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

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

гармонійно доповнює наочний графічний мову, забезпечуючи діаграми

необхідної додаткової інформацією.

Діаграми IDEF0 також будуються для кожного значущого

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

замовникам.

На наступному рисунку 2.4 зображено IDEF0 діаграму для основного

прецеденту "Генерація документного набору".

A0

А-1

Генерація документного набору

ЗАГОЛОВОК:УЗЕЛ: НОМЕР: 0А-0 Нульовий рівень декомпозиції.

Інформація для заповнення документів Згенеровані документи

Набір користувальницьких шаблонів

Користувач

1

А-1

Генерація документного набору

Пакет MS Word

Рисунок 2.4 – Нульовий рівень декомпозиції процесу "Генерація

документного набору"

43

Як бачимо з даної IDEF0 діаграми, у якості вхідної інформації для

процесу генерації документного набору виступає інформація для

заповнення документів, яку має ввести механізм – користувач. У якості

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

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

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

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

На рисунку 2.5 зображений перший рівень декомпозиції даного

складного процесу.

ЗАГОЛОВОК:УЗЕЛ: НОМЕР: 1А-1 Перший рівень декомпозиції. Генерація документного набору.

1

А-2

Заповнення джерела даних інформацією

2

Перевірка введених даних

3

А-3

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

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

документів

Заповнене джерело даних

Заповнене і перевіренеджерело даних

Користувач

Згенеровані документи

Пакет MS Word

Рисунок 2.5 – Перший рівень декомпозиції процесу "Генерація

документного набору"

Отже, процес генерації документного набору складається із трьох

основних дій: заповнення джерела даних інформацією, перевірка введених

даних, генерація відповідних документів. На кожному з цих етапів

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

інформація для заповнення документів, яку має ввести механізм –

44

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

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

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

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

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

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

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

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

врахування відмінків, множини чи однини слів, які були введені

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

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

документів та їх заповнення інформацією із заповненого і перевіреного

джерела даних, яке слугує вихідними змінними для другого блоку. На

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

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

на основі яких і створюються необхідні документи.

На рисунку 2.6 зображено другий рівень декомпозиції процесу

"Генерація документного набору". Детальному огляду підлягає дія

"Заповнення джерела даних інформацією".

На даній діаграмі дія "Заповнення джерела даних інформацією", яка

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

(рис. 2.5), розкладена на три дії.

На першому етапі відбувається просте введення інформації, яка

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

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

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

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

того, що користувачеві не потрібно багато раз вводити подібну

інформацію, яка використовується у різних відмінках, множині чи однині.

45

ЗАГОЛОВОК:УЗЕЛ: НОМЕР: 2А-2 Другий рівень декомпозиції. Заповнення джерела даних інформацією.

1

Введенення первинної інформації

2

Обробка первинної інформації

3

Формування джерела даних

Інформація для заповнення документів

Набір користувальницьких шаблонів

Користувач

Введена первиннаінформація

Оброблена первиннаінформація

Заповнене джерело даних

Рисунок 2.6 – Другий рівень декомпозиції процесу "Генерація

документного набору". Дія "Заповнення джерела даних інформацією"

На другому етапі відбувається обробка первинної інформації, яка

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

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

користувачем інформацію, щоб вона відповідала потрібним відмінкам,

множині чи однині.

На третьому етапі відбувається співставлення обробленої інформації

із назвами динамічних полів у кожному із документів у наборі. Таким

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

процесу "Генерація документного набору".

На рисунку 2.7 зображено дію "Генерація відповідних документів",

яка є третім блоком на першому рівні декомпозиції процесу "Генерація

документного набору" (рис. 2.5).

Дана дія, також, була декомпонована на три блоки. У першому блоці,

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

46

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

механізмом – пакет MS Word. На виході із даного блоку отримуються

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

динамічні поля у вигляді закладок.

На другому етапі відбувається заповнення даних динамічних полів

інформацією із заповненого і перевіреного джерела даних. У визначене

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

значення із джерела.

ЗАГОЛОВОК:УЗЕЛ: НОМЕР: 3А-3 Другий рівень декомпозиції. Генерація відповідних документів.

1

Створення документів із шаблонів

2

Заповнення динамічних полів

3

Збереження документів

Заповнене і перевіренеджерело даних

Набір користувальницьких шаблонів

Документи зістатичним текстом

Заповнені документи

Згенеровані документи

Пакет MS Word

Сигнал на створення документів

Рисунок 2.7 – Дія "Генерація відповідних документів"

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

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

атрибуті документного набору.

Ще одним корисним інструментом при проектуванні предметної

області є діаграми потоків даних, або діаграми Гайн-Сарона. DFD (Data

Flow Diagrams) – це методологія графічного структурного аналізу, яка

описує зовнішні по відношенню до системи джерела та адресати даних,

47

логічні функції, потоки даних та сховища даних, до яких здійснюється

запит [1].

Даний тип діаграм добре описує зміни даних у часі. На рисунку 2.8

зображено DFD-діаграму, яка декомпонована з другого блоку першого

рівня декомпозиції процесу "Генерація документного набору", який

називається "Перевірка введених даних".

Тимчасове сховище джерела інформації

Перевірка коректності трансформування інформації

Внесення змін у некоректні значення

Збереження змінених даних у джерелі

Користувач

Тимчасове сховище перевіреного джерела

інформації

Початкові дані

Некоректні значення

Зміни

Вказівки на некоректні значення

Виправлені значення

Початкові дані

Перевірене джерело інформації

Рисунок 2.8 – DFD-діаграма процесу "Перевірка введених даних"

На даній діаграмі немає функцій механізму та управління. Їх роль

виконують зовнішні сутності (Користувач) та сховища даних (Тимчасове

сховище джерела інформації, Тимчасове сховище перевіреного джерела

інформації).

48

Згідно з даними наведеної діаграми, процес перевірки введених

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

трансформовані з введеної ним інформації, відбувається за наступним

алгоритмом. Спочатку із тимчасового сховища джерела інформації

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

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

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

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

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

На етапі розвитку дуже важливу роль відіграють артефакти, що

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

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

Одним із найголовніших інструментів, при побудові моделі

проектування, є діаграми послідовностей. Діаграма послідовності – в

UML, відображає взаємодії об'єктів впорядкованих за часом. Зокрема, такі

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

повідомлень [19].

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

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

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

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

"Створення документного набору". Даний прецедент є простим з точки

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

системі.

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

програмного коду. Наприклад, дивлячись на наведену діаграму (рис. 2.9),

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

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

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

49

DocSetController

AddDocSet:=AddDocSet(DocSet)

:XMLDocSetDataStore

AddDocSet(DocSet)

DataStoreProvider

GetDocSetDataStore(loginName)

Create(LoginName)

IDocSetDataStore

Рисунок 2.9 – Діаграма послідовності для прецеденту "Створення

документного набору"

У даному класі викликається метод GetDocSetDataStore з параметром

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

DataStoreProvider, який використовується для створення об'єктів, що

взаємодіють з даними.

У класі DataStoreProvider викликається конструктор класу

XMLDocSetDataStore, який повертає об'єкт даного класу. Після цього у

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

інтерфейс IDocSetDataStore. Потім викликається метод отриманого

інтерфейсу AddDocSet із параметром DocSet, який виконується у

створеному екземплярі класу XMLDocSetDataStore (див. додаток Г).

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

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

послідовностей та діаграми програмних класів ефективно доповнюють

один одного, і, майже завжди, вони розглядаються разом [11]. На

50

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

прецеденту "Створення документного набору"

+AddDocSet(в DocSet) : bool

BLL.DocSets::DocSetController

+AddDocSet() : bool+DeleteDocSet()+UpdateDocSet()+GetDocSetById()+GetUserDocSets()+AddDocSet(в DocSet)+Create(в LoginName)

-LoginName-DocSetsPath

DAL.DocSets::XMLDocSetDataStore

IDocSetDataStore

-Name-Description-IsReady-Id

BLL::Document

-Id-Name-Description-Date-LastEditDate-SavePath

BLL.DocSets::DocSet

+AddHistoryRecord()

-HistoryPath-History

DAL::DataStoreBase

-User

BLL::ControllerBase

1

0..*

DocSet-Contains-Document

Рисунок 2.10 – Діаграма програмних класів для прецеденту "Створення

документного набору"

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

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

методами. Також, на даній діаграмі зображені зв'язки між даними класами.

За наведеної діаграми (рис. 2.10) можна побачити, що:

– клас DocSetController унаслідується від класу ControllerBase,

який містить приватний атрибут User;

– один екземпляр класу DocSet може містити нуль або декілька

екземплярів класу Document;

51

– клас XMLDocSetDataStore реалізує інтерфейс

IDocSetDataStore;

– клас XMLDocSetDataStore унаслідується від класу

DataStoreBase, у якого є два приватних атрибути та публічний метод

AddHistoryRecord;

– класи XMLDocSetDataStore, DocSet, та DocSetController

взаємодіють між собою під час виконання операції створення

документного набору.

Слід зазначити, що жорстке дотримання всіх нюансів даних діаграм

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

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

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

Отже, таким чином, виділивши основні варіанти використання

системи автоматизованої генерації документів на основі користувацьких

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

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

список артефактів, що були створені на початковому етапі та на етапі

розвитку, наведено у додатках.

2.3 Вибір архітектури та технології автоматизованої системи

Виходячи з наведених вимог до автоматизованої системи генерації

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

що у якості сховища даних мають використовуватися або SQL-сховища

даних без серверного варіанту, або файлові сховища даних типу XML-

сховищ.

Така ситуація має місце через те, що програмний додаток, що

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

52

задачі. Крім цього, даний програмний додаток орієнтований тільки на

кінцевого користувача без back-end додатку. Тому кінцевий продукт буде

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

серверна архітектура найчастіше є неприйнятною.

З огляду на вимоги щодо портативності, зручності розгортання та

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

версії програмного додатку, найкращим варіантом є використання

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

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

даних, їх частоту, та об'єми даних, що мають зберігатися.

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

користувача, документні набори кожного користувача, документи кожного

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

запитів. В середньому припускається, що даним програмним додатком

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

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

швидкої роботи. У документний набір користувач в середньому додає від

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

динамічних полів.

В результаті підрахунку, отримуємо, що, при середньому обрахунку,

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

записи історії.

Існують випадки, коли потреби користувача значно перевищують

середні показники. За результатами альфа-тестування, яке проводилося на

базі виробничої практики у "Херсонська регіональна філія Державне

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

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

врахування записів історії.

Проте, у будь-якому варіанті об'єм даних, що мають зберігатися у

сховищі не є критично великим для файлових XML-сховищ. Аналіз

53

навантаження потоків даних та їх частоти також свідчить про те, що

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

кращим варіантом буде вибір XML-сховища даних.

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

було обране інтегроване середовище розробки Microsoft Visual Studio 2010

Ultimate [6] та мова Visual C# 4.0 [7]. Microsoft Visual Studio – серія

продуктів фірми Майкрософт, які включають інтегроване середовище

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

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

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

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

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

Windows, Windows Mobile, Windows CE, .NET Framework, .NET Compact

Framework та Microsoft Silverlight.

У якості найкращої технології для доступу до даних було обрано

технологію Linq to XML. LINQ to XML – це оснащений засобами LINQ і

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

з XML-файлами всередині мов програмування. NET Framework.

LINQ to XML подібний моделі DOM в тому відношенні, що

завантажує XML-документ в пам'ять. До такого документу можна

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

файлі або серіалізувати і передати через Інтернет. Однак між інтерфейсом

LINQ to XML і моделлю DOM існують відмінності: інтерфейс реалізує

більш легку і просту в роботі модель об'єктів. Крім того, в ньому

використовуються переваги, реалізовані в Visual C # 2008 [3].

Найважливіша гідність LINQ to XML полягає в його інтеграції з

LINQ (Language-Integrated Query). Ця інтеграція дає можливість

створювати запити до завантаженому в пам'ять XML-документу з метою

отримання колекцій елементів і атрибутів. За своєю функціональністю (але

не по синтаксису) реалізовані в LINQ to XML можливості формування

54

запитів порівнянні з можливостями XPath та XQuery. Завдяки інтеграції

LINQ в Visual C # 2008 забезпечується більш сувора типізація, перевірка

під час компіляції і покращена підтримка відладчика.

На наступному рисунку (рис. 2.11) зображено скільки

функціональних можливостей поєднує у собі технологія Linq to XML, яка

реалізована у бібліотеці System.Linq.Xml.dll, яка вбудована у .NET

Framework 4.0.

Рисунок 2.11 – Функціональні можливості технології Linq to XML

Таким чином, у якості архітектурного стилю розгортання була

обрана безсерверна однорівнева архітектура, а у якості технології доступу

до даних – Linq to XML. Такий тип архітектури найкраще задовольняє

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

середнього розміру.

У якості архітектурного стилю структури додатку була обрана

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

функціональні шари користувацького інтерфейсу, рівня бізнес-логіки, та

рівня доступу до даних. Такий тип архітектури дозволить краще

55

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

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

2.4 Програмне та апаратне забезпечення

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

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

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

даного програмного продукту підібрана саме таким чином, щоб найкраще

забезпечити вимоги щодо зручного розгортання та впровадження при

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

Таким чином, єдиною важливою умовою для роботи даного

програмного додатку є наявність встановленої платформи .NET Framework

4.0 та текстового процесору MS Word, який входить у пакет Microsoft

Office 2003 чи вище.

Платформа .NET Framework 4.0 має необхідний функціонал для

роботи із даними. У разі відсутності даної платформи на робочій станції

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

основі користувацьких шаблонів запропонує встановити її.

Microsoft Word (повна назва Microsoft Office Word) – текстовий

процесор, що випускається фірмою Майкрософт, входить до складу

офісного пакету «Microsoft Office». Microsoft Word є найбільш популярним

з використовуваних в даний момент текстових процесорів, що зробило

його бінарний формат документа стандартом де-факто, і багато

конкуруючі програми мають підтримку сумісності з даним форматом [8].

Оскільки головним форматом електронної документації є саме

формат .doc та .docx, то й кінцевий програмний продукт націлений на

роботу саме з цими форматами. Саме тому наявність текстового процесору

56

MS Word версії 2003 чи вище на робочій станції користувача є

обов'язковою.

Інші вимоги до програмного та апаратного забезпечення наведені у

таблиці 2.1. Загалом, вимоги щодо програмного та апаратного

забезпечення є дуже малими, що є перевагою даного програмного

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

Таблиця 2.1 – Системні вимоги для коректної роботи із

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

шаблонів

Назва Параметри

Процесор 500 МГц чи вище

ОЗУ – RAM 256 MB

Дисковий простір 10 МБ

Монітор 1024 х 768 чи вище

Операційна система

Windows XP, Windows Vista,

Windows 7, Windows Server 2003 R2,

Windows Server 2008

57

РОЗДІЛ 3 РЕАЛІЗАЦІЯ ПРОТОТИПУ АВТОМАТИЗОВАНОЇ СИСТЕМИ

ГЕНЕРАЦІЇ ДОКУМЕНТІВ НА ОСНОВІ КОРИСТУВАЦЬКИХ

ШАБЛОНІВ

3.1 Структура та особливості реалізації інформаційного

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

шаблонів

Інформаційне забезпечення автоматизованої системи генерації

документів на основі користувацьких шаблонів в значній мірі визначає

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

здійснює інформаційний обмін всередині і зовні системи і формується

відповідно сформованих, у першому розділі, вимог.

Як зазначалось у другому розділі, у якості сховища даних було

обрано файлове XML-сховище, як найбільш прийнятне для програмного

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

специфікацію XML-структури сховища даних у табличному вигляді.

Для коректного функціонування підсистеми авторизації, створюється

файл usersstore.pts у папці /Users/ даного програмного додатку. Даний

XML-файл містить інформацію для авторизації користувачів, які

користуються системою. Для швидкості обробки інформації вся додаткова

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

персональній теці користувача. Структура файлу usersstore.pts наведена у

таблиці 3.1.

Під час реєстрації нового користувача у файл usersstore.pts додається

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

/Users/. У даній папці містяться файл історії запитів даного користувача та

файл з додатковими персональними даними. Дана модель розподілення

інформації по окремим файлам дає необхідну гнучкість під час розробки

системи.

58

Таблиця 3.1 – Структура файлу usersstore.pts

№ Назва

елементу

Короткий

опис

Батьківський

елемент

Атрибути

Назва Опис Формат

даних

А Б В Г Ґ Д Е

1 Usersstore кореневий

елемент

– – – –

2 User певний

користувач

системи

Usersstore LoginName логін string

Password пароль encoded

string

SecurityQuestion секретне

питання

string

SecurityAnswer секретна

відповідь

encoded

string

IsCurrent ідентифікатор

поточності

bool

Структура файлу history.pts, який розташовується у папці

/Users/<Ім'я користувача>/ наведена у таблиці 3.2.

Таблиця 3.2 – Структура файлу history.pts

№ Назва

елементу

Короткий

опис

Батьківський

елемент

Атрибути

Назва Опис Формат

даних

А Б В Г Ґ Д Е

1 UserHistory кореневий

елемент

– – – –

2 Record log-запис

події

UserHistory Type тип події string

Date дата події datetime

IsSuccess результат bool

AddInfo додаткова

інформація

string

У даний файл вноситься інформація про діяльність певного

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

59

набору, нового шаблону, генерація набору документів, та ін. У разі

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

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

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

інформацію про помилки системи. Також, дана система ведення історії

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

корисним у певних випадках.

У файлі /Users/<Ім'я користувача>/preferences.pts міститься

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

у таблиці 3.3.

Таблиця 3.3 – Структура файлу preferences.pts

№ Назва елементу Короткий опис Батьківський

елемент

Атрибути

Назва Опис Формат

даних

А Б В Г Ґ Д Е

1 UserPreferences кореневий елемент – – – –

2 Name ім'я UserPreferences – – –

3 FatherName по-батькові UserPreferences – – –

4 DateOfBirth дата народження UserPreferences – – –

5 SaveGenerationFile чи потрібно

зберігати файл

генерації документів

UserPreferences – – –

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

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

системи та масштабування персональних налаштувань користувача. У разі

розміщення даної інформації у файлі /Users/usersstore.pts, можна спростити

схему сховища даних, але втратити швидкість входу користувача у

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

великим. Саме через не остаточну визначеність у кількості персональної

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

60

що для кращої масштабованості та гнучкості у даному питанні,

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

користувача.

Дані щодо документних наборів користувача містяться у його

власній папці за адресою /Common/<Ім'я користувача>/ у файлі

docsetsstore.pts. Структура даного файлу наведена у таблиці 3.4.

Таблиця 3.4 – Структура файлу docsetsstore.pts

№ Назва

елементу

Короткий

опис

Батьківський

елемент

Атрибути

Назва Опис Формат

даних

А Б В Г Ґ Д Е

1 DocSets кореневий

елемент

– – – –

2 DocSet набір

документів

DocSets Id ідентиф. int

Name назва string

SavePath шлях до папки

збер. за замовч.

string

Date дата створення datetime

LastEditDate дата ост.

редагування

datetime

Description опис string

3 BaseValue базове

значення

DocSet Id ідентиф. int

Name назва string

Date дата створення datetime

LastEditDate дата ост.

редагування

datetime

У даному документі міститься необхідна інформація для роботи із

документними наборами користувача У атрибутах елементу DocSet

міститься інформація про сам документний набір, а у його дочірніх

елементах BaseValue міститься інформація про необхідні для заповнення

даного документного набору дані. Тобто кожний запис BaseValue вказує,

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

61

значення. Дані значення використовуються для формування

неперевіреного джерела інформації при генерації документного набору.

Більш детальна інформація про даний процес наведена у підрозділі 2.2

даної випускної роботи.

Інформація про самі документи, що входять у документний набір,

міститься у файлі /Common/<Ім'я користувача>/ <Id набору>/

documentsstore.pts. Структура даного файлу наведена у таблиці 3.5.

Таблиця 3.5 – Структура файлу documentsstore.pts

№ Назва

елементу

Короткий

опис

Батьківський

елемент

Атрибути

Назва Опис Формат

даних

А Б В Г Ґ Д Е

1 Documents кореневий

елемент

– – – –

2 Document документ Documents Id ідентиф. int

Name назва string

Date дата створення datetime

LastEditDate дата ост.

редагування

datetime

Description опис string

IsReady чи готовий для

генерації

bool

3 DynamicField динамічне

поле

документу

Document Id ідентиф. int

Name назва string

BaseValueId ідент. баз. знач. int

BookmarkName назва закладки

у .doc файлі

string

Case відмінок string

IsPlural чи множина bool

Для кожного документу у документному наборі створюється

відповідний запис. У якості дочірніх елементів документу виступають

елементи, так звані, динамічні поля. Кожне динамічне поле відповідає за

62

одну закладку у файлі шаблону (.doc, .docx), та зберігає певну інформацію

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

відмінку та числі. Інформація у динамічних полях кожного документа

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

при заповнені безпосередньо документів на основі шаблону.

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

папці /Common/<Ім'я користувача>/ <Id набору>/Documents/. Назва файлу

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

Document у файлі documentsstore.pts.

Отже, файлове сховище може мати вигляд подібний до наведеного

на рисунку 3.1.

Рисунок 3.1 – Структура дерева файлів та каталогів системи

Таким чином, було розроблене сховище даних на основі XML-

файлів. Звісно, що для коректної роботи такого сховища необхідно було

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

та цілісності даних. Цілісність збережених даних контролюється із коду

додатку. При зовнішній зміні даних (не за допомогою даного програмного

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

потребують синхронізації.

63

Додавання значень у файли сховища відбувається за допомогою

технології Linq to XML, яка є частиною .NET Framework 4.0. Функція

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

Лістинг 3.1 – Функція додавання запису про новий документний

набір у файл сховища.

/// <summary> /// Добавляет документный набор в файл docsetsstore.pts /// </summary> /// <param name="ds">Необходимый документных набор.</param> /// <returns></returns> public bool AddDocSet(DocSet ds) { bool ret = true; string addInfo = ""; XDocument docSets = DocSets; //Проверяет есть ли документный набор с таким именем. IEnumerable<XElement> docSetWithSameName = docSets.Root.Elements("DocSet").Where(t => t.Attribute("Name").Value == ds.Name); if (docSetWithSameName.Count() > 0) { //Уже есть такой док. набор. ret = false; addInfo = "Помилка. Вже існує документний набір з таким ім'ям."; } else { //Имя не занято. //Вычисление айди нового док. набора. int maxId = 0; if (docSets.Root.HasElements) { maxId = docSets.Root.Elements("DocSet").Max(t => int.Parse(t.Attribute("Id").Value)); } //Создание и добавление набора в XML файл. var newDocSet = new XElement("DocSet", new XAttribute("Id", maxId + 1), new XAttribute("Name", ds.Name), new XAttribute("SavePath", ds.SavePath), new XAttribute("Description", ds.Description), new XAttribute("Date", ds.Date.ToString("g")), new XAttribute("LastEditDate", ds.LastEditDate.ToString("g"))); docSets.Root.Add(newDocSet); docSets.Save(_docSetsPath); } //Запись транзакции в журнал истории пользователя. AddHistoryRecord("newdocset", ds.Date, ret, addInfo); return ret; }

64

Використання технології Linq to XML дає змогу швидко та зручно

маніпулювати даними у форматі XML. У наведеному вище фрагменті коду

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

самим ім'ям, якщо такого не знайдено – виконується запис у файл сховища.

Після цього вноситься інформація у журнал трансакцій користувача.

Таким чином було сформовано інформаційне забезпечення

автоматизованої системи генерації документів на основі користувацьких

шаблонів та розроблено структуру сховища даних.

3.2 Проектування інтерфейсу користувача

Одним із головних видів діяльності при розробці програмного

забезпечення є розробка інтерфейсу користувача. Автоматизована система

генерації документів орієнтована на широке коло користувачів. Тобто,

відповідно інтерфейс користувача має бути простим та доступним навіть

для людини без спеціальних знань у даній сфері.

Слід зазначити, що дана версія програмного продукту поки що є

прототипом системи автоматизації генерації документів на основі

користувацьких шаблонів. Проте, даний прототип вдало пройшов альфа-

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

регіональна філія Державне підприємство "Центр державного земельного

кадастру".

Отже стартове вікно програми перед входом користувача у систему

має вигляд, зображений на рисунку 3.2. У даному діалоговому вікні

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

персональних даних.

65

Рисунок 3.2 – Стартове вікно програми перед входом користувача

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

програми зі списком документних наборів користувача (рис. 3.3). У

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

користувача.

Рисунок 3.3 – Головне вікно програми

66

Два рази натиснувши на потрібному документному наборі,

користувач побачить інформацію про даний набір та список його

документів (рис. 3.4).

Рисунок 3.4 – Деталі документного набору

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

документному наборі, користувач може два рази клацнути мишкою по

потрібному документу (рис. 3.5).

У лівій частині даного вікна наводиться список всіх документів

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

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

кількості закладок у файлі *.doc, тому для того, щоб документ став

готовим для генерації, потрібно всім його динамічним полям співставити

певне базове значення документного набору. У разі відсутності потрібного

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

"Додати б. значення" (рис. 3.6).

67

Рисунок 3.5 – Вікно деталей документа

Рисунок 3.6 – Додавання нового базового значення до документного

набору

Отже, співставивши всі динамічні поля всіх документів у

документному наборі, користувач може почати генерацію документів. Слід

68

зауважити, що дане "конфігурування" документного набору достатньо

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

зображений на рисунку 3.7.

Рисунок 3.7 – Вікно заповнення базових значень при генерації набору

документів

У даному вікні (рис. 3.7) користувачу необхідно внести лише

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

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

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

продивитись отримані результати трансформації та внеси в них зміни

(рис. 3.8).

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

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

введених базових значень. Згенеровані документи будуть збережені за

шляхом, який був вказаний на попередньому етапі (рис. 3.7). За

замовчуванням цей шлях зберігається у налаштуваннях документного

набору. Отримані документи зображені на рисунку 3.9.

69

Рисунок 3.8 – Перевірка трансформованих значень

Рисунок 3.9 – Отримані файли у результаті генерації

Процедури додавання нового документного набору та документу

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

додавання документного набору необхідно вказати його назву, короткий

опис та шлях до збереження файлів (рис. 3.10).

Для додавання нового документу (шаблону) у документний набір

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

У даному діалоговому вікні користувачу потрібно обрати файл із

розширенням .doc або .docx. Система автоматично підрахує яка кількість

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

кнопку "Додати", і документ буде доданий до набору.

70

Рисунок 3.10 – Додавання нового документного набору

Рисунок 3.11 – Додавання нового документу до набору

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

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

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

основі користувацьких шаблонів.

На рисунку 3.12 зображена панель інструментів з коротким описом

кожної команди.

71

Рисунок 3.12 – Панель інструментів

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

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

Використання простих і зрозумілих форм в елементах

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

зручності. Дана версія інтерфейсу знаходиться на стадії доробки, проте по

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

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

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

системи

Використання автоматизованої системи генерації документів на

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

дуже розповсюджену проблему. Основна користь даної автоматизованої

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

та заповнення документації.

72

Оскільки розроблений прототип системи успішно пройшов альфа

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

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

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

у "Херсонська регіональна філія Державне підприємство "Центр

державного земельного кадастру", було виявлено, що на складання однієї

технічної документації для однієї земельної ділянки, за наявності всіх

необхідних даних, інженер, коли його ніхто не відволікає, витрачає від

п'ятдесяти хвилин до однієї години та двадцяти п'яти хвилин. Якщо додати

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

ін., то в результаті отримуємо, що один інженер заповнює технічну

документацію на земельну ділянку близько двох з половиною годин.

Оскільки складання технічної документації на земельну ділянку є

роботою періодично повторювальною та обов'язковою для кожної

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

прототипу, що й було зроблено.

Створення документного набору, який містить у собі всі необхідні

вісімнадцять документів (шаблонів документів) з налаштованими

динамічними полями, зайняло одну годину та десять хвилин. Слід

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

набору є одноразовим, і його не потрібно повторювати знову.

Інженер, користуючись створеним документним набором, має ввести

22 базових значення, що займає близько шести з половиною хвилин. Ще

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

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

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

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

сумарно 182 динамічних поля.

Таким чином, час необхідний для заповнення даної технічної

документації зменшився з 80 хвилин (150 хвилин у реальних умовах

73

робочого процесу) до дев'яти з половиною хвилин. Таким чином

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

заповнення документації у 8,42 рази (у 16 разів). Більш наочно результати

підрахунку ефективності наведені у таблиці 3.6.

Таблиця 3.6 – Порівняння ручного та автоматизованого заповнення

технічної документації на земельну ділянку інженером

№ Етап генерації Середній час ручного

способу роботи, хв.

Середній час автоматизованого

способу роботи, хв.

1 Виникнення

необхідності у створенні

документації

– –

2 Пошук та відкриття

потрібного шаблону

2 0,3

3 Заповнення документів

інформацією

67 6,5

4 Перевірка введених

значень

8 2

5 Збереження документів 2,5 1

Загалом 79,5 9,8

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

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

Конкурентів та програм прямих аналогів на ринку виявлено не було, а

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

середньостатистичну людину.

Витрати на розробку даної автоматизованої системи складаються з

таких видів витрат:

– витрати на заробітну плату програмістам;

– витрати на ліцензійне програмне забезпечення;

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

додатку.

74

Витрати на заробітну плату програмістів обраховуються за

формулою:

∑ , (3.1)

де kN – кількість розробників k-ї професії, чол;

kr – годинна зарплата розробника k-ї професії, грн.;

kT – трудомісткість розробки для k-го розробника (кількість

витраченого розробником часу), год.;

Kзар = 1,3685– коефіцієнт нарахувань на фонд заробітної плати, долі.

Приймаємо 1kN . Годинна зарплата розробника визначається по

формулі:

, (3.2)

де kM – місячна зарплата k-го розробника, грн.;

Fkміс

– місячний фонд часу його роботи, год.

Приймаємо місячну зарплату програміста по Сумській області рівну

3000 грн. Кількість робочих днів на рік – 251 день. Кількість робочих

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

Отже, місячний фонд часу роботи програміста складає:

Тоді, годинна зарплата розробника складає:

75

Трудомісткість розробки даної автоматизованої системи складає 22

робочих днів, або 176 год. Таким чином отримуємо значення витрат на

заробітну плату програмістів рівну:

∑

Витрати на ліцензійне програмне забезпечення та підтримку системи

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

дорівнювати нулю. Дана ситуація стає можливою через те, що планується

участь даної автоматизованої системи у програмі стартапів Microsoft

BizSpark.

Таким чином витрати на розробку програмного додатку рівні

витратам на зарплату розробникам і складають 4325,77 грн. На даний

момент часу було знайдено 30 потенційних клієнтів, які хоті б мати

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

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

Закругливши вартість одного екземпляру до 150 грн. отримаємо

ціну, по якій варто розпочати продаж програмного додатку. Дана ціна є

прийнятною для середньостатистичної людини. Економічний ефект, який

буде отриманий від користування автоматизованою системою генерації

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

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

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

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

76

досягається зменшення часу необхідного для заповнення одного документа

у 6,5 разів (на 85%).

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

працівника, який отримує заробітну плату у розмірі 1500 грн./міс. та

працює в середньому 167 годин на місяць. Таким чином вартість години

роботи такої людини складає 9 грн.

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

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

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

, (3.3)

де ЕЧ – економія часу від використання системи, год.;

ВД – вартість програмного додатку, грн.;

rk – годинна заробітна плата працівника.

Отже, економія часу має скласти:

Для того, щоб зекономити такий час, людина повинна витратити

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

, (3.4)

де СЧ – сумарний час, який працівник має затратити на генерацію

документації, год.;

kв – коефіцієнт вивільнення часу при використанні автоматизованої

системи.

77

Сумарний час дорівнює:

Отже, якщо сумарний час заповнення вручну періодично

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

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

індивіда. Як швидко у людини настає етап, коли додаток себе вже окупив,

залежить від того, на скільки часто виникає необхідність у заповнені

періодично повторювальної документації. В середньому працівник

витрачає 20 хвилин на день на заповнення періодично повторювальної

документації.

Таким чином можна розрахувати через яку кількість робочих днів

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

де КД – кількість робочих днів необхідних для того, щоб економічна

вигода від користування системою перевищить витрати на неї, днів;

Чген – середній час, який працівник витрачає на генерацію

періодично повторювальної документації, год.

Крім цього, економлячи свій час працівник може його витрачати на

основну свою діяльність і підвищувати доходи підприємства. Якщо взяти

за норму, що кожен працівник витрачає 20 хвилин на день на генерацію

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

витрачається 7 годин робочого часу, або 4%. Використовуючи

автоматизовану систему можна зменшити цей час до 0,6% від робочого

часу на місяць. При цьому вивільняється 3,4% робочого часу одного

працівника.

78

Якщо коефіцієнт продуктивності одного працівника рівний 2, то це

означає, що підприємство від його праці отримує в середньому дохід від

його праці у 2 рази більше ніж витрати на неї. При вивільнені 3,4%

робочого часу працівника його коефіцієнт продуктивності становитиме

2,068, що дасть підприємству приріст доходу на рівні 6,8% з одного

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

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

використанні ним автоматизованої системи документогенерації на основі

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

79

ВИСНОВКИ

Генерація документів – процес створення документації та заповнення

її інформацією. Цей процес є масовим по своїй природі, адже всі

господарські дії потрібно супроводжувати відповідними документами.

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

притаманний всім офісним працівникам, як генерація та заповнення

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

документації, які використовуються на сучасних підприємствах. До таких

форм документації належать: звіти, заяви, накази, акти, укази, і т.д. З

розвитком суспільства та ІТ-технологій постійно покращувались засоби

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

потрібно було вести. Зараз майже весь процес документогенерації

відбувається у електронній формі.

Генерація документів на основі шаблонів відбувається у п'ять етапів:

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

– відкриття/створення потрібного шаблону;

– заповнення документа інформацією;

– перевірка правильності заповнення;

– збереження документа.

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

заповнені одразу декількох взаємопов'язаних документів. Як правило,

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

своєму оформленні.

Особливістю даної галузі досліджень є те, що з генерацією

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

кожній фірмі будь-якого типу та форми власності потрібно створювати та

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

80

що дає перспективи автоматизації даного процесу, деякі – одноразово, і

автоматизовувати даний вид діяльності не має сенсу.

Аналіз стану автоматизації у сфері генерації документів на основі

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

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

документів. Даний функціонал дозволяє пройти весь процес

документогенерації значно швидше та пропустити деякі етапи взагалі. Дані

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

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

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

інформації з бази даних, шаблони автоматично нею заповнюються, та

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

друком.

Проте не всі спеціалізовані інформаційні та виробничі системи

вбудований функціонал з генерації та автоматичного заповнення певних

документів звітності. Крім цього, не на всіх підприємствах дані системи

використовуються через їх високу вартість, або недоцільність. Також слід

враховувати той факт, що є багато видів документації, які не входять у

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

потребують автоматизації, через високі трудо- та часовитрати на своє

заповнення.

Дана тенденція у сфері генерації документів ще раз підтверджує

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

основі користувацьких шаблонів.

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

автоматизована система генерації документів на основі користувацьких

шаблонів. Всі вимоги наводились згідно класифікації FURPS.

Досліджено нормативно-правову базу України на предмет

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

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

81

описуються у Законі України "Про електронні документи та електронний

документообіг", прийнятому у травні 2003 року.

Виходячи із сформованих вимог до автоматизованої системи

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

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

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

діаграм, а також за допомогою діаграм прецедентів та програмних класів.

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

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

зворотному зв'язку з кінцевим користувачем.

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

архітектуру без back-end додатку. Кращим типом сховища даних стало

файлове XML-сховище, через вимоги щодо портативності, зручності

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

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

Для повноцінного функціонування автоматизованої системи на

кінцевій робочій станції користувача необхідна лише наявність

встановленної .NET Framework 4.0, яка є безкоштовною, та текстового

процесору Microsoft Word версії 2003 чи вище, що вже використовується у

більшості підприємств на території України.

Розроблено зручний та інтуїтивний інтерфейс системи, що

забезпечує потреби користувачів у інформації щодо генерації документів

на основі користувацьких шаблонів.

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

Розраховано, що розробка і використання програмного продукту є

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

складає 85%. Термін окупності капіталовкладень в автоматизовану

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

Вирахувано, що термін окупності даної системи складає в середньому 59

робочих днів.

82

ПЕРЕЛІК ВИКОРИСТАНИХ ДЖЕРЕЛ

1. Data flow diagram – Wikipedia [Електронний ресурс] / Режим

доступу: http://en.wikipedia.org/wiki/Data_flow_diagram. – Заголовок з

екрану.

2. FURPS – Wikipedia [Електронний ресурс] / Режим доступу:

http://en.wikipedia.org/wiki/FURPS. – Заголовок з екрану.

3. LINQ to XML [Електронний ресурс] / Режим доступу:

http://msdn.microsoft.com/en-us/library/bb387098.aspx. – Заголовок з екрану.

4. Megapolis.Документообіг - InBase [Електронний ресурс] /

Режим доступу: http://inbase.com.ua/uk/products/workflow-system/docflow. –

Заголовок з екрану.

5. Rational Unified Process – Вікіпедія [Електронний ресурс] /

Режим доступу: http://uk.wikipedia.org/wiki/Rational_Unified_Process. –

Заголовок з екрану.

6. Visual Studio Home | Microsoft Visual Studio [Електронний

ресурс] / Режим доступу: http://www.microsoft.com/visualstudio/en-us. –

Заголовок з екрану.

7. Visual C# [Електронний ресурс] / Режим доступу:

http://msdn.microsoft.com/en-us/vstudio/hh388566.aspx. – Заголовок з екрану.

8. Word 2010 - Document and Word Processing Software

[Електронний ресурс] / Режим доступу: http://office.microsoft.com/en-

us/word. – Заголовок з екрану.

9. Ватсон Б. C# 4.0 на примерах. / Б. Ватсон [пер. з англ.] – П. :

БХВ-Петербург, 2011. – 608 с.

10. Використання шаблонів і стилів при оформленні документів

[Електронний ресурс] / Режим доступу: http://1715.us/Glava%207/

Index12.htm. – Заголовок з екрану.

11. Діаграма класів – Вікіпедія [Електронний ресурс] / Режим

доступу: http://uk.wikipedia.org/wiki/Діаграма_класів. – Заголовок з екрану.

83

12. Діаграма послідовності – Вікіпедія [Електронний ресурс] /

Режим доступу: http://uk.wikipedia.org/wiki/Діаграма_послідовності. –

Заголовок з екрану.

13. Документообіг – Вікіпедія [Електронний ресурс] / Режим

доступу: http://uk.wikipedia.org/wiki/Документообіг. – Заголовок з екрану.

14. Електронний документ – Вікіпедія [Електронний ресурс] /

Режим доступу: http://uk.wikipedia.org/wiki/Електронний_документ. –

Заголовок з екрану.

15. Електронний документообіг – Вікіпедія [Електронний ресурс] /

Режим доступу: http://uk.wikipedia.org/wiki/Електронний_документообіг. –

Заголовок з екрану.

16. Ларман К. Применение UML и шаблонов проектирования. 2-е

издание. / К. Ларман. [пер. з англ.] – М. : Видавничий дім "Віл'ямс", 2004. –

624 с.

17. Нейгел К., Ивьен Б., Глинн Д., Уотсон К., Скиннер М. C# 4.0 и

платформа .NET 4 для профессионалов / К. Нейгел, Б. Ивьен, Д. Глинн,

К. Уотсон, М. Скиннер [пер. з англ.] – М. : Видавничий дім "Віл'ямс", 2011.

– 1440 с.

18. Опис стандарту IDEF0 | ЕasyСode [Електронний ресурс] /

Режим доступу: http://easy-code.com.ua/2011/03/opis-standartu-idef0. –

Заголовок з екрану.

19. Про електронні документи та електронний документообіг;

Закон від 22.05.2003 № 851-IV [Електронний ресурс] / Режим доступу:

http://zakon2.rada.gov.ua/laws/show/851-15. – Заголовок з екрану.

20. Про пріоритетні напрями розвитку науки і техніки

[Електронний ресурс] / Режим доступу:

http://zakon2.rada.gov.ua/laws/show/2623-14. – Заголовок з екрану.

21. Райзберг Б.А., Лозовский Л.Ш., Стародубцева Е.Б..

Современный экономический словарь. — 2-е изд., испр. / Б.А. Райзберг,

Л.Ш. Лозовский, Е.Б. Стародубцева – М. : ИНФРА-М, 1999. – 479 с.

84

22. Система автоматизації документообігу – Вікіпедія

[Електронний ресурс] / Режим доступу:

http://uk.wikipedia.org/wiki/Система_ автоматизації_документообігу. –

Заголовок з екрану.

23. Угода між Україною та Європейським Співтовариством про

наукове і технологічне співробітництво [Електронний ресурс] / Режим

доступу: http://zakon2.rada.gov.ua/laws/show/994_194. – Заголовок з екрану.

24. Центр ДЗК [Електронний ресурс] / Режим доступу:

http://dzk.gov.ua/index.php?option=com_content&view=article&id=53&Itemid

=62. – Заголовок з екрану.

85

ДОДАТКИ

Додаток А – Перший варіант документу "Бачення проекту"

Видение проекта Система автоматизированной документогенерации «Patternius»

Версия Дат

а

Описание Автор

Первый

черновой вариант

16.0

1.12

Начало разработки

системы, приблизительное

видение

Акименко

Владимир Игоревич

Введение

Нам видеться надёжное и удобное приложение для быстрой

генерации документов с большим объемом статического текста и

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

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

заполнения.

Позиционирование

Экономические предпосылки

На данный момент не существует решений-аналогов, позволяющих

быстро и удобно заполнять сразу несколько документов с большим

содержанием статического текста и динамическими полями. Это является

неплохой предпосылкой для продолжения исследования данной области.

Формулировка проблемы

Для формулировки проблемы, лучше всего воспользоваться

примером. Предположим, что ежедневная отчетность работника

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

документов (Заказ, Общая информация, Выполнение, Условия). Во всех

86

этих документах используются данные о ФИО клиента, его адресе,

телефоне, и номере паспорта. В документах много статического

(постоянного) текста, а нужные для изменения поля сильно «разбросаны»

по тексту.

Стоит заметить, что в пакет могут входить гораздо большее

количество документов, и количество нужных полей также может

отличаться. Дабы облегчить задачу работника при составлении подобных

пакетов документации, и обойтись без излишней траты времени на

копирование и поиск нужных полей для вставки, нужна система, в которой

данная проблема решается оптимальным способом.

Место системы

Данная система предназначается для всех заинтересованных лиц,

имеющих подобного рода проблему (описанную в пункте «Формулировка

проблемы»). Главным свойством такой системы должна стать широкая

поддержка различных шаблонов документации, а также возможность

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

Заинтересованные лица

Пользователи системы

Офисные работники, частные лица.

Другие заинтересованные лица

Компании и фирмы, в которых работники используют данную

систему, поскольку это экономит их время и оптимизирует работу.

Задачи высокого уровня

‒ Необходимо оптимизировать работу пользователей при составлении

документаций, отчетов, актов, и других наборов документов.

Необходимо обеспечить быструю и удобную генерацию и

заполнение наборов документов с большим количеством

статического текста и динамическими вставками.

‒ Необходимо максимально уменьшить количество рутинной работы.

87

Задачи уровня пользователя

Дописать после прецедентов

Обзор

Перспективы

Данное приложение может стать единственным в своём роде

«автоматизатором» генерации и заполнения многодокументных

документаций на основе пользовательского ввода. Это открывает широкие

перспективы для продвижения данной системы на рынок и

распространения её как коробочного продукта.

Преимущества системы

Свойство системы Преимущества для

заинтересованных лиц

Автоматизированное заполнение

документных наборов

Оптимизация затрат времени при

рутинном заполнении документов.

Возможность импорта/экспорта

документных наборов

Облегчение передачи информации

между заинтересованными лицами.

Возможность сохранения/загрузки

заполнения документных наборов

Облегчение заполнения наборов

документов.

Будет реализована система

авторизации пользователей в системе

Персонализация всех данных и их

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

возможность конфигурирования работы

системы «под себя».

Возможность создания

пользовательских документных наборов

Гибкое подстраивание под

потребности конкретного пользователя.

Цены

Уточнить приблизительную стоимость. Пока 150 грн.

Основные свойства системы

‒ Генерация и заполнение документных наборов, основываясь на

пользовательском вводе.

88

‒ Авторизация пользователей при работе с системой.

‒ Возможность экспорта/импорта документных наборов.

‒ Возможность сохранения/загрузки состояния документного набора в

процессе работы.

‒ Возможность создания пользовательских документных наборов для

генерации и заполнения.

‒ Удобство и простота использования.

Другие требования и ограничения

‒ Данная система обязана работать с документами в самом

распространённом формате – формате MS Word (*.doc, *.docx).

‒ Больше внимания следует уделить именно удобству использования

данной системы (дружественный интерфейс, высокое качество

справки)

89

Додаток Б – Документ "Додаткова специфікація" у першій редакції

Дополнительная спецификация Система автоматизированной документогенерации «Patternius»

Версия Дат

а

Описание Автор

Первый

черновой вариант

18.0

1.12

Начало разработки

системы

Акименко

Владимир Игоревич

Введение.

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

Patternius, не вошедшие в описание прецедентов.

Функциональность.

Регистрация событий и обработка ошибок.

Все события системной важности и ошибки должны

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

разработчику для их анализа.

Подключаемые бизнес-правила.

В системе не предусмотрены подключаемые бизнес-правила, но

должна быть возможность небольшой корректировки существующих

бизнес-правил.

Безопасность.

Все важные данные каждого пользователя должны быть защищены

криптографическими методами.

Удобство использования.

Человеческие факторы.

90

Главным условием для системы является её «интуитивная

понятность» для пользователя. Данное условие должно выполняться за

счет дружественного юзабильного интерфейса пользователя, и

качественной справки.

Все шаги должны быть снабжены полезными подсказками, чтобы

пользователь не сомневался в правильности своих действий.

Надёжность.

Возможность восстановления информации.

Нужно обеспечить возможность восстановления системы после

различного рода сбоев. Нужно добиться работоспособности системы в 95%

случаев выполнения сценариев.

Производительность.

В связи с небольшим количеством информации в системе в

подавляющем большинстве случаев, скорость выполнения операций

должна быть гарантированно высокой. При генерации набора документов,

производительность в основном зависит от производительности ПК

пользователя и производительности системы MS Word.

Возможность поддержки.

Адаптация системы.

Пользователь должен иметь возможность конфигурировать

некоторые аспекты функционирования системы на своё усмотрение.

Конфигурирование.

Этот вопрос требует дополнительного изучения аспектов гибкости

системы.

Ограничения.

‒ На пользовательском ПК должна быть установлена система MS

Word и платформа .NET Framework 4.

91

‒ Скорее всего, в качестве хранилища данных будут использованы

файлы на постоянном носителе клиентского ПК (XML-формат).

Приобретаемые компоненты. Нет.

Бесплатные компоненты. В целом предполагается использование

бесплатных компонентов для разработки ПО на платформе Windows

корпорации Microsoft.

Интерфейсы.

Важные аппаратные интерфейсы.

Стандартные аппаратные средства ПК.

Программные интерфейсы.

Для взаимодействия с системой MS Word, предполагается

использование встроенных в .NET Framework 4 интерфейсов.

Бизнес-правила.

Имя Правило Возм. измен. Источник

ПРАВ1 Генерация

документов в

формате MS Word

крайне редко принципы

работы системы

MS Word

ПРАВ2 Генерация на

основе

пользовательского

ввода

никогда принципы

формирования

пользовательских

документов

92

Додаток В – Приклад опису прецеденту "Генерація документного

набору"

Прецедент П1. Генерация набора документов.

Основной исполнитель. Офисный работник (пользователь

системы).

Заинтересованные лица и их требования.

‒ Офисный работник (пользователь системы).

1. Хочет быстро ввести значения динамических полей и получить

на основании его ввода набор из n документов, в которых в

нужном месте расположены нужные значения (динамических

полей).

2. Хочет иметь возможность вернуться к заполнению (вводу)

значений динамических полей, а также иметь возможность

сохранять/загружать значения динамических полей для

данного документного набора.

3. Хочет иметь возможность выбора места, куда будут

сохраняться сгенерированные документы.

4. Хочет получить отчет о сгенерированном наборе.

‒ Система MS Word.

1. Требует четкой передачи всех необходимых данных для

создания, заполнения, и сохранения всех необходимых

документов документного набора.

Предусловия. Пользователь авторизирован, у него есть минимум

один документный набор с минимум одним документом.

Постусловия. Получено n документов в формате .doc или .docx (по

выбору пользователя), в определённом пользователем месте на носителе

(жд., флэш, и т.д.) Значения динамических полей для данного

документного набора сохранены для возможности их восстановления без

повторного ввода.

Основной успешный сценарий.

93

1. Пользователь выбирает необходимый документный набор для

генерации.

2. Пользователь вводит все необходимые значения для заполнения всех

динамических полей во всех документах выбранного документного

набора.

3. Пользователь выбирает необходимый путь для сохранения

сгенерированных документов.

4. Система запускает пакет MS Word.

5. Системе MS Word сообщается, какие документы следует открыть, и

чем заполнить их динамические поля.

6. MS Word открывает необходимые документы. и заполняет

динамические поля в соответствии с передаваемой информацией.

7. Система MS Word сохраняет документы по указанному имени, и

закрывает их.

8. Система сохраняет значения, введённые пользователем для данного

документного набора во временное хранилище и в файл по

указанному пути.

9. Система информирует пользователя об успешной генерации и

предоставляет отчет.

Расширения.

*а. При каждом сбое.

1. Система информирует пользователя о возможной причине сбоя, и

рекомендует пути решения данной проблемы.

2. Пользователь выполняет необходимые требования.

3. Пользователь повторно пытается сгенерировать набор документов.

*б. При сохранении значений.

1. Пользователь вводит имя для набора сохраняемых значений для

данного документного набора.

2. Пользователь выбирает путь для сохранения.

3. Системе сохраняет значения полей для данного документного в

специальный файл, под указанным именем по указанному пути, для

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

2а. Загрузка ранее сохранённых значений полей.

1. Пользователь выбирает сохранённую копию значений для

динамических полей

94

2. Система автоматически заполняет все подходящие значения.

1-3а. Отказ пользователя.

1. Система просит подтвердить пользователя своё решение.

1а. Пользователь подтверждает своё желание прекратить процесс

заполнения значений динамических полей.

a. Система восстанавливает своё предыдущее состояние.

1б. Пользователь не подтверждает своего желания.

a. Система продолжает работу в текущем состоянии.

Специальные требования.

‒ Весь процесс заполнения и генерации должен быть максимально

понятным и удобным пользователю.

‒ В 95% случаев нужно добиться положительного результата

генерации набора документов.

‒ При возможных сбоях не должны пострадать никакие данные

пользователя.

‒ На ПК пользователя должна быть инсталлирована система Microsoft

Office версии 2003 и выше, и, в частности, система MS Word.

Список технологий.

‒ Весь процесс происходит при использовании стандартных

аппаратных средств ПК (клавиатура, мышь, монитор, и т.д.)

Частота использования. Очень часто.

Открытые вопросы.

‒ Придумать максимально доступный и удобный интерфейс системы.

‒ Изучить принципы взаимодействия программных систем с

документами MS Word.

95

Додаток Г – Код класів рівня взаємодії з даними

Лістинг Г.1 – Код класу XMLDocSetDataStore, який відповідає за

обробку даних наборів документів

using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.IO; using System.Xml.Linq; using PatterniusV3.BLL.DocSetLogic; using System.Collections.ObjectModel; namespace PatterniusV3.DAL.DocSetStore { public class XMLDocSetDataStore:DataStoreBase, IDocSetDataStore { #region PrivateFields private string _loginName = ""; private string _docSetsPath = ""; private string LoginName { get { return _loginName; } set { _loginName = value; _historyPath = string.Format("{0}/{1}/{2}/{3}", Directory.GetCurrentDirectory(), "Users", LoginName, "history.pts"); _docSetsPath = string.Format("{0}/{1}/{2}/{3}", Directory.GetCurrentDirectory(), "Common", LoginName, "docsetsstore.pts"); if (!Directory.Exists(Path.GetDirectoryName(_docSetsPath))) { Directory.CreateDirectory(Path.GetDirectoryName(_docSetsPath)); } } } private XDocument _docSets; private XDocument DocSets { get { if (File.Exists(_docSetsPath)) { _docSets = XDocument.Load(_docSetsPath); } else { _docSets = new XDocument(new XElement("DocSets")); _docSets.Save(_docSetsPath); } return _docSets; } } #endregion #region Constructors

96

Продовження лістингу Г.1:

public XMLDocSetDataStore(string loginName) { //При инициализации свойства LoginName, происходит заполнение всех необходимых путей к файлам и папкам. LoginName = loginName; } #endregion #region InterfaceMethods /// <summary> /// Добавляет документный набор в файл docsetsstore.pts /// </summary> /// <param name="ds">Необходимый документных набор.</param> /// <returns></returns> public bool AddDocSet(DocSet ds) { bool ret = true; XDocument docSets = DocSets; //Проверяет есть ли документный набор с таким именем. IEnumerable<XElement> docSetWithSameName = docSets.Root.Elements("DocSet").Where(t => t.Attribute("Name").Value == ds.Name); if (docSetWithSameName.Count() > 0) { //Уже есть такой док. набор. ret = false; } else { //Имя не занято. //Вычисление айди нового док. набора. int maxId = 0; if (docSets.Root.HasElements) { maxId = docSets.Root.Elements("DocSet").Max(t => int.Parse(t.Attribute("Id").Value)); } //Создание и добавление набора в XML файл. var newDocSet = new XElement("DocSet", new XAttribute("Id", maxId + 1), new XAttribute("Name", ds.Name), new XAttribute("SavePath", ds.SavePath), new XAttribute("Description", ds.Description), new XAttribute("Date", ds.Date.ToString("g")), new XAttribute("LastEditDate", ds.LastEditDate.ToString("g"))); docSets.Root.Add(newDocSet); docSets.Save(_docSetsPath); } //Запись транзакции в журнал истории пользователя. AddHistoryRecord("newdocset", ds.Date, ret); return ret; } public bool DeleteDocSet(DocSet ds) { throw new NotImplementedException(); } /// <summary>

97

Продовження лістингу Г.1:

/// Обновляет док. набор новыми данными. /// </summary> /// <param name="ds"></param> /// <returns></returns> public bool UpdateDocSet(DocSet ds) { bool ret = true; XDocument docSets = DocSets; //Проверка на наличия док. набора с таким же именем, но другим айди. IEnumerable<XElement> docSetWithSameName = docSets.Root.Elements("DocSet").Where(t => t.Attribute("Name").Value == ds.Name && ds.Id.ToString() != t.Attribute("Id").Value); if (docSetWithSameName.Count() > 0) { //Имя занято. ret = false; } else { //Получение старого документного набора из хранилища. XElement updatableDocSet = docSets.Root.Elements("DocSet").Single(t => t.Attribute("Id").Value == ds.Id.ToString()); string dirPath = Path.GetDirectoryName(_docSetsPath); //Меняем имя папки. Directory.Move(string.Concat(dirPath, "/", updatableDocSet.Attribute("Name").Value), string.Concat(dirPath, "/", ds.Name)); if (updatableDocSet.HasAttributes) { //Изменение параметров. updatableDocSet.Attribute("Name").Value = ds.Name; updatableDocSet.Attribute("Description").Value = ds.Description; updatableDocSet.Attribute("LastEditDate").Value = ds.LastEditDate.ToString("g"); updatableDocSet.Attribute("SavePath").Value = ds.SavePath; docSets.Save(_docSetsPath); } } //Фиксация транзакции в журнале пользователя. AddHistoryRecord("updatedocset", ds.LastEditDate, ret); return ret; } /// <summary> /// Извлекает из системы хранилища все док. наборы пользователя. /// </summary> /// <returns></returns> public ObservableCollection<DocSet> GetUserDocSets() { var ret = new ObservableCollection<DocSet>(); IEnumerable<XElement> docSetsElements = DocSets.Root.Elements("DocSet"); foreach (XElement xEl in docSetsElements) { ret.Add(new DocSet() { Id = int.Parse(xEl.Attribute("Id").Value), Name = xEl.Attribute("Name").Value,

98

Продовження лістингу Г.1:

SavePath = xEl.Attribute("SavePath").Value, Description = xEl.Attribute("Description").Value, Date = DateTime.Parse(xEl.Attribute("Date").Value), LastEditDate = DateTime.Parse(xEl.Attribute("LastEditDate").Value) }); } return ret; } /// <summary> /// Извлекает из системы хранилища документный набор с заданным айди. /// </summary> /// <param name="id"></param> /// <returns></returns> public DocSet GetDocSetById(int id) { var ret = new DocSet(); XElement docSetElement = DocSets.Root.Elements("DocSet").Single(t => t.Attribute("Id").Value == id.ToString()); if (docSetElement.HasAttributes) { //Заполняем простые свойства документного набора. ret.Id = id; ret.Name = docSetElement.Attribute("Name").Value; ret.Description = docSetElement.Attribute("Description").Value; ret.Date = DateTime.Parse(docSetElement.Attribute("Date").Value); ret.SavePath = docSetElement.Attribute("SavePath").Value; ret.LastEditDate = DateTime.Parse(docSetElement.Attribute("LastEditDate").Value); //Заполняем коллекцию его базовых значений. if (docSetElement.HasElements) { //ret.BaseValues = new ObservableCollection<BaseValue>(); foreach (XElement item in docSetElement.Elements("BaseValue")) { ret.BaseValues.Add(new BaseValue() { Id = int.Parse(item.Attribute("Id").Value), Name = item.Attribute("Name").Value, Description = item.Attribute("Description").Value, Date = DateTime.Parse(item.Attribute("Date").Value), LastEditDate = DateTime.Parse(item.Attribute("LastEditDate").Value) }); } } } return ret; } public bool AddBaseValue(int docSetId, BaseValue bv) { bool ret = true; XDocument docSets = DocSets; XElement currDocSet = docSets.Root.Elements("DocSet").Single(t => t.Attribute("Id").Value == docSetId.ToString());

99

Продовження лістингу Г.1:

if (currDocSet.HasAttributes) { //Получение айди. int maxId = 0; if (currDocSet.HasElements) { maxId = currDocSet.Elements("BaseValue").Max(t => int.Parse(t.Attribute("Id").Value)); } var newBaseValue = new XElement("BaseValue", new XAttribute("Id", maxId + 1), new XAttribute("Name", bv.Name), new XAttribute("Description", bv.Description), new XAttribute("Date", bv.Date.ToString("g")), new XAttribute("LastEditDate", bv.LastEditDate.ToString("g"))); currDocSet.Add(newBaseValue); docSets.Save(_docSetsPath); } else { ret = false; } AddHistoryRecord("addbasevalue", bv.Date, ret); return ret; } public bool UpdateBaseValue(int docSetId, BaseValue bv) { bool ret = true; XDocument docSets = DocSets; XElement currDocSet = docSets.Root.Elements("DocSet").Single(t => t.Attribute("Id").Value == docSetId.ToString()); if (currDocSet.HasAttributes) { //Проверка на наличие базового значения с таким же именем. IEnumerable<XElement> sameName = currDocSet.Elements("BaseValue").Where(t => t.Attribute("Name").Value == bv.Name && t.Attribute("Id").Value != bv.Id.ToString()); if (sameName.Count() > 0) { ret = false; } else { //Выбор нужного базового занчения. XElement currBaseValue = currDocSet.Elements("BaseValue").Single(t => t.Attribute("Id").Value == bv.Id.ToString()); currBaseValue.Attribute("Name").Value = bv.Name; currBaseValue.Attribute("Description").Value = bv.Description; currBaseValue.Attribute("LastEditDate").Value = bv.LastEditDate.ToString("g"); docSets.Save(_docSetsPath); } } else { ret = false;

100

Продовження лістингу Г.1:

} AddHistoryRecord("updatebasevalue", bv.LastEditDate, ret); return ret; } #endregion } }

Лістинг Г.2 – Код класу XMLDocumentDataStore, який відповідає за

обробку даних документів

using System; using System.Collections.Generic; using System.Linq; using System.Text; using PatterniusV3.BLL.DocumentLogic; using System.Xml.Linq; using System.IO; using System.Collections.ObjectModel; namespace PatterniusV3.DAL.DocumentStore { public class XMLDocumentDataStore:DataStoreBase, IDocumentDataStore { #region PrivateFields private string _documentsPath = ""; private string _docSetName = ""; private string _loginName = ""; private string _phisicalDocsPath = ""; private XDocument _documents; #endregion #region Attributes private string LoginName { get {return _loginName;} set { _loginName = value; _historyPath = string.Format("{0}/{1}/{2}/{3}", Directory.GetCurrentDirectory(), "Users", _loginName, "history.pts"); _documentsPath = string.Format("{0}/{1}/{2}/{3}/{4}", Directory.GetCurrentDirectory(), "Common", _loginName, _docSetName, "documentsstore.pts"); _phisicalDocsPath = string.Format("{0}/{1}/{2}/{3}/{4}/", Directory.GetCurrentDirectory(), "Common", _loginName, _docSetName, "Documents"); if (!Directory.Exists(Path.GetDirectoryName(_documentsPath))) { Directory.CreateDirectory(Path.GetDirectoryName(_documentsPath)); if (!Directory.Exists(_phisicalDocsPath)) { Directory.CreateDirectory(_phisicalDocsPath); } } } }

101

Продовження лістингу Г.2:

private XDocument DocumentsStore { get { if (!File.Exists(_documentsPath)) { _documents = new XDocument(new XElement("Documents")); _documents.Save(_documentsPath); } else { _documents = XDocument.Load(_documentsPath); } return _documents; } } #endregion #region Constructors public XMLDocumentDataStore(string loginName, string docSetName) { _docSetName = docSetName; LoginName = loginName; } #endregion #region InterfaceMethods public bool AddDocument(DocumentDetails doc) { bool ret = true; XDocument docs = DocumentsStore; //Проверка на наличие документов с таким именем. IEnumerable<XElement> sameName = docs.Root.Elements("Document").Where(t => t.Attribute("Name").Value == doc.Name); if (sameName.Count() > 0) { ret = false; } else { //Копируем файл. Дописать трай File.Copy(doc.StartPath, string.Concat(_phisicalDocsPath, doc.Name), true); //Определяем нужный айди. int maxId = 0; if (docs.Root.HasElements) { maxId = docs.Root.Elements("Document").Max(t => int.Parse(t.Attribute("Id").Value)); } //Можно добавлять. var newElement = new XElement("Document", new XAttribute("Id", maxId + 1), new XAttribute("Name", doc.Name), new XAttribute("Description", doc.Description), new XAttribute("Date", doc.Date.ToString("g")), new XAttribute("LastEditDate", doc.LastEditDate.ToString("g")), new XAttribute("IsReady", doc.IsReady)); docs.Root.Add(newElement);

102

Продовження лістингу Г.2:

docs.Save(_documentsPath); } //Записываем в историю. AddHistoryRecord("adddocument", doc.Date, ret); return ret; } public bool UpdateDocument(DocumentDetails doc) { bool ret = true; XDocument docs = DocumentsStore; //Проверка на наличие документа с тем же именем. IEnumerable<XElement> sameName = docs.Root.Elements("Document").Where(t => t.Attribute("Name").Value == doc.Name && t.Attribute("Id").Value != doc.Id.ToString()); if (sameName.Count() > 0) { ret = false; } else { //Можно изменять. XElement neededElem = docs.Root.Elements("Document").Single(t => t.Attribute("Id").Value == doc.Id.ToString()); //Переименовываем файл. File.Move(string.Concat(_phisicalDocsPath, neededElem.Attribute("Name").Value), string.Concat(_phisicalDocsPath, doc.Name)); if (neededElem.HasAttributes) { neededElem.Attribute("Name").Value = doc.Name; neededElem.Attribute("Description").Value = doc.Description; neededElem.Attribute("LastEditDate").Value = doc.LastEditDate.ToString("g"); docs.Save(_documentsPath); } } //Добавим запись в историю. AddHistoryRecord("updatedocumet", doc.LastEditDate, ret); return ret; } public bool DeleteDocument(int docId) { throw new NotImplementedException(); } /// <summary> /// Получает список всех документов документного набора. /// </summary> /// <returns></returns> public ObservableCollection<DocumentDetails> GetDocuments() { var ret = new ObservableCollection<DocumentDetails>(); XDocument docs = DocumentsStore; IEnumerable<XElement> currDocs = docs.Root.Elements("Document");

103

Продовження лістингу Г.2:

if (currDocs.Count() > 0) { foreach (XElement doc in currDocs) { ret.Add(new DocumentDetails() { Id = int.Parse(doc.Attribute("Id").Value), Name = doc.Attribute("Name").Value, Description = doc.Attribute("Description").Value, Date = DateTime.Parse(doc.Attribute("Date").Value), LastEditDate = DateTime.Parse(doc.Attribute("LastEditDate").Value), IsReady = bool.Parse(doc.Attribute("IsReady").Value) }); } } return ret; } /// <summary> /// Получает нужный документ со всеми заполненными полями. /// </summary> /// <param name="docId">Айди нужного документа.</param> /// <returns></returns> public DocumentDetails GetDocumentById(int docId) { var ret = new DocumentDetails(); XDocument docs = DocumentsStore; //Получаем нужный документик. XElement currDoc = docs.Root.Elements("Document").Single(t => t.Attribute("Id").Value == docId.ToString()); if (currDoc.HasAttributes) { //Если у него есть атрибуты. Т.е. если он найден - заполняем объект Document. ret.Id = docId; ret.Name = currDoc.Attribute("Name").Value; ret.LastEditDate = DateTime.Parse(currDoc.Attribute("LastEditDate").Value); ret.Date = DateTime.Parse(currDoc.Attribute("Date").Value); ret.IsReady = bool.Parse(currDoc.Attribute("IsReady").Value); ret.Description = currDoc.Attribute("Description").Value; if (currDoc.HasElements) { //Если у него есть динамические поля - заполняем их коллекцию. ret.DynamicFields = new ObservableCollection<DynamicField>(); foreach (XElement item in currDoc.Elements("DynamicField")) { ret.DynamicFields.Add(new DynamicField() { Id = int.Parse(item.Attribute("Id").Value), Name = item.Attribute("Name").Value, BaseValueId = int.Parse(item.Attribute("BaseValueId").Value), BookmarkName = item.Attribute("BookmarkName").Value, Case = (CaseVariant)Enum.Parse(typeof(CaseVariant), item.Attribute("Case").Value) }); }

104

Продовження лістингу Г.2:

} } return ret; } /// <summary> /// Получает нужное динамическое поле нужного документа. /// </summary> /// <param name="docId">Айди документа.</param> /// <param name="dynFieldId">Айди динамического поля.</param> /// <returns></returns> public DynamicField GetDynamicFieldById(int docId, int dynFieldId) { var ret = new DynamicField(); XDocument docs = DocumentsStore; //Получаем нужный документик. XElement currDoc = docs.Root.Elements("Document").Single(t => t.Attribute("Id").Value == docId.ToString()); if (currDoc.HasElements) { //Если получили документ. Всё ОК, и у него на самом деле есть дин. поля. XElement currDynamicField = currDoc.Elements("DynamicField").Single(t => t.Attribute("Id").Value == dynFieldId.ToString()); if (currDynamicField.HasAttributes) { //Если нужное дин. поле найдено, и у него есть атрибуты. ret.Id = int.Parse(currDynamicField.Attribute("Id").Value); ret.Name = currDynamicField.Attribute("Name").Value; ret.BaseValueId = int.Parse(currDynamicField.Attribute("BaseValueId").Value); ret.BookmarkName = currDynamicField.Attribute("BookmarkName").Value; ret.Case = (CaseVariant)Enum.Parse(typeof(CaseVariant), currDynamicField.Attribute("Case").Value); } } return ret; } public bool AddDynamicField(int docId, DynamicField dynField) { bool ret = true; //Получаем нужный документ. XDocument docs = DocumentsStore; XElement currDocument = docs.Root.Elements("Document").Single(t => t.Attribute("Id").Value == docId.ToString()); if (currDocument.HasAttributes) { //Проверка на наличие дин. поля с таким именем. IEnumerable<XElement> sameName = currDocument.Elements("DynamicField").Where(t => t.Attribute("Name").Value == dynField.Name); if (sameName.Count() > 0) { ret = false; }

105

Продовження лістингу Г.2:

else { //Определяем айди. int maxId = 0; if (currDocument.HasElements) { maxId = currDocument.Elements("DynamicField").Max(t => int.Parse(t.Attribute("Id").Value)); } //Создаем новое дин. поле для записи в XML var newDynField = new XElement("DynamicField", new XAttribute("Id", maxId + 1), new XAttribute("Name", dynField.Name), new XAttribute("BaseValueId", dynField.BaseValueId), new XAttribute("BookmarkName", dynField.BookmarkName), new XAttribute("Case", dynField.Case.ToString())); currDocument.Add(newDynField); docs.Save(_documentsPath); } } AddHistoryRecord("adddynamicfieldToDoc_" + docId.ToString(), DateTime.Now, ret); return ret; } public bool UpdateDynamicField(int docId, DynamicField dynField) { bool ret = true; //Получаем нужный документ. XDocument docs = DocumentsStore; XElement currDocument = docs.Root.Elements("Document").Single(t => t.Attribute("Id").Value == docId.ToString()); if (currDocument.HasAttributes) { //Проверка на наличие дин. поля с таким именем и другим айди. IEnumerable<XElement> sameName = currDocument.Elements("DynamicField").Where(t => t.Attribute("Name").Value == dynField.Name && t.Attribute("Id").Value != dynField.Id.ToString()); if (sameName.Count() > 0) { ret = false; } else { //Извлекаем нужную запись. XElement currDynField = currDocument.Elements("DynamicField").Single(t => t.Attribute("Id").Value == dynField.Id.ToString()); //Меняем данные дин. поля. currDynField.Attribute("Name").Value = dynField.Name; currDynField.Attribute("BookmarkName").Value = dynField.BookmarkName; currDynField.Attribute("BaseValueId").Value = dynField.BaseValueId.ToString(); currDynField.Attribute("Case").Value = dynField.Case.ToString(); docs.Save(_documentsPath);

106

Продовження лістингу Г.2:

} } AddHistoryRecord("updatedynamicfieldToDoc_" + docId.ToString(), DateTime.Now, ret); return ret; } public bool DeleteDynamicField(int docId, int dynFieldId) { bool ret = true; //Получаем нужный документ. XDocument docs = DocumentsStore; XElement currDocument = docs.Root.Elements("Document").Single(t => t.Attribute("Id").Value == docId.ToString()); if (currDocument.HasElements) { //Извлекаем нужную запись. XElement currDynField = currDocument.Elements("DynamicField").Single(t => t.Attribute("Id").Value == dynFieldId.ToString()); //Удаляем запись. currDynField.Remove(); docs.Save(_documentsPath); } AddHistoryRecord("deletedynamicfieldFromDoc_" + docId.ToString(), DateTime.Now, ret); return ret; } public string GetLoadPath(string name) { return string.Concat(_phisicalDocsPath, name); } #endregion } }

107

Додаток Ґ – Код класів рівня бізнес-логіки

Лістинг Ґ.1 – Код класу DocumentController, який відповідає за

взаємодію об'єктів документів із об'єктами доступу до даних

using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Collections.ObjectModel; using PatterniusV3.DAL; namespace PatterniusV3.BLL.DocumentLogic { public class DocumentController:ControllerBase { public static bool AddDocument(DocumentDetails doc) { bool ret; doc.Date = DateTime.Now; doc.LastEditDate = DateTime.Now; ret = DataStoreProvider.GetDocumentDataStore(User.LoginName, CurrentDocSet.Name).AddDocument(doc); if (ret) { CurrentDocSet.Documents = GetDocuments(); } return ret; } public static bool UpdateDocument(DocumentDetails doc) { bool ret; doc.LastEditDate = DateTime.Now; ret = DataStoreProvider.GetDocumentDataStore(User.LoginName, CurrentDocSet.Name).UpdateDocument(doc); if (ret) { CurrentDocSet.Documents = GetDocuments(); } return ret; } //public bool DeleteDocument(); public static ObservableCollection<DocumentDetails> GetDocuments() { return DataStoreProvider.GetDocumentDataStore(User.LoginName, CurrentDocSet.Name).GetDocuments(); } //public ObservableCollection<DynamicField> GetDynamicFields(); public static DocumentDetails GetDocumentById(int docId) { CurrentDocument = DataStoreProvider.GetDocumentDataStore(User.LoginName, CurrentDocSet.Name).GetDocumentById(docId); return CurrentDocument; }

108

Продовження лістингу Ґ.1:

public static DynamicField GetDynamicFieldById(int dynFieldId) { return CurrentDocument.DynamicFields.Single(t => t.Id == dynFieldId); } public static DynamicField GetDynamicFieldById(int dynFieldId, bool needOverload) { var ret = new DynamicField(); if (needOverload) { ret = DataStoreProvider.GetDocumentDataStore(User.LoginName, CurrentDocSet.Name).GetDynamicFieldById(CurrentDocument.Id, dynFieldId); } else { ret = CurrentDocument.DynamicFields.Single(t => t.Id == dynFieldId); } return ret; } public static bool AddDynamicField(DynamicField dynField) { var provider = DataStoreProvider.GetDocumentDataStore(User.LoginName, CurrentDocSet.Name); bool ret = provider.AddDynamicField(CurrentDocument.Id, dynField); if (ret) { CurrentDocument.DynamicFields = provider.GetDocumentById(CurrentDocument.Id).DynamicFields; } return ret; } public static bool UpdateDynamicField(DynamicField dynField) { var provider = DataStoreProvider.GetDocumentDataStore(User.LoginName, CurrentDocSet.Name); bool ret = provider.UpdateDynamicField(CurrentDocument.Id, dynField); if (ret) { CurrentDocument.DynamicFields = provider.GetDocumentById(CurrentDocument.Id).DynamicFields; } return ret; } public static bool DleteDynamicField(int dynFieldId) { var provider = DataStoreProvider.GetDocumentDataStore(User.LoginName, CurrentDocSet.Name); bool ret = provider.DeleteDynamicField(CurrentDocument.Id, dynFieldId); if (ret) { CurrentDocument.DynamicFields = provider.GetDocumentById(CurrentDocument.Id).DynamicFields; }

109

Продовження лістингу Ґ.1:

return ret; } public static string GetLoadPath() { return DataStoreProvider.GetDocumentDataStore(User.LoginName, CurrentDocSet.Name).GetLoadPath(CurrentDocument.Name); } } }