47567 (Методи розробки структури програми)

_{МІНІСТЕРСТВО} ОСВІТИ УКРАЇНИ

Бердичівський політехнічний коледж

КОНТРОЛЬНА РОБОТА

з дисципліни “Технологія розробки програмного забезпечення”

(варіант №15)

Виконав: студент групи ПЗС-504

Томашов О.В.

Перевірив: викладач

Тростянський Б.Г.

м. Бердичів

2007 р.

Зміст

1. Методи розробки структури програми

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

3. Інструменти комп’ютерної підтримки розробки програмних засобів

4. Практичне завдання

Список використаної літератури

1. Методи розробки структури програми

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

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

функціональну специфікацію модуля (опис функцій, виконуваних цим модулем по кожному з його входів).

Функціональна специфікація модуля будується так само, як і функціональна специфікація ПЗ.

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

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

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

Цю документацію можна розбити на дві групи:

Документи управління розробкою ПЗ.

Документи, що входять до складу ПЗ.

Документи управління розробкою ПЗ керують і протоколюють процеси розробки і супроводу ПЗ, забезпечуючи зв'язок усередині колективу розроблювачів ПЗ і між колективом розроблювачів і менеджерами ПЗ - особами, що керують розробкою ПЗ. Ці документи можуть бути наступних типів:

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

Звіти про використання ресурсів у процесі розробки. Створюються менеджерами.

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

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

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

Користувальницька документація ПЗ (К-документация).

Документація по супроводу ПЗ (С-документація)

3. Інструменти комп’ютерної підтримки розробки програмних засобів

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

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

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

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

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

користувальницький інтерфейс повинний бути однаковим;

користувальницький інтерфейс повинний дозволяти користувачу виправляти власні помилки;

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

В даний час широко поширені командні і графічні користувальницькі інтерфейси.

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

Графічний користувальницький інтерфейс надає користувачу можливості:

звертатися до ПЗ шляхом вибору на екрані придатного графічного чи текстового об'єкта,

одержувати від ПЗ інформацію на екрані у виді графічних і текстових об'єктів,

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

Графічний користувальницький інтерфейс дозволяє

розміщати на екрані безліч різних вікон, у які можна виводити інформацію незалежно;

використовувати графічні об'єкти (піктограмами чи іконки), для позначення різних інформаційних об'єктів чи процесів;

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

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

4. Практичне завдання

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

Приклад файлу форми Delphi6 для табулювання функції:

unit Func_tab;