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

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

загальна інформаційна модель системи;

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

точно визначені за допомогою CASE-засоби інтерфейси між автономно розробляються підсистемами;

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

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

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

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

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

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

проводиться аналіз використання даних;

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

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

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

завершується розробка документації проекту.

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

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

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

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

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

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

Як підсумок перерахуємо основні принципи методології RAD:

розробка додатків итерациями;

необов'язковість повного завершення робіт на кожному з етапів життєвого циклу;

обов'язкове залучення користувачів до процесу розробки ІС;

необхідне застосування CASE-засобів, що забезпечують цілісність проекту;

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

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

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

тестування і розвиток проекту, здійснювані одночасно з розробкою;

ведення розробки нечисленної добре керованою командою професіоналів;

грамотне керівництво розробкою системи, чітке планування та контроль виконання робіт. 2. Структурний підхід до проектування ІС 2.1. Сутність структурного підходу

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

Усі найбільш поширені методології структурного підходу [9,11,12,13] базуються на ряді загальних принципів [3]. В якості двох базових принципів використовуються наступні:

принцип "розділяй і володарюй" - принцип вирішення складних проблем шляхом їх розбиття на безліч менших незалежних задач, легких для розуміння і вирішення;

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

Виділення двох базових принципів не означає, що інші принципи є другорядними, оскільки ігнорування будь-якого з них може призвести до непередбачуваних наслідків (в тому числі і до провалу всього проекту). Основними з цих принципів є наступні:

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

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

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

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

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

SADT (Structured Analysis and Design Technique) моделі і відповідні функціональні діаграми (підрозділ 2.2);

DFD (Data Flow Diagrams) діаграми потоків даних (підрозділ 2.3);

ERD (Entity-Relationship Diagrams) діаграми "сутність-зв'язок" (підрозділ 2.4).

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

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

Методологія SADT розроблена Дугласом Россом і отримала подальший розвиток у роботі [4]. На її основі розроблена, зокрема, відома методологія IDEF0 (Icam DEFinition), яка є основною частиною програми ICAM (Інтеграція комп'ютерних та промислових технологій), що проводиться за ініціативою ВПС США.

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

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

строгість і точність. Виконання правил SADT вимагає достатньої строгості й точності, не накладаючи в той же час надмірних обмежень на дії аналітика. Правила SADT включають:

обмеження кількості блоків на кожному рівні декомпозиції (правило 3-6 блоків);

зв'язність діаграм (номери блоків);

унікальність міток і найменувань (відсутність повторюваних імен);

синтаксичні правила для графіки (блоків і дуг);

поділ входів та управлінь (правило визначення ролі даних).

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

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

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

Однією з найбільш важливих особливостей методології SADT є поступове введення все більших рівнів деталізації у міру створення діаграм, що відображають модель.

Рис. 2.1. Функціональний блок та інтерфейсні дуги

На малюнку 2.2, де наведено чотири діаграми та їх взаємозв'язку, показана структура SADT-моделі. Кожен компонент моделі може бути декомпозирована на іншій діаграмі. Кожна діаграма ілюструє "внутрішню будову" блоку на батьківській діаграмі. 2.2.2. Ієрархія діаграм

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

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

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