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

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

Інтерфейс системи складається з:

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

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

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

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

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

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

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

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

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

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

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

5.1.3 Продукт повинен виконувати фільтрацію даних менше ніж за секунду;

5.1.4 Продукт не повинен займати більше 20 мегабайт оперативної пам’яті;

5.1.5 Продукт не повинен займати на магнітному носію більше 20 мегабайт.

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

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

Вимоги до інформації

6.1 Структура вхідних даних:

Таблиця 1.2.1 – Вхідні дані системи

Ідентифікатор	Тип	Діапазон значень	Пояснення
Код діагнозу	Текстовий(String)	–	Код діагнозу.
Термін	Текстовий(String)	–	Назва діагнозу.
Термін лікування	Текстовий(String)	–	Термін лікування діагнозу.
Код квитанції	Текстовий(String)	–	Код квитанції.
Код клієнта	Текстовий(String)	–	Код клієнта.
Всього до оплати	Числовий(double)	–	Сума, яку клієнт після використання послуг медичного діагностичного центру повинен оплатити в грошовій одиниці – рн..
Дата видачі	Дата(date)	1968 – 2100	Дата видачі клієнту квитанції.
Прізвище та ім’я клієнта	Текстовий(String)	–	Прізвище та ім’я клієнта.
Діагноз	Текстовий(String)	–	Діагноз
Код препарату	Текстовий(String)	–	Код препарату, який належить медичному діагностичному центру.
Код лікаря	Текстовий(String)	–	Код лікаря.
Прізвище та ім’я	Текстовий(String)	–	Прізвище та ініціали клієнта.
Код паспорту	Текстовий(String)	–	Код паспорту клієнта.
Телефонний номер	Текстовий(String)	–	Телефонний номер клієнта
Місто проживання	Текстовий(String)	–	Місто проживання клієнта.
Прізвище і ініціали	Текстовий(String)	–	Прізвище та ініціали лікаря.
Код паспорту	Текстовий(String)	–	Код паспорту лікаря.
Телефонний номер	Текстовий(String)	–	Телефонний номер лікаря.
Місто проживання	Текстовий(String)	–	Місто проживання лікаря.
Назва препарату	Текстовий(String)	–	Назва препарату, який належить медичному діагностичному центру.
Дата виготовлення	Дата(Date)	1968 – 2100	Дата виготовлення препарату.
Термін придатності	Дата(Date)	1968 – 2100	Дата, до якого препарат можна вживати.
text2	Текстовий(AnsiString)	–	Для виконання запитів додавання та видалення інформації
text3	Текстовий(AnsiString)	–	Для виконання запитів додавання та видалення інформації
text	Текстовий(AnsiString)	–	Для виконання запитів додавання та видалення інформації
textKey	Текстовий(AnsiString)	–	Для перевірки на повторюваність значень по кодовим полям всіх таблиць
textTermin	Текстовий(AnsiString)	–	Для перевірки на повторюваність значень по полю «Термін» таблиці «Діагнози»

6.2 Структура вихідних даних:

Таблиця 1.2.2 – Вихідні дані системи

Ідентифікатор	Тип	Діапазон значень	Пояснення
Код діагнозу	Текстовий(String)	–	Код діагнозу.
Термін	Текстовий(String)	–	Назва діагнозу.
Термін лікування	Текстовий(String)	–	Термін лікування діагнозу.
Код квитанції	Текстовий(String)	–	Код квитанції.
Код клієнта	Текстовий(String)	–	Код клієнта.
Всього до оплати	Числовий(double)	–	Сума, яку клієнт після використання послуг медичного діагностичного центру повинен оплатити в грошовій одиниці – рн..
Дата видачі	Дата(date)	1968 – 2100	Дата видачі клієнту квитанції.
Прізвище та ім’я клієнта	Текстовий(String)	–	Прізвище та ім’я клієнта.
Діагноз	Текстовий(String)	–	Діагноз
Код препарату	Текстовий(String)	–	Код препарату, який належить медичному діагностичному центру.
Код лікаря	Текстовий(String)	–	Код лікаря.
Прізвище та ім’я	Текстовий(String)	–	Прізвище та ініціали клієнта.
Код паспорту	Текстовий(String)	–	Код паспорту клієнта.
Телефонний номер	Текстовий(String)	–	Телефонний номер клієнта
Місто проживання	Текстовий(String)	–	Місто проживання клієнта.
Прізвище і ініціали	Текстовий(String)	–	Прізвище та ініціали лікаря.
Код паспорту	Текстовий(String)	–	Код паспорту лікаря.
Телефонний номер	Текстовий(String)	–	Телефонний номер лікаря.
Місто проживання	Текстовий(String)	–	Місто проживання лікаря.
Назва препарату	Текстовий(String)	–	Назва препарату, який належить медичному діагностичному центру.
Дата виготовлення	Дата(Date)	1968 – 2100	Дата виготовлення препарату.
Термін придатності	Дата(Date)	1968 – 2100	Дата, до якого препарат можна вживати.
date	Текстовий(String)	–	Для отримання вибраного користувачем дати, яка задана через компонент MonthCalendar, щоб виконати обрахування загальної суми за день.
*d	Символьний(Char)	–	Для конвертування в правильну позицію для бази даних дату.
first_2_day	Символьний(Char)	–	Для конвертування в правильну позицію для бази даних дату.
month	Символьний(Char)	–	Для конвертування в правильну позицію для бази даних дату.
d1	Символьний(Char)	–	Для конвертування в правильну позицію для бази даних дату.
none	Текстовий(String)	–	Для виведення інформації про відсутній прибуток.
sum_day	Текстовий(String)	–	Для виведення користувачу суму за день.

 

 

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

Огляд технології розробки

RAD (від англ. rapid application development - швидка розробка додатків) - концепція створення засобів розробки програмних продуктів, яка надає особливого увагу швидкості і зручності програмування, створенню технологічного процесу, що дозволяє програмісту максимально швидко створювати комп'ютерні програми.

Основні принципи RAD:

· Інструментарій повинен бути націлений на мінімізацію часу розробки.

· Створення прототипу для уточнення вимог замовника.

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

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

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

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

Середовища розробки, використовують принципи RAD:

· Borland Delphi.

· Borland C + + Builder.

· Microsoft Visual Studio.

· Macromedia Flash.

· Macromedia Authorware.

· Macromedia Director.

· Omnis Studio.

· Visual DataFlex.

· IntraWeb.

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

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

Найбільш суттєвими з них є:

· Висока швидкість розробки;

· Низька вартість;

· Висока якість.

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

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

Технологія RAD забезпечує:

· Прудкість просування програмного продукту на ринок;

· Інтерфейс влаштовує користувача;

· Легку адаптованість проекту до змінюваним вимогам;

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

Під терміном «RAD» звичайно розуміється процес розробки ПЗ, що містить 3 елементи:

· Невелику команду програмістів (від 2 до 10 осіб);

· Короткий, але ретельно пророблений виробничий графік (від 2 до 6 міс.);

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

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

Життєвий цикл ПЗ за методологією RAD складається з чотирьох фаз:

· Фаза аналізу і планування вимог.

· Фаза проектування.

· Фаза побудови.

· Фаза впровадження.

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

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

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

Архітектура потоків даних

BPwin - потужний інструмент моделювання, розроблений фірмою Computer Associates Technologies який використовується для аналізу, документування та реорганізації складних бізнес-процесів. Модель, створена засобами BPwin, дозволяє чітко документувати різні аспекти діяльності - дії, які необхідно зробити, способи їх здійснення, що вимагаються для цього ресурси та ін. Таким чином, формується цілісна картина діяльності підприємства - від моделей організації роботи в маленьких відділах до складних ієрархічних структур. При розробці або закупівлі програмного забезпечення моделі бізнес-процесів служать прекрасним засобом документування потреб, допомагаючи забезпечити високу ефективність інвестицій у сферу IT. В руках же системних аналітиків і розробників BPwin - ще й потужний засіб моделювання процесів при створенні корпоративних інформаційних систем.

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

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

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

BPwin дозволяє:

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

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

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

BPwin (тепер AllFusion Process Modeler) - програмний продукт в області реалізації засобів CASE-технологій. Дозволяє проводити опис, аналіз і моделювання бізнес-процесів. Займає одне з лідируючих місць в своєму сегменті ринку. В даний час випускається компанією Computer Associates. Поширюється на комерційній основі.

Включає три стандартні методології: IDEF0 (функціональне моделювання), DFD (моделювання потоків даних) і IDEF3 (моделювання потоків робіт). Ці методології по-своєму унікальні. Кожна з них може бути виконана окремо за допомогою BPwin, але їх сукупність укладена в модель дає аналітику повну картину предметної області клієнта.

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

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

· функції обробки інформації (роботи, процеси);

· документи (стрілки, arrow), об'єкти, співробітників або відділи, що беруть участь в обробці інформації;

· зовнішні посилання (external references), що забезпечують інтерфейс із зовнішніми об'єктами, які знаходяться за межами системи, що моделюється;

· таблиці для збереження документів (сховища даних, data store).

У BPwin для побудови діаграм потоків даних використовується нотація Гейна - Сарсона.

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

Роботи. У DFD роботи являють собою функції системи, що перетворюють входи у виходи.

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

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

Злиття і розгалуження стрілок. У DFD стрілки можуть зливатися і розгалужуватися, що дозволяє описати декомпозицію стрілок. Кожний новий сегмент стрілки, що зливається або розгалужується може мати власне ім'я.

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

Альтернативним підходом є підхід, популярний при створенні програмного забезпечення, називаний подійним поділом (event partitioning), у якому різні діаграми DFD вибудовують модель системи. По-перше, логічна модель будується як сукупність робіт і документування того, що вони (ці роботи) повинні робити.

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

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

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

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