Міністерство освіти і науки
Міжрегіональна академія управління персоналом
Індекс групи
ІК-8-17-Б1ППі(4.6з)
Тимошенко Олександр Юрійович
Контрольна робота
З дисципліни: Конструювання програмного забезпечення
Прізвище і ініціали викладача: Людвиченко В.О.
Київ – 2021
ЗМІСТ
ВСТУП 2
1. ОСНОВИ КОНСТРУЮВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ. 3
1.1. Місце КПЗ в життєвому циклі програмної системи. 3
1.2. Фундаментальні складові конструювання програмного забезпечення. 7
1.3. Мінімізація складності (Minimizing Complexity) 7
1.4. Очікування змін (Anticipating Changes) 8
1.5. Конструювання з можливістю перевірки (Constructing for Verification) 8
2. СТАНДАРТИ У КОНСТРУЮВАННІ 9
Список використаної літератури 13
ВСТУП
Давно не секрет, що сфера інформаційних технологій є одним із головних драйверів економіки нашої країни. Вона займає третій рядок за обсягом експортної виручки і поступається за цим параметром лише таким «класичним» індустріям, як агро і металургія. Тому для студента напрямку «Інженерія програмного забезпечення» повинні входити поняття про методи ефективного та оптимального в певному сенсі кодування алгоритмів в першу чергу на мовах високого рівня.
В 2018 році програміст повинен генерувати не просто будь-який код, який працює, а і обов’язково володіти якісним стилем програмування, при чому якісно, а також методами документування, застосовувати методи мінімізації коду, проводити ефективний пошук помилок, зокрема не явних, на етапі відладки та вміти якісно тестувати власний програмний продукт.
Розгляданню саме цих питань і присвячені навчально-методичні матеріали, в яких представлений матеріал, що направлений на набуття насамперед практичних навичок ефективного програмування.
1. ОСНОВИ КОНСТРУЮВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ.
1.1. Місце КПЗ в життєвому циклі програмної системи.
Розробка програмного забезпечення (ПЗ) – це складний процес, в який входить багато складових. В загальному випадку це:
визначення проблеми;
вироблення вимог;
створення плану конструювання;
розробка архітектури ПЗ або високорівневе проектування;
детальне проектування;
кодування і налагодження;
блочне тестування;
інтеграційне тестування;
інтеграція;
тестування системи;
корегувальне супроводження.
Термін конструювання програмного забезпечення (software construction) описує детальне створення робочої програмної системи за допомогою комбінації кодування, верифікації (перевірки), модульного тестування (unit testing), інтеграційного тестування та налагодження.
На мал.1 показано місце конструювання як частину кроків серед процесів, що проходять при побудові ПЗ.Мал.1.Конструювання серед процесів побудови ПЗ
Головними компонентами конструювання є кодування та налагодження, однак воно включає і детальне проектування, блочне тестування, інтеграційне тестування та інші процеси.
Іноді конструювання називають "кодуванням" або “програмуванням". Кодування в даному випадку видається не найкращим терміном, так як воно має на увазі механічну трансляцію розробленого плану в команди мови програмування, тоді як конструювання є зовсім не механічним процесом і часто пов’язане з творчістю та аналізом. Сенс слів "конструювання" та "програмування" досить близький.
Дана область знань пов'язана з іншими областями. Найбільш сильний зв'язок існує з проектуванням (Software Design) і тестуванням (Software Testing). Причиною цього є те, що сам по собі процес конструювання програмного забезпечення зачіпає важливі аспекти діяльності з проектування й тестування. Крім того, конструювання відштовхується від результатів проектування, а тестування (у будь-якій своїй формі) передбачає роботу з результатами конструювання. Досить складно визначити межі між проектуванням, конструюванням і тестуванням, тому що всі вони пов'язані в єдиний комплекс процесів життєвого циклу і, в залежності від обраної моделі життєвого циклу і застосовуваних методів (методології), таке розділення може мати різний вигляд.
Хоча ряд операцій з проектування детального дизайну може відбуватися до стадії конструювання, великий обсяг такого роду проектних робіт відбувається паралельно з конструюванням або як його частина. Це є сутність зв'язку з областю знань "Проектування програмного забезпечення".
У свою чергу, протягом всієї діяльності з конструювання, інженери використовують модульне і інтеграційне тестування. Таким чином пов'язана дана галузь знань з "Тестуванням програмного забезпечення".
У процесі конструювання звичайно створюється більша частина активів програмного проекту – конфігураційних елементів (configuration items). Тому в реальних проектах просто неможливо розглядати діяльність по конструюванню у відриві від галузі знань "конфігураційного управління" (Software Configuration Management).
Так як конструювання неможливе без використання відповідного
інструментарію і, ймовірно, дана діяльність є найбільш інструментальнонасиченою, важливу роль у конструюванні грає область знань "Інструменти і методи програмної інженерії" (Software Engineering Tools and Methods).
Безумовно, питання забезпечення якості значимі для всіх галузей знань і етапів життєвого циклу. У той же час, код є основним результуючим елементом програмного проекту. Таким чином, явно напрошується і присутній зв'язок обговорюваних питань з областю знань "Якість програмного забезпечення" (Software Quality).
З пов'язаних дисциплін програмної інженерії (Related Disciplines of Software Engineering) найбільш тісний і природний зв'язок даної галузі знань існує з комп'ютерними науками (computer science). Саме в них, звичайно, розглядаються питання побудови та використання алгоритмів і практик кодування. Нарешті, конструювання стосується і управління проектами (project management), причому, в тій мірі, наскільки діяльність з управління конструюванням важлива для досягнення результатів конструювання.
Мал. 2. Область знань "Конструювання програмного забезпечення"
Далі наведено деякі конкретні задачі, що виникають в процесі розробки ПЗ, пов’язані з конструюванням:
перевірка виконання умов, необхідних для успішного конструювання;
визначення способів подальшого тестування коду;
проектування та написання класів та методів;
створення та присвоєння імен змінних та іменованих констант;
вибір управляючих структур та організації блоків команд;
блочне тестування, інтеграційне тестування і відлагодження власного
коду;
взаємний огляд коду та низькорівневих програмних структур членами
групи;
"шліфування" коду шляхом його ретельного форматування та
коментування;
інтеграція програмних компонентів, створених окремо;
оптимізація коду, яка направлена на підвищення його швидкодії і зниження міри використання ресурсів.
З іншого боку, з видів діяльності, що проходять в процесі розробки ПЗ, до конструювання не відносяться: керування процесом розробки, виробки вимог, розробка високорівневої архітектури програми, проектування інтерфейсу користувача, тестування системи і її супроводження – для кожного з цих пунктів є своя наука.
1.2. Фундаментальні складові конструювання програмного забезпечення.
Фундаментальні основи конструювання програмного забезпечення включають:
Мінімізація складності
Очікування змін
Конструювання з можливістю перевірки
Стандарти у конструюванні
Перші три концепції застосовуються не тільки до конструювання, але й
проектування, і лежать в основі сучасних методологій управління життєвим
циклом програмних систем.
1.3. Мінімізація складності (Minimizing Complexity)
Основною причиною того, чому люди використовують комп'ютери в бізнес цілях, є обмежені можливості людей в обробці і зберіганні складних структур і великих обсягів інформації, зокрема, протягом тривалого періоду часу. Це міркування є однією з основних рушійних сил у конструюванні програмного забезпечення: мінімізація складності. Потреба у зменшенні складності впливає на всі аспекти конструювання і особливо критична для процесів верифікації (перевірки) і тестування результатів конструювання, тобто самих програмних систем.
Зменшення складності у конструюванні програмного забезпечення досягається за допомогою звертання особливої уваги на створення простого коду, який легко читається, іноді на шкоду прагненню зробити його ідеальним (наприклад, з точки зору гнучкості або слідування тим чи іншим уявленням про красу, витонченість коду, вправність тих чи інших прийомів тощо). Це не означає, що повинно обмежуватися застосування тих чи інших розвинених мовних можливостей використовуваних засобів програмування. Мається на увазі "лише" надання більшої значимості читаності коду, простоті тестування, прийнятного рівня продуктивності та задоволенню заданих критеріїв, замість постійного вдосконалення коду, не оглядаючись на терміни, функціональність і інші характеристики та обмеження проекту.
Мінімізація складності досягається, зокрема, за рахунок слідування стандартам, використанням низки специфічних технік кодування і підтримкою практик, спрямованих на забезпечення якості в конструюванні.
1.4. Очікування змін (Anticipating Changes)
Більшість програмних систем змінюються з плином часу. Причин цьому – безліч. Очікування змін є однією з рушійних сил конструювання програмного забезпечення. Програмне забезпечення не є ізольованим від зовнішнього оточення (як системного, так і з точки зору галузі діяльності, для автоматизації задач і проблем якого воно застосовується). Більш того, програмні системи є частиною середовища, що змінюється, і повинні змінюватися разом з нею, а, іноді, і бути джерелом змін самого середовища.
Очікування змін підтримується рядом технік кодування.
1.5. Конструювання з можливістю перевірки (Constructing for Verification)
"Конструювання для перевірки" (а саме такий сенс закладений в оригінальній назві даної підтеми) припускає, що побудова програмних систем повинна вестися таким чином, щоб сама програмна система допомагала вести пошук причин збоїв, будучи прозорою для застосування різних методів перевірки (і, до речі, внесення необхідних змін), як на стадії незалежного тестування (наприклад, інженерами-тестувальниками), так і в процесі операційної діяльності – експлуатації, коли особливо важлива можливість швидкого виявлення та виправлення помилок що виникають.
Серед технік, спрямованих на досягнення такого результату конструювання:
Огляд, оцінка коду (code review)
Модульне тестування (unit-testing)
Структурування коду для і спільно з застосуванням автоматизованих засобів тестування (automated testing)
Обмежене застосування складних або важких для розуміння мовних структур
2. СТАНДАРТИ У КОНСТРУЮВАННІ
Стандарти, які безпосередньо застосовуються при конструюванні, включають:
Комунікаційні методи (наприклад, стандарти форматів документів і оформлення вмісту)
Мови програмування і відповідні стилі кодування (наприклад, Java Language Specification, що є частиною стандартної документації JDK – Java Development Kit і Java Style Guide, що пропонує загальний стиль кодування для мови програмування Java)
Платформи (наприклад, стандарти програмних інтерфейсів для викликів функцій операційного середовища, такі як прикладні програмні інтерфейси платформи Windows – Win32 API, Application Programming Interface або .NET Framework SDK, Software Development Kit)
Інструменти (не в термінах середовищ розробки, але можливих засобів конструювання – наприклад, UML як один зі стандартів для визначення нотацій для діаграм, що представляють структура коду і його елементів або деяких аспектів поведінки коду)
Використання зовнішніх стандартів. Конструювання залежить від зовнішніх стандартів, пов'язаних з мовами програмування, використовуваним інструментальним забезпеченням, технічними інтерфейсами і взаємним впливом конструювання програмного забезпечення та інших галузей знань програмної інженерії (в тому числі, пов'язаних дисциплін, наприклад, управління проектами). Стандарти створюються різними органами, наприклад, консорціумом OMG – Object Management Group (зокрема. Стандарти CORBA, UML, MDA, ...), міжнародними організаціями з стандартизації такими, як ISO/IEC, IEEE, TMF, ..., виробниками платформ, операційних середовищ і т.д. (Наприклад, Microsoft, Sun Microsystems, CISCO, NOKIA, ...), виробниками інструментів, систем управління базами даних і т.п. (Borland, IBM, Microsoft, Sun, Oracle, ...). Розуміння цього факту дозволяє визначити достатній і повний набір стандартів, які застосовуються у проектній команді або організації в цілому.
Кожна програмна система протягом свого існування проходить з певною послідовністю фази або стадії від задуму до його втілення в програми, експлуатацію та вилучення. Така послідовність фаз називається життєвим циклом розробки (Software life cycle processes). На кожній фазі відбувається певна сукупність процесів, кожен з яких породжує певний продукт, використовуючи певні ресурси.
Усі продукти всіх процесів програмної інженерії являють собою певні описи – тексти вимог до розробки, погодження домовленостей, документацію, тексти програм, інструкції з експлуатації тощо.
Головними ресурсами програмної інженерії, які визначають ефективність її розробок, є час і вартість цих розробок.
Різновиди діяльності, котрі становлять процеси життєвого циклу програмної системи, зафіксовано в міжнародному стандарті ISO/IEC 12207 : 1995—0801 : Informational Technology - Software life cycle processes.
Згідно з наведеним стандартом, усі процеси поділено на три групи:
головні процеси;
допоміжні процеси;
організаційні процеси.
До головних процесів віднесено такі:
процес придбання, який ініціює життєвий цикл системи та визначає організацію-покупця автоматизованої системи, програмної системи або сервісу;
процес розроблення, який означає дії організації — розробника програмного продукту;
процес постачання, який означає дії під час передавання розробленого продукту покупцеві;
процес експлуатації, який означає дії з обслуговування системи під час її використання — консультації користувачів, вивчення їхніх побажань тощо;
процес супроводження, який означає дії з керування модифікаціями, підтримки актуального стану та функціональної придатності, інсталяцію та вилучення версій програмних систем у користувача.
У свою чергу, до процесу розроблення входять такі процеси:
інженерія вимог до системи;
проектування;
кодування й тестування.
До допоміжних процесів віднесено ті, що так чи інакше забезпечують якість продукту. Терміном якість продукту позначено сукупність властивостей, які зумовлюють можливість задоволення потреб замовника, котрий сформулював їх у формі вимог на розробку.
До організаційних процесів віднесено менеджмент розробки, створення структури організації, навчання персоналу, визначення відповідальності кожного з учасників процесів життєвого циклу розробки.
Стандарт ISO/IEC 12207:1995 - 0801: Informational Technology - Software life cycle processes є головним чинником визначення змісту діяльності у сфері програмної інженерії, і всі знання, яких потребують професіонали з програмної інженерії, формулюються стосовно процесів, визначених цим стандартом.
Зупинимося докладніше на процесах розробки програмного забезпечення, які в сукупності мають забезпечити шлях від усвідомлення потреб замовника до передавання йому готового продукту. На цьому шляху виділяють низку характерних робіт:
Визначення вимог. Збір та аналіз вимог замовника виконавцем і подання їх у нотації, яка є зрозумілою як для замовника, так і для виконавця.
Проектування. Перетворення вимог до розробки в послідовність проектних рішень щодо способів реалізації вимог: формування загальної архітектури програмної системи та принципів її прив’язки до конкретного середовища функціонування; визначення детального складу модулів кожної з архітектурних компонент.
Реалізація. Перетворення проектних рішень на програмну систему, яка реалізує такі рішення.
Тестування. Перевірка кожного з модулів та способів їхньої інтеграції; тестування програмного продукту в цілому (так звана верифікація); тестування відповідності функцій працюючої програмної системи вимогам (requirements), поставленим до неї замовником (так звана валідація).
Експлуатація та супроводження готової програмної системи.
Список використаної літератури
Основы Программной Инженерии (по SWEBOK). 3. Конструирование програмного обеспечения. http://swebok.sorlik.ru/3_software_construction.html.
Лавріщева К.М. ПРОГРАМНА ІНЖЕНЕРІЯ.–К.– 2008.–319 с
Інформатика: Комп’ютерна техніка. Комп’ютерні технології. Посіб. / За ред. О.І.Пушкаря – К: Видавничий центр “Академія”, 2001. – 696с. (Альма-матер)
Макконнелл С. Совершенный код. Мастер-класс / Пер. с англ.- М.: Издательско-торговый дом "Русская Редакция"; СПб.: Питер, 2005.- 896 стр.: ил.