Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Не вказано
Факультет:
Комп'ютерні науки
Кафедра:
Не вказано
Інформація про роботу
Рік:
2008
Тип роботи:
Інші
Предмет:
Інші
Частина тексту файла (без зображень, графіків і формул):
МІНІСТЕРСТВО ОСВІТИ ТА НАУКИ УКРАЇНИ
НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ “ЛЬВІВСЬКА ПОЛІТЕХНІКА”
Кафедра ПЗ
Створення та робота з випадками використання в Rational Rose
Методичні матеріали
до лабораторної роботи № 2 з курсу:
“Основи проектування інформаційних систем”
для студентів базового напрямку
6.0804 “Комп’ютерні науки”
ЗАТВЕРДЖЕНО
на засіданні кафедри
“Програмне забезпечення”
Протокол №
від
ЛЬВІВ 2008
Створення та робота з випадками використання в Rational Rose. Методичні матеріали до лабораторної роботи № 2 з курсу: “ Основи проектування інформаційних систем ” для студентів базового напрямку 6.0804 “Комп’ю тер ні науки”.
Укладачі:
Макар В.М., доцент, к.т.н.
Муха Т.О.., асистент.
Відповідальний за випуск:
Рецензенти:
1. МЕТА РОБОТИ
Ознайомитися з основними принципами побудови моделей за допомогою програмного засобу Rational Rose, нав читися створювати акторів, випадки використання, відношення між ними та будувати діаграму випадків використання.
2.ОСНОВНІ ТЕОРЕТИЧНІ ВІДОМОСТІ
2.1 Основні поняття і постановка модельної задачі
Робота над моделлю в середовищі Rational Rose починається із загального аналізу проблеми і побудови діаграми варіантів використання, яка відображає функціональне призначення програмної системи, що проектується. Основне завдання діаграми варіантів використання – бути єдиним засобом, який дав би можливість замовнику, кінцевому користувачеві і розробнику спільно обговорювати функціональність і поведінку системи.
Модельна задача
Основним прикладом, що буде розглядатися є реєстрація курсів в університеті ESU (Eastern State University).
Після того, як викладачі ESU вирішать, які курси вони будуть вести протягом семестру, служба реєстрації курсів введе інформацію в комп’ютерну систему. Потім для викладачів видрукують сумарний звіт по курсах, які вони читатимуть, а для студентів – каталог курсів.
На цьому етапі студенти заповнюють спеціальну реєстраційну форму, де вказують вибрані курси і віддають її в службу реєстрації. Зазвичай студент підписується на чотири курси, після чого інформація заноситься в комп’ютер. Після цього запускається нічна пакетна програма, яка розподіляє студентів по курсах. При виникненні конфліктної ситуації служба реєстрації уточнює дані студента. Після вдалого розподілення студенту висилається розклад для провірки. Зазвичай, процес реєстрації на курси займає близько тижня, проте в ряді випадків може бути потрібно до двох тижнів, щоб залагодити всі питання. Після цього викладачі отримують список студентів для кожного курсу, який вони будуть читати.
Постановка задачі реєстрації курсів:
На початку кожного семестру студенти можуть запросити каталог курсів, в який включений список предметів, навчання по яких пропонується в даному семестрі. Інформація про курси повинна містити прізвище викладача, назву факультету і короткий опис, який допоможе студентам зробити вибір.
Нова система дозволить студенту здійснити вибір чотирьох курсів, із тих що пропонуються в наступаючому семестрі. Крім того студенту потрібно вказати ще два варіанта на випадок якщо курс буде відмінений або переповнений. На курс не повинно бути записано більше десяти і менше трьох студентів. Курс, на який запишеться менше трьох студентів буде відмінений. Після закінчення реєстрації система реєстрації направляє інформацію в систему оплати для виставлення рахунків студентам.
Викладачі повинні мати можливість он-лайнового доступу до системи для вказання курсів, які вони будуть читати, і для перегляду списку студентів, що записалися.
В кожному семестрі виділяється визначений час, протягом якого студенти можуть міняти свій розклад і отримувати доступ до системи для додавання і видалення вибраних курсів.
Актори
Актори не є частиною системи – вони являються чимось або кимось, що повинно взаємодіяти з системою.
Актори можуть:
тільки надавати інформацію системі
тільки отримувати інформацію із системи
надавати і отримувати інформацію із системи
Зазвичай акторів визначають із опису задачі або шляхом переговорів із замовниками і експертами. Для визначення акторів може бути використаний наступний набір запитань:
хто використовує систему
хто відповідає за супровід системи
зовнішнє апаратне забезпечення, що використовується системою інші системи, які повинні взаємодіяти із даною системою
Потрібно уважно підходити до питання визначення акторів для системи. Таке визначення зазвичай відбувається ітеративно – перший із затверджених списків акторів як правило далекий від кінцевого. Наприклад, чи є новий студент актором іншого виду, ніж студент, що повернувся із академічної відпустки? Припустимо спочатку зупинились на ствердній відповіді. Наступний крок – вияснити як актор взаємодіє із системою. Якщо новий студент використовує систему не так, як студент, що повернувся, то це різні актори. Якщо ж вони використовують систему однаковим чином – це один і той же актор.
Інший варіант – створення актора для кожної ролі, яку виконує учасник. Тут теж можна отримати надлишковість. Наприклад, немає потреби створювати окремого актора, тому що необхідні засоби, уже закладені для акторів в ролі студентів і викладачів.
Для системи реєстрації курсів можна виділити наступних акторів:
студент
викладач
реєстратор
система оплати
Випадки використання (Use cases)
За допомогою випадків використання (use cases) моделюється діалог між актором і системою. Іншими словами, вони визначають можливості, які система забезпечує для актора. Набір всіх випадків використання визначає способи її використання.
Протягом довгих років велися дискусії на тему правильності випадків використання. Однією із проблем є рівень їх деталізації. Наскільки детальним повинен він бути? Однозначної відповіді немає. Для визначення рівня деталізації може використовуватись наступне правило: «Випадок використання визначає основний елемент функціональності і відбувається від початку до кінця. Він повинен приносити щось значне для актора».
Наприклад: в системі реєстрації навчальних курсів студент повинен обрати курси для наступного семестру; студент повинен бути закріплений до пропонованих курсів; студенту повинен бути виставлений рахунок. Це три випадки використання чи один? Варто було б організувати як один, тому що функціональність того, що відбувається, визначає те, що відбувається, від початку до кінця.
Друга проблема в тому, як об’єднати функціональність різних дій, які здаються єдиними. Наприклад, реєстратор повинен добавляти курси, видаляти і змінювати їх. Три випадки використання чи один? Знову таки варто було б організувати один, робота з навчальним планом тому, що дії виконуються одним актором (реєстратором) і виконуються над однією сутністю (розкладом).
На основі описаних вище потреб можна виділити наступні випадки використання:
реєстрація на курси
вибір курсів для викладання
запит розкладу курсів
управління інформацією про курси
управління інформацією про викладачів
управління інформацією про студентів
створення каталогу курсів
Відношення
Між актором і випадком використання може існувати лише один тип відношення – асоціативне відношення. Асоціативне відношення може бути або одностороннім (від актора до випадку відношення або від випадку відношення до актора), або двостороннім (від актора до випадку відношення і від випадку відношення до актора). Напрямок зв’язку показує, хто є її ініціатором (актор чи випадок використання). Такий тип відношення зображається у вигляді суцільної лінії, що з’єднує елементи, що взаємодіють. Напрямок взаємодії зображається стрілкою.
Існує два типи відношень між випадками використання: включає і доповнює. Різні випадки використання можуть мати фрагменти, що функціонують однаково. Їх зазвичай виділяють в окремий випадок використання, щоб не повторювати декілька разів. Відношення включає створюється тоді, коли один випадок використання використовує інший. Наприклад, кожний випадок використання в системі реєстрації курсів починається з аутентифікації користувача.
Відношення включає зображається у вигляді стрілки з переривчастою лінією з надписом (стереотипом) «include», яка напрямлена від базового випадку використання до використовуваного.
Відношення доповнює використовується для відображення:
додаткових режимів;
режимів, які запускаються тільки при відповідних умовах, наприклад сигнал тривоги;
альтернативних потоків, які запускаються по вибору актора.
Наприклад випадок використання, що контролює рух коробок на конвеєрі, може бути доповнений випадком використання сигналу тривоги при виникненні затору.
Відношення доповнює зображається у вигляді стрілки з переривчастою лінією з надписом (стереотипом) «extend».
2.2
Для створення нової пустої моделі в Rational Rose необхідно після запуску програми в вікні майстра створення моделі натиснути на кнопку Cancel. Для переходу на діаграму Use Case необхідно розкрити натисканням лівої кнопки миші розділ Use Case View у вікні Browser і двічі натиснути на піктограму із надписом Main. Результат виконання описаних вище дій зображено на рис.2.1.
Рис.2.1. Активізація Use Case діаграми
Rational Rose дає можливість створювати нові елементи моделі декількома способами:
Можна створити нові елементи, використовуючи контекстне меню, як зображено на рис.2.2.
Рис.2.2. Створення нового елементу за допомогою контекстного меню
Можна створити елементи за допомогою Menu: Tools → Create.
Ще можна створити за допомогою панелі інструментів.
В першому випадку елемент створюється безпосередньо в моделі, але його значок не включається в жодну діаграму. Після створення елементу таким чином необхідно помістити його на вибрану діаграму.
В другому і третьому випадку разом із створенням елементу його значок появляється на поточній діаграмі автоматично. Відповідно порівняно з першим випадком виконується на одну дію менше.
Перед тим, як приступити до власне побудови моделі варто ознайомитися із панеллю інструментів для діаграми випадків використання (Use case diagram).
Панель інструментів для діаграми випадків використання
Рис.2.3. Вигляд панелі інструментів для діаграми випадків використання
Selection Tool (інструмент вибору) – основний інструмент, який дозволяє вибирати елементи діаграми, для того, щоб виконувати над ними подальші дії. При створенні нового елемента діаграми треба вибрати потрібний інструмент в панелі інструментів, кнопка «залипає», а після створення треба знову перейти в режим Selection Tool.
Text Box (текст) – даний інструмент дає можливість створити довільний надпис на діаграмі, який не прив’язаний до жодного іншого елементу. Для створення напису потрібно натиснути кнопку Text Box, при цьому курсор приймає вигляд вертикальної стрілки, і клікнути в тому місці діаграми, де потрібно створити напис.
Note (замітка) – даний інструмент створює елемент замітку, що дозволяє вписати в нього прийняті під час аналізу рішення. Замітки можуть містити простий текст, фрагменти коду або посилання на інші документи. Досить часто Note з’єднують з іншими елементами діаграми за допомогою інструменту Anchor Note, для того щоб показати, до якого елементу діаграми відноситься замітка (рис.4.5).
Рис.2.4. Зв’язок між актором і заміткою
Anchor Note (якір для замітки) - цей інструмент дозволяє зв’язати елемент Note з будь-яким елементом на діаграмі, в тому числі із іншим елементом Note.
Package (пакет) – цей дозволяє створювати пакети, які можуть включати в себе групи елементі в Use case і в даній діаграмі може використовуватися для визначення більш великих сценаріїв поведінки об’єктів з подальшою деталізацією. До того ж пакети можуть включати в себе і інші пакети, що дозволяє створювати значний рівень вложеності деталізації.
Use case (випадки використання) – даний інструмент дозволяє створювати випадки використання (детальний опис наведений вище).
Actor (актор) – цей інструмент дає можливість створювати акторів (визначення і опис поняття наведені вище).
Unidirectional Association (однонаправлене відношення асоціації) – інструмент, що дає можливість створити однонаправлене відношення асоціації. Змінивши його параметри, його можна перетворити в двонаправлене відношення асоціації.
Dependency or instantiates (відношення включає або доповнює) – інструмент, який дозволяє створити зв’язок між випадками використання.
Рис.2.5. Актори і випадки використання для задачі реєстрації курсів
Створивши актори і випадки використання першим способом, який був описаний вище, отримуємо наступні випадки використанні і випадки використання.
Для створення діаграми випадків використання потрібно перенести ці елементи на діаграму.
Головна діаграма випадків використання для задачі реєстрації курсів зображена на Рис.2.6
Рис.2.6. Головна діаграма ІС реєстрації курсів
Окрім головної діаграми випадків використання можна створити ще й інші додаткові діаграми випадків використання. Для цього треба в контекстному меню розділу Use Case View обрати New → Use Case Diagram і ввести ім’я нової діаграми в Browser.
Рис.2.7. Створення додаткової діаграми випадків використання
Так наприклад для актора «Викладач» додаткова діаграма випадків використання може мати наступний вигляд:
Рис.2.8. Додаткової діаграма випадків використання
3.КОНТРОЛЬНІ ЗАПИТАННЯ
Які особливості елемента «актор»?
Що являє собою поняття «випадок використання»(Use Case), і що вони визначають?
Які труднощі виникають при визначенні набору випадків використання?
Для чого використовуються діаграми випадків використання?
Як створити нову діаграму?
Які значки є в панелі інструментів діаграми варіантів використання і яке їх значення?
4.ЛАБОРАТОРНЕ ЗАВДАННЯ
Ознайомитися з основними поняттями та елементами для побудови моделі інформаційної системи.
Провести аналіз завдання (індивідуальні завдання наведені в Додатку) визначити акторів і випадки використання, а також зв’язки між ними.
Побудувати діаграму випадків використання.
Оформити і здати звіт про виконання лабораторної роботи.
5.ЗМІСТ ЗВІТУ
Мета роботи.
Короткі теоретичні відомості.
Постановка задачі індивідуального завдання.
Оформлений належним чином (з коментарями та поясненнями) список акторів і випадків використання з коротким описом кожного, а також вигляд і покрокові дії для побудови діаграми випадків використання.
Аналіз результатів та висновки.
6.СПИСОК РЕКОМЕНДОВАНОЇ ЛІТЕРАТУРИ
Т.Кватрани. Rational Rose 2000 и UML. Визуальное моделирование.- М.: ДМК Пресс, 2001. - 176 с.
С.А. Трофимов. Case-технологии: практическая робота в Rational Rose. Изд. 2-е. – М.: Бином-Пресс, 2002. – 288 с.
http://www.intuit.ru/department/se/ibmrrose/3/1.html
ДОДАТОК
1. Інформаційна система автоматизації роботи лікарняного закладу. Лікар має можливість проглянути лікарняну картку конкретного пацієнта і добавити туди дані. Лікар може направити пацієнта для вияснення діагнозу на аналізи, результати яких повинні бути видані лікареві. Пацієнт має можливість проглянути розклад прийому лікарів.
2. Інформаційна система фірми, яка займається торгівлею. Система повинна розрізняти великий гурт, дрібно гуртових і роздрібних покупців. Замовник має мати можливість проглянути наявність товарів і їх ціни. В системі повинні реєструватися поступлення товарів і продаж товарів. Система має давати можливість менеджеру фірми перевірити наявність товару і замовити його у відділу постачання, якщо його немає. Система має видавати інформацію касиру про те, яка ціна на даний товар.
3. Інформаційна система бібліотеки університету. В системі повинен бути організований доступ для читачів до електронних каталогів. Для студентів і працівників університету повинен бути доступним і електронний варіант текстів книг. Читачі бібліотеки повинні мати змогу оформити за допомогою системи замовлення на книгу. Система повинна вести облік книг виданих в читальний зал і на абонемент.
4. Інформаційна система автомобільного салону. Покупець повинен мати змогу переглянути каталог автомобілів, що продаються, і їх характеристики. Менеджер повинен мати інформацію про наявність відповідних автомобілів і можливість їх замовити у постачальника. Салон повинен надавати гарантійне сервісне обслуговування автомобілям, купленим у них. Страхова компанія оформляє страховку для купленого автомобіля.
5. Система зрошування поля. Після збору інформації про температуру, вологість, швидкість вітру, робиться аналіз і визначається кількість води, яка повинна бути подана для зрошення зрошувальною системою. Для кожного виду рослин повинен бути визначений відповідний режим зрошування агрономом.
6. Інформаційна система зоопарку. Система постачання по замовленню системи контролю повинна постачати відповідну кількість корму для тварин. Адміністрація зоопарку може придбати або продати ту чи іншу тварину. Система контролю повинна вести облік тварин, контролювати стан їхнього здоров’я. Вразі захворювання повинен бути викликаний ветеринар, який лікуватиме тварину.
7. Інформаційна система житлового будинку. Адміністрація будинку повинна вести облік людей, що проживають у будинку, а також висилати рахунок і отримувати кошти за послуги від тих, хто проживає у будинку. В разі виникнення поломок, адміністрація повинна викликати майстрів, які б усунули поломку. Майстри отримають гроші за роботу від адміністрації. Ті хто проживають у будинку повинні інформувати адміністрацію про поломки.
8. Інформаційна система обліку працівників заводу. Адміністрація повинна мати можливість переглядати результати роботи робітників. Повинна мати можливість звільняти і набирати на роботу робітників. Адміністрація отримує зарплату від відділу бухгалтерії. Робітники теж отримують зарплату. Адміністрація може давати вказівки бухгалтерії преміювати тих чи інших робітників. Робітник може звільнитися з роботи написавши заяву у відділі кадрів.
9. Інформаційна система редакції газети. Повинна зберігатися інформація про видані газети. Не видані газети спочатку подаються у відділ редагування, де вони редагуються. Матеріали отримуються від журналістів і від дописувачів. Журналісти отримують зарплату, дописувачі ні. Газета після редагування подається на друк у видавництво.
10. Інформаційна система банку. Банк надає кредити фізичним і юридичним особам. Система повинна відслідковувати і інформувати банк про тих, хто не сплатив у відповідний термін місячної плати за кредит. Клієнти мають мати можливість переглянути стан свого рахунку, зняти з нього кошти, або покласти кошти на рахунок. Банк подає в суд, якщо боржник не сплачує кредиту у відповідні терміни.
11. Інформаційна система реєстрації автомобілів та дорожнього руху ДАІ. Система повинна дозволяти вести як облік транспортних засобів, так дані про порушників, ДТП, водіїв і т.д.
12. Інформаційна система аеропорту. Пасажир має мати можливість переглянути розклад рейсів і ціну квитка. Він має мати можливість замовити і оплатити квиток. В систему реєстрації аеропорту має поступати інформація про польоти і екіпаж і вона має формувати розклад польотів. Для кожного літака повинен бути список членів екіпажу. Для кожного рейсу повинна бути можливість перевірити наявність непроданих квитків і їх кількість та місця.
13. Інформаційна система автоматизованого укладання розкладу учбового закладу. Викладачі подають інформацію про предмети, які вони будуть читати. Кафедри подають інформацію про те, які аудиторії і скільки аудиторій в них є, і які групи закріплені за кафедрою. Повинна бути можливість переглянути розклад для конкретної групи. Повинна бути можливість переглянути список пар для конкретних викладачів. З вхідної інформації повинен бути сформований розклад. Повинна бути можливість корегувати розклад, а також отримати список пар (група, дисципліна, дата, час) для конкретної аудиторії.
14. Інформаційна система обліку поселень та бронювань у готелі. Клієнт готелю має мати змогу переглянути список вільних номерів і їх характеристики, теж повинен мати змогу забронювати місце на відповідне число, якщо номер вільний, та замовити список послуг. Для конкретного номеру на конкретне число повинна відображатися ціна найму. Реєстратор повинен мати змогу проглянути таблицю вільних місць на відповідне число. Також він повинен мати змогу забронювати відповідне місце, або здійснити поселення у відповідний номер. Система обслуговування (ресторан, та інші служби) повинні отримувати інформацію про те, які послуги замовлені, і в якому номері зупинився замовник.
15. Інформаційна система для автоматизації діяльності фірми-ріелтора. Для клієнта повинна бути можливість проглянути інформацію про квартири, що продаються чи здаються в оренду. Для працівника фірми повинна бути доступна контактна інформація власника, та ціна тої чи іншої квартири або її оренди. Для квартир, які здаються в оренду, повинен бути орієнтовний час, на який здається квартира. Повинна бути змога отримати квартири за ціною на них.
16. Інформаційна система для апарату поповнення рахунку. Користувач повинен мати можливість подати в апарат суму, на яку він хоче поповнити рахунок, обрати оператора зв’язку і ввести свій номер. Система поповнення рахунку повинна перерахувати гроші відповідному оператору зв’язку. Система поповнення рахунку повинна видати клієнту чек – підтвердження поповнення рахунку.
17. Інформаційна система обліку абонентів оператора мобільного зв’язку. Абонент має мати можливість здійснювати розмови, відсилати СМС, ММС, а система оплати повинна тарифікувати дзвінки і знімати з рахунку кошти. Абонент має мати змогу поповнити рахунок. Оператор забороняє здійснення вихідних дзвінків, якщо система оплати повідомляє його про те, що в абонента недостатньо грошей. Оператор повідомляє абонента про малу суму коштів на рахунку, якщо сума на рахунку менша зазначеного значення. Інформація про абонентів повинна зберігатися (зокрема номер абонента і сума на рахунку).
18. Інформаційна система підприємства постачання води. Система обліку користувачів отримує, зберігає та подає в систему оплати інформацію про споживання води. Користувачі послугою, які мають лічильник повинні самі повідомляти покази лічильника в систему обліку користувачів. Для користувачів, які не мають лічильника система обліку направляє інформацію по стандартному тарифу, відповідно до кількості проживаючих, у відділ оплати. Відділ оплати згідно з інформацією, яка подається відділом обліку, направляє рахунки на оплату користувачам з лічильником та без лічильника. Користувачі повинні здійснити оплату. Користувачі повідомляють систему обслуговування про поломки мережі водопостачання. Система обслуговування повинна усунути несправність і повідомити про це відділ обліку.
19. Інформаційна система тролейбусного парку. Служба відповідальна за встановлення графіку руху повинна отримувати інформацію від завідуючого рухомим складом про кількість тролейбусів. На основі інформації про кількість тролейбусів та інформації про маршрут (вважається що вона відома) встановити графік руху тролейбусів. Кожен водій повинен отримати графік роботи від служби відповідальної за розклад руху. Повинна бути можливість отримати графік руху і водіїв для конкретного тролейбуса в конкретний день. Служба відповідальна за ремонт повинна бути проінформована в разі поломки.
20. Інформаційна система форуму. Адміністратор керує правами користувачів форуму. Він може блокувати користувачів, які шкодять роботі форуму. Він повинен мати змогу отримати графік відвідуваності форуму його користувачами, має права для зміни і видалення повідомлень і тем. Система повинна реєструвати нових користувачів. Модератори теж мають права на редагування повідомлень і їх видалення. Звичайні користувачі можуть лише створювати повідомлення і теми, але не можуть редагувати повідомлення, крім своїх повідомлень.
21. Інформаційна система обліку користувачів провайдера Інтернету. Для доступу в Інтернет є три різних тарифних плани на трьох різних швидкостях. Система по логіну користувача повинна визначати, який тарифний план він замовив і відповідно до того провайдер надає йому доступ на замовленій швидкості. Система повинна реагувати на те, чи заплатив за послугу той чи інший користувач. Для того повинен бути перевірено чи приходили перерахування від цього користувача. Якщо він не заплатив за послугу, то доступ повинен бути заблокований.
22. Інформаційна система електронного телефонного довідника. Система повинна зберігати інформацію про адреси та телефони фізичних та юридичних осіб. Користувач повинен мати змогу отримати інформацію по запиту по адресі, по прізвищі, імені, по-батькові. Адміністратор повинен мати можливість вносити зміни, якщо міняється адреса, чи телефон тої чи іншої особи, додати новий запис до бази даних при появі нового абонента з новим номером. Система повинна надавати змогу користувачам інформувати адміністратора при знайденні ними помилки в даних системи.
23. Інформаційна система комп’ютерної системи кафедри. До системи повинні мати доступ студенти та викладачі, та інженери з різними правами (абстрагуватимемся та не будемо уточнювати), які надає адміністратор. При порушенні правил користувачами адміністратор має право їх заблокувати. Адміністратор повинен мати змогу переглянути дані про те хто, на якому комп’ютері і коли заходив у систему. Адміністратор має змогу створити новий обліковий запис для нового користувача.
24. Інформаційна система торгової фірми. Служба постачання вносить інформацію про прибуття товару і його кількість. Менеджер має можливість замовляти товар і переглядати його наявність і кількість на складі. Торговий агент повинен мати можливість доступатися до інформації про наявність і кількість товару на складі і відправляти замовлення на постачання в службу дистрибуції. Дистрибуція повинна мати можливість переглядати інформацію про замовлення, що поступили і виконувати доставку товару.
24. Інформаційна система торгової фірми. Служба постачання вносить інформацію про отриманий товар. Менеджер повинен мати можливість переглянути інформацію про наявність і кількість товару і здійснити замовлення. При здійсненні замовлення інформація про замовлення повинна поступати в бухгалтерію і бухгалтерія повинна оплатити замовлення. При відсутності коштів бухгалтерія може відмінити замовлення. Бухгалтерія повинна мати можливість переглянути неоплачені замовлення, які зробив менеджер. Товар продається безпосередньо на фірмі через касу, де оператори продають товар при цьому система відзначає відповідну кількість як продану. Оператор повинен мати змогу переглянути наявність товару і його кількість.
25. Інформаційна система підтримання мікроклімату в приміщенні. Значення температури та відносної вологості в приміщенні поступає з відповідних датчиків. Користувач системи має змогу встановити значення температури та відносної вологості, які потрібно підтримувати. Система проаналізувавши дані дає команду пристроям, які керують відносною вологістю та температурою.
26. Інформаційна система обліку використаної електроенергії. Відділ збору показів лічильників збирає і вносить інформацію про покази лічильників користувачів послугою. Система зберігає інформацію про тарифікацію світла та пільги користувачів. Відповідно до тарифів нараховується плата за електроенергію, яка направляється в фінансовий відділ. Фінансовий відділ відслідковує злісних боржників і направляє інформацію про них у відділ, який займається відключенням злісних боржників. Відділ контролю здійснює контроль за несанкціонованим підключенням до електромережі і вносить в систему дані про порушників. Ця інформація надходить у відділ, який займається відключенням, який відключає цих користувачів.
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора