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

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

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

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

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

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

- надійність функціонування і безпека застосування;

- ефективне використання пам’яті або продуктивності ЕОМ;

- трудомісткість або тривалість розробки;

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

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

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

РОЗДІЛ 2. ПІДХОДИ ДО ПОБУДОВИ ПРОГРАМНИХ ЗАСОБІВ.
ОБ’ЄКТНО-ОРІЄНТОВАНИЙ ПІДХІД. МОВА UML

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

На етапі проектування технологічного об’єкта закладаються концептуальні рішення по його конструкції та принципам функціонування. Саме на даному етапі зосереджені основні зусилля розробників з рішення проблем, що виникають у зв’язку зі складністю самої системи та складністю процесу її створення [3, 4]. Аналіз показує, що складні системи мають п’ять ознак:

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

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

внутрішньоелементні зв’язки зазвичай сильніше міжелементних, тому високочастотні взаємодії усередині структури виявляються природно відділені від низькочастотних взаємодій між структурами. Це обумовлює поділ системи на абстрактні автономні частини, які можна вивчати роздільно;

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

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

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

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

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

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

У зв’язку з широтою проблем і природною складністю об’єктів дослідження, до яких застосовується ООП, до середини 90-х років розвилася досить велика кількість заснованих на ООП так званих об’єктно-орієнтованих методологій. До найбільш відомих з них відносяться Booch, OMT (Object Modeling Technique), OOSE (Object-Oriented Software Engineering). В 1994-1995 роках автори зазначених методологій (Grady Booch, James Rumbaugh, Ivar Jacobson) об’єднали свої зусилля й створили UML – уніфіковану мову моделювання (Unified Modeling Language), що у цей час є одним з найбільш популярних інструментів розробки об’єктно-орієнтованих систем. Виник консорціум UML, у який увійшли компанії DEC, Hewlett-Packard, Intellicorp, Microsoft, Oracle, Texas Instruments, Rational, і інші. Об’єктно-орієнтовані методології підтримуються відповідними CASE-засобами. Для використання UML розроблені, такі CASE-засоби, як Rational Rose, Select Enterprise, Visual UML і ін., є підтримка UML в Microsoft Visio.

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

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

2.2. Призначення та основні компоненти UML

Уніфікована мова моделювання або надалі UML являє собою універсальну мову, що дозволяє одночасно з аналізом створювати документацію для проектування складних ієрархічних систем, для того, щоб потім втілювати її у працездатний код на будь-якій з мов програмування [4-6]. Автори мови приклали багато зусиль, щоб UML строго описувала процес створення програмного забезпечення.

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

Мова UML призначена насамперед для розробки програмних систем. Її використання особливо ефективне в наступних областях:

· інформаційні системи масштабу підприємства;

· банківські і фінансові послуги;

· телекомунікації;

· транспорт;

· оборонна промисловість, авіація і космонавтика;

· роздрібна торгівля;

· медична електроніка;

· наука;

· розподілені Web-системи.

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

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

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

· клас – це група сутностей (об’єктів), що володіють подібними властивостями, а саме, даними і поводженням. Окремого представника деякого класу називають об’єктом класу або просто об’єктом;

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

· під поводженням об’єкта в UML розуміють будь-які правила взаємодії об’єкта з зовнішнім світом і з даними самого об’єкта;

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

· спадкування – це відношення, що визначає рівень ієрархії конкретного класу в дереві класів, і говорить про те, що нащадки конкретного класу є різновидом класу-батька. Механізм спадкування реалізується за допомогою копіювання всіх атрибутів предка (спадкування) і їхнього часткового перевизначення. Перевизначати можна як дані, так і методи;

· поліморфізм – стосується перевизначення поводження об’єктів. В UML для опису поліморфізму вводяться поняття операції і метода. У класів є операції, що визначають його поводження. Вони успадковуються нащадками, але кожен нащадок класу може надати свій метод реалізації будь-якій успадкованій операції, який відмінний від відповідного методу предка. Підкреслимо, що з операцією зв’язаний якісний опис поводження об’єкта, а з методом – його конкретна реалізація. Таким чином, стає можливим, успадковуючи операції, надавати їм потрібні властивості, які притаманні об’єктам класу-нащадка;

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

Основні компоненти, що складають UML, включають опис семантики UML, його графічної нотації і додаткових понять, що дозволяють розширити зміст основних понять мови. Документація UML містить докладний опис цих компонентів і разом з формальним описом UML у вигляді сімох pdf-файлів представлена на сайті Ratіonal Software (www.rational.com). Наведемо скорочений опис основних понять мови.

UML – це графічна мова і її вивчення варто починати з вивчення застосовуваних у ній графічних образів ("Notatіon Guіde"). Для правильного трактування графічних образів необхідно познайомиться з їхньою змістовною стороною ("UML Semantіcs"). Авторами також описані і можливі розширення мови, пристосовані до конкретних технологій. Для опису семантики автори використовували саму мову UML, a там, де не вистачало її можливостей, – англійську.

У процесі розробки система представляється у вигляді об’єднання декількох проекцій, кожна з яких описує визначений аспект розроблюваної системи, а разом вони визначають систему у всій її повноті. Ці проекції представляються в UML наступними діаграмами:

· діаграми класів (class dіagrams). Діаграми класів показують статичну структуру системи, тобто визначають типи об’єктів системи і різного роду статичні зв’язки і відносини між ними. Діаграми класів містять набір статичних (декларативних) елементів, таких як класи, типи і їхні зв’язки, зображених у вигляді графа. Діаграми класів можуть бути логічно об’єднані в пакети;

· діаграми варіантів використання (use case dіagrams). Звичайно в складних систем багато функцій і існує багато варіантів їхнього використання (сценаріїв). Одна і та ж діюча особа (actor) рідко використовує усі функції системи, тому всі діючі особи можна умовно розділити на групи, відповідно до типових сценаріїв використання визначених функцій. Для кожної групи можна скласти свій об’єднаний груповий сценарій (use case), що представляє собою набір усіх можливих сценаріїв застосування тієї або іншої частини системи. Список усіх групових сценаріїв визначає функціональні вимоги до системи, за допомогою яких може бути сформульоване технічне завдання. Діаграми варіантів використання являють собою граф, за допомогою якого показані всі типові діючі особи і їхня взаємодія з системою. Взаємодія представлена сценаріями застосування;

· діаграми взаємодії (іnteractіon dіagrams) підрозділяються на діаграми послідовності і кооперативні діаграми. На обох діаграмах представлена часова послідовність використання об’єктів при реалізації конкретного сценарію і повідомлень, якими вони при цьому обмінюються. Тут можна побачити наявну в мові надлишковістю, тому що обидві діаграми, по суті, відрізняються лише за формою. Більш того, вони скоріше можуть бути застосовані на етап "ручного" проектування, коли ми намагаємося за допомогою олівця і паперу уявити собі майбутню систему, і в силу своєї громіздкості, не можуть бути покладені в основу машинної графічної мови;

· діаграми послідовності (sequence dіagrams) показують, у якій послідовності з’являються об’єкти при виконанні тієї або іншої операції (сценарію) і який потік повідомлень при цьому виникає. Діаграми послідовності мають дві осі: вертикальна представляє час, горизонтальна – різні об’єкти. Зазвичай інтерес представляє тільки послідовність появи об’єктів у міру виконання операції, але у випадку систем реального часу можуть знадобитися і конкретні значення часу;

· кооперативні діаграми (collaboratіon dіagrams). Мета цієї діаграми та ж, що і діаграми послідовності, але можливо комусь вона виявиться більш зручною. На діаграмі у вигляді графа зображуються об’єкти, що беруть участь у виконанні операції, їхній зв’язок і послідовність появи. Звичайно це дерево, тому що для більш складних випадків такі діаграми стають дуже складними для сприйняття. Повідомлення, якими обмінюються об’єкти, зображені у вигляді стрілок, щоб відбивати їхню часову послідовність, кожна стрілка пронумерована;

· діаграми станів (state dіagrams). Будь-який об’єкт системи може змінювати своє поводження в залежності від внутрішніх або зовнішніх подій, що відбуваються, або, іншими словами, він може реагувати на події, змінюючи свій стан. Діаграми станів показують послідовність станів, у яких може опинитися об’єкт, у залежності від подій, що відбуваються, разом з їхніми реакціями на ці події. Діаграми станів описують стан тільки одного класу або об’єкта. Стани в UML трактуються так само, як у карті станів Харела, тобто коли система знаходиться в одному зі станів, фіксується деякий набір значень змінних системи, що установилися у відповідь на подію, що відбулася;

· діаграми діяльностей (actіvіty dіagrams). У багатьох випадках ми спостерігаємо зміну станів об’єкта, викликану тільки внутрішніми причинами. Усередині об’єкта виконуються послідовно або паралельно визначені тривалі дії. Для такого типу систем UML і пропонує використовувати діаграми діяльностей. Така діаграма призначена для того, щоб відбити переходи, викликані внутрішніми процесами (на противагу зовнішнім подіям, з якими має справа діаграма стану). Діаграми діяльностей використовуються для опису складного поводження класу або сценарію і представлення складних операцій у вигляді послідовності рівнобіжних і послідовних тривалих дій;

· діаграми реалізації (іmplementatіon dіagrams). Діаграми реалізації складаються з компонентних діаграм і діаграм застосування (розгортання). Вони, на відміну від діаграм стану, взаємодії, використання і класів, що є логічними представленнями системи в процесі її розробки, дають фізичне представлення системи;

· компонентні діаграми (component dіagrams) Компонентні діаграми показують взаємозв’язок між компонентами ПЗ, включаючи компоненти у вихідному коді, бінарні компоненти і компоненти, що виконуються. Деякі компоненти можуть існувати тільки під час виконання, зв’язування (lіnkіng) або компіляції;

· діаграми застосування (розгортання) (deployment dіagrams). Використовуються для представлення схеми розташування процесорів і пристроїв, задіяних у реалізації системи, а також зображення з’єднань між ними – маршрутів передачі інформації.

Розглянемо більш докладно діаграми класів та діаграми станів.

Дата добавления: 2014-01-07