Банк рефератов содержит более 364 тысяч рефератов, курсовых и дипломных работ, шпаргалок и докладов по различным дисциплинам: истории, психологии, экономике, менеджменту, философии, праву, экологии. А также изложения, сочинения по литературе, отчеты по практике, топики по английскому.
Полнотекстовый поиск
Всего работ:
364139
Теги названий
Разделы
Авиация и космонавтика (304)
Административное право (123)
Арбитражный процесс (23)
Архитектура (113)
Астрология (4)
Астрономия (4814)
Банковское дело (5227)
Безопасность жизнедеятельности (2616)
Биографии (3423)
Биология (4214)
Биология и химия (1518)
Биржевое дело (68)
Ботаника и сельское хоз-во (2836)
Бухгалтерский учет и аудит (8269)
Валютные отношения (50)
Ветеринария (50)
Военная кафедра (762)
ГДЗ (2)
География (5275)
Геодезия (30)
Геология (1222)
Геополитика (43)
Государство и право (20403)
Гражданское право и процесс (465)
Делопроизводство (19)
Деньги и кредит (108)
ЕГЭ (173)
Естествознание (96)
Журналистика (899)
ЗНО (54)
Зоология (34)
Издательское дело и полиграфия (476)
Инвестиции (106)
Иностранный язык (62791)
Информатика (3562)
Информатика, программирование (6444)
Исторические личности (2165)
История (21319)
История техники (766)
Кибернетика (64)
Коммуникации и связь (3145)
Компьютерные науки (60)
Косметология (17)
Краеведение и этнография (588)
Краткое содержание произведений (1000)
Криминалистика (106)
Криминология (48)
Криптология (3)
Кулинария (1167)
Культура и искусство (8485)
Культурология (537)
Литература : зарубежная (2044)
Литература и русский язык (11657)
Логика (532)
Логистика (21)
Маркетинг (7985)
Математика (3721)
Медицина, здоровье (10549)
Медицинские науки (88)
Международное публичное право (58)
Международное частное право (36)
Международные отношения (2257)
Менеджмент (12491)
Металлургия (91)
Москвоведение (797)
Музыка (1338)
Муниципальное право (24)
Налоги, налогообложение (214)
Наука и техника (1141)
Начертательная геометрия (3)
Оккультизм и уфология (8)
Остальные рефераты (21692)
Педагогика (7850)
Политология (3801)
Право (682)
Право, юриспруденция (2881)
Предпринимательство (475)
Прикладные науки (1)
Промышленность, производство (7100)
Психология (8692)
психология, педагогика (4121)
Радиоэлектроника (443)
Реклама (952)
Религия и мифология (2967)
Риторика (23)
Сексология (748)
Социология (4876)
Статистика (95)
Страхование (107)
Строительные науки (7)
Строительство (2004)
Схемотехника (15)
Таможенная система (663)
Теория государства и права (240)
Теория организации (39)
Теплотехника (25)
Технология (624)
Товароведение (16)
Транспорт (2652)
Трудовое право (136)
Туризм (90)
Уголовное право и процесс (406)
Управление (95)
Управленческие науки (24)
Физика (3462)
Физкультура и спорт (4482)
Философия (7216)
Финансовые науки (4592)
Финансы (5386)
Фотография (3)
Химия (2244)
Хозяйственное право (23)
Цифровые устройства (29)
Экологическое право (35)
Экология (4517)
Экономика (20644)
Экономико-математическое моделирование (666)
Экономическая география (119)
Экономическая теория (2573)
Этика (889)
Юриспруденция (288)
Языковедение (148)
Языкознание, филология (1140)

Контрольная работа: Характеристика якості програмних засобів

Название: Характеристика якості програмних засобів
Раздел: Рефераты по информатике, программированию
Тип: контрольная работа Добавлен 11:43:14 15 сентября 2009 Похожие работы
Просмотров: 36 Комментариев: 16 Оценило: 3 человек Средний балл: 5 Оценка: неизвестно     Скачать

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

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

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

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

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

Горпинич О.О.

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

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

м. Бердичів

2007 р

Зміст

1. Поняття якості програмних засобів.

2. Основні поняття і принципи відладки та тестування програм.

3. Особливості об’єктного підходу на етапі конструювання програмних засобів.

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

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

1. Поняття якості програмних засобів

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

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

- функціональність,

·- надійність,

·- легкість застосування,

- ефективність,

·- супровід,

- мобільність.

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

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

Легкість застосування - це характеристики ПЗ, що дозволяють мінімізувати зусилля користувача по підготовці вхідних даних, застосуванню ПЗ і оцінці отриманих результатів.

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

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

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

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

2. Основні поняття і принципи відладки та тестування програм

