logo search
Інформаційні управляючі системи та технології / Metod_rekomendacii_MDR

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

В залежності від того, як на практиці реалізуються два перші етапи життєвого циклу (ЖЦ ІУС), тобто аналіз вимог і проектування, прийнято розрізняти наступні підходи індустріального автоматизованого проектування ІУС: структурно-орієнтований, об’єктно-орієнтований, процесно-орієнтований та агентно-орієнтований.

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

Вибравши цей підхід до створення ІУС, магістрант повинен враховувати те, що для таких методів характерним є:

1) розбиття на рівні абстракції з обмеженням кількості елементів на кожному з рівнів (як правило, від 3 до 7, при цьому верхня межа відповідає можливостям людського мозку сприймати певну кількість взаємопов’язаних об’єктів, а нижня вибрана з міркувань здорового глузду);

2) обмежений контекст, що включає лише істотні на кожному рівні деталі;

3) використання жорстких формальних правил запису;

4) послідовне наближення до кінцевого результату.

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

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

1) DFD (Data Flow Diagrams) — діаграми потоків даних (ДПД) спільно зі словниками даних і специфікаціями процесів (міні-специфікаціями);

2) ERD (Entity—Relationship Diagrams) — діаграми «суть—зв’язок»;

3) STD (State Transition Diagrams) — діаграми переходів станів.

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

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

2) модуль має ім’я, за яким до нього можна звертатися як до єдиного фрагмента;

3) модуль може приймати і/або передавати дані як параметри у певній послідовності чи зв’язувати дані через фіксовані осередки або загальні області.

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

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

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

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

1.3.3.2. Об’єктно-орієнтований підхід. Суть об’єктно-орієнтованої методології зводиться до об’єктної декомпозиції предметної області, що подається у вигляді сукупності об’єктів, які взаємодіють між собою за допомогою передачі повідомлень. Даний підхід не є протиставленням структурному підходу, більше того, фрагменти методологій структурного аналізу (а саме його базові моделі: DFD, ЕRD і SТD) використовуються під час об’єктно-орієнтованого аналізу для моделювання структури і поведінки самих об’єктів.

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

Здійснюючи об’єктну декомпозицію, магістранту необхідно враховувати, що об’єкти і класи повинні організовуватися за такими принципами:

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

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

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

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

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

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

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

На етапі проектування магістрант може використати такі діаграми:

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

  2. діаграми модулів і діаграми процесів, що моделюють конкретні програмні і апаратні компоненти, є частиною статичної фізичної моделі;

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

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

Обравши цей підхід до створення ІУС, магістрант повинен виконати наступні дії:

1) розгляyти існуючу систему управління економічним об’єктом - виявити витратні центри та cформувати моделі: структурні, функціональні (процесні), моделі даних, а також комплексні (моделі класу “AS-IS” (тобто «як є»)), скориставшись для цього наприклад, побудовою діаграм бізнес-процесів (IDEF0), діаграм потоків процесів (IDEF3) та діаграм потоків даних (DFD);

2) побудувати моделі “TO-BE” (тобто «як повинно бути»);

3) скласти план заходів щодо переходу зі стану «як є» у стан «як повинно бути».

Для практичної реалізації цього підходу магістранту необхідно буде вибрати, попередньо обґрунтувавши свій вибір, конкретний інструментальний засіб, наприклад: 1) інструментальний засіб побудови архітектури інтегрованих інформаційних систем (ARIS), 2) інструментальний засіб динамічного моделювання діяльності підприємств (DEM), інструментальний засіб BP Win (APM) тощо.

1.3.3.4. Агентно-орієнтований підхід. Суть агентно-орієнтованого підходу до створення ІУС полягає в тому, що така інформаційна система проектуються та реалізуються як сукупність програмних агентів (software agent) або як мультиагентна система.

Обравши агентно-орієнтований підхід до створення ІУС, магістрант повинен виконати наступні кроки:

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

1) ідентифікація зовнішніх агентів: виділяються зовнішні агенти та висвітлюються їх цілі;

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

3) ідентифікація зовнішніх по відношенню до системи повідомлень: визначаються повідомлення, на які система повинна відповідати;

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

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

1) побудова внутрішньої діаграми агента: цілі агентів та послуги, які вони виробляють, відображаються у внутрішній діаграмі агента;

2) побудова діаграми «клас – відношення»: діаграма агента переводиться в діаграму «клас – відношення» шляхом розгляду відношень;

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

1.3.3.5. Індустріальне типове проектування ІУС. В основі типової (прототипної) технології або RAD-технології (rapid application development - технології швидкої розробки додатків) проектування лежить спіральна модель ЖЦ ІУС. Згідно цієї технології ІУС розробляється шляхом розширення програмних прототипів, повторюючи шлях від деталізації вимог до деталізації програмного коду.

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

1) аналіз і планування інформаційної стратегії – користувачі разом з фахівцями-розробниками беруть участь в ідентифікації проблемної області;

2) проектування – користувачі беруть участь в технічному проектуванні під керівництвом фахівців-розробників;

3) конструювання – фахівці-розробники проектують робочу версію ІУС з використанням мов 4-го покоління;

4) упровадження – фахівці-розробники навчають користувачів роботі в середовищі з новою ІУС.