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

Мета:

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

Обладнання: комп’ютери зі встановленими ОС та пакунком офісних програм.

Структура уроку

1. Організаційний момент
2. Актуалізація опорних знань
3. Вивчення нового матеріалу
4. Інструктаж з ТБ
5. Закріплення вивченого матеріалу
6. Підбиття підсумків уроку
7. Домашнє завдання

Хід уроку

1. Організаційний момент
Привітання з учнями. Перевірка присутності і готовності учнів до уроку. Перевірка виконання домашнього завдання. Оголошення теми й мети уроку.

2. Актуалізація опорних знань

1. З якими мовами програмування та в яких програмних середовищах ви працювали?
2. Які алгоритмічні структури ви втілювали?
3. Які ви знаєте етапи реалізації задачі за допомогою комп'ютера?

3. Вивчення нового матеріалу

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

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

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

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

1. Cистемний аналіз.
2. Cистемне програмування — визначення поточних цілей, складання графіків та планів роботи.
3. Cистемне проектування — реальне проектування системи та її частин з метою досягнення оптимальної ефективності.
4. Створення програм математичного забезпечення.
5. Введення системи в дію та її перевірка.
6. Обслуговування системи.

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

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

Наразі існує велика кількість парадигм програмування. Основними серед наявних парадигм програмування вважаються такі:

• імперативне програмування;
• декларативне прогамування;
• об'єктно-орієнтоване програмування.

Метод — це сукупність теоретичних принципів і практичних прийомів, які потрібно застосувати для виконання певної задачі.

Методологія програмування — це об'єднана єдиним філософським підходом сукупність методів, які застосовують у процесі створення програм.

З кожною методологією можна пов'язати деякі характерні для неї атрибути, а саме:

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

Імперати́вне програмува́ння — парадигма програмування, згідно з якою описують процес отримання результатів як послідовність інструкцій зміни стану програми.

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

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

Методи і концепції

• Метод зміни станів полягає у послідовній зміні станів, підтримано концепцією алгоритму.

• Метод управління потоком виконання полягає у покроковому контролі керування, підтримано концепцією потоку виконання.

Обчислювальна модель. Якщо під обчислювачем розуміти сучасний комп'ютер, то його станом будуть значення всіх елементів пам'яті, стан процесора (в тому числі покажчик поточної команди) і всіх пов’язаних пристроїв. Єдина структура даних — послідовність осередків (пар «адреса» — «значення») з лінійно впорядкованими адресами.

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

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

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

Найвідоміші імперативні мови програмування було створено наприкінці 50-х — всередині 70-х років XX століття: Fortran (1954), Algol (1960), Pascal (1970), С (1972).

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

Мови декларативного програмування поділяють на функціональні й логічні.

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


Методи і концепції функціонального програмування

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

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

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

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

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

Найвідомішою мовою функціонального програмування є мова LISP. Мову Lisp (LISt Processing) було запропоновано Джоном Маккарті в 1960 році. Її зорієнтовано на структуру даних у формі списку. Вона дозволяє організувати ефективну обробку великих обсягів текстової інформації.

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

Методи і концепції програмування

• Метод однаковості полягає в однаковому застосуванні механізму логічного доказу до всієї програми.

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

Prolog (від французького PROgrammation LOGique) — це найвідоміша мова логічного програмування. Перше втілення мови здійснили А. Калмерое і Ф. Россель (Франція) в 1972 р. Головне призначення мови — розробка інтелектуальних програм і систем. Prolog — це мова програмування, створена спеціально для роботи з базами знань, заснованими на фактах і правилах (одного з елементів систем штучного інтелекту). У мові втілено механізм пошуку з поверненням.

Об'єтно-орієнтоване програмування (ООП) — це модель програмування, заснована на стверджені того, що програма — це сукупність об’єктів, які взаємодіють між собою. Кожен об’єкт в цій моделі є незалежним, і він здатний отримувати, опрацьовувати дані та відправляти ці дані іншим об’єктам.

Методи і концепції ООП

• Опис поведінки системи в термінах обміну повідомленнями між об'єктами.

• Виділення об'єктів і зв'язків між ними, що підтримано такими концепціями:

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

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

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

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

Обчислювальна модель в явному вигляді підтримує лише одну операцію — надсилання повідомлення одного об'єкта іншому. При цьому:

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

Синтаксис і семантика:

• клас — тип даних для опису об'єктів;
• об'єкт / змінна / процес — представник класу;
• повідомлення — екземпляр класу, призначеного для обміну даними між об'єктами;
• поле / властивість — дані об'єкта.

чисті мови — містять невелику мовну частину і істотну бібліотеку класів — Simula (1962), Smalltalk (1972), Beta (1975), Self (1986), Cecil (1992);
• гібридні мови — з'явилися в результаті впровадження об'єктно-орієнтованих конструкцій в популярні імперативні мови — Ada (1974), C ++ (1983), Object Pascal (1984), Eiffiel (1992);

• урізані мови — з'явилися в результаті видалення з гібридних мов найбільш небезпечних і непотрібних з об'єктно-орієнтованої точки зору конструкцій — Java (1995), C# (2000).

Уніфікований процес розробки програмного забезпечення
Процес розробки програмного забезпечення — це сума різних видів діяльності, необхідних для перетворення вимог користувачів в програмну систему. Уніфікований процес розробки програмного забезпечення є компонентно-орієнтованим. Інакше кажучи, система програм будують на основі програмних компонентів, пов'язаних добре визначеними інтерфейсами. Такий процес засновано на трьох ключових концепціях:

• керування варіантами використання;
• орієнтування на архітектуру;
• є ітеративним та інкрементним.

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

Варіант використання — це частина функціональності системи, необхідна для отримання користувачем значимого для нього, відчутного і вимірного результату. Сума всіх варіантів використання становить модель варіантів використання, яка описує повну функціональність системи.

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

Орієнтування на архітектуру. Поняття архітектури програми включає в себе найбільш важливі статичні і динамічні аспекти системи. Архітектура виростає з вимог до результату. Ці вимоги відображають у варіантах використання. Однак вони також залежать від безлічі інших чинників, таких, як вибір платформи для роботи програми (тобто комп'ютерної архітектури, операційної системи, СУБД, мережних протоколів), доступність готових блоків багаторазового використання, нефункціональні вимоги (наприклад, продуктивність і надійність).

Архітектура програмного проєкту — це структура компонентів програми або системи, їх взаємозв'язку, принципи та настанови для їх проектування і розвитку в часі.

Як пов'язані архітектура і варіанти використання? Кожен продукт має функції і форму. Функції відповідають варіантам використання, а форма — архітектурі. Ми потребуємо у взаємодії між варіантами використання і архітектурою. Реально архітектуру й варіанти використання розробляються паралельно.

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

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

Переваги керованого ітеративного процесу

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

• Зниження ризику непостачання продукту на ринок у заплановані терміни.

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

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

• аналіз і планування вимог;
• проектування;
• побудов;
• впровадження.

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

1. Що система повинна робити для її основних користувачів?
2. Як повинна виглядати архітектура системи?
3. Який план і скільки коштуватиме розробка продукту?

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

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

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

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

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

4. Інструктаж з ТБ
5. Закріплення вивченого матеріалу
Схематично подати основні методології програмування та мови, що їм належать.

6. Підбиття підсумків уроку
Виставлення оцінок.

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

Текст упорядкувала Іванова Поліна Геннадіївна, учителька середньої загальної школи № 128 Дніпровського району міста Києва, під час виконання випускної роботи на курсах підвищення кваліфікації з 10.12.2018 по 14.12.2018.