Програмна інженерія в історичному аспекті.

Програмна інженерія в історичному аспекті.

 

Наприкінці 90-х р. минулого століття знання і досвід, що були накопичені в індустрії програмного забезпечення за попередні 30-35 років, а також більш ніж 15-літніх спроб застосування різних моделей розробки, усе це, нарешті, оформилося в те, що прийнято називати дисципліною програмної інженерії – Software Engineering. Якоюсь мірою, таке формування дисципліни на основі широко розповсюдженого практичного досвіду нагадує ті процеси, що відбувалися в управлінні проектами. Виникали і розвивалися професійні асоціації, спеціалізовані інститути, комітети зі стандартизації й інші утворення, що, зрештою, прийшли до спільної думки про необхідність зведення професійних знань по відповідним областях і стандартизації відповідних програм навчання.

У 1958 р. всесвітньо відомий статистик Джон Тьюкей (John Tukey)уперше ввів термін software - програмне забезпечення. У 1972 р. IEEE (Computer Society of the Institute for Electrical and Electronic Engineers, IEEE Computer Society – IEEE--CS (Комп'ютерне Суспільство) чи просто IEEE. http://www.ieee.org/) випустив перший номер Transactions on Software Engineering – Праці з програмної інженерії. Перший цілісний погляд на цю область професійної діяльності з'явився 1979 р., коли Комп'ютерне Суспільство IEEE підготувало стандарт IEEE Std 730 щодо якості програмного забезпечення. Після 7 років напружених робіт, у 1986 р. IEEE випустило IEEE Std 1002 ”Taxonomy of Software Engineering Standards”.

У 1990 р. почалося планування всеосяжних міжнародних стандартів, в основу яких лягли концепції і погляди стандарту IEEE Std 1074 і результатів роботи утвореної в 1987 р. спільної комісії ISO/IEC JTC 1(International Organization for Standardization; IEC – International Electrotechnical Commission; JTC 1 – Joint Technical Committee 1, Information technology).

У 1995 р. група цієї комісії SC7 “Software Engineering ” випустила першу версію міжнародного стандарту ISO//IEC 12207 “Software Lifecycle Processes ”. Цей стандарт став першим досвідом створення єдиного загального погляду на програмну інженерію. Відповідний національний стандарт Росії – ГОСТ Р ИСО/МЭК 12207-99 [ГОСТ 12207,1999 ] містить повний автентичний переклад тексту міжнародного стандарту ISO/IEC 12207-95 (1995 р.).

У свою чергу, IEEE і ACM (Association of Computer Machinery).,почавши спільні роботи ще в 1993 р. з кодексу етики і професійної практики в даній галузі (ACM/IEEE-CS Code of Ethics and Professional Practice), до 2004 р. сформулювали два ключових описи того, що сьогодні ми і називаємо основами програмної інженерії –Software Engineering:

1. Guide to the Software Engineering Body of Knowledge (SWEBOK),IEEE 2004 Version - Керівництво до Зводу Знань з Програмної Інженерії, надалі просто “SWEBOK ” [SWEBOK,2004 ];

2. Software Engineering 2004.Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering - Навчальний План для Викладання Програмної Інженерії у Вузах (дана назва представлено у вільному перекладі) [SE,2004 ].

Обидва стандарти стали результатом консенсусу провідних представників індустрії і визнаних авторитетів в галузі програмної інженерії - за аналогією з тим, як був створений PMI PMBOK. Так ми прийшли до сьогоднішнього стану Software Engineering як дисципліни.

SWEBOK: Керівництво до зводу знань з програмної інженерії.

 

З 1993 р. IEEE і ACM координують свої роботи в рамках спеціального спільного комітету -Software Engineering Coordinating Committee (SWECC -http://www.computer.org/tab/swecc).Проект SWEBOK був ініційований цим комітетом у 1998 р. Оцінений можливий обсяг змісту SWEBOK і інші фактори привели до того, що було рекомендовано проводити роботи з реалізації проекту не тільки силами добровольців з рядів експертів індустрії і представників найбільших споживачів і виробників програмного забезпечення, але і на основі принципу “повної зайнятості”. Базовий комплекс робіт, у відповідності зі спеціальним контрактом, був переданий у Software Engineering Management Research Laboratory Університету Квебек у Монреалі (Universite du Quebec a Montreal).

Серед компаній, що підтримали цей унікальний проект були Boeing, MITRE, Raytheon, SAP. У результаті проекту, здійсненого за фінансової підтримки цих і інших компаній і організацій, а також з урахуванням його значимості для індустрії, SWEBOK Advisory Committee (SWAC) прийняв рішення зробити SWEBOK загальнодоступним – http://www.swebok.org/ перспективі, якщо удасться забезпечити відповідний рівень фінансування, SWAC вважає за необхідне закінчену версію SWEBOK 2008 зробити також вільно доступною на Web-сайті проекту. Сьогоднішня “публічність” (загальнодоступність) результатів проекту стала можлива, у першу чергу, саме завдяки підтримці SWEBOK Industrial Advisory Board (IAB) – структури, що поєднує представників компаній, що підтримали проект.

Проект SWEBOK планувався у вигляді трьох фаз: Strawman (“солом'яна людина”), Stoneman (“кам'яна людина”) і Ironman (“залізна людина”). До 2004 р. була випущена версія Посібника зі Зводу Знань 3-їй фази -Ironman, тобто максимально наближена до остаточного варіанту і схвалена IEEE у лютому 2005 р. до публікації в якості Trial-версії. Основна мета поточної “пробної ” версії SWEBOK – поліпшити представлення, цілісність і корисність матеріалу керівництва на основі збору й аналізу відгуків на дану версію для того, щоб випустити фінальну редакцію документа в 2008 р.З ряду обгрунтованих причин, “SWEBOK є досить консервативним” [SWEBOK,2004, с.B-2 ].

Після 6 років безпосередніх робіт над документом, SWEBOK включає “лише” 10 галузей знань (knowledge areas, KA). При цьому, що справедливо і для PMBOK, додавання нових галузей знань у SWEBOK досить прозоре. Усе, що для цього потрібне, зрілість (чи, принаймні, явний і швидкий процес досягнення зрілості) і загальноприйнятності відповідної галузі знань, якщо це не призведе до серйозного
ускладнення SWEBOK (*концепція “загальноприйнятності” - generally accepted – визначена в IEEE Std 1490--1998,Adoption of
PMI Standard — A Guide to the Project Management Body of Knowledge).

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

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

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

Структура і зміст SWEBOK.

 

Опис галузей знань у SWEBOK побудовано за ієрархічним принципом, як результат структурної декомпозиції. Така ієрархічна побудова звичайно нараховує два-три рівня деталізації, прийнятих для ідентифікації тих чи інших загальновизнаних аспектів програмної інженерії. При цьому, структура декомпозиції галузей знань деталізована тільки до того рівня, що потрібен для розуміння природи відповідних тем і можливості пошуку джерел компетенції й інших довідкових даних і матеріалів. У принципі, вважається, що як такий “звід знань ” з програмної інженерії представлений не в обговорюваному керівництві (SWEBOK),а в першоджерелах (як зазначених у ньому, так і представлених за його рамками) [SWEBOK,2004, с.1-2 ].

SWEBOK описує 10 галузей знань:

1. Software requirements – програмні вимоги

2. Software design – дизайн (архітектура)

3. Software construction – конструювання програмного забезпечення

4. Software testing - тестування

5. Software maintenance – експлуатація (підтримка)програмного забезпечення

6. Software configuration management – конфігураційне управління

7. Software engineering management – управління в програмній інженерії

8. Software engineering process – процеси програмної інженерії

9. Software engineering tools and methods – інструменти і методи

10. Software quality – якість програмного забезпечення.

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

1. Computer engineering

2. Computer science

3. Management

4. Mathematics

5. Project management

6. Quality management

7. Software ergonimics

8. Systems engineering

Варто відзначити, що прийняті розмежування між галузями знань, їх компонентами (subareas) і іншими елементами досить довільні. При цьому, на відміну від PMBOK, галузі знань SWEBOK не включають “входи ” і “виходи ”. Деякою мірою така декомпозиція пов'язані з тим, що SWEBOK не асоційовано з тією чи іншою моделлю (наприклад, життєвого циклу) чи методом. Хоча на перший погляд перші п'ять галузей знань у SWEBOK представлені в традиційній послідовній (каскадній -waterfall) моделі, це не більш ніж слідування прийнятій послідовності висвітлення відповідних тем. Інші галузі і структура декомпозиції галузей представлені за абеткою.

На рис. 1 представлені перші п'ять галузей знань.

Рис. 1. Перші п'ять галузей знань [SWEBOK,2004,с.1-8, рис.2 ]

 

Інженерія вимог

 

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

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

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

Область знань «Вимоги до ПЗ (Software Requirements))) складається у таких розділів:

- інженерія вимог (Requirement Engineering),

- виявлення вимог (Requirement Elicitation),

- аналіз вимог (Requirement Analysis), специфікація вимог (Requirement Specification).

- валідація вимог (Requirement validation),

- керування вимогами (Requirement Management).

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

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

Керування вимогами до ПЗ полягає в контролі за виконанням вимог і плану­ванні використання ресурсів (людських, програмних, технічних, часових, вартісних) у процесі розроблення проміжних робочих продуктів на етапах ЖЦ і продукту в цілому.

Якість і процес поліпшення вимог - це процес формулювання характеристик і атрибутів якості (надійність, реактивність і ін.), які повинно мати ПЗ, методи їх досягнення на етапах ЖЦ і оцінювання отриманих результатів.

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

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

Специфікація вимог до ПЗ - процес формалізованого опису функціональ­них і не функціональних вимог, вимог до характеристик якості відповідно до стан­дарту якості ISO/IEC 9126, які будуть відпрацьовуватися на етапах ЖЦ ПЗ. У спе­цифікації вимог відбивається структура ПЗ, вимоги до функцій, якості і документа-функцій, якості і документації, а також задається архітектура системи і ПЗ, алгоритми, логіка керування і структура даних. Специфікуються також системні вимоги, не функціональні вимоги і вимоги до взаємодії з іншими компонентами і платформами (БД, СКБД, маршаллінг даних, мережа й ін.).

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

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

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

 

Керування конфігурацією

 

Керування конфігурацією - це ідентифікація компонентів системи, визначення функціональних, фізичних характеристик системи, апаратного і програмного забезпечення для контролю виконання, внесення змін і трасування конфігурації. Процес керування визначено як один з допоміжних процесів ЖЦ (ISO/IEC 12207), виконуваний технічним і адміністративним менеджментом проекту. При цьому складаються звіти про зміни, внесені у конфігурацію, і ступінь їхньої реалізації, а також проводиться перевірка відповідності внесених змін заданим вимогам.

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

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

Область знань «Керування конфігурацією ПЗ (Software Configuration Management - SCM)» складається з таких розділів:

- керування процесом конфігурації (Management of SMC Process),

- ідентифікація конфігурації ПЗ (Software Configuration Identification),

- контроль конфігурації ПЗ (Software Configuration Control),

- облік статусу (поведінка або стани) конфігурації ПЗ (Software Configuration Status Accounting),

- аудит конфігурації ПЗ (Software Configuration Auditing),

-керування версіями ПЗ і доставкою (Software Release Management and Delivery).

Керування процесом конфігурації. Це діяльність з контролю еволюції і ці­лісності продукту при ідентифікації, змінах і забезпеченні звітною інформацією, що стосується конфігурації. Вона містить у собі:

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

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

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

- трасування змін у конфігурації на етапах супроводу й експлуатації ПЗ.

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

Контроль конфігурації ПЗ - це роботи з координації, затвердження або відкидання реалізованих змін в елементах конфігурації після ідентифікації, а також з аналізу вхідних компонентів конфігурації.

Облік статусу або стану конфігурації ПЗ — комплекс заходів для визначення ступеня зміни конфігурації, а також правильності внесених змін усистему при супроводі. Інформація і кількісні показники накопичуються у відповідній БД і використовуються при складанні звітності, оцінюванні якості і виконанні процесів ЖЦ.

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

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

Базис (baseline) - формально позначений набір елементів ПЗ, зафіксований на етапах ЖЦ.

Бібліотека ПЗ - колекція об'єктів ПЗ і документації, призначена для полег­шення процесу розроблення, використання і супроводження.

Складання ПЗ - об'єднання коректних елементів і конфігураційних даних у єдину виконувану програму.

 

Процес інженерії

 

Процес інженерії - є мета рівнем, що визначає основні поняття, способи реа­лізації, оцінювання, вимірювання, дії з керування змінами й удосконалення самого процесу. Як уже згадувалася в п. 1.1.2., для оцінювання й удосконалення процесу програмної інженерії застосовується модель зрілості СММ [12], яку розроблено Інститутом програмної інженерії SEI (Software Engineering Institute) CLLIA. Ця модель встановлює рівні готовності організації-розробника ПЗ створювати задовільно, середньо, добре і дуже добре програмну продукцію. Поняття рівня готовності визначається наявністю в організації необхідних ресурсів (людських, програмних, технічних і фінансових), стандартів і методик, а також здатністю колективу створювати програмні продукти. Модель СММ має п'ять рівнів. Перший і другий рівні фіксують недостатню готовність виконувати розробку продукту. Третій - п'ятий рівні характеризують певний ступінь готовності, зрілості і здатності фахівців (а, значить, і організації) виготовляти, відповідно, середній, гарний і відмінний продукт. Чим вище рівень зрілості, тим більше вимог ставиться до процесу програмної інженерії, придатного для виконання цілей і задач утворення продукту, що задовольняє користувача.

Існують різновиди цієї моделі: СММ - SW (Software) для оцінки зрілості ПЗ, СММІ (СММ Integrated) - для обліку потреб великих державних структур в ПЗ (СІЛА), а також інші моделі, наприклад, Bootstrap - для оцінки зрілості малих і середніх комерційних компаній, стандарт ISO 15504 (Software Process Improvement and Capability) - для удосконалення процесу (наприклад, удосконалювати процес на другому рівні, щоб одержати сертифікат на третій рівень зрілості).

Концепція зрілості процесу програмної інженерії ґрунтується на процесі ПЗ (software process), широті його можливостей (software process capability), результативності (software process performance) і зрілості (software process maturity). Процес ПЗ у моделі СММ - це множина діяльностей (activities), методів (methods), практичних прийомів (practices), що використовують при розробки ПЗ шляхом планування робіт і оцінювання проміжних результатів, які приводять до кінцевого продукту високої якості.

Область знань «Процес програмної інженерії (Software Engineering Process)» складається з таких розділів:

- концепції процесу інженерії ПЗ (Software Engineering Process Concepts), інфраструктура процесу (Process Infrastructure),

- визначення процесу (Process Definition),

- оцінки процесу (Process Assessments),

- якісний аналіз процесу (Qualitative Process Analysis),

- виконання і змінювання процесу (Process Implementation and Change).

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

Інфраструктура процесу містить у собі ресурси (людські, технічні, інформаційні і програмні), стандарти, методики керування якістю, проектом і структуру колективу розробників ПЗ типу: команда, бригада, експериментальна фабрика (Experimental Factory), каркас виробництва на лінії продуктів (Framework for Product Line Practice) і ін. До основних задач інфраструктури належать керування і комунікації в колективі, інженерні методи виробництва програмного продукту й удосконалення процесу з накопиченим досвідом розробки ПЗ.

Визначення процесу ґрунтується на: типах процесів і моделей (каскадна, спіральна, ітераційна й ін.); моделях ЖЦ процесів і засобів, стандартах ЖЦ ПЗ ISO/IEC 12207 і ISO/IEC 15504, IEEE std. 1074 і IEEE std. 1219; методах і нотаціях подання процесів і автоматизованих засобів їх підтримки. Основною метою процесу є підвищення якості одержуваного продукту, поліпшення різних аспектів програмної інженерії, автоматизація і удосконалення процесів.

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

Оцінки стосуються також технічних робіт у сфері програмної інженерії, керування персоналом і якості ПЗ. Для цього проводяться експериментальні дослідження середовища, збирання інформації, моделювання, класифікація отрима­них помилок і дефектів, а також статичний аналіз недоліків процесу порівняно з існуючими стандартами (наприклад, ISO/IEC 12207) і потенційних аспектів необхідності вдосконалювати процес.

Якісний аналіз процесу полягає в ідентифікації і пошуку «слабких місць» у процесі створення ПЗ на початку його функціонування і після експлуатації. Розглядаєтьсядві техніки аналізу: огляд даних і порівняння процесу з основними положеннями стандарту ISO/IEC 12207, збирання даних про якість процесів; аналіз головних причин відмов у функціонуванні ПЗ, відкіт назад від точки виникнення відхилення до точки правильної роботи системи для з'ясування причин зміни процесу. На якість результатів проекту і процесу впливають застосовувані інструменти і досвід фахівців.

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

 

Структурне програмування

 

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

Основу структурного програмування становлять:

- розподіл системи на множину незалежних задач, доступних для розуміння і розв'язання;

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

До головних принципів належать:

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

- формалізація, тобто загальне методологічне вирішення проблеми;

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

ність;

- утворення ієрархічної структури даних.

При структурному аналізі застосовуються три найпоширеніші моделі структурного проектування ПС:

• SADT (Structured Analysis and Design Technique) - метод структурного аналізу й техніка проектування моделі системи за допомогою функціональних діаграм [1];

• SSADM (Structured Systems Analysis and Design Methode) - метод структур­ного аналізу й проектування систем [2];

• IDEF (Integrated Definition Functions) - метод визначення функціональної моделі, IDEF1 - інформаційної моделі, IDEF2 - динамічної моделі й ін. [3].

Розглянемо ці методи детальніше.

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

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

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

Метод SADT базується на наступних концепціях:

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

 

 

Рис. 5.1. Структура моделі

 

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

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

- унікальність позначок і найменувань;

- незалежність функціональної моделі від організаційної структури колекти­ву розробників.

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

Результат проектування в методі SADТ - модель, що складається з діаграм, фрагментів текстів і глосарію з посиланнями один на одного. Всі функції й інтер­фейси зображуються діаграмами у вигляді блоків і дуг. Місце з'єднання дуги з блоком визначає тип інтерфейсу. Керуюча інформація позначається дугою, яка входить у блок зверху, у той час як інформація, що піддається обробці, вказується з лівої сторони блоку, а результати виходу - з правої сторони. Механізм, що здійснює операцію (людина або автоматизована система), задається дугою, що входить у блок знизу.

Одна з найбільш важливих переваг методу SADТ - поступова деталізація мо­делі системи в міру додавання функцій і діаграм, що уточнюють цю модель.

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

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

Таке програмування передбачає наявність моделі ЖЦ із послідовними процесами розроблення програмного проекту, починаючи з аналізу і формування вимог для ПрО (рис. 5.2).

До етапів ЖЦ належать:

- стратегічне проектування та вивчення можливості виконання проекту;

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

- логічне проектування та специфікація компонентів системи;

- фізичне проектування структур даних відповідно до вибраної структури БД (реляційної, об'єктно-орієнтованої й ін.) та конструювання окремих компонентів, їх тестування і тестування системи в цілому;

- виготовлення продукту і документації для замовника.

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

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

Рис.5.2. Життєвий цикл SSADM

 

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

Фізичне проектування – це визначення типу СКБД і подання даних у ній з урахуванням специфікації логічної моделі даних, обмежень на пам'ять і час оброб­ки, а також визначення механізмів доступу, розміру логічної БД, зв'язків між елементами системи.

Фізична специфікація містить у собі:

- специфікацію функцій і схеми реалізації компонентів функцій,

- опис процедурних і не процедурних компонентів й інтерфейсів,

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

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

Процеси, які виконуються у SSADM, пов'язані з роботами, що керують пото­ками інформації трьох типів: потік робіт; санкціоновані потоки за контролем або керуванням; звіти про хід розроблення.

Конструювання - це побудова конструкцій і елементів системи, їхнє тесту­вання на наборах даних, які підбираються на ранніх етапах ЖЦ розробки системи.

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

Згідно з методом SSADM створюється структурна модель системи і модель потоків даних. У діаграмах структурної моделі впорядкування процесів наведено зліва направо і віддзеркалює розвиток у часі, а не інтервали часу.

Модель потоків даних (Data Flow Model - DFM) використовується для опису процесів обробки даних у системі й містить у собі:

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

- опис елементарних процесів, потоків даних, сховищ даних і зовнішніх сутностей.

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

До об'єктів моделювання системи в SSADM належать:

1. Функції, які створюються на основі DFM і моделювання взаємозв'язків подій і сутностей для дослідження обробки даних у системі;

2. Події - деякі прикладні дії, які ініціюють процеси для занесення й віднов­лення даних системи. Подія приводить до виклику процесу і досліджується за до­помогою моделювання її впливу на сутності;

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

Найпоширеніші засоби моделювання даних - діаграми «сутність-зв'язок» (ER - діаграми), запропоновані Баркером, як застосування класичної ER - моделі Чена. В ER - діаграмах визначаються сутності (множини однотипних об'єктів) ПрО, їхні властивості (атрибути) і залежності (зв'язки). Сутність (Entity) - реальний або уявлюваний об'єкт, що має істотне значення для області. Кожна сутність й її екзем­пляр мають унікальні імена. Сутність має такі властивості:

- один або кілька атрибутів, які або належать сутності, або успадковуються через зв'язок (Relationship);

- довільну кількість зв'язків з іншими сутностями моделі.

Зв'язок - це асоціація між двома сутностями ПрО. У загальному випадку кожен екземпляр сутності-батька асоційований з довільною кількістю екземплярів успадкованої сутності (нащадка), а кожен екземпляр сутності-нащадка асоційова­ний з одним екземпляром сутності-батька. Таким чином, екземпляр сутності-нащадка може існувати тільки при наявності сутності-батька. Для зв'язків можуть встановлюватися обмеження на кількість екземплярів сутності, що беруть участь у зв'язку. Наприклад, одному екземпляру однієї сутності може відповідати не більше ніж один екземпляр іншої.

Метод IDEF1 базується на концепції ER - моделювання і призначений для побудови інформаційної моделі подібно до реляційної моделі. Даний метод постій­но розвивається й удосконалюється (наприклад, методологія IDEF1X - проектування, орієнтована на автоматизацію - ERwin, Design/IDEF). Основна особ­ливість полягає в тому, що кожен екземпляр сутності може бути однозначно іден­тифікований без визначення відношення з іншими сутностями. Якщо Ідентифікація екземпляра сутності залежить від його відношення до іншої сутності, то сутність є залежною. Кожній сутності присвоюється унікальне ім'я і номер, які розділяють косою рискою «/» і розміщують над блоком, який позначає сутність. Обмеження на множинність зв'язку можуть означати, що для кожного екземпляра сутності-батька:

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

- існує не менше ніж один або не більше ніж один пов'язаний з ним екземп­ляр сутності-нащадка;

- існує зв'язок з деяким фіксованим числом екземплярів сутності-нащадка. Якщо екземпляр сутності-нащадка однозначно визначається своїм зв'язком із

сутністю-батьком, то зв'язок є ідентифікований, інакше - не ідентифікований. Сутність-батько в ідентифікованому зв'язку може бути як незалежною, так і залежною від зв'язків з іншими сутностями. Сутність-нащадок у не ідентифікованому зв'язку буде незалежною, якщо вона не є також сутністю-нащадком у якому-небудь ідентифікованому зв'язку.