Лекція Системне та прикладне пз. Сучасні тех-нології розроблення пз > 1 Системне та прикладне пз



Дата конвертації04.01.2017
Розмір445 b.
ТипЛекція


Лекція 3.1. Системне та прикладне ПЗ. Сучасні тех-нології розроблення ПЗ

  • Лекція 3.1. Системне та прикладне ПЗ. Сучасні тех-нології розроблення ПЗ

  • 3.1.1 Системне та прикладне ПЗ

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


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

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

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



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

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

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

  • Різні ОС (ОС MS-DOS, OC Windows, OC Linux, OC Unix та ін.) використовують ті чи інші можливості обслуговування компонентів комп’ютера і організації діалогу з користувачем. Основними характеристиками ОС є розрядність, а також підтримання багатопроцесорності, багатозадачності та багатокористувацького режиму.



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

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

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



3.1.2. Службове програмне забезпечення

  • 3.1.2. Службове програмне забезпечення

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

  • Найбільш поширені службові програми:

  • 1. Диспетчери файлів (файлові менеджери).

  • 2. Засоби стиснення даних (архіватори).

  • 3. Засоби діагностики.

  • 4. Програми інсталяції (установлення).

  • 5. Засоби комунікації.

  • 6. Засоби перегляду та відтворення.

  • 7. Засоби комп’ютерної безпеки.



3.1.3. Прикладне програмне забезпечення

  • 3.1.3. Прикладне програмне забезпечення

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

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



1. Текстові редактори.

  • 1. Текстові редактори.

  • 2. Текстові процесори.

  • 3. Графічні редактори.

  • 4. Системи керування базами даних (СКБД).

  • 5. Електронні таблиці.

  • 6. Системи автоматизованого проектування.

  • 7. Настільні видавничі системи.

  • 8. Редактори HTML (Web-редактори).

  • 9. Браузери (засоби перегляду Web-документів).

  • 10. Системи автоматизованого перекладу.

  • 11. Інтегровані системи діловодства.

  • 12. Бухгалтерські системи

  • 13. Фінансові аналітичні системи.

  • 14. Експертні системи.

  • 15. Геоінформаційні системи.

  • 16. Системи відеомонтажу.

  • 17. Інструментальні мови та системи програмування.



3.1.4. Сучасні технології розроблення програмного забезпечення

  • 3.1.4. Сучасні технології розроблення програмного забезпечення

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

  • Розрізняють методи, засоби та процедури технології розроблення ПЗ.

  • Методи забезпечують розв’язання таких завдань:

  • планування й оцінювання проекту;

  • аналіз системних та програмних вимог;

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

  • кодування;

  • тестування;

  • супроводження.



Засоби (утиліти) технології розроблення ПЗ потрібні для автоматизованої підтримки методів технології розроблення ПЗ. Для спільного використання утиліти можуть об’єднуватися в системи автоматизованого конструювання ПЗ. Такі системи називають CASE-системами (CASE – Computer Software Engineering – програмна інженерія з комп’ютерною підтримкою).

  • Засоби (утиліти) технології розроблення ПЗ потрібні для автоматизованої підтримки методів технології розроблення ПЗ. Для спільного використання утиліти можуть об’єднуватися в системи автоматизованого конструювання ПЗ. Такі системи називають CASE-системами (CASE – Computer Software Engineering – програмна інженерія з комп’ютерною підтримкою).

  • Процедури є тим, що поєднує методи й утиліти для того, щоб вони забезпечували безперервний технологічний ланцюг розроблення.

  • Процедури визначають:

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

  • формування звітів, форм за відповідними вимогами;

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

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



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

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

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

  • Найдавнішою парадигмою процесу розроблення ПЗ є класичний життєвий цикл (автор Уїнстон Ройс, 1970).

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





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

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

  • Системний аналіз задає функцію кожному елементу в комп’ютерній системі, взаємодію елементів одне з одним. Аналіз починається з визначення вимог до всіх системних елементів та визначення підмножини цих вимог до програми. Необхідність системного підходу явно проявляється, коли формується інтерфейс ПЗ з іншими елементами (апаратурою, людьми, базами даних). На цьому ж етапі починається розв’язання завдань з планування проекту ПЗ. У процесі планування проекту визначаються обсяг проектних робіт та їх ризик, необхідні трудовтрати, формуються завдання і план-графік робіт.



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

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

  • Проектування ґрунтується на створенні:

  • архітектури ПЗ;

  • модульної структури ПЗ;

  • алгоритмічної структури ПЗ;

  • структури даних;

  • вхідного та вихідного інтерфейсів (вхідних та вихідних форм даних).



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

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

  • Кодування полягає у переведенні результатів проектування на текст мовою програмування.

  • Тестування – виконання програми для виявлення дефектів у функціях, логіці та формі реалізації програмного продукту.

  • Супроводження – це внесення змін у ПЗ, що експлуатується. Призначення змін:

  • виправлення помилок;

  • адаптація до змін зовнішнього відносно ПЗ середовища;

  • удосконалення ПЗ відповідно до вимог замовника.



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

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

  • Переваги класичного життєвого циклу: складає план та часовий графік на всіх етапах проекту, упорядковує хід конструювання.

  • Недоліки класичного життєвого циклу: 1) реальні проекти часто потребують відхилення від стандартної послідовності кроків; 2) цикл ґрунтується на точному формулюванні вихідних вимог до ПЗ (що не завжди властиве реальним проектам).

  • Модель швидкого розроблення додатків RAD (Rapid Application Development) – одна з найбільш використовуваних моделей технології розроблення ПЗ (рис. 3.2).





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

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

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

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



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

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

  • Тестування та об’єднання. Це зменшує час на тестування (оскільки численні програмні елементи вже протестовані, хоча нові елементи мають бути також протестовані).

  • Використовувати RAD можна в тому випадку, коли кожна головна функція завершиться за три місяці. Кожна головна функція адресована окремій групі розробників, а потім інтегрується в цілу систему.



