47560 (572033)

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла

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

Контрольна робота

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

(варіант №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;

N4: TMenuItem;

N5: TMenuItem;

N3: TMenuItem;

N7: TMenuItem;

N8: TMenuItem;

N9: TMenuItem;

BitBtn3: TBitBtn;

procedure BitBtn1Click(Sender: TObject);

procedure Edit1KeyPress(Sender: TObject; var Key: Char);

procedure Edit2KeyPress(Sender: TObject; var Key: Char);

procedure Edit3KeyPress(Sender: TObject; var Key: Char);

procedure Edit1Exit(Sender: TObject);

procedure Edit2Exit(Sender: TObject);

procedure Edit3Exit(Sender: TObject);

procedure BitBtn2Click(Sender: TObject);

procedure N4Click(Sender: TObject);

procedure N3Click(Sender: TObject);

procedure FormActivate(Sender: TObject);

procedure BitBtn3Click(Sender: TObject);

procedure N5Click(Sender: TObject);

procedure N7Click(Sender: TObject);

procedure N8Click(Sender: TObject);

procedure N9Click(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form1: TForm1;

X,Xn,Xk,H:real;//Параметри табулювання

fname:String[25];//

f:textfile;

implementation

{$R *.dfm}

procedure P1;

begin

MessageDlg ('"Xп" не може бути більшим ніж "Хк".' +#13

+'Введіть значення правильно.', mtWarning, [mbCancel], 0);

Form1.Edit1.Text:='';

Form1.Edit2.Text:='';

end;

procedure P2;

begin

MessageDlg ('Крок табулювання "H" не може приймати таких значень.' +#13

+'Введіть значення правильно.', mtWarning, [mbCancel], 0);

Form1.Edit3.Text:='';

end;

procedure P3;

begin

MessageDlg ('Введене значення знаходться за межами допустимого.' +#13

+'Введіть значення правильно.', mtWarning, [mbCancel], 0);

end;

procedure P4;

begin

MessageDlg ('Треба ввести всі дані.', mtWarning, [mbCancel], 0);

end;

procedure P5;

begin

Form1.Edit1.Text:='';

Form1.Edit2.Text:='';

Form1.Edit3.Text:='';

Form1.Edit1.SetFocus;

Form1.Height:=167;

Form1.Position:=poScreenCenter;

Form1.Label4.Visible:=False;

Form1.Label5.Visible:=False;

Form1.Label6.Visible:=False;

Form1.Label7.Visible:=False;

Form1.StringGrid1.Visible:=False;

Form1.ListBox1.Items.Clear;

Form1.Memo1.Lines.Clear;

Form1.ListBox1.Visible:=False;

Form1.Memo1.Visible:=False;

end;

procedure TForm1.Edit1KeyPress(Sender: TObject; var Key: Char);

begin

case Key of

'0'..'9',Chr(8):;

'-': if (pos('-',Edit1.Text)= 0) and (length(Edit1.Text) = 0)

Then Key := '-'

else Key := Chr(0);

',': if pos(',',Edit1.Text)<>0

THen Key := Chr(0);

else Key := Chr(0);

end;

end;

procedure TForm1.Edit2KeyPress(Sender: TObject; var Key: Char);

begin

case Key of

'0'..'9',Chr(8):;

'-': if (pos('-',Edit2.Text)= 0) and (length(Edit2.Text) = 0)

Then Key := '-'

else Key := Chr(0);

',': if pos(',',Edit2.Text)<>0

Then Key := Chr(0);

else Key := Chr(0);

end;

end;

procedure TForm1.Edit3KeyPress(Sender: TObject; var Key: Char);

begin

case Key of

'0'..'9',Chr(8):;

',': if pos(',',Edit3.Text)<>0

Then Key := Chr(0);

else Key := Chr(0);

end;

end;

procedure TForm1.Edit1Exit(Sender: TObject);

Характеристики

Тип файла документ

Документы такого типа открываются такими программами, как Microsoft Office Word на компьютерах Windows, Apple Pages на компьютерах Mac, Open Office - бесплатная альтернатива на различных платформах, в том числе Linux. Наиболее простым и современным решением будут Google документы, так как открываются онлайн без скачивания прямо в браузере на любой платформе. Существуют российские качественные аналоги, например от Яндекса.

Будьте внимательны на мобильных устройствах, так как там используются упрощённый функционал даже в официальном приложении от Microsoft, поэтому для просмотра скачивайте PDF-версию. А если нужно редактировать файл, то используйте оригинальный файл.

Файлы такого типа обычно разбиты на страницы, а текст может быть форматированным (жирный, курсив, выбор шрифта, таблицы и т.п.), а также в него можно добавлять изображения. Формат идеально подходит для рефератов, докладов и РПЗ курсовых проектов, которые необходимо распечатать. Кстати перед печатью также сохраняйте файл в PDF, так как принтер может начудить со шрифтами.

Список файлов ответов (шпаргалок)