Успіх налагодження ПЗ у значній мірі визначає раціональна організація тестування. При налагодженні ПЗ відшукуються й усуваються, в основному, ті помилки, наявність яких у ПЗ установлюється при тестуванні. Як було уже відзначене, тестування не може довести правильність ПЗ, у кращому випадку воно може продемонструвати наявність у ньому помилки. Іншими словами, не можна гарантувати, що тестуванням ПЗ практично здійсненним набором тестів можна установити наявність кожної наявної в ПЗ помилки. Тому виникає дві задачі. Перша задача: підготувати такий набір тестів і застосувати до них ПЗ, щоб знайти в ньому по можливості більше число помилок. Однак чим довше продовжується процес тестування (і налагодження в цілому), тим більшої стає вартість ПЗ. Звідси друга задача: визначити момент закінчення налагодження ПЗ (чи окремого його компонента). Ознакою можливості закінчення налагодження є повнота охоплення пропущеними через ПЗ тестами (тобто тестами, до яких застосоване ПЗ) безлічі різних ситуацій, що виникають при виконанні програм ПЗ, і відносно рідкий прояв помилок у ПЗ на останньому відрізку процесу тестування. Останнє визначається відповідно до необхідного ступеня надійності ПЗ, зазначеної в специфікації його якості. Для оптимізації набору тестів, тобто для підготовки такого набору тестів, що дозволяв би при заданому їхньому числі (чи при заданому інтервалі часу, відведеному на тестування) виявляти більше число помилок у ПЗ, необхідно, по-перше, заздалегідь планувати цей набір і, по-друге, використовувати раціональну стратегію планування тестів. Проектування тестів можна починати відразу ж після завершення етапу зовнішнього опису ПЗ. Можливі різні підходи до вироблення стратегії проектування тестів, який можна умовно графічно розмістити (див. мал. 9.1) між наступними двома крайніми підходами. Лівий крайній підхід полягає в тім, що тести проектуються тільки на підставі вивчення специфікацій ПЗ (зовнішнього опису, опису архітектури і специфікації модулів). Будівля модулів при цьому ніяк не враховується, тобто вони розглядаються як чорні ящики. Фактично такий підхід вимагає повного перебору всіх наборів вхідних даних, тому що в противному випадку деякі частини програм ПЗ можуть не працювати при пропуску будь-якого тесту, а це значить, що помилки, що містяться в них, не будуть виявлятися. Однак тестування ПЗ повною безліччю наборів вхідних даних практично нездійсненно. Правий крайній підхід полягає в тім, що тести проектуються на підставі вивчення текстів програм з метою протестувати всі шляхи виконання кожної програм ПЗ. Якщо узяти до уваги наявність у програмах циклів з перемінним числом повторень, то різних шляхів виконання програм ПЗ може виявитися також надзвичайно багато, так що їхнє тестування також буде практично нездійсненно. Оптимальна стратегія проектування тестів розташована усередині інтервалу між цими крайніми підходами, але ближче до лівого краю. Вона включає проектування значної частини тестів по специфікаціях, але вона вимагає також проектування деяких тестів і по текстах програм. При цьому в першому випадку ця стратегія базується на принципах:

· на кожну використовувану функцію - хоча б один тест,

· на кожну область і на кожну границю зміни якої-небудь вхідної величини - хоча б один тест,

· на кожну особливу (виняткову) ситуацію, зазначену в специфікаціях, - хоча б один тест.

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

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);

begin

If Edit1.Text='' Then Exit;

If (Abs(StrToFloat(Edit1.Text))>100000)Then

begin

P3;

Edit1.Text:='';

Edit1.SetFocus;

end;

end;

procedure TForm1.Edit2Exit(Sender: TObject);

begin

If Edit2.Text='' Then Exit;

If (Abs(StrToFloat(Edit2.Text))>100000)Then

begin

P3;

Edit2.Text:='';

Edit2.SetFocus;

end;

end;

procedure TForm1.Edit3Exit(Sender: TObject);

begin

If Edit3.Text='' Then Exit;

If (StrToFloat(Edit3.Text)>10000)Then

begin

P3;

Edit3.Text:='';

Edit3.SetFocus;

end;

end;

//Основнапроцедурапрограми

Procedure TForm1.BitBtn1Click(Sender: TObject);

var

I,K:integer;

Y :array[0..1000] of Real;

label L1;

begin

//Перевірка наявності правильних значень в полях введення і їх взаємної

//коректності, з виведенням відповдних повідомлень і формуванням переходів

IF (Edit1.Text = '') or (Edit2.Text = '') or(Edit3.Text = '') then

begin

P4;

Exit;

end;

IF Edit3.Text ='0' then

begin

