Автоматизована система обліку

Автоматизированная довідково-інформаційна система обліку й контролю поставок на.

предприятии.

1. Стан проблеми обліку поставок на предприятие.

Господарство України є сукупність підприємств і закупівельних організацій.

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

державної форми власності перебувають у віданні різних міністерств і.

відомств, соціальній та віданні місцевих виконкомів. Виробнича діяльність.

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

призначення, господарського ужитку та ін.

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

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

і котрі перебувають державною бюджеті. Найбільше держбюджетних.

організацій підпорядковано Міністерства освіти й науки України: школи,.

дитячі садки, педагогічні інститути, технікуми, училища тощо. (близько тридцяти%.

загальної кількості організацій); Міністерства охорони здоров’я України — лікарні,.

санаторії, госпіталі та інших. лікувальні установи (близько 20%); міністерства.

культури та освіти України — театри, бібліотеки, музеї та ін. (понад 25 відсотків%.

загальної кількості організацій) [3].

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

(через від відповідних міністерств і відомства), і територіальним.

(через місцевих органів управления).

Підприємства господарства України виробляють різноманітну продукцію. У його числі.

можна знайти засоби виробництва: верстати, машини, металопродукцію, товари.

народного споживання, предмети побутової хімії і т.п.

Для виробництва всієї перерахованої вище продукції підприємства, незалежно від.

форм власності, для свого нормального і стабільного функціонування.

потребують сировину, комплектуючих, запчастинах тощо. Інакше кажучи в організацію.

своєї діяльності підприємства зіштовхуються з проблемою своєчасного постачання.

продукції. Для цього підприємства державної форми власності.

використовують постачальницькі організації (нині даними організаціями.

користуються спеціалізовані державні підприємства), підприємства ж.

приватних форм власності проводять відповідні заходи, створені задля.

вчасна й безупинне забезпечення необхідним сировиною чи матеріалами. Однак у.

час майже всі підприємства будь-який форми власності.

самостійно шукають підприємств-постачальників, і навіть принаймні.

необхідності організацією поставок.

Однією з показників характеризуючих підприємства є товарообіг,.

що є планово організаційний процес звернення коштів.

виробництва [2], від якої великою мірою залежать та інші економічні.

показники. У цілому загальний обсяг товарообігу включають усе товари, реалізовані.

підприємством, тобто. одержані від підприємств постачальників продукції. Також.

товарообіг показує як швидко підприємство використовує отриману.

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

підприємство здійснюється поставок, тим паче стабільно працює дане.

предприятие.

При здійсненні поставок на підприємство виробляється обробка і збереження.

великої кількості інформації, пов’язаної з постачаннями, яка охопить собою включает:

вчасна й правильне оформлення документів і контролю над кожної операцією.

надходження товарів — від постачальників, з переробки нафти та інших джерел,.

виявлення розбіжності фактичного наявності і кількість, вказаної у.

супровідних документах;

контролю над своєчасним, повний та правильним оприбуткуванням які поступили.

товаров;

вчасна й правильне оформлення документації контроль над кожної.

операцією відпустки, відвантаження чи реалізації товара;

контролю над дотриманням нормативів запасу товаров.

У зв’язку з цим для надійного функціонування системи поставок необхідно вести.

їх систематичний і безперервний облік, що й виконувати розроблювальне ПО.

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

програмного забезпечення можливістю застосування на сучасної.

електронно-обчислювальної техніці [1], зручним інтерфейсом, низькою вартістю,.

можливістю її використання будь-якою предприятии.

1.1 Загальна характеристика проблемы.

При здійсненні поставок підприємства виробники продукції.

виробничо-технічного призначення входять у договірні відносини з.

підприємствами споживачами (покупцями) як постачальники укладають прямі.

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

постачання предприятий-заказчиков.

Договори про поставки необхідно укладати своєчасно. Вони вказуються.

умови поставки товарів, їх кількість, асортимент, якість, комплектність і.

терміни поставки. З іншого боку, в договорах передбачені ціни на всі товари, загальна.

сума, порядок розрахунків, платіжні і відвантажувальні реквізити постачальника і.

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

зазначених у них пунктах. Порушення термінів договорів та зобов’язання тягне.

відповідальність, передбачену «Положенням щодо постачання продукції.

виробничо-технічного призначення" і «Особливими умовами поставки.».

Контроль над втіленням договорів здійснюють товарні відділи.

Раціональна організація приймання продукції з постачальників має важливого значення.

для своєчасного, повного, комплексного постачання підприємств сировиною,.

матеріалами, паливом, інструментами, обладнанням і іншими засобами.

производства.

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

Є надійною основою схоронності товарно-матеріальних ценностей.

Загальний порядок приймання товарно-матеріальних цінностей встановлено «Положенням про.

поставці продукції виробничо-технічного призначення". Порядок і продовжити терміни.

приймання товарно-матеріальних цінностей на певному кількість і якість,.

оформлення актів приймання і пред’явлення претензій визначено інструкцією про.

порядку приймання продукції виробничо-технічного призначення і товарів.

народного споживання за кількістю інструкцією про порядок приймання продукції.

виробничо-технічного призначення за якістю. Особливості приймання.

окремих видів продукції визначаються Держстандартах [12.01.005−89], технічних.

умовах, Особливих умовах постачання російської та договорах поставки, які передбачають.

особливі порядки приймання продукції при поставках.

На підприємствах державної форми власності здійсненням всіх дій.

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

відповідного програмного забезпечення, займається певну кількість.

персоналу підприємства, але, зазвичай, розробка такого програмного.

забезпечення велася мовами низького рівня програмування, а й за останні 6−8.

років розвиток машинних коштів (ПЕОМ), програмних засобів різко збільшилася,.

тому раніше розроблене ПО і не відповідає вищим вимогам,.

що ставляться до сучасним програмним продуктам. Що ж до підприємств,.

фірм різний форм приватної власності, всі вони найчастіше мають зовсім.

відповідного програмного забезпечення, значно збільшує.

трудомісткість процесу контролю та обліку проведення поставок. Розроблюваний.

програмний продукт і покладено дані проблеми.

1.2 Формулювання задач.

Будь-яке підприємство, здійснюючи своєї діяльності, щоб одержати продукції з.

постачальників має укласти останніми договір про поставки продукції. Зазвичай.

на однойменну продукцію підприємство-замовник укладає кілька договорів із.

предприятиями-поставщиками. Потім замовник в міру потреби у певному.

продукції висилає постачальнику заявку про поставки продукції і на одержує вигоду від.

останнього рахунок-фактуру, у якій зазначено найменування продукції та її відпускна.

ціна. З цих рахунків підприємство-замовник визначає оптимальну.

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

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

їх у банку протягом строку, передбаченого договором. Тож.

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

створювати (роздруковувати) такі необхідні документы:

бланк договору предприятия-заказчика з фирмой-поставщиком (із зазначенням.

найменування і юридичиних адрес сторін, асортименту продукції постачанню,.

її кількості і імовірною вартості, а як і умови і продовжити терміни дії.

договора);

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

номенклатура, терміни поставки).

Також створювана автоматизовану систему за даними постачальників і.

знову отриманим даним повинна визначати оптимальний рахунок-фактуру з місця.

зору количество-цена.

Будь-яку поставку підприємство-замовник зобов’язане оплатити в встановлені договором.

терміни, тому АС має здійснювати підрахунок суми боргу (грошей до виплати) на.

поточну дату.

1.3 Мотивація задач.

Підприємство чи фірма, виробляючи своєї продукції, потребує сировини від.

інших підприємств. На те й теж сировину в різних производителей-поставщиков.

різна відпускна ціна, у цілях зниження собівартості випущеної.

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

постачальників і далі висилає постачальникам заявку про поставки продукції з.

зазначенням типу, і її кількості. Оскільки підприємство-замовник і при отриманні.

вантажів однак пов’язані з документами, з документальним оформленням.

поставок, то проектируемая АСИС повинна створювати все бланки документів,.

що з поставками.

Оскільки всі постачальники висилають замовнику рахунки-фактури (прейскурант ціни.

замовлену продукцію), але серед їх безлічі необхідно визначити найбільш.

вигідна предприятия-заказчика, як за ціною, і за якістю, що має.

виконувати створювана АС.

Оскільки договору з постачальниками полягають визначений термін, передбачене.

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

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

замовлення має бути оплачений, тож треба знати суму до оплати на вказане.

число, як загальну і різноманітні постачальникам в отдельности.

Оскільки перелічені вище дії здійснюються протягом тривалого.

часу, то, при прийнятті рішення про продовження строку дії договору.

доцільно брати до уваги такі чинники: якість поставок.

конкретними постачальниками (мається на увазі виконання термінів здійснення.

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

відсутність чи відсоток шлюбу), його толерантність стосовно оплати за.

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

підприємство, що надалі її було б использовать.

1.3. Технічне задание.

Автоматизована довідково-інформаційна система (АСИС) «Облік поставок» буде.

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

контроль обліку поставок вироблених на підприємство. Також під час використання.

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

підприємство, виявлення боргу оплаті поставок. Розроблюване ПО.

можна використовувати як керівником підприємства, реалізації.

контролю вироблених поставок на підприємство, і начальниками цехів, для.

ведення обліку поставок.

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

Підставою до виконання роботи є підставою наказ про базі переддипломної практики.

від 10 червня 1999 р. № 270 по Державному аерокосмічному університету і.

наказ про дипломному проектуванні від 26 червня 2000 р. № 271.

1.3.2. Призначення разработки.

Метою дипломного проектування є розробка і створення програмного.

продукту «Облік поставок». Цей програмне забезпечення призначено для.

контролю, обліку, автоматизації і систематизації інформації про поставки.

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

будь-яким виглядом виробництва чи діяльності.

Розроблюваний програмний продукт має забезпечити створення інформаційного.

бази про здійснених поставках на підприємство, і навіть здійснювати створення.

наступних документів :

бланк договору підприємства замовника з фирмой-поставщиком (із зазначенням.

найменування і юридичиних адрес сторін, що у договорі,.

асортименту продукції постачанню, її кількості, імовірною.

вартості, умови і продовжити терміни дії договора);

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

найменування, номенклатура, терміни поставки, сума поставки);

замовлення поставку.

Комерційна версія програмного продукту дозволить производить:

є повнішим контроль й організацію обліку про поставки на предприятие;

автоматизувати процес оформлення поставок на предприятие;

зменшить тимчасові видатки оформлення, що з поставками;

обраховувати заборгованість за оплатою здійснених поставок на зазначений период;

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

і з користування програмним продуктом.

Розроблюваний автоматизовану систему має реалізувати такі.

функции:

Забезпечення введення даних про поставки на предприятие;

Аналіз введеної информации;

Підрахунок заборгованості підприємства за здійснені поставки;

Визначати оптимальний рахунок-фактуру з погляду «количество-цена»;

Виробляє печатку документації, що з організацією поставок (бланк.

договору, замовлення, заявки).

1.3.3. Вихідні дані і источники.

Ця робота виходить з темі переддипломної практики і є його.

продовженням з урахуванням рекомендацій для поліпшення раніше розробленого ПО,.

запропонованих керівником практики від підприємства міста і групою співробітників цього.

підприємства міста і розглянутих керівником практики від института.

1.3.4. Вихідні вимоги до кінцевого результату.

Вимоги по функциональности.

Розроблювана АСИС має забезпечити автоматизований контроль, а як і.

облік поставок на підприємство (цех цього підприємства), при цьому створювана.

система должна:

Забезпечувати введення, що з поставками на підприємство й нам обробку цих.

данных;

Створювати звітні документи і документи в організацію грузопоставок; (.

Додаток А).

Мати систему допомоги по программе;

При введення даних про найменуванні товарів повинен використовуватися довідник.

«Номенклатура товаров»;

Створювані документи повинні відповідати галузевим стандартам, прийнятим на.

підприємстві.

Умови эксплуатации.

Утворюваний програмний продукт має використовуватися директором.

підприємства, начальником цеху, начальником складу, залежно від місця.

експлуатації продукту. Задані характеристики функціонування повинні.

забезпечуватися за умов, визначених конкретним носієм даних,.

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

час є жорстких дисків, котрим оптимальним є.

функціонування за температур від 5 до +35оС і відносній вологості від 10.

до 60 процентов.

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

Програма повинна функціонувати на персональні комп’ютери з такою.

конфигурацией:

IBM PC/AT сумісних ПЕОМ не нижче Pentium 100;

з обсягом ОЗУ щонайменше 16 мегабайт;

Обсяг необхідного дискового простору — щонайменше 10 мегабайт.

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

Утворювана програма повинна функціонувати, легко інсталюватися,.

налаштовуватися і коректно працювати у виконанні наступних требований:

наявність ОС типу Windows 95, Windows 98, Windows NT 4. x,.

Windows 2000 і сумісних з ними;

наявність бази даних LocalInterBase чи сумісних з ней;

введення дати обов’язковий у вигляді маски;

введення цифр обязателен.

Вимоги по защите.

Задля більшої захисту від несанкціонованого доступу до інформації, що з.

поставками на підприємство передбачуватиметься система паролів за мінімального завантаження.

програми в оперативну пам’ять. Задля більшої захисту даних про збої у мережі.

харчування ПК або аварійному завершенні роботи програми буде передбачено режим.

автосохранения.

1.3.5. Етапи проведення работ.

Етапи проведення роботи представлені у таблиці 1.2.

Таблиця 1.2. Етапи проведення работы.№ЭтапыСроки выполненияОтчетность.

1Изучение принципів системи грузопоставок на предприятие07.07.1999 -.

14.07.1999.

2Ознакомление з раніше виконану работой01.09.1999- 08.09.1999.

3Определение вимог до разработке9.09.2000- 19.09.1999Техническое.

задание.

4Разработка інформаційної моделі предметної області (побудова.

концептуальної модели)20.09.200- 09.10.1999.

5Выбор алгоритмічних средств10.10.1999- 28.10.1999.

6Определение програмних средств29.10.99- 07.11.1999.

7Выбор методики випробування і тестирования08.11.1999- 15.11.1999Техническое.

предложение.

8Разработка алгоритмів, що з реалізацією обліку поставок16.11.1999-.

9.12.1999.

9Проектирование алгоритмів, що з формуванням тестових.

заданий10.12.1999 — 20.12.1999.

10Определение коштів проведення тестування і грунтовного аналізу його.

результатов11.12.1999- 30.12.1999.

11Разработка програмного забезпечення що з реалізацією обліку.

поставок на предприятие31.12.1999- 15.02.2000.

12Разработка програмного забезпечення що з формуванням тестових.

заданий16.02.2000- 3.03.2000.

13Реализация програмного забезпечення проведення тестування та якісного аналізу.

його результатов4.03. 2000- 4.04.2000.

14Проведение тестування та клінічних випробувань розробленого програмного.

обеспечения5.04.2000- 19.04.2000.

16Написание расчетно-пояснительной записки20.04.2000-.

21.05.2000Расчетно-пояснительная записка.

17Подготовка плакатов22. 05.2000- 29.05.2000Плакаты.

18Подготовка доклада29.05.2000- 11.06.2000Доклад.

19Предзащита дипломного проекта12.06.2000.

20Защита дипломного проекта20.06.2000.

1.3.6. Плановані показники эффективности.

Через війну виконаної роботи передбачається досягти наступних эффектов:

зменшення часу який буде необхідний обліку поставок вироблених на.

предприятие;

автоматизація контролю поставок;

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

довгий час давності, щодо можливості повнішого розрахунку ефективності.

діяльності предприятия;

стала популярність про конкретні строки оплати здійснених поставок.

1.3.7. Порядок приймання результатів работы.

Приймання результатів роботи ввозяться відповідність до планом приймання,.

затвердженим спеціалісти кафедри і узгоджених із керівником практики. Цей план зараз.

входять такі пункты:

Введення технічного завдання, технічного пропозиції, журналу переддипломної.

практиці, і змісту расчетно-пояснительной записки після проходження.

переддипломної практики.

Здача программы.

Предзащита дипломного проекту. Даються: расчетно-пояснительная записка,.

плакати, доповідь, рецензія, відгук руководителя.

Захист дипломного проекту. Даються: дипломний проект з документами,.

зауваження, допуск право на захист, картка обліку деканату, демонстраційний образец.

1.3.8. Документація, предъявляемая після закінчення работы.

Після закінчення роботи надається наступна документация:

Технічне задание;

Расчетно-пояснительная записка;

Опис применения;

Керівництво системного программиста;

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

Також предоставляются:

Плакаты;

Доклад;

Рецензия;

Текст программы;

Дискета з належним програмним продуктом і супровідній документацией.

2. Моделирование.

2.1 Аналіз уявлення моделей данных.

Для ефективного функціонування розроблюваної АСИС «Облік поставок» буде.

розроблена СУБД [24]. Тому нижче розглянуті логічні і концептуальні.

моделі даних.

2.2 Вибір логічного моделі данных.

2.2.1 Ієрархічна модель данных.

Ієрархічна модель [6] даних є ієрархію як дерева.

Ця модель даних виходить з сегменті, що є.

сукупність полів, характеризуючих даний сегмент. Сегменти різняться по.

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

на поля даних. Два пов’язаних сегмента, розташованих на суміжних рівнях.

називаються вихідним (вищого рівня) і породжених (нижчого).

Ієрархічна запис — система взаємозалежних сегментів, у якій кожен.

породжений сегмент представлений стільки раз, скільки потрібно до повного.

розкриття цього сегменту. У ієрархічної структурі є сегмент, який.

має вихідного і називається головним чи кореневим. У цьому вся сегменті зазвичай.

розташовується ідентифікатор об'єкта, властивості якого розкриваються в сегментах.

другого й існуючих рівнів иерархии.

Задля реалізації даної моделі на фізичному рівні використовується ряд стандартних.

методів розміщення даних на запам’ятовувальних пристроях, які можуть опинитися розміщувати.

сегменти такими ієрархічними способами доступу: послідовний,.

индексно-последовательный, прямий, индексно-прямой. Відповідно до способами.

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

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

від користувача знання шляхів доступу до даних, які пройшли по гілкам дерева.

ієрархічної записи. Що однією з недоліків даної моделі. У.

ролі інших недоліків можна назвати следующие:

Складність реалізації «багато до багатьох», потребує надмірності даних на.

фізичному рівні, що сприятиме небажаному і виправданого збільшення.

БД;

вимога підвищеної коректності до операції видалення, оскільки видалення.

вихідного сегмента тягне у себе видалення порожденных;

доступом до кожному породженому сегменту можлива лише через вихідний, що.

збільшує час відповіді а запит до БД.

У зв’язку з тим, що ієрархічна модель має велику кількість недоліків.

вона буде застосовується для моделювання розроблюваної АСИС.

2.2.2 Мережевий модель данных.

Мережа [5] - більш загальну структуру тоді як ієрархією. Вузлами мережі є.

окремі екземпляри записи. Вузли записи є одиницею доступу до БД.

Оскільки окремий вузол може мати кілька безпосередньо старших вузлів,.

як і, як і кілька безпосередньо підлеглих, то дана структура.

забезпечує пряме уявлення відносини «багато до багатьох». Для зв’язок між.

записями-узлами існує єднальна запис, всі екземпляри якої вкладаються у.

ланцюжок для зв’язку двох экземпляров.

Основний конструкцією мережевий моделі даних є набір. До кожного типу.

набору, що визначається у схемі, повинен бути вказаний певний тип записи.

власника набору, а як і довільне число типів записи членів набору. Кожен.

примірник набору складається з одного экземпляра-владельца і самого чи більше.

примірників записей-членов.

Кожен примірник записи-набора представляє ієрархічні зв’язок між.

примірником записи-владельца і відповідними екземплярами записей-членов. Це.

є наслідком того обмеження, що жодного примірник записи-члена з.

набору на може належати більш, ніж одному примірнику набору. Спосіб,.

яким кожен примірник записи власника пов’язують із відповідними.

екземплярами записей-членов, визначається схемою мережі. Однією з способів.

організації таких зв’язків є з’ясування ланцюжка покажчиків, які виходять із.

примірника записи-владельца, що пропливали всі екземпляри записей-членов і.

повертаються назад до примірнику записи-владельца, що забезпечує високу.

швидкість обробки запитів.

Головна вада мережевий моделі залежить від складності структур пам’яті.

Користувач має знати, які ланцюжка є і які відсутні. У.

результаті мову запитів процедурний і вимагає програмістських навыков.

2.2.3 Реляційна модель данных.

Реляційна модель — множинне ставлення яке є.

підмножина декартова твори списку доменів [27,20]. Домен — це.

безліч значень, з якого здобуваються значення для даного атрибута.

Інакше кажучи основу реляційної моделі лежать прості таблиці, які.

задовольняють певним обмеженням, тому можна розглядати як.

математичні відносини. Рядки таких таблиць називаються кортежами, імена.

шпальт — атрибутами. Слід зазначити, що це кортежі різні, а порядок.

шпальт довільний, ніж спрощується процес обробки кортежів. Що стосується.

(таблиці) виділяється кілька атрибутів, однозначно котрі ідентифікують кортежі і.

званих ключами.

Особливість реляційної моделі у тому, що у відмінність від мережевий і.

ієрархічної моделей реальні об'єкти і взаємозв'язку з-поміж них видаються в.

базі даних однаково як нормализованных відносин [24].

Основна хиба реляційної моделі даних пов’язують із низькою.

продуктивністю реляційної СУБД. Але розробка сучасних СУБД як-от,.

ORACLE, InterBase, Acsses та інших. дозволило подолати і це недостаток.

Переваги реляційної моделі можна розділити на дві группы:

гідності для пользователя:

реляційна БД є набір таблиць із якими користувач звик.

работать;

непотрібно пам’ятати шляху доступу до даних і будувати алгоритми і складні процедури.

обробки свого запроса;

реляционные мови легкі вивчення та освоєння, тоді як мови спілкування.

з ієрархічної і мережевий моделями призначені для програмістів мало.

придатні для пользователей;

гідності обробки даних реляційної БД:

зв’язність. Реляционное уявлення дає ясну картину взаємозв'язків атрибутів.

із різних отношений;

точність. Спрямовані зв’язку в реляційної БД відсутні. Відносини зі своєї.

природі мають точнішим здоровим глуздом і піддаються маніпулюванню з.

використанням засобів, як алгебра і літочислення відносин [5],.

які забезпечують наочність і гнучкість моделі данных;

гнучкість. Операції проекції й об'єднання [17] дозволяють розрізати і склеювати.

відносини, отже програміст може отримувати різноманітні файли у потрібній.

форме;

таємність. Контроль таємності спрощується. До кожного відносини є.

можливість завдання правомірності доступу, засекречені показники можна.

виділити в окремі відносини з перевіркою прав доступа.

Простота впровадження. Фізичне розміщення однорідних (табличных) файлів.

набагато простіше, ніж розміщення ієрархічних і мережевих структур.

Незалежність даних. БД повинна допускати можливість розширення, тобто.

додавання нових атрибутів і отношений.

Висновок: оскільки серед перелічених логічних моделей даних реляційна.

має значними перевагами і малими вадами, те вона й буде.

узята на основу побудови СУБД.

2.3 Вибір концептуальної модели.

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

Семантична модель;

Фреймы;

Модель «сущность-связь».

Семантична модель полягає в побудові семантичної мережі. Під.

семантичної мережею розуміють орієнтований граф, що з помічених.

вершин і дуг і ставить об'єкти й стосунку предметної області. Семантичні.

мережі мають також низку достоїнств, а именно:

Опис об'єктів предметної області відбувається природним языком;

Усі записи, які у БД накопичуються у досить однорідної структуре.

Але, попри ці переваги, семантична модель даних має низку.

недоліків, одна з яких і найсуттєвіший, у тому, що.

побудова реляційної моделі даних з урахуванням семантичних мереж утруднено.

Фрейми виражаються структурами даних із прив’язаними процедурами обробки цих.

даних. Фрейми може бути наступних видів: подієві, характеристики,.

логічні предикати. Використання фреймовой моделі як і недоцільно,.

оскільки ця модель не відбиває типи зв’язків [14] в реляційної моделі.

данных.

Модель «сущность-связь» описується в термінах сутність, зв’язок, значення.

Сутність — поняття що може бути ідентифіковано. Зв’язок — з'єднання.

сутностей. Для уявлення зв’язків і сутностей запроваджено спеціальний метод:

ER-диаграма [27]. Відрізняються сутності з трьох основних класів: стрижневі,.

асоціативні і характеристичні. Стрижнева сутність — це незалежна.

сутність (їй властиво незалежне існування). Асоціативна сутність чи.

асоціація сприймається як зв’язок між двома або як сутностями типу.

" багатодобагатьом «чи такі їм. Характеристичне сутність (чи.

характеристика) є сутність, єдина мету, якої, у межах.

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

інший сутності. ER-диаграма — графічне уявлення взаємозв'язків сутностей.

Кожне безліч сутностей представляється прямокутником, а безліч зв’язків -.

ромбом. Зв’язки може бути трьох типів: «одне одного», «один до багатьох», «багато.

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

що у реляційної моделі відповідають таблицы.

Висновок: у зв’язку з тим, що модель «сущность-связь» найближча на засадах.

організації до реляційної моделі і реалізація останньої з урахуванням першої.

найзручніша, то ролі концептуальної моделі обрано модель.

«сущность-связь».

2.4 Процес моделирования.

2.4.1 Виділення сущностей.

Сутність «постачальник» є стрижневою сутністю розроблюваної моделі. З.

постачальником полягає договір, виходячи з якої іде ця решта.

діяльність підприємстві на поставки, відправлення заявки постачальникам, отримання.

від нього рахунків-фактури, відправлення замовлення про поставки, отримання товару, оплата.

поставки. Як ключа для даної сутності вводиться атрибут № Постачальника.

Усі сутності, їх атрибути ключі представлені у табл. 2.1.

Таблиця 2.1.

Назва сущностиАтрибутКлюч.

Договір №Договору, дата договору, сума договору, термін действия.№Договора.

Постачальник №Постачальника, найменування постачальника, адресу, телефон.№Поставщика.

Асортимент товарів №Товару, найменування товара.№Товара.

Заявка№Заявки, асортимент заявки, номер договору, дата заявки.№Заявки.

Замовлення №Замовлення, №Договору, асортимент замовлення, дата замовлення, номер рахунки.

№Заказа.

Рахунок-фактура №Рахунки, асортимент рахунки, ціна за одиницю товару, сума.

счета.№Счета.

2.5 Побудова логічного модели.

Виконавши аналіз сутностей і зв’язків меду ними побудуємо логічний модель, як.

відносин (таблиця 2.2).

Таблиця 2.2.

Назва сущностиАтрибутКлюч.

Договір №Договору, дата договору, сума договору, термін действия.№Договора.

Постачальник №Постачальника, найменування постачальника, адресу, телефон.№Поставщика.

Асортимент товарів №Товару, найменування товара.№Товара.

Заявка№Заявки, номер договору, дата заявки.№Заявки.

Заявка №Заявки, №товару, количество.№Заявки, №Товара.

Асортимент заявки№Заказа, №Договору, дата замовлення, номер рахунки. №Заказа.

Асортимент заказа№Заказа, №Заявки, №товара.№Заказа, №Заявки, №товара.

Счет-фактура№Счета, сума счета.№Счета.

Ціни поставщика№Счета, №Заявки, №Товара.№Счета, №Заявки, №Товара.

Для побудови логічного моделі даних використовувалося case — засіб.

[17] ER-Win, що дозволяє проектувати реляционные моделі даних як.

на фізичному рівні (ER-диаграмы), і на фізичному (проектування.

таблиць БД).

Логічний модель даних представленій у вигляді ER-диаграмы на рис. 2.2.

Рис 2.2 ER-диаграмма моделі даних АСИС «Облік поставок».

3. Проектування алгоритмів довідково-інформаційної системи обліку й контролю.

поставок на предприятие.

Алгоритмизация у найзагальнішому вигляді може бути оцінена як процес.

спрямованого дії проектувальника (групи проектувальників), необхідний.

вироблення алгоритмів, достатніх для реалізації створюваного об'єкта (системи),.

задовольняючого заданим вимогам [19]. Завершальним етапом алгоритмізації.

є виготовлення набору алгоритмів, відображає рішення, прийняті.

проектувальником, у вигляді, яка потрібна на виробництва об'єкта (системи). При.

проектуванні системи я використовував три класу алгоритмов:

Алгоритми, пов’язані з проектуванням АСИС;

Алгоритми реляційної алгебри, необхідних роботи з БД;

Алгоритми розрахунку необхідних показників (обчислення заборгованості підприємства.

за оплатою поставок, визначення оптимального счета-фактуры).

3.1 Вибір методу проектування АСИС.

Метод — це послідовний процес створення моделей, які описують цілком.

певними засобами різні сторони розроблюваної програмної системи.

[18]. Методи важливі з кількох причин. По-перше, вони упорядковують процес.

створення складних програмних систем. По-друге, вказують менеджерам в.

процесі вироблення оцінити рівень просування і риск.

Зазвичай методи проектування діляться втричі основні группы;

Метод проектування згори вниз;

Метод потоків данных;

Объектно-ориентированное проектирование.

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

відзначити, більшість програм написаний відповідно до цього методом. Тим.

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

обмеження доступу до даних; він теж надає достатніх засобів для.

організації паралелізму. Структурний метод може забезпечити створення.

гранично складних систем, і він, зазвичай, неефективний в об'єктних і.

объектно-ориентированных мовами програмування. Тому цей метод не.

використовувався для проектування АСИС «Облік поставок».

У методі потоків даних програмна система сприймається як перетворювач.

вхідних потоків у вихідні. Метод потоків даних із успіхом застосовувався при.

рішенні низки складних завдань, зокрема, в системах інформаційного.

забезпечення, де є прямі зв’язок між вхідними і вихідними потоками.

системи та де немає потрібно приділяти особливої уваги швидкодії. Але оскільки.

однією з основних вимог що висуваються до проектованої АСИС є.

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

оформлення поставок для підприємства, застосування цього методу також.

недоцільно для проектування АСИС.

Объектно-ориентированное проектування (object-oriented design, OOD)—это підхід.

основу якого уявлення у тому, що програмну систему потрібно.

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

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

утворюють ієрархію. Объектно-ориентированный підхід відбиває топологію новітніх.

мов високого рівня, як-от Object Pascal, З++, Smalltalk [23] та інших.

Моделі, для проектування якої використовується вищезгаданий підхід.

проектування притаманні чотири головних элемента:

Абстрагирование;

Инкапсуляция;

Модульность;

Иерархия.

Абстрагування дає можливість окреслити суттєві характеристики проектованого.

об'єкта, що відрізняють його з інших объектов;

Інкапсуляція — процес відділення друг від друга елементів об'єкта, визначальних.

його будова та поведінка. Вона дозволяє ізолювати контрактні зобов’язання.

абстракції від своїх реализации.

Модульність — властивість системи, що була розкладена на внутрішньо зв’язкові, але.

слабко пов’язані між собою модулі.

Ієрархія — упорядкування абстракцій, розташування їх за уровням.

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

спостереження поведінки об'єкта ззовні, а інкапсуляція визначає чітких меж.

між різними абстракціями, тобто. стеження поведінкою об'єкта изнутри.

Використання цих елементів проектування й дозволяє приймати значно більшу.

продуктивність будь-який проектованої системы.

Отже, для проектування АСИС використовується объектно-ориентированный.

подход.

3.2. Аналіз алгоритмів роботи з базою данных.

Систему керування розробленої БД використовує реляционный підхід для побудови.

бази даних [20]. Такі системи засновані на реляційної моделі даних,.

що використовуються моделювання взаємозв'язків між об'єктами реального.

світу й у зберігання даних про ці об'єктах. Застосування реляційної моделі.

даних [27] зумовлено використанням реляційної алгебри і лобіювання відповідних.

алгоритмів і операцій до виконання дій над даними. Використання.

алгоритмів реляційної алгебри [20] дозволяє забезпечити високу.

продуктивність роботи з базою данных.

Основні операції реляційної алгебри були вперше запропоновані Коддом [26]. Він.

довів, що запити, формулируемые з допомогою мови обчислення може бути.

сформульовані в мовами реляційної алгебри і навпаки [18], тобто запити.

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

виконання запитів до розробленої БД. Нижче наведено ряд запитів до БД:

SELECT nomer_dogovora, postav. nomer_postav, dogovor. nomer_postav,.

naimen_post.

FROM postav, dogovor.

WHERE postav. nomer_postav=dogovor.nomer_postav.

SELECT select nomer_zajavki, zajavka. nomer_dogovora,.

dogovor.nomer_dogovora, naimen_post, postav. nomer_postav,.

dogovor.nomer_postav.

FROM from zajavka, dogovor, postav.

WHERE (zajavka.nomer_dogovora=dogovor.nomer_dogovora).

AND (postav.nomer_postav=dogovor.nomer_postav).

SELECT nomer_zakaza, zakaz. nomer_dogovora, dogovor. nomer_dogovora,.

naimen_post, postav. nomer_postav, dogovor. nomer_postav.

FROM zakaz, dogovor, postav.

WHERE (zakaz.nomer_dogovora=dogovor.nomer_dogovora).

AND (postav.nomer_postav=dogovor.nomer_postav).

Розглянемо чотири операції над відносинами [20]:

Селекция;

Проекция;

Теоретико-множественное объединение;

Соединение.

Селекція (selected_on — піддані селекції по) зменшує кількість рядків.

таблиці, і можна уявити, як результат розрізування таблиці за горизонталлю.

і видалення непотрібних кортежів. Формально селекція записується так:

R selected_on [] {синтаксис мови запитів (SQL)}.

Тут — це логічне вираз, що може утримувати порівняння.

значень одних атрибутів зі значеннями інших у тому самому кортежі чи з.

константами. Через війну зберігаються лише рядки, задовольняють.

.

Операція селекції відповідає програмам, які вибирають записи з файлів і.

друкують ці записи. Проте умови відбору можуть стосується лише окремо.

узятим записів. Наприклад, неможливо вибрати запис, з те, що.

значення будь-якого її поля одно чи більше, ніж значення цієї поля була в.

предидущей записи. Насправді ж майже неможливо змоделювати поведінка.

автомата з кінцевим числом станів, який змінює свою стан кожної.

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

Проекція (projected_to — спроецированное на) зменшує кількість шпальт в.

таблиці; цю операцію можна уявити як розрізування за вертикаллю.

назва операції має своїм джерелом поняття проекції безлічі точок.

N-мерного простору у просторі із меншим кількістю вимірів. Наприклад,.

внаслідок проекції безлічі точок площині (Х, У) на вісь Х виходить.

