МАРК РЕГНЕРУС ДОСЛІДЖЕННЯ: Наскільки відрізняються діти, які виросли в одностатевих союзах
РЕЗОЛЮЦІЯ: Громадського обговорення навчальної програми статевого виховання ЧОМУ ФОНД ОЛЕНИ ПІНЧУК І МОЗ УКРАЇНИ ПРОПАГУЮТЬ "СЕКСУАЛЬНІ УРОКИ" ЕКЗИСТЕНЦІЙНО-ПСИХОЛОГІЧНІ ОСНОВИ ПОРУШЕННЯ СТАТЕВОЇ ІДЕНТИЧНОСТІ ПІДЛІТКІВ Батьківський, громадянський рух в Україні закликає МОН зупинити тотальну сексуалізацію дітей і підлітків Відкрите звернення Міністру освіти й науки України - Гриневич Лілії Михайлівні Представництво українського жіноцтва в ООН: низький рівень культури спілкування в соціальних мережах Гендерна антидискримінаційна експертиза може зробити нас моральними рабами ЛІВИЙ МАРКСИЗМ У НОВИХ ПІДРУЧНИКАХ ДЛЯ ШКОЛЯРІВ ВІДКРИТА ЗАЯВА на підтримку позиції Ганни Турчинової та права кожної людини на свободу думки, світогляду та вираження поглядів
Контакти
Тлумачний словник Авто Автоматизація Архітектура Астрономія Аудит Біологія Будівництво Бухгалтерія Винахідництво Виробництво Військова справа Генетика Географія Геологія Господарство Держава Дім Екологія Економетрика Економіка Електроніка Журналістика та ЗМІ Зв'язок Іноземні мови Інформатика Історія Комп'ютери Креслення Кулінарія Культура Лексикологія Література Логіка Маркетинг Математика Машинобудування Медицина Менеджмент Метали і Зварювання Механіка Мистецтво Музика Населення Освіта Охорона безпеки життя Охорона Праці Педагогіка Політика Право Програмування Промисловість Психологія Радіо Регилия Соціологія Спорт Стандартизація Технології Торгівля Туризм Фізика Фізіологія Філософія Фінанси Хімія Юриспунденкция |
|
|||||||
Про варіанти взаємодії користувача з ПСМделювання взаємодії користувача з ПС базується на сценаріях UML, а саме, Варіантах використання, до яких актор звертається до системи. У відповідь система виконує певну роботу у результаті одного запуску відповідної роботи системи, або, якщо якісь події її перервали, вважається невиконаною. Будь–яка робота складається з чотирьох частин, а саме: 1. Актор посилає до системи запит та дані до нього. 2. Система підтверджує отримання запиту та даних. 3. Система реагує на підтверджений запит зміною свого стану. 4. Система видає актору результат. Варіанти використання системи деталізуються в процесі їх подальшого аналізу у сукупність взаємодіючих об’єктів. Визначений таким чином ланцюг трансформацій (проблема – цілі – варіанти використання – об'єкти) відображає ступені концептуалізації, тобто досягнення розуміння проблеми, послідовного зниження складності її частин та підвищення рівня формалізації моделей останніх. Зазначимо, що наведені вище трансформації зазвичай виражаються в термінах базових понять проблемної області, які використовується при представленні ПрО та варіантів використання. Життєвий цикл варіанта використання такий: - Особа–в–ролi, або екземпляр актора, вводить підходящий стимул, стартує екземпляр потрібного йому варіанта використання і виконується доти, доки екземпляр варіанту використання знову чекає на вхідний стимул від екземпляру актора. - Екземпляр варіанта використання існує, поки він виконується. У даній моделі визначені такі правила: – кожен варіант використання може запускатися тільки одним актором; – кожен актор може запускати декілька варіантів використання; – взаємодія акторів в інтересах системи (тобто, як складова її функціональності) дозволяється тільки через передбачені для цього варіанти використання; – актор не визначає варіант використання, він тільки ініціює ланцюжок подій, який викличе варіант використання; – для кожного актора визначаються (неформально) його інтерфейси з тими варіантами використання, які він буде запускати. Варіант використання має стан та поведінку. Якщо запуск багатьох варіантів використання системи мають подібну поведінку, вони розглядаються як клас об`єктів варіанту використання. Виклик варіанта породжує екземпляр класу.. Фіксація варіантів використання визначається вимогами та неформальним описом його властивостей. Кожному процесу відповідають один або декілька сценаріїв взаємодії з користувачем системи. Сценарії визначають послуги, які запускаються кожним типом актора. Для специфікації властивостей варіантів використання пропонується каркас (framework), подається послідовністю наступних елементів: – назва, яка однозначно ідентифікує варіант використання на діаграмах моделі сценарію i є засобом посилання на варіант використання; – анотація (короткий зміст у неформальному поданні); – актори, що можуть запускати варіант використання за зверненнями до послуги системи; – визначення усіх аспектів взаємодії системи з акторами: можливих дій акторів та їх можливих наслідків; – передумови визначення початкового стану, необхідного для успішного виконання; – функції, які здійснюються при виконанні варіанта використання ; – опис нестандартні ситуації, яка може з'явитися при виконанні варіанта використання та завдання дії, яка є реакцією на таку ситуацію ; – умови завершення варіанта використання; – постумови, що визначає кінцевий стан варіанта використання при його нормальному, тобто успішному завершенні.; – опис інтерфейсів, який також подається неформально; . – нефункціональні вимоги до варіанта використання. Включення – перелік назв сценаріїв, які він використовує у сенсі UML Нижче подаються специфікації властивостей сценаріїв взаємодії користувача задля його інформаційного забезпечення. В даному документі специфікації варіанта використання обмежуються такими атрибутами: назва, функції, передумови, пост–умови, опис інтерфейсів тощо.
Читайте також:
|
||||||||
|