Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Не вказано
Факультет:
Комп'ютерні науки
Кафедра:
Не вказано
Інформація про роботу
Рік:
2008
Тип роботи:
Інші
Предмет:
Інші
Частина тексту файла (без зображень, графіків і формул):
МІНІСТЕРСТВО ОСВІТИ ТА НАУКИ УКРАЇНИ
НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ “ЛЬВІВСЬКА ПОЛІТЕХНІКА”
Кафедра ПЗ
Діаграми дії в Rational Rose
Методичні матеріали
до лабораторної роботи № 3 з курсу:
“Основи проектування інформаційних систем”
для студентів базового напрямку
6.0804 “Комп’ютерні науки”
ЗАТВЕРДЖЕНО
на засіданні кафедри
“Програмне забезпечення”
Протокол №
від
ЛЬВІВ 2008
Діаграми дії в Rational Rose. Методичні матеріали до лабораторної роботи № 3 з курсу “Основи проектування інформаційних систем” для студентів базового напрямку 6.0804 “Комп’ю тер ні науки”.
Укладачі:
Макар В.М., доцент, к.т.н.
Муха Т.О.., асистент.
Відповідальний за випуск:
Рецензенти:
1. МЕТА РОБОТИ
Ознайомитися з основними принципами побудови діаграм дій за до по мо гою системи Rational Rose. Навчитися застосовувати на прак ти ці дії, переходи, елементи вибору та лінії синхронізації для побудови діаграм дій.
2.ОСНОВНІ ТЕОРЕТИЧНІ ВІДОМОСТІ
2.1 Постановка модельної задачі
Основним прикладом, що буде розглядатися є реєстрація курсів в університеті ESU (Eastern State University). Після того, як викладачі ESU вирішать, які курси вони будуть вести протягом семестру, служба реєстрації курсів введе інформацію в комп’ютерну систему. Потім для викладачів видрукують сумарний звіт по курсах, які вони читатимуть, а для студентів – каталог курсів.
На цьому етапі студенти заповнюють спеціальну реєстраційну форму, де вказують вибрані курси і віддають її в службу реєстрації. Зазвичай студент підписується на чотири курси, після чого інформація заноситься в комп’ютер. Після цього запускається нічна пакетна програма, яка розподіляє студентів по курсах. При виникненні конфліктної ситуації служба реєстрації уточнює дані студента. Після вдалого розподілення студенту висилається розклад для провірки. Зазвичай, процес реєстрації на курси займає близько тижня, проте в ряді випадків може бути потрібно до двох тижнів, щоб залагодити всі питання. Після цього викладачі отримують список студентів для кожного курсу, який вони будуть читати.
Постановка задачі реєстрації курсів:
На початку кожного семестру студенти можуть запросити каталог курсів, в який включений список предметів, навчання по яких пропонується в даному семестрі. Інформація про курси повинна містити прізвище викладача, назву факультету і короткий опис, який допоможе студентам зробити вибір.
Нова система дозволить студенту здійснити вибір чотирьох курсів, із тих що пропонуються в наступаючому семестрі. Крім того студенту потрібно вказати ще два варіанта на випадок якщо курс буде відмінений або переповнений. На курс не повинно бути записано більше десяти і менше трьох студентів. Курс, на який запишеться менше трьох студентів буде відмінений. Після закінчення реєстрації система реєстрації направляє інформацію в систему оплати для виставлення рахунків студентам.
Викладачі повинні мати можливість он-лайнового доступу до системи для вказання курсів, які вони будуть читати, і для перегляду списку студентів, що записалися.
2.2. Сценарії варіантів використання
Діаграма варіантів використання є найбільш загальним поданням функціональних вимог до системи. Однак моделювання варіантів використання не зводиться тільки до побудови діаграм. Для подальшого проектування системи потрібні більш конкретні деталі. Ці деталі описуються в документі, який називається сценарієм варіанту використання або потоком подій. Метою потоку подій є докладне документування процесу взаємодії актора з системою, що реалізується в рамках заданого випадку використання. У потоці подій мають бути описані всі дії, необхідні для виконання запитів актора. Хоча потік подій і описується докладно, він також не повинен залежати від реалізації. Основна мета полягає в описі що буде робити система, а не як вона це буде робити. Зазвичай опис потоку подій складається з таких розділів:
Короткий опис. Кожний випадок використання повинен мати корот кий опис його суті та призначення. Наприклад, варіант використання “Ство рен ня каталогу курсів” може мати такий опис: варіант використання “Ство рен ня каталогу курсів” дозволяє сформувати повний список навчальних курсів, які будуть читатися в наступному семестрі, призначити для кожного з них викладачів, а також забезпечити доступ до нього для студентів з метою їх реєстрації.
Передумови (pre-conditions). Передумови випадку використання - це такі умови, які повинні бути виконані, перш ніж випадок використання почне виконуватися сам. Наприклад, такою умовою може бути виконання іншого варіанту використання або наявність у користувача прав доступу, необхідних для початку роботи. Не всі варіанти використання мають передумови. Раніше згадувалося, що діаграми варіантів використання не повинні відображати порядок їх виконання. Таку інформацію можна описати за допомогою передумов. Наприклад, передумовами варіанта використання “Ство рен ня каталогу курсів” є виконання варіантів використання “Збереження інфор мації про курси” та “Збереження інформації про викладачів”.
Основний та альтернативний потоки подій. Конкретні деталі варіан тів використання описуються в основному та в альтернативних потоках по дій. Потік подій поетапно описує, що має відбуватися під час виконання зак ла деної у варіант використання функціональності. В потоці подій описується те, що буде робити система, а не як вона буде робити це, причому описується все це з точки зору користувача. Основний потік подій описує нормальний хід подій (за відсутності помилок), і при наявності декількох можливих ва ріан тів перебігу подій може розгалужуватися на підпорядковані потоки (subflows). Альтернативні потоки описують від хи лення від нормального перебігу подій (помилкові ситуації) та їх обробку. Наприклад, потоки подій для випадку використання “Ство рен ня каталогу курсів” можуть мати такий вигляд:
Основний потік подій
Варіант використання починається реєстратором з формування навчального плану для конкретного семестру.
Викладачі вибирають навчальні курси, які вони будуть читати, включаючи тип занять.
Реєстратор переглядає і затверджує вибрані викладчами курси.
Реєстратор формує каталог курсів, який містить інформацію про назви курсів, типи занять курсу, розподіл годин курсу, види контролю, перелік тем курсу, викладачів, які читатимуть курс.
Реєстратор зберігає сформований каталог на файл-сервері.
Реєстратор розсилає сформований каталог студентам.
Реєстратор відкриває реєстрацію студентів на курси.
Варіант використання завершується.
Альтернативний потік подій 1. Залишилися курси не вибрані викладачами.
4.1.Система інформує реєстратора, що залишилися курси для яких відсутні викладачі.
4.2.Варіант використання завершується.
Альтернативний потік подій 2. Курс вибраний декількома викладачами.
3.1.Система повідомляє реєстратора про наявність курсів, для вик ла дан ня яких записалося декілька викладачів.
3.2.Реєстратор розсилає відповідним викладачам відповідне повідом лен ня.
3.3.Варіант використання завершується.
Деякі рекомендації, яких слід дотримуватися при написанні основного потоку подій: в кожному пункті слід явно вказувати, хто виконує дію – актор чи система; не показуйте незначні дії; не описуйте дії в процесі роботи з інтерфейсом користувача; не описуйте помилкові ситуації.
Постумови (post-conditions). Постумовами називаються такі умови, які завжди повинні бути виконані після завершення варіанту викорис тан ня. Як і для передумов, за допомогою постумов можна вводити інфор мацію про порядок виконання варіантів використання системи. Якщо, наприклад, після одного з варіантів використання повинен завжди виконуватися інший, це можна описати як постумову. Такі постумови є не у кожного варіанту використання.
Розширення (extensions). Цей пункт присутній в описі сценарію випадку використння, якщо в основному потоці подій зустрічаються часткові випадки, тобто ситуації, які рідко зустрічаються.
2.3. Діаграми дій та її елементи
Діаграми дій відображають динаміку проекту і являються схемами по то ків управління в системі від дії до дії, а також паралельних дій і альтер на тивних потоків. В конкретній точці життєвого циклу діаграми дій можуть представляти потоки між функціями системи або всередині окремої функції. На різних етапах життєвого циклу вони створюються для відображення послідовності виконання операцій.
Діаграми дій можна також застосовувати для опису потоків подій у варіантах використання. За допомогою текстового опису можна досить детально розказати про потік подій. Проте, досить часто в складних і зап лу та них потоках з багатьма альтернативними шляхами розвитку подій може бути дуже важко вловити та зрозуміти логіку подій. Діаграми дій надають ту ж інформацію, що і текстовий опис потоку подій, але в наочній графічній формі.
Основним елементом діаграми є дія (activity), під якою розуміють виконання визначеної поведінки в потоці управління системи. Дією може бути деяка задача з потоку подій, яку потрібно виконати вручну або автоматизованим способом, операція класу і т.д. Дія зображається у вигляді заокругленого прямокутника з текстовим описом.
Будь-яка діаграма дій повинна мати початкову точку, яка визначає початок потоку подій. Початковий стан зображається у вигляді зама льо ва но го круга. Кінцева точка на діаграмі дій не є обов’язковою, вона позначається у вигляді замальованого круга обведеного додатковим колом. Зазвичай в потоці декілька кінцевих станів – для кожного альтернативного напрямку.
Переходи, які зображаються у вигляді стрілок, використовуються для зображення шляху потоку управління від дії до дії. Зазвичай, вони (переходи) здійснюються після закінчення дії.
При моделюванні керуючих потоків системи часто необхідно показати місця їх розділення на основі вибору за певною умовою. Переходи із елемента вибору містять обмежуючі умови, які визначають, який напрямок переходу буде обраний. Елементи вибору і умови дозволяють задавати альтернативні потоки подій. Елементи вибору зображаються у вигляді ромба.
В потоці досить часто існують дії, які потрібно виконувати паралельно. Лінія синхронізації (synchronization bar) дозволяє вказати на необхідність їх одночасного виконання, а також забезпечує єдине виконання дій в потоці (тобто вказує на необхідність завершення певних дій для переходу до наступної). Таким чином лінії синхронізації можуть мати декілька вхідних ліній переходів і одну вихідну, або одну вхідну і багато вихідних.
Секції ділять діаграми дій на декілька ділянок. Це потрібно для того, щоб показати, хто відповідає за виконання дій на кожній ділянці, а також для аналізу потоків подій в різних варіантах використання.
2.4. Діаграми дій в Rational Rose
Діаграми дій в пакеті Rational Rose створюються наступним чином:
Клікніть правою клавішею миші по розділі представлення випадків використання (Use Case View) у списку оглядача (Browser).
У контекстно залежному меню, що появилося, обираємо команду New→Activity Diagram. У список буде добавлено нова діаграма з ім’ям New Diagram.
Введіть назву діаграми.
Для того, щоб відкрити діаграму, клікніть двічі по ній мишею.
Рис. 2.1. Нова діаграма дій з назвою «Створення каталогу»
Для створення дії в програмі Rational Rose необхідно зробити наступне:
Натисніть мишею на кнопку Activity на панелі інструментів.
Рис. 2.2. Розташування кнопки Activity на панелі інструментів
Клікніть по діаграмі дій для того, щоб розмістити елемент, що зображає дію, на діаграму.
Введіть ім’я нової дії.
Рис. 2.3. Дії
Для того, щоб додати до діаграми дій переходи в пакеті Rational Rose потрібно виконати наступні дії:
Клікнути по кнопці State Transition на панелі інструментів.
Рис. 2.4. Кнопка State Transition
Клікнути по початковій дії на діаграмі і перемістити стрілку переходу на дію, яка відбувається після неї.
Рис. 2.5. Переходи
Для створення елементів вибору в програмі Rational Rose потрібно виконати наступні дії:
Клікніть по кнопці Decision на панелі інструментів.
Рис. 2.6. Елемент вибору
Клікніть по діаграмі дій для того, щоб помістити на неї елемент вибору.
Введіть ім’я нового елементу.
Клікніть по кнопці State Transition на панелі інструментів.
Клікніть на попередній дії діаграми і перемістіть стрілку переходу на елемент вибору.
Рис. 2.7. Елемент вибору, разом з переходом
Послідовність створення умовних переходів в програмі Rational Rose:
Натисніть кнопку State Transition на панелі інструментів.
Клікніть по елементі вибору на діаграмі і перемістіть стрілку переходу на наступну дію.
Двічі клікніть по стрілці переходу для того, щоб відкрити діалогове вікно Specification.
Клікніть по закладці Detail.
В полі вводу Guard Condition введіть умову переходу.
Рис. 2.8. Вікно Specification
Клікніть по кнопці OK для того, щоб закрити діалогове вікно.
Рис. 2.9. Діаграма з умовою переходу
Для того, щоб отримати прямолінійні лінії переходів у програмі Rational Rose потрібно виконати наступні дії:
Виберіть лінії переходів, які ви хочете зробити прямолінійними (для вибору декількох ліній одразу можна використовувати клавішу Shift).
Виберіть команду меню Format→Style→RectiLinear.
Розмістіть лінії так як вам потрібно на діаграмі дій, перетягуючи їх за допомогою миші.
Для створення лінії синхронізації потрібно:
Натиснути на кнопку Horizontal Synchronization або Vertical Synchronization на панелі інструментів.
Клікнути по діаграмі дій для того, щоб розмістити на ній лінію синхронізації.
Клікнути на кнопку State Transition на панелі інструментів і добавити необхідні вхідні і вихідні лінії переходів до лінії синхронізації.
Рис. 2.10. Лінії синхронізації
Для створення секцій в Rational Rose потрібно:
Клікніть по кнопці Swimlane на панелі інструментів.
клікніть на діаграмі дій, щоб створити на ній нову секцію з назвою New Swimlane.
Клікніть двічі по назві нової секції, щоб відкрити діалогове вікно Specification.
Введіть потрібну назву секції в полі для вводу Name.
Клікніть по кнопці OK, щоб закрити діалогове вікно.
Для зміни розмірів секції перемістіть її границю за допомогою миші.
Перемістіть всі необхідні дії і переходи на діаграмі в нову секцію, де зразу зможете їх створювати.
Рис. 2.11. Секції
Послідовність створення і додавання початкового та кінцевих станів на діаграму дій така:
Клікніть по кнопці Start State або End State на панелі інструментів.
Клікніть на діаграмі дій, для того, щоб помістити на неї символ початкового або кінцевого стану.
Якщо ви додали початковий стан, клікніть по кнопці State Transition на панелі інструментів, а після цього на символ початкового стану і здійсніть перехід до першої дії в потоці.
Якщо ви додали кінцевий стан, клікніть по кнопці State Transition на панелі інструментів, а після того на попередній дії і здійсніть перехід до символу кінцевого стану на діаграмі.
Рис. 2.12. Початковий і кінцевий стани
3.КОНТРОЛЬНІ ЗАПИТАННЯ
Для чого потрібні сценарії варіантів використання?
З яких розділів складається опис потоку подій варіантів використання?
Для чого використовуються діаграми дій?
З яких елементів може складатися діаграма дій?
Що таке лінія синхронізації? Які види ліній синхронізації є і для чого вони використовуються?
Як вказати на діаграмі дій відповідального за виконання дії?
Як створити умовні переходи в Rational Rose?
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. Інформаційна система торгової фірми. Служба постачання вносить інформацію про прибуття товару і його кількість. Менеджер має можливість замовляти товар і переглядати його наявність і кількість на складі. Торговий агент повинен мати можливість доступатися до інформації про наявність і кількість товару на складі і відправляти замовлення на постачання в службу дистрибуції. Дистрибуція повинна мати можливість переглядати інформацію про замовлення, що поступили і виконувати доставку товару.
25. Інформаційна система підтримання мікроклімату в приміщенні. Значення температури та відносної вологості в приміщенні поступає з відповідних датчиків. Користувач системи має змогу встановити значення температури та відносної вологості, які потрібно підтримувати. Система проаналізувавши дані дає команду пристроям, які керують відносною вологістю та температурою.
26. Інформаційна система обліку використаної електроенергії. Відділ збору показів лічильників збирає і вносить інформацію про покази лічильників користувачів послугою. Система зберігає інформацію про тарифікацію світла та пільги користувачів. Відповідно до тарифів нараховується плата за електроенергію, яка направляється в фінансовий відділ. Фінансовий відділ відслідковує злісних боржників і направляє інформацію про них у відділ, який займається відключенням злісних боржників. Відділ контролю здійснює контроль за несанкціонованим підключенням до електромережі і вносить в систему дані про порушників. Ця інформація надходить у відділ, який займається відключенням, який відключає цих користувачів.
27. Інформаційна система торгової фірми. Служба постачання вносить інформацію про отриманий товар. Менеджер повинен мати можливість переглянути інформацію про наявність і кількість товару і здійснити замовлення. При здійсненні замовлення інформація про замовлення повинна поступати в бухгалтерію і бухгалтерія повинна оплатити замовлення. При відсутності коштів бухгалтерія може відмінити замовлення. Бухгалтерія повинна мати можливість переглянути неоплачені замовлення, які зробив менеджер. Товар продається безпосередньо на фірмі через касу, де оператори продають товар при цьому система відзначає відповідну кількість як продану. Оператор повинен мати змогу переглянути наявність товару і його кількість.
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора