База даних аптеки

База даних аптеки

Магазин музичних інструментів

1.      
Аналіз досліджуваної області

1.1    Виділення базових об’єктів предметної області

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

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

Можуть існувати такі обмеження при роботі з базою даних:

.        один виробник може виробляти кілька препаратів;

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

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

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

Завданнями бази даних є:

)        додавання нових препаратів;

)        додавання нових торгових назв;

)        додавання нових лікарських форм;

)        додавання нових постачальників (виготовлювачів);

)        додавання нових хвороб;

)        класифікація препаратів за виготовлювачам;

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

Розробляється БД включає в себе наступні сутності (відносини):

·        групи;

·        лікарські форми;

·        препарати;

·        захворювання;

·        торгові назви;

·        буфер;

·        складові.

Інформація про препарат:

·        штрихкод;

·        назва;

·        ціна;

·        опис.

Група:

·        назва;

·        опис.

Інформація про виробника (постачальника):

·        унікальний код постачальника;

·        назва;

·        ПІБ представника.

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

1.2   
Аналіз системних вимог

В першу чергу основною вхідною інформацією буде інформація про товар, а саме: назва, штрих-код, виробник, опис, ціна (Таблиця 1.1).

Таблиця 1.1 - Вхідні дані

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

-       блок виведення інформації про товари призначений для виведення інформації про товари;

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

В основному проект працюватиме з базою даних SQL Server.

1.3    Глосарій предметної області та технічне завдання

На підставі аналізу предметної області створюємо та оформлюємо словник предметної області:

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

-       користувач - суб’єкт, що користується послугами «Аптеки»;

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

Нижче наведена специфікація вимог до системи:

–       адміністратори аптеки можуть переглядати, редагувати та поновлювати інформацію про товари;

–       клієнти можуть обирати товар та його кількість;

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

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

1.4    Аналіз можливості застосування існуючих шаблонів

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

Існує 3 основних групи шаблонів:

.        шаблони, що породжують - це шаблони проектування, що абстрагують процес інстанціювання. Вони допоможуть зробити систему незалежною від способу створення, композиції та представлення її об'єктів. Шаблон, який породжує класи, використовує спадкування, щоб варіювати створюваний клас, а шаблон, що створює об'єкти, делегує інстанціювання іншому об'єктові. Ці шаблони важливі, коли система більше залежить від композиції об'єктів, ніж від спадкування класів. Таким чином, замість прямого кодування фіксованого набору поведінок, визначається невеликий набір фундаментальних, за допомогою композиції яких можна отримувати складніші;

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

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

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

Ключем до паттерну компонувальник є абстрактний клас, який є одночасно і примітивом, і контейнером(Component). У ньому оголошені методи, специфічні для кожного виду об'єкта (такі як Operation) і загальні для всіх складових об'єктів, наприклад операції для доступу і управління нащадками. Підкласи Leaf визначає примітивні об'єкти, які не є контейнерами. У них операція Operation реалізована відповідно до їх специфічних потреб. Оскільки у примітивних об'єктів немає нащадків, то жоден з цих підкласів не реалізує операції, пов'язані з управління нащадками (Add, Remove, GetChild). Клас Composite складається з інших примітивніших об'єктів Component. Реалізована в ньому операція Operation викликає однойменну функцію відтворення для кожного нащадка, а операції для роботи з нащадками вже не порожні. Оскільки інтерфейс класу Composite відповідає інтерфейсу Component, то до складу об'єкта Composite можуть входити і інші такі ж об'єкти.

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

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

Зареєстровані події транслюються в різні запити, що спрямовуються компонентам Моделі або об'єктам, відповідальним за відображення даних. Відокремлення моделі від вигляду даних дозволяє незалежно використовувати різні компоненти для відображення інформації. Таким чином, якщо користувач через Контролер внесе зміни до Моделі даних, то інформація, подана одним або декількома візуальними компонентами, буде автоматично відкоригована відповідно до змін, що відбулися.

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

Система зі складною моделлю області визначення може бути спрощена за допомогою додаткового рівня, наприклад Data Mapper, який би ізолював об'єкти від коду доступу до БД. У таких системах може бути корисним додавання ще одного шару абстракції поверх шару розподілу даних (Data Mapper), в якому б був зібраний код створення запитів. Це стає ще більш важливим, коли в області визначення безліч класів або при складних, важких запитах. У таких випадках додавання цього рівня особливо допомагає скоротити дублювання коду запитів.

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

.       
Представлення моделі системи

2.1    Представлення прецедентів та їх специфікація

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

Рисунок 2.1 - Загальна діаграма прецедентів

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

2.2    Логічне представлення моделі

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

Логічна структура БД в кінцевому вигляді повинна відповідати всім стандартам, а саме:

         не містити зв’язків «багато-до-багатьох»;

         не мати складних зв'язків;

         не повинно бути множинних атрибутів.

Всі зв’язки типу «багато-до-багатьох», видаляються за допомогою виділення проміжної сутності і замінюються на два зв’язки типу «один-до-одного» до новоствореної сутності.

Проаналізувавши структуру бази даних, було зроблено висновки про її відповідність вимогам. База даних не містить зв'язків «багато-до-багатьох», всі атрибути сутностей є простими а складні зв'язки відсутні. Першим кроком спрощення концептуальної моделі є попередні перетворення з метою усунення зв'язків, які є несумісними з реляційною моделлю.

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

-      кожна сутність, кожний атрибут і кожний зв'язок повинні мати ім'я (зв'язок супертипу або асоціативний зв'язок може не мати імені);

-        ім'я сутності повинне бути унікальне в рамках моделі даних;

         ім'я атрибуту повинне бути унікальне в рамках сутності;

         ім'я зв'язку повинне бути унікальне, якщо для нього генерується таблиця БД;

         кожний атрибут повинен мати визначення типу даних;

         сутність в необов'язковому зв'язку повинна мати ключовий атрибут. Те ж саме відноситься до сильної сутності в слабкому зв'язку, супертипу в зв'язку «супертип-підтип» і необов'язкової сутності в обов'язковому (повному) зв'язку;

         підтип в зв'язку «супертип-підтип» не може мати ключовий атрибут;

         у асоціативному або слабкому зв'язку може бути тільки одна асоціативна (слабка) сутність;

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

Рисунок 2.2 - Логічне представлення моделі

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

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

2.3    Вибір засобів розробки інформаційної системи

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

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

Реляційна модель представляє об'єкти і взаємозв'язки між ними за допомогою таблиць. Групувати дані у таблиці є дуже зручним рішенням, таблиця має такі властивості:

         кожний елемент таблиці являє собою один елемент даних;

         повторювані групи відсутні;

         стовпцям присвоєні унікальні імена;

         у таблиці немає двох однакових рядків.

Між таблицями можуть існувати наступні зв'язки: один до одного, один до багатьох, багато до багатьох.

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

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

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

На сьогоднішній день існує досить багато СКБД. Деякі з них є локальними, деякі - мережевими. Однією з найвідоміших і найпопулярніших СКБД, яка працює з локально є Microsoft Access. «Microsoft Access» (повна назва Microsoft Office Access) - система управління базами даних від компанії Майкрософт, програма, що входить до складу пакету офісних програм Microsoft Office. Має широкий спектр функцій, включаючи зв'язані запити, сортування по різних полях, зв'язок із зовнішніми таблицями і базами даних. Завдяки вбудованій мові VBA, в самому Access можна писати підпрограми, що працюють з базами даних. Вбудовані засоби взаємодії MS Access зі зовнішніми СУБД з використанням інтерфейсу ODBC знімають обмеження, властиві Microsoft Jet Database Engine. Інструменти MS Access, які дозволяють реалізувати таку взаємодію називаються «пов'язані таблиці» (зв'язок з таблицею СУБД) і «запити до сервера» (запит на діалекті SQL, який «розуміє» СУБД). Корпорація Microsoft для побудови повноцінних клієнт-серверних додатків на базі MS Access рекомендує використовувати в якості рушія бази даних СУБД MS SQL Server. При цьому є можливість поєднати з властивою MS Access простотою інструменти для управління БД і засоби розробки. Відомі також реалізації клієнт-серверних додатків на базі зв'язки Access 2003 з іншими СУБД, зокрема, MySQL, проте в даному випадку це не виправдано, оскільки це потребуватиме додаткового коду та додаткових програмних засобів. MySQL - вільна система керування реляційними базами даних. MySQL був розроблений компанією «ТсХ» для підвищення швидкодії обробки великих баз даних. Ця система керування базами даних (СКБД) з відкритим кодом була створена як альтернатива комерційним системам. MySQL з самого початку була дуже схожою на mSQL, проте з часом вона все розширювалася і зараз MySQL - одна з найпоширеніших систем керування базами даних. Вона використовується, в першу чергу, для створення динамічних веб-сторінок, оскільки має чудову підтримку з боку різноманітних мов програмування. MySQL - компактний багатонитевий сервер баз даних. Характеризується великою швидкістю, стійкістю і простотою використання. MySQL вважається гарним рішенням для малих і середніх застосувань. Проте MySQL не надто оптимізована під потужні проекти та роботу із сторонніми ресурсами, також вона не досить добре співпрацює з середовищем Visual Studio, що призводить до створення лишнього коду та неможливості повною мірою реалізувати усі можливості ПЗ. Серед відомих СКБД з віддаленим доступом та клієнт-серверною архітектурою виділимо SQL Server. SQL Manager for SQL Server - це високопродуктивна програма для розробки і адміністрування баз даних сервера Microsoft SQL. SQL Manager працює з усіма версіями SQL Server, починаючи з сьомої, і підтримує всі новітні можливості SQL Server, включаючи нові типи даних (datetimeoffset, hierarchyid, geometry, geography та інші), табличні типи і параметри табличних значень, тригери входу, резервні копії з стиском і багато іншого. Програма включає в себе безліч інструментів, таких як Візуальний конструктор баз даних, який дозволяє швидко створювати бази даних SQL Server, Візуальний конструктор запитів для побудови складних запитів до SQL Server і безліч інших корисних інструментів для ефективного адміністрування SQL Server. Сучасний, графічний інтерфейс і оптимальна система майстрів налаштувань будуть зрозумілі навіть новачкові. Так як даний проект передбачає клієнт-серверну архітектуру, то для його розробки було обрано СКБД SQL Manager for SQL Server.

3.1    Структура і функціональне призначення модулів системи, їх взаємозв'язок

Структура даних - це ті змінні, які використовуються програмою для її роботи. Змінні бувають глобальні та локальні. Глобальні змінні передбаченні для використання більше ніж однією функцією. Локальні - змінні, які існують і діють лише в тілі однією процедури. Найважливішою ознакою змінної є її тип. Тип - для мови програмування це певне ключове слово, яке дає змогу передбачити діапазон можливих значень.

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

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

В таблицях дані розподіляються по стовпцям (які називаються полями) і рядкам (які називаються записами). Всі дані, що містяться в відповідному полі таблиці, повинні мати один і той же тип. Кожне поле таблиці характеризується найменуванням, типом і шириною поля. При завданні типу даних поля також можна вказати розмір, формат та інші параметри, що впливають на відображення значення поля і точність числових даних. Додатковий функціонал дозволяє з легкістю розробити середовище для маніпулювання даними згідно побажань замовника. При проектуванні не використовувалось наслідування від класів, проте використовувалось множинне наслідування за допомогою інтерфейсів. Діаграма класів дозволяє переглянути структуру програмного продукту.

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

3.2    Розробка програмних модулів

Даний проект буде розроблятись засобами середовища програмування MS Visual Studio 2012.Visual Studio - лінійка продуктів фірми Майкрософт, що включають інтегроване середовище розробки програмного забезпечення і ряд інших інструментальних засобів.включає один або декілька з наступних компонентів:

         Visual Basic.NET, а до його появи - VisualBasic;

         Visual C++;

         Visual C#;

         Visual J#.C# надає розробникам сучасну компоненто-орієнтовану мову, яка дозволяє швидко конструювати чудові рішення, керовані даними. Можливості C# дозволяють створювати рішення для широкого кола клієнтів, включаючи веб-програми, програми на основі Microsoft Windows Forms, додатки для «тонких» та інтелектуальних клієнтів. На відміну від Object Pascal, у С# підпрограми реалізовані тільки у вигляді функцій, проте спеціальний тип функції void не повертає ніякого значення. Саме тому деякі функції таким чином і були реалізовані.

На відміну від С++, С# більш структурована і типізована мова програмування. В неї немає глобальних змінних, тому що кожна змінна належить певному класу. Також в неї є безліч конструкторів по роботі з базами даних, які пришвидшать виконання і здешевлять проект. В результаті підключення до бази даних створюється конфігураційний файл, в якому можна змінювати шлях до бази даних без перекомпіляції програми. Підключення до бази даних здійснюється створенням копії даної бази, що дає можливість працювати з віддаленим сервером. В проекті буде використовуватись локальне підключення до бази даних, бо для створення хоча б мереженого підключення немає потрібних прав доступу і можливостей, а також підключення до бази даних через OLE за допомогою ADO.NET, яка підтримує мережене з’єднання, тому при необхідності можна звертатись до бази даних через мережу, прописавши попередньо шлях в конфігураційному файлі, який знаходиться в одній папці з виконуваним файлом. Також локальне підключення пришвидшить розробку і тестування проекту.

Базу даних додаток розроблено за допомогою ПЗ MS SQL Server 2008. Через технологію SQL підключаємо її вбудованими засобами MS Visual Studio.

Порядок підключення бази даних:

на панелі інструментів обираємо Data->Add New Data Source (рисунок 3.1);

Рисунок 3.1 - Створення нового підключення

- вибираємо тип підключення до БД та вказуємо шлях (рисунок 3.2);

Рисунок 3.2 - Тип підключення

створюємо нове підключення шляхом натискання кнопки «New connection» (рисунок 3.3) та обираємо MS SQL Server;

Рисунок 3.3 - Підключення до БД

В результаті підключення відкривається вікно, яке призначене для редагування та перегляду параметрів БД в середовищі C# (рисунок 3.4):

Отже, обрано засіб створення ПЗ VisualStudio 2012 та мову програмування С#(як одну з мов програмування, що розвивається найшвидше). Використання.NET Framework дає змогу використовувати дуже велику кількість вбудованих класів та виконувати відкомпільований код на будь - якій апаратній платформі (яка підтримується .NET).

Рисунок 3.4 - Схема даних у середовищі MS Visual Studio

Також серед переваг MS Visual Studio варто відзначити велику різноманітність засобів для зв’язку із базами даних (API). Для цього можна використовувати:

         OLEDB технологію - дозволяє звертатись до даних за допомогою уніфікованого доступу;

         ODBC (англ. Open DataBase Connectivity) - це відкритий інтерфейс доступу до баз даних, розроблений консорціумом X/Open. Даний інтерфейс надає можливості уніфікованого доступу, не турбуючись про технологію, яка застосовується для зберігання даних. Це надає можливості одному додатку зв’язуватись із джерелами, побудованими на різних СКБД.

Базу даних було розроблено за допомогою MS SQL Server. Використання двох технологій одного і того ж виробника полегшує завдання і дозволяє повною мірою реалізовувати можливості обох середовищ.

Програмування на Visual C# складається з двох процесів:

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

написання кодів, що додають функціональність діалоговим вікнам.

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

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

{DevExpress. UserSkins. BonusSkins. Register();. UserSkins. OfficeSkins. Register();. EnableVisualStyles();. SetCompatibleTextRenderingDefault (false. Run (new MainF());

} // якщо виникае помилка: виводимо повідомлення(Exception e)

{. Show («Message:» + e. Message + «Source:» + e. Source

+ «Data:» + e. Data + «InnerException:» + e. InnerException);

}

Таким чином попереджаються «виліти» програми, і ПЗ буде працювати оректно незалежно від поведінки користувача.

3.3    Інструкція користувача

Для швидкого запуску програми необхідно натиснути на іконку XSearch.exe, яка розташовується в робочій теці програми. Крім того, для зручності запуску програми ви можете використовувати панель Швидкий запуск системи Windows, розмістивши на ній значок програми.

При запуску програми перед користувачем з’являється головне меню (рисунок 3.5):

Рисунок 3.5 - Головне вікно програми

Тут користувач починає свою роботу, вибравши будь-який розділ. Необхідно зауважити, що неможливо працювати з програмою, поки не занесені дані про товар. Коли є перелік товарів, вже додають постачальників, і тільки тоді можна зробити замовлення і отримати поставку. Розділ «Виробники» зображено на рисунку 3.6:

Вікно ліків зображено на рисунку 3.7. У центрі цього вікна можна побачити перелік виробників, короткий опис, Штрихкод товару, ціну і звісно назву. Для кожної з форм реалізовано контекстнеменю яке появиться при натисканні ПКМ в якому реалізовані різні дії для роботи з таблицею.

Рисунок 3.6 - Виробники

Рисунок 3.7 - Ліки

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

.4      
Вимоги до технічних засобів

Програма «Пошуково інформаційна система Аптеки» розроблена в середовищі MS Visual Studio 2012 з використанням СУБД Microsoft SQL Server 2012. Для функціонування проекту необхідна наявність встановленого MS SQL Server 2012 на комп’ютері, який буде виконувати роль сервера. Також для серверу і всіх інших машин - клієнта платформи Microsoft. Net Framework версії 4.0 або вище.

Для того щоб програма могла нормально функціонувати, конфігурація комп’ютера, на який вона встановлюється, повинна відповідати таким мінімальним вимогам:

процесор - тактова частота 2.0 ГГц і вище;

ОЗП - 1024 Мбайт і вище;

об’єм вільного місця на жорсткому диску - 20 Mбайт;

операційна система - Windows 2000 / Windows XP® / Windows Vista® / Windows 7®;

відео карта - 256 Mб;

оптимальна роздільна здатність монітора 1024х768 або вище;

Перед використанням програми її треба встановити. Для цього запускається файл XSearch.exe та за допомогою майстру установки проект легко інсталюється на комп’ютері.

Так, як програма потребує налаштування та синхронізації з СУБД MS SQL Server, то загального інсталятора немає, налаштування з`єднань може провести працівник із знаннями комп’ютерних мереж та вищеописаного СКБД.

Для сервера необхідно провести такі налаштування:

встановити MS SQL Server;

з установочного диску скопіювати базу даних з папки «DATA» та помістити їх у папку С:\Program Files\Microsoft SQL Server\ MSSQL10_50.MSSQLSERVER \MSSQL\ DATA;

встановити проект - файл XSearch.exe

Для клієнта необхідні наступні налаштування:

встановити проект - файл XSearch.exe

У файлі kf.txt, який буде розмішуватись в каталозі з встановленим проектом, вказати назву комп’ютеру-серверу або його IP-адресу.

3.5    Якість програмного забезпечення

Якість програмного забезпечення - характеристика програмного забезпечення, ступінь відповідності ПЗ до вимог. При цьому вимоги можуть трактуватись по-різному, що породжує декілька незалежних визначень терміну. Частіше за все, використовують визначення ISO 9001, згідно з яким якість - це «ступінь відповідності наявних характеристик вимогам».

Існує оцінка якості з позиції звичайного користувача. Для цього аспекту якості використовують термін «usability». Для оцінки цього аспекту якості, відповідають на наступні питання:

чи є інтерфейс користувача інтуїтивно зрозумілим;

наскільки легко виконувати прості, часті операції;

наскільки легко виконувати складні операції;

чи зрозумілі повідомлення про помилки;

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

чи є документація до ПЗ, наскільки вона повна;

чи є інтерфейс користувача самодокументуючим;

чи завжди затримки відповіді від програми є прийнятними.

Також розглядають якість коду. Якість коду може визначатись різними критеріями. Деякі з них мають значення тільки з точки зору людини. Наприклад, форматування тексту програми - неважливо для комп'ютеру, але може мати велике значення для супроводу. Багато з існуючих стандартів кодування, що визначають специфічні для мови програмування угоди та задають низку правил, мають на меті полегшити супровід програмного забезпечення в майбутньому. Також існують інші критерії, що визначають чи «гарно» написаний код, наприклад, такі, як структурованість - ступінь логічного розділення коду на блоки.

Деякі фактори якості коду:

читабельність;

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

низька складність коду;

коректність обробки винятків;

методи покращення якості коду: рефакторинг.

Сукупність властивостей ПЗ, що забезпечує задовільну для користувача якість, залежить від умов і характеру експлуатації цього ПЗ. Тому при описі якості ПЗ, насамперед, повинні бути визначені критерії оцінки якості ПЗ - фактори якості. Фактори якості - нефункціональні вимоги до ПЗ, що відносяться до, наприклад, надійності та продуктивності програм.

Деякі з факторів якості:

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

легкість застосування - мінімізація зусиль користувача по підготовці вхідних даних, застосуванню ПЗ і оцінці отриманих результатів;

функціональність - здатність ПЗ виконувати набір функцій, які задовольняють потреби користувачів. Набір зазначених функцій визначається в зовнішньому описі ПЗ;

повнота - всі необхідні частини програми повинні бути представлені та реалізовані;

стислість - відсутність надлишкової інформації та її дублювання. Реалізація принципів DRY;

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

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

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

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

супровід - це характеристики ПЗ, що дозволяють мінімізувати зусилля по внесенню змін для усунення в ньому помилок і по його модифікації відповідно до потреб користувачів;

мобільність - це здатність ПЗ бути перенесеним з одного середовища (оточення) в іншу, зокрема, з одного комп'ютера на іншій;

безпечність.

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

3.6    Управління якістю проекту та ризиками

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

Існують такі ризики проекту, що впливають на його хід:

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

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

ризики вимог - можливість змін в вимогах до результатів;

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

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

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

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

Щодо якості - застосування додаткових можливостей дозволить покращити якість ПЗ інтернет-магазину музичних інструментів. Основними пропозиціями щодо покращення якості є:

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

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

Висновок

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

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

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

В процесі виконання курсової роботи:

·  застосовано на практиці теорію розробки інформаційної системи;

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

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

·        розроблено таблиці, встановлено всі властивості їх полів, забезпечено цілісність;

·        розроблено засоби коригування, пошуку, сортування та фільтрування даних;

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

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

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

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

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

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

аптека лікарських база інформаційний

1. Жарков В.А. Компьютерная графика, мультимедиа и игры на Visual C# [Текст] / В.А. Жарков - М.: ЮНИТИ, 2008. - 355 с.

. Лабор В. Visual C# Создание приложений для Windows [Текст] /

В. Лабор - М.: Издательский дом «Вильямс», 2007. - 385 с.

3. Агуров П.В. C#. Сборник рецептов [Текст] / П.В. Агуров - М.: Издательский дом «Вильямс», 2007. - 429 с.

. Библиотека MSDN - библиотека официальной технической документации для разработчиков под ОС Microsoft Windows. Архитектура ADO.NET [Електронна публікація] URL: http://msdn.microsoft.com/ru-ru/library/27y4ybxw (v=vs.100).aspx (дата звернення 12.12.2012)

. Форум программистов и сисадминов CyberForum.ru. FAQ по ADO.NET [Електронна публікація] URL: http://www.cyberforum.ru/ado-net/thread342184.html (дата звернення 12.12.2012)

. Форкун Ю.В., Кисіль Т.М. Проектний практикум: методичні вказівки до курсового проектування для студентів напряму підготовки «Програмна інженерія» [Текст] / Ю.В. Форкун, Т.М. Кисіль. - Хмельницький: ХНУ, 2011. - 48 с.

. Сандерсон С. ASP.NET MVC для профессионалов [Текст] / С. Сандерсон - М.: Издательский дом «Вильямс», 2009. - 557 с.