Розділ 2 Опис комплексу задач комп’ютерної автоматизованої приймальної коиісії стхт нухт

2.1. Характеристика вхідної інформації

Опис вхідної інформації, що необхідна для функціонування системи наведено у таблиці 2.1.

Таблиця 2.1. Перелік вхідної інформації

Назва	Форма представлення	Частота отримання
Дані про товар	Екранна форма	Відповідно до ухвалення документу
Дані про персонал	Екранна форма	Відповідно до ухвалення документу
Дані про транспорт	Екранна форма	Відповідно до ухвалення документу
Дані про замовника	Екранна форма	Відповідно до ухвалення документу
Дані про постачальника	Екранна форма	Відповідно до ухвалення документу

2.2 Використання вихідної інформації

Опис вихідної інформації, яка отримується в результаті функціонування системи наведено у таблиці 2.2.

Назва	Форма представлення	Періодичність
Список товару	Друкований документ, екранна форма	Відповідно до вимог користувача
Список персоналу	Друкований документ, екранна форма	Відповідно до вимог користувача
Приходна відомість	Друкований документ, екранна форма	Відповідно до вимог користувача
Розрахункова відомість	Друкований документ, екранна форма	Відповідно до вимог користувача
Список постачальників	Друкований документ, екранна форма	Відповідно до вимог користувача

Таблиця 2.2. Перелік вихідної інформації

2.3 Інформаційне забезпечення комп’ютерної інформаційної підтримки замовлень торгового підприємства «ром»

Згідно вимог для створення комп’ютерної автоматизованої підсистеми формування та виконання замовлень було використане наступне програмне забезпечення:

• BPWin 4.0 (для створення функціональної моделі)

• CASE- засіб моделювання верхнього рівня AllFusion ERwin Data Modeler 7.1

(для проектування та генерації бази даних);

• СУБД MSSQL 2008 (для збереження бази даних);

• Borland Delphi 7 (Для розробки інформаційної підтримки)

2.3.1 BPWin 4.0

BPWin – це засіб функціонального моделювання, який являє собою інтегроване середовище для моделювання функцій, процесів, відображення діяльності підприємств та їх взаємодії, має досить зручний інтерфейс з користувачем і велику гаму можливостей для представлення звітів. Загалом BPWin реалізує методологію IDEF0, IDEF2 (WorkFlow Diagram) та DFD (DataFlow Diagram).

Функціональна модель (IDEF0) призначена для опису існуючих бізнес-процесів на підприємстві (модель AS-IS) та ідеального положення речей, тобто, того, до чого потрібно прагнути (модель TO-BE). Спочатку проводиться опис системи в цілій її взаємодії з навколишнім світом (контекстна діаграма), після чого проводиться функціональна декомпозиція, тобто, система розбивається на підсистеми і кожна підсистема описується окремо (діаграми декомпозиції). Якщо потрібно, то кожна підсистема розбивається на більш дрібні до досягнення потрібного ступеня деталізації. Після кожного сеансу декомпозиції проводиться сеанс експертизи: кожна діаграма перевіряється експертами предметної області або представниками замовника. Така технологія створення моделі дозволяє побудувати модель, адекватну предметної області на всіх рівнях абстрагування. BРwin дозволяє переключитися на будь-якій галузі моделі на нотацію IDEF2 чи DFD і створити змішану модель. Анотація DFD включає такі поняття, як зовнішнє посилання і сховище даних, що робить її більш зручною у порівнянні з IDEF0 для

моделювання документообігу. Методологія IDEF2 включає елемент „перехрестя”, що дозволяє описати логіку взаємодії компонентів системи.

2.3.2 AllFusion ERwin Data Modeler 7.1

AllFusion ERwin Data Modeler – це засіб концептуального проектування БД, який використовує стандарт IDEF1Х. ERwin реалізує проектування схеми БД, генерацію її опису на мові цільової СУБД (ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server, Progress, MySQL та ін.) і реінжиніринг існуючої БД. За допомогою ERwin керівники проектів можуть задокументувати структуру БД, отримати звіти і забезпечити ефективне управління проектом, адміністратори БД – підвищити продуктивність інформаційної системи, розробники – спочатку, використовуючи візуальні засоби, описати схему БД, а потім автоматично згенерувати готові SQL-запити для створення БД в обраній реляційній СУБД.

