exam10 4 - stankin/design-part-1 GitHub Wiki

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

Реферат к лекции 10 История развития итеративной разработки программных средств

Выполнил: Крупенко Илья, ИДБ-18-08

Проверил: Козарезов Денис, ИДБ-18-08

Унифицированный процесс Rational (RUP)

Унифицированный процесс Rational — это универсальная методология распределения задач и сфер ответственности при разработке программного обеспечения. Её цель – создание высококачественного программного обеспечения, отвечающего потребностям и запросам пользователей. Методология RUP была разработана в компании Rational Software Corporation, которую в 2003 году купила IBM.

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

К примеру, RUP используется в системе управления онлайн-обучением TAP University. Компания поставила перед собой цель расширить область традиционного офлайн-обучения и улучшить свои сервисы для корпоративных, частных пользователей и студентов.

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

1

Что такое унифицированный процесс Rational (RUP)?

Работа над процессом – команда разработчиков RUP тесно работает с покупателями, партнёрами и группами компаний, постоянно обновляя методологию.

RUP оптимизирует командную работу – обеспечивает команде разработчиков свободный доступ к базе знаний с инструкциями для использования программных средств. Это помогает быстрее справиться с критическими проблемами. Благодаря этому команда легко находит общий язык в процессе работы над проектом.

RUP ориентирован на создание и поддержание моделей – вместо написания большого количества бумажной документации при использовании RUP методологии создаются модели – семантические представления разрабатываемого командой программного обеспечения.

RUP – это инструкция использования Unified Modelling Language (UML) – UML позволяет команде легко донести свои требования к проекту, его архитектуру и план реализации.

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

Шесть основополагающих принципов RUP

В основе RUP лежит шесть главных принципов:

  1. Итеративная модель разработки – устранение рисков на каждой стадии проекта позволяет лучше понять проблему и вносить необходимые изменения, пока не будет найдено приемлемое решение;
  2. Управление требованиями – RUP описывает процесс организации и отслеживания функциональных требований, документации и выбора оптимальных решений (как в процессе разработки, так и при ведении бизнеса);
  3. Компонентная архитектура – архитектура системы разбивается на компоненты, которые можно использовать как в текущем, так и в будущих проектах;
  4. Визуальное моделирование ПО – RUP методология разработки показывает, как создать визуальную модель программного обеспечения, чтобы понять структуру и поведение архитектуры и его компонентов;
  5. Проверка качества ПО – в процессе разработки программного обеспечения контролируется качество всех действий команды;
  6. Контроль внесённых изменений – отслеживание изменений позволяет выстроить непрерывный процесс разработки. Создаётся благоприятная обстановка, в рамках которой команда будет защищена от изменений в рабочем процессе.

Структура RUP

Данный подход описывает, кто делает что делает, как и когда. RUP можно представить в виде четырёх основных элементов:

Работники – «Кто»

Элемент «работник» определяет поведение и ответственность всех членов команды, сконцентрированных на общей цели – создании искусственных объектов (артефактов). В RUP работник – это скорее роль, определяющая, как индивидуумы должны выполнять свою работу. Работник не только производит определённые действия, но также владеет набором артефактов.

Действия – «Как»

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

Артефакты (искусственные объекты) – «Что»

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

Рабочий процесс (прецедент) – «Когда»

Рабочий процесс представляет собой последовательность действий, приводящих к видимому результату. В терминах UML можно представить рабочий процесс как диаграмму последовательности, диаграмму кооперации или диаграмму активности:

2

Пример структуры описания прецедента

1. Идентификатор прецедента

Лабораторная №4

2. Название прецедента

Разработка алгоритма и описания процедуры в проектной команде

3. Контекст

Дисциплина "Проектирование информационных систем".

Деловая игра "Разработка по SCRUM".

4. Участники (actors) и цели (goals)

Участник Категория Цель (goal)
Студент Основной Освоить методику организации разработки по SCRUM
Куратор Внешний Стимулировать освоение методики
Лектор Внешний Сократить количество ошибок
Репозиторий Инструмент Предоставить место размещения канбан-доски, задач, кода и текстов
PlantUML Инструмент Предоставить средства генерации диаграмм

5. Предусловия (pre-conditions)

  • сформирована команда, определены полномочия и обязанности ролей

  • сформулирован проект, цели проекта и системы разобраны по SMART

  • сформулирована пользовательская история (User Story) для реализации в ходе деловой игры

  • освоены основные методы проведения совещаний в форме мозгового штурма

  • освоены основные средства веб-программирования:

    • 📑 💻 HTML
    • 📑 💻 CSS
    • 📑 💻 JavaScript
    • 📑 💻 AJAX
    • 📑 💻 JQUERY
    • 📑 💻 JSON
    • 💬 паттерны и
    • 📑 💻 фреймворки MVC

  • определены предпочтения и личные возможности самостоятельного выполнению в ходе деловой игры типовых задач:

    • разработка функции
    • разработка теста
    • разработка схемы и/или подготовка данных

