Модуль учета

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

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

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

 

 

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

Розглянемо  основні принципи структурного підходу. У основу функціонально-модульного підходу встановлений принцип алгоритмічної декомпозиції, відповідно до якого проводиться поділ функцій ІС на модулі по функціональній приналежності, коли кожен модуль системи реалізує один з етапів загального процесу. Традиційний функціонально-модульний підхід до проектування ІС передбачає суворо послідовний порядок дій (так звана «модель водоспаду»). На думку Страуструпа, головний недолік моделі «водоспаду» полягає в однонаправленості інформаційних потоків. Якщо проблема виявляється «внизу за течією», то часто виникає сильний організаційний і методичний натиск з метою проводити лише обмежені виправлення і вирішити проблему без дії на попередні стадії проекту. Такий недостатній зворотний зв'язок приводить до проектування, збиткового у багатьох відношеннях, а обмежені виправлення ведуть до деформованих реалізацій. Зміна вимог до системи може привести до  її цілковитому перепроектуванню, тому помилки, закладені на ранніх етапах, сильно позначаються на часі і кінцевій ціні розробки. Орієнтація на модель «водоспаду» збільшує вірогідність того, що буде втрачений контроль над розв'язанням виникаючих проблем.

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

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

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

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

                 абстрагування;

                інкапсуляція;

                 модульна;

                 ієрархія;

                 типізація;

                 паралелізм;

                 стійкість.

Основними поняттями  об'єктно-орієнтованого підходу  є об'єкт і клас.

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

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

Більшість існуючих методів об'єктно-орієнтованого  підходу включає мову моделювання  і опис процесу моделювання. Процес - це опис кроків, які необхідно виконати при розробці проекту. Як мова моделювання об'єктного підходу використовується уніфікована мова моделювання UML, яка містить стандартний набір діаграм для моделювання.

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

Об'єктно-орієнтований підхід володіє наступними перевагам:

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

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

Порівняння  існуючих методик

У функціональних моделях (DFD-діаграмах потоків даних, SADT-діаграмах) головними структурними компонентами є функції (операції, дії, роботи), які  на діаграмах зв'язуються між собою потоками об'єктів.

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

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

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

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

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

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

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

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

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

Як можна  бачити з представленого огляду, кожна  з розглянутих методик дозволяє вирішити задачу побудови формального опису робочих процедур досліджуваної системи. Всі методики дозволяють побудувати модель «як є» (AS-IS) і «як повинно бути» (TO-BE). З другого боку, кожна з цих методик володіє істотними недоліками. Їх можна підсумовувати таким чином: недоліки застосування окремої методики лежать не у області опису реальних процесів, а в неповноті методичного підходу.

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

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

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

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

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

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

При побудові адміністративних регламентів виділяються  наступні стадії:

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

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

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

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