В ERwin існують два рівні представлення і моделювання – логічний і фізичний. Логічний рівень є прямим відображенням фактів з реального життя. Вони іменуються на природній мові з будь-якими роздільниками слів (кома, пробіл та ін.). На логічному рівні не розглядається використання конкретної СУБД, не визначаються типи даних (наприклад, ціле або дійсне число) і не визначаються індекси для таблиць. Цільова СУБД, імена об’єктів і типи даних, індекси складають другий - фізичний рівень моделі ERwin.

2.3.3 MS SQL Server 2008

SQL Server 2008 - це реляційна СУБД, яка використовує мову Transact SQL для пересилки повідомлень між комп'ютером клієнта і комп'ютером, на якому працює SQL Server 2008. Реляційна СУБД складається з механізму баз даних, власне баз даних і додатків, необхідних для управління даними і компонентами реляційної СУБД. Реляційна СУБД організує дані у вигляді зв'язаних таблиць які складаються з рядків і стовпців, що становлять базу даних. Реляційна СУБД відповідає за підтримку структури бази даних і вирішує наступні завдання:

• підтримує зв'язки між даними в базі;

• гарантує коректне зберігання даних і виконання правил, що регламентують зв'язку між ними;

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

База даних (БД) SQL Server 2008 є реляційну базу даних, сумісну з SQL (Structured Query Language) з інтегрованою підтримкою XML для Інтернет додатків. SQL Server 2008 створений на основі сучасного розширюваного сервера SQL Server 7.0. У наступних розділах ви познайомитеся з базами даних, реляційними базами даних, SQL і XML.

Вихідний код MS SQL Server (до версії 7.0) грунтувався на коді Sybase SQL Server, і це дозволило Microsoft вийти на ринок баз даних для підприємств, де конкурували Oracle, IBM, і, пізніше, сама Sybase. Microsoft, Sybase і Ashton - Tate спочатку об'єдналися для створення і випуску на ринок першої версії програми, що отримала назву SQL Server 1.0 для OS / 2 (близько 1989 року), яка фактично була еквівалентом Sybase SQL Server 3.0 для Unix, VMS та ін Microsoft SQL Server 4.2 був випущений в 1992 році і входив до складу операційної системи OS / 2 версії 1.3. Офіційний реліз Microsoft SQL Server версії 4.21 для ОС Windows NT відбувся одночасно з релізом самої Windows NT (версії 3.1). Microsoft SQL Server 6.0 був першою версією SQL Server, створеною виключно для архітектури NT і без участі в процесі розробки Sybase.

До того часу, як вийшла на ринок ОС Windows NT, Sybase і Microsoft розійшлися та власні моделі цього програмного продукту і маркетинговим схемами. Microsoft намагалася отримати виняткові права на всі версії SQL Server для Windows. Пізніше Sybase змінила назву свого продукту на Adaptive Server Enterprise щоб уникнути плутанини з Microsoft SQL Server. До 1994 року Microsoft отримала від Sybase три повідомлення про авторські права як натяк на походження Microsoft SQL Server.

Після розділення компанії зробили декілька самостійних релізів програм. SQL Server 7.0 був першим сервером баз даних зі справжнім графічним інтерфейсом адміністрування. Для усунення претензій з боку Sybase у порушенні авторських прав, весь успадкований код в сьомій версії був переписаний.

Версія SQL Server 2005 - була представлена ​​в листопаді 2005 року. Запуск версії відбувався паралельно запуску Visual Studio 2005. Існує також «урізана» версія Microsoft SQL Server - Microsoft SQL Server Express, вона доступна для скачування і може безкоштовно розповсюджуватися разом з використовують її програмним забезпеченням.

З моменту випуску попередньої версії SQL Server (SQL Server 2000) було здійснено розвиток інтегрованого середовища розробки і ряду додаткових підсистем, що входять до складу SQL Server 2005. Зміни торкнулися реалізації технології ETL (витяг, перетворення і завантаження даних), що входить до складу компонента SQL Server Integration Services (SSIS), сервера оповіщення, засобів аналітичної обробки багатовимірних моделей даних (OLAP) і збору релевантної інформації (обидві служби входять до складу Microsoft Analysis Services), а також декількох служб повідомлень, а саме Service Broker і Notification Services. Крім цього, були проведені покращення в продуктивності.

