Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Форма № Н - 6.01
Національний університет водного господарства та природокористування
(повне найменування вищого навчального закладу)
Навчально-науковий інститут автоматики, кібернетики та обчислювальної техніки
(повна назва інституту)
Кафедра обчислювальної техніки
(повна назва кафедри, циклової комісії)
з дисципліни
“Інженерія програмного забезпечення”
(назва дисципліни)
на тему: Проектування та розробка програмного забезпечення для автоматизації обліку спецодягу працівників підприємства
Студента (ки) ІІІ курсу КІ-11 групи
напряму підготовки 6.050102
“Комп’ютерна інженерія”
Гончарук Л.Ю.
(прізвище та ініціали)
Керівник старший викладач кафедри комп’ютерних наук Фільо І.Є.
(посада, вчене звання, науковий ступінь, прізвище та ініціали)
Національна шкала
Кількість балів: Оцінка: ECTS
Члени комісії Б.Б. Круліковський
(підпис) (прізвище та ініціали)
Б.А. Замрій
(підпис) (прізвище та ініціали)
І.Є. Фільо
(підпис) (прізвище та ініціали)
Рівне - 2013 рік
НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ
ВОДНОГО ГОСПОДАРСТВА ТА ПРИРОДОКОРИСТУВАННЯ
Інститут Автоматики, кібернетика та обчислювальної техніки
Кафедра Обчислювальної техніки
Дисципліна «Інженерія програмного забезпечення»
Напрям 6.050102 «Комп’ютерна інженерія»
Курс 1 Група КІ-11 інтегровані Семестр 1
Затверджено на засіданні кафедри обчислювальної техніки 8.10.2013 протокол №3
ЗАВДАННЯ
на курсову роботу студента
Гончарук Людмили Юріївни
1.Вступ
2. Аналіз предметної області
2.1. Опис предметної області
2.2. Огляд і аналіз існуючих аналогів, що реалізують функції
предметної області
2.3. Проектування ER-моделі предметної області
3. Специфікація вимог до програмного забезпечення в методології RUP
3.1.Глосарій
3.2.Текстовий формат специфікації варіантів використання
3.3.Розробка пакету UML-діаграм концептуального рівня
проектування програмного забезпечення
3.3.1. Діаграми варіантів використання(use case diagram)
3.3.2. Діаграми послідовності (sequence diagram)
3.3.3. Діаграми пакетів (package diagram)
3.4. Специфікація функціональних та не функціональних вимог
4. Проектні та технічні рішення
4.1. Проектування логічної моделі даних
4.2.Проектування фізичної моделі даних
4.3. Розробка архітектури програмного забезпечення
4.4. Тестування програмного забезпечення
4.5. Супровід програмного забезпечення
4.5.1. Керівництво адміністратора
4.5.2. Керівництво користувача
5. Висновки
Список використаних джерел
Додатки
5. Перелік графічного матеріалу
1. ER-модель предметної області
2. Діаграми варіантів використання(use case diagram)
3. Діаграми послідовності (sequence diagram)
4. Діаграми пакетів (package diagram)
5. Логічна модель даних
6. Фізична модель даних
7. Схема архітектури програмного забезпечення
8. Відеокадри тестування програмного забезпечення
9. Відеокадри інтерфейсу користувача
|
Номер і назва етапів курсової роботи |
Термін виконання етапів роботи |
Примітка |
|
1. Аналіз літературних джерел |
27.09 – 03.10 |
|
|
2. Аналіз об’єкта проектування |
04.10 – 16.10 |
|
|
3.Розробка вимог до програмного забезпечення |
17.10 – 31.10 |
|
|
4. Проектні та технічні рішення |
01.11 – 21.11 |
|
|
5. Оформлення пояснювальної записки |
22.11 – 7.12 |
Дата видачі завдання 26 вересня 2013 р.
Керівник ст. викладач кафедри ___________________ І.Є. Фільо
Завдання прийняв до виконання __________________ Д. Ю. Якобчук
РЕФЕРАТ
Пояснювальна записка до курсового проекту: 56 с., 29 мал., 1 табл., 14 джерел.
В курсовій роботі досліджуються питання проектування та розробки програмного забезпечення для автоматизації обліку спецодягу працівників підприємства.
Метою роботи є проектування програмного забезпечення за методологією RUP та розробка програмного забезпечення для автоматизації обліку продажів магазином книг комп’ютерної тематики.
У результаті роботи був проведений аналіз предметної області, на його основі побудована ER-модель предметної області, розроблена повна специфікація вимог у текстовому форматі. На основі визначених вимог були розроблені UML-діаграми концептуального рівня проектування програмного забезпечення, архітектура програмного забезпечення. Візуальне проектування виконувалось із використанням CASE-засобу Microsoft Access та Microsoft Visio.
Також була розроблена інформаційна система для автоматизації обліку обліку спецодягу працівників підприємства, в якій реалізовано сучасні методології програмної інженерії.
Програмний продукт може бути використаний у організаціях, які займаються роздрібним та оптовим продажем одягу для автоматизації продажу та формування облікової звітності.
РЕФЕРАТ
Пояснительная записка к курсовому проекту : 56 с . ,29 рис. , 1 табл . , 14 источников.
В курсовой работе исследуются вопросы проектирования и разработки программного обеспечения для автоматизации учета спецодежды сотрудников предприятия .
Целью работы является проектирование программного обеспечения по методологии RUP и разработка программного обеспечения для автоматизации учета спецодежды сотрудников предрриятия .
В результате работы был проведен анализ предметной области , на его основе построена ER -модель предметной области , разработана полная спецификация требований в текстовом формате . На основе определенных требований были разработаны UML- диаграммы концептуального уровня проектирования программного обеспечения , архитектура программного обеспечения . Визуальное проектирование выполнялось с использованием CASE - средства Microsoft Access и Microsoft Visio.
Также была разработана информационная система для автоматизации учета спецодежды сотрудников предрриятия, в которой реализовано современные методологии программной инженерии.
Программный продукт может быть использован в организациях занимающихся розничной продажей спецодежды для автоматизации продаж и формирование учетной отчетности .
ABSTRACT
Explanatory note to the course of the project: 56p. , 29 Fig. , 1 tab. , 14 sources.
As a term paper investigates the design issues and the development of software to automate sales booksellers computer topics.
The aim is to design software RUP methodology and software development to automate the sales book store computer topics.
As a result of an analysis of the subject area, based on ER- based domain model developed complete specification requirements in text format. Based on the identified requirements were developed UML- diagrams of the conceptual design level of software, software architecture . The visual design was carried out using a CASE-tool Microsoft Access and Microsoft Visio.
Also developed an information system to automate the sales book store computer topics. Which implemented modern software engineering methodologies .
The software can be used in organizations that are engaged in the retail sale of computer books for automation and form of accounting statements.
Зміст
1 Вступ
2 Аналіз предметної області
2.1 Опис предметної області
2.2 Огляд і аналіз існуючих аналогів, що реалізують функції предметної області
2.3 Проектування ER-моделі предметної області
3 Специфікація вимог до програмного забезпечення в методології RUP
3.1 Глосарій.
3.2 Текстовий формат специфікації варіантів використання.
3.3 Розробка пакету UML-діаграм концептуального рівня проектування ПЗ…
3.3.1 Діаграми варіантів використання(use case diagram)………………………..
3.3.2 Діаграми послідовності (sequence diagram)………………………………....
3.3.3 Діаграми пакетів (package diagram)………………………………………….
3.4 Специфікація функціональних та не функціональних вимог……………….
4 Проектні та технічні рішення.
4.1 Проектування логічної моделі даних………………………………………….
4.2 Проектування фізичної моделі даних…………………………………………
4.3 Розробка архітектури програмного забезпечення……………………………
4.4 Тестування програмного забезпечення……………………………………….
4.5 Супровід програмного забезпечення………………………………………….
4.5.1 Керівництво адміністратора…………………………………………………
4.5.2 Керівництво користувача……………………………………………………
Висновки.
Список використаних джерел.
Додатки………………………………………………………………………………..
ПЕРЕЛІК УМОВНИХ СКОЛОЧЕНЬ
ПрО – предметна область;
UML – Unified Modeling Language;
CASE – Computer-Aided Software Engineering;
ПЗ – програмне забезпечення;
ЖЦ – життєвий цикл.
БД – база даних;
ІС – інформаційна система;
СУБД – система управління базами даних;
ВСТУП
Останнім часом спостерігається стрімкий розвиток інформаційних технологій і впровадження їх в багато сфер життєдіяльності людини. Неможливість управляти технічними і економічними процесами, що все більш ускладнюються, зумовила в першу чергу впровадження в сферу промисловості, бізнесу, комерції інформаційних систем, які повинні виконувати збір, управління, коректування і розповсюдження інформації усередині організації. Дані є цінним ресурсом, і можуть забезпечувати як повсякденні потреби організації, так і підтримку ухвалення стратегічних рішень.
У зв’язку з інтенсивним розвитком мережі Інтернет, й переходом до електронного бізнесу та торгівлі, виникає необхідність у якісних, швидких, надійних та функціональних програмних рішеннях для умов, що складаються. При чому дані рішення повинні забезпечувати як належний рівень прозорості взаємодії учасників, так і необхідний ступінь безпечності інформації. Для того, щоб отримати такі рішення, перш за все необхідно правильно спроектувати програмне забезпечення.
Методологія проектування інформаційних систем описує процес створення і супроводу систем у вигляді життєвого циклу інформаційної системи, представляючи його як деяку послідовність стадій і процесів, що на них виконуються. Для кожного етапу визначаються склад і послідовність виконуваних робіт, отримані результати, методи і засоби, необхідні для виконання робіт, ролі та відповідальність учасників і т.д. Таке формальне описання життєвого циклу інформаційної системи дозволяє спланувати та організувати процес колективної розробки і забезпечити управління цим процесом.
Метою даної курсової роботи є проектування та розробка програмного забезпечення для автоматизації обліку продажів магазином книг комп’ютерної тематики за методологією RUP.
Досягнення мети роботи здійснюється шляхом вирішення таких задач:
При розробленні програмного забезпечення були використані такі технології: Microsoft Access та Microsoft Visio.
Програмний продукт може бути використаний у організаціях які займаються роздрібним продажем комп’ютерних книг для автоматизації продажу та формування облікової звітності.
РОЗДІЛ II.
АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ
2.1. Опис предметної області
У результаті дослідження й аналізу предметної області були визначені такі сутності, атрибути і первинні ключі.
Зв’язки сутностей визначаються на основі бізнес правил, які побудовані з урахуванням організаційної структури та операцій, що виконуються в системі:
Крім того необхідно врахувати:
2.2. Огляд і аналіз існуючих аналогів, що реалізують функції предметної області
Аналізуючи предметну область програмного продукту, мною було виявлено аналоги програм. 1С:, яка являється програмою аналогом до створеної мною програми автоматизації обліку спецодягу працівників підприємстві. Проаналізувавши дану програму-аналог, було зроблено висновок, що деякі додатки, компоненти та модулі схожі за своєю функціональністю.
Головною метою програмного комплексу «1С:» є якісна автоматизація обліку підприємств та установ. У цьому напрямку «1С:» вирішує основні завдання обліку підприємств та установ, а також дозволяє виробляти весь комплекс розрахунків , які здійснюються установою.
За допомогою програмного комплексу досягається :
1С: Бухгалтерія призначена для обліку різних видів фінансово - господарської діяльності підприємств:
2.3 Проектування ER-моделі предметної області
Сутності, атрибути і первинні ключі предметної області
Таблиця 1.1
|
Сутність |
Атрибути |
Первинний ключ |
|
СПЕЦОДЯГ |
Код спецодягу; Код виробника; Вид спецодягу; Термін придатності; Вартість одиниці. |
Код спецодягу |
|
ЦЕХ |
Код цеху; Назва цеху; П.І.Б. начальника цеху. |
Код цеху |
|
ПРАЦІВНИК |
Код працівника; Код цеху; Вид спецодягу; П.І.Б. працівника; Посада; Знижка на спецодяг (%). |
Код працівника |
|
ОТРИМАННЯ |
Код працівника; Код спецодягу; Дата отримання; Розпис. |
Дата отримання |
|
ВИРОБНИК |
Код виробника; Отримання; П.І.Б.начальника; Адреса виробника; Номер телефону. |
Код виробника |
На основі задач, які були поставленні перед інформаційною системою, і на основі аналізу предметної області, побудована ER -діаграма.
Мал.1. ER-діаграма обліку продажів магазином книг комп’ютерної тематики.
РОЗДІЛ ІІІ
СПЕЦИФІКАЦІЯ ВИМОГ ДО ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ В МЕТОДОЛОГІЇ RUP
3.1. Глосарій.
RUP - (англ. Rational Unified Process - Раціональний Уніфікований Процес) - це сукупність рекомендацій, що стосується розробки програмного забезпечення. Він описує дисциплінований підхід до призначення задач та відповідальності в організації по розробці програмного забезпечення. Головною метою RUP є надавати певності в керованості проекту, в високій якості програмного забезпечення, що передається кінцевим користувачам не виходячи за рамки прогнозованого графіку розробки та бюджету.
ІТЕРАЦІЯ - це завершений цикл розробки, що виражається у випуску (внутрішньої або зовнішньої) версії.
АКТОР - це визначення зв'язаної множини ролей, які може відігравати користувач при спілкуванні з системою
ДІАГРАМИ ВИКОРИСТАННЯ - Діаграми використання допомагають зрозуміти що повинна робити система без занурювання в питання як вона це буде робити.
UML-ДІАГРАМИ - (Unified Modelling Language або UML - універсальна мова моделювання) — це мова позначень або побудови діаграм, призначена для визначення, візуалізації і документування моделей зорієнтованих на об’єкти систем програмного забезпечення.
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ - це процес вирішення задач та планування для створення програмного рішення. Після того як мета і специфікація програми описані, розробник створить дизайн проекту, або найме дизайнера для розробки плану рішення. В дизайн включаються як описи низькорівневих компонентів, алгоритмів, так і огляд архітектури.
ЖИТТЄВИЙ ЦИКЛ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ — сукупність окремих етапів робіт, що проводяться у заданому порядку протягом періоду часу, який починається з вирішення питання про розроблення програмного забезпечення і закінчується припиненням використання програмного забезпечення
ФУНКЦІОНАЛЬНІ ВИМОГИ - описують внутрішню роботу системи, її поведінку: калькулювання даних, маніпулювання даними, опрацьовування даних, і інші специфічні функції які повиина виконувати система.
Функціональні вимоги визначають що система повинна робити, а не функціональні вимоги визначають якою система повинна бути.
CASE-ЗАСІБ – засоби що реалізують case технологію створення і супроводу.
3.2 Текстовий формат специфікації варіантів використання.
Авторизація в системі:
- ІС повідомляє користувачів, що вони ввели некоректний логін або пароль і знову пропонує ввести дані авторизації.
- користувачі повторно вводять коректні дані.
- Відбувається адресація користувачів на завантажувальну форму.
- Після натиснення кнопки «Розпочати роботу з ІС» користувачі потрапляють на головну форму.
Перегляд списку спецодягу:
Перегляд списку періодичної продукції:
Перегляд списку постачальників:
Перегляд списку отримання:
Перегляд списку працівників:
Перегляд списку продаж:
Перегляд списку товару:
Пошук за назвою виробника:
1) Зацікавлені особи прецеденту та їх вимог: користувач хоче швидко виконати пошук виробника за певними критеріями.
2) Користувачі ІС , тобто основні актори прецеденту: покупець, адміністратор.
3) Передумови прецеденту: ІС повинна бути активною тоді коли користувач користується нею та користувачами ІС будуть: покупець та адміністратор.
4) Основний успішний сценарій: покупець та адміністратор задає критерії пошуку у формі пошуку, система валідує критерії пошуку, якщо критерії коректні, то ІС відображає результати пошуку і надає можливість нового пошуку.
5) Розширення основного або альтернативні потоки: покупець та адміністратор ввів некоректні дані:
- ІС повідомляє покупця та адміністратора, що він ввів некоректний критерій пошуку і пропонує знов ввести критерії пошуку.
- Покупець та адміністратор повторно вводить коректні критерії пошуку.
- ІС відображає результати пошуку по БД і надає можливість нового пошуку.
Пошук за кодом виробника:
1) Зацікавлені особи прецеденту та їх вимог: користувач хоче швидко виконати пошук за кодом виробника.
2) Користувачі ІС , тобто основні актори прецеденту: покупець, адміністратор.
3) Передумови прецеденту: ІС повинна бути активною тоді коли користувач користується нею та користувачами ІС будуть: покупець та адміністратор.
4) Основний успішний сценарій: покупець та адміністратор задає критерії пошуку у формі пошуку, система валідує критерії пошуку, якщо критерії коректні, то ІС відображає результати пошуку і надає можливість нового пошуку.
5) Розширення основного або альтернативні потоки: покупець та адміністратор ввів некоректні дані:
- ІС повідомляє покупця та адміністратора, що він ввів некоректний критерій пошуку і пропонує знов ввести критерії пошуку.
- Покупець та адміністратор повторно вводить коректні критерії пошуку.
- ІС відображає результати пошуку по БД і надає можливість нового пошуку.
Пошук за телефоном виробника:
1) Зацікавлені особи прецеденту та їх вимог: користувач хоче швидко виконати пошук за телефоном.
2) Користувачі ІС , тобто основні актори прецеденту: покупець, адміністратор.
3) Передумови прецеденту: ІС повинна бути активною тоді коли користувач користується нею та користувачами ІС будуть: покупець та адміністратор.
4) Основний успішний сценарій: покупець та адміністратор задає критерії пошуку у формі пошуку, система валідує критерії пошуку, якщо критерії коректні, то ІС відображає результати пошуку і надає можливість нового пошуку.
5) Розширення основного або альтернативні потоки: покупець та адміністратор ввів некоректні дані:
- ІС повідомляє покупця та адміністратора, що він ввів некоректний критерій пошуку і пропонує знов ввести критерії пошуку.
- Покупець та адміністратор повторно вводить коректні критерії пошуку.
- ІС відображає результати пошуку по БД і надає можливість нового пошуку.
Пошук поставок за постачальником:
1) Зацікавлені особи прецеденту та їх вимог: користувач хоче швидко виконати пошук поставок за постачальником.
2) Користувачі ІС , тобто основні актори прецеденту: адміністратор, покупець.
3) Передумови прецеденту: ІС повинна бути активною тоді коли користувач користується нею та користувачами ІС будуть: адміністратор.
4) Основний успішний сценарій: адміністратор задає критерії пошуку у формі пошуку, система валідує критерії пошуку, якщо критерії коректні, то ІС відображає результати пошуку і надає можливість нового пошуку.
5) Розширення основного або альтернативні потоки: адміністратор ввів некоректні дані:
- ІС повідомляє адміністратора, що він ввів некоректний критерій пошуку і пропонує знов ввести критерії пошуку.
- Адміністратор повторно вводить коректні критерії пошуку.
- ІС відображає результати пошуку по БД і надає можливість нового пошуку.
Пошук поставок за товаром:
1) Зацікавлені особи прецеденту та їх вимог: користувач хоче швидко виконати пошук поставок за товаром.
2) Користувачі ІС , тобто основні актори прецеденту: адміністратор, покупець.
3) Передумови прецеденту: ІС повинна бути активною тоді коли користувач користується нею та користувачами ІС будуть: адміністратор.
4) Основний успішний сценарій: адміністратор задає критерії пошуку у формі пошуку, система валідує критерії пошуку, якщо критерії коректні, то ІС відображає результати пошуку і надає можливість нового пошуку.
5) Розширення основного або альтернативні потоки: адміністратор ввів некоректні дані:
- ІС повідомляє адміністратора, що він ввів некоректний критерій пошуку і пропонує знов ввести критерії пошуку.
- Адміністратор повторно вводить коректні критерії пошуку.
- ІС відображає результати пошуку по БД і надає можливість нового пошуку.
Пошук постачальника за адресою:
1) Зацікавлені особи прецеденту та їх вимог: користувач хоче швидко виконати пошук постачальника за адресою.
2) Користувачі ІС , тобто основні актори прецеденту: покупець, адміністратор.
3) Передумови прецеденту: ІС повинна бути активною тоді коли користувач користується нею та користувачами ІС будуть: покупець та адміністратор.
4) Основний успішний сценарій: покупець та адміністратор задає критерії пошуку у формі пошуку, система валідує критерії пошуку, якщо критерії коректні, то ІС відображає результати пошуку і надає можливість нового пошуку.
5) Розширення основного або альтернативні потоки: покупець та адміністратор ввів некоректні дані:
- ІС повідомляє покупця та адміністратора, що він ввів некоректний критерій пошуку і пропонує знов ввести критерії пошуку.
- Покупець та адміністратор повторно вводить коректні критерії пошуку.
- ІС відображає результати пошуку по БД і надає можливість нового пошуку.
Пошук постачальника за телефоном:
1) Зацікавлені особи прецеденту та їх вимог: користувач хоче швидко виконати пошук постачальника за телефоном.
2) Користувачі ІС , тобто основні актори прецеденту: покупець, адміністратор.
3) Передумови прецеденту: ІС повинна бути активною тоді коли користувач користується нею та користувачами ІС будуть: покупець та адміністратор.
4) Основний успішний сценарій: покупець та адміністратор задає критерії пошуку у формі пошуку, система валідує критерії пошуку, якщо критерії коректні, то ІС відображає результати пошуку і надає можливість нового пошуку.
5) Розширення основного або альтернативні потоки: покупець та адміністратор ввів некоректні дані:
- ІС повідомляє покупця та адміністратора, що він ввів некоректний критерій пошуку і пропонує знов ввести критерії пошуку.
- Покупець та адміністратор повторно вводить коректні критерії пошуку.
- ІС відображає результати пошуку по БД і надає можливість нового пошуку
Пошук працівника за ім’ям або прізвищем:
1) Зацікавлені особи прецеденту та їх вимог: користувач хоче швидко виконати пошук працівника за ім’ям або прізвищем.
2) Користувачі ІС , тобто основні актори прецеденту: адміністратор.
3) Передумови прецеденту: ІС повинна бути активною тоді коли користувач користується нею та користувачами ІС будуть: адміністратор.
4) Основний успішний сценарій: адміністратор задає критерії пошуку у формі пошуку, система валідує критерії пошуку, якщо критерії коректні, то ІС відображає результати пошуку і надає можливість нового пошуку.
5) Розширення основного або альтернативні потоки: адміністратор ввів некоректні дані:
- ІС повідомляє адміністратора, що він ввів некоректний критерій пошуку і пропонує знов ввести критерії пошуку.
- Адміністратор повторно вводить коректні критерії пошуку.
- ІС відображає результати пошуку по БД і надає можливість нового пошуку.
Пошук працівника за посадою:
1) Зацікавлені особи прецеденту та їх вимог: користувач хоче швидко виконати пошук працівника за посадою.
2) Користувачі ІС , тобто основні актори прецеденту: адміністратор.
3) Передумови прецеденту: ІС повинна бути активною тоді коли користувач користується нею та користувачами ІС будуть: адміністратор.
4) Основний успішний сценарій: адміністратор задає критерії пошуку у формі пошуку, система валідує критерії пошуку, якщо критерії коректні, то ІС відображає результати пошуку і надає можливість нового пошуку.
5) Розширення основного або альтернативні потоки: адміністратор ввів некоректні дані:
- ІС повідомляє адміністратора, що він ввів некоректний критерій пошуку і пропонує знов ввести критерії пошуку.
- Адміністратор повторно вводить коректні критерії пошуку.
- ІС відображає результати пошуку по БД і надає можливість нового пошуку.
Пошук працівника за кодом:
1) Зацікавлені особи прецеденту та їх вимог: користувач хоче швидко виконати пошук працівника за кодом.
2) Користувачі ІС , тобто основні актори прецеденту: адміністратор.
3) Передумови прецеденту: ІС повинна бути активною тоді коли користувач користується нею та користувачами ІС будуть: постачальник та адміністратор.
4) Основний успішний сценарій: постачальник та адміністратор задає критерії пошуку у формі пошуку, система валідує критерії пошуку, якщо критерії коректні, то ІС відображає результати пошуку і надає можливість нового пошуку.
5) Розширення основного або альтернативні потоки: постачальник та адміністратор ввів некоректні дані:
- ІС повідомляє постачальник та адміністратора, що він ввів некоректний критерій пошуку і пропонує знов ввести критерії пошуку.
- Постачальник та адміністратор повторно вводить коректні критерії пошуку.
- ІС відображає результати пошуку по БД і надає можливість нового пошуку.
Пошук товару за назвою:
1) Зацікавлені особи прецеденту та їх вимог: користувач хоче швидко виконати пошук товару за назвою.
2) Користувачі ІС , тобто основні актори прецеденту: покупець, адміністратор.
3) Передумови прецеденту: ІС повинна бути активною тоді коли користувач користується нею та користувачами ІС будуть: покупець та адміністратор.
4) Основний успішний сценарій: покупець та адміністратор задає критерії пошуку у формі пошуку, система валідує критерії пошуку, якщо критерії коректні, то ІС відображає результати пошуку і надає можливість нового пошуку.
5) Розширення основного або альтернативні потоки: покупець та адміністратор ввів некоректні дані:
- ІС повідомляє покупця та адміністратора, що він ввів некоректний критерій пошуку і пропонує знов ввести критерії пошуку.
- Покупець та адміністратор повторно вводить коректні критерії пошуку.
- ІС відображає результати пошуку по БД і надає можливість нового пошуку.
Додавання, редагування, видалення даних:
1) Зацікавлені особи прецеденту та їх вимоги: адміністратор: хоче додати, видалити або відредагувати певні дані;
2) Користувачі ІС тобто основні актори прецеденту: адміністратор;
3) Передумови прецеденту:
- ІС повинна бути активною;
- Користувачем ІС має бути адміністратор.
4) Основний успішний сценарій: адміністратор видаляє, редагує або додає нові дані, ІС валідує дані, якщо всі дані вірні то ІС оновлює, додає або видаляє відповідні записи в БД системи і відображає оновлений список;
5) Розширення основного сценарію або альтернативні потоки: адміністратор ввів некоректні дані при редагуванні або додаванні даних:
- ІС повідомляє адміністратора про введення некоректних даних і пропонує знову ввести коректні дані;
- Адміністратор повторно вводять коректні дані;
- ІС відображає оновлений список.
6) Спеціальні вимоги:
- Необхідно забезпечити 100% надійність обробки всіх транзакцій;
- ІС повинна мати 3 види користувачів з відповідними правами: покупець, постачальник, адміністратор;
- ІС повинна реагувати на запити користувачів не довше ніж 5 секунд.Див. Додаток А.
3.3 Розробка пакету UML-діаграм концептуального рівня проектування ПЗ
3.3.1 Діаграми варіантів використання(use case diagram)
Цей вид діаграм дозволяють створювати список операцій, які виконує система. Як правило цей вид діаграм називають діаграмами функцій так як набір таких діаграм створює список вимог до системи і визначається з множиною функцій, що виконує система. Кожна діаграма - це опис послідовності дій та взаємодій між акторами та іншими компонентами системи.
Діаграми варіантів використання (usecase diagrams) використовуються для відображення сценаріїв використання системи (usecases) та користувачів системи (actors), які використовують її функції.
Актори на діаграмі варіантів використання позначаються символом людини, а варіанти використання – еліпсом. Актори та варіанти використання поєднуються напрямленою асоціацією (unidirectional association) – стрілкою, що спрямована від актора до варіанта використання. Також актори можуть поєднуватися з використанням зв’язків узагальнення. Варіанти використання можуть бути пов’язані між собою трьома видами зв’язків: узагальненням (generalization), розширенням (extend relationship) та включенням (include relationship).
3.3.2 Діаграми послідовності (sequence diagram)
Взаємодія об’єктів прийняття та передачі повідомлення об’єктами-клієнтами та обробки цих повідомлень об’єктами-серверами. При цьому в різних ситуаціях можуть одні і ті ж самі об’єкти можуть виступати як у якості клієнтів та й у якості серверів. Даний тип діаграм дозволяє відобразити послідовність повідомлень між об’єктами. Цей тип діаграм не акцентує увагу на конкретній взаємодії головний акцент приділяється послідовності прийому/передачі повідомлень. Для того щоб окинути оком усі взаємозв’язки об’єктів слугує наступній тип діаграм.
Мал. 2. Діаграма послідовності побудови списків
Мал. 3. Діаграма послідовності формування пошуку
Мал. 4. Діаграма послідовності авторизації акторів ІС
3.3.3 Діаграми пакетів (package diagram)
В процесі розробки ПЗ є потреба розподілити програмне рішення на компоненти. Це потрібно також для розподілення роботи між членами команди розробників, та для подальшого повторного використання коду. Засобом моделювання в UML, який дає змогу агрегувати окремі компоненти в групи залежно від їх логічного призначення в системі є поняття пакету (package).
Кожен пакет володіє усіма елементами, що належать до нього, при цьому сам пакет може входити до складу іншого пакету. Графічно пакет позначається відповідним прямокутником, який має унікальне ім’я та може містити в собі інші пакети.
Крім відношення вкладеності, деякі пакети можуть знаходитися у певній функціональній залежності один від одного, тобто це коли компоненти, що знаходяться в одному пакеті, використовуються в іншому. Така залежність позначається на діаграмі пунктирною лінією із стрілкою на кінці Для підвищення рівня інформативності діаграм пакетів на них (до речі, як і на інших UML-діаграмах) можливо використовувати коментарі. Такий коментар позначається спеціальним графічним елементом, який містить відповідний текст.
Інтерфейс ІС :
Модуль розрахунків:
Бізнес логіка:
Мал. 5. Діаграма пакетів
РОЗДІЛ ІV
ПРОЕКТНІ ТА ТЕХНІЧНІ РІШЕННЯ
4.1 Проектування логічної моделі даних
Логічне проектування – процес створення моделі використовуваної на підприємстві інформації з урахуванням обраної моделі організації даних, але незалежно від типу цільової СУБД і інших фізичних аспектів реалізації. Ціль етапу – створення логічної моделі даних на рівні моделі записів для досліджуваної частини підприємства шляхом уточнення і перетворення концептуальної моделі з урахуванням особливостей обраної організації даних у цільовий СУБД (наприклад, реляційна чи мережева модель).
Логічне проектування виконується для певної моделі даних. Для реляційної моделі даних логічне проектування полягає у створені реляційної схеми, визначені числа і структури таблиць, формуванні запитів до БД, визначені типів звітних документів, розробці алгоритмів обробки інформації, створені форм для вводу і редагування даних в БД і рішенні цілого ряду інших задач. На цьому етапі проводиться усунення особливостей логічної моделі, які несумісні з реляційною моделлю:
Після спрощення в концептуальній моделі можуть бути присутні лише такі елементи:
Створивши логічну модель даних потрібно проаналізувати реляційну схему на коректність об’єднання атрибутів в одному відношенні. Перевірка виконується шляхом застосування послідовної нормалізації до кожного з відношень. Перевірка показує, що реляційна схема знаходиться в 4-й нормальній формі й корегування моделі не потрібно.
Після перевірки логічної моделі за допомогою правил потрібно аналізувати систему на предмет виконання трансакцій користувачів, які задаються на початкових етапах проектування.
Подальша перевірка моделі полягає у перевірці підтримки цілісності даних. На основі матеріалів можна визначити, що підтримується посилкова цілісність. Всі інші перевірки, включаючи і перевірку трансакцій користувачів, вимагають більш детального опрацювання даного проекту БД.
4.2 Проектування фізичної моделі даних
На етапі фізичного проектування бази даних, насамперед, необхідно вибрати конкретну цільову СУБД. Тому фізичне проектування нерозривно пов'язане з конкретної СУБД. Між логічним і фізичним проектуванням існує постійний зворотний зв'язок, тому що рішення, прийняті на етапі фізичного проектування з метою підвищення продуктивності системи, здатні вплинути на структуру логічної моделі даних.
Основною метою фізичного проектування у випадку реляційної моделі даних є наступне:
• створення набору реляційних таблиць і обмежень для них на основі інформації, представленої в логічній моделі даних;
• визначення конкретних структур зберігання даних і методів доступу до них, що забезпечують оптимальну продуктивність СУБД;
• розробка засобів захисту створюваної системи.
Фізична модель визначає розміщення даних у зовнішній пам’яті. Вона ще називається внутрішньою моделлю системи і форма її представлення залежить від обраної СУБД. Якщо обрана така СУБД, яка підтримує реляційну модель даних, то треба таблиці разом з атрибутами і зв’язки між таблицями перенести в середовище СУБД з врахуванням вимог до відповідних об’єктів БД. Так, ідентифікатори (імена) таблиць і полів мають задовольняти вимогам СУБД, типи
даних, розміри полів, обмеження теж мають бути приведені у відповідність до прийнятих у даній СУБД. Далі визначаються стратегії індексування, а також взаємозв’язки між таблицями, первинні та зовнішні ключі на основі визначених у
даталогічній моделі та врахуванням способів їх завдання в обраній СУБД.
На етапі фізичного проектування слід приділити особливу увагу забезпеченню цілісності БД. У СУБД цілісність даних забезпечується обмеженнями цілісності, тобто набором правил, що встановлюють допустимість даних та зв’язків між ними. Наводиться контрольний приклад заповненої БД з урахуванням встановлених обмежень цілісності.
Таким чином, послідовність робіт при створенні фізичної моделі на основі реляційної моделі даних може бути наступною:
• аналіз та вибір СУБД;
• розробка структури (фізичної моделі) бази даних засобами вибраної СУБД з урахуванням типів даних та обмежень цілісності атрибутів;
• розробка схеми взаємозв’язків бази даних засобами вибраної
СУБД з урахуванням обмежень посилальної цілісності;
• розробка контрольного приклада заповнення бази даних.
Кінцевим результатом роботи є представлення таблиць та зв’язків між ними, що описані в даталогічній моделі даних, у середовищі обраної СУБД. При цьому мають бути визначені (запрограмовані мовою опису даних) обмеження цілісності як для атрибутів, так и посилальна цілісність.
На етапі проектування бази даних на фізичному рівні треба, у першу чергу, визначитися з СУБД. Оскільки обсяг бази даних незначний, а підрозділи, що будуть її використовувати, то найбільш прийнятним рішенням буде вибір «настільної» СУБД Access та розміщення її на сервері, до якого будуть мати доступ підрозділи-користувачі. Питання розмежування доступу слід вирішити засобами операційної системи.
Засобами СУБД визначаємо ключі та інші властивості атрибутів у. Наведемо вигляд таблиць та у режимі конструктора, при цьому показано властивості тих атрибутів, що потребують їх встановлення (визначення).
Цілісність бази даних на рівні таблиць забезпечено наявністю первинних ключів у кожній таблиці атрибути виділені жирним шрифтом), а на рівні зв’язків посилальною цілісністю (на схемі вона відображена символами ‘1’ та ‘∞’ на кінцях зв’язків).
4.3 Розробка архітектури програмного забезпечення
Мал. 6. Архітектура проектованої ІС
4.4 Тестування програмного забезпечення
Тестування ПЗ повинно включати функціональне і структурне тестування. Функціональне тестування (Functional Testing), яке також називають тестуванням за принципом «чорної скриньки» (“Black Box” Testing), полягає у перевірці функцій, які виконуються елементами ПЗ, на відповідність вимогам, проекту ПЗ та документації користувача. Структурне тестування (Structural Testing), яке також називають тестуванням за принципом «білої скриньки» або «скляної скриньки» (“White Box” Testing або “Glass Box” Testing), полягає у перевірці внутрішньої структури елементів ПЗ.
Виконання функціонального і структурного тестування ПЗ було здійснене незалежно одне від одного. Основним видом тестування є функціональне. Функціональне тестування застосовують для ПЗ у цілому, а також для програмних об'єктів будь-якого рівня (процедури, модуля, підсистеми, системи). Структурне тестування доповнює функціональне. Цій вид тестування можливий для рівня не вище рівня програмного модуля.
Під час реалізації функціонального і структурного тестування ПЗ були виконані наступні дії:
а) планування тестування:
1) розроблення плану тестування;
б) розроблення вимог до тестів:
1) визначення складових якості ПЗ, які оцінюються за результатами тестування;
2) визначення складових ПЗ, які тестувались;
3) оцінка необхідних для тестування ресурсів (бюджет, час, персонал);
в) проектування тестів:
1) проектування специфікації тестів;
г) проектування тестових процедур;
1) проектування детальних тестів;
2) проектування інструментального середовища тестування;
3) розроблення тестів;
4) розроблення детальних тестів;
5) розроблення тестових даних;
6) розроблення інструментального середовища тестування;
д) виконання тестування та оцінка його результатів:
1) виконання тестових прикладів;
2) аналіз результатів тестування;
3) розроблення звіту про тестування.
Загальну структуру інструментального середовища тестування ПЗ представлено на малюнку . Складові частини представленого інструментального середовища можуть бути цілком або частково автоматизовані.
Мал. 7. — Структурна схема інструментального середовища тестування ПЗ
4.5 Супровід програмного забезпечення
4.5.1 Керівництво адміністратора
Вступ
Дана ІС призначена для роздрібної торгівлі, функції якої автоматизуються при рішенні задачі "Облік спецодягу працівників підприємства ". Задача призначена для ведення довідників і оперативних файлів, формування і друк документів: "Звіт працівників"; "Звіт по отриманню", “Звіт по товарам”. У ІС містяться відомості про призначення програми, умови її застосування, опис задачі. Користувач спілкується з ПК природною мовою через систему меню й екранні форми.
Призначення й умови застосування
Програмне забезпечення задачі організує автоматичне виконання наступних функцій: введення і накопичення даних про працівників, постачальників, та інші їх параметри; введення і накопичення інформації про поставлений спецодяг; формування і друк документів: "Звіт працівників"; "Звіт по отриманню", “Звіт по товарам”. Інформаційна система з " Обліку спецодягу працівників підприємства " функціонує на ПК на базі мікропроцесора Pentium4 фірми Intel (тактова частота процесора 2.0 Мгц), ОС Windows. ІС написана в СУБД Microsoft Access. Робота з програмним забезпеченням ведеться в інтерактивному режимі. Усі повідомлення ПЗ по задачі з'являються на екран з підказкою вибору дій, якими необхідно керуватися користувачу в подальшій роботі.
Підготовка до роботи
Включіть ПК. Після автоматичного завантаження Windows 7 або Windows XP запустити файл «Спецодяг». mdb. Після запуску програма зажадає: "Введіть пароль", введіть пароль і натисніть кнопку "Ввійти", після чого, якщо пароль введено правильно, можна приступати до рішення задачі.
Опис задачі
Виконання функцій відбувається шляхом вибору відповідної вкладки вікна.
Мал. 8. Форма авторизації в ІС
При запуску Спецодяг. mdb з’являється форма авторизації в ІС. В рядку «Виберіть користувача» є можливість вибрати з випадаючого списку користувачів ІС (адміністратор, завідувач складу, покупець, постачальник).
Після вибору необхідного користувача потрібно ввести в пароль. Пароль у кожного із користувачів є індивідуальним, і видається при прийнятті на роботу.
Натиснувши клавішу «Ввійти» з’являється «Завантажувальна форма» ІС. Дана форма складається лише з двох кнопок: Розпочати роботу в ІС та Вихід.
Форма завантажування має вигляд (Мал. 9).
Мал.9. Завантажувальна форма.
Нажавши кнопку «Вихід» ІС автоматично закриється. Якщо нажати кнопку «Розпочати роботу з ІС» відкриється головна форма для роботи. Для кожного користувача буде відображено лише ті таблиці, якими він повинен користуватись, наприклад: постачальник і покупець будуть бачити усі вкладки крім (Документація та Таблиці).
Головне вікно програми виглядає так (Мал. 10.):
Мал.10. Головна форма ІС.
На головній форма містяться 6 вкладок (Перегляд, Редагування, Інформація, Друк, Про інформаційну систему, Вихід). Кожна з вкладок має свою функціональність та відповідає за певні дії. Почнемо опис з вкладки «Перегляд». Вона містить: Перегляд інформації про виробників(перегляд повного списку виробників), Перегляд інформації про спецодяг (відображається таблиця інформації про спецодяг), Перегляд інформації про виданий спецодяг, Перегляд інформації про працівників, Перегляд інформації про цехи. На вкладці присутні кнопки пошуку, які дозволяють зручно та оперативно знайти ту інформацію, яка потрібна користувачу. Кнопки пошуку зображені на Мал.11 .
Мал..11. Вкладка «Перегляд».
Мал.12. Перегляд списку виробників.
Мал.13. Перегляд списку спецодягу.
Мал.14. Перегляд списку отриманого спецодягу.
Мал.15. Перегляд списку працівників.
Мал.16. Перегляд списку цехів.
Мал.17. Вкладка «Редагування».
Дана вкладка містить наступне: редагування інформації про виробників, редагування інформації про спецодяг, редагування інформації про виданий спецодяг, редагування інформації про працівників, редагування інформації про цехи.
Мал.18. Редагування списку виробників.
Мал.19. Редагування списку спецодягу.
Мал.20. Редагування списку отриманого спецодягу.
Мал.21. Редагування списку працівників.
Мал.22. Редагування списку цехів.
Наступною вкладкою даної інформаційної системи є вкладка «Інформація», яка зображена на мал..23.
Мал.23. Вкладка «Інформація»
Дана вкладка мастить у собі наступні таблиці: інформація про працівників, інформація про виробника, інформація про спецодяг.
Мал.24. Інформація про працівника.
Мал.25. Інформація про виробника.
Мал.26. Інформація про спецодяг.
Мал.27. Інформація про знижки.
Наступною вкладкою системи є «Друк», яка зображена на малюнку 28 і містить ті ж самі таблиці, що й вкладка «Інформація».
Мал.28. Вкладка «Друк».
Мал.29. Вкладка «Про інформаційну систему».
Дана вкладка містить інформацію про власника та розробника інформаційної системи автоматизації обліку спецодягу працівників підприємства.
4.5.2 Керівництво користувача
В керівництві користувача буде усе те, що в керівництві адміністратора, тільки для користувача не буде активна вкладка «Таблиці» та ще деякі кнопки на вкладках головної форми. Також користувачеві потрібно враховувати що програма призначена для експлуатації на IBM-сумісних персональних комп’ютерах. Для використання програми необхідно мати таку апаратну та програмну конфігурацію:
5 . Висновки
Курсова робота з дисципліни «Інженерія програмного забезпечення» з теми Проектування та розробка програмного забезпечення для автоматизації обліку спецодягу працівників підприємства створена для ведення обліку. База даних включає декілька таблиць. Це забезпечує зручність введення даних до бази.
Використання запитів значно полегшує обробку інформації бази даних. За допомогою запиту на вибірку, ввівши назву та виробника спецодягу виводиться вся інформація про даний виріб. Форми забезпечують більш зручне введення та перегляд даних. Форма є зручною коли потрібно по певному працівнику переглянути всі записи, які були зроблені. Кнопкова форма призначена для користувачів, які не достатньо ознайомлені з структурою бази даних і забезпечує зручну роботу зі звітами, формами та таблицями.
Модель «сутність-зв’язок» є високорозвиненою концептуальною моделлю даних. Подана модель даних є набором концепцій, які описують структуру бази даних і пов’язані з нею трансакції оновлення і видалення даних.
Розробивши логічну структуру бази даних, яка відповідає концептуальній моделі предметної області, формується схема функціонування бази даних. На даталогічному етапі інфологічна модель перетворюється на опис схеми бази даних у термінах вибраної СУБД. Вибір СУБД я здійснив після аналізу потреб і особливостей бази даних, виявлених на інфологічному етапі.
Під час виконання курсової роботи я закріпила теоретичні знання, набуті при вивченні дисципліни «Інженерія програмного забезпечення», та практично застосувала методи концептуального проектування реляційних баз даних.
Отже, можна сказати, що електронні бази даних ідеально підходять для такого підприємства. Більше того, без них нормальна робота підприємства майже неможлива. Вони мають досить велику швидкість обробки даних, є більш зручними у використанні, більш надійними, вони не потребують додаткових витрат на зберігання інформації, а також можна створювати резервні копії на випадок пошкодження бази даних.
У курсовій роботі створені передумови основних принципів побудови таких продуктів без знання мови програмування, основною метою яких є надати можливість користувачам автоматизувати процес роботи з можливістю створення не тільки електронних, а й паперових документів на основі яких формується уявлення про роботу підприємства на різних етапах функціонування.
Список використаних джерел
1. Гайна Г.А., Попович Н.Л. Організація баз даних і знань.
Організація реляційних баз даних: Конспект лекцій.−К.:КНУБА, 2000. − 76с.
2. Гарсиа-Молина Г., Ульман Д., Уидом Д. Системы баз данных.−М.: Издательский дом "Вильямс", 2003. − 1088 с.
3. Григорьев Ю.А., Ревунков Г.И. Банки данных.−М.: Изд-во МГТУ им. Н.Э.Баумана, 2002. − 320 с.
4. Дейт К.Дж. Введение в системы баз данных.−К.: Диалектика, 1998. − 784 с.
5. Диго С.М. Проектирование и использование баз данных.−М.: Финансы и статистика, 1995. − 208 с.
6. Карпова Т.С. Базы данных: модели, разработка, реализация.− СПб.: Питер, 2001. − 304 с.
7. Когаловский М.Р. Энциклопедия технологий баз данных.− М.: Финансы и статистика, 2002. − 800 с.
8. Кренке Д. Теория и практика построения баз данных.− СПб.: Питер, 2003. − 800 с.
9. Малыхина М.П. Базы данных: основы, проектирование, использование. − СПб.: БХВ-Петербург, 2004. − 512 с.
10. Роб П., Коронел К. Системы баз данных: проектирование, реализация и управление. − СПб.: БХВ-Петербург, 2004. − 1040 с. 179
11. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных.− СПб.: Корона принт, 2004. − 736 с.
12. Гайна Г. А. Основи проектування баз даних: Навчальний посібник. – К.: Кондор, 2008. – 200 с.
13. Проектування інформаційних систем: Посібник \За редакцією Пономаренка В. С. – К.: Видавничий центр «Академія», 2002.
14. Каратигін С. Access 2000 на примерах.