Заглавная страница Избранные статьи Случайная статья Познавательные статьи Новые добавления Обратная связь FAQ Написать работу КАТЕГОРИИ: АрхеологияБиология Генетика География Информатика История Логика Маркетинг Математика Менеджмент Механика Педагогика Религия Социология Технологии Физика Философия Финансы Химия Экология ТОП 10 на сайте Приготовление дезинфицирующих растворов различной концентрацииТехника нижней прямой подачи мяча. Франко-прусская война (причины и последствия) Организация работы процедурного кабинета Смысловое и механическое запоминание, их место и роль в усвоении знаний Коммуникативные барьеры и пути их преодоления Обработка изделий медицинского назначения многократного применения Образцы текста публицистического стиля Четыре типа изменения баланса Задачи с ответами для Всероссийской олимпиады по праву Мы поможем в написании ваших работ! ЗНАЕТЕ ЛИ ВЫ?
Влияние общества на человека
Приготовление дезинфицирующих растворов различной концентрации Практические работы по географии для 6 класса Организация работы процедурного кабинета Изменения в неживой природе осенью Уборка процедурного кабинета Сольфеджио. Все правила по сольфеджио Балочные системы. Определение реакций опор и моментов защемления |
Варіанти використання системиСодержание книги
Похожие статьи вашей тематики
Поиск на нашем сайте
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 – Дослідження користувача
Комп’ютерний рівень знань користувача, який буде користуватися програмним додатком узагальнено в таблиці 3.1.2.2. Таблиця – 3.1.2.2 – Характеристика користувача програми
|
|||||||||||||||||||||||||||||||||||||||||||||||
Последнее изменение этой страницы: 2016-08-16; просмотров: 2021; Нарушение авторского права страницы; Мы поможем в написании вашей работы! infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.145.66.104 (0.013 с.) |