безліч точок, розташованих в цій осі. На жаль, значення проекцій.

деяких «точок» можуть збігатися; це у тому випадку, коли проекція.

віддалить стовпець, входить у ключ, отже частини двох «укорочених».

кортежів може бути ідентичними. Тоді доведеться видалити дублікати і тим самим.

зменшити кількість рядків, тобто. розмір БД. Коли б одне із можливих.

ключів і під час проекції залишиться незачепленим, то дублікатів не будет.

Формально проекція записується наступним образом:

R projected_to {, }.

Де список означає імена сохраняемых шпальт.

Операція проекції відповідає програмі відбору трохи інакше, ніж.

операція селекції, саме, вона друкує певні поля з кожного запису.

Видалення дублікатів зазвичай буває у результаті сортування записів по.

потрібним полях, після чого записи пропускаються до того часу, доки зміниться.

значення поля. Насправді за одного перегляді файла операція проекції зазвичай.

приміром із операцією селекции.

Теоретико-множественное об'єднання (union) має дві операнда; вона бере рядки.

двох таблиць і розміщає їх одне за іншому, формуючи одну довгу таблицю. Це.

можливе лише тому випадку, коли обидві таблиці мають і той ж тип, тобто.

мають збіжні назви (імена) і типи шпальт. Такі таблиці називають.

«сумісними з об'єднання». Усі дублікати рядків мали бути зацікавленими віддалені з.

отношения-результата. Ця операція аналогічна об'єднанню множин в алгебрі,.

але є додаткової стосовно обмеження, оскільки є.

можливість відновити ставлення шляхом поєднання двох доповнюють одне одного.

результатів операції селекции.

Операція теоретико-множественного відносини відповідає відомої операції.

«злиття» файлів. Якщо відомо, що файли не перетинаються, і якщо порядок.

записів не играетроли, досить скопіювати один файл наприкінці іншого.

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

використовуються прості алгоритми злиття., що зчитують по черзі записи з.

кожного файла залежно від цього, у якому з файлів запис має ключ з.

меншим значенням полів, отож у новий файл записи також будуть поміщатися в.

порядку первинних ключей.

Поєднання (joined_to — з'єднання з) має дві операнда; її визначено для.

будь-яких двох таблиць. Якщо такі дві таблиці немає шпальт з збігаються.

іменами, то з'єднання поводиться, як декартово твір, поєднуючи кожну.

рядок першої таблиці по черзі з кожним рядком другий таблиці. Якщо імена.

всіх шпальт цих двох таблиць збігаються, то з'єднання поводиться як.

теоретико-множественное те що, і це створює таблицю, що складається з тих рядків,.

що зустрічаються у кожному з аналізованих двох таблиць (така таблиця може.

це бути й порожній, аналогічно порожньому безлічі). Якщо в двох таблиц-операндов.

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

таблиця, що містить все імена шпальт першої таблиці, і навіть всі ті імена.

шпальт другий таблиці, які зустрілись у першої. Рядки результату.

вибираються з першого таблиці, а додаткові значення конкатенируются.

(приєднуються) з тих рядків другий таблиці, які мають значення загальних.

шпальтах збігаються. До певної міри сполуки є доповненням.

проекції, якщо здійснити проекцію «вихідного» відносини те щоб вийшов.

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

з'єднання цього стосунки відновить вихідне при додатковому умови, що.

кожен стовпець вихідного відносини зустрічається хоча в одній з проекцій.

При формулюванні запитів операція сполуки є вирішальної, тоді як.

запиті використовується понад одного відносини. Зазвичай, на формування.

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

рядків, і, нарешті, проекція на необхідні стовпчики для друку.

Операція сполуки найбільше відповідає операції «селективною вибірки»,.

і під час якої список ключів подано у вигляді записів в файлі.

транзакцій [19], і потрібно вибрати чи записати в вихідний файл.

відповідні записи з основного файла. Ключі в файлі транзакцій можуть.

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

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

бути вибрано кілька записів з основного файла. Отже, використовується.

з'єднання як узагальнену те що [20].

Алгоритми, які виконують перелічені вище операції, реалізуються лише на рівні.

системи управління базою даних. Їх зміст формується з урахуванням визначень.

операцій. Для реалізації використовуються чи стандартні функції мови.

програмування, чи формується SQL-запрос. Докладніше реалізація буде.

розглянута у наступному главе.

3.3. Проектування алгоритмів розрахунку боргу оплаті постачання і.

визначення оптимальної заявки.

4. Вибір коштів на розробки АСИС, опис структури АСИС.

4.1 Вибір апаратних средств.

При виборі апаратних коштів на розробки АСИС найбільшу роль грає чинник.

швидкодії роботи ПЕОМ. Оскільки від нього залежить час розробки.

ПО, відповідно витрат за розробку й його собівартості.

Швидкість функціонування ПЕОМ переважно такими параметрами:

Обсягом оперативної пам’яті (ОП);

Швидкодією процессора;

Обсягом відеопам'яті (ВП).

З вимог що висуваються до що використовуються програмним засобам.

розробки (Delpi 3.0 InterBase 4.2) мінімальне значення перелічених вище.

параметрів становить ВП — 12 МБ, процесор — з урахуванням Intel 486, ВП — 1 МБ.

При мінімальних значеннях параметрів функцмонирование розробленої АСИС.

малоефективно, тому рекомендуемым є комп’ютер з такими.

значеннями параметров:

Процесор — intel 586−100 МГц;

Оперативна памть — 16 Мб;

Видеопамять — 1 Мб;

4.2. Аналіз і вибір програмних засобів розробки АСИС.

Сучасні кошти розробки ПО характеризуються більшою розмаїтістю.

критеріїв, используюя які розробник має можливість автоматизувати.

процес розробки додатків. Так було в час інструментальні кошти.

позволяют:

створювати інтерфейс испльзуя стандартні компоненты;

передавати управління різним процесам, залежно стану системы;

створювати оболонки для баз даних, як і держава сама бази данных;

розробляти надійніше ПО, шляхом обробки виняткових ситуацій.

які виникають за некоректною роботі ПО.

Сучасні кошти розробки характеризуються такими параметрами:

підтримка объектно-ориентированного стилю программирования;

зокрема можливість використання CASE-технологий, як проектування.

розроблюваної системи, так розробки моделей реляционных баз данных;

використання візуальних компонент для наочного проектування интерфейса;

підтримка БД;

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

реляционными базами данных;

можливість синхронізації складових частин проекту (надається при.

розробці великих програмних комплексов).

Переліченими Вище властивостями мають мови програмування, наприклад: Delphi,.

Visual З++, Borland З++ Biulder, Visual FoxPro і другие.

Кожна з цих коштів містить всього спектра сучасного інструментарію, який.

перераховано раніше. Головна відмінність полягає у галузі використання.

аналізованих коштів. Так Visual З++ зазвичай використовується розробки.

додатків виділені на роботи з ОС Windows, використовують основні.

властивості ОС [1], а як і виконують дуже багато вычислений. 12] Одним.

з якихось вад даного кошти розробки додатків є високе.

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

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

кінцевий продукт (ПО), використовуючи цей продукт необхідно більше дискове.

простір, аніж за створенні аналогічного ПО іншими засобами розробки.

Borland З++ Biulder за своїми недоліків аналогічний Visual З++, але має ще.

одним — розробка баз даних з урахуванням мови SQL та його підтримка обмежена.

Система розробки Visual FoxPro пред’являє найменші вимоги до системним.

ресурсів, та її застосування обмежена незручністю в візуальному створенні.

інтерфейсу розроблюваного докладання. Недоліком Delphi у тому, що.

за його використанні немає достатнього доступу функцій ОС, але цей.

недолік є несуттєвим, оскільки розроблювальне додаток орієнтоване на.

підтримку БД, а чи не працювати з ОС. Чимале значення під час виборів Delphi як.

кошти на розробки АСИС грає зокрема можливість використання великого.

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

до створення СУБД.

Під час створення програмного продукту АСИС «Облік поставок» головний критерій вибору.

програмних засобів розробки являлись:

швидкість розробки приложений;

можливість швидкого внесення змін — у программу;

можливість редагування і перегляду БД, використовуючи кошти разработки.

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

підтримки обраним інструментарієм ОС, апаратної підтримки, яка потрібна на їх.

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

використання відповідних програмних засобів. Забезпечити мінімальне час.

розробки можна за виконання цих условий.

З наведених вимог, виділимо такі характеристики коштів.

розробки програмного обеспечения:

Наявність досвіду розробки з допомогою даного програмного продукта;

Вимоги по ресурсам;

Підтримка операційній системы;

Наочність розробки интерфейса;

Надані можливості роботи з базами данных;

Доступность;

Швидкість роботи розробленого програмного обеспечения;

Обробка виняткових ситуаций;