6. Постусловия (post-conditions)

  • все задачи (issues) к выбранной пользовательской истории зарегистрированы в соответствующем проекте
  • все задачи (issues) включены в спринт и распределены по исполнителям
  • все исполнители дали оценку по трудозатратам и срокам выполнения назначенных им задач
  • в каждой задаче записаны ее зависимости (dependencies) от других задач

7. Основной поток (main flow)

Участник Действие (activity) Ожидаемый результат
РП (Владелец продукта) Регистрирует участников проекта Участники приняли приглашения и подключились к проекту
СП (Аналитик) Регистрирует историю как отдельную задачу проекта (issue) Задача с номером
НИ (Архитектор) Разбивает задачу истории на подзадачи - процедуры Список подзадач с именами процедур
ВН (Дизайнер) Разбивает задачу истории на подзадачи - страницы Список подзадач с именами страниц
БА (Тестировщик) Разбивает задачу истории на подзадачи - тесты Список подзадач с именами тестов
АД (Мастер) Получает оценку времени для каждой подзадачи, собирает sprint log, назначает исполнителей Список подзадач на канбан-доске
КО (Тех.писатель) Делает описания для всех подзадач, требующих программной реализации Описание и необходимые диаграммы в комментариях к задаче, в виде вики-страницы или в виде комментариев в файле программы
ПП (Программист) Разрабатывает алгоритмы выполнения всех подзадач, требующих программной реализации Описание алгоритма и диаграмма деятельности в комментариях к задаче, в виде вики-страницы или в виде комментариев в файле программы

8. Исключения (exceptions)

Условие (риск) Последствия Реакция
Распределение только выбранных задач не полностью покрывает задачи спринта Срыв выполнения всего спринта Дораспределить оставшиеся задачи по участникам команды
Возникают слишком объемные задачи Задача не может быть решена в ходе одной лабораторной Разбить задачи на более мелкие, занимающие не более 1 нормочаса каждая

9. Альтернативы (alternates)

То, что может повлиять на путь перехода от предусловий к постусловиям

10. Временные параметры

  • Триггер (событие, стартующее прецедент): начало занятия по расписанию

  • Номинальная частота повторения прецедента: 1 раз в семестр * число студентов (60)

  • Продолжительность прецедента: 4 ак.часа = 4 нормочаса

Этапы разработки и примеры отображения прецедента на диаграммах UML

1.Определение требований

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

3

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

Для детализации конкретного прецедента используется диаграмма Активности (Activity Diagram):

4

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

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

2.Анализ

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

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

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

Для отображения модели анализа при помощи UML используется диаграмма классов со стереотипами (образцами поведения) «граничный класс», «сущность», «управление», а для детализации используются диаграммы сотрудничества (Collaboration):

5

Стереотип «граничный класс» отображает класс, который взаимодействует с внешними актантами, «сущность» – отображает классы, которые являются хранилищами данных, а «управление» – классы, управляющие запросами к сущностям.

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

Если акцентировать внимание на порядке взаимодействия, то другим его представлением будет диаграмма последовательности (Sequence):

6

Эта диаграмма позволяет взглянуть на обмен сообщениями во времени, наглядно отобразить последовательность процесса.

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

3.Проектирование

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

Для создания модели проектирования используются целый набор UML диаграмм: диаграммы классов, диаграммы кооперации, диаграммы взаимодействия, диаграммы активности. В нашем примере используется диаграмма классов (Class):

7

4.Реализация

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

8

5.Тестирование

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

❌ Реферат не закончен: нет ни структуры описания прецедента, см. любую из лабораторных4-6, ни примера его отображения (частичного, что важно) на диаграммах UML. Ну т.е. попросту потеряна связь между RUP и прецедентами.

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

❌ Перемудрено: вопрос был всего лишь в том, что из полного описания прецедента (10 пунктов) можно отразить на диаграммах, в первую очередь Use Case, а что нельзя.

Литература:

  1. Rational Unified Process // https://ru.wikipedia.org/wiki/Rational_Unified_Process

  2. Рабочие процессы RUP и диаграммы UML // http://www.caseclub.ru/articles/rup_uml.html

  3. RUP методология // https://www.internet-technologies.ru/articles/newbie/unificirovannyy-process-rational-rup.html

  4. Using RUP to manage small projects and teams // https://immagic.com/eLibrary/ARCHIVES/GENERAL/IBM/I050715K.pdf

  5. lab4 // https://github.com/stankin/design-part-1/wiki/lab4