MessageDlg ('Требазадатикроктабулювання,'

+ #13 +' якиймаєненульовезначення', mtWarning, [mbCancel], 0);

Edit3.Text := '';

Edit3.SetFocus;

goto l1;

end;

Xn:=StrToFloat(Edit1.Text);

Xk:=StrToFloat(Edit2.Text);

H:=StrToFloat(Edit3.Text);

If Xk<Xn Then

begin

P1;

goto L1;

end;

If (H<=0) Or (H>=Abs(Xk-Xn)) Then

begin

P2;

goto L1;

end;

X:=Xn-H;

K:= Round((Abs((Xk-Xn))/H));

If K>1000 Then

begin

MessageDlg ('Переповненнямасивуданих.'

+#13 +'Требазменшитиінтервалабо'

+#13 +' збільшитикроктабулювання', mtWarning, [mbCancel], 0);

Edit1.Text := '';

Edit2.Text := '';

Edit3.Text := '';

goto l1;

end;

//Фомування компонентів для виведення результатів

StringGrid1.RowCount:= K+2;

Form1.Height:=430;

Form1.Position:=poScreenCenter;

Label4.Visible:=True;

Label5.Visible:=True;

Label6.Visible:=True;

Label7.Visible:=True;

StringGrid1.Visible:=True;

Label7.Caption:='уполі memo';

ListBox1.Items.Clear;

Memo1.Lines.Clear;

ListBox1.Visible:=True;

Memo1.Visible:=True;

StringGrid1.Cells[0,0]:='X';

StringGrid1.Cells[1,0]:='Y';

//Розрахуноківиведеннярезультатів

For I:=0 to K do

begin

Y[I]:=(1+ln(2-Xn+H*I))/(1-Xn+H*I+0.1);

//Наступний рядок забезпечує виведення результату

// з точністю до тисячних

Y[I]:= Round(Y[I]*1000)/1000;

StringGrid1.Cells[0,I+1]:=FloatToStr(Xn+H*I);//Виведенняутаблицю

StringGrid1.Cells[1,I+1]:=FloatToStr(Y[I]);

ListBox1.Items.Add(FloatToStr(Xn+H*I)+' '+FloatToStr(Y[i])); //Виведенняусписок

Memo1.Lines.Add(FloatToStr(Xn+H*I)+' '+FloatToStr(Y[i])); //ВиведенняуполеМемо

end;

l1:;

end;

//Запис результатів у файл

procedure TForm1.BitBtn2Click(Sender: TObject);

begin

ListBox1.Items.SaveToFile('result.txt');

end;

//Збереженняуфайлі

procedure TForm1.N4Click(Sender: TObject);

begin

ListBox1.Items.SaveToFile(fname);

end;

//Зчитати з файла і вивести у поле Мемо із скриттям зайвих компонентів

procedure TForm1.N3Click(Sender: TObject);

begin

If FileExists('result.txt')= False Then

Begin

MessageDlg('Файланеіснує', mtWarning, [mbCancel], 0);

Exit;

end;

Label7.Visible:=True;

Label7.Caption :='Результатизчитуваннязфайлу';

Memo1.Lines.LoadFromFile('result.txt');

Memo1.Visible:=True;

Label4.Visible:=False;

Label5.Visible:=False;

Label6.Visible:=False;

ListBox1.Visible:=False;

StringGrid1.Visible:=False;

Form1.Height:=430;

Memo1.SetFocus;

Form1.Position:=poScreenCenter;

end;

//Створенняфайлузперевіркоюйогоіснування

procedure TForm1.FormActivate(Sender: TObject);

begin

fname:='result.txt';

AssignFile (f, fname);

If FileExists('result.txt')= False Then

begin

rewrite(f);

CloseFile(f);

end;

end;

//Очищенняполіввведення

procedure TForm1.BitBtn3Click(Sender: TObject);

begin

P5;

end;

procedure TForm1.N5Click(Sender: TObject);

begin

P5;

end;

//Вихід з програми

procedure TForm1.N7Click(Sender: TObject);

begin

Close;

end;

//Виведеннядовідки

procedure TForm1.N8Click(Sender: TObject);

begin

ShowMessage(ГорпиничО.О. + #13 + ' студентгрупипзс-504');

end;

procedure TForm1.N9Click(Sender: TObject);

begin

ShowMessage('Навчальнапрограматабулюванняфункції.' + #13 +

' Версія 1.0');

end;

end.

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

1. В. Турский. «Методология программирования».

2. Б.Іванов “Дискретная математика. Алгоритмы и программы”.

3. Конспект лекцій з предмету.

4. Інтернет мережа..

Оценить/Добавить комментарий
Имя
Оценка
Комментарии:
Делаю рефераты, курсовые, контрольные, дипломные на заказ. Звоните или пишите вотсап, телеграмм, вайбер 89675558705 Виктория.
08:22:42 18 октября 2021
Срочная помощь учащимся в написании различных работ. Бесплатные корректировки! Круглосуточная поддержка! Узнай стоимость твоей работы на сайте 64362.ru
11:18:04 11 сентября 2021
Привет студентам) если возникают трудности с любой работой (от реферата и контрольных до диплома), можете обратиться на FAST-REFERAT.RU , я там обычно заказываю, все качественно и в срок) в любом случае попробуйте, за спрос денег не берут)
Olya14:12:28 25 августа 2019
.
.14:12:27 25 августа 2019
.
.14:12:26 25 августа 2019

Смотреть все комментарии (16)
Работы, похожие на Контрольная работа: Характеристика якості програмних засобів

Назад
Меню
Главная
Рефераты
Благодарности
Опрос
Станете ли вы заказывать работу за деньги, если не найдете ее в Интернете?

Да, в любом случае.
Да, но только в случае крайней необходимости.
Возможно, в зависимости от цены.
Нет, напишу его сам.
Нет, забью.



Результаты(286081)
Комментарии (4150)
Copyright © 2005-2021 HEKIMA.RU [email protected] реклама на сайте