Переваги та недоліки RAD:

  • Переваги та недоліки RAD:

  • 1) для великих проектів у RAD необхідні істотні людські ресурси (необхідно створити достатню кількість груп);

  • 2) RAD можна використовувати лише для таких додатків, які можуть бути розбиті на окремі модулі і в яких продуктивність не є критичною величиною;

  • 3) RAD не можливо використовувати в умовах високих технічних ризиків (тобто в разі використання нових технологій).

  • 3.1.5. Спіральна модель

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

  • Спіральна модель – один з найпоширеніших варіантів використання цієї стратегії.

  • Спіральна модель ( Баррі Боем, 1988) ґрунтується на властивостях класичного життєвого циклу, до яких додається новий елемент – аналіз ризику (рис 3.3).





Як показано на рис. 3.3, модель визначає чотири дії, які подано чотирма квадрантами спіралі:

  • Як показано на рис. 3.3, модель визначає чотири дії, які подано чотирма квадрантами спіралі:

  • планування – визначення цілей, варіантів та вимог;

  • аналіз ризику – аналіз варіантів та оцінювання ризи-ку(ів);

  • конструювання – розроблення продукту наступного рівня;

  • оцінювання – оцінювання замовником поточних результатів конструювання.

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



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

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

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



Переваги спіральної моделі:

  • Переваги спіральної моделі:

  • 1) найреальніше (у вигляді еволюції) відображає розроблення ПЗ;

  • 2) дозволяє явно враховувати ризик на кожному витку еволюції розроблення;

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

  • 4) використовує моделювання для зменшення ризику та вдосконалення програмного виробу.

  • Недоліки спіральної моделі:

  • 1) новизна (бракує достатньої статистики ефективності моделі);

  • 2) підвищені вимоги до замовника;

  • 3) ускладнення під час контролю та керування часом розроблення.



Дякую за увагу!!!

  • Дякую за увагу!!!



Каталог: main -> study -> pages
pages -> Мовою називається певний набір символів І правил, що встановлюють способи комбінацій цих символів для запису осмислених повідомлень. У системному програмуванні мовою
pages -> Апаратна залежність операційних систем 5 Апаратна залежність операційних систем
pages -> 1. Танненбаум Г. Архитектура компьютера. – Спб.: изд. «Питер», 2002. – 704с
pages -> Лекція Етапи розроблення програмного забезпечення
pages -> Лекція 5 Методологія rup
pages -> Модуль №4 "Системи програмування"
pages -> Лекція Модель sadt. Побудова функціональної моделі. Ієрархія діаграм


Поділіться з Вашими друзьями:


База даних захищена авторським правом ©pres.in.ua 2019
звернутися до адміністрації

    Головна сторінка