Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Проектування системи інтернет-магазину
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
ІКТА
Факультет:
КН
Кафедра:
Не вказано
Інформація про роботу
Рік:
2009
Тип роботи:
Курсова робота
Предмет:
Програмування частина 4 Технологія системного програмування
Частина тексту файла (без зображень, графіків і формул):
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ “ЛЬВІВСЬКА ПОЛІТЕХНІКА”
Пояснювальна записка
до курсової роботи
з дисципліни:
"Програмування, частина 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. Аналіз аналогів
Перед початком розробки системи для інтернет-магазину було досліджено існуючі аналоги, які використовуються в сучасних аналогах для оптимізації його функціонування.
Проаналізувавши існуючі системні рішення було зроблено висновок, що на сьогоднішній день в світі існує досить багато і, практично, ідеальних рішень для реалізації інтернет-магазину (ebay.com, auction.ua – приклади інтернет-аукціонів). Так в інтернет-магазинах, для задоволення потреб всіх користувачів використовується ціла низка програмного забезпечення та колективного складу.
Для ведення обліку товарних запасів і користувачів, в більшості випадків використовуються бази даних MySQL.
Сам інтернет-магазин розробляється на мові програмування PHP, хоча, на мою думку, раціональніше і дешевше використовувати двигуни аналогів (напр. Amiro CMS. CMS – система управління сайтом. В ній передбачено абсолютно все, що потрібно для функціонування інтернет-магазину).
Для розробки унікального дизайну сайту інтернет-магазину, спочатку потрібно намалювати шаблон сайту в будь-якій програмі для обробки графічних зображень, потім перетворити (верстка) це все в html-сторінку, а також інтегрувати дизайн в нашу CMS.
Для підтримки зв’язку з клієнтами використовуються зворотні форми, e-mail, а також телефонна довідкова служба (інформатори).
Система, яка є розроблена під час виконання даного курсового проекту практично перевершує існуючі програмні рішення і є оптимальною для організації роботи інтернет-магазину, адже вона поєднує в одному модулі вирішення всіх поставлених задач.
3. Моделювання системної архітектури засобами UML
3.1. Аналіз предметної галузі
Під час розробки системи для роботи музичної школи спочатку було визначено всіх потенційних користувачів даної системи і визначено всі їх вимоги до даної системи. Таким чином серед прецедентів, які мають відношення до музичної школи можна виділити:
Клієнта
Директора
Інформатора
Службу доставки
Сервісна служба
Далі було проаналізовано всі їх вимоги від системи, які можна структуризувати наступним чином:
Рис.2 Ієрархія точок зору усіх користувачів системи.
Для графічного відображення вимог кожного користувача системи було використано уніфіковану мову моделювання UML. За допомою якої було створено діаграми прецедентів, що і відображає їх вимоги.
а)
б)
в)
г)
д)
Рис.3 Діаграми прецедентів: директора (А), клієнта (Б), служби доставки (В), інформатора (Г), сервісної служби (Д).
На першому періоді розробки системи було визначено місце системи в середовищі:
Рис.4 Структурна схема моделі системного середовища.
При реалізації системи було змодельовано ряд стандартних процесів, які відбуваються в інтернет-магазині, серед яких можна виділити процес реєстрації клієнта на сайті та процес покупки товару.
Рис.5 Модель процесу реєстрації клієнта на сайті.
Рис.6 Модель процесу покупки товару клієнтом.
При реалізації даної системи використовується ряд баз даних:
Користувачів (клієнтів);
Товарів (категорій товарів);
Персоналу.
Кожна база даних зберігає відповідну інформацію, що забезпечує можливість реалізації системи.
Для відображення сутності баз даних можна використати наступну діаграму:
Рис.7 Модель сутності баз даних, та зв’язків між ними.
3.2. Розробка архітектури програмного забезпечення
Наступним етапом в розробці системи є розробка архітектури програмного забезпечення. На цьому етапі визначається структуру системи, та структуру керування та взаємодії складових системи.
Для реалізації структури системи було використано базу даних SQL. Яка забезпечує доступ до потрібної інформації кожному користувачу. Всі дані зберігаються на потужному сервері хостинга або приватному сервері.
Рис.8 Структура системи для роботи інтернет-магазину
(модель репозиторій)
Для реалізації системи роботи інтернет-магазину було обрано модель, що керується подіями. А саме модель передачі повідомлень.
Рис.9 Модель керування.
4. Тестування програмного забезпечення
4.1. Теоретична частина
Тестування програмного забезпечення - це процес аналізу або експлуатації програмного забезпечення з метою виявлення дефектів.
Тестування передбачає "аналіз" або "експлуатацію" програмного продукту. Тестова діяльність, що пов'язана з аналізом результатів розробки програмного забезпечення, називається статичним тестуванням. Воно передбачає перевірку програмних кодів, контроль та перевірку програми без запуску на комп'ютері. Тестова діяльність, що передбачає експлуатацію програмного продукту, називається динамічним тестуванням. Динамічне та статичне тестування доповнюють одне одного.
Мета розробника полягає в тому, щоб зробити програмний код без дефектів, який відповідає призначенню програмного продукту та відповідає вимогам замовника. Мета тестувальника пов'язана з аналізом коду та експлуатації програми, що у результаті повинно призвести до виявлення дефектів, які проявляються під час його інтегрування, конфігурування та виконання в різних середовищах.
Тестування програмного забезпечення виконує дві базові функції: верифікацію та атестацію. Верифікація забезпечує відповідність результатів конкретної фази процесу розробки вимог даної та попередньої стадії. Атестація є гарантією того, що програмний продукт задовольняє системним вимогам.
Програмний продукт є якісним, коли:
під час роботи користувача з програмним продуктом виникає невелика кількість відмов;
програмний продукт надійний, а це означає, що його використання рідко викликало аварійні відмови;
програмний продукт задовольняє вимогам більшості користувачів.
Процес тестування є дуже важливим при розробці програмного забезпечення. Адже на цьому етапі можна ще до введення в експлуатацію виявити помилки в його роботі. На сьогоднішній день цьому процесу приділяють надзвичайно велику увагу всі розробники, адже він допомагає економити і підтримувати імідж фірми.
Тому розроблено велику кількість методів тестування, серед яких :
Тестування на відмову;
Структурне тестування ("білого ящика");
Тестування "чорного ящика";
Перевірка на модель;
Та інші.
Для тестування розробленого програмного забезпечення в даному курсовому проекті будуть використані саме такі методи тестування.
Будь яке тестування повинно складатися з наступних елементів і процесів, тобто виконуватись за наступною схемою:
Рис. 10 Схема процесу тестування.
4.2. Тестування "чорної скриньки"
При тестуванні "чорної скриньки" (англ. black-box testing), тестер має доступ до ПЗ тільки через ті ж інтерфейси, що й замовник або користувач, або через зовнішні інтерфейси, що дозволяють іншому комп'ютеру або іншому процесу підключитися до системи для тестування.
Для проведення даного тестування було обрано емулятор інтернет-магазину, розроблений спеціально для курсової роботи.
Вимогами до даної програми є зрозумілість в користуванні, зрозуміле діалогове вікно при введенні даних і виводі результату.
Було отримано наступні результати:
Рис.13 Результат виконання програми.
Аналіз результату:
Діалогове вікно для роботи практично не має недоліків:
при запуску програми присутній опис, що вона повинна виконувати;
введені дані і результат роботи візуально відділені;
діалог з користувачем ведеться на кирилиці, що відповідає стандарту і зручно для користувача;
в процесі тестування було визначено, що програма працює правильно для різного числового значення вхідних даних.
4.3. Тестування "білої скриньки"
При тестуванні "білої скриньки" (англ. white-box testing, також говорять - прозорого ящика), тести створюються на основі знань про структуру системи і про те, як вона працює і критерії повноти тестування на відсотках елементів коду, які відпрацювали в ході виконання тестів.
Для проведення даного тестування було обрано задачу з лабораторної роботи №3.
Критерії тестування:
Наявність змістовних ”шапок” до файлів
Наявність змістовних ”шапок” до функцій
Відповідність імен функції Венгерській нотації
Відповідність імен змінних Венгерській нотації
Наявність пояснюючих коментарів до коду
Дотримання форматування тексту
Мобільність
Оптимальне функціонування окремих блоків програми.
В процесі виконання тестів було проаналізовано текст програми:
//------------------------------ FILE headers.h -------------------------------------
using namespace std;
struct readerData {
int codeNum;
char Name[10];
char LastName[15];
char year[4];
};
int enterChoiceR(void);
void readRecordR(FILE *);
void textFileR(FILE *);
//void updateRecord(FILE *);
void newRecordR(FILE *);
void deleteRecordR(FILE *);
void deleteAllRecordR(FILE *);
void textFileR(FILE *readPtr)
{
FILE *writePtr;
struct readerData reader;
if ((writePtr = fopen("base_readers.txt", "w")) == NULL)
cout << "Не могу подключиться к БД!" << endl;
else {
rewind (readPtr);
fprintf (writePtr, "%-15s%-16s%-lls%10s\n",
"Код товара", "Название", "Количество", "Цена");
for(int i=0;i<5;i++) {
fread(&reader, sizeof (struct readerData), 1, readPtr);
if (reader.codeNum !=0)
fprintf (writePtr, "%-15d%-16s%-lls%19s\n",
reader.codeNum, reader.Name,
reader.LastName, reader.year);
}
}
fclose (writePtr);
}
/*
void updateRecord(FILE *fPtr)
{
int account;
float transaction;
struct clientData client;
printf("Enter account to update (1 - 100): ") ;
scanf("%d", &account);
fseek(fPtr, (account - 1) * sizeof(struct clientData),
SEEK_SET);
fread(&client, sizeof (struct clientData), 1, fPtr);
if (client.acctNum == 0)
printf("Acount #%d has no information.\n",account);
else {
printf("%-6d%-16s%-lls%10.2f\n\n",
client.acctNum, client.lastName,
client.firstName, client.balance);
printf("Enter chrge (+) or payment(-): ");
scanf("%f", &transaction);
client.balance += transaction;
printf("%-6d%-16s%-lls%10.2f\n",
client.acctNum, client.lastName,
client.firstName, client.balance);
fseek(fPtr, (account-1) * sizeof(struct clientData),
SEEK_SET);
fwrite(&client, sizeof (struct clientData), 1, fPtr);
}
}
*/
void deleteRecordR(FILE *fPtr)
{
struct readerData reader, blankreader = {0, "", "", ""};
int Num;
printf("------------> Введите номер товара для удаления (1-100): ");
scanf("%d", &Num);
fseek(fPtr, (Num - 1) * sizeof(struct readerData),
SEEK_SET);
fread(&reader, sizeof (struct readerData), 1, fPtr);
if (reader.codeNum == 0)
printf("\n------------> Товара №%d не существует.\n", Num);
else {
fseek(fPtr, (Num - 1) * sizeof(struct readerData),
SEEK_SET);
fwrite(&blankreader,sizeof(struct readerData), 1, fPtr);
}
}
void newRecordR(FILE *fPtr)
{
struct readerData reader;
int Num;
printf ("\n------------> Введите код нового товара (1-100): ");
scanf("%d", &Num);
fseek(fPtr, (Num -1) * sizeof (struct readerData),
SEEK_SET);
fread (&reader, sizeof (struct readerData), 1, fPtr);
if (reader.codeNum !=0)
printf("\n------------> Товар #%d уже существует, попробуйте ввести другой номер!\n",
reader.codeNum);
else {
printf("\n------------> Введите название, Количество, Цену товара через пробел\n? ");
scanf ("%s%s%s", &reader.Name, &reader.LastName,
&reader.year);
reader.codeNum = Num;
fseek(fPtr, (reader.codeNum -1) *
sizeof(struct readerData), SEEK_SET);
fwrite(&reader, sizeof (struct readerData), 1, fPtr);
}
}
void readRecordR(FILE *fPtr)
{
struct readerData reader;
if ((fPtr = fopen("readers.dat", "r")) == NULL)
printf("Не могу подключиться к БД!\n");
else {
rewind (fPtr);
printf ("%-15s%-16s%-lls%10s\n", "Код товара", "Название",
"Количество", "Цена");
for(int i=0;i<5;i++) {
fread(&reader, sizeof (struct readerData), 1, fPtr);
if (reader.codeNum !=0)
printf("%-15d%-16s%-lls%19s\n",
reader.codeNum, reader.Name,
reader.LastName, reader.year);
}
}
}
void deleteAllRecordR(FILE *fPtr)
{
struct readerData reader, blankreader = {0, "", "", ""};
int Num;
for(Num=0;Num<5;Num++)
{
fseek(fPtr, (Num - 1) * sizeof(struct readerData),
SEEK_SET);
fread(&reader, sizeof (struct readerData), 1, fPtr);
if (reader.codeNum == 0)
printf(" ");
//printf("Аккаунта №%d не существует!\n", Num);
else {
fseek(fPtr, (Num - 1) * sizeof(struct readerData),
SEEK_SET);
fwrite(&blankreader,sizeof(struct readerData), 1, fPtr);
}
}
}
int enterChoiceR (void)
{
int menuChoice;
cout << endl
<< "Виберите действие:" << endl
<< " 0: Вывести БД товаров на экран" << endl
<< " 1: Сохранить БД в файл" << endl
//"2 - update an account\n"
<< " 3: Добавить новый товар" << endl
<< " 4: Удалить товар" << endl
<< " 5: Обнулить БД" << endl
<< " 6: Выйти из магазина" << endl
<< "Ваш выбор: ";
cin >> menuChoice;
cout << endl;
return menuChoice;
}
#include <iostream>
#include <stdio.h>
#include "reader.h"
using namespace std;
char currentUser;
//------------------------------ FILE MAIN.CPP -------------------------------------
int main ()
{
setlocale(LC_CTYPE, "");
cout << "Добро пожаловать в эмулятор интернет-магазина!" << endl << endl;
cout << "Вы можете войти в систему как [A]dmin или [U]ser." << endl;
cout << "Ваш выбор: "; cin >> currentUser;
if ( currentUser == 'A' || currentUser == 'a')
cout << "------------> Вы вошли как Admin!" << endl;
else
cout << "------------> Вы вошли как User!" << endl;
FILE *cfPtr;
int choice;
if ((cfPtr = fopen("readers.dat", "r+")) == NULL)
{
cout << "Невозможно открыть файл! Создаю новый..." << endl;
cfPtr = fopen("readers.dat", "w");
}
while ( (choice = enterChoiceR())!= 6) {
switch(choice) {
case 0:
readRecordR(cfPtr); // Зчитуємо БД
break;
case 1:
if ( currentUser == 'A' || currentUser == 'a')
textFileR(cfPtr); // Зберігаємо БД
else
cout << "------------> У вас не достаточно прав!" << endl;
break;
//case 2:
//updateRecord(cfPtr);
//break;
case 3:
if ( currentUser == 'A' || currentUser == 'a')
newRecordR(cfPtr); // Новий запис
else
cout << "------------> У вас не достаточно прав!" << endl;
break;
case 4:
if ( currentUser == 'A' || currentUser == 'a')
deleteRecordR(cfPtr); // Видаляємо запис
else
cout << "------------> У вас не достаточно прав!" << endl;
break;
case 5:
if ( currentUser == 'A' || currentUser == 'a')
deleteAllRecordR(cfPtr); // Очищуємо БД
else
cout << "------------> У вас не достаточно прав!" << endl;
break;
}
}
fclose(cfPtr);
return 0;
}
Аналіз результату.
Змістовні ”шапки” до файлів присутні, проте виконані не відповідно до вимог, в них не міститься інформація про назву функції, його призначення, автора і статистика введення змін.
Змістовні ”шапки” до функцій відсутні.
Практично всі імена функцій і змінних програми оформлені відповідно до Венгерської нотації.
Коментарі в програмі відсутні. Причина – інтуїтивно зрозумілий алгоритм.
Текст програми відформатовано відповідно до вимог.
Програма є мобільною і функціонування окремих блоків є оптимальним.
Всі негативні аргументи пояснюються тим, що програма не є об’ємною, і в ній легко розібратись без усіх правил.
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
03.04.2013 21:04-
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора