Метод низпадаючої розробки структури програми (стр. 1 из 2)
Бердичівський політехнічний коледж
Контрольна робота
з дисципліни “Технологія розробки програмного забезпечення”
(варіант №17)
Виконав: студент групи Пзс-504
Шпак Р.В.
Перевірив: викладач
Тростянський Б.Г.
Бердичів
2007
1. Метод “згори – вниз” розробки структури програми
2. Документація по супроводженню програмних засобів
3. Основні класи інструментальних середовищ розробки і супроводження програмних засобів
4. Практичне завдання
Список використаної літератури
1. Метод “згори – вниз” розробки структури програми
Метод низпадаючої розробки (згори – вниз) полягає в наступному. Як і в попередньому методі спочатку будується модульна структура програми у виді дерева. Потім по черзі програмуються модулі програми, починаючи з модуля самого верхнього рівня (головного), переходячи до програмування якого-небудь іншого модуля тільки в тому випадку, якщо вже запрограмований модуль, який до нього звертається. Після того, як усі модулі програми запрограмовані, виконується їхнє почергове тестування і налагодження в такому ж низпадаючому) порядку. При цьому першим тестується головний модуль програми. При цьому ті модулі, до яких може звертатися головний, заміняються їхніми імітаторами. Після завершення тестування і налагодження головного і будь-якого наступного модуля виробляється перехід до тестування одного з модулів, що у даний момент представлені імітаторами, якщо такі маються. Для цього імітатор обраного для тестування модуля заміняється самим цим модулем і, крім того, додаються імітатори тих модулів, до яких може звертатися обраний для тестування модуль. При такому порядку розробки програми вся необхідна глобальна інформація формується вчасно, тобто ліквідується дуже неприємне джерело прорахунків при програмуванні модулів. Деяким недоліком низпадаючої розробки, що приводить до певних ускладнень при її застосуванні, є необхідність абстрагуватися від базових можливостей використовуваної мови програмування, видумуючи абстрактні операції, що пізніше потрібно буде реалізувати за допомогою виділених у програмі модулів. Однак здатність до таких абстракцій представляється необхідною умовою розробки великих програмних засобів, тому її потрібно розвивати.
Особливістю розглянутих методів висхідної і низпадаючої розробок (які називаються класичними) є вимога, щоб модульна структура програми була розроблена до початку програмування (кодування) модулів. Ця вимога знаходиться в повній відповідності з водоспадним підходом до розробки ПЗ, тому що розробка модульної структури програми і її кодування виконуються на різних етапах розробки ПЗ: перша завершує етап конструювання ПЗ, а друга - відкриває етап кодування.
2. Документація по супроводженню програмних засобів
Документація по супроводу ПЗ описує ПЗ із погляду її розробки. Ця документація необхідна, якщо ПЗ припускає вивчення того, як воно улаштовано (сконструйовано), і модернізацію його програм. Тому в разі потреби модернізації ПЗ до цієї роботи залучається спеціальна команда розроблювачів-супровідників. Цій команді прийдеться мати справу з такою же документацією, що визначала діяльність команди первісних (основних) розроблювачів ПЗ, ( з тією лише різницею, що ця документація для команди розроблювачів-супровідників буде, як правило, чужою (вона створювалася іншою командою). Щоб зрозуміти будову і процес розробки ПЗ, що модернізується, команда розроблювачів-супровідників повинна вивчити цю документацію, а потім внести в неї необхідні зміни, повторюючи в значній мірі технологічні процеси, за допомогою яких створювалося первісне ПЗ.
Документацію по супроводу ПЗ можна розбити на дві групи:
- документація, що визначає будівлю програм і структур даних ПЗ і технологію їхньої розробки;
- документацію, що допомагає вносити зміни в ПЗ.
Документація першої групи містить підсумкові документи кожного технологічного етапу розробки ПЗ. Вона включає наступні документи:
Зовнішній опис ПЗ.
Опис архітектури ПЗ.
Для кожної програми ПЗ, опис її модульної структури, включаючи зовнішню специфікацію кожного включеного в неї модуля.
Тексти модулів обраною мовою програмування.
Документація другої групи містить
Посібник із супроводу ПЗ, що описує особливості реалізації ПЗ (зокрема, труднощі, що довелося переборювати) і як враховані можливості розвитку ПЗ у його будівлі (конструкції). У ньому також фіксуються, які частини ПЗ є апаратно- і программно-залежними.
3. Основні класи інструментальних середовищ розробки і супроводження програмних засобів
Розроблювачам великих програмних засобів приходиться вирішувати дуже специфічні і складні проблеми, особливо, якщо цей ПЗ представляє собою програмну систему нового типу, у погано комп'ютеризованій предметній області. Розробка ПЗ починається з процесу формулювання вимог до нього, на основі яких, виходячи з досить неясних бажань замовника, повинний бути створений документ, що досить точно визначає задачі розроблювачів ПЗ. Цей документ називається зовнішнім описом ПЗ.
Зовнішній опис ПЗ відіграє роль точної постановки задачі, рішення якої повинен забезпечити розроблювальний ПЗ. Більш того, він повинен містити всю інформацію, яку необхідно знати користувачу для застосування ПЗ. Зовнішній опис є вихідним документом для трьох взаємопов’язаних процесів: розробки текстів (для конструювання і кодування) програм, що входять у ПЗ, розробки документації по застосуванню ПЗ і розробки комплекту тестів для тестування ПЗ. Помилки і неточності в зовнішньому описі, у кінцевому рахунку, трансформуються в помилки самого ПЗ і обходяться особливо дорого, по-перше, тому, що вони допускаються на самому ранньому етапі розробки ПЗ, і, по-друге, тому, що вони поширюються на три рівнобіжних процеси. Це вимагає прийняття особливо серйозних заходів для їх попередження. Вихідним документом для розробки зовнішнього опису є технічне завдання на розробку ПЗ, яке узгоджується зацікавленими сторонами і затверджується відповідним чином. Через цей документ передається від замовника (користувача) до розроблювача основна інформація щодо необхідного ПЗ, тому формування цього документа представляє собою досить тривалий і складний ітераційний процес взаємодії між замовником і розроблювачем, з якого і починається етап розробки вимог до ПЗ. Труднощі, що виникають у цьому процесі, зв'язані з тим, що користувачі часто погано представляють, що їм насправді потрібно. Крім того, проблеми, які необхідно відобразити у вимогах, можуть не мати визначеного формулювання, що приводить до поступової зміни розуміння розроблювачами цих проблем. У зв'язку з цим визначенню вимог часто передує процес системного аналізу, у якому з'ясовується, наскільки доцільне замовлене ПЗ, як уплине таке ПЗ на діяльність користувачів і які особливості діяльності користувачів воно повинне враховувати. Іноді буває корисним розробка спрощеної версії необхідного ПЗ, яка називається прототипом ПЗ. Аналіз "пробного" застосування прототипу дозволяє виявити дійсні потреби користувачів і істотно уточнити вимоги до ПЗ.
Зовнішній опис ПЗ поділяють на дві самостійні частини функціональну специфікацію і специфікацію якості ПЗ. У даному випадку під терміном “специфікація” розуміється перелік властивостей та їх значень, які необхідно забезпечити в результаті розробки програмного продукту. Опис поводження ПЗ визначає функції, які повинне виконувати ПЗ, і тому його називають функціональною специфікацієюПЗ. Вимоги до якості ПЗ повинні бути сформульовані так, щоб розроблювачу були зрозумілі якісні показники та їх значення, які йому необхідно досягнути при розробці цього ПЗ. Ця частина зовнішнього опису називається специфікацією якості ПЗ. Звичайно розробка специфікації якості передує розробці функціональної специфікації ПЗ, тому що деякі вимоги до якості ПЗ можуть визначати включення у функціональну специфікацію спеціальних функцій, наприклад, функції захисту від несанкціонованого доступу до деяких об'єктів інформаційного середовища. Таким чином, структуру зовнішнього опису ПЗ можна виразити формулою:
Зовнішній опис ПЗ = визначення вимог
+ специфікація якості ПЗ
+ функціональна специфікація ПЗ
Зовнішній опис визначає, що повинне робити ПЗ і якими зовнішніми властивостями воно повинне володіти, але не відповідає на питання, як забезпечити необхідні зовнішні властивості ПЗ і як це ПЗ повинно бути улаштовано. Зовнішній опис повинний досить точно і повно визначати задачі, які повинні вирішити розроблювачі ПЗ. У той же час він повинен бути зрозумілим користувачем - на його підставі замовником досить часто приймається остаточне рішення про висновок договору на розробку ПЗ. Зовнішній опис відіграє велику роль у забезпеченні необхідної якості ПЗ, тому що специфікація якості ставить для розроблювачів ПЗ конкретні орієнтири, що керують вибором прийнятних рішень при реалізації специфікованих функцій.
4. Практичне завдання
З використанням засобів візуального програмування розробити програму для автоматичного розрахунку значень складної функції:
Приклад файлу форми Delphi6 для табулювання функції:
unit Func_tab;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls, Buttons, Grids, Menus;
type
TForm1 = class(TForm)
Label1: TLabel;
Edit1: TEdit;
Label2: TLabel;
Edit2: TEdit;
Label3: TLabel;
Edit3: TEdit;
StringGrid1: TStringGrid;
BitBtn1: TBitBtn;
Label4: TLabel;
ListBox1: TListBox;
Memo1: TMemo;
BitBtn2: TBitBtn;
Label5: TLabel;
Label6: TLabel;
Label7: TLabel;
MainMenu1: TMainMenu;
N1: TMenuItem;
N2: TMenuItem;