Рудов И.А.

Методология RUP (Rational Unified Process). Способы декомпозиции прецедентов (Use Case) и ее изображение на диаграммах прецедентов

Rational Unified Process (RUP)- это процесс разработки программного обеспечения. Его цель состоит в том, чтобы гарантировать высокое качество программного продукта, отвечающего потребностям конечных пользователей, в пределах предсказуемого графика и бюджета выполнения. RUP обеспечивает строгий подход к решению задач проектирования и ответственности разработчиков.

Диаграмма вариантов использования (англ. use case diagram) в UML — диаграмма, отражающая отношения между актёрами и прецедентами и являющаяся составной частью модели прецедентов, позволяющей описать систему на концептуальном уровне[1].

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

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

При моделировании системы с помощью диаграммы прецедентов системный аналитик стремится:

• чётко отделить систему от её окружения;
• определить действующих лиц (актёров), их взаимодействие с системой и ожидаемую функциональность системы;
• определить в глоссарии предметной области понятия, относящиеся к детальному описанию функциональности системы (то есть прецедентов).
• Работа над диаграммой может начаться с текстового описания, полученного при работе с заказчиком. При этом нефункциональные требования (например, конкретный язык или система программирования) при составлении модели прецедентов опускаются (для них составляется другой документ)

Элементы:

Для отражения модели прецедентов на диаграмме используются:

• рамки системы (англ. system boundary) — прямоугольник с названием в верхней части и эллипсами (прецедентами) внутри. Часто может быть опущен без потери полезной информации,
• актёр (англ. actor) — стилизованный человечек, обозначающий набор ролей пользователя (понимается в широком смысле: человек, внешняя сущность, класс, другая система), взаимодействующего с некоторой сущностью (системой, подсистемой, классом). Актёры не могут быть связаны друг с другом (за исключением отношений обобщения/наследования),
• прецедент — эллипс с надписью, обозначающий выполняемые системой действия (могут включать возможные варианты), приводящие к наблюдаемым актёрами результатам. Надпись может быть именем или описанием (с точки зрения актёров) того, «что» делает система (а не «как»). Имя прецедента связано с непрерываемым (атомарным) сценарием — конкретной последовательностью действий, иллюстрирующей поведение. В ходе сценария актёры обмениваются с системой сообщениями. Сценарий может быть приведён на диаграмме прецедентов в виде UML-комментария. С одним прецедентом может быть связано несколько различных сценариев.

Отношения между прецедентами Часть дублирующейся информации в модели прецедентов можно устранить указанием связей между прецедентами:

• обобщение прецедента — стрелка с незакрашенным треугольником (треугольник ставится у более общего прецедента),
• включение прецедента — пунктирная стрелка со стереотипом «include»,
• расширение прецедента — пунктирная стрелка со стереотипом «extend» (стрелка входит в расширяемый прецедент, в дополнительном разделе которого может быть указана точка расширения и, возможно в виде комментария, условие расширения)

Порядок построения диаграммы (вариант):

• выделить группы действующих лиц (работающих с системой по-разному, часто из-за различных прав доступа);
• идентифицировать как можно больше вариантов использования (процессов, которые могут выполнять пользователи). При этом не следует делить процессы слишком мелко, нужно выбирать лишь те, которые дадут пользователю значимый результат. Например, кассир может «продать товар» (это будет являться прецедентом), однако «ввод штрих-кода товара для получения цены» самостоятельным прецедентом не является;
• дополнить прецеденты словесным описанием (сценарием):
• для каждого прецедента создать разделы: «главная последовательность» и «альтернативные последовательности»;
• при составлении сценария нужно упорно задавать заказчику вопросы «что происходит?», «что дальше?», «что еще может происходить?» и записывать ответы на них.

Сценарии являются очень важной частью диаграмм использования, хотя их формат и не регламентирован. Ряд авторов предлагает использовать псевдокод для представления сценария и даже сразу строить диаграммы деятельности или взаимодействия, но на мой взгляд, наиболее предпочтительным вариантом на этапе построения use-case диаграмм является текстовый, описывающий систему с точки зрения пользователя (т.к. именно этот формат будет наиболее понятен заказчику, с которым вам предстоит согласовывать техническое задание).

