- •Лекція 1. Тема: ядра знань swebok
- •1.1. Аналіз і характеристика областей знань swebok
- •1.1.1 Основи програмних вимог (Software Requirements)
- •1.1.2. Проектування пз (Software design)
- •1.1.3. Конструювання пз (Software Construction)
- •1.1.4 Тестування пз (Software Testing)
- •1.1.5 Супровід пз (Software maintenance)
- •1.1.6. Управління конфігурацією пз (Software Configuration Management– scm)
- •1.1.8. Процес інженерії пз (Software Engineering Process)
- •1.1.9. Методи і засоби інженерії пз (Software Engineering Tools and Methods)
- •Лекція 2. Тема: життєвий цикл і етапи розробки програмного забезпечення
- •1.1.7. Управління інженерією пз (Software Engineering Management)
- •Лекція 3. Тема: еволюція моделей життєвого циклу програмного забезпечення
- •1.6. Прискорення розробки пз.
- •Лекція 4. Тема: оцінка якості процесів створення програмного забезпечення
- •Лекція 5. Тема: визначення вихідних даних для проектування програмного забезпечення
- •5.1 Визначення вимог до пз
- •5.2 Формування і аналіз вимог
- •5.2.1 Опорні точки зору
- •5.2.2 Сценарії
- •5.2.3 Етнографічний метод
- •5.3 Специфікація вимог
- •5.4 Атестація вимог
- •5.5 Класифікація програмних продуктів за функціональною ознакою
- •5.6 Основні експлуатаційні вимоги до програмних продуктів
- •5.7 Передпроектні дослідження предметної області
- •Лекція 6. Тема: розробка технічного завдання
- •2. Підстави для розробки
- •3. Призначення
- •4. Вимоги до програми або програмного виробу
- •5. Вимоги до програмної документації
- •1. Вступ
- •2. Підстава для розробки
- •3. Призначення
- •4. Вимоги до програми або програмного виробу
- •4.1. Вимоги до функціональних характеристик
- •Лекція 7. Тема: принципові рішення початкових етапів проектування
- •Контрольні питання і завдання
- •Аналіз вимог і визначення специфікацій програмного забезпечення при структурному підході
- •Лекція 8. Тема: Специфікації програмного забезпечення при структурному підході
- •Flow-форми
- •Діаграми Насси-Шнейдермана
- •Контрольні питання та завдання:
- •Лекція 9. Тема: діаграми потоків даних
- •Словник даних
- •Вміст словника даних
- •Лекція 10. Тема: діаграми «сутність-зв’язок»
- •Лекція 11. Тема: приклади побудови діаграм та специфікації процесів
- •Лекція 12 Тема: діаграми переходів станів
- •13.1. Структурна схема майбутнього програмного забезпечення
- •13.2 Використання методу покрокової деталізації для проектування структури програмного забезпечення
- •13.3 Структурні карти Константайна
- •13.4.Структурні карти Джексона
- •13.5 Характеристики хорошої моделі реалізації
- •Зчеплення
- •Зв’язаність
- •13.6 Функціональна схема
- •Лекція 14. Тема: методології структурного аналізу і проектування
- •Контрольні питання та завдання
- •Лекція 15. Тема: синтаксис діаграм
- •Контрольні питання та завдання
- •Лекція 16. Тема: Синтаксис діаграм
- •Збір інформації
- •Контрольні питання та завдання:
- •Лекція 17. Тема: побудова sadt-діаграм
- •17.2. Побудова sadt-діаграми для процесу “Побудова таблиць/графіків функцій однієї змінної”
- •Типи зв'язків між функціями
- •Лекція 18. Тема: доповнення до діаграм і моделей
- •Критерії оцінки і вибору
- •Функціональні характеристики
- •3. Загальні функції:
Лекція 7. Тема: принципові рішення початкових етапів проектування
На початкових етапах процесу проектування повинні бути прийняті принципові рішення, що багато в чому визначають цей процес, а також якість і трудомісткість розробки. До таких рішень відносять:
• вибір архітектури програмного забезпечення;
• вибір типу призначеного для користувача інтерфейсу і технології роботи з документами;
• вибір підходу до розробки (структурного або об'єктного);
• вибір мови і середовища програмування.
Іншими словами, ці рішення визначають, що проектується, з якими потребами та характеристиками, як і якими засобами.
Частина рішень може бути визначена в технічному завданні, утворивши групу технологічних вимог. Останні повинні бути прийняті якомога раніше, оскільки є початковими даними для процесу проектування.
Вибір архітектури програмного забезпечення.
Архітектурою програмного забезпечення називають сукупність базових концепцій (принципів) його побудови [11]. Архітектура програмного забезпечення визначається складністю вирішуваних завдань, ступенем універсальності програмного забезпечення, що розробляється, і числом користувачів, що одночасно працюють з однією його копією. Розрізняють:
• однокористувацьку архітектуру, при якій програмне забезпечення розраховане на одного користувача, що працює за персональним комп'ютером;
• багатокористувацьку архітектуру, яка розрахована на роботу в локальній або глобальній мережі.
Крім того, в рамках однокористувацької архітектури розрізняють:
• програми;
• пакети програм;
• програмні комплекси;
• програмні системи.
Багатокористувацьку архітектуру реалізують системи, побудовані за принципом «клієнт-сервер».
Програмою називають адресований комп'ютеру набір інструкцій, що точно описує послідовність дій, які необхідно виконати для вирішення конкретного завдання. При структурному підході програми є ієрархією підпрограм, що викликають один одного в процесі рішення поставленої задачі, при об'єктному підході – сукупність об'єктів, що обмінюються повідомленнями, для реалізації яких розроблені спеціальні класи. Програма в цьому випадку є окремо компільованою програмною одиницю, яка може використовувати стандартні бібліотеки підпрограм, але, як правило, не організовує свої. Це найпростіший вид архітектури, який зазвичай використовується при рішенні невеликих завдань.
Пакети програм є сукупністю програм, що вирішують завдання деякої прикладної області. Наприклад, пакет графічних програм, пакет математичних програм. Програми такого пакету зв'язані між собою тільки приналежністю до визначеної прикладної області. Пакет програм реалізують як набір окремих програм, кожна з яких сама вводить необхідні дані і виводить результати. По суті справи пакет програм - це деяка бібліотека програм.
Програмні комплекси є сукупністю програм, що спільно забезпечують вирішення невеликого класу складних завдань однієї прикладної області. Для рішення такої задачі можливо потрібно буде вирішити декілька підзадач, послідовно викликаючи програми комплексу. Виклик програм в програмному комплексі здійснюється спеціальною програмою - диспетчером, який забезпечує нескладний інтерфейс з користувачем і можливо, видачу деякої довідкової інформації. Від пакету програм програмний комплекс відрізняється ще і тим, що декілька програм можуть послідовно або циклічно викликатися для вирішення одного завдання, і, отже, бажано зберігати початкові дані і результати викликів в межах одного призначеного для користувача проекту. Програми в цьому випадку можуть реалізовуватися як окремо, так і як спільно компільовані програмні одиниці, а початкові дані зберігатися в оперативній пам'яті або у файлах.
Програмні системи є організованою сукупністю програм (підсистем), що дозволяє вирішувати широкий клас завдань з деякої прикладної області. На відміну від програмних комплексів програми, що входять в програмну систему взаємодіють через загальні дані. Програмні системи зазвичай мають розвинені користувацький і внутрішні інтерфейси, що вимагає їх ретельного проектування.
Багатокористувацькі програмні системи на відміну від звичайних програмних систем повинні організовувати мережеву взаємодію окремих компонентів програмного забезпечення, що ще ускладнює процес його розробки. Для розробки подібного програмного забезпечення використовують спеціальні технології або платформи, наприклад, технології CORBA, COM, Java і тому подібне/
Вибір типу призначеного для користувача інтерфейсу. Розрізняють чотири типи призначених для користувача інтерфейсів:
• примітивні - реалізують єдиний сценарій роботи, наприклад, введення даних - обробка - виведення результатів;
• меню - реалізують безліч сценаріїв роботи, операції яких організовані в ієрархічні структури, наприклад, «вставка»: «вставка файлу», «вставка символу» і т. д.;
• з вільною навігацією - реалізують безліч сценаріїв, операції яких не прив'язані до рівнів ієрархії, і припускають визначення безлічі можливих операцій на конкретному кроці роботи; інтерфейси даної форми в основному використовують Windows-додатки;
• прямого маніпулювання - реалізують безліч сценаріїв, представлених в операціях над об'єктами, основні операції ініціюються переміщенням піктограм об'єктів мишею, дана форма реалізована в інтерфейсі самої операційної системи Windows альтернативно інтерфейсу з вільною навігацією.
Тип призначеного для користувача інтерфейсу багато в чому визначає складність і трудомісткість розробки, які істотно зростають в порядку перерахування типів. До 80% програмного коду може реалізовувати саме призначений для користувача інтерфейс [37]. Тому зрозуміло, що на ранніх стадіях навчання програмуванню реалізують в основному примітивні інтерфейси і меню, хоча вони і не зручні для користувачів.
Поява об'єктно-орієнтованих візуальних середовищ розробки програмного забезпечення, що використовують подієвий підхід до програмування і в основному розрахованих на створення інтерфейсів з вільною навігацією, істотно понизило трудомісткість розробки подібних інтерфейсів і спростило реалізацію інтерфейсів прямого
маніпулювання. Таким чином, вибір двох останніх типів інтерфейсів припускає використання одного з візуальних середовищ розробки програмного забезпечення. Якщо відповідні середовища розробникові не доступні, то слід враховувати велику трудомісткість створення подібних інтерфейсів.
Крім того, вибір типу інтерфейсу включає вибір технології роботи з документами.
Розрізняють дві технології:
• однодокументна, яка припускає однодокументний інтерфейс (SDI – Single Document Interface);
• багатодокументна, яка припускає багатодокументний інтерфейс (MDI – Multiple Document Interface).
Багатодокументну технологію використовують, якщо програмне забезпечення повинне працювати з декількома документами одночасно, наприклад, з декількома текстами або декількома зображеннями. Однодокументну - якщо одночасна робота з декількома документами не обов'язкова.
Трудомісткість реалізації багатодокументних інтерфейсів з використанням сучасних бібліотек приблизно на 3...5 % вище, ніж першого. Вибір типу впливає на трудомісткість більш істотно.
Вибір підходу до розробки. Якщо вибраний інтерфейс з вільною навігацією або прямого маніпулювання, то, як указувалося вище, це практично однозначно припускає використання подієвого програмування і об'єктного підходу, оскільки сучасні середовища візуального програмування, такі як Visual C++, Delphi, Builder C++ і подібні до них надають інтерфейсні компоненти саме у вигляді об'єктів бібліотечних класів. При цьому залежно від складності наочної області програмне забезпечення може реалізовуватися як з використанням об'єктів і, відповідно, класів, так і чисто процедурно. Виняток становлять випадки використання спеціалізованих мов розробки Інтернет-додатків, таких як Perl, побудованих по абсолютно іншому принципу.
Примітивний інтерфейс і інтерфейс типу меню сумісні як із структурним, так і з об'єктним підходами до розробки. Тому вибір підходу здійснюють з використанням додаткової інформації.
Практика показує, що об'єктний підхід ефективний для розробки дуже великих програмних систем (більше 100000 операторів універсальної мови програмування) і в тих випадках, коли об'єктна структура наочної області яскраво виражена.
Слід також враховувати, що необхідно обережно використовувати об'єктний підхід при жорстких обмеженнях на ефективність програмного забезпечення, що розробляється, наприклад при розробці систем реального часу. У всіх інших випадках вибір підходу залишається за розробником.
Вибір мови програмування. В більшості випадків жодної проблеми вибору мови програмування реально не існує. Мова може бути визначена:
• організацією, що веде розробку; наприклад, якщо фірма володіє ліцензійним варіантом C++ Builder, то вона вестиме розробки переважно в даному середовищі;
• програмістом, який по можливості завжди використовуватиме добре знайому мову;
• усталеною думкою («всі розробки подібного роду повинні виконуватися на C++ або на Java або на ...») і т. п
Якщо ж все-таки вибір мови реально можливий, то потрібно мати на увазі, що всі існуючі мови програмування можна розділити на наступні групи:
• універсальні мови високого рівня;
• спеціалізовані мови розробника програмного забезпечення;
• спеціалізовані мови користувача;
• мови низького рівня.
У групі універсальних мов безумовним лідером на сьогодні є мова С (разом з C++). Дійсно різні версії С і C++ мають цілий ряд дуже істотних переваг:
• багатоплатформенність - для всіх використовуваних в даний час платформ існують компілятори з мови С і C++;
• наявність операторів, що реалізовують основні структурні алгоритмічні конструкції (умовну обробку, всі види циклів);
• можливість програмування на низькому (системному) рівні з використанням адрес оперативної пам'яті;
• величезні бібліотеки підпрограм і класів.
Все це зробило С і C++ основними мовами, що використовуються для створення операційних систем, і, у свою чергу, служить для них додатковою рекламою. Проте С і C++ мають і серйозні недоліки:
• відсутність повноцінних вбудованих структурних типів даних (існуючі псевдоструктурні типи, що використовують адресну арифметику, недостатньо жорстко визначені, щоб контролювати багато операцій над цими даними, що приводить до великої кількості помилок, що виявляються тільки в процесі відлагодження програми);
• наявність синтаксичних неоднозначностей, які також не дозволяють компілятору контролювати правильність програми;
• обмежений контроль параметрів, що передаються в підпрограму, що також виявляється тільки в процесі відлагодження програми, і тому подібне.
Альтернативою С і C++ серед універсальних мов програмування, що використовуються для створення прикладного програмного забезпечення, на сьогодні є Pascal, компілятори якого через чіткий синтаксис виявляють крім синтаксичних і велику кількість семантичних помилок. Версія Object Pascal, використана в середовищі Delphi, супроводжується професійними бібліотеками класів, що спрощують ведення великих розробок, в тому числі і баз даних, що вимагають використання, що робить Delphi достатньо ефективним середовищем для створення додатків Windows.
Окрім цих мов до групи універсальних належать також Basic, Modula, Ada і деякі інші. Кожна з вказаних мов, так само, як C++ і Pascal, має свої особливості і, відповідно, свою область застосування.
Спеціалізовані мови розробника програмного забезпечення використовують для створення конкретних типів програмного забезпечення. До них відносять:
• мови баз даних;
• мови створення мережевих застосувань;
• мови створення систем штучного інтелекту і так далі.
Спеціалізовані мови користувача зазвичай є частиною професійних середовищ користувача, характеризуються вузькою спрямованістю і розробниками програмного забезпечення не використовуються.
Мови низького рівня дозволяють здійснювати програмування практично на рівні машинних команд. При цьому отримують найоптимальніші, як з погляду часу виконання, так і з погляду об'єму необхідної пам'яті програми. Але ці мови абсолютно не годяться для створення великих програм і, тим більше, програмних систем.
Основна причина - низький рівень абстракцій, якими повинен оперувати розробник, звідки неприпустимо великий час розробки. Істотно і те, що самі мови низького рівня не підтримують принципів структурного програмування, що значно погіршує технологічність програм, що розробляються.
В даний час мови типу Асемблера зазвичай використовують:
• при написанні порівняно простих програм, що взаємодіють безпосередньо з технічними засобами, наприклад драйверів, оскільки в цьому випадку доводиться копітко настроювати відповідне устаткування, переваги мов програмування високого рівня стають неістотними;
• у вигляді вставок в програми на мовах високого рівня, наприклад, для прискорення перетворення даних в циклах з великою кількістю повторень.
Вибір середовища програмування. Середовищем програмування називають програмний комплекс, який включає спеціалізований текстовий редактор, вбудовані компілятор компонувальник, відладчик, довідкову систему і інші програми, використання яких спрощує процес написання і відладки програм.
Останнім часом широкого поширення набули згадувані вище середовища візуального програмування, в яких програміст дістає можливість візуального підключення до програми деяких кодів із спеціальних бібліотек компонентів, що стало можливим з розвитком об'єктно-орієнтованого програмування.
Найчастіше використовуються візуальні середовища Delphi, C++ Builder фірми Borland (Inprise Corporation), Visual C++, Visual Basic фірми Microsoft, Visual Ada фірми IBM і ін.
Між основними візуальними середовищами цих фірм Delphi, C++ Builder і Visual C++ є істотна відмінність: візуальні середовища фірми Microsoft забезпечують нижчий рівень програмування «під Windows». Це є їх перевагою і недоліком. Гідністю - оскільки зменшується вірогідність виникнення «нестандартної» ситуації, тобто ситуації, не передбаченої розробниками бібліотеки компонентів, а недоліком - оскільки це істотно завантажує програміста «рутинною» роботою, від якої позбавлений програміст, що працює з Delphi або C++ Builder. Багато нарікань викликає також інтерфейс Visual C++ також орієнтований на низькорівневе програмування.
У загальному випадку, якщо мова йде про вибір між цими середовищами, то він в значній мірі повинен визначатися характером проекту.
Вибір або формування стандартів розробки. Реальне застосування будь-якої технології проектування вимагає формування або вибору ряду стандартів, які повинні дотримуватися всіма учасниками проекту:
• стандарт проектування;
• стандарт оформлення проектної документації;
• стандарт інтерфейсу користувача.
Стандарт проектування повинен визначати:
• набір необхідних моделей (схем, діаграм) на кожній стадії проектування і ступінь їх деталізації;
• правила фіксації проектних рішень на діаграмах, зокрема правила іменування об'єктів і угоди по термінології, набір атрибутів для всіх об'єктів і правила їх заповнення на кожній стадії, правила оформлення діаграм, включаючи вимоги до форми і розмірів об'єктів;
• вимоги до конфігурації робочих місць розробників, включаючи налаштування операційної системи і потрібних CASE-засобів;
• механізм забезпечення спільної роботи над проектом, у тому числі і правила інтеграції підсистем проекту і аналізу проектних рішень на несуперечність.
Стандарт оформлення проектної документації повинен регламентувати:
• комплектність, склад і структуру документації на кожній стадії;
• вимоги до її змісту і оформлення;
• правила підготовки, розгляду, узгодження і затвердження документів.
Стандарт інтерфейсу користувача повинен визначати:
• правила оформлення екранів (шрифти і колірну палітру), склад і розташування вікон і елементів управління;
• правила користування клавіатурою і мишею;
• правила оформлення текстів допомоги;
• перелік стандартних повідомлень;
• правила обробки реакції користувача.
Всі описані вище проектні рішення істотно впливають на трудомісткість і складність розробки. Тільки після їх ухвалення слід переходити до аналізу вимог і розробки специфікацій проектованого програмного забезпечення.
