Разработка АСИС “Учет поставок”

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

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

• Семантична модель;
• Фрейми;
• Модель “суть-зв'язок”.

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

• Опис об'єктів наочної області відбувається природною мовою;
• Всі записи, що поступають в БД накопичуються в щодо однорідній структурі.

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

Фрейми  виражаються структурами даних з прив'язаними процедурами обробки цих даних. Фрейми можуть бути наступних видів: подієві, характеристики, логічні предикати. Використання фреймової моделі так само недоцільно, оскільки дана модель не відображає типи зв'язків [14] в реляційній моделі даних.

    Модель  “суть-зв'язок”  описується в термінах суть, зв'язок, значення. Суть – поняття яке може бути ідентифіковане. Зв'язок – з'єднання суті. Для представлення зв'язків і суті введений спеціальний метод: ER-диаграма [27]. Розрізняється суть трьох основних класів: стрижньові, асоціативні і характеристичні. Стрижньова суть – це незалежна суть (їй властиве незалежне існування). Асоціативна суть або асоціація розглядається як зв'язок між двома або більш суттю типу "багато -ко- багатьом" або подібні до них. Характеристична суть (або характеристика) є суттю, єдина мета якої, в рамках даної наочної області, полягає в описі або уточненні деякій іншій суті. ER-диаграма – графічне представлення взаємозв'язків суті. Кожна безліч суті представляється прямокутником, а безліч зв'язків – ромбом. Зв'язки можуть бути трьох типів: “один до одного”, “один до багатьом”, “багато до багатьом”. дані типи зв'язку властиві реляційній моделі, як і суть, якій в реляційній моделі відповідають таблиці.

 

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

    2.4.1 Виділення суті 

    Суть  “постачальник” є стрижньовою суттю  моделі, що розробляється. З постачальником полягає договір, на підставі якого  ведеться решта всієї діяльності підприємстві по постачаннях, відправлення заявки постачальникам, отримання від них рахунку-фактури, відправлення замовлення на постачання, отримання товару, оплата постачання. Як ключ для даної суті вводиться атрибут № Постачальника.

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

    Таблиця 2.1

 

 

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

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

• Алгоритми, пов'язані з проектуванням АСИС;
• Алгоритми реляційної алгебри, необхідні для роботи з БД;
• Алгоритми розрахунку необхідних показників (обчислення заборгованості підприємства по оплаті постачань, визначення оптимального рахунку-фактури).

 

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

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

    Обычно  методы проектирования делятся на три  основные группы;

• Метод проектирования сверху вниз;
• Метод потоков данных;
• Объектно-ориентированное проектирование.

Для структурного проектування характерна алгоритмічна декомпозиція. Слід зазначити, що більшість  програм написана відповідно до цього  методу. Проте структурний підхід не дозволяє виділити абстракції і забезпечити обмеження доступу даним; він також не надає достатніх засобів для організації паралелізму. Структурний метод не може забезпечити створення гранично складних систем, і він, як правило, неефективний в об'єктних і об'єктно-орієнтованих мовах програмування. Тому даний метод не використовувався для проектування АСИС “Облік постачань”.

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

Об'єктно-орієнтоване  проектування (object-oriented design, OOD) — это підхід в основі якого лежить уявлення про те, що програмну систему потрібно проектувати як сукупність об'єктів, що взаємодіють один з одним, розглядаючи кожен об'єкт як екземпляр певного класу, причому класи утворюють ієрархію. Об'єктно-орієнтований підхід відображає топологію новітніх мов високого рівня, таких як Object Pascal, C++, 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-мерного простору в простір з меншою кількістю вимірювань. Наприклад, в результаті проекції безлічі точок площини (Х,у) на вісь Х виходить безліч крапок, розташованих на цій осі. На жаль, значення проекцій деяких “крапок” можуть співпадати; це відбудеться у тому випадку, коли проекція видалить стовпець, що входить в ключ, так що частини двох “укорочених” кортежів, що залишилися, можуть бути ідентичними. Тоді доведеться видалити дублікати і тим самим зменшити кількість рядків, тобто розмір БД. Якщо хоч би один з можливих ключів при виконанні проекції залишиться незачепленим, то дублікатів не буде.