Мы поможем в написании ваших работ!



ЗНАЕТЕ ЛИ ВЫ?

Варіанти використання системи

Поиск

UML (уніфікована мова моделювання) - мова графічного опису для об'єктного моделювання в області розробки програмного забезпечення, моделювання бізнес-процесів, системного проектування та відображення організаційних структур.

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

UML дозволяє також розробникам програмного забезпечення досягти угоди в графічних позначеннях для представлення загальних понять (таких як клас, компонент, узагальнення, агрегація і поведінка) і більше сконцентруватися на проектуванні та архітектурі.

Переваги UML:

· UML об'єктно-орієнтований, в результаті чого методи опису результатів аналізу і проектування семантично близькі до методів програмування на сучасних об'єктно-орієнтованих мовах;

· UML дозволяє описати систему практично з усіх можливих точок зору і різні аспекти поведінки системи;

· Діаграми UML порівняно прості для читання після досить швидкого ознайомлення з його синтаксисом;

· UML розширює і дозволяє вводити власні текстові та графічні стереотипи, що сприяє його застосування не тільки в сфері програмної інженерії;

· UML набув широкого поширення і динамічно розвивається.

Критика:

Незважаючи на те, що UML - досить широко поширений і використовуваний стандарт, його часто критикують через наступних недоліків:

· Надмірність мови. UML часто критикується як невиправдано великий і складний. Він включає багато надлишкових або практично невикористовуваних діаграм і конструкцій.

· Неточна семантика. Так як UML визначено комбінацією себе (абстрактний синтаксис), OCL (мовою опису обмежень - формальної перевірки правильності) і англійської (детальна семантика), то він позбавлений скутості, властивою мовам, точно певним техніками формального опису. У деяких випадках абстрактний синтаксис UML, OCL і англійська суперечать один одному, в інших випадках вони неповні. Неточність опису самого UML однаково відбивається на користувачів і постачальників інструментів, приводячи до несумісності інструментів через унікальне трактування специфікацій.

· Проблеми при вивченні і впровадженні. Вищеописані проблеми роблять проблематичним вивчення та впровадження UML, особливо коли керівництво насильно змушує використовувати UML інженерів за відсутності у них попередніх навичок.

· Тільки код відображає код. Ще одна думка - що важливі робочі системи, а не красиві моделі. Відповідно з цією думкою, існує потреба в кращому способі написання ПЗ; UML цінується при підходах, які компілюють моделі для генерування вихідного або здійсненного коду.

· Кумулятивна навантаження / Неузгодженість навантаження. Неузгодженість навантаження - термін з теорії системного аналізу для позначення нездатності входу однієї системи сприйняти вихід іншої. Як у будь-якій системі позначень UML може представити одні системи більш коротко і ефективно, ніж інші. Таким чином, розробник схиляється до рішень, які більш комфортно підходять до переплетення сильних сторін UML і мов програмування. Проблема стає більш очевидною, якщо мова розробки не дотримується принципів ортодоксальної об'єктно-орієнтованої доктрини (не стараються відповідати традиційним принципам ООП).

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

Діаграма використання в UML - діаграма, що відображає відносини між акторами і прецедентами і є складовою частиною моделі прецедентів, що дозволяє описати систему на концептуальному рівні.

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

Основне призначення діаграми - опис функціональності і поведінки, що дозволяє замовнику, кінцевому користувачеві і розробнику спільно обговорювати проектовану або існуючу систему.

При моделюванні системи за допомогою діаграми використання системний аналітик прагне:

· чітко відокремити систему від її оточення;

· визначити дійових осіб (акторів), їх взаємодія з системою і очікуваний функціонал системи;

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

Для відображення моделі використання на діаграмі використовуються:

· рамки системи (англ. system boundary) - прямокутник з назвою у верхній частині і еліпсами (прецедентами) всередині. Часто може бути опущений без втрати корисної інформації,

