asyan.org
добавить свой файл
1


Лекція №21

Тема: Специфіка розробки інтегрованих інформаційних систем
План

  1. CASE-засоби.

  2. Методологія RAD.

  3. Методологія функціонального моделювання SADT.

  4. Моделювання потоків даних (процесів).


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

Технологія проектування визначається як сукупність трьох складових:

  • покрокової процедури, що визначає послідовність технологічних операцій проектування;

  • критеріїв і правил, використовуваних для оцінки результатів виконання технологічних операцій;

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

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

Технологія проектування, розробки і супроводи ІС повинна задовольняти наступним загальним вимогам:

  • технологія повинна підтримувати повний ЖЦ ПО;

  • технологія повинна забезпечувати гарантоване досягнення цілей розробки ІС із заданою якістю і у встановлений час;

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

  • технологія повинна забезпечувати можливість ведення робіт по проектуванню окремих підсистем невеликими групами (3-7 чоловік). Це обумовлено принципами керованості колективу і підвищення продуктивності за рахунок мінімізації числа зовнішніх зв'язків;

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

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

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

  • технологія повинна бути підтримана комплексом узгоджених CASE-засобів, що забезпечують автоматизацію процесів, виконуваних на всіх стадіях ЖЦ.

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

  • стандарт проектування;

  • стандарт оформлення проектної документації;

  • стандарт призначеного для користувача інтерфейсу.

Стандарт проектування повинен встановлювати:

  • набір необхідних моделей (діаграм) на кожній стадії проектування і ступінь їх деталізації;

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

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

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

Стандарт оформлення проектної документації повинен встановлювати:

  • комплектність, склад і структуру документації на кожній стадії проектування;

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

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

  • вимоги до настройки видавничої системи, використовуваної як вбудований засіб підготовки документації;

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

Стандарт інтерфейсу користувача повинен встановлювати:

  • правила оформлення екранів (шрифти і колірна палітра), склад і розташування вікон і елементів управління;

  • правила використовування клавіатури і миші;

  • правила оформлення текстів допомоги;

  • перелік стандартних повідомлень;

  • правила обробки реакції користувача.
^

Методологія RAD


Одним з можливих підходів до розробки ПО в рамках спіральної моделі ЖЦ є що одержала останнім часом широке розповсюдження методологія швидкої розробки додатків RAD (Rapid Application Development). Під цим терміном звичайно розуміється процес розробки ПО, що містить 3 елементи:

  • невелику команду програмістів (від 2 до 10 чоловік);

  • короткий, але ретельно пропрацює виробничий графік (від 2 до 6 міс.);

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

Життєвий цикл ПО за методологією RAD складається з чотирьох фаз:

  • фаза аналізу і планування вимог;

  • фаза проектування;

  • фаза побудови;

  • фаза упровадження.

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

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

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

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

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

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

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

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

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

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

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

Методологія функціонального моделювання SADT


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

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

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

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

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

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

  • унікальність влучний і найменувань (відсутність імен, що повторюються);

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

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

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

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

Моделювання потоків даних (процесів)


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

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

  • зовнішня суть;

  • системи/підсистеми;

  • процеси;

  • накопичувачі даних;

  • потоки даних.


Література:

Томас Конноли, Каролин Бегг, Анна Страчан. Базы данных: проектирование, реализация и сопровождение. Теория и практика, 2-е изд. – М.: Издательский дом «Вильямс», 2000. [1], 983-995
Контрольні запитання:

  1. Якими складовими визначається технологія проектування?

  2. Яким загальним вимогам повинна задовольняти технологія проектування, розробки і супроводу ІС?

  3. Дайте коротку характеристику основнім принципи методології RAD?

  4. На яких концепціях ґрунтуються основні елементи методології SADT?

  5. Що лежить в основі методології моделювання потоків даних (процесів)?