2.2.4 Borland Delphi 7

Delphi – це середовище швидкої розробки, в якій як мова програмування використовується мова Delphi. Мова Delphi – об'єктно-орієнтована мова, що строго типізується, в основі якої лежить добре знайомий програмістам Object Pascal.

Delphi – є середовищем розробки програм, яке використовує багато передових ідей і концепцій, закладених в графічному інтерфейсі Windows. Як відомо, середовище великою мірою визначає ефективність роботи програміста. У середовищі програмування Delphi є всі необхідні інструменти для того, щоб створювати повноцінні програми. Писати, компілювати і тестувати програму – все це можна робити, не виходячи з Delphi.

Delphi простий і логічний. Основні конструкції мови чітко виділяються в програмі, що сприяє хорошому сприйняттю написаного коду. Графічний інтерфейс Delphi відмінно продуманий, середовище розробки надає доступ тільки до тих ділянок коду, з якими необхідно працювати, приховуючи основну частину програми, яка створюється автоматично самою розробкою.

Для виконання даного проекту нам потрібно було використовувати мову програмування Delphi. Середовище Borland Delphi 7 має великі можливості в візуальному режимі, також значним плюсом було те, що в цьому семестрі ми вивчали цю мову програмування. До цього я знав лише одну мову програмування Pascal. Мова програмування Delphi основана на мові Pascal тому мені було не дуже складно вивчити цю мову. Також, в мене була література з користування даною програмою.

При виконанні даного проекту перед нами поставало завдання розробити оптимальний варіант програми і написати її зручною для користування – важливий аспект в подальшому її використанні. а також розробити програму, яка відповідала б всім критеріям якості програмного продукту, тобто слідуючим пунктам:

1. Відповідність програми поставленій задачі;

2. Надійність програми;

3. Ефективність;

4. Модифікаційність;

5. Читабельність тексту програми;

6. Документованість;

7. Простота супровіду.

У виборі алгоритму для даного проекту ми мали два варіанти адже розрахунок перехідних процесів можна виконувати двома методами, і переді мною постав вибір між розрахунком класичним та операторним методами. Ми звичайно обрали розрахунок класичним методом, тому що цей метод використовується частіше для розрахунку перехідних процесів. Класичний метод розрахунку полягає в тому, що перехідна величина представляється як сума двох доданків: примушеної і вільної складових. Примушені складові відповідають сталому режиму й можуть бути знайдені звичайними методами розрахунку для кола після комутації. Вид примушених складових струму або напруги залежить як від форми ЕРС діючих у колі джерел, так і від конфігурації самого кола. Вільна складова обумовлюється енергією, що являє собою різницю запасів між усталеними режимами до й після комутації. Запас енергії кола мають тільки реактивні елементи. Вільні величини змінюються з часом за експоненціальними затухаючими функціями.

Першим важливим кроком у виконанні даного проекту є правильне виконання перехідних процесів, і правильне введення формул до програми, адже неправильно введені формули до програми, або неправильно виконані розрахунки перехідних процесів для даної схеми могли привести до зациклення або навіть зависання моєї програми. Спочатку саме така проблема у нас і була, програма зациклювалась і зависала. Чи то розрахунки перехідних процесів були виконані невірно, чи формули до програми були введені невірно. Але цієї проблеми вдалося позбутися. Нашу програму можна було б модернізувати, але в цьому не має потреби. Наш варіант написання програми для мене здається найоптимальнішим, тому що був ретельно продуманий і розроблений.

Все перший крок у виконанні даного проекту зроблено виконано розрахунки перехідних процесів для заданої схеми. Другим не менш важливим кроком у виконанні даного проекту стало виконання зовнішнього інтерфейсу програми. Так як ми поставили перед собою чітке завдання стосовно інтерфейсу програми, ми відразу уявляли зовнішній вигляд програми. Адже ми мали створити максимально практичну і функціональну програму.