Рассмотрим разработку диаграмм вариантов использования на примере — пусть заказчик дал нам следующее техническое задание:

• Цель — развитие у детей математических навыков.

• Платформа: Linux, Windows, Android.

• Функциональность:

• для учеников:

• выбор подготовленного учителем блока заданий;

• выполнение заданий;

• для учителя:

• подготовка для учеников блоков заданий;

• добавление в систему ученика;

• просмотр отчетов. При первом запуске система должна позволять ввести пароль учителя. Задания представляют собой математические задачи на сложение, вычитание, умножение и деление. В блоке задач могут быть задачи различных типов (указывается количество). Помимо ввода типа выполняемой в примере операции необходимо указывать допустимые диапазоны чисел (или даже отдельные числа, т.к. при изучении таблицы умножения часто сначала учат умножение на 2, затем на 5, а только потом все остальное). Кроме того, для операции вычитания необходимо иметь возможность установить вычитаемое меньше уменьшаемого (т.к. в противном случае результат будет отрицательным, а отрицательные числа в школе проходят гораздо позже).

Очевидно, несмотря на то, что заказчик очень подробно описал некоторые детали, мы не можем не только приступить к реализации задачи, но даже приблизительно оценить стоимость и сроки выполнения. Из такого задания не понятно, например, что должны содержать отчеты. Однако, мы сразу можем выделить две группы пользователей и несколько видов их деятельности.

Рис. 1. Пример диаграммы использования

Сплошные линии на диаграмме представляют собой отношения ассоциации, отражающие возможность использования актором прецедента. После того, как определен набор вариантов использования, можно приступать к составлению сценариев. Сценарии должны описываться с точки зрения пользователя, при этом важно описывать взаимодействие пользователя с элементами интерфейса. Так например сценарий прецедента регистрации ученика мог бы выглядеть следующим образом:

Название прецедента: регистрация ученика

Действующее лицо: учитель

Цель: добавить ученика в систему, получив его пароль

Предусловия: учитель осуществил вход в систему

Главная последовательность:

• учитель выбирает в главном меню пункт «добавить ученика«;

• система показывает учителю окно добавления ученика, содержащее поля для ввода логина и пароля, а также кнопки «далее» и «назад»;

• учитель вводит желаемый логин и пароль ученика, нажимает кнопку «далее»;

• система добавляет ученика;

• учителю открывается главное меню и в течении 5 секунд выводится уведомление о том, что ученик был добавлен успешно. Альтернативная последовательность (возврат в главное меню без добавления ученика):

• учитель выбирает в главном меню пункт «добавить ученика«;

• система показывает учителю окно добавления ученика, содержащее поля для ввода логина и пароля, а также кнопки «далее» и «назад»;

• учитель нажимает кнопку «назад»;

• учителю открывается главное меню (при этом данные, введенные в формы окна добавления ученика не сохраняются). Альтернативная последовательность (добавление ученика, уже имеющегося в системе):

• учитель выбирает в главном меню пункт «добавить ученика«;

• система показывает учителю окно добавления ученика, содержащее поля для ввода логина и пароля, а также кнопки «далее» и «назад»;

• учитель вводит желаемый логин и пароль ученика, нажимает кнопку «далее»;

• учителю в течении 5 секунд отображается уведомление о том, что запрашиваемый логин занят.

Аналогичным образом должны быть прописаны все прецеденты, изображенные на диаграмме. Составлять сценарии нужно достаточно упорно чтобы описать все возможные варианты действий пользователя в системе. Заказчик может делать это с большим удовольствием, а программист за счет этого раньше узнает возможные пожелания заказчика (так из приведенного сценария он мог бы выяснить, что программа должна отображать всплывающие уведомления).

Несмотря на простоту приведенного сценария, в его последовательностях можно найти дублирование, если оно имеет место в ваших сценариях — вы можете выделить некоторые фрагменты описания в отдельные прецеденты (которые могут быть как самостоятельными, так и являться лишь частью других вариантов использования). При этом между прецедентами появится либо отношение расширения (extend), либо включения (include), которые отображаются на диаграммах (в UML также существует отношение обобщения, а в OML — вызова и предшествования).

Отношение включения указывает на то, что поведение одного прецедента включается в некоторой точке в другой прецедент в качестве составного компонента. Особенности включения заключаются в том, что включаемый прецедент должен быть обязательным для дополняемого (включение должно быть безусловным, а дополняемый вариант использования без включения не сможет выполняться), т.е. это это отношение задает очень сильную связь. Например, если мы хотим изобразить на диаграмме тот факт, что удаление набора задач учителем и выполнение задач учеником не должно происходить без обязательного просмотра всех наборов задач — то нам нужно использовать отношение включения:

Рис. 2. Отношение включения на диаграмме использования

Отношение расширения отражает возможное присоединение одного варианта использования к другому в некоторой точке (точке расширения). При этом подчеркивается то, что расширяющий вариант использования выполняется лишь при определенных условиях и не является обязательным для выполнения основного прецедента. На диаграмме такой вид отношения изображается стрелкой, направленной к расширяемому прецеденту, в отдельном разделе которого может быть описана точка расширения, а условия расширения могут быть приведены в комментарии с ключевым словом Condition. Таким образом, расширение позволяет моделировать необязательное поведение системы, которое является условным и не изменяет поведение основного прецедента. Например отношение расширения нужно применить, если по техническому заданию требуется возможность удаления набора задач в прецеденте просмотра отчетов при условии, что все ученики решили этот набор.

Рис. 3. Отношение расширения на диаграмме использования

Таким образом можно показать, что у учителя появляется возможность (но не обязанность) удалить набор задач при просмотре отчетов если все ученики выполнили этот набор.

На последней диаграмме используется символ комментария для задания условий расширения, при этом комментарий связывается пунктирной линией с отношением расширения, т.к. относится к нему. В ряде публикаций по UML и ICONIX предлагается описывать с помощью комментариев на диаграмме прецедентов:

нефункциональные требования к системе (при этом используется стереотип <>); сценарии вариантов использования (связывая комментарий с соответствующим прецедентом); детали реализации и другие выводы, к которым разработчики пришли в процессе обсуждения задачи (не все с этим согласны, т.к. use-case диаграмма показывается заказчику, которому не нужны детали). Наиболее типичными ошибками при построении этого вида диаграмм являются:

• неправильное использование отношений расширения и включения, в том числе попытки использовать диаграммы для функциональной декомпозиции системы. Возникает из-за непонимания различий между этими двумя видами отношений и того, что use-case диаграмма должна выражать лишь требования к системе, а не детали ее реализации;
• разработка диаграммы с точки зрения программиста, а не пользователя. В сценариях должны использоваться названия элементов управления (видимые пользователю), но нежелательно изображать детали реализации (такие как менеджер событий), не понятные заказчику; не достаточная проработка сценариев:
• отсутствие или недостаточное количество альтернативных последовательностей, в которых должен быть учтен, в том числе, ввод некорректных данных в систему;
• описание действий пользователя без указания конкретных элементов интерфейса системы и отсутствие описаний реакции системы в сценариях. Важно, что процесс ICONIX является итеративным, поэтому если вы допустите неточности на этапе разработке диаграмм использования — их можно будет найти и исправить на следующих этапах (в частности, пропущенные объекты могут быть выделены при работе над диаграммами робастности, а сценарии детально проработаны при построении диаграмм последовательности).

Стоит отметить, что нет единого мнения по поводу использования в текстах сценария условных операторов или циклов. Ряд аналитиков считают, что наличие слов типа «если» в сценарии является ошибкой, которая исправляется добавлением альтернативной последовательности. Другие — допускают использование 1-2 ветвлений в сценарии, при этом отмечают, что такой подход улучшает читабельность сценариев.

Если следовать всем приведенным правилам составления диаграмм вариантов использования, с их помощью можно достаточно подробно проработать техническое задание чтобы оценить сроки и стоимость его выполнения, описать конкретные сценарии взаимодействия с системой, которые лягут в основу тестов и документации, и согласовать всё это с заказчиком.

Список литературы:

• Буч Градди Объектно-ориентированный анализ и проектирование с примерами приложений, 3-е изд. / Буч Градди, Максимчук Роберт А., Энгл Майкл У., Янг Бобби Дж., Коналлен Джим, Хьюстон Келли А.: Пер с англ. – М.: ООО “И.Д. Вильямс”, 2010. – 720 с.
• Розенберг Д., Скотт К. Применение объектного моделирования с использованием UML и анализ прецедентов.: Пер. с англ. М.: ДМК Пресс, 2002
• Бабич А. В. Введение в UML // Интернет университет информационных технологий. 2008. URL: http://www.intuit.ru/studies/courses/1007/229/info (дата обращения: 19.03.2016).
• Леоненков, A.B. Объектно-ориентированный анализ и проектирование с использованием UML и IBM Rational Rose: учеб. пособие Текст. / A.B. Леоненков. М.: Интернет-Ун-т информ. технологий: БИНОМ, Лаборатория знаний, 2006. — 320 с.

2. Понятие очереди в теории массового обслуживания. Виды и способы организации очередей в объектно-ориентированном программировании.

Теория массового обслуживания. Понятие очереди

Рассмотрим для начала что же такое теория массового обслуживания.

Предметом этой теории является являются системы массового обслуживания (СМО).Задачами теории массового обслуживания являются анализ и исследование явлений, возникающих в системах обслуживания. Одна из основных задач теории заключается в определении таких характеристик системы, которые обеспечивают заданное качество функционирования, например, минимум времени ожидания, минимум средней длины очереди. Цель изучения режима функционирования обслуживающей системы в условиях, когда фактор случайности является существенным, контролировать некоторые количественные показатели функционирования системы массового обслуживания. Такими показателями, в частности являются среднее время пребывания клиента в очереди или доля времени, в течение которой обслуживающая система простаивает. При этом в первом случае мы оцениваем систему с позиции «клиента», тогда как во втором случае мы оцениваем степень загруженности обслуживающей системы. Путем варьирования операционными характеристиками обслуживающей системы может быть достигнут разумный компромисс между требованиями «клиентов» и мощностью обслуживающей системы.

Любой системе массового обслуживания характерна структура, которая определяется составом элементов и функциональными связями.

Основные элементы системы следующие:

1. Входящий поток требований (интенсивность входящего потока);
2. Каналы обслуживания (число каналов, среднее число занятых, производительность);
3. Очередь требований (среднее число заявок, среднее время пребывания одной заявки);
4. Выходящий поток требований (интенсивность входящего потока).

Взаимодействие этих элементов представлено в одноканальной СМО, структурная модель которого представлена на рисунке 4.

Рис. 4. Модель СМО

Очередь же представляет собой последовательность требований или заявок, которые, заставая систему обслуживания занятой, не выбывают, а ожидают ее освобождения, а затем они обслуживаются в том или ином порядке. Очередью можно назвать также и совокупность ожидающих каналов или средств обслуживания. Это ключевое понятие теории очередей.

Процесс образования очереди носит стохастический характер, так как состоит из случайных переменных, значения которых меняются во времени. Очереди требований или заявок подразделяются, прежде всего, на замкнутые и линейные.

Также важными параметрами являются длина очереди, т.е. среднее число ожидающих требований, и время ожидания обслуживания – среднее время пребывания требования в системе до момента начала обслуживания.

Виды и способы организации очередей в объектно-ориентированном программировании.

Очередь

Очередь как структура данных понятна даже людям, не знакомым с программированием. Очередь содержит элементы, как бы выстроенные друг за другом в цепочку. У очереди есть начало и конец. Добавлять новые элементы можно только в конец очереди, забирать элементы можно только из начала. В отличие от обычной очереди, которую всегда можно при желании покинуть, из середины программистской очереди удалять элементы нельзя.

Очередь - такой последовательный список с переменной длинной, включение элементов в который происходит с одной стороны, а исключение элементов - с другой стороны списка. Очередь иногда называют циклической памятью или списком типа FIFO («first-in-first-out»). Этим названием описывается принцип технической обработки очереди или обслуживания конфликтных требований путём упорядочения процесса по принципу: «первым пришёл — первым обслужен» (ПППО). Тот, кто приходит первым, тот и обслуживается первым, пришедший следующим ждёт, пока обслуживание первого не будет закончено, и так далее.