Час створення розробленого програмного обеспечения;

Зручність эксплуатации;

Для перелічених вище коштів на розробки АСИС скористаємося методом.

варіантних обгрунтувань. Цей метод призначений для вибору найкращого варіанта.

з кількох запропонованих і складається з таких этапов:

Визначення критеріїв, за якими вироблено порівняння і рівня їх.

важности.

Кожен варіант оцінюється по одержаному переліку критеріїв. Виходить.

чисельна значення — оценка.

Перебування загальної кількості балів кожного з варіантів (можна враховувати.

важливість критеріїв).

Кращим вважається варіант, набравши якомога більше баллов.

Аби вирішити поставленого завдання використовуватимемо перелік характеристик,.

наведений раніше.

Результати наведені у таблиці 4.1.

Таблиця 4.1.

Засіб разработки.

Характеристика коштів розробки.

Delpi.

Visual З++.

Borland З++ Buielder.

Visual FoxPro.

Наявність досвіду розробки з допомогою даного програмного.

продукта;8644.

Вимоги по ресурсам;7665.

Підтримка операційній системы;8887.

Наочність розробки интерфейса;9785.

Надані можливості роботи з базами данных;8647.

Швидкість роботи розробленого програмного обеспечения;6787.

Обробка виняткових ситуаций;8886.

Час створення розробленого програмного обеспечения;9657.

Зручність эксплуатации;7887.

Всего:70 626 056.

Висновок: Через війну виконаного аналізу інструментальних коштів виявили, що у.

ролі засобів розробки АСИС буде використано Delphi, як найбільш.

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

Використовуючи Delphi можна докладання для MS Windows95/98/NT з.

мінімальними витратами часу т.к. у її основі лежить концепція швидкого.

створення додатків (RAD).

Основні інформацію про Delphi [15,16,17]:

Базується на розширенні мови Pascal — Object Pascal.

Інтегрована середовище розробки додатків — дозволяє створювати,.

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

середовищі программирования;

Візуальна технологія розробки програм — дозволяє швидко створювати.

докладання шляхом розміщення у формі стандартних компонентів. У цьому.

відповідний код програми автоматично генерується Delphi. Така.

технологія звільняє розробника від рутинної робота зі створення.

користувальницького інтерфейсу і дозволяє приділити більше уваги внутрішньої.

організації даних, і обробці данных.

Технологія Two Ways Tools робить ефективнішою роботи з компонентами. При.

зміні програмного коду з вікна редактора Delphi відповідним чином.

змінює й які самі компоненти. З іншого боку, за зміни властивостей компонентів.

в інспектора редактора об'єктів (Object Inspector) вони негайно позначаються на.

вікні редактора кода.

Бібліотека компонентів містить багато стандартних компонентів, які можна.

використовувати під час створення додатків. Сюди відносяться елементи управління у стилі.

Windows95 і IE 4.0, і навіть шаблони для форм і экспертов.

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

широко використовуються компоненти, призначені до роботи з базами даних. З їхніми.

допомогою можна прості докладання, призначені в обробці.

даних, і додатки типу клиент/сервер. Особливістю цих компонентів є.

те, що під час створення докладання Delphi відображає результати обробки.

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

своєю практикою програми. З іншого боку підтримка баз даних в Delphi.

здійснюється з допомогою набору драйверів сполук з SQL-северами Borland SQL.

Links for Windows, що дозволяють інтегрованому в Delphi ядру процесора.

баз даних Borland, (BDE) Borland Database Engine, отримувати доступом до локальним.

баз даних Paradox, dBASE, Access, FoxPro, і навіть SQL-северам InterBase,.

Informix, Oracle, Sybase, DB2, Microsoft SQL.

32-битовый компілятор Delphi генерує виконувані EXE-файлы. У цьому.

є можливість генерувати або прості EXE-файлы, або складні.

докладання, потребують підключення DLL-библиотек.

Delphi — це перший інструмент у якому швидке проектування узгоджується з.

використанням оптимизирующего компілятора [3]. З іншого боку, в Delphi то, можливо.

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

складної технологією програмування, яка коли-небудь використовувалася для.

персональних комп’ютерів. На відміну більшості інших інструментів,.

виділені на швидкої розробки додатків, Delphi є расширяемым.

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

розширюваність Delphi:

Безпосередній доступом до інтерфейсу додатків АПІ;

Вмонтований Асемблер; обробка рядків, написаних на Ассемблері вставлених в.

текст програм Delphi;

Можливість створення користувальних об'єктів VCL і OCX;

Можливість створення DLL-библиотек та інших «вторинних «об'єктів середовища Windows;

Объектная орієнтація — можливість створювати нові класи, наследующие властивості.

існуючих класів, або, почавши від початку, будувати свої собственные.

Однією з основних критеріїв, під час виборів інструмента розробки додатків баз.

даних є масштабованість можливість працювати з даними у різних.

платформах. Масштабованість в Delphi досягається завдяки наступним властивостями.

[ ]:

Підтримка як локальних таблиць, і що є на віддалених серверах баз.

данных;

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

Управління Базами Даних (СУБД), збудованим в різних платформах;

Вільне переміщення докладання з однієї СУБД до іншої, здійснюване.

у вигляді ядра Borland Database Engine, яке організує доступом до баз.

даних, попри розбіжності в платформах;

Наявність власних швидких драйверів для основних платформ типу клиент/сервер;

Повна підтримка ODBC.

Delphi, як СУБД, цілком орієнтований на реляционную модель даних, і має.

вмонтований мову запитів до баз даних SQL (Structured Query Language).

4.4. Опис программы.

4.4.1. Опис интерфейса.

Після запуску файла postavki. exe виконання через монітор з’являється головне.

меню (рис 4.1):

Рис 4.1 Головне меню АСИС.

Спочатку роботи з програмою необхідно з'єднатися з базою даних, навіщо.

клацнути за командою меню з'єднається з БД. Коли комп’ютері користувача.

встановлено InterBase Local Server і створено база даних, то з’явиться запит на.

підтвердження права доступу до БД (рис 4.2):

Рис 4.2 Вікно введення пароля.

Пароль доступу Khai.

Що стосується, якщо з'єднання минуло успішно, то користувач допускається роботи з.

АСИС.

4.4.2 Фундаментальна обізнаність із режимами АСИС.

Робоча вікно АСИС виглядає так (рис 4.3):

Рис 4.3 Робоча область АСИС.

Нижче описана роботу з АСИС.

Фундаментальна обізнаність із договорами.

Фундаментальна обізнаність із договорами включає в себя:

— Фундаментальна обізнаність із поставщиками;

— Фундаментальна обізнаність із договорами;

— Фундаментальна обізнаність із товарами;

— Фундаментальна обізнаність із ув’язненими договорами;

— Фундаментальна обізнаність із асортиментом договоров;

Договір укладається підприємством-замовником з предприятием-поставщиком на.

поставку певного виду та асортименту продукції. З одним постачальником може.

бути укладено кілька договорів. Як атрибутів договору є.

такі поля: номер договору, код постачальника, дата договору, сума договору,.

термін дії договору. Усі атрибути, крім термін дії договору є.

обов’язковими заповнення. З договору виробляється подальша.

діяльність із поставкам для підприємства. Вона в:

— Фундаментальна обізнаність із заявками;

— Робота зі счетами;

— Фундаментальна обізнаність із заказами.

Для автоматизації використання АСИС «Облік поставок» реалізована можливість.

друку бланків документів договору, заявки, замовлення.

Додавання нової угоди здійснюється шляхом вибору відповідної закладання.

і введення тексту в поля-атрибуты таблиці. Додавання за умови, що з.

який додається договору відомий поставщик.

Редагування відбувається за натисканні клавіші Enter на обраної записи.

Відбувається автоматичне зміна всіх полів інших таблиць що з номером.

редагованого договору. Це зміна необхідне підтримки ссылочной.

цілісності в БД.

Для видалення певного договору необхідно двічі клацнути правої кнопкою.

миші на удаляемом договорі. Автоматично підуть все записи пов’язані з.

удаляемым договором (заявки, рахунки-фактури, заказы).

Фундаментальна обізнаність із поставщиками.

Фундаментальна обізнаність із постачальниками полягає у додаванні нового постачальника, його атрибутів,.

видаленні постачальника, редагуванні атрибутів постачальника: код постачальника (для.

кожного постачальника код унікальний), найменування постачальника, адресу.

постачальника. Усі атрибути, крім телефону є обов’язковими заповнення,.

у випадку їхньої незаполнения виникає ошибка.

Додавання постачальника виробляється так: користувач вибирає.

відповідну таблицю і продовжує заповнювати атрибути поставщика.

Для редагування таблиці «постачальники» потрібно вибрати запис для редагування.

натиснути клавішу Enter та змінити необхідну інформацію. Змінені атрибути.