· актор (англ. actor) - стилізований чоловічок, що позначає набір ролей користувача (розуміється в широкому сенсі: людина, зовнішня сутність, клас, інша система), що взаємодіє з деякою сутністю (системою, підсистемою, класом). Актори не можуть бути пов'язані один з одним (за винятком відносин узагальнення / успадкування),

· прецедент - еліпс з написом, що позначає виконувані системою дії (можуть включати можливі варіанти), що призводять до спостережуваних акторами результатами. Напис може бути ім'ям або описом (з точки зору акторів) того, «що» робить система (а не «як»). Ім'я прецеденту пов'язано з неперервним (атомарним) сценарієм - конкретної послідовністю дій, що ілюструє поведінку. В ході сценарію актори обмінюються з системою повідомленнями. Сценарій може бути приведений на діаграмі використання у вигляді UML-коментаря. З одним прецедентом може бути пов'язано кілька різних сценаріїв.

При роботі з варіантами використання важливо пам'ятати декілька простих правил:

· кожен прецедент відноситься як мінімум до однієї дійової особи;

· кожен прецедент має ініціатора;

· кожен прецедент призводить до відповідного результату.

Для реалізації діаграми використання в проекті медичного діагностичного центру я визначаю користувачів системи(клієнт, поставщик, бухгалтер), їх права допуску до певних даних(інформація про ліки) та допуск до певних функціональностей системи(друк, пошук, введення / виведення і редагування даних про ліки). Діаграма використання системи наведено в додатку В(Рис. 35), діаграма послідовності системи наведено в додатку В(Рис. 36), діаграма класів системи наведено в додатку В(Рис. 37), кооперативна діаграма системи наведено в додатку В(Рис. 38).

 


ДЕТАЛЬНЕ ПРОЕКТУВАННЯ

Проектування інтерфейсу

Поняття інтерфейсу

Графічний інтерфейс користувача (ГІП) (англ. Graphical user interface, GUI) - різновид призначеного для користувача інтерфейсу, в якому елементи інтерфейсу (меню, кнопки, значки, списки і т. п.), представлені користувачеві на дисплеї, виконані у вигляді графічних зображень.

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

Графічний інтерфейс користувача є частиною призначеного для користувача інтерфейсу і визначає взаємодію з користувачем на рівні візуалізованою інформації.

Можна виділити наступні види GUI:

· Простий: типові екранні форми і стандартні елементи інтерфейсу, що забезпечуються самою підсистемою GUI;

· Істинно-графічний, двовимірний: нестандартні елементи інтерфейсу і оригінальні метафори, реалізовані власними засобами програми або сторонньої бібліотекою;

· Тривимірний.

Однією з вимог до хорошого графічного інтерфейсу програмної системи є концепція «роби те, що я маю на увазі» або DWIM (англ. Do What I Mean). DWIM вимагає, щоб система працювала передбачувано, щоб користувач заздалегідь інтуїтивно розумів, яку дію виконає програма після отримання його команди.

Переваги:

· Графічний інтерфейс є «дружнім» для користувачів, які почали знайомство з комп'ютером з графічного інтерфейсу.

· У програмах обробки графіки він, найчастіше, є єдино можливим.

Недоліки:

· Більше споживання пам'яті в порівнянні з текстовим інтерфейсом

· Складніше організувати віддалену роботу

· Неможливість автоматизації, якщо вона не була закладена автором програми

· Графічний інтерфейс не є «дружнім» для користувачів, які почали знайомство з комп'ютером з інтерфейсу командного рядка.

· Графічний інтерфейс складніше у використанні для незрячих людей.

Інтерфейс користувача комп'ютерної програми включає:

· Засоби відображення інформації, що відображається інформацію, формати і коди;

· Командні режими, мова «користувач - інтерфейс»;

· Пристрої і технології введення даних;

· Діалоги, взаємодія і транзакції між користувачем і комп'ютером, зворотний зв'язок з користувачем;

· Підтримку прийняття рішень у конкретній предметній області;

· Порядок використання програми і документацію на неї.

Інтерфейс часто розуміють тільки як зовнішній вигляд програми. Однак на справді користувач сприймає через нього всю програму в цілому, а значить, таке розуміння є занадто вузьким.

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

До цих елементів відносяться:

· Набір завдань користувача, які він вирішує за допомогою системи;

· Елементи управління системою;

· Навігація між блоками системи;

· Візуальний (і не тільки) дизайн екранів програми;

· Засоби відображення інформації, яка відображається інформація та формати;

· Пристрою і технології введення даних;

· Діалоги, взаємодія і транзакції між користувачем і комп'ютером;

· Зворотний зв'язок з користувачем;

· Підтримка прийняття рішень в конкретній предметній області;

· Порядок використання програми і документація на неї.

Основні вимоги до інтерфейсу користувача:

· Мінімальність витрат ресурсів з боку користувача. Людина-оператор повинен виконувати тільки необхідну роботу, повинні виключатися повторення одних і тих же дій, що виникають, наприклад, при введенні даних. Повинно бути виключено дублювання роботи;

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

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

· Вікна програми повинні бути інтуїтивно зрозумілими для виконання поставленої користувачем завдання щодо проектованої системи.

 

Дослідження користувача

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

В основі визначення інтерфейсу користувача та кількості форм реалізації визначається по максимально дозволеному простору оперативної пам’яті та кількості пропонованих завдань до розробника. Враховуються соціальні характеристики користувача та його навики.

Таблиця 3.1.2.1 – Дослідження користувача

Користувачі Лікарі Старша медсестра
Соціальні характеристики Чоловіки Жінки Україномовні Середній рівень володіння ПК Жінка Україномовні Середній рівень володіння ПК
Мотиваційне цільове середовище Виробнича необхідність Престиж Мотивація до навчання висока Виробнича необхідність Зручність Мотивація до навчання висока
Навики і уміння Отримали навички(досвід) роботи з програмою
Вимоги до ПЗ ІС Час реакції ПО ІС, допустима для очікування Відсутність жорстких обмежень за часом Забезпечення поточною інформацією за даними в «Лікарі», «Препарати», «Клієнти», «Діагнози», «Квитанції» Можливість формування нових даних в «Лікарі», «Препарати», «Клієнти», «Діагнози», «Квитанції» Можливість друку даних із таблиць «Лікарі», «Препарати», «Клієнти», «Діагнози», «Квитанції»  
Задачі користувача Перегляд введення та зміна даних таблиць «Лікарі», «Препарати», «Клієнти», «Діагнози», «Квитанції» Перегляд, введення та зміна даних таблиць «Лікарі», «Препарати», «Клієнти», «Діагнози», «Квитанції» Фільтрування даних Друк квитанції  
Робоче середовище Стандартизовані ПК на ОС Windows XP/Vista/7/8/8.1/10

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

Таблиця – 3.1.2.2 – Характеристика користувача програми

Характеристика Градації
Рівень знань і досвід
Комп’ютерна грамотність Середній. Користувач повинен володіти елементарними навиками користування комп’ютером
Системний досвід Середній
Досвід роботи з подібними програмами Середній
Освіта Закінчена вища освіта
Рівень читання 9 років в школі
Машинопис 100 слів за хвилину
Фізичні характеристики користувача
Вік Молодий, середнього віку, літній
Стать Чоловіча, жіноча
Розвиненість рук Лівша, правша, володіє однаково обома руками
Характеристики завдань і роботи користувача
Спосіб використання цієї програми Ознайомлення з інформацією, яка в ній знаходиться, додавання, видалення, здійснювати пошук та фільтрацію даних, обчислювати суму за день та друкувати звіти

 



Поделиться:


Последнее изменение этой страницы: 2016-08-16; просмотров: 2021; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.145.66.104 (0.013 с.)