1.Постановка завдання.
Розробити ПО ІС аптеки:
1) із застосуванням структурного підходу, створивши: початкову контекстну діаграму; концептуальну модель даних з атрибутами; діаграми потоків даних нульового і наступних рівнів для процесів ІС; діаграми системних процесів нульового і наступних рівнів; діаграму послідовності екранних форм.
2) із застосуванням об'єктно-орієнтованого підходу в середовищі Rational Rose реалізувати: діаграму варіантів використання; діаграму класів; діаграму послідовності; кооперативну діаграму; діаграму пакетів; мережеву конфігурацію системи; діаграму стану.
2. Структурний підхід до розробки ПЗ ІС Аптеки.
2.1. Життєвий цикл ПЗ ІС.
Одним з базових понять методології проектування ІС є поняття життєвого циклу її програмного забезпечення (ЖЦ ПЗ). ЖЦ ПЗ - це безперервний процес, який починається з моменту прийняття рішення про необхідність його створення і закінчується в момент його повного вилучення з експлуатації.
Основним нормативним документом, що регламентує ЖЦ ПЗ, є міжнародний стандарт ISO / IEC 12207 [5] (ISO - International Organization of Standardization - Міжнародна організація по стандартизації, IEC - International Electrotechnical Commission - Міжнародна комісія по електротехніці). Він визначає структуру ЖЦ, що містить процеси, дії і завдання, які повинні бути виконані під час створення ПЗ.
Структура ЖЦ ПЗ за стандартом ISO / IEC 12207 базується на трьох групах процесів:
· Основні процеси ЖЦ ПЗ (придбання, постачання, розробка, експлуатація, супровід);
· Допоміжні процеси, що забезпечують виконання основних процесів (документування, управління конфігурацією, забезпечення якості, верифікація, атестація, оцінка, аудит, рішення проблем);
· Організаційні процеси (управління проектами, створення інфраструктури проекту, визначення, оцінка та поліпшення самого ЖЦ, навчання).
Розробка включає в себе всі роботи по створенню ПЗ і його компонент відповідно до заданих вимог, включаючи оформлення проектної та експлуатаційної документації, підготовку матеріалів, необхідних для перевірки працездатності та відповідної якості програмних продуктів, матеріалів, необхідних для організації навчання персоналу і т.д. Розробка ПЗ включає в себе, як правило, аналіз, проектування і реалізацію (програмування).
Експлуатація включає в себе роботи з впровадження компонентів ПЗ в експлуатацію, в тому числі конфігурування бази даних і робочих місць користувачів, забезпечення експлуатаційної документації, проведення навчання персоналу і т.д., і безпосередньо експлуатацію, в тому числі локалізацію проблем і усунення причин їх виникнення , модифікацію ПЗ в рамках встановленого регламенту, підготовку пропозицій щодо вдосконалення, розвитку та модернізації системи.
Управління проектом пов'язано з питаннями планування та організації робіт, створення колективів розробників і контролю за термінами і якістю виконуваних робіт. Технічне і організаційне забезпечення проекту включає вибір методів та інструментальних засобів для реалізації проекту, визначення методів опису проміжних станів розробки, розробку методів і засобів випробувань ПЗ, навчання персоналу тощо Забезпечення якості проекту пов'язане з проблемами верифікації, перевірки та тестування ПЗ. Верифікація - це процес визначення того, чи відповідає поточний стан розробки, досягнуту на даному етапі, вимогам цього етапу. Перевірка дозволяє оцінити відповідність параметрів розробки з вихідними вимогами. Перевірка частково збігається з тестуванням, яке пов'язане з ідентифікацією відмінностей між дійсними та очікуваними результатами і оцінкою відповідності характеристик ПЗ вихідним вимогам. У процесі реалізації проекту важливе місце займають питання ідентифікації, опису і контролю конфігурації окремих компонентів і всієї системи в цілому.
Управління конфігурацією є одним з допоміжних процесів, що підтримують основні процеси життєвого циклу ПЗ, передусім процеси розробки і супроводу ПЗ. При створенні проектів складних ІС, що складаються з багатьох компонентів, кожен з яких може мати різновиди чи версії, виникає проблема обліку їх зв'язків і функцій, створення уніфікованої структури та забезпечення розвитку всієї системи. Управління конфігурацією дозволяє організувати, систематично враховувати і контролювати внесення змін в ПЗ на всіх стадіях ЖЦ. Загальні принципи та рекомендації конфігураційного обліку, планування та управління конфігураціями ПЗ відображені в проекті стандарту ISO 12207-2 [5].
Кожен процес характеризується певними завданнями і методами їх вирішення, вихідними даними, отриманими на попередньому етапі, і результатами. Результатами аналізу, зокрема, є функціональні моделі, інформаційні моделі та відповідні їм діаграми. ЖЦ ПО носить ітераційний характер: результати чергового етапу часто викликають зміни в проектних рішеннях, вироблених на більш ранніх етапах.
Моделі життєвого циклу ПЗ
Стандарт ISO / IEC 12207 не пропонує конкретну модель ЖЦ і методи розробки ПЗ (під моделлю ЖЦ розуміється структура, що визначає послідовність виконання та взаємозв'язку процесів, дій і завдань, що виконуються протягом ЖЦ. Модель ЖЦ залежить від специфіки ІС та специфіки умов, в яких остання створюється і функціонує). Його регламенти є загальними для будь-яких моделей ЖЦ, методологій і технологій розробки. Стандарт ISO / IEC 12207 описує структуру процесів ЖЦ ПЗ, але не конкретизує в деталях, як реалізувати або виконати дії і завдання, включені в ці процеси.
До теперішнього часу найбільшого поширення набули наступні дві основні моделі ЖЦ:
· Каскадна модель (70-85 р.р.);
· Спіральна модель (86-90 р.р.).
У спочатку існували однорідних ІС кожен додаток являло собою єдине ціле. Для розробки такого типу додатків застосовувався каскадний спосіб. Його основною характеристикою є розбиття всієї розробки на етапи, причому перехід з одного етапу на наступний відбувається тільки після того, як буде повністю завершена робота на поточному. Кожен етап завершується випуском повного комплекту документації, достатньої для того, щоб розробка могла бути продовжена іншою командою розробників.
Позитивні сторони використання каскадного підходу полягають у наступному [2]:
· На кожному етапі формується закінчений набір проектної документації, який відповідає критеріям повноти та узгодженості;
· Виконуються в логічній послідовності етапи робіт дозволяють планувати терміни завершення всіх робіт і відповідні витрати.
2.1.3. Стандарт ISO 12207.
Стандарт ISO 12207 - Процеси життєвого циклу програмного забезпечення - найбільш повно на рівні міжнародних стандартів відображає життєвий цикл, технологію розробки та забезпечення якості складних програмних засобів. Життєвий цикл ПЗ представлений набором етапів, приватних робіт та операцій у послідовності їх виконання і взаємозв'язку, що регламентують ведення розробки на всіх стадіях від підготовки технічного завдання до завершення випробувань ряду версій і закінчення експлуатації ПЗ. У ЖЦ включаються описи вихідної інформації, способів виконання операцій і робіт, встановлюються вимоги до результатів і правил їх контролю, а також до змісту технологічних та експлуатаційних документів. Визначається організаційна структура колективів, розподіл і планування робіт, а також контроль за реалізацією ЖЦ ПЗ.
Стандарт визначає архітектуру, процеси, розділи і підрозділи ЖЦ ПЗ, а також перелік базових робіт та деталізує зміст кожної з них. Архітектура ЖЦ ПЗ в стандарті базується на трьох великих компонентах (Мал. 4):
· Основні процеси життєвого циклу ПЗ і визначальні роботи (розділ 5);
· Допоміжні процеси і роботи, що підтримують життєвий цикл ПЗ (розділ 6);
· Організаційні процеси і керування життєвим циклом ПЗ (розділ 7).
Ці розділи стандарту складаються з ряду підрозділів, в яких детально розкривається зміст кожної роботи та коментуються особливості їх виконання. Рекомендації до кожного підрозділу складаються в середньому з 3-6 пунктів - робіт (процедур). Загальна кількість робіт і коментарів до них у стандарті понад 220.
У розділі 5 викладені основи ЖЦ і рекомендації з підготовки, розробки, експлуатації і супроводу програмних засобів (див. Рис. 4). Процеси придбання та / або підготовки до створення ПЗ повинні починатися з ініціалізації проекту, аналізу концепції, аналіз ринку продуктів, вироблення вимог і складу підтримують документів, створення попереднього плану проекту. Основні роботи зі створення складного комплексу програм рекомендується починати з визначення складу супровідних документів, вибору засобів конфігураційного керування і забезпечення якості, а також вибору методів і засобів технологічного забезпечення розробки всієї інформаційної системи. Кодування і тестування кожного компонента ПЗ повинно бути оформлено сукупністю документів, що засвідчують відповідність компонента первинної специфікації, що містять тести і результати тестування.
Рекомендується розробляти план робіт, що включає комплексування компонентів, тестування з усіх розділів вимог і показникам якості, а також документування плану, результатів інтеграції, використаних тестів, критеріїв оцінки та отриманих результатів. Далі ПО слід піддавати кваліфікаційному (атестаційної) тестування з усіх розділів вимог контракту, при широкому варіюванні тестів, змінах значень критеріїв, а також тестувати повноту й адекватність технологічної та документації користувача реальному програмному продукту. Перевірений таким чином комплекс програм інтегрується в обчислювальні засоби інформаційної системи, засоби візуалізації та телекомунікації.
Ці роботи взаємодіють з роботами, що забезпечують супровід ПЗ. Фахівці аналізують повідомлення про помилки та пропозиції на модифікацію ПЗ, селектіруют їх на відповідність вимогам контракту й оцінюють доцільність проведення змін. Підготовлені зміни тестуються і перевіряються за критеріями, визначеними в документації.
Допоміжні технологічні роботи, підтримують життєвий цикл ПЗ, і рекомендації щодо їх виконання викладені в розділі 6. Процеси документування ПЗ повинні охоплювати планування і забезпечення документування, рекомендації по стандартизації, проектування та розробки, а також з виробництва, конфігураційного управління і супроводу комплекту документації на ПЗ. Для забезпечення гарантій якості слід використовувати планування, методологію, процедури і стандарти підтримки якості ПЗ відповідно до контракту з урахуванням доступних ресурсів. Верифікація ПО повинна включати її організацію, планування і технічне забезпечення. Посвідчення правильності (атестація) повинна гарантувати повну відповідність програмного продукту специфікаціям, вимогам і документації на ПЗ і можливість його надійного функціонування та безпечного застосування користувачем.
Організації життєвого циклу ПЗ присвячений розділ 7. Вона містить основні роботи з управління проектом, виробництвом та засобами для забезпечення процесів по розробці, експлуатації і супроводу. Процеси формування інфраструктури повинні складатися з вибору та встановлення апаратних і програмних засобів, технології, стандартів і обслуговування, що використовуються для розробки, супроводу та забезпечення експлуатації ПС. Процеси вдосконалення життєвого циклу ПС перебувають у встановленні, оцінюванні, вимірюванні, контролі та коригуванні процесів життєвого циклу конкретних ПЗ. Процеси навчання визначаються вимогами до проекту, повинні враховувати необхідні ресурси, управління і технічні засоби. Викладено рекомендації щодо перетворення та адаптації базової структури цього міжнародного стандарту для конкретного проекту (додаток А) і керівництво щодо їх виконання в ЖЦ ПЗ (додаток В).
2.2. Діаграми, реалізовані в структурному підході.
1. Початкова контекстна діаграма ПО ІС Аптеки:
Чек Документи
Отримане ліки Замовлення (опт)
База ліків
Заявка на ліки ТТН
Замовлення від Зав. Аптеки
Заявка на ліки Документи
База ліків
Ліки Відправка замовлення на ліки
Чек ТТН
Замовлення (опт)
Наявність даного ліки
2. Концептуальна модель даних з атрибутами.
(0, N) (1,1)
(1,1) (0, N
(0, N)
(0, N)
(1,1)
Розробити ПО ІС аптеки:
1) із застосуванням структурного підходу, створивши: початкову контекстну діаграму; концептуальну модель даних з атрибутами; діаграми потоків даних нульового і наступних рівнів для процесів ІС; діаграми системних процесів нульового і наступних рівнів; діаграму послідовності екранних форм.
2) із застосуванням об'єктно-орієнтованого підходу в середовищі Rational Rose реалізувати: діаграму варіантів використання; діаграму класів; діаграму послідовності; кооперативну діаграму; діаграму пакетів; мережеву конфігурацію системи; діаграму стану.
2. Структурний підхід до розробки ПЗ ІС Аптеки.
2.1. Життєвий цикл ПЗ ІС.
Одним з базових понять методології проектування ІС є поняття життєвого циклу її програмного забезпечення (ЖЦ ПЗ). ЖЦ ПЗ - це безперервний процес, який починається з моменту прийняття рішення про необхідність його створення і закінчується в момент його повного вилучення з експлуатації.
Основним нормативним документом, що регламентує ЖЦ ПЗ, є міжнародний стандарт ISO / IEC 12207 [5] (ISO - International Organization of Standardization - Міжнародна організація по стандартизації, IEC - International Electrotechnical Commission - Міжнародна комісія по електротехніці). Він визначає структуру ЖЦ, що містить процеси, дії і завдання, які повинні бути виконані під час створення ПЗ.
Структура ЖЦ ПЗ за стандартом ISO / IEC 12207 базується на трьох групах процесів:
· Основні процеси ЖЦ ПЗ (придбання, постачання, розробка, експлуатація, супровід);
· Допоміжні процеси, що забезпечують виконання основних процесів (документування, управління конфігурацією, забезпечення якості, верифікація, атестація, оцінка, аудит, рішення проблем);
· Організаційні процеси (управління проектами, створення інфраструктури проекту, визначення, оцінка та поліпшення самого ЖЦ, навчання).
Розробка включає в себе всі роботи по створенню ПЗ і його компонент відповідно до заданих вимог, включаючи оформлення проектної та експлуатаційної документації, підготовку матеріалів, необхідних для перевірки працездатності та відповідної якості програмних продуктів, матеріалів, необхідних для організації навчання персоналу і т.д. Розробка ПЗ включає в себе, як правило, аналіз, проектування і реалізацію (програмування).
Експлуатація включає в себе роботи з впровадження компонентів ПЗ в експлуатацію, в тому числі конфігурування бази даних і робочих місць користувачів, забезпечення експлуатаційної документації, проведення навчання персоналу і т.д., і безпосередньо експлуатацію, в тому числі локалізацію проблем і усунення причин їх виникнення , модифікацію ПЗ в рамках встановленого регламенту, підготовку пропозицій щодо вдосконалення, розвитку та модернізації системи.
Управління проектом пов'язано з питаннями планування та організації робіт, створення колективів розробників і контролю за термінами і якістю виконуваних робіт. Технічне і організаційне забезпечення проекту включає вибір методів та інструментальних засобів для реалізації проекту, визначення методів опису проміжних станів розробки, розробку методів і засобів випробувань ПЗ, навчання персоналу тощо Забезпечення якості проекту пов'язане з проблемами верифікації, перевірки та тестування ПЗ. Верифікація - це процес визначення того, чи відповідає поточний стан розробки, досягнуту на даному етапі, вимогам цього етапу. Перевірка дозволяє оцінити відповідність параметрів розробки з вихідними вимогами. Перевірка частково збігається з тестуванням, яке пов'язане з ідентифікацією відмінностей між дійсними та очікуваними результатами і оцінкою відповідності характеристик ПЗ вихідним вимогам. У процесі реалізації проекту важливе місце займають питання ідентифікації, опису і контролю конфігурації окремих компонентів і всієї системи в цілому.
Управління конфігурацією є одним з допоміжних процесів, що підтримують основні процеси життєвого циклу ПЗ, передусім процеси розробки і супроводу ПЗ. При створенні проектів складних ІС, що складаються з багатьох компонентів, кожен з яких може мати різновиди чи версії, виникає проблема обліку їх зв'язків і функцій, створення уніфікованої структури та забезпечення розвитку всієї системи. Управління конфігурацією дозволяє організувати, систематично враховувати і контролювати внесення змін в ПЗ на всіх стадіях ЖЦ. Загальні принципи та рекомендації конфігураційного обліку, планування та управління конфігураціями ПЗ відображені в проекті стандарту ISO 12207-2 [5].
Кожен процес характеризується певними завданнями і методами їх вирішення, вихідними даними, отриманими на попередньому етапі, і результатами. Результатами аналізу, зокрема, є функціональні моделі, інформаційні моделі та відповідні їм діаграми. ЖЦ ПО носить ітераційний характер: результати чергового етапу часто викликають зміни в проектних рішеннях, вироблених на більш ранніх етапах.
Моделі життєвого циклу ПЗ
Стандарт ISO / IEC 12207 не пропонує конкретну модель ЖЦ і методи розробки ПЗ (під моделлю ЖЦ розуміється структура, що визначає послідовність виконання та взаємозв'язку процесів, дій і завдань, що виконуються протягом ЖЦ. Модель ЖЦ залежить від специфіки ІС та специфіки умов, в яких остання створюється і функціонує). Його регламенти є загальними для будь-яких моделей ЖЦ, методологій і технологій розробки. Стандарт ISO / IEC 12207 описує структуру процесів ЖЦ ПЗ, але не конкретизує в деталях, як реалізувати або виконати дії і завдання, включені в ці процеси.
До теперішнього часу найбільшого поширення набули наступні дві основні моделі ЖЦ:
· Каскадна модель (70-85 р.р.);
· Спіральна модель (86-90 р.р.).
У спочатку існували однорідних ІС кожен додаток являло собою єдине ціле. Для розробки такого типу додатків застосовувався каскадний спосіб. Його основною характеристикою є розбиття всієї розробки на етапи, причому перехід з одного етапу на наступний відбувається тільки після того, як буде повністю завершена робота на поточному. Кожен етап завершується випуском повного комплекту документації, достатньої для того, щоб розробка могла бути продовжена іншою командою розробників.
Позитивні сторони використання каскадного підходу полягають у наступному [2]:
· На кожному етапі формується закінчений набір проектної документації, який відповідає критеріям повноти та узгодженості;
· Виконуються в логічній послідовності етапи робіт дозволяють планувати терміни завершення всіх робіт і відповідні витрати.
2.1.3. Стандарт ISO 12207.
Стандарт ISO 12207 - Процеси життєвого циклу програмного забезпечення - найбільш повно на рівні міжнародних стандартів відображає життєвий цикл, технологію розробки та забезпечення якості складних програмних засобів. Життєвий цикл ПЗ представлений набором етапів, приватних робіт та операцій у послідовності їх виконання і взаємозв'язку, що регламентують ведення розробки на всіх стадіях від підготовки технічного завдання до завершення випробувань ряду версій і закінчення експлуатації ПЗ. У ЖЦ включаються описи вихідної інформації, способів виконання операцій і робіт, встановлюються вимоги до результатів і правил їх контролю, а також до змісту технологічних та експлуатаційних документів. Визначається організаційна структура колективів, розподіл і планування робіт, а також контроль за реалізацією ЖЦ ПЗ.
Стандарт визначає архітектуру, процеси, розділи і підрозділи ЖЦ ПЗ, а також перелік базових робіт та деталізує зміст кожної з них. Архітектура ЖЦ ПЗ в стандарті базується на трьох великих компонентах (Мал. 4):
· Основні процеси життєвого циклу ПЗ і визначальні роботи (розділ 5);
· Допоміжні процеси і роботи, що підтримують життєвий цикл ПЗ (розділ 6);
· Організаційні процеси і керування життєвим циклом ПЗ (розділ 7).
Ці розділи стандарту складаються з ряду підрозділів, в яких детально розкривається зміст кожної роботи та коментуються особливості їх виконання. Рекомендації до кожного підрозділу складаються в середньому з 3-6 пунктів - робіт (процедур). Загальна кількість робіт і коментарів до них у стандарті понад 220.
У розділі 5 викладені основи ЖЦ і рекомендації з підготовки, розробки, експлуатації і супроводу програмних засобів (див. Рис. 4). Процеси придбання та / або підготовки до створення ПЗ повинні починатися з ініціалізації проекту, аналізу концепції, аналіз ринку продуктів, вироблення вимог і складу підтримують документів, створення попереднього плану проекту. Основні роботи зі створення складного комплексу програм рекомендується починати з визначення складу супровідних документів, вибору засобів конфігураційного керування і забезпечення якості, а також вибору методів і засобів технологічного забезпечення розробки всієї інформаційної системи. Кодування і тестування кожного компонента ПЗ повинно бути оформлено сукупністю документів, що засвідчують відповідність компонента первинної специфікації, що містять тести і результати тестування.
Рекомендується розробляти план робіт, що включає комплексування компонентів, тестування з усіх розділів вимог і показникам якості, а також документування плану, результатів інтеграції, використаних тестів, критеріїв оцінки та отриманих результатів. Далі ПО слід піддавати кваліфікаційному (атестаційної) тестування з усіх розділів вимог контракту, при широкому варіюванні тестів, змінах значень критеріїв, а також тестувати повноту й адекватність технологічної та документації користувача реальному програмному продукту. Перевірений таким чином комплекс програм інтегрується в обчислювальні засоби інформаційної системи, засоби візуалізації та телекомунікації.
Ці роботи взаємодіють з роботами, що забезпечують супровід ПЗ. Фахівці аналізують повідомлення про помилки та пропозиції на модифікацію ПЗ, селектіруют їх на відповідність вимогам контракту й оцінюють доцільність проведення змін. Підготовлені зміни тестуються і перевіряються за критеріями, визначеними в документації.
Допоміжні технологічні роботи, підтримують життєвий цикл ПЗ, і рекомендації щодо їх виконання викладені в розділі 6. Процеси документування ПЗ повинні охоплювати планування і забезпечення документування, рекомендації по стандартизації, проектування та розробки, а також з виробництва, конфігураційного управління і супроводу комплекту документації на ПЗ. Для забезпечення гарантій якості слід використовувати планування, методологію, процедури і стандарти підтримки якості ПЗ відповідно до контракту з урахуванням доступних ресурсів. Верифікація ПО повинна включати її організацію, планування і технічне забезпечення. Посвідчення правильності (атестація) повинна гарантувати повну відповідність програмного продукту специфікаціям, вимогам і документації на ПЗ і можливість його надійного функціонування та безпечного застосування користувачем.
Організації життєвого циклу ПЗ присвячений розділ 7. Вона містить основні роботи з управління проектом, виробництвом та засобами для забезпечення процесів по розробці, експлуатації і супроводу. Процеси формування інфраструктури повинні складатися з вибору та встановлення апаратних і програмних засобів, технології, стандартів і обслуговування, що використовуються для розробки, супроводу та забезпечення експлуатації ПС. Процеси вдосконалення життєвого циклу ПС перебувають у встановленні, оцінюванні, вимірюванні, контролі та коригуванні процесів життєвого циклу конкретних ПЗ. Процеси навчання визначаються вимогами до проекту, повинні враховувати необхідні ресурси, управління і технічні засоби. Викладено рекомендації щодо перетворення та адаптації базової структури цього міжнародного стандарту для конкретного проекту (додаток А) і керівництво щодо їх виконання в ЖЦ ПЗ (додаток В).
2.2. Діаграми, реалізовані в структурному підході.
1. Початкова контекстна діаграма ПО ІС Аптеки:
Замовлення від Зав. Аптеки
Чек ТТН
Замовлення (опт)
3 |______________ Касир |
4 |______________ Зав. Аптекою |
2. Концептуальна модель даних з атрибутами.
Відправляє |
Отримує |
|
(0, N)
|
Відправляє |
(0, N)
(1,1)
Отримує |
(1,1)
Оплачує |
(1,1)
Отримує |
(1,1)
Видає |
| |||||
3. Діаграма потоків 0-го рівня.
Оплата ліки |
Заявка на ліки |
База ліків |
Товарно-транспортна накладна |
Відправка замовлення на ліки |
Отримане ліки |
Чек |
Документи для отримання замовлення |
Замовлення (опт) |
1 База ліків
____________ 3_____________ Адміністрування __оплати та видачі лекарств_ |
Наявність ліки |
Товарно-транспортна накладна |
Відправка замовлення на ліки |
Документи для отримання замовлення |
База ліків |
Заявка на ліки |
4 |______________ Зав. Аптекою |
Замовлення (опт) |
Оплата ліки |
Ліки |
3 |______________ Касир |
Чек |
4. Діаграма потоків даних першого рівня для процесу 2.
____________ 2.1____________ Обслужити ________покупателя________ |
Заявка на ліки |
1 |______________ Покупець |
____________ 2.2____________ Підготувати ____заявку від покупателя____ |
Покупці
Заявка на ліки |
Наявність ліки |
База ліків |
Ліки
3 |_____________ Касир |
5. Діаграма потоків даних другого рівня для процесу 2.1.
Заявка на ліки |
____________ 2.1.1__________ Підтвердити ________регістрацію________ |
1 |_____________ Покупець |
____________ 2.1.2__________ Зареєструвати _____заявку покупателя_____ |
Номер покупця |
Підтвердження реєстрації |
Покупці
6. Діаграма потоків даних першого рівня для процесу 2
Чек |
Ліки |
Ліки |
3 |______________ Касир |
1 |______________ Покупець |
____________ 2.1____________ Сплатити _________лекарство_________ |
Чек |
Оплата |
____________ 2.2____________ Видати _________лекарство_________ |
Ліки
7. Діаграма системних процесів нульового рівня
База ліків |
Ліки |
Наявність даного ліки |
Вартість ліки |
Оплата ліки |
2 |_____________ Менеджер |
Заявка на ліки |
Отримане ліки |
Чек |
База ліків |
1 |______________ Покупець |
3 |______________ Касир |
4 |______________ Зав. Аптекою |
5 |______________ Принтер |
Чек |
Документи |
Замовлення (опт) |
Замовлення на ліки |
ТТН |
Документи |
Замовлення на ліки |
ТТН |
Замовлення (опт) |
Чек до |
8. Діаграма системних процесів першого рівня
1 |______________ Покупець |
3 |_____________ Касир |
5 |______________ Принтер |
2 ____ ПК Відділу продажів _______ |
3 ____ ПК Менеджера__ _______ |
4 _ ПК Завідувача аптекою ____ |
4 |_____________ Зав. Аптекою |
2 |_____________ Менеджер |
Чек до |
6 |______________ ЛВС |
1 БД ІС Аптеки
9. Діаграма послідовності екранних форм.
Система аптеки |
Персонал |
Купівля |
Ліки |
Чек |
Заявка |
Зав. Аптеки |
Касир |
Менеджер |
Покупець |
3. Об'єктно-орієнтований підхід до розробки ПЗ ІС Аптеки
1. Use - Case Diagram.
2. Sequence Diagram.
3.Traceabilities.
4. Мережева конфігурація системи.
5. Collaboration Diagram.
Висновок.
У цій роботі розроблена інформаційна система аптеки в Case-засобі Rational Rose корпорації Rational.
У ході роботи була створена початкова контекстна діаграма, яка є основною при побудові діаграм DFD, що розбиваються на діаграми потоків нульового і наступних рівнів для процесів ІС. Також була сконструйована концептуальна модель з атрибутами, тобто діаграма ERD, що є прототипом бази даних, яка включає в себе базу даних замовлень і ліків в аптечній мережі.
Для представлення діаграм на фізичному рівні були створені діаграми системних процесів, що відображають взаємозв'язок комп'ютерів, людей за допомогою ЛОМ та мереж Інтернет.
Структурний підхід дає основу для створення діаграм об'єктно-орієнтованого підходу в середовищі Rational Rose.
Об'єктно-орієнтований підхід включає в себе в першу чергу діаграму варіантів використання, яка вдає із себе дійових осіб, які беруть участь у створенні ІС Аптеки (менеджер оптової фірми, завідувач аптекою, касир, покупець) і пов'язані з їх діяльністю варіанти використання.
З діаграми варіантів використання випливають діаграми послідовностей, що дозволяють розбивати і уточнювати кожен варіант використання.
Наступним етапом об'єктно-орієнтованого підходу є створення класів з відповідними атрибутами (з визначенням стереотипів класів) і взаємодія між класами.
Діаграма мережевої конфігурації системи показує, що менеджеру, завідувачу аптекою, касиру, покупцеві необхідні комп'ютери, виділений сервер для зберігання заявок від покупця, документів для отримання замовлень, базу даних медичних ліків. Комп'ютери менеджерів, а також покупців, з сервером будуть з'єднаються з допомогою глобальної мережі Інтернет.
Відповідно, комп'ютери завідуючої і касира можуть бути з'єднані з допомогою ЛОМ, і теж можуть працювати з сервером через мережу Інтернет.
У подальшому для цієї інформаційної системи повинні бути створені програмістами користувальницькі додатки окремо для клієнтів, касира, менеджерів, завідувачки аптеки.
Список використаної літератури.
1. Міроненкова Ж.В. Розвиток інформаційних мереж у фармацевтичній галузі / Міроненкова Ж.В., Лозова Г.Ф. / / В зб.: Матеріали Х Російського національного конгресу «Людина і ліки». - М., 2003. - С. 12.
2. http://ref.ruscore.ru/rqref/part6/item7101.html
3. http://www.klubok.net/downloads2.html
4. http://inform-referats.narod.ru/informatic-all.htm
5. http://rational.com