постачальника автоматично змінюються за іншими таблицах.

Видалення записи «постачальник» відбувається шляхом подвійного щиглика мишею на удаляемой.

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

Фундаментальна обізнаність із товарами.

Таблиця «товари» є довідник товарів, що поставляються на.

підприємство. Атрибути цієї таблиці містять унікальний код кожному за товару і.

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

таблицю асортимент договору.

Додавання нової запис у таблицю здійснюється шляхом введення інформації про товарі.

у поетичні рядки таблиці товари. Редагування — натисканням клавіші Enter на.

редактируемой рядку і зміні информации.

Видалення — подвійним клацанням миші на удаляемой строке.

Фундаментальна обізнаність із ув’язненими договорами.

Фундаментальна обізнаність із даної таблицею для користувача обмежена, оскільки для її.

заповнення служать раніше заповнені таблиці (договір, поставщик).

Фундаментальна обізнаність із асортиментом договоров.

Фундаментальна обізнаність із асортиментом договорів залежить від додаванні, редагуванні і.

видаленні найменування товару чи товарів, які постачальник зобов’язується поставити.

замовнику виходячи з переліку поставлених товарів, указываемом в укладеному.

договорі. Вказані вище операції проводяться аналогічно операціям регулярно працюють з.

договорами.

Фундаментальна обізнаність із заявками.

Фундаментальна обізнаність із заявками є роботи з трьома закладками:

— Заявка;

— Асортимент заявки;

— Усі заявки.

Закладання «заявка» містить таблицю з цими про заявках, які зробив замовник.

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

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

обов’язковим. Номер договору одне із ув’язнених, інакше виникає.

помилка.

Користувач має можливість додавати, редагувати і видаляти записи.

Додати запис за разі коли таблиця активна, тобто. користувач.

здійснює роботу з нею. Таблиця автоматично перетворюється на режим додавання.

записів при натисканні користувачем клавіші на порожній рядку, або натисканням.

клавіші Insert. Для редагування необхідно вибрати запис для редагування.

і, натиснувши клавішу Enter зробити редагування необхідного поля записи.

Видалення відбувається шляхом подвійного щиглика мишею на обраної видалення.

записи.

Закладання «асортимент товарів» містить таблицю з цими про зробленою заявці, а.

саме: номер заявки, номер товару, кількість замовленої продукції прийнятих.

одиницях виміру (прим., кг., л., тощо.). все атрибути є обов’язковими до.

заповнення. З іншого боку, номер товару (код товару) може бути обраний тільки з.

номерів товару, які зазначені у довіднику товарів.

Видалення, додавання і редагування записів відбувається аналогічно закладанні.

заявка.

Робота зі счетами.

Для робота з рахунками пропонується закладання «рахунок-фактура», що містить.

таблицю рахунки і полі визначення оптимального рахунки. Таблиця «рахунки».

включає атрибути: номер рахунки, номер заявки, номер договору, сума рахунки. Усі.

атрибути обов’язкові заповнення. Асортимент рахунки відповідає.

асортименту заявки. На закладку виводиться інформація (або дається.

введення) тільки з одного ув’язнений договорів, номер якого обраний в.

таблиці асортимент договорів.

Фундаментальна обізнаність із заказами.

Робота з замовленнями пропонується дві закладки:

— Заказ;

— Усі заказы.

У закладку «замовлення» включені таблиця «замовлення» з атрибутами: номер

замовлення, номер договору, номер рахунки, отримано, оплачено, і полі визначення.

заборгованості підприємства з оплаті виконаних поставок. Користувачу.

дають можливість додавання, редагування і видалення записів. Усі.

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

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

Заповнення полів таблиці оплачено і отримано можна проводити з выпадающего.

списку з цими двома рядками (так, нет).

Якщо ж борг за оплатою поставок відсутня, то полі «борг» приймає.

значення «нет».

Закладання «все замовлення» є таблицю з переліком всіх замовлень.

зроблених за всі укладених договорів. Що-небудь у ній змінювати користувач не.

має возможности.

Печать.

Закладання «печатку» використовується до друку бланків договорів, заявок, замовлень.

Для вибору документа, що необхідно надрукувати слід вибрати.

відповідний флажок.

5. Випробування програмного продукта.

Надійність програмного забезпечення (ПО) є можливість його роботи без відмов.

протягом певного періоду часу, розрахована з урахуванням вартості для.

користувача кожного відмови [9]. Надійність програмного забезпечення як.

визначальний елемент його якості закладається на етапі розробки та.

проектування, реалізується на етапі реалізації ПО [11]. Вибір критеріїв,.

що ними визначаться надійність ПО, пошук оптимальної стосовно.

цим критеріям його структури, вибір режиму роботи ПО — ось далебі неповний.

перелік тих проблем, що їх вирішені на етапі створення та її реалізації.

ПО до його експлуатації. Тож забезпечення надійності ПО найчастіше.

використовують такі терміни, як доказ, тестування, налагодження, контроль і.

випробування, які найчастіше використовують як синоніми, тому наведемо ці.

определения:

Тестування (testing) — процес виконання програми або це частини програми, з.

наміром чи метою знайти ошибки;

Доказ (proof) — спроба знайти помилки у програмі безвідносно до.

зовнішньої для програми середовищі. Більшість методів докази передбачає.

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

математичних теорем правильність программы.

Контроль (verification) — спроба знайти помилки у тестової, чи моделируемой.

среде;

Випробування (validation) — спроба знайти помилки, виконуючи програму заданої.

реальної среде;

Атестація (certification) — авторитетне підтвердження правильності програми.

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

певним стандартом;

Налагодження (debugging) перестав бути різновидом тестування. Хоча «налагодження» і.

«тестування» часто використовують як синоніми, під ними маються на увазі різні.

види діяльності. Тестування — діяльність, спрямовану виявлення.

помилок; налагодження спрямовано встановлення точної природи відомої ошибки.

5.1. Довідкові документы.

Випробування програмного продукту виробляються з допомогою наступній.

довідкової литературы:

ГОСТ Р28 195−89 Оцінка якості програмних средств.

ISO/IEC 9126: 1991 Information Technology Software Product Quality.

Characteristics.

Стандарти розробки ПО ESA PSS-05−0-1991.

5.2. Короткий огляд верифікації .

Емпірична перевірка обозначает:

дія з перевірці, інспекції, тестуванню, контролю процесів, певних.

вимогами ANSI -78.

процес визначення: задовольняє чи продукт даної фазі ЖЦ ПО вимогам,.

сформульованим протягом попередніх фаз;

формальне доказ коректності программы.

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

Ряд визначень, приведений нижче, охоплює другу бік тестування: типи.

помилок, що передбачається знайти, і стандарти, із якими.

сопоставляются тестируемые программы.

Тестування модуля чи автономне тестування — контроль окремого.

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

інших модулів). Тестування модуля іноді також включає математичне.

доказательство.

Тестування сполучень — контроль сполучень між частинами системи (модулями,.

компонентами подсистемами).

Комплексне тестування — контроль і/або випробування системи з відношення до.

вихідним цілям. Комплексне тестування є процесом контролю, коли вона.

виконується в моделируемой середовищі, і процесом випробування, якщо виконується в.

середовищі реальної, жизненной.

Тестування прийнятності - перевірка відповідності програми вимогам.

пользователя.

5.3. Процеси верификации.

Верифікацію, тестування й випробування розроблюваної системи продукуватимемо.

відповідно до стандартами ES-PSS-05.

Процес верифікації включає в себя:

технічні перевірки, наскрізні контролі і інспекції ПО;

перевірки те, що вимоги до ПО відповідають потребам заказчика;

перевірки те, що вимоги нині проектом є відповідними вимогам.

ПО;

автономне тестирование;

системне тестирование;

приёмочное тестирование;

ревизии.

З вище викладеного, було проведено тестові випробування програмного.

продукта.

5.3.1. Наскрізний контроль.

Ефективний прийом оцінки детальних зовнішніх специфікацій — підготувати тести та.

потім скористатися докладними зовнішніми специфікаціями для імітації поведінки.

системи. Цей процес відбувається часто називають наскрізним контролем [10] чи прослеживанием.

Для перевірки окремих зовнішніх функцій потрібно виконати такі дії.

Хтось (не автор специфікацій) повинен спочатку побудувати «тести на папері» для.

цієї функції, тобто. список конкретних вхідних даних (допустимих і неприпустимих).

Разом з автором специфікацій потім імітують введення цих даних до системи,.

використовуючи специфікації як опис поведінки системи. Якщо виявляється, що.

специфікації описують вихідних даних чи перетворення для якогось набору.

вхідних даних недостатньо повно і, це, що виявлено.

ошибка.

Важливо, що мета будь-якого такого сеансу наскрізного контролю — знайти.

помилки, але з виправляти їх сразу.

Використовуючи даний прийом тестування, були протестовані запити здійснювані.

до бази даних (БД) створеної системи. І тому на вхід подавалися різні.

запити до БД (Див. додаток B).

У результаті проведення тесту було зафіксоване, що коректні запити.

обробляються БД відповідно до гаданому результату, час обробки запиту.

відповідає зазначеному в ТЗ (трохи більше 3 секунд при мінімальної конфігурації,.

процесор Intel 586). При спробі здійснити некоректне запит до БД який завжди.

видаються повідомлення помилки, або зазначено що насамперед необхідно.

зробити правильної роботи системы.

5.3.2. Трасування вимог до ПЗ проведено та вимог пользователя.

Для перевірки вимог до ПЗ проведено та вимог користувача на повноту.

(пошук всіх пропущених вимог), тобто. задоволення всіх своїх вимог.

користувача в програмному продукті, і відсутності такої неоднозначності застосовується.

матриця трассировки.

Відповідність вимог перевірялося на ранніх стадіях ЖЦ програмного продукту.

Використовуючи матрицю трасування було встановлено повну відповідність між.

вимогами користувача та вимогами до ПО, неоднозначності у вимогах.

виявлено були. (див. ТЗ «Матриця трассировки»).

5.3.3. Тестування зовнішніх функций.

Мета тесту зовнішньої функції - знайти розбіжності між програмою і її зовнішніми.

специфікаціями. Необхідною умовою успішного тестування функцій є.

наявність чітких і точних зовнішніх специфікацій. Якщо зовнішні специфікації неповні.

чи неоднозначні, результатів тестування мусять приносити стільки же.

Зовнішні специфікації зазвичай розбиваються деякі зовнішні функції (наприклад,.

на кшталт вхідних повідомлень чи команд користувача), і після докладного вивчення.

кожної функції будуються тести. Тести мають будуватися всім вхідних умов і.

варіантів, і навіть межах всіх галузей допустимих значень на вході і.

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

функціональних кордонів Шотландії й у випадках і у разі введення неприпустимих чи.

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

засновану на функціональних діаграмах (cause-effect graphing).

Тестування функцій — процес контролю, оскільки він зазвичай виконується в.

моделируемой середовищі (на противагу обстановці реальної). Інакше кажучи,.

тестування функцій зазвичай виконується для компонент системи колись, що вона.

буде зібрано воєдино. Наприклад, може бути недоступні певні устрою.

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

імітації його роботи, можуть відсутні або бути неповними окремі компоненти.

програмного забезпечення, що також зажадає імітації чи застосування.

допоміжних программ.

Метод функціональних диаграм [11], пропонує спосіб переказування специфікацій,.

написаних природному мові, мовою формальний. Це.

проектування высокорезультативных тестів, не котрі страждають надмірністю, і.

обнаруживающих випадки неповноти і неоднозначності у вхідних специ-фікаціях.

Метод передбачає аналіз семантичного змісту зовнішніх специфікацій і.

переклад їх у мову логічних відносин між вхідними даними (ситуаціями) і.

вихідними даними і перетвореннями (ефектами), які у вигляді.

логічного діаграми («іили"-графа), званої функціональної диаграммой.

Діаграма постачається примітками як синтаксичних правив і обмежень.

зовнішнього середовища й потім перетворюється на таблицю рішень з обмеженою входом.

Кожен стовпець таблиці відповідає майбутньому тесту.

Послідовність застосування метода:

Перший крок: розбити зовнішні специфікації деякі функції, комбінаторні.

властивості яких і було повинні тестироваться;

Другий крок: проаналізувати специфікації у пошуках всіх явних і неявних.

ситуацій (умови на вході) і ефектів (дії не вдома). Найкраще робити.

це, підкреслюючи кожну ситуацію й у ефект, тоді як вони.

зустрічаються під час читання специфікацій. Усі ситуації та ефекти нумеруються.

довільним образом.

Третій крок: намалювати функціональну діаграму. Ситуації зображуються як.

вершин лівому краю листи паперу, а ефекти — правому.

Четверте крок: перетворити діаграму в таблицю рішень з обмеженою виходом.

Треба лише вибрати певний ефект та не записати все комбінації ситуацій,.

що його викликають, потім виписати також стану решти ефектів при.

цих комбінаціях ситуаций.

5.3.4. Тестування модуля.

Метою тестування модуля є перебування невідповідності між логікою і.

сполученнями модуля, з одного боку, та її зовнішніми специфікаціями (описом.

функцій, вхідних і вихідних динячих, зовнішніх ефектів), з іншого боку. Процес.

проектування тестів для модуля складається з таких чотирьох шагов:

Керуючись зовнішніми специфікаціями модуля, були готові тести для.

кожній ситуації і «кожної можливості, кожної кордону областей допустимих.

значень всіх вхідних даних, областей зміни даних, всім неприпустимих.

условий.

Був перевірений текст програми, аби переконатися, що це умовні переходи були.

виконані кожному напрямі. (Текст програми визначався з допомогою.

створеного логічного анализатора).

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

тіла циклів, з його однократним виконанням і максимальною кількістю повторений.

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

вхідних даних, і було додано відповідні тесты.

Слід зазначити, що компіляцію модуля теж можна розглядати, як частина.

процесу тестування, оскільки компілятор виявляє більшість.

синтаксичних помилок, і навіть деякі семантичні і логічні ошибки.

Через війну реалізації цього типу тестування було зафіксоване, що це.

умовні переходи виконуються у кожному напрямі, немає «зациклення».

в модулі при граничних значеннях індексів циклів, як і нема.

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

реагує на граничні значення водимых даних корректно.

5.4.5. Комплексне тестирование.

Комплексне тестування — процес пошуків невідповідності системи її вихідним.

цілям [11]. Це найбільш творчий із усіх видів тестування. Вона складається з.

наступних шагов:

Тестування стресів. Поширений недолік великих систем у цьому, що вони.

функціонують начебто нормально при слабкої чи помірної навантаженні, але.

ламаються за високої навантаженні й у стресових ситуаціях реальної середовища.

Тестування стресів представляє спроби піддати систему крайньому.

«давлению».

Для проведення тестів здійснювалося дуже багато запитів до БД (20.

запитів). Через війну тесту був зафіксовано ніяких відхилень у роботі.

програми, але відзначалося певне уповільнення роботи БД з запросами.

Тестування обсягу. Тоді як із тестуванні стресів робиться спроба.

піддати систему серйозним навантажень в короткий інтервал часу,.

тестування обсягу є спробу пред’явити системі великі обсяги.

даних (максимальний объм бази даних, 2 МБ) протягом тривалого.

времени.

Для проведення тестів створювалася БД як і великих розмірів, створювалися.

черги документів, виведених на печатку, використовувалися граничні значення.

числових форматів. Через війну тесту також було зафіксовано відхилень в.

роботі програми, обробка запитів БД здійснювалася із незначною.

замедлением.

Тестування конфігурації. Багато системи забезпечують роботу різних.

конфігурацій апаратури та ВО. Кількість таких конфігурацій часто дуже велика, але.

необхідно перевірити хоча б максимальну і мінімальну конфігурації. Система.

зазнала з усіма апаратними пристроями, із якими вони можуть.

здійснювати роботу (гнучкі нагромаджувачі даних, принтеры).

Працюючи з різними типами накопичувачів даних (НГМД, НЖМД) виявлено було.

помилок, крім малої інформативності помилок які виникають за некоректною.

працювати з НГМД.

Тестування захисту. Оскільки увагу до питань збереження таємності в.

сьогоднішньому автоматизованому суспільстві зростає, до більшості систем.

пред’являються певних вимог щодо захисту від.

несанкціонованого доступу. Мета тестування захисту — порушити таємність в.

системе.

У результаті проведення тесту було зафіксоване, що користувач яка має.

доступу до системи проникнути туди не может.

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

(час відповіді щодо різноманітних навантажень і різних конфігурацій) — важливу складову.

проектів систем. У порівняні з іншими типами комплексного тестування системи.

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

монография[22].

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

конфігурації (ЕОМ з урахуванням Intel 486, Pentium 100, Cyrix 350). Через війну.

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

відзначити, робота на ПК з урахуванням Intel 486 категорично не рекомендується, хоч і возможна.

15 «>5.5. Висновки з тестування ПО.

На підставу проведення перелічених вище тестів (див. додаток B, З) можна.

укласти, что:

Створена система виконує всі функції, вказаних у ТЗ.

При аварійному відключенні зберігає максимально можливу кількість данных.

Система може працювати на ПК різної конфігурації, зокрема і.

минимальной.

Система відповідає поставленим вимогам захисту від несанкціонованого.

доступа.

Система коректно здійснює своєї роботи під час роботи з більшими на обсягами даних.

(за максимального обсязі БД — 2 МБ) і за велику кількість запросов (20.

запросов).