Класи і характеристики технологій проектування

Клас технології проектування	Ступінь автоматизації	Ступінь типізації	Ступінь адаптивності
Канонічне проектування	Ручне проектування	Оригінальне проектування	Реконструкція
Індустріальне автоматизоване проектування	Комп’ютерне проектування	Оригінальне проектування	Реструктуризація моделі (генерація ІСМ)
Індустріальне типове проектування	Комп’ютерне проектування	Типове складальне проектування	Параметризація і реструктуризація моделі (конфігурація ІСМ)

 

3.2. Канонічне проектуваня

Канонічному проектуваню відповідає каскадна модель життєвого циклу ІСМ, яка відповідно до застосовуваного в нашій країні держстандарту 34.601-90 такі стадії створення автоматизованих систем:

формування вимог до інформаційної системи;

розробка концепції інформаційної системи;

розробка технічного завдання;

створення ескізного проекту;

технічне проектування;

робоче проектування;

введення в експлуатацію;

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

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

Індустріальне автоматизоване проектування ІСМ передбачає використання CASE-засобів автоматизації проектування (Computer Aided System/Software Engineering), орієнтованих на автоматизацію проектування програмного забезпечення з використанням специфікацій у вигляді діаграм або текстів для опису системних вимог, зв’язків між моделями системи, динаміки поводження системи й архітектури програмних засобів.

Сучасні CASE-системи підтримують такі основні методології проектування: функціонально (структурно)-орієнтовані та об ’єктно-орієнтовані.

Функціонально-орієнтована CASE-технологія грунтується на методології структурного аналізу і проектування інформаційних систем, яка використовує такі прийоми:

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

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

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

BFD (Bussiness Function Diagram) - діаграма бізнес-функцій (функціональні специфікації);

DFD (Data Flow Diagram) - діаграма потоків даних;

STD (State Transition Diagram) - діаграма переходів станів (матриці перехресних посилань);

ERD (Entity Relationship Diagram) - ER-модель даних предметної області (інформаційно-логічні моделі «сутність-зв’язок»);

SSD (System Structure Diagram) - діаграма структури програмного додатка.

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

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

Об’єктно-орієнтоване моделювання проблемної області найбільш використовуваною у даний час є уніфікована мова моделюванняUML (Unified Modeling Language), розроблена групою комп’ютерних фірм OMG (Object Management Group) і реалізована у багатьох пакетах CASE-засобів, як то: Rational Rose (виробник - Rational), Natural Engineering Workbench (виробник - Software AG), ARIS Toolset (виробник - IDS prof. Scheer) та ін.

Мова UML підтримує систему об’єктно-орієнтованих моделей, що передбачає побудову таких діаграм:

1) діаграма прецедентів використання (Use-case diagram), що відображає функціональність ІСМ у вигляді сукупності послідовностей виконуваних транзакцій;

2) діаграма класів об’єктів (Class diagram), що відображає структуру сукупності взаємозалежних класів об’єктів аналогічно ER-діаграмі функціонально-орієнтованого підходу;

3) діаграми станів (Statechart diagram), кожна з яких відображає динаміку станів об’єктів одного класу і пов’язаних із ними подій;

4) діаграми взаємодії об’єктів (Interaction diagram), кожна з який відображає динамічну взаємодію об’єктів у рамках одного прецеденту використання;

5) діаграми діяльностей (Activity diagram), що відображають потоки робіт у взаємозалежних прецедентах використання;

6) діаграми пакетів (Package diagram), що відображають розподіл об’єктів за функціональними або забезпечувальними підсистемами;

7) діаграма компонентів (Component diagram), що відображає фізичні модулі програмного коду;

8) діаграма розміщення (Deployment diagram), що відображає розподіл об’єктів по вузлах обчислювальної мережі.

3.4. Індустріальне типове проектування ІСМ

Індустріальне типове проектування ІСМ передбачає створення системи з готових покупних типових елементів (типових проектних рішень).

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

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

Підсистемний метод типового проектування ІС у якості елементів типізації використовує окремі підсистеми, що реалізуються як пакети прикладних програм (ППП). Пиклади функціональних ППП: «1C: Підприємство» (автоматизація бухгалтерського обліку, розрахунку заробітної плати, складського обліку), «Фоліо - Склад» (автоматизація складських операцій), ІНЕК (фінансовий аналіз) та ін.

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

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

Параметрично-орієнтоване проектування ІС передбачає параметричне налаштовування пакету прикладних програм (ППП), який розглядається як «чорна скринька».

Параметрична інформація задається:

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

у таблицях описів конфігурації програмних модулів (наприклад, умови включення (виключення) модуля, режими ручногоабо автоматичного відновлення полів даних, методи розрахунків показників і т.ін.);

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

Моделъно-орієнтоване проектування ІС полягає в адаптації компонентів типової ІС до моделі проблемної області конкретної організаційно-економічної системи. Основними особливостями даної технології проектування є підтримка моделі типової ІС, побудова моделі конкретного підприємства, а також досягнення відповідності між ними.

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

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