Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Проектування системи музичної школи
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Не вказано
Факультет:
Не вказано
Кафедра:
Не вказано
Інформація про роботу
Рік:
2009
Тип роботи:
Інші
Предмет:
Системне програмування
Частина тексту файла (без зображень, графіків і формул):
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ “ЛЬВІВСЬКА ПОЛІТЕХНІКА”
Пояснювальна записка
до курсової роботи
з дисципліни:
"Програмування, частина 4. Технологія системного програмування"
На тему : «Проектування системи музичної школи»
Анотація
Курсовий проект з дисципліни "Програмування, частина 4. Програмна інженерія" являється підсумком вивчення даного предмету. Під час роботи над даним проектом студенти повині показавши всі свої набуті знання виконати поставлене перед ними завдання.
Курсовий проект складається з двох частин: перша частина предсталяє собою розробку системи для певної організації чи сфери дільності. В цій частині проводиться аналіз існуючих аналогів, також здійснюється опрацювання вимог потенційних користувачів і розробка самої системи.
В другій частині здійснюється різного роду тестування програмного забезпечення для перевірки його працездатності та ефективності, тобто відповідність його поставленим вимогам.
Зміст
Вступ 4
Завдання 6
1. Вибір життєвого циклу 7
2. Аналіз аналогів 8
3.Моделювання системної архітектури засобами UML
3.1. Аналіз предметної галузі 9
3.2. Розробка архітектури програмного забезпечення 17
4. Тестування програмного забезпечення 18
4.1.Теоретична частина 18
4.2.Тестування "чорної скриньки" 20
4.3.Тестування "білої скриньки" 21
4.4.Перевірка на модель 25
4.5.Тестування на відмову 26
Висновок 27
Список літератури 28
Додаток А
Вступ
При розробці системи для музичної школи була використана уніфікована мова моделювання UML.
Мова UML є інструментом візуального моделювання систем, тому основним за собом її використання вважаються діаграми. Кожна з діаграм віддзеркалює певний аспект системи, а вся множина діаграм - становить структурну основу проекту.
Обєктно-орієнтована методологія опирається на систему діаграм – одиничних описів фрагментів системи. Різні типи діаграм відображають різні аспекти системи. У кожній діаграми є своя мета і своя аудиторія. Моделювання здійснюється як «порівнений спуск» від концептуальної моделі до логічної, а потім до фізичної моделі програмної системи.
В UML інтегровані різноманітні відомі засоби візуального моделювання, які добре зарекомендували себе на практиці, зокрема, забезпечується можливість опису двох визначальних видів об'єктних моделей:
структурних (або статичних) моделей – описується структура сутностей системи, включаючи класи, інтерфейси, відношення, атрибути;
моделей поведінки (або динамічних моделей) – описується поведінка (функціонування) об'єктів системи, включаючи методи, взаємодію, процес зміни станів окремих компонент чи всієї системи.
Надати користувачу засоби візуального моделювання систем різного призначення з акцентацією на можливості їх розробки та отримання документації. (UML містить як абстрактні конструкції для представлення моделей, так і цілком конкретні, які дозволяють описувати деталі реалізації програмних систем).
Забезпечити користувачів засобами розширення та специфікації з метою більш точного опису конкретних предметних областей. (Хоча у більшості випадків для побудови моделей цілком достатньо базових конструкцій UML, все ж в UML уведено механізм розширення базових понять. Крім того, можлива спеціалізація базових понять, шляхом доповнення останніх новими атрибутами чи властивостями).
Підтримувати таку специфікацію моделей, яка, з одного боку, була б незалежною від конкретних мов програмування і, з іншого боку, забезпечувала б потенційні можливості реалізації у таких мовах.
Діаграма UML – це зображення у вигляді графа з вершинами (сутностями) і ребрами (відношеннями).
Основна мета діаграм – візуалізація архітектури розроблюваної системи з різних точок зору.
Діаграма – деякий зріз системи. Звичайно діаграми дають згорнуте представлення елементів, із яких складається розроблювана система. При цьому один і той самий елемент може бути присутнім у декількох (а іноді й в усіх) діаграмах.
При візуальному моделюванні з UML використовуються вісім видів діаграм, кожна з яких може містити елементи певного типу. Типи можливих елементів і Діаграми прецедентів або діаграми використання (use case diagrams). Такі діаграми описують функціональність, яка буде надаватись користувачам системи, котра проектується. Представляються шляхом використання прецедентів та акторів, а також відношень між ними. Набір усіх прецедентів діаграми фактично визначає функціональні вимоги, за допомогою яких може бути сформульоване технічне завдання.
Діаграми класів (class diagrams) описують статичну структуру класів. Дозволяють (на концептуальному рівні) формувати "словник предметної області" та (на рівні специфікацій і рівні реалізацій) визначати структуру класів у програмній реалізації системи. Можуть використовуватись для генерації каркасного програмного коду (в реальній мові програмування).
Для опису динаміки використовуються діаграми поведінки (behavior diagrams), що підрозділяються на
діаграми станів (statechart diagrams);
діаграми діяльності (активності) (activity diagrams);
діаграми взаємодії (interaction diagrams), що у свою чергу підрозділяються на
діаграм послідовності (sequence diagrams);
діаграм кооперації (співробітництва) (collaboration diagrams).
І, нарешті, діаграми реалізації (implementation diagrams) поділяються на
компонентні діаграми· (діаграми компонентів) (component diagrams);
діаграми розгортання· (deployment diagrams).
Спочатку для програмної системи серією діаграм прецедентів визначається її зовнішня функціональність (виділяються всі прецеденти та актори, а також відношення між ними).
Уся подальша робота над проектом має здійснюватись на основі прецедентів: для кожного прецеденту формується опис його динаміки у вигляді серії діаграм взаємодії та діаграм діяльності.
З отриманих описів шляхом виявлення об'єктів, що задіяні в реалізації прецедентів, будуються діаграми класів.
Для визначення поведінки класів із складною динамікою реагування на події можуть формуватись діаграми станів.
Розміщення об'єктів по програмних модулях описується в компонентних діаграмах, а розміщення програмних модулів по вузлах комп'ютерам мережі – у діаграмах розгортання.
Завдання
Метою даного курсового проекту є розробити модель функціонування музичної школи.
Під час розробки першої частини даного проекту моделі потрібно врахувати вимоги всіх користувачів, тобто тих людей, які мають пряме відношення до навчання і організації навчання в цьому закладі. В результаті розроблена модель повина задовільняти вимоги всіх користувачів, забезпечуючи оптимальний навчальний процес, можливість вести реестр груп та статистику їх успішності для забезпечення контролю над ними, можливість організовувати концерти, організовувати і проводити рекламні заходи, співпрацювати з міжнародними організаціями.
В другій частині необхідно провести тестування на відмову, структурне тестування (білого ящика), тестування чорного ящика, та перевірку на модель розробленого програмного забезпечення.
1.Вибір життєвого цикл
При розробці системи для музичної школи для досягнення оптимального результату найбільш підходяшою є модель життєвого циклу при якій була б можливість повернутися на певний попередній етап розробки при винекненні певних помилок, що дало б можливість швидкого їх виправлення (ітераційна модель). В результаті це б дало можливість як найкраще, і як найшвидше виконати поставлене завдання.
Дану модель можна представити в графічному вигляді таким чином:
Рис.1- Графічне зображення моделі життєвого циклу.
Хоча дана модель не є повінстю досконалою, але вона повністю підходить для вирішення поставленої задачі.
2. Аналіз аналогів
Перед початком розробки системи для музичної школи було досліджено існуючі аналоги, які використовуються в сучасних музичних школах для оптимізації навчального процесу.
Проаналізувавши існуючі системні рішення було зроблено висновок, що на сьогоднішній день в Україні не існує такої системи, яка б на основі однієї програмної розробки виконувала б всі поставленні завдання. Так в музичних школах для задоволення потреб всіх користувачів використовується ціла низка програмного забезпечення, а в деяких випадках працівники змушені обходитись без нього. Таким чином кожен з них, для здійснення оптимальної роботи повинен розібратися як працює не одна, а одразу декілька програм. А оскільки більшість працівників в даній сфері є людьми старшого покоління, то це є досить проблематично.
Для ведення обліку учнів і гуртків в більшості випадків використовується програма Microsoft Office Access, з пакету Microsoft Office, або аналоги, що дозволяють створювати бази даних.
Складання розкладів гуртків і розкладу викладачів і досі виконуються спочатку без програмного забезпечення, лише після його повної розробки, він переноситься в електронний вигляд для розповсюдження. Для цього також використовується найрізноманітніше програмне забезпечення.
Для розроблення програмних листівок також використовується найрізноманітніше програмне забезпечення, починаючи від стандартних програм Windows, і закінчуючи Adobe Photoshop та іншими спеціалізованими програмами.
Для обміну даними з міжнародними організаціями, іншими музичними школами, та для розсилання запрошень, також використовуються різноманітні програмні засоби для обробки електронної пошти.
Система, яка є розроблена під час виконання даного курсового проекту повністю перевершує існуючі програмні рішення і є оптимальною для організації роботи музичної школи, адже вона поєднує в одному модулі вирішення всіх поставлених задач.
3.Моделювання системної архітектури засобами UML
3.1. Аналіз предметної галузі
Під час розробки системи для роботи музичної школи спочатку було визначено всіх потенційних користувачів даної системи і визначено всі їх вимоги до даної системи. Таким чином серед прецедентів, які мають відношення до музичної школи можна виділити:
Учня
Викладача
Директора
Організатора концертів
Секритар
Далі було проаналізовано всі їх вимоги від системи, які можна структуризувати наступним чином:
Рис.2- Ієрархія точок зору усіх користувачів системи.
Для графічного відображення вимог кожного користувача системи було використано уніфіковану мову моделювання UML. За допомою якої було створено діаграми прецедентів, що і відображає їх вимоги.
A) Б)
Рис.3 – Діаграми прецедентів: директора (А) і організатора концертів (Б).
А) Б)
В)
Рис.4 – Діаграми прецедентів: учня (А), викладача (Б) і секретаря (В).
На першому періоді розробки системи було визначено місце системи в середовищі:
Рис.5. - Структурна схема моделі системного середовища.
При реалізації системи було змоделювано ряд стандартних процесів, які відбуваються в музичній школі, серед яких можна виділити процес прийняття учня в музичну школу, процес організації концертів, процес формування нових гуртків.
Рис.6 – Модель процесу прийняття учня в музичну школу.
Рис.7- Модель процесу організації концертів.
Рис.8- Модель процесу формування нових гуртків.
При реалізації даної системи використовується ряд баз даних:
Гуртків;
Успішності учнів;
Інвентаря;
Музичних творів;
Концертів;
Викладацького складу;
Учнів.
Кожна база даних зберігає відповідну інформацію, і містить поля за допомогою яких вона звязується з іншими базами даних, що забезпечує можливість реалізації системи.
Для відображення сутності та звязків між базами даних можна використати наступну діаграму:
Рис.9. – Модель сутності баз даних, та звязків між ними.
3.2. Розробка архітектури програмного забезпечення
Наступним етапом в розробці системи є розробка архітектури програмного забезпечення. На цьому етапі визначається структуру системи, та структуру керування та взаємодії складових системи.
Для реалізації структури системи було використано одну із стандартних моделей – модель репозиторій. Яка забезпечує доступ до потрібної інформації кожному користувачу. Всі дані зберігаються на обному більш-менш потужному компютері, що дозволяє централізувати роботу, і економити при виборі параметрів машин клієнтів, що здешевлює реалізацію системи.
Рис.10. Структура системи для роботи музичної школи (модель репозиторій)
Для реалізації системи роботи музичної школи було обрано модель , що керуються подіями. А саме модель передачі повідомлень.
Рис.11- Модель керування.
4. Тестування програмного забезпечення
4.1. Теоретична частина
Тестування програмного забезпечення - це процес аналізу або експлуатації програмного забезпечення з метою виявлення дефектів.
Тестування передбачає "аналіз" або "експлуатацію" програмного продукту. Тестова діяльність, що пов'язана з аналізом результатів розробки програмного забезпечення, називається статичним тестуванням. Воно передбачає перевірку програмних кодів, контроль та перевірку програми без запуску на комп'ютері. Тестова діяльність, що передбачає експлуатацію програмного продукту, називається динамічним тестуванням. Динамічне та статичне тестування доповнюють одне одного.
Мета розробника полягає в тому, щоб зробити програмний код без дефектів, який відповідає призначенню програмного продукту та відповідає вимогам замовника. Мета тестувальника пов'язана з аналізом коду та експлуатації програми, що у результаті повинно призвести до виявлення дефектів, які проявляються під час його інтегрування, конфігурування та виконання в різних середовищах.
Тестування програмного забезпечення виконує дві базові функції: верифікацію та атестацію. Верифікація забезпечує відповідність результатів конкретної фази процесу розробки вимог даної та попередньої стадії. Атестація є гарантією того, що програмний продукт задовольняє системним вимогам.
Програмний продукт є якісним, коли:
під час роботи користувача з програмним продуктом виникає невелика кількість відмов;
програмний продукт надійний, а це означає, що його використання рідко викликало аварійні відмови;
програмний продукт задовольняє вимогам більшості користувачів.
Процес тестування є дуже важливим при розробці програмного забезпечення. Адже на цьому етапі можна ще до введення в експлуатацію виявити помилки в його роботі. На сьогоднішній день цьому процесу приділяють надзвичайно велику увагу всі розробники, адже він допомагає економити і підтримувати імідж фірми.
Тому розроблено велику кількість методів тестування, серед яких :
Тестування на відмову;
Структурне тестування ("білого ящика");
Тестування "чорного ящика";
Перевірка на модель;
Та інші.
Для тестування розробленого програмного забезпечення в даному курсовому проекті будуть використані саме такі методи тестування.
Будь яке тестування повинно складатися з наступних елементів і процесів, тобто виконуватись за наступною схемою:
Рис. 12 – Схема процесу тестування.
4.2.Тестування "чорної скриньки"
При тестуванні "чорної скриньки" (англ. black-box testing), тестер має доступ до ПЗ тільки через ті ж інтерфейси, що й замовник або користувач, або через зовнішні інтерфейси, що дозволяють іншому комп'ютеру або іншому процесу підключитися до системи для тестування.
Для проведення даного тестування було обрано задачу з лабораторної роботи №3.
Завданням якої є вивести всі перестановки чисел 1..n(тобто послідовність довжини n, в якому кожне з цих чисел входить по одному разу )
Вимогами до даної програми є зрозумілість в користуванні, зрозуміле діалогове вікно при введенні даних і виводі результату.
Для проведення тестування було запущено файл lab3.exe.
Було введено розмір послідовності 4 і отримано наступні результати:
Рис.13 – Результат виконання програми.
Аналіз результату. Діалогове вікно для роботи має ряд недоліків: при запуску програми нема опису, що вона повина виконувати, немає відокремлення між введеними даними і результатом роботи. Діалог з користувачем ведеться на трансліті, що не відповідає стандарту і є не зручно для користувача.
В процесі тестування було визначено, що програма працює правильно для різного числового значення вхідних даних.
4.3.Тестування "білої скриньки"
При тестуванні "білої скриньки" (англ. white-box testing, також говорять - прозорого ящика), тести створюються на основі знань про структуру системи і про те, як вона працює і критерії повноти тестування на відсотках елементів коду, які відпрацювали в ході виконання тестів.
Для проведення даного тестування було обрано задачу з лабораторної роботи №3.
Критерії тестування:
Наявність змістовних ”шапок” до файлів
Наявність змістовних ”шапок” до функцій
Відповідність імен функції Венгерській нотації
Відповідність імен змінних Венгерській нотації
Наявність пояснюючих коментарів до коду
Дотримання форматування тексту
Мобільність
Оптимальне функціонування окремих блоків програми.
В процесі виконання тестів було проаналізовано текст програми:
Файл main.cpp
//---------------------------------------------------------------------------
/***************************************************************************
FILE........: main.cpp
AUTHOR......: Borodaty Oleksandr KI21
DESCRIPTION.: File contents classes wich used in main.cpp
FUNCTION....: - void masivu (int nSizeA,int nSizeB,int rnMasivC[1000])
- transposition(int nPos)
NOTES.......: Class CEvklid used for finding of most general divizor
COPYRIGHT...: All rights reserved by Borodaty Oleksandr
HYSTORY.....: DATE COMMENT
----------------------------------------------
24-02-2009 Created-Borodaty
03-03-2009 Add Function masivu - Borodaty
11-03-2009 Modify Function masiv - Borodaty
15-03-2009 Add Function Perestanovka - Borodaty
*****************************************************************************/
/*------------------------IMPORT DECLARATION--------------------------------*/
#include <vcl.h>
#include <stdio.h>
#include <conio.h>
#include <iostream.h>
/*---------------------PUBLIC DECLARATION----------------------------------*/
#include <labs.h>
#pragma hdrstop
//---------------------------------------------------------------------------
#pragma argsused
/*------------------------PUBLIC FUNCTION----------------------------------*/
/****************************************************************************
FUNCTION.......: transposition
DESCRIPTION....: A function prints all the transpositions are possible
ARGUMENTS......: - nPos - current position in array
RETURNS........: None
******************************************************************************/
void transposition
(
int nPos
)
{
int nI; //Counter 1
int nJ; //Counter 2
//Destroys on a monitor, current combination
if (g_nSize == nPos)
{
for(nI = 1; nI <= g_nSize; nI++)
cout << g_nArr[nI];
cout << "\n";
}
else
for(nJ = nPos + 1; nJ <= g_nSize; nJ++)
{
//Changes combination
g_nTransPos = g_nArr[nPos + 1];
g_nArr[nPos + 1] = g_nArr[nJ];
g_nArr[nJ] = g_nTransPos;
transposition(nPos+1); //Causes a recursive function
//Returns combination to the entrance
g_nTransPos = g_nArr[nPos + 1];
g_nArr[nPos + 1] = g_nArr[nJ];
g_nArr[nJ] = g_nTransPos;
}
}
/*****************************************************************************
FUNCTION.......: main
DESCRIPTION....: A main function is for the choice of number of laboratory work
ARGUMENTS......: None
RETURNS........: None
NOTE...........: - If value of nNumber 1-2 it is a number of laboratory work.
- 0 is a program exit
******************************************************************************/
int main()
{
while(g_nNumber != 0)
{
clrscr();
cout << "VVedit nomer labu 1-2\n0 - vuhid \nLaba: ";
cin >> g_nNumber;
switch(g_nNumber) //An operator is conditional for the choice of laboratory work
{
……
case 3: //Laborotary work #3
{
cout << "VVedit rozmir poslidovnosti \n";
cin >> g_nSize;
//Add sequence of numbers
for (g_nCount = 1; g_nCount <= g_nSize; g_nCount++)
g_nArr[g_nCount] = g_nCount;
// Used function transposition
transposition(0);
break;
}
}
if (g_nNumber != 0) //An operator is conditional for verification of conclusion of service report
{
cout << "\nNatusnit lubu klavishu dlya prodovgenja";
getch();
}
}
}
//---------------------------------------------------------------------------
//End of file main.cpp
Файл labs.h
/***************************************************************************
FILE........: labs.h
AUTHOR......: Borodaty Oleksandr KI21
DESCRIPTION.: File contents classes wich used in main.cpp
NOTES.......: Class CEvklid used for finding of most general divizor
COPYRIGHT...: All rights reserved by Borodaty Oleksandr
HYSTORY.....: DATE COMMENT
--------------------------------
24-02-2009 Created-Borodaty
11-03-2009 add globals variables-Borodaty
15-03-2009 add globals variables-Borodaty
****************************************************************************/
/*------------------------------PUBLIC VARIABLES--------------------------*/
int g_nCount,
g_nCount2; //standart counter
int g_nSize; //Standart variable size of array
int g_nTransPos; //Standart variable for Transposition
int g_nSizeA,
g_nSizeB; //Size of array used in Laboratoru#2
int g_nArr[1000]; //Used as result
int g_nNumber=1; //A variable is for determination of number of LR
float g_fltOperandA,
g_fltOperandB; //Temporal operands or Evklid algoritm used in Labaratory#1
Аналіз результату.
1. Змістовні ”шапки” до файлів присутні вони змістовні, виконанні відповідно до вимог, в них містить інформація про назву файла, його призначення, автора і статистика введення змін.
2. Змістовні змістовні ”шапки” до функцій присутні і виконанні відповідно до вимог в них описується назва функції, її призначення, вхідні та вихідні змінні.
3. Всі імена функцій і змінних програми оформлені відповідно до Венгерської нотації,
4. Коментарі в програмі присутні, вони використовуються для пояснення використання кожної змінної і для кращого розуміння роботи програми. Написані вони відповідно до вимог, на міжнародній мові, тобто англійській.
5. Текст програми відформатовано відновідно до вимог.
6. Програма є мобільною і функціонування окремих блоків є оптимальним.
4.4.Перевірка на модель
Метою даного виду тестування є перевірка на правильність виконання поставленої задачі за допомогою додаткової моделі, яка вже відлагоджена і працює правильно. Дане тестування має наступний структурний вигляд:
Рис. 14 – Схема процесу перевірки на модель.
Для проведення тестування в якості системи було використано задачу №1. Завданням якої є знайти суму наступного ряду sum=1/0!+1/1!...1/n!.
В якості моделі для перевірки було використано програму Wise Calculator, яка дозволяє вирішувати різноманітні математичні задачі.
В процесі тестування було здійснено перевірку для 15 різних n, і в 15 з 15 випадків результати виконання і системи і моделі були однаковими, тобто правильність виконання програми становить 100 %.
Нище наведено приклад виконання перевірки для n=4:
Рис. 15 – Результат виконання програми - системи.
Рис. 16 – Результат виконання програми - моделі.
4.5. Тестування на відмову
Для проведення тестування на відмову всі програми, які були розроблені під час виконання лабораторних робіт були поєднанні в один модуль. Повний текст даного модуля наведений в додатку А.
Основними критеріями тестування було дослідження, поведінку як окремих задач програми так і модуль вцілому, при введені різноманітних вхідних даних.
Аналізуючи отриманні результати можна зробити наступний висновок: що як окремі підпрограми так і модуль вцілому є вузькоспеціалізовані, тобто їх легко вивести з ладу вводячи неправильні вхідні дані (наприклад для всіх підпрограм це є введення букв, або введення дробових чисел). При введені неправильних даних немає повідомлення про помилку, а програма просто відмовляється працювати.
Висновок
Під час виконання даного курсового проекту було досягнуто основну його мету, тобто було розроблено модель функціонування системи музичної школи.
При проектуванні архітектури системи було використано мову UML. Перевага її в тому що за допомогою діаграм можна представити практично все що потрібно – при цьому вони є досить зрозумілими для рядового програміста або менеджера проекту. Хоча також є певні недоліки – нема жорсткої стандартизації при розробці певної системи. Це може призвести до того що різними особами окремі моменти на схемі можуть інтерпретуватися по різному. Також відсутність чіткої стандартизації ускладнює вивчення. Але попри все це використання даної мови все ж полегшує процес розробки.
При розробці системи головний акцент робився на автоматизацію процесу роботи музичної школи. Хоча до досконалості ще дуже далеко, оскільки потрібно проводити комплексні дослідження і спостереження, консультуватися у спеціалістів. Тому перед впровадженням потрібно провести детальне тестування і підстрахувати систему людським фактором.
В процесі написання другої частини курсового – проведення тестування програмного забезпечення було досліджено як окремі підсистеми так і модуль вцілому на відповідність їх поставлених вимогах. Для цього було розроблено ряд тестів різноманітного характеру. І було визначено, що дана система, яка була розроблена під час виконання лабораторних робіт не є досконалою в використанні, а є дуже спеціалізованна і привязана до виріщення конкретно поставленого завдання. Хоча вона повністю задовольняє вимоги навчального процесу, адже вона написана відповідно до вимог Венгерській нотації і виконує поставленні завдання.
Список літератури
Рамбо Дж., Якобсон А., Буч Г. «UML: специальный справочник.» - СПб.: Питер, 2002. - 656 с.
Фаулер М., «UML. Основы, 3-е издание / Пер. с англ.» - СПб.: Символ-плюс, 1999. - 192 с.
Дудзяний І.М., «Обєктно-орієнтоване моделювання програмних систем»- Львів, Видавничий центр ЛНУ ім. Івана Франка, 2007.
http://www.refer.org.ua
Коротун Т.М., «Моделі і методи тестування програмних систем», Київ, 2006.
Андон Ф.И. , Коваль Г.И. ,Коротун Т.М, Сус лов В.Ю. «Основы инженерии качества программ ных систем» . – Киев: Академпериодика, 2002. – 504 с.
http://www.uk.wikipedia.org
http://www.kspu.kr.ua
Додаток А
//---------------------------------------------------------------------------
/***************************************************************************
FILE........: main.cpp
AUTHOR......: Borodaty Oleksandr KI21
DESCRIPTION.: File contents classes wich used in main.cpp
FUNCTION....: - void masivu (int nSizeA,int nSizeB,int rnMasivC[1000])
- transposition(int nPos)
- void even_odd(int nSize)
NOTES.......: Class CEvklid used for finding of most general divizor
COPYRIGHT...: All rights reserved by Borodaty Oleksandr
HYSTORY.....: DATE COMMENT
----------------------------------------------
24-02-2009 Created-Borodaty
24-02-2009 Add Factorial- Borodaty
Add Factorial Suma_rady- Borodaty
03-03-2009 Add Function masivu - Borodaty
11-03-2009 Modify Function masiv - Borodaty
15-03-2009 Add Function Perestanovka - Borodaty
28-03-2009 Add Function even_odd - Borodaty
*****************************************************************************/
/*------------------------IMPORT DECLARATION--------------------------------*/
#include <vcl.h>
#include <stdio.h>
#include <conio.h>
#include <iostream.h>
#include <math.h>
/*---------------------PUBLIC DECLARATION----------------------------------*/
#include <labs.h>
#pragma hdrstop
//---------------------------------------------------------------------------
#pragma argsused
/*------------------------PUBLIC FUNCTION----------------------------------*/
FUNCTION.......: Factorial
DESCRIPTION....: Function which calculates value of factorial of number ,
this function utillized as an appendix to function Suma_rady
ARGUMENTS......: - FactN-Maximal number from which it is needed to find a factorial
RETURNS........: - FactK-Value of factorial of number
******************************************************************************/
double Factorial(int nFactN)
{ g_nFactK = 1;
for (g_nCount = 1; g_nCount <= nFactN; g_nCount ++)
g_nFactK *= g_nCount; // Finding of factorial
return(g_nFactK);
}
/****************************************************************************
FUNCTION.......: Suma_rady
DESCRIPTION....: Function which calculates value sum of row of numbers 1/0!+1/1!+
+...+1/N!
ARGUMENTS......:
RETURNS........: - SumY- Sum of numerical row
******************************************************************************/
int Suma_rady()
{
printf("Vvedit kilkist");
scanf("%d", &g_nCount2); // Input parametr "kilkist"
for (g_nCount = 0; g_nCount <= g_nCount2; g_nCount ++)
g_dblSumY += 1 / Factorial(g_nCount); // Finding of sum
printf("Rezultat: y = %f", g_dblSumY); // Out rezult on the screen
return 0;
}
FUNCTION.......: masivu
DESCRIPTION....: Function which calculates the derivates of coefficients of two arrays
ARGUMENTS......: - nSizeA - Size of 1 array
- nSizeB - Size of 2 array
RETURNS........: - rnMasivC - Result of derivative coefficients
******************************************************************************/
void masivu
(
int nSizeA,
int nSizeB,
int rnMasivC[1000]
)
{
int nMasivA[500],
nMasivB[500]; //Used as coefficients, information is filled from a meter
randomize;
for(g_nCount=0;g_nCount<=nSizeA; g_nCount++) //Hammer in coefficients an array
nMasivA[g_nCount]=random(100);
for(g_nCount=0;g_nCount<=nSizeB; g_nCount++) //Hammer in coefficients an array
nMasivB[g_nCount]=random(100);
//Add zeros to the array
for (g_nCount=0; g_nCount<=nSizeA+nSizeB; g_nCount++)
rnMasivC[g_nCount]=0;
//Cycles which calculate coefficients which are added to the array
for(g_nCount=0;g_nCount<=nSizeA; g_nCount++)
for(g_nCount2=0;g_nCount<=nSizeB; g_nCount++)
{
rnMasivC[g_nCount+g_nCount2]+=nMasivA[g_nCount]*nMasivB[g_nCount];
}
}
/****************************************************************************
FUNCTION.......: transposition
DESCRIPTION....: A function prints all the transpositions are possible
ARGUMENTS......: - nPos - current position in array
RETURNS........: None
******************************************************************************/
void transposition
(
int nPos
)
{
int nI; //Counter 1
int nJ; //Counter 2
//Destroys on a monitor, current combination
if (g_nSize == nPos)
{
for(nI = 1; nI <= g_nSize; nI++)
cout << g_nArr[nI];
cout << "\n";
}
else
for(nJ = nPos + 1; nJ <= g_nSize; nJ++)
{
//Changes combination
g_nTransPos = g_nArr[nPos + 1];
g_nArr[nPos + 1] = g_nArr[nJ];
g_nArr[nJ] = g_nTransPos;
transposition(nPos+1); //Causes a recursive function
//Returns combination to the entrance
g_nTransPos = g_nArr[nPos + 1];
g_nArr[nPos + 1] = g_nArr[nJ];
g_nArr[nJ] = g_nTransPos;
}
}
/****************************************************************************
FUNCTION.......: even_odd
DESCRIPTION....: A function writes at first even numbers then odd
ARGUMENTS......: - nSize - size of array
RETURNS........: None
******************************************************************************/
void even_odd
(
int nSize
)
{
int nArrMain[500]; //Array of different numbers
int nArrEven[500]; //Array used for Even numbers
int nArrOdd[500]; //Array used for Odd numbers
int nCountEven=0; //Counter for even numbers
int nCountOdd=0; //Counter for odd numbers
randomize;
//Hammer different number in an array and out it on display
for (g_nCount = 0; g_nCount < nSize; g_nCount++)
{
nArrMain[g_nCount] = random(100);
cout << nArrMain[g_nCount] << " ";
}
cout << "\n";
//Find even number write down them in an array, find odd and write down them in an array
for (g_nCount = 0; g_nCount < nSize; g_nCount++)
if (fmod(nArrMain[g_nCount], 2) == 0)
{
nArrEven[nCountEven] = nArrMain[g_nCount];
nCountEven++;
}
else
{
nArrOdd[nCountOdd] = nArrMain[g_nCount];
nCountOdd++;
}
//Out even numbers
for (g_nCount = 0; g_nCount < nCountEven; g_nCount++)
cout << nArrEven[g_nCount] << " ";
//Out odd numbers
for (g_nCount = 0; g_nCount < nCountOdd; g_nCount++)
cout << nArrOdd[g_nCount] << " ";
}
/*****************************************************************************
FUNCTION.......: main
24.03.2013 13:03-
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора