Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Не вказано
Факультет:
Комп'ютерні науки
Кафедра:
Не вказано
Інформація про роботу
Рік:
2008
Тип роботи:
Інші
Предмет:
Інші
Частина тексту файла (без зображень, графіків і формул):
МІНІСТЕРСТВО ОСВІТИ ТА НАУКИ УКРАЇНИ
НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ “ЛЬВІВСЬКА ПОЛІТЕХНІКА”
Кафедра ПЗ
Діаграма станів в Rational Rose
Методичні матеріали
до лабораторної роботи № 5 з курсу:
“Основи проектування інформаційних систем”
для студентів базового напрямку
6.0804 “Комп’ютерні науки”
ЗАТВЕРДЖЕНО
на засіданні кафедри
“Програмне забезпечення”
Протокол №
від
ЛЬВІВ 2008 Діаграма станів в Rational Rose. Методичні матеріали до лабораторної роботи № 5 з курсу: “ Основи проектування інформаційних систем ” для студентів базового напрямку 6.0804 “Комп’ю тер ні науки”.
Укладачі:
Макар В.М., доцент, к.т.н.
Муха Т.О., асистент.
Відповідальний за випуск:
Рецензенти:
МЕТА РОБОТИ
Ознайомитися з основними принципами моделювання динамічної поведінки об’єктів. Ознайомитися з поняттями: об’єкт, стан, переходи між станами, дізнатися про особливі стани об’єкту. Ознайомитися з принципами і прийомами побудови діаграми станів за допомогою програмного засобу Rational Rose. Навчитися застосовувати на практиці знання таких понять як клас, об’єкт, пакет, стереотип класу для побудови діаграм класів.
ОСНОВНІ ТЕОРЕТИЧНІ ВІДОМОСТІ
Основні поняття і постановка модельної задачі
Модельна задача
Основним прикладом, що буде розглядатися є реєстрація курсів в університеті ESU (Eastern State University).
Після того, як викладачі ESU вирішать, які курси вони будуть вести протягом семестру, служба реєстрації курсів введе інформацію в комп’ютерну систему. Потім для викладачів видрукують сумарний звіт по курсах, які вони читатимуть, а для студентів – каталог курсів.
На цьому етапі студенти заповнюють спеціальну реєстраційну форму, де вказують вибрані курси і віддають її в службу реєстрації. Зазвичай студент підписується на чотири курси, після чого інформація заноситься в комп’ютер. Після цього запускається нічна пакетна програма, яка розподіляє студентів по курсах. При виникненні конфліктної ситуації служба реєстрації уточнює дані студента. Після вдалого розподілення студенту висилається розклад для провірки. Зазвичай, процес реєстрації на курси займає близько тижня, проте в ряді випадків може бути потрібно до двох тижнів, щоб залагодити всі питання. Після цього викладачі отримують список студентів для кожного курсу, який вони будуть читати.
Постановка задачі реєстрації курсів:
На початку кожного семестру студенти можуть запросити каталог курсів, в який включений список предметів, навчання по яких пропонується в даному семестрі. Інформація про курси повинна містити прізвище викладача, назву факультету і короткий опис, який допоможе студентам зробити вибір.
Нова система дозволить студенту здійснити вибір чотирьох курсів, із тих що пропонуються в наступаючому семестрі. Крім того студенту потрібно вказати ще два варіанта на випадок якщо курс буде відмінений або переповнений. На курс не повинно бути записано більше десяти і менше трьох студентів. Курс, на який запишеться менше трьох студентів буде відмінений. Після закінчення реєстрації система реєстрації направляє інформацію в систему оплати для виставлення рахунків студентам.
Викладачі повинні мати можливість он-лайнового доступу до системи для вказання курсів, які вони будуть читати, і для перегляду списку студентів, що записалися.
В кожному семестрі виділяється визначений час, протягом якого студенти можуть міняти свій розклад і отримувати доступ до системи для додавання і видалення вибраних курсів.
Моделювання динамічної поведінки
Випадки використання застосовуються для опису поведінки системи, тобто взаємодії об’єктів в ній. Інколи потрібно розглянути поведінку всередині самого об’єкту. Діаграма станів (statechart diagram) показує положення одиночного об’єкту, події або повідомлення, котрі спричиняють перехід з одного стану в інший, і дії, які є результатом зміни стану.
Діаграму станів не потрібно створювати для кожного класу в системі, тільки для класів з «особливою» динамічною поведінкою. Для визначення динамічних об’єктів в системі, тобто об’єктів, які відсилають і отримують велику кількість повідомлень, можуть використовуватися діаграми взаємодій. Діаграма станів також корисна для вивчення поведінки класу-агрегату і керуючого класу.
Місце для рисунка
Потрібно уважно підходити до питань аналізу і зосередитися на тому, що являє собою проблема, а не на тому, як вона буде вирішуватися.
Для створення діаграми станів в програмі Rational Rose:
Клікніть правою кнопкою миші по класові в списку оглядача.
У контекстно-залежному меню, що появилося оберіть команду New → Statechart Diagram (Створити → Діаграму станів). У список оглядача буде додано діаграма New Diagram.
Введіть її назву.
Щоб відкрити діаграму, клікніть по значку «+» зліва від імені підкласу у вікні оглядача, потім по «+» ліворуч від пункту State/Activity Model (Модель станів і дій), а потім двічі по діаграмі станів.
Діаграма станів в списку оглядача для класу навчальний курс (Course Offering) показана на рис. 1.
Рис. 1. Діаграма станів в оглядачі
Стани
Стан (state) – це деяке положення в житті об’єкта, при якому він задовольняє певній умові, виконує деяку дію або очікує події. Стан об’єкту можна описати за допомогою значень одного або декількох атрибутів класу. Наприклад, об’єкт навчальний курс може бути відкритим (доступний для запису студентів) або закритий (вже записана на курс максимальна кількість студентів). Стан залежить від кількості студентів, які прикріплені до об’єкту навчальний курс. Крім того, він (стан) може визначатися наявністю зв’язку із іншим об’єктом. Актор викладач може читати лекції або бути у відпустці. Це залежить від наявності зв’язку із об’єктом навчальний курс. При аналізі стану об’єкту можна перевірити потужність, яка була вибрана, для відношення з іншим об’єктом. Тобто, якщо знаходження у відповідному стані залежить від наявності зв’язку з іншим об’єктом, то потужність відношення, що відноситься до зв’язаного класу, повинна включати нульове значення (іншими словами, відношення необов’язкове). Таким чином, стани об’єкта визначаються при вивченні атрибутів і зв’язків, вказаних для нього.
В мові UML стан зображується у вигляді прямокутника з заокругленими кутами – див. рис. 2.
Діаграма станів включає всі повідомлення, які об’єкт отримує і відсилає. Сценарій – це одиничний прохід по діаграмі станів. Інтервал між двома повідомленнями, які відсилає об’єкт, зазвичай являється станом. Таким чином, для визначення станів об’єкту потрібно вивчити діаграму послідовності дій (подивіться на інтервали між лініями повідомлень, які отримує об’єкт). Якщо для кожної функції в системі реєстрації навчальних курсів були створені діаграми послідовності дій, то з їх допомогою можна виявити, що об’єкти класу навчальний курс можуть бути в одному із наступних станів: ініціалізація (створений для реєстрації, але студенти не закріплені), відкритий (доступний для запису студентів), закритий (на курс записана максимальна кількість студентів), відмінений (більше н читається).
Послідовність створення станів в програмі Rational Rose:
Клікніть по кнопці State (Стан) на панелі інструментів.
Клікніть по діаграмі, для того щоби помістити на неї новий стан.
Введіть його назву.
Стани класу навчальний курс зображені на рис. 3.
Рис. 3. Стани
Переходи між станами
Переходи між станами (state transitions) є змінами вихідного стану наступним (який, зокрема, може бути тим самим, що й попередній). Перехід може супроводжуватись деякою дією.
Існує два способи виходу із стану – автоматичний і неавтоматичний. Автоматична зміна стану відбувається, коли дія вихідного стану буде закінчена – з переходом не пов’язана жодна подія. Неавтоматичний перехід між станами викликається певною подією (від іншого об’єкту, або із зовнішнього середовища). Вважається, що обидва типи переходів виконуються за нульовий час і не можуть бути перервані. Перехід між станами зображується у вигляді стрілки, що направлена від вихідного стану до наступного.
Для створення переходів між станами в програмі Rational Rose:
Клікніть по кнопці State Transition (перехід) на панелі інструментів.
Клікніть по вихідному стані діаграми.
Проведіть лінію переходу до наступного стану.
Якщо це потрібно, то введіть назву нового переходу.
Переходи між станами показані на рис. 4.
Рис. 4. Переходи між станами
Особливі стани
Існує два особливих стани, що присутні на діаграмі станів – початковий (start state) і кінцевий (stop state).
Кожна діаграма повинна мати один і тільки один початковий стан, так як об’єкт може знаходитися в цілісному стані зразу після створення. В мові UML початковий стан зображається у вигляді маленького зафарбованого круга (див. рис. 5).
Рис. 5. Початковий і кінцевий стани відповідно
Об’єкт може мати декілька кінцевих станів, які зображуються у вигляді зафарбованого круга, який обведений додатковим колом (див. рис. 9.5).
Для того, щоб створити початковий стан в програмі Rational Rose:
Клікніть по кнопці Start (Початковий стан) на панелі інструментів.
Клікніть по діаграмі, щоб розмістити на ній значок вхідного стану.
Натисніть кнопку State Transition на панелі інструментів.
Клікніть по початковому стану і проведіть лінію переходу до наступного стану.
Початковий стан на діаграмі станів показано на рис. 6.
Рис. 6. Початковий стан
Для створення кінцевого стану в програмі Rational Rose виконайте наступні дії:
Натисніть на кнопку Stop (Кінцевий стан) на панелі інструментів.
Клікніть по діаграмі, щоб розмістити на ній значок кінцевого стану.
Клікніть по кнопці State Transition на панелі інструментів.
Клікніть по одному із станів на діаграмі і проведіть лінію переходу до кінцевого стану.
Кінцевий стан на діаграмі станів показано на рис. 7.
Рис. 7. Кінцевий стан
Параметри переходів
З переходом між станами може бути пов’язана умова (guard condition) і/або визначена дія (action). Перехід може також бути викликаний подією (event). Дія – це поведінка, яка проявляється при виникненні переходу. Подія – повідомлення, яке відсилається іншому об’єкту системи. Умова – логічний вираз значень атрибутів, який допускає перехід тільки тоді, коли він істинний. І дія, і перевірка умови представляють собою поведінку об’єкта і, зазвичай, реалізуються у вигляді операцій. Часто такі операції є скритими (private), тобто використовуються тільки самим об’єктом. В мові UML параметри переходу зображуються так, як показано на рис. 8.
Рис. 8. Нотація мови UML для параметрів переходів
Рис. 9. Параметри переходів
Послідовність додавання параметрів переходу в програмі Rational Rose:
Клікніть правою клавішею миші по стрілці переходу на діаграмі.
В контекстно-залежному меню, яке появилося, виберіть команду Specification (Параметри), щоб викликати діалогове вікно параметрів переходу.
Виберіть закладку Detail (Детально).
Вкажіть дію, умову і подію для переходу.
Натисніть на кнопку OK, щоб закрити діалогове вікно налаштування параметрів.
Параметри переходу на діаграмі станів показані на рис. 9.
Параметри станів
Дії, що супроводжують всеможливі переходи в визначений стан можна розглядати як вхідні дії (entry action) для цього стану. І навпаки, дії, що супроводжують переходи із даного стану, є для нього вихідними (exit action). Поведінка, що виникає всередині стану, називається діяльністю (activity). Діяльність починається при вході у стан і закінчується або переривається при переході з нього. Поведінка може бути простою дією або подією, що посилається іншому об’єкту.
Як і у випадку з діями і перевірками умов для переходу, поведінка всередині стану зазвичай реалізується у вигляді операцій. У мові UML параметри станів зображуються так, як показано на рис. 10.
Рис. 10. Нотація мови UML для параметрів станів
Визначення вхідних, вихідних і внутрішніх дій для стану в програмі Rational Rose передбачає виконання наступних кроків:
Натисніть правою кнопкою миші на зображенні стану на діаграмі.
У контекстно-залежному меню, що появилося, оберіть команду Open Specification (Параметри), для того щоб викликати діалогове вікно параметрів стану.
Виберіть закладку Actions (Дії).
Клікніть правою клавішею миші по списку Actions (Дії).
В контекстно-залежному меню, яке з’явилося, виберіть команду Insert (Додати). В список буде додана нова дія.
Двічі клікніть по новій дії в списку для того, щоб відкрити діалогове вікно Action Specification (Параметри дії).
Вкажіть момент виконання дії: on entry (при вході), on exit (при виході), on event (при певній події).
Введіть опис дії або події.
Вкажіть тип дії: auction (дія) або send event (виклик події).
Якщо потрібно, то введіть назву дії або події.
Клікніть по кнопці OK, для того щоб закрити діалогове вікно Action Specification.
Клікніть по кнопці OK, для того щоб закрити діалогове вікно State Specification.
Параметри станів на діаграмі станів показані на рис. 11.
Рис. 11. Параметри станів
3.КОНТРОЛЬНІ ЗАПИТАННЯ
Що показує діаграма станів?
Що являє собою поняття «стан»?
Для яких класів потрібно створювати діаграму станів?
Що таке перехід між станами?
Які є особливі стани?
Охарактеризуйте поняття дія, умова, подія?
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%
Оголошення від адміністратора