Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Програмна інженерія як фах. Базові поняття програмної інженерії
Інформація про навчальний заклад
ВУЗ:
Національний авіаційний університет
Інститут:
Не вказано
Факультет:
Не вказано
Кафедра:
Не вказано
Інформація про роботу
Рік:
2008
Тип роботи:
Лекція
Предмет:
Інженерія програмного забеспечення
Частина тексту файла (без зображень, графіків і формул):
Дисципліна: Інженерія програмного забезпечення
Модуль №1 " Області знань програмної інженерії. Моделі життєвого циклу для розробки програмних систем "
Тема: Програмна інженерія як фах. Базові поняття програмної інженерії.
Мета
1. Познайомити студентів з досягненнями в галузі програмної інженерії.
2. Вивчити сучасні методи інженерії та використовувати їх на практиці.
3. Освоєння підходів до поведінки менеджерів колективів при виконанні замовлення на розробку комп’ютерних програмних систем.
Зміст
Загальні відомості про дисципліну.
Поняття складності.
Системотехніка обчислювальних систем.
Проектування, конструювання ПЗ.
Супровід, управління інженерією ПЗ.
Домашнє завдання та контрольні питання.
Література
Соммервил И. Инженерия программного обеспечения. – М.: И.Д. «Вильямс», 2002. – 624 с.
Буч Г. Объектно-ориентированний анализ и проектирование с примерами приложений. – М.: ООО «И.Д. Вильямс», 2008. – 720 с.
Бабенко Л.П. Основи програмної інженерії. – К.: Т-во «Знання», КОО, 2001. – 269 с.
Загальні відомості про дисципліну.
Курс – 2 Семестр – 3, 4
Семестр - 3
2 модулі
Модуль №1 "Області знань програмної інженерії. Моделі життєвого циклу для розробки програмних систем"
Модуль №2 "Методи об'єктного аналізу та побудови моделей предметних областей. Прикладні та теоретичні методи програмування"
Лекції – 4(2+3(2= 14 год
Лабораторні заняття – (3(4+6)+(4+6+8)= 36 год
Домашнє завдання – 8 год
МКР - 2+2=4 год
Самостійна робота – 35 год
Ітого: - 97 год
Звітність: диференційований залік
Поняття складності.
Лікар, будівельник і програміст посперечалися про те, чия професія древнє. Лікар помітив: "У Біблії сказано, що Бог створив Еву з ребра Адама. Це міг зробити тільки хірург, тому моя професія сама древня у світі". Його перебив будівельник: "Однак, як сказано в Книзі Буття, ще раніше Бог створив з хаосу спочатку небо, а потім - землю. Це було перше й, безсумнівно, найбільш вражаюче будівництво. Отже, дорогий доктор, ви помиляєтеся. Саме моя професія сама древня у світі". Почувши це, програміст відкинувся на спинку крісла, посміхнувся й запитав довірчим тоном: "Ну а хто ж, по-вашому, створив хаос?"
"Чим складніше система, тим вона уязвимее" [5]. Важко собі представити будівельника, що міркує, а чи не вирити ще один підвальний поверх під уже побудованим стоєтажним будинком. Такий захід було б занадто дорогим і небезпечним. Як не дивно, користувачі програмного забезпечення, не замислюючись, просять робити аналогічні зміни в програмах. Більше того, він уважають, що для програміста це завдання не представляє ніяких труднощів.
Наша нездатність упоратися зі складністю, характерна до програмного забезпечення, приведе до затримок, додаткових витрат і порушень технічного завдання. Таку ситуацію часто називають кризою програмного забезпечення, але, відверто говорячи, хворобу, що триває настільки довго, варто називати нормальним станом. На жаль, ця криза вже привела до марнотратних витрат трудових ресурсів - найдорожчого товару, - і багато можливостей виявилися упущеними. Для того щоб створити нове програмне забезпечення, необхідне користувачам, зовсім не досить просто зібрати команду гарних програмістів. Крім того, у багатьох організаціях велика кількість персоналу змушена відволікатися на підтримку морально застарілих програм. З огляду на прямій і непрямий внесок, що вносить програмне забезпечення в економіку найбільш розвинених країн, а також величезні можливості, що з'являються завдяки інформатизації, варто визнати, що миритися з такою ситуацією більше не можна.
Приклади складних систем
Структура персонального комп'ютера
Персональний комп'ютер - це пристрій середньої складності. Більшість персональних комп'ютерів складається з тих самих основних елементів: центрального процесора (central processor unit - CPU), монітора, клавіатури й зовнішнього запам'ятовувального пристрою, як правило, CD- або DVD-дисководу й жорсткого диска. Кожної із цих компонентів можна, у свою чергу, розкласти на більше дрібні складові частини. Наприклад, центральний процесор звичайно складається з первинної пам'яті, арифметико-логічного пристрою (arithmetic/ logic unit - ALU) і шини, до якої приєднані периферійні пристрої. Кожну із цих частин також можна розкласти на компоненти: арифметико- логічний пристрій складається з регістрів і схем довільного керування (random control logic), які у свою чергу складаються із ще більш простих деталей: вентилів, інверторів і т.д.
Цей приклад демонструє ієрархічну природу складної системи. Нормальна робота персонального комп'ютера забезпечується тільки взаємодією всіх його складових частин. Разом узяті, ці окремі частини утворять логічне ціле. Дійсно, щоб зрозуміти, як працює комп'ютер, необхідно розділити його на компоненти й розглянути їх окремо. Отже, роботу монітора й жорсткого диска можна вивчати незалежно друг від друга. Точно так само можна вивчати арифметико-логічний пристрій, не обертаючи уваги на підсистему первинної пам'яті.
Ієрархія характерна не тільки для складних систем, але й для абстракцій. У розглянутому вище прикладі компонентам персонального комп'ютера відповідають певні поняття, що утворять рівні абстракції. Кожному із цих рівнів відповідає сукупність пристроїв, взаємодія яких забезпечує функціонування компонентів більше високого рівня. Конкретний рівень абстракції можна вибирати, виходячи з певних заздалегідь потреб. Наприклад, для дослідження синхронізації первинної пам'яті доцільно розглянути комп'ютер на рівні вентилів. У той же час цей рівень абстракції неприйнятний, якщо потрібно знайти помилку в електронній таблиці.
Структура рослин і тварин
Ботаніки прагнуть зрозуміти подібність і розходження між рослинами, вивчаючи їхню морфологію, тобто форму й структуру. Рослини - це складні багатоклітинні організми, поводження яких, наприклад, фотосинтез і випар вологи, забезпечується взаємодією різних органів.
Рослини складаються із трьох основних частин - корінь, стебел і листів. Кожна із цих частин має особливу структуру. Наприклад, корінь складається з відростків, волосків, верхівки й чехлика. Аналогічно, вивчаючи зріз аркуша, можна виявити єпидермис, мезофилл і судинну тканину. Кожна із цих структур, у свою чергу, являє собою сукупність кліток. Усередині кожної клітки можна виявити новий рівень складності, що охоплює хлоропласти, ядро й т.д. Як і комп'ютер, рослина являє собою ієрархію певних компонентів, кожний рівень якої характеризується власною складністю.
Всі частини, що ставляться до тому самому рівня абстракції, взаємодіють цілком певним чином. Розглядаючи рослину на вищому рівні абстракції, можна виявити наступну картину. Корінь поглинають із ґрунту воду й мінеральні речовини й передають їхнім стеблам. Стебла доставляють ці речовини листам, які, у свою чергу, за допомогою фотосинтезу роблять із них необхідні живильні елементи.
Між різними рівнями абстракції завжди існує чітка границя. Наприклад, компоненти аркуша спільно забезпечують його функціонування як єдиного цілого й майже не взаємодіють із елементами корінь. Простіше говорячи, між частинами, що ставляться до різних рівнів абстракції, існує чіткий поділ функцій.
У комп'ютері вентилі є елементами як центрального процесора, так і жорсткого диска. У різних частинах рослини також можна знайти загальні структурні елементи. Так Бог заощаджує засобу вираження. Наприклад, клітки служать основними будівельними блоками всіх структур рослини. Зрештою, корінь, стебла й листи рослини складаються саме із кліток. Однак існує безліч різновидів кліток. Наприклад, одні клітки містять хлоропласти, а інших - ні, оболонки одних кліток пропускають воду, а інших - ні, крім того, клітка може бути живий або мертвої.
Вивчаючи морфологію рослини, неможливо виділити окремі частини, відповідальні за якусь одну невелику фазу єдиного великого процесу, наприклад, фотосинтезу. У рослині не існує централізованих частин, що безпосередньо координують діяльність компонентів, що ставляться до більше низьких рівнів. Замість цього в ньому існують окремі частини, що діють як незалежні агенти, кожна з яких має досить складне поводження, що є частиною функцій більше високого рівня. Більше високий рівень функціонування рослини забезпечується тільки завдяки цілеспрямованій взаємодії незалежних агентів. У теорії складності це явище називається похідним поводженням (emergent behaviour): поводження цілого складніше, ніж поводження суми його складових [6].
Звернувшись до зоології, можна з'ясувати, що багатоклітинні тварини, як і рослини, мають ієрархічну структуру: сукупності кліток формують тканини, що утворять органи, групи яких визначають систему (наприклад, травну) і т.д. Тут також проявляється економія засобів вираження, характерна для Бога. Основними цеглинками, з яких складаються як тварини, так і рослини, є клітки. Зрозуміло, клітки рослин і тварин відрізняються друг від друга. Наприклад, клітки рослин укладені у тверду целюлозну оболонку, а клітки тварин - немає. Незважаючи на ці розходження, обидві ці структури, безсумнівно, є клітками. Це явище являє собою приклад спільності різних організмів.
Крім того, у рослинах і тваринах існує величезна кількість механізмів надклітинного рівня. І рослини, і тварини використають судинну систему для транспортування живильних речовин усередині організму, а між індивідуумами того самого виду існують полові розходження.
Структура матерії
Дослідження в таких різних областях, як астрономія і ядерна фізика, дають багато інших прикладів неймовірно складних систем. Ці наукові дисципліни демонструють приклади ієрархічних систем нового типу. Астрономи вивчають галактики, які об'єднані в скупчення. У свою чергу, галактики складаються із зірок, планет і інші небесних тел. Фахівці з ядерної фізики зіштовхуються зі структурною ієрархією фізичних тіл зовсім іншого масштабу. Атоми складаються з електронів, протонів і нейтронів; електрони є елементарними частками, а протони й нейтрони діляться на ще більш дрібні компоненти - кварки.
У цих складних ієрархіях знову виявляються універсальні механізми. Зокрема, у Всесвіті діють усього чотири типи сил: гравітаційна, електромагнітна, сильна й слабка взаємодії. Багато законів фізики, що стосуються цих взаємодій, наприклад, закон збереження енергії й імпульсу, носять універсальний характер, поширюючись як на галактики, так і на кварки.
Структура суспільних інститутів
Як останній приклад складних систем звернемося до суспільних інститутів. Люди поєднуються в групи для рішення завдань, які не можуть бути вирішені індивідуумами. Одні організації є тимчасовими, інші існують протягом декількох поколінь. Ніж крупніше організація, тим отчетливее проявляється її ієрархічна структура. Наприклад, транснаціональні корпорації складаються з компаній, які у свою чергу утворяться підрозділами, що включають у себе філії, якою належать місцеві офіси й т.д. Якщо організація проходить випробування часом, то границі між її частинами можуть змінитися, а потім може виникнути нова, більше стійка ієрархія.
Отношения між різними частинами великої організації нагадують відносини між компонентами комп'ютера, рослини або галактики. У той же час, ступінь взаємодії між співробітниками одного офісу вище, ніж між співробітниками двох різних офісів. Поштовий службовець, наприклад, як правило, не спілкується з виконавчим директором компанії, а в основному контактує зі своїми колегами по поштовій відділення. Однак при цьому різні рівні організації об'єднані загальними механізмами. Так, робота службовця й директора оплачується однієї й тією же фінансовою організацією, причому вони обоє використають загальне встаткування, зокрема, телефонну систему компанії.
Визначення складності програмного забезпечення
Як відомо, не всі системи програмного забезпечення є складними. Існує добре забутий клас додатків, проектованих, розроблювальною, супроводжуваною й використовуваних тим самим людиною, - або починаючим програмістом, або професіоналом, що працює поодинці. Це не виходить, що такі системи погано спроектовані й неелегантні. Тим більше, ніхто не ставить під сумнів кваліфікацію їхніх творців. Просто такі системи, як правило, мають дуже обмежену область застосування й дуже недовго використаються. Як правило, їх простіше замінити новими програмами, чим намагатися повторно використати, переробляти або вдосконалювати. Розробка таких додатків скоріше стомлююча, чим складна, тому вони не представляють для нас інтересу.
Предметом нашого дослідження є проблеми розробки промислового програмного забезпечення. У цій області можна знайти програми, що демонструють самі різні види поводження, наприклад, системи зі зворотним зв'язком, які управляють або управляються подіями фізичного миру при обмежених ресурсах часу й пам'яті; програми, що підтримують цілісність баз даних, що містять сотні тисяч записів і обеспечивающих паралельне відновлення й запити; системи керування й контролю за реальними об'єктами, наприклад, системи керування повітряними або залізничними перевезеннями. Такі системи звичайно використаються досить довго, і згодом від їхнього нормального функціонування починають залежати багато користувачів. У галузі промислового програмування також існують засобу, що спрощують створення додатків у конкретних предметних областях, а також програми, що імітують деякі аспекти людського інтелекту.
Найважливішою особливістю промислової програми є її висока складність. Одному програмістові не під силу вирішити всі проблеми, пов'язані із проектуванням такої системи. Грубо говорячи, складність промислових програм перевищує інтелектуальні можливості окремої людини. На жаль, ця властивість є істотною характеристикою всіх великих систем програмного забезпечення. Слово "істотна" означає, що зі складністю промислових програм можна впоратися, але ігнорувати її не можна.
Чому програмному забезпеченню властива складність?
Брукс затверджує: "Складність програмного забезпечення є істотним, а не випадковою властивістю" [3]. Це пояснюється чотирма причинами: складністю предметної області, труднощами керування розробкою програмного забезпечення, необхідністю забезпечити гнучкість програм, а також складністю опису функціонування дискретних систем.
Складність предметної області
Намагаючись вирішити проблеми за допомогою програмного забезпечення, ми неминуче зіштовхуємося з необхідністю задовольнити безліч різних, іноді взаємовиключних вимог. Розглянемо вимоги, пропоновані до електронної системи багатомоторного літака, комутатору стільникового телефону й автономного робота. Механізми функціонування таких систем уже самі по собі досить складні для розуміння, а якщо додати до цьому додаткові вимоги (часто неявні), такі як зручність, продуктивність, вартість, стійкість і надійність, то складність завдання може стати довільної, про що й попереджав Брукс.
Ця зовнішня складність звичайно породжується "недорозумінням", що існує між користувачами системи і її розробниками, оскільки користувачам дуже важко виразити свої потреби у формі, зрозумілої розроблювач. Іноді користувач дуже смутно уявляє собі, що йому потрібно від майбутньої системи програмного забезпечення. Це не можна назвати провиною користувачів або розробників; просто кожна із цих груп випробовує недолік знань у предметній області іншої групи. Користувачі й розробникі часто по-різному бачать сутність проблеми й пропонують різні способи її рішення. Насправді, навіть якщо користувач точно знає, що йому потрібно, його вимоги дуже важко формалізувати. Як правило, вони описуються в багатотомних документах, проілюстрованих декількома малюнками. Такі документи важко зрозуміти, вони допускають неоднозначну інтерпретацію й дуже часто містять інформацію, що ставиться скоріше до проектування, а не виражають основні вимоги замовника.
Вимоги, пропоновані до системи програмного забезпечення, у процесі розробки часто змінюються. Це ще більше підвищує її складність. Як правило, технічне завдання коректується через те, що в процесі проектування системи постановка завдання поступово уточнюється. Знайомлячи з першими результатами, описаними в проектній документації й реалізованими в прототипах, а також використовуючи систему після її інсталяції, користувачі починають краще розуміти й чіткіше формулювати свої реальні потреби. У той же час, цей процес дозволяють розроблювачам вникнути в предметну область і ставити більше точні питання, що проясняють темні місця проектованої системи.
Оскільки велика система програмного забезпечення завжди пов'язана з інвестуванням засобів, ми не можемо дозволити собі викидати існуючу систему при кожній зміні технічного завдання. Системи згодом еволюціонують, за планом або спонтанно. Іноді цей процес помилково називають супроводом програмного забезпечення. Точніше кажучи, супроводом (maintenance) називається виправлення виявлених помилок, еволюцією (evolution) — реакція на зміну технічних вимог, а збереженням (preservation) — спроба всіма можливими продовжити способами функціонування застарілих і частин, що розпадаються, програмного забезпечення. На жаль, як показує досвід, значна частка ресурсів, виділених на розробку програмних систем, витрачається саме на збереження.
//
Завдання групи проектувальників - створити ілюзію простоти
Труднощі керування проектуванням
Основне завдання розроблювачів програмного забезпечення — створити ілюзію простоти, щоб захистити користувачів від величезної й часто довільної складності проекту. Очевидно, що великий масштаб системи програмного забезпечення не ставиться до її основних достоїнств. Для зменшення розмірів програм винаходяться хитромудрі й потужні методи, що створюють ілюзію простоти й дозволяють повторно використати існуючі коди й проектні рішення. Проте вимоги, пропоновані до системи, часто змушують проектувальників або створювати заново велика кількість програм, або використати існуючий код, адаптуючи його до нових умов. Усього кілька десятиліть назад програми обсягом у кілька тисяч рядків, написані на асемблері, вражали уяву. У цей час нікого не дивують системи програмного забезпечення, розмір яких обчислюється десятками тисяч або навіть мільйонів рядків (причому на мовах високого рівня). Жодна людина ніколи не зможе повністю зрозуміти таку систему. Навіть якщо розкласти її на складові частини, прийде аналізувати сотні, а іноді й тисячі окремих модулів. Такий обсяг робіт під силу лише команді розроблювачів, состав якої в ідеалі повинен бути мінімальним. Незалежно від кількості розроблювачів, перед ними постійно виникають складні проблеми, пов'язані з колективним проектуванням. Чим більше розроблювачів, тим складніше зв'язку між ними й тем сутужніше координувати їхня взаємодія, особливо якщо учасники робіт географічно вилучений друг від друга, що відбувається досить часто. Таким чином, при колективній розробці програмного забезпечення головним завданням керівництва є забезпечення єдності й цілісності проекту.
Необхідність забезпечення гнучкості програм
Будівельні компанії звичайно не мають власного лісового господарства, що поставляло б їм ліс для виробництва пиломатеріалів, і не володіють металургійними заводами, що виготовляють сталеві балки для майбутніх будинків. Однак у програмній індустрії така практика одержала широке поширення. Програмування має граничну гнучкість і дозволяє проектувальникові виражати абстракції будь-якого рівня. Ця гнучкість досить приваблива, оскільки вона спонукує розроблювача самостійно створювати практично всі базові конструкції, з яких складаються абстракції більше високих рівнів. На відміну від будівельної промисловості, у якій існують загальноприйняті вимоги до якості матеріалів, у програмній індустрії таких стандартів майже немає. У результаті проектування програмного забезпечення залишається трудомісткою справою.
Складність опису дискретних систем
Кидаючи м'яч у повітря, ми можемо точно пророчити його траєкторію, тому що в нормальних умовах діють певні фізичні закони. Ми б дуже зачудувалися, якби, кинувши м'яч ледве сильніше, виявили, що на середині шляху він зненацька зупинився й полетів вертикально нагору . У недостатньо налагодженій програмі моделювання польоту м'яча така ситуація цілком можлива.
Усередині великого додатка можуть існувати сотні й навіть тисячі змінних, а також кілька потоків керування. Стан прикладної програми в кожний момент часу описується сукупністю всіх змінних, їхніх поточних значень, адрес і стеків виклику для кожного процесу. Тому що програма виконується на цифрових комп'ютерах, виникає система з дискретними станами. Аналогові системи, такі як рух кинутого м'яча, навпаки, є безперервними. Парнас (Ратаї) затверджує: "Коли ми говоримо, що система описується безперервною функцією, ми маємо на увазі, що в ній немає схованих сюрпризів. Невеликі зміни вхідних параметрів завжди викликають невеликі зміни результатів" [4]. З іншого боку, дискретні системи мають кінцеве число можливих станів. У великих системах спостерігається так званий комбінаторний вибух, що робить це число дуже більшим. Проектуючи системи, розроблювачі, як правило, розділяють їх на компоненти так, щоб одна частина якнайменше впливала на іншу. Однак переходи між дискретними станами неможливо моделювати за допомогою безперервних функцій. Кожна подія, зовнішнє стосовно системи, може перевести її в новий стан, і, більше того, перехід з одного стану в інше не завжди є детермінованим. У найгіршому разі зовнішня подія може ушкодити систему через те, що її творці не передбачили всі можливі варіанти. Якщо в програмному забезпеченні рухової установки корабля виникне переповнення пам'яті, викликане некоректними вхідними даними (як це відбулося один раз у дійсності), наслідки можуть виявитися дуже серйозними. Ще недавно в програмному забезпеченні систем керування метрополітеном, автомобілями, супутниками, повітряним рухом, складами й т.д. спостерігався різкий ріст кількості збоїв. У безперервних системах таке поводження було б малоймовірним, але в дискретних системах будь-яка зовнішня подія може вплинути на будь-яку частину внутрішнього стану системи. Очевидно, це є основним стимулом для інтенсивного тестування систем програмного забезпечення. Проте, за винятком найпростіших систем, що вичерпує тестування провести неможливо. У цей час немає ні математичних інструментів, ні інтелектуальних можливостей для повноцінного моделювання поводження більших дискретних систем. Отже, ми повинні задовольнитися прийнятним рівнем впевненості в їхній правильній роботі.
1.3 П'ять ознак складної системи
Вивчаючи природу складності, ми виділили п'ять ознак, властивих будь-які складній системі.
Ієрархічна структура
Випливаючи роботі Саймона (Simon) і Єндо (Ando), Куртуа (Courtois) затверджує наступне.
Часто складність проявляється у вигляді ієрархії, при цьому складні системи складаються із взаємозалежних підсистем, що мають, у свою чергу, власні підсистеми, і т.д., аж до найнижчого рівня, утвореного елементарними компонентами. [7]
Саймон відзначає: "Той факт, що багато складних систем мають майже розкладену, ієрархічну структуру, є головним чинником, що дозволяє нам зрозуміти, описати й навіть "побачити" такі системи і їхні частини" [8]. Дійсно, схоже на те, що можна зрозуміти лише системи, що мають ієрархічну структуру
Важливо відзначити, що архітектура складних систем залежить як від компонентів, так і від ієрархічних відносин між ними. "Всі системи мають підсистеми, і всі системи є частинами більших систем... Сутність системи визначається відносинами між її частинами, а не частинами як такими" [9].
Архітектура складної системи залежить як від її компонентів, так і від ієрархічних відносин між ними
Відносність вибору елементарних компонентів
Досвід дослідження природи елементарних компонентів складних систем показує наступне.
Як правило, спостерігач довільно вирішує, які компоненти в даній системі вважати елементарними.
Елементарний компонент із погляду одного спостерігача може виявитися на набагато більше високому рівні абстракції з погляду іншого.
Поділ функцій
Саймон називає ієрархічні системи розкладеними (decomposable), оскільки їх можна розділити на идентифицируемие частини, і майже розкладеними (nearly decomposable), тому що їхні складові не є абсолютно незалежними друг від друга. Це приводить нас до наступної загальної властивості всіх складних систем:
Зв'язку усередині компонентів звичайно сильніше, ніж зв'язку між компонентами. Ця обставина дозволяє відокремити "високочастотну" динаміку компонентів, - стосовну до їхньої внутрішньої структури, - від "низькочастотної" динаміки, - стосовної до взаємодії між компонентами" [10].
Це розходження між усередині- і межкомпонентними взаємодіями дозволяє провести поділ функцій (separation of concerns) між частинами системи й вивчати їх окремо.
Загальна структура
Як ми вже відзначали, багато складних систем реалізуються за допомогою ощадливих засобів вираження. Це дозволило Саймону затверджувати наступне.
"Ієрархічні системи звичайно складаються з деяких типів підсистем, по-різному скомбінованих і організованих" [11].
Інакше кажучи, складні системи мають загальну структуру. Це може проявлятися у вигляді повторного використання як дрібних компонентів, наприклад, кліток організму, так і більших структур, таких як судинні системи, наявні й у рослин, і у тварин.
Стійкі проміжні форми
Як відзначалося вище, складні системи еволюціонують у часі. Зокрема, уважається, що "складні системи розвиваються із простих набагато швидше, якщо вони мають стійкі проміжні форми" [12]. Цю думку можна виразити більш ефектно.
"Будь-яка працездатна складна система є підсумком еволюції більше простої працездатної системи... Складна система, розроблена "з нуля", ніколи не працює тому що треба, і ніякі "заплатки" не змусять її працювати правильно. Проектування варто починати із простої працездатної системи" [13].
У процесі еволюції системи об'єкти, що спочатку вважалися складними, стають елементарними компонентами, з яких створюються ще більш складні системи. Більше того, правильні елементарні об'єкти неможливо створити відразу: спочатку з ними необхідно попрацювати, получше вивчити реальне поводження системи й лише потім удосконалити.
2. Системотехніка обчислювальних систем
Ціль дійсної глави - дати введення в і пояснити, чому знання в цій області важливі для фахівців але програмному забезпеченню. Прочитавши цю главу, ви повинні:
розуміти, чому програмне забезпечення все тире застосовується в розробках системотехніки;
знати основні інтеграційні характеристики систем: безвідмовність, продуктивність, надійність і безпека;
розуміти, чому в процесі розробки систем необхідно враховувати оточення, у якому буде працювати система;
мати подання про процеси створення систем і системного забезпечення.
Інтеграційні властивості систем
Система і її оточення
Моделювання систем
Процеси створення систем
Придбання систем
Системотехніка, як технологія створення систем, охоплює процеси створення специфікацій, проектування, розробки, тестування, впровадження й супроводи систем як єдиного цілого. Системотехнік, що займається розробкою обчислювальних систем, не зосереджений тільки на програмному забезпеченні, він приділяє рівну увагу програмному забезпеченню, апаратним засобам і засобам взаємодії з користувачами й системним оточенням. Він повинен думати про ті функції, які буде виконувати система й, властиво, заради яких будується система, а також про взаємодію системи з її оточенням. Фахівець зі створення програмного забезпечення повинен розуміти завдання системотехніки, оскільки виникаючі проблеми часто є результатом рішень, прийнятих системотехніками.
Існує безліч найрізноманітніших визначень поняття "система4, від дуже абстрактних до надзвичайно конкретних. З мого погляду, найбільш удалим визначенням системи буде наступне.
Система - це сукупність взаємодіючих компонентів, що працюють спільно для досягнення певних цілей.
Це визначення охоплює дуже широке коло систем. Наприклад, така проста система, як олівець, складається із двох або декількох "апаратних" компонентів, у той час як система керування польотами може складатися з тисяч апаратних і програмних компонентів плюс оператори, які приймають рішення на основі даних, надаваних інформаційними підсистемами.
Визначальною ознакою системи є те, що властивості й поводження системних компонентів впливають один на одного надзвичайно складним і заплутаним образом. Коректне функціонування кожного системного компонента залежить від функціонування багатьох інших компонентів. Так, операційне забезпечення може виконувати свої функції, якщо тільки працює процесор і відповідні апаратні засоби. Процесор може виконувати обчислення, якщо тільки коректно інстальовані програмні системи, що задають ці обчислення.
Системи часто мають ієрархічну структуру, тобто як компоненти містять інші системи. Наприклад, комп'ютерна система поліції містить географічну інформаційну систему, що пропонує інформацію про місце, де трапилося або може трапитися яку-небудь подію. Системи, які є компонентами інших систем, називаються підсистемами. Визначальна властивість підсистем полягає в тім, що вони можуть функціонувати самостійно, незалежно від тих систем, до складу яких входять. Тому географічну інформаційну систему можна використати також в інших системах. Разом з тим їхнє поводження в складі якої-небудь конкретної системи залежить, звичайно, від взаємодії з іншими підсистемами.
Схибність взаємодії між системними компонентами означає, що система не зводиться просто до суми її складових частин. Вона має певні властивості, які властиві їй саме як цілісній системі. Такі інтеграційні властивості не можуть бути властивостями якої-небудь окремої частини системи. Більше того, вони проявляються тоді, коли система розглядається як єдине ціле. Деякі із цих властивостей можна вивести з аналогічних властивостей окремих підсистем, але частіше вони є комплексним результатом взаємодії всіх підсистем і їх неможливо оцінити, виходячи з аналізу окремих системних компонентів.
Приведемо приклади інтеграційних властивостей.
1. Сумарний розмір системи. Це приклад інтеграційного показника системи, якому можна обчислити, виходячи тільки із властивостей окремих компонентів.
Безвідмовність системи. Ця властивість залежить від безвідмовності окремих компонентів і взаємозв'язку між ними.
Зручність експлуатації системи. Це дуже складне многопараметрическое властивість, що залежить не тільки від програмного забезпечення й апаратних засобів системи, але також від оточення, у якому експлуатується система, і від системних операторів.
У цій книзі основна увага приділяється обчислювальним системам, які складаються з апаратних і програмних компонентів і, як правило, мають підсистеми для взаємодії з людиною. Фахівець із програмного забезпечення повинен знати системотехніку обчислювальних систем, оскільки тут програмний компонент грає дуже важливу роль. Наприклад, в 1969 році для здійснення посадки людини на Місяць у програмі "Аполлон" використалося ПО, що займає всього 10 Мбайт, а ПО космічній станції- 100 Мбайт. Таким чином, технології інженерії програмного забезпечення часто є критичним чинником при розробці складних обчислювальних систем.
2.1. Інтеграційні властивості систем
Як відзначалося вище, інтеграційні властивості систем проявляються тільки тоді, коли система розглядається як єдине ціле. У цьому складається складність прогнозування й оцінки таких властивостей, оскільки іноді можна виміряти показники тільки підсистем, з яких складається комплексна система.
Існує два типи інтеграційних властивостей.
Функціональні властивості, які проявляються тільки тоді, коли система працює як єдине ціле. Наприклад, велосипед має функціональні властивості транспортного засобу тільки тоді, коли зібраний зі своїх компонентів.
Нефункціональні властивості: безвідмовність, продуктивність, безпека й захищеність (обмеження несанкціонованого доступу до системи), які залежать від поводження системи в операційному оточенні. Такі властивості часто критичні для обчислювальних систем, оскільки якщо вони не досягають певного мінімального рівня, то система не буде працездатною. Деякі функції й можливості системи можуть бути не затребувані всіма користувачами, так що система може бути працездатної й без них. Разом з тим система, не надійна або не ефективна у своїх окремих функціях, однаково вважається бракованою.
Щоб проілюструвати складність у визначенні інтеграційних властивостей, розглянемо такий показник системи, як безвідмовність. Це комплексні показники, що завжди варто розглядати на рівні системи, а не її окремих компонентів. Компоненти в системі взаємозалежні, так що збій в одному компоненті може поширитися по всій системі й викликати відповідну реакцію в інших компонентах. Проектувальники систем часто не можуть угадати послідовність поширення збоїв у системі, тому важко оцінити безвідмовність системи тільки на підставі даних про безвідмовність її окремих компонентів.
Існує три тісно зв'язаних між собою фактора, які впливають на загальну безвідмовність системи.
1. Безвідмовність апаратних засобів. Ці показники визначається ймовірністю виходу з ладу окремих апаратних компонентів і часом, необхідним па їхню заміну.
Безвідмовність програмного забезпечення. Це показники роботи компонента ПО без збоїв і помилок. Програмні помилки звичайно не роблять впливу на апаратні засоби системи. Тому система може продовжувати функціонувати навіть тоді, коли ПО видає некоректні результати. Безвідмовність програмного забезпечення докладно розглядається в главах 16 і 17.
Помилки операторів. Оператори, що експлуатують систему, також можуть допускати помилки у своїй діяльності.
Всі перераховані фактори тісно зв'язані між собою. Збої в апаратних засобах можуть породити помилкові сигнали, які потім надходять на вхід програмних компонентів, що, у свою чергу, може привести до непередбаченого поводження програмного забезпечення. Оператори звичайно допускають помилки в позаштатних ситуаціях, коли система поводиться незвичайним образом. Такі ситуації часто породжуються якими-небудь збоями в системі. Неправильних дій оператора, у свою чергу, можуть спровокувати збої й помилки в роботі апаратних засобів, що також може привести до подальшого поширення збійних і помилкових сигналів по системних ланцюгах. Таким чином, невелика помилка, що виникла в одній підсистемі й у принципі легко переборна, може привести до ситуації, що вимагає повного відключення системи.
Безвідмовність системи також залежить від оточення, у якому вона експлуатується. Як вказувалося вище, важко передбачати системне оточення, у якому буде експлуатуватися система. Інакше кажучи, складно описати оточення у вигляді обмежень, які повинні враховуватися при розробці системи. Підсистеми, що становлять цілісну систему, можуть по-різному реагувати на зміни в системному оточенні, тим самим впливаючи на загальну безвідмовність системи самим непередбаченим образом. Внаслідок цього, навіть якщо система є єдиним цілим, буває важко або зовсім неможливо виміряти рівень її безвідмовності.
Допустимо, система призначена для експлуатації при нормальній кімнатній температурі. Для того щоб система могла функціонувати при інших температурних режимах, рє електронні компоненти повинні бути розраховані для роботи в певному температурному інтервалі, скажемо, від 0 до 45°. При виході із цього температурного інтервалу компонента можуть поводитися непередбаченим образом. Тепер припустимо, що система є внутрішньою складовою частиною повітряного кондиціонера. Якщо кондиціонер несправний і жене гаряче повітря через електронні компоненти, то вони, а отже, і вся система можуть вийти з ладу. Якщо кондиціонер працює нормально, то система також повинна працювати нормально. Але внаслідок фізичної замкнутості кондиціонера можуть виникнути непередбачені впливи різних компонентів пристрою один на одного, що також може привести до різних збоїв.
Подібно безвідмовності, інші інтеграційні характеристики (такі, як продуктивність і зручність експлуатації) також важкі для визначення, але можуть бути оцінені в процесі експлуатації системи. Оцінка інших властивостей, наприклад безпеки системи і її захищеності, породжує більші складності. Ці властивості не просто властиві працюючій системі, вони відбивають ті характеристики, які вона не показує. Наприклад, при розробці мір захищеності, де одним з показників є неможливість несанкціонованого доступу до даних, порівняно легко прорахувати всі можливі режими доступу до даних і виключити небажані. Тому оцінити рівень захищеності можна тільки через характеристики системи, властиві їй за замовчуванням. Більше того, система буде вважатися захищеності, що володіє властивістю, доти, поки хто-небудь не зламає її засобу захисту.
2.2. Система і її оточення
Будь-яка система залежить від сигналів, даних або іншої інформації, що надходить на її входи; іншими словами, система функціонує в певному оточенні, що впливає на її функціонування й продуктивність. Іноді оточення можна розглядати як самостійну систему, що складається з безлічі інших систем, які впливають один на одного.
На мал. 2.1 показано кілька систем, об'єднаних у систему життєзабезпечення офісного будинку. Система опалення, електроенергетична система, система висвітлення, системи водопостачання й каналізації й система безпеки є підсистемами будови, що, у свою чергу, також можна розглядати як систему. Будинок розташований на вулиці, що також є системою більше високого рівня. Вулиця буде підсистемою системи міста й т.д. Таким чином, оточення якої-небудь системи саме є системою більше високого рівня. У загальному випадку оточення якої-небудь системи - це композиція її локального оточення й оточення системи більше високого рівня.
Рис. 2.1. Ієрархія систем
Розглянемо систему безпеки, що входить у систему життєзабезпечення будинку (див. мал. 2.1). Її локальне оточення складається з інших систем цього будинку. До оточення системи також необхідно віднести системи, що не входять у систему будинки, але стосовні до системи вулиці й системі міста, включаючи природні природні системи, у тому числі погодну (тобто вплив погодних факторів па систему безпеки).
Приведемо дві основні причини, якими викликана необхідність ураховувати при розробці систем їхнє оточення.
У багатьох випадках система призначена саме для реагування на зміну певних параметрів оточення. Так, система опалення реагує па зміни в навколишнім середовищі, підвищуючи або знижуючи температуру своїх опалювальних приладів. Тут правильне функціонування системи проявляється саме як реакція на зміни параметрів оточення.
Часто якість функціонування системи може залежати від параметрів оточення самим непередбаченим образом. Так, система електропостачання прямо залежить від вуличного оточення будинку. Наприклад роботи, проведені по благоустрої вулиці, по недогляду можуть ушкодити силовий кабель і, отже, вивести з ладу всю систему електропостачання будинку. Або грозовий розряд може індуцировати велики струми в електричній системі, що може порушити її нормальне функціонування.
Крім фізичного оточення (навколишнього середовища), показаного на мал. 2.1, системи можуть перебувати в певних відносинах з організаційним оточенням, що містить у собі правила й процедури, засновані на політичних, економічних і екологічних пріоритетах суспільства. Якщо система побудована без обліку організаційного оточення, вона може не знайти попиту на ринку системних продуктів і буде відкинута користувачами й потенційними споживачами.
На розробку систем впливають як людські, так і організаційні фактори, що входять в оточення системи.
Експлуатаційний фактор. Чи вимагає система внесення змін у робочий процес її експлуатації, залежно від зміни параметрів оточення? Якщо відповідь на це питання позитивний, отже, необхідне навчання персоналу, що експлуатує цю систему. Якщо навчання тривале або персонал може втратити в заробітку, існує ймовірність, що така система буде відкинута підлога ьзовател ями.
Фактор персоналу. Чи може впровадження системи привести до зниження вимог до кваліфікації персоналу або докорінно змінити способи його роботи? Якщо це так, тоді персонал може спробувати протистояти впровадженню системи в їхню організацію. Менеджери середньої ланки, що керують проектами, часто підозрюють, що їхній статус в організації понизиться після впровадження комп'ютерних систем.
Організаційн...
05.12.2012 19:12-
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора