exam_07
Методология RUP (Rational Unified Process).Способы декомпозиции прецедентов (Use Case) и ее изображение на диаграммах прецедентов
Методология RUP. Rational Unified Process (RUP)- – методология разработки ПО, созданная компанией Rational Software. Его цель состоит в том, чтобы гарантировать высокое качество программного продукта, отвечающего потребностям конечных пользователей, в пределах предсказуемого графика и бюджета выполнения. RUP обеспечивает строгий подход к решению задач проектирования и ответственности разработчиков.
Основные принципы:
1 — ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков
2 — концентрация на выполнении требований заказчиков к исполняемой программе
3 — ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки
4 — компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта
5 — постоянное обеспечение качества на всех этапах разработки проекта (продукта)
6 — работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам Процессы и стадии RUP
RUP использует итеративную модель разработки. В конце каждой итерации (в идеале продолжающейся от 2 до 6 недель) проектная команда должна достичь запланированных на данную итерацию целей, создать или доработать проектные артефакты и получить промежуточную, но функциональную версию конечного продукта.
Полный жизненный цикл разработки ПО состоит из 4 этапов:
В фазе начальной стадии:
•Формируются видение и границы проекта.
•Создается экономическое обоснование (business case).
•Определяются основные требования, ограничения и ключевая функциональность продукта.
•Создается базовая версия модели прецедентов.
(Прецедент соответствует отдельной функциональности системы, определяет один из вариантов её использования и описывает типичный способ взаимодействия пользователя с системой. Варианты использования обычно применяются для спецификации внешних требований к системе)
•Оцениваются риски.
При завершении начальной фазы оценивается достижение этапа жизненного цикла цели, которое предполагает соглашение заинтересованных сторон о продолжении проекта.
2.Уточнение (Elaboration) В фазе «Уточнение» производится анализ предметной области и построение исполняемой архитектуры. Это включает в себя:
•Документирование требований (включая детальное описание для большинства прецедентов).
•Обновленное экономическое обоснование и более точные оценки сроков и стоимости.
•Сниженные основные риски.
•Успешное выполнение фазы разработки означает достижение этапа жизненного цикла архитектуры
3.Построение (Construction) В фазе «Построение» происходит реализация большей части функциональности продукта. Фаза Построение завершается первым внешним релизом системы и вехой начальной функциональной готовности.
4.Внедрение (Transition) В фазе «Внедрение» создается финальная версия продукта и передается от разработчика к заказчику. Это включает в себя программу бета-тестирования, обучение пользователей, а также определение качества продукта. В случае, если качество не соответствует ожиданиям пользователей или критериям, установленным в фазе Начало, фаза Внедрение повторяется снова. Выполнение всех целей означает достижение вехи готового продукта и завершение полного цикла разработки
Диаграмма вариантов использования (англ. use case diagram) в UML — диаграмма, которая отражает отношения между актёрами и прецедентами и которая является составной частью модели прецедентов, позволяющей описать систему на концептуальном уровне.
Прецедент — часть функциональности моделируемой системы, благодаря которой пользователь может получить конкретный, измеримый и нужный ему результат. Прецедент соответствует отдельному сервису системы, определяет один из вариантов её использования и описывает типичный способ взаимодействия пользователя с системой. Варианты использования обычно применяются для спецификации внешних требований к системе.
Основное назначение диаграммы — описание функциональности и поведения, позволяющее заказчику, конечному пользователю и разработчику совместно обсуждать проектируемую или существующую систему.
При моделировании системы с помощью диаграммы прецедентов системный аналитик стремится:
•чётко отделить систему от её окружения;
•определить действующих лиц (актёров), их взаимодействие с системой и ожидаемую функциональность системы;
•определить в предметной области понятия, относящиеся к детальному описанию функциональности системы (то есть прецедентов).
Работа над диаграммой может начаться с текстового описания, полученного при работе с заказчиком. При этом нефункциональные требования (например, конкретный язык или система программирования) при составлении модели прецедентов опускаются (для них составляется другой документ)
Элементы:
Для отражения модели прецедентов на диаграмме используются:
рамки системы (англ. system boundary) — прямоугольник с названием в верхней части и эллипсами (прецедентами) внутри. Часто может быть опущен без потери полезной информации
актёр (англ. actor) — стилизованный человечек, обозначающий набор ролей пользователя (понимается в широком смысле: человек, внешняя сущность, класс, другая система), взаимодействующего с некоторой сущностью (системой, подсистемой, классом). Актёры не могут быть связаны друг с другом (за исключением отношений обобщения/наследования),
прецедент — эллипс с надписью, обозначающий выполняемые системой действия, приводящие к наблюдаемым актёрами результатам.
Надпись - может быть именем или описанием (с точки зрения актёров) того, «что» делает система (а не «как»).
Имя прецедента связано с непрерываемым сценарием — конкретной последовательностью действий, иллюстрирующей поведение. В ходе сценария актёры обмениваются с системой сообщениями.
Сценарий может быть приведён на диаграмме прецедентов в виде UML-комментария. С одним прецедентом может быть связано несколько различных сценариев.
Порядок построения диаграммы :
•выделить группы действующих лиц (работающих с системой по-разному, часто из-за различных прав доступа);
•идентифицировать как можно больше вариантов использования (процессов, которые могут выполнять пользователи). При этом не следует делить процессы слишком мелко, нужно выбирать лишь те, которые дадут пользователю значимый результат. Например, кассир может «продать товар» (это будет являться прецедентом), однако «ввод штрих-кода товара для получения цены» самостоятельным прецедентом не является;
•дополнить прецеденты словесным описанием (сценарием):
Для каждого прецедента создать разделы: «главная последовательность» и «альтернативные последовательности»; при составлении сценария нужно упорно задавать заказчику вопросы «что происходит?», «что дальше?», «что еще может происходить?» и записывать ответы на них.
Сценарии являются очень важной частью диаграмм использования, хотя их формат и не регламентирован.
Рассмотрим разработку диаграмм вариантов использования на примере. Пусть заказчик дал нам следующее техническое задание:
Цель — развитие у детей особых математических навыков.
Платформа: Windows, Linux
Функциональность:
для учеников:
выбор подготовленного учителем блока заданий;
выполнение этих заданий;
для учителя:
подготовка для учеников блоков заданий;
добавление в систему ученика/ов;
просмотр отчетов.
При первом запуске система должна позволять ввести пароль учителя. Задания представляют собой математические упражнения на сложение, вычитание, умножение и деление. В блоке задач могут быть задачи различных типов (указывается количество). Помимо ввода типа выполняемой в примере операции необходимо указывать допустимые диапазоны чисел (или даже отдельные числа, т.к. при изучении таблицы умножения часто сначала учат умножение на 2, затем на 5, а только потом все остальное). Кроме того, для операции вычитания необходимо иметь возможность установить вычитаемое меньше уменьшаемого! (т.к. в противном случае результат будет отрицательным, а отрицательные числа в школе проходят гораздо позже).
Сценарии должны описываться с точки зрения пользователя, при этом важно описывать взаимодействие пользователя с элементами интерфейса. Так например сценарий прецедента регистрации ученика мог бы выглядеть следующим образом:
Название прецедента: регистрация ученика
Действующее лицо: учитель
Цель: добавить ученика в систему, получив его пароль
Предусловия: учитель осуществил вход в систему
Главная последовательность:
учитель выбирает в главном меню пункт «добавить ученика«;
система показывает учителю окно добавления ученика, содержащее поля для ввода логина и пароля, а также кнопки «далее» и «назад»;
учитель вводит желаемый логин и пароль ученика, нажимает кнопку «далее»;
система добавляет ученика;
учителю открывается главное меню и в течении 5 секунд выводится уведомление о том, что ученик был добавлен успешно. Альтернативная последовательность (возврат в главное меню без добавления ученика):
учитель выбирает в главном меню пункт «добавить ученика«;
система показывает учителю окно добавления ученика, содержащее поля для ввода логина и пароля, а также кнопки «далее» и «назад»;
учитель нажимает кнопку «назад»;
учителю открывается главное меню (при этом данные, введенные в формы окна добавления ученика не сохраняются). Альтернативная
последовательность (добавление ученика, уже имеющегося в системе):
учитель выбирает в главном меню пункт «добавить ученика«;
система показывает учителю окно добавления ученика, содержащее поля для ввода логина и пароля, а также кнопки «далее» и «назад»;
учитель вводит желаемый логин и пароль ученика, нажимает кнопку «далее»;
учителю в течении 5 секунд отображается уведомление о том, что запрашиваемый логин занят.
Аналогичным образом должны быть прописаны все прецеденты, изображенные на диаграмме. Составлять сценарии нужно достаточно упорно чтобы описать все возможные варианты действий пользователя в системе.
Наиболее типичными ошибками при построении диаграмм являются:
•неправильное использование отношений расширения и включения, в том числе попытки использовать диаграммы для функциональной декомпозиции системы. Возникает из-за непонимания различий между этими двумя видами отношений и того, что use-case диаграмма должна выражать лишь требования к системе, а не детали ее реализации;
•разработка диаграммы с точки зрения программиста, а не пользователя;
•В сценариях должны использоваться названия элементов управления (видимые пользователю), но нежелательно изображать детали реализации (такие как менеджер событий), непонятные заказчику;
•недостаточная проработка сценариев;
•отсутствие или недостаточное количество альтернативных последовательностей, в которых должен быть учтен, в том числе, ввод некорректных данных в систему;
•описание действий пользователя без указания конкретных элементов интерфейса системы и отсутствие описаний реакции системы в сценариях.
Если следовать всем приведенным правилам составления диаграмм вариантов использования, с их помощью можно достаточно подробно проработать техническое задание чтобы оценить сроки и стоимость его выполнения, описать конкретные сценарии взаимодействия с системой, которые лягут в основу тестов и документации, и согласовать всё это с заказчиком.
Список литературы:
-
Википедия, общие вводные данные по определениям https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B5%D1%86%D0%B5%D0%B4%D0%B5%D0%BD%D1%82
-
Понятие методолгии RUP и описание основных принципов https://qaevolution.ru/metodologiya-menedzhment/rup/
3.Процессы и стадии RUP https://habr.com/ru/sandbox/43802/
4.Бабич А. В. Введение в UML // Интернет университет информационных технологий. 2008. URL: http://www.intuit.ru/studies/courses/1007/229/info
Понятие очереди в теории массового обслуживания. Виды и способы организации очередей в объектно-ориентированном программировании.
Теория массового обслуживания. Понятие очереди
Рассмотрим для начала что же такое теория массового обслуживания.
Теория массового обслуживания, или очередей, — раздел теории вероятностей, целью исследований которого является рациональный выбор структуры системы обслуживания и процесса обслуживания на основе изучения потоков требований на обслуживание, поступающих в систему и выходящих из неё, длительности ожидания и длины очередей. В теории массового обслуживания используются методы теории вероятностей и математической статистики.
Предметом этой теории является являются системы массового обслуживания (СМО).Задачами теории массового обслуживания являются анализ и исследование явлений, возникающих в системах обслуживания. Одна из основных задач теории заключается в определении таких характеристик системы, которые обеспечивают заданное качество функционирования. Например, минимум времени ожидания, минимум средней длины очереди. Цель изучения режима функционирования обслуживающей системы в условиях, когда фактор случайности является существенным, контролировать некоторые количественные показатели функционирования системы массового обслуживания. Такими показателями, в частности являются среднее время пребывания клиента в очереди или доля времени, в течение которой обслуживающая система простаивает.
Любой системе массового обслуживания характерна структура, которая определяется составом элементов и функциональными связями.
Основные элементы системы следующие:
•Входящий поток требований (интенсивность входящего потока);
•Каналы обслуживания (число каналов, среднее число занятых, производительность);
•Очередь требований (среднее число заявок, среднее время пребывания одной заявки);
•Выходящий поток требований (интенсивность входящего потока);
Очередь же представляет собой последовательность требований или заявок, которые,видя, что система обслуживания занята, не выбывают, а ожидают ее освобождения, а затем они обслуживаются в том или ином порядке. Очередью можно назвать также и совокупность ожидающих каналов или средств обслуживания. Это ключевое понятие теории очередей.
Процесс образования очереди носит стохастический характер, так как состоит из случайных переменных, значения которых меняются во времени. Очереди требований или заявок подразделяются, прежде всего, на замкнутые и линейные.
Также важными параметрами являются длина очереди, т.е. среднее число ожидающих требований, и время ожидания обслуживания – среднее время пребывания требования в системе до момента начала обслуживания.
Виды и способы организации очередей в объектно-ориентированном программировании.
Очередь
Очередь как структура данных понятна даже людям, не знакомым с программированием. Очередь содержит элементы, как бы выстроенные друг за другом в цепочку. У очереди есть начало и конец. Добавлять новые элементы можно только в конец очереди, забирать элементы можно только из начала. В отличие от обычной очереди, которую всегда можно при желании покинуть, из середины программистской очереди удалять элементы нельзя.
Очередь иногда называют циклической памятью. Принцип технической обработки очереди или обслуживания конфликтных требований путём упорядочения процесса объясняется по принципу: «первым пришёл — первым обслужен» (ПППО). Тот, кто приходит первым, тот и обслуживается первым, пришедший следующим ждёт, пока обслуживание первого не будет закончено, и так далее.
Двусторонняя очередь
Разновидностью очередей является двухсторонняя очередь или по-другому дек. Она отличается от обычной очереди тем, что добавление и удаление данных допустимо с обоих концов очереди. Для реализации алгоритмов работы с двухсторонней очередью можно использовать те же структуры, что и для обычной очереди (Data (данные) и Queue (очередь)), необходимо только дополнить основные операции. Для работы с деком необходимы следующие действия: добавление в начало и конец очереди (последнюю можно взять из примеров для обычной очереди), удаление из начала очереди (берем как для обычной очереди) и с конца очереди.
Очередь с приоритетом
Это очень интересная разновидность очередей. В ней добавление новых данных производится также в конец очереди, а вот выборка — в зависимости от какого-либо правила. Примером может служить очередь в кассу магазина, где людей с какими-нибудь удостоверениями, например, инвалида или ветерана, обслуживают без очереди. Для представления данных можно использовать те же структуры, что и для обычной очереди, добавление в конец очереди будет таким же, а вот извлечение из очереди требует основательной переделки. При каждом извлечении вначале надо поискать в очереди «вне очередников» (есть такой — его и извлекаем, на этом очередной запрос исчерпан) и только потом работать с остальными в обычном режиме. Могут быть выделены два типа таких видов очередей:
•Очередь с приоритетным включением - такая очередь, в которой последовательность элементов все время поддерживается упорядоченной по убыванию приоритета. •Очередь с приоритетным исключением — очередь, в которой включение элементов осуществляется в конец,а при исключении производится поиск элемента с максимальным приоритетом.
Взвешенные настраиваемые очереди
Здесь делается попытка предоставить всем классам определенный минимум пропускной способности, т.е. обслуживания, и гарантировать некоторые требования к задержкам. Под весом для каждого класса понимается процент предоставляемой классу пропускной способности (от полной выходной пропускной способности). Алгоритм, используемый администратором для назначения весов, называется настраиваемой очередью
Основные операции с очередями:
•Включение элемента и исключение элемента.
•Добавление элемента в начало очереди.
•Удаление элемента из начала очереди.
•Добавление элемента в конец очереди.
•Удаление элемента из конца очереди.
•Проверка очереди на наличие в нем элемента.
Список литературы:
-
Википедия. Определение теории массового обслуживания https://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B8%D1%8F_%D0%BC%D0%B0%D1%81%D1%81%D0%BE%D0%B2%D0%BE%D0%B3%D0%BE_%D0%BE%D0%B1%D1%81%D0%BB%D1%83%D0%B6%D0%B8%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F
-
Понятие системы ТМО https://bourabai.ru/cm/bank.htm
-
Информация о взвешенных настраиваемых очередях https://studopedya.ru/1-103034.html
-
Понятие очередей и алгоритмах их обслуживания https://helpiks.org/6-84559.html