Домой	Поиск	Войти	Контакты		Добавить в избранное
					Сделать стартовой

ГЛАВНАЯ

ИНФОБЛОК

НОВОСТИ

ВОЙТИ

КОНТАКТЫ

БОЛЬШАЯ ЛЕНИНГРАДСКАЯ БИБЛИОТЕКА

МЕНЮ

Главная

Технология

Уголовное и уголовно-исполнительное право

Строительство и архитектура

Спорт и туризм

Социология и обществознание

Сельское лесное хозяйство и землепользование

Религия и мифология

Разное

Психология

Производство и технологии

Программирование компьютеры и кибернетика

Начертательная геометрия

Не сортированные

Оккультизм и уфология

Программирование и комп-ры

Экологическое право

Экология

Экономика

Экономико-математическое моделирование

Экономическая география

Финансовый менеджмент финансовая математика

Финансы деньги кредит

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

БОЛЬШАЯ ЛЕНИНГРАДСКАЯ БИБЛИОТЕКА - РЕФЕРАТЫ - Порядок розробки програмного модуля. Атестація програмних засобів

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

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

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

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

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

(варіант №1)

Виконав: студент групи Пзс-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;

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;

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;

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;

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;

procedure TForm1. Edit3Exit (Sender: TObject);

begin

If Edit3. Text='' Then Exit;

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

begin

P3;

Edit3. Text: ='';

Edit3. SetFocus;

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;

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

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. Інтернет.

	НОВОСТИ

Изменения

Прошла модернизация движка, изменение дизайна и переезд на новый более качественный сервер

	СЧЕТЧИК

БОЛЬШАЯ ЛЕНИНГРАДСКАЯ БИБЛИОТЕКА
	© 2010