Порядок розробки програмного модуля. Атестація програмних засобів

23

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

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

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

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

(варіант №1)

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

Аранчій І. О

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

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

м. Бердичів 2007 р.

Зміст

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

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. "Требования и спецификации в разработке программ" М. Мир, 1984.

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

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

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

5. Інтернет.