Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Тема 3 Створення ІСМ нова.doc
Скачиваний:
3
Добавлен:
30.04.2019
Размер:
122.88 Кб
Скачать

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

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

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

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

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

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

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

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

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

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

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), що відображає розподіл об’єктів по вузлах обчислювальної мережі.