Двусторонняя очередь

Разновидностью очередей является двухсторонняя очередь или дек. Она отличается от обычной очереди тем, что добавление и удаление данных допустимо с обоих концов очереди. Для реализации алгоритмов работы с двухсторонней очередью можно использовать те же структуры, что и для обычной очереди (Data (данные) и Queue (очередь)), необходимо только дополнить основные операции. Для работы с деком необходимы следующие действия: добавление в начало и конец очереди (последнюю можно взять из примеров для обычной очереди), удаление из начала очереди (берем как для обычной очереди) и с конца очереди.

Очередь с приоритетом

Это очень интересная разновидность очередей. В ней добавление новых данных производится также в конец очереди, а вот выборка -- в зависимости от какого-либо правила. Примером может служить очередь в кассу магазина, где людей с какими-нибудь удостоверениями, например, ветеранов или инвалидов, обслуживают без очереди. Для представления данных можно использовать те же структуры, что и для обычной очереди, добавление в конец очереди будет таким же, а вот извлечение из очереди требует основательной переделки. При каждом извлечении вначале надо поискать в очереди «вне очередников» (есть такой -- его и извлекаем, на этом очередной запрос исчерпан) и только потом работать с остальными в обычном режиме. Могут быть выделены два типа таких видов очередей:

1. Очередь с приоритетным включением - такая очередь, в которой последовательность элементов все время поддерживается упорядоченной по убыванию приоритета.
2. Очередь с приоритетным исключением — очередь, в которой включение элементов осуществляется в конец, а при исключении производится поиск элемента с максимальным приоритетом.

Взвешенные настраиваемые очереди

Здесь делается попытка предоставить всем классам определенный минимум пропускной способности, т.е. обслуживания, и гарантировать некоторые требования к задержкам. Под весом для каждого класса понимается процент предоставляемой классу пропускной способности (от полной выходной пропускной способности). Алгоритм, используемый администратором для назначения весов, называется настраиваемой очередью (рис. 5).

Рис. 5. Взвешенная настраиваемая очередь

Основные операции с очередями

Основные операции:

1. Включение элемента и исключение элемента. При включении новый элемент заносится в ячейку, следующую за указателем P2. При исключении из очереди извлекается элемент, адресуемый указателем P1, после чего P1 перемещается к следующему элементу.
2. Добавление элемента в начало очереди.
3. Удаление элемента из начала очереди.
4. Добавление элемента в конец очереди.
5. Удаление элемента из конца очереди.
6. Проверка очереди на наличие в нем элемента.

Список литературы:

• Электронный ресурс "Экономический рост" URL:http://ekrost.ru/poster/teoriya-ocheredei.html (Дата обращения 18.03.2019)
• Роберт Круз. Структуры данных и проектирование программ. — Бином. Лаборатория знаний, 2008. — С. 768.
• Электронный ресурс "Мегалекции" URL:https://megalektsii.ru/s10016t1.html (Дата обращения 19.03.2019)
• Электронный ресурс "Allbest" URL:https://otherreferats.allbest.ru/programming/00381030_0.html (Дата обращения 19.03.2019)
• Электронный ресурс "МВБлог" URL:http://mvblog.ru/archives/312/ (Дата обращения 18.03.2019)

3.Взаимосвязь вопросов и применение в ВКР

Диаграммы вариантов использования желательно применить при написании выпускной квалификационной работы, так как она позволяет описать систему еще на концептуальном уровне. Используя эти диаграммы будет проще продумывать архитектуру программного продукта, которая будет включать в себя правильно настроенный менеджер очередей.

Например, при создании модуля планирования туристических маршрутов на основе анализа интересов пользователя, необходимо с самого начала правильно настроить работу очереди. В рамках данного модуля будет использоваться очередь с приоритетом, где наивысший приоритет отдается пользовательским запросам, а наименьший - системным фоновым службам.