Смекни!
smekni.com

Магазин побутової техніки (стр. 2 из 3)

1.2 Підстави для розробки

Підстава для розробки є підготовка програмного продукту для виконання завдання курсової роботи по курсу «Технологія програмування і створення програмних продуктів»

1.3 Призначення розробки

Програма призначена для створення, управління вмістом бази даних, що містить наступні дані:

а)Інформацію побутової техніки;

б)Можливість проведення пошуку абонентів за типом побутової техніки, фірмою виробником, моделлю, за ціновим проміжком, проміжком виготовлення;

в) Програма надає інтерфейс для управління вмістом бази.

2. Вимоги до програми або програмного виробу

2.1 Вимоги до функціональних характеристик

Програма повинна забезпечувати можливість виконання перерахованих нижче функцій:

а)Можливість додавання нової побутової техніки;

б)Можливість пошуку по базі даних побутової техніки інформації про побутову техніку;

в)Можливість збереження даних про побутову техніку;

г)Можливість зміни даних побутової техніки.

2.2 Вимоги до надійності

Відмови програми унаслідок некоректних дій користувача при взаємодії з програмою недопустимі.

3. Умови експлуатації

3.1 Кліматичні умови експлуатації

Кліматичні умови експлуатації, при яких повинні забезпечуватися задані характеристики, повинні задовольняти вимогам, що пред'являються до технічних засобів в частині умов їх експлуатації

3.2 Вимоги до кваліфікації і чисельності персоналу

Кваліфікація персоналу повинна забезпечувати ефективне функціонування технічних і програмних засобів системи у всіх режимах роботи системи.

Мінімальна кількість персоналу, потрібного для роботи програми, повинна складати не менше 1 штатної одиниці – оператор .

4. Вимоги до інформаційної і програмної сумісності

4.1 Вимоги до інформаційних структур і методів рішення

Програма повинна забезпечувати багатокористувацький доступ до бази даних.

4.2 Вимоги до початкових кодів і мов програмування

До початкових кодів додаткові вимоги не пред'являються.

Вимоги до мов програмування повинні бути сформовані на етапі проектування.

4.3 Вимоги до програмних засобів, використовуваних програмою

Вимоги до програмних засобів, використовуваних програмою, повинні бути сформовані на етапі проектування.

5. Вимоги до програмної документації

5.1 Попередній склад програмної документації

Склад програмної документації повинен включати:

а)технічне завдання;

б)програму і методики випробувань;

в)керівництво оператора;

6. Техніко-економічні показники

6.1 Економічні переваги розробки

Орієнтовна економічна ефективність не розраховуються. Аналогія не проводиться зважаючи на унікальність вимог, що пред'являються, до розробки.

7. Стадії і етапи розробки

7.1 Стадії розробки

Розробка повинна бути проведена в дві стадії:

а)розробка технічного завдання;

б)робоче проектування;

7.2 Етапи розробки

На стадії розробки технічного завдання повинен бути виконаний етап розробки, узгодження і затвердження справжнього технічного завдання.

На стадії робочого проектування повинні бути виконані перераховані нижче етапи робіт:

а)розробка програми;

б)розробка програмної документації;

в)випробування програми.

7.3 Зміст робіт по етапах

На етапі розробки технічного завдання повинні бути виконані перераховані нижче роботи:

а)постановка завдання;

б)визначення і уточнення вимог до технічних засобів;

в)визначення вимог до програми;

г) визначення стадій, етапів і термінів розробки програми і документації на неї

д)узгодження і затвердження технічного завдання.

На етапі розробки програми повинна бути виконана робота по програмуванню (кодуванню) і налагодження програми.

На етапі розробки програмної документації повинна бути виконана розробка програмних документів відповідно до вимог до складу документації На етапі випробувань програми повинні бути виконані перераховані нижче види робіт:

а)розробка, узгодження і твердження і методики випробувань;

б)проведення випробувань;

в) коректування програми і програмної документації за наслідками випробувань.

2.3 Діаграма «сутність-зв'язок»

Модель "сутність-зв'язок" (ER-модель) (англ. Entity-relationship model або entity-relationship diagram) - модель даних, яка дозволяє описувати концептуальні схеми за допомогою узагальнених конструкцій блоків. ER-модель - це мета-модель даних, тобто засіб опису моделей даних.

ER-модель зручна при проектуванні інформаційних систем, баз даних, архітектур комп'ютерних застосунків та інших систем (моделей). За допомогою такої моделі виділяють найсуттєвіші елементи (вузли, блоки) моделі і встановлюють зв'язки між ними.

Існує ряд моделей для представлення знань. Одним з найзручніших інструментів уніфікованого представлення даних, незалежного від реалізовуючого його програмного забезпечення, є модель "сутність-зв'язок" (entity - relationship model, ER - model).

Модель "сутність-зв'язок" ґрунтується на якійсь важливій семантичній інформації про реальний світ і призначена для логічного представлення даних. Вона визначає значення даних в контексті їх взаємозв'язку з іншими даними. Важливим для нас є той факт, що з моделі "сутність-зв'язок" можуть бути породжені всі існуючі моделі даних (ієрархічна, мережева, реляційна, об'єктна), тому вона є найбільш загальною. Будь-який фрагмент наочної області може бути представлений як безліч сутностей, між якими існує деяка безліч зв'язків.

ER-модель - це одна з найбільш простих візуальних моделей. Вона дозволяє осягнути структуру об'єкта «крупними мазками», в загальних рисах. Такий загальний опис структури називається ER-діаграмою або онтологією вибраної предметної області (area of interest).

2.4 Діаграма потоків даних (DFD)

Діаграма потоків даних (англ. Data Flow Diagram) — графічне представлення «потоків» даних в інформаційній системі. Діаграма потоків даних також може використовуватись для представлення обробки даних (структурна розробка). Вважається звичайним, для розробника, з початку креслити ДПД рівня контексту, завдяки чому буде показано взаємодію системи із зовнішніми модулями. Ця ДПД рівня контексту, потім розширюється, для того, щоб показати розроблювану систему детальніше. Діаграми потоків даних містять чотири типи графічних елементів: процеси, що представляють собою трансформацію даних в рамках системи, що описується, репозиторії (сховище даних), зовнішні по відношенню до системи сутності та потоки даних між елементами трьох попередніх типів.

Реалізація

2.5 Програма та методика тестування


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

2.6 Інструкція користувача (інструкція підключення компонента)

В даному програмному продукті (магазин побутової техніки) існує лише один вид користувача - оператор, котрий має всі права. Саме тому інструкція розроблена для операторів даного програмного продукта.

Інструкція

Магазин побутової техніки (б/у)- програма для зберігання бази даних побутової техніки. В базу даних заноситься тип побутової техніки, фірма виробник, модель, заводський номер, дата виготовлення, ремонт, ціна, коментарі. Програмний продукт має вигляд невеликого вікна з полем для введення необхідних даних, таблицею зі списком побутової техніки, та функціональними кнопками. (Рис. 1).

Рис.1 Головне вікно програми

· Для додавання даних про нову побутову техніку в базу даних спочатку треба заповнити поля таблиці а потім натиснути на кнопку

.

· Для просмотра всіх абонентів котрі знаходяться в базі, необхідно у текстовому полі для введення призвища натиснути клавішу “Enter”.

· Для пошуку в поле, що знаходиться понизу вікна, вводяться необхідні дані та обирається критерій пошуку.

Щоб редагувати запис в базі даних,необхідно знайти побутову техніку, клацнувши по ньому у списку побутової техніки в таблиці, та ввівши необхідну інформацію клацнути на клавішу «Enter». Аналогічно робимо для видалення запису, тільки уже нажимаємо -

.

Висновок

У курсовій роботі було реалізовано базу даних(програмний продукт) «Магазин побутової техніки (б/у)». А також забезпечено загрузку всіх елементів інтерфейсу з файлу.

В даному програмному продукті база має таку структуру: тип побутової техніки, фірма виробник, модель, заводський номер, дата виготовлення, ремонт, ціна, коментарі. В цій програмі реалізовано додавання елементу в список; видалення із списку елемента; пошук елементів за ціновим проміжком, проміжком виготовлення; зміна даних елементу списку; збереження в базу даних.

Завдання виконано повність всі координати всіх елементів інтерфейсу загружаються нормально без виявлення будь яких помилок.


Перелік посилань

1. Деван Шеперд - Освой самостоятельно XML, 2-е издание : Пер. с англ. – М.: Издательский «Вильямс», 2002. – 432с.

2. Рэй Э. Изучаем XML. Пер. с англ. – СПб: Символ – Плюс, 2001. – 408с., ил.

3. XML. Справочник. Пер. с англ. – СПб: Символ – Плюс, 2002. – 576с., ил.

4. П. Ноутон, Г. Шилдт. Java: наиболее полное руководство. — СПБб.: Петербург, 2000.


Додаток А

using System;

using System.Collections.Generic;

using System.ComponentModel;

using System.Data;

using System.Drawing;

using System.Linq;

using System.Text;

using System.Windows.Forms;

using System.IO;

namespace WindowsFormsApplication1

{

public partial class FormMain : Form

{

public FormMain()

{

InitializeComponent();

}

private void складBindingNavigatorSaveItem_Click(object sender, EventArgs e)

{

this.Validate();

this.складBindingSource.EndEdit();

this.tableAdapterManager.UpdateAll(this.складDataSet);

}


private void FormMain_Load(object sender, EventArgs e)

{

// TODO: This line of code loads data into the 'складDataSet.Склад' table. You can move, or remove it, as needed.