Проектування програмного забезпечення медичного закладу

PAGE \* MERGEFORMAT2

Зміст

1. Вступ:

1.1 Призначення, мета:

Даний документ проектується студентом ПР – 9 – 12 для опису програмного продукту «Medical© control». А також системних, функціональних і не функціональних вимог до даного продукту.

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

2. Загальний опис:

2.1 Характеристики:

2.2.1. Веде облік клієнтів;

2.2.2. Веде облік діагнозів клієнтів;

2.2.3. Виконує пошук;

2.1.4. Обчислює вартість за день;

2.1.5. Друкує звіти.

2.2 Користувачі:

2.2.1. Старша медсестра;

2.2.2. Лікарі;

2.2.3. Головний лікар.

2.3 Середовище функціонування:

Даний продукт працює на операційній системі Windows 95 / 98 / 2003 / Vista / 7 / 8 / 8.1 / 10.

Апаратна платформа: Клавіатура, миша, монітор, системний блок(материнська плата, вінчестер, процесор, блок живлення, відеоадаптер 16Mb).

3. Характеристики системи:

3.1 Функціональні вимоги:

3.1.1 Продукт повинен дозволяти вводити дані;

3.1.2 Продукт повинен дозволяти виводити дані;

3.1.3 Продукт повинен дозволяти видаляти дані;

3.1.4 Продукт повинен дозволяти здійснювати пошук даних по діагнозу або по ПІБ пацієнта;

3.1.5 Продукт повинен обчислювати прибуток за день;

3.1.6 Продукт повинен дозволяти друкувати звіти.

4. Вимоги до зовнішніх інтерфейсів:

4.1 Користувацькі інтерфейси:

На інтерфейсі продукту буде міститися:

4.1.1 Головне меню;

4.1.2 Таблиця бази даних;

4.1.3 Вікна додавання та видалення даних.

4.1.4 Вікна пошуку даних.

4.1.5 Фільтрація даних.

4.1.6 Меню швидкого доступу.

4.2 Апаратні інтерфейси:

4.2.1 Взаємодіє з принтером.

5. Не функціональні вимоги:

5.1 Вимоги продуктивності:

5.1.1 Продукт повинен обчислювати вартість за день менше ніж за секунду;

5.1.2 Продукт повинен здійснювати пошук менше ніж за секунду;

5.1.3 Програма повинна бути розроблена на мові С++.

5.2 Вимоги безпеки:

5.2.1 Продукт повинен містити аутентифікацію по паролю.

Висновок

Список літератури

Вступ

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

C ++ Builder - програмний продукт, інструмент швидкої розробки додатків (RAD), інтегроване середовище програмування (IDE), система, використовувана програмістами для розробки програмного забезпечення на мові програмування C ++. C ++ Builder об'єднує в собі комплекс об'єктних бібліотек (STL, VCL, CLX, MFC та ін.), компілятор, відладчик, редактор коду і багато інших компонентів. C ++ Builder містить інструменти, які за допомогою drag-and-drop дійсно роблять розробку візуальної, спрощує програмування завдяки вбудованому WYSIWYG - редактору інтерфейсу та ін. dBASE і Paradox: Sybase, Oracle, InterBase і Informix; Excel, Access, FoxPro і Btrieve. Механізм ADO додає обслуговуванню зв'язків з базами даних дивовижну простоту і прозорість.

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

Життєвий цикл

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

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

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

Проектування програмного забезпечення

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

На цьому етапі:

1. Формується структура і визначається архітектура програмного забезпечення.
2. Визначаються модулі, які розділяються на ієрархічні рівні.
3. Вибирається структура інформаційних масивів, що становлять базу даних.
4. Розробляються алгоритми.

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

Програмування (реалізація)

На даному етапі проводиться програмування модулів.

Тестування програмного забезпечення

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

Супровід програмного забезпечення

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

1. В програмне забезпечення залишаються помилки не виявлені під час тестування.
2. Користувачі хочуть вдосконалити програмне забезпечення або самі щось хочуть змінити.

Моделі розробки програмного засобу

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

Види моделей життєвого циклу: каскадна(водоспадна), спіральна, ітеративна.

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

Каскадна (водоспадна) модель

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

Спіральна модель

Спіральна модель процесу(86 – 90 рр.) – передбачає послідовність етапів розробки життєвого циклу, яка виконується більше одного разу. Упор розробки робиться на етап «системний аналіз» і проектування. Кожний виток спіралі відповідає створенню фрагмента або версії програмного засобу. На нього уточнюються характеристики проекту і планується робота на наступному витку спіралі. При такому способі робіт буде повне виконання роботи на кожному етапі, але головне надати користувачу найшвидше працездатний продукт.

Ітеративна модель

Ітеративний підхід (англ. Iteration, «повторення») у розробці програмного забезпечення - це виконання робіт паралельно з безперервним аналізом отриманих результатів і коригуванням попередніх етапів роботи. Проект при цьому підході в кожній фазі розвитку проходить повторюваний цикл PDCA: Планування - Реалізація - Перевірка - Оцінка (англ. Plan-do-check-act cycle).

Технологія розробки програмного забезпечення

Дисципліна «Технологія розробки програмного забезпечення» направлена на вивчення теоретичних основ, методів і способів розробки інформаційних систем. У ній детально розглядається уніфікована мова моделювання UML, основні його будівельні блоки (об'єкти, класи, відносини і діаграми), і можливості створення системи з їх допомогою.

У програмі BPwin можна створювати моделі трьох видів. Для цього використовуються такі методології: IDEF0, IDEF3, DFD.

Методологія IDEF0

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

Діаграма складається з блоків і стрілок.

Функціональна діяльність – її робота(дієслово).

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

1. Призначення моделі – це набір питань на які повинна відповідати модель.
2. Границі моделювання (її межі) – це рівень деталізації.
3. Точка зору – вибирається перспектива з якої бачиться система.

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

Моделі IDEF0 мають ієрархічну систему. Головний блок система – це контекстна функція, вона може бути декомпозирована (може бути декомпозирована у ряд блоків).

Методологія IDEF3

IDEF3 (англ. Integrated DEFinition for Process Description Capture Method) - методологія моделювання і стандарт документування процесів, що відбуваються в системі. Метод документування технологічних процесів являє собою механізм документування та збору інформації про процеси. IDEF3 показує причинно-наслідкові зв'язки між ситуаціями і подіями в зрозумілій експерту формі, використовуючи структурний метод вираження знань про те, як функціонує система, процес або підприємство.

Методологія DFD

DFD - загальноприйняте скорочення від англ. Data Flow Diagrams - діаграми потоків даних. Так називається методологія графічного структурного аналізу, що описує зовнішні по відношенню до системи джерела і адресати даних, логічні функції, потоки даних і сховища даних, до яких здійснюється доступ.

Діаграма потоків даних (data flow diagram, DFD) - один з основних інструментів структурного аналізу і проектування інформаційних систем, що існували до широкого поширення UML. Незважаючи на що має місце в сучасних умовах зміщення акцентів від структурного до об'єктно-орієнтованого підходу до аналізу і проектування систем, «старовинні» структурні нотації раніше широко і ефективно використовуються як в бізнес-аналізі, так і в аналізі інформаційних систем.

Методологія UML

UML (англ. Unified Modeling Language - уніфікована мова моделювання) - мова графічного опису для об'єктного моделювання в області розробки програмного забезпечення. UML є мовою широкого профілю, це - відкритий стандарт, який використовує графічні позначення для створення абстрактної моделі системи, званої UML-моделлю. UML був створений для визначення, візуалізації, проектування та документування, в основному, програмних систем. UML не є мовою програмування, але на підставі UML-моделей можлива генерація коду.

Діаграма варіантів використання (use case diagram) - діаграма, на якій зображуються відносини між акторами й варіантами використання.

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

Варіант використання описується овальною формою дієсловом, стрілки – зв’язки.

Структура процесу моделювання Erwin

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

1. Сутності – таблиці позначаються прямокутником, містять атрибути.
2. Атрибут – це властивість екземпляра сутності. Є атрибут «первинний ключ» - це унікальна властивість екземпляра сутності.

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

Зв’язок – це функціональна залежність між сутностями, наприклад: викладач навчає студента – тут зв’язок «навчає».

При створення зв’язку між таблицями(сутностями), в самій таблиці створюється зовнішній ключ.

Генерування бази даних BatchAccess

Генерування бази даних робиться за допомогою Erwin та BatchAccess.

1. Спочатку відкривається Erwin та в ньому вибирається InterBase в меню Target server і нажимаємо «Ок».

1. Потім вибираємо , і нажимаємо Preview і копіюємо весь генерований лістинг в BatcAccess.

1. Відкриваємо BatchAccess і вибираємо вкладку Database > Create New… , відкриється діалогове вікно для зберігання бази даних під довільним ім’ям.

1. Нажимаємо Ctrl+N, вставляємо генерований код з ERrwin і нажимаємо F5, нажимаємо Ctrl+S, відкриється діалогове вікно зберігання sql коду під довільним ім’ям(потрібно зберегти).

База даних повністю готова для роботи.

Для роботи з базою даних в Builder c++ 6 потрібно помістити компонент ADOConnection та клацнувши на ньому двічі, натиснути клавішу «Build». В наступному вікні вибрати «Microsoft Jet 4.0 OLE DB Provider» та натиснути «Далее». В наступному вікні вибрати шлях до створеної бази даних та натиснути «Ок». В властивостях компоненту LoginPrompt змінити на false.

База даних до Builder c++ 6 підключена, і повністю готова до роботи.

Висновок

На даній курсовій роботі було створено додаток «Medical© control», який працює зі створеною(генерованою) базою даних MDC.mdb(Медичний діагностичний центр).

Було створено окремі модулі для кожної таблиці, в яку можна додавати, видаляти через компоненти DBGrid та DBNavigator або ж через окремі модулі спеціального призначення (додавання та видалення даних). Було створено окремі модулі пошуку даних для кожної таблиці. Було створено модуль аутентифікації по паролю, для керованого доступу до додатку, та створено модуль зміни паролю, який зберігається в файлі(renew.bin). Також були реалізовані можливості друку звітів(даних) та їх перегляду, фільтрація даних, підрахування кількості записів в певній таблиці(відображаються в StatusBar). Були реалізовані підказки при наведенні на той чи інший компонент, які відображаються в StatusBar. Також реалізовані модулі «Довідка» та «Про нас». Через модуль «Квитанції», можна викликати модуль «Прибуток»(підрахування заробленої суми за день), результат якого відображаються StatusBar модуля «Квитанції» або ж у модулі «Прибуток».Модулі програми викликаються через головне меню програми або через панель швидкого доступу(ToolBar). Реалізовано вихід з програми через головне меню та панель швидкого доступу.

На даній курсовій роботі я засвоїв навики реалізації додатку(візуальне програмування), закріпив навички створення специфікації, навчився проводити тестування та виконав супровід додатку створений через Builder c++ 6.

Список літератури

1. Зборівська В. П. «Методичні вказівки з курсу основи програмної інженерії».
2. Зборівська В. П. «Методичні вказівки з курсу інструментальні засоби візуального програмування».
3. Лаврищева К. М. «Програмна інженерія».
4. Синіцин С. В., Налютін Н. Ю. «Верифікація програмного забезпечення».
5. Канер Ким, Фолк Джек, Нгуєн Енг Кек «Тестування програмного забезпечення».

Додаток 1. Лістинг програми
Додаток 2. Результати роботи програми
Додаток 3. CD – диск з курсовою роботою