Форма входа

Категории раздела

Повышение производительности аналитика [7]

Поиск

Наш опрос

Интересны ли Вам статьи цикла "Повышение производительности аналитика"?
Всего ответов: 25

Друзья сайта

  • Официальный блог
  • Сообщество uCoz
  • FAQ по системе
  • Инструкции для uCoz
  • Статистика


    Онлайн всего: 1
    Гостей: 1
    Пользователей: 0
    Четверг, 18.01.2018, 04:46
    Приветствую Вас Гость
    Главная | Регистрация | Вход | RSS

    Я - Аналитик!

    Каталог статей

    Главная » Статьи » Опыт моделирования на UML » Повышение производительности аналитика

    Повышение производительности аналитика 06

    Еще раз об описании прецедентов

    Те, кто читал предыдущие статьи, мой подход знают: "Модель первична, документ вторичен!". В этой статье я постараюсь подробно обосновать этот подход. Начну с цитирования "отцов-основателей".

    "Три друга": Как описывать прецедент?[1]

    "Поведение. Последовательность поведения можно описать при помощи конечного автомата, графа деятельности, взаимодействия или текстового кода, написанного на каком-либо из языков программирования.

    Элементы Use Case можно описать и неформально – при помощи сценариев или простого текста, однако такие описания недостаточно точны и не годятся для интерпретации инструментами моделирования".

    RUP: Как описывать прецедент?[2]

    RUP предоставляет следующие материалы, связанные с описанием прецедентов:

    • Описание артефакта "прецедент"
    • Шаги задачи описания артефакта
    • Рекомендации по использованию диаграммы деятельности для моделирования поведения артефакта
    • Шаблон спецификации прецедента[3]
    • Контрольный лист для оценки качества артефакта

    Что мы описываем?

    Практически все элементы UML характеризуются дихотомиями типа класс/объект, статическая структура/динамическое поведение и т.д.

    Прецедент (модельный элемент Use Case) характеризуется, в частности, дихотомией внешнее поведение/реализация[4].

    Говоря о прецедентах, системные аналитики имеют в виду только внешнее поведение. Такой подход имеет, как минимум, две причины:

    • Только о внешнем поведении говорится в классическом определении прецедента
    • Роль системного аналитика состоит в определении требований к системе, т.е. тоже к внешнему ее поведению.

    И именно описанию внешнего поведения прецедентов посвящена эта статья[5]

    Предпосылки

    В этой статье (и во всем цикле) мы предполагаем, что системный аналитик – это единственная роль, которая определяет требования к системе. Требования сформулированы так, что:

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

    Сравнение способов моделирования

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

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

    • Диаграмма состояний

    Поведение прецедента естественнее всего формулировать в терминах действий, выполняемых системой в ответ на действия субъекта (Actor)[6]. А диаграмма состояний акцентируется на возможных состояниях классификатора (прецедента), и на переходах его из состояния в состояние в ответ на события. Эти события генерируются, в частности, действиями, доступными в состоянии.

    На мой взгляд, диаграмма состояний неудобна для моделирования внешнего поведения прецедента.

    • Диаграмма деятельности

    Диаграмма деятельности – это граф действий. Она предназначена специально для моделирования рабочих потоков. Она легко понимается даже незнакомым с UML читателем.

    Некоторые специалисты считают, что диаграмму деятельности не следует применять в моделировании прецедентов, т.к. она не соответствует объектно-ориентированному подходу[7], и ее элементы не отображаются в объекты будущей системы.

    Не хочется вдаваться в полемику, но задам вопрос: "Насколько структурированное текстовое описание ближе к объектно-ориентированному подходу, чем диаграмма деятельности?".

    Что касается отображения элементов деятельности в элементы системы, то, наверное, этому можно посвятить отдельную статью. Пишите, если Вам это интересно!

    • Диаграмма последовательности

    Эта диаграмма представляет взаимодействия объектов путем обмена сообщениями. Каждое сообщение инициирует запуск действия (операции) объекта. Хотя диаграмма последовательности позволяет наглядно представить поведение несложного рабочего потока, это ее качество резко падает с появлением необходимости отображать логику, циклы и т.д.

    Для борьбы со сложностью можно вместо диаграммы полного рабочего потока представлять множество диаграмм (для каждого возможного сценария выполнения прецедента). Но тогда общая картина поведения становится еще менее наглядной.

    Тем не менее, некоторые считают эту диаграмму более достойной (более правильной, т.к. она уж точно объектно-ориентированная!). Но прецедент описывает взаимодействие всего двух объектов: внешнего субъекта и системы. Некоторые не знают, но субъект (actor) в UML не может иметь операций, а значит, не может принимать сообщения (кроме возвратных)[8]. А это существенно ограничивает возможность моделирования взаимодействий.

    ·        Диаграмма коммуникаций

    Эта разновидность диаграммы взаимодействия не имеет средств отображения логики рабочего потока.

    Диаграмма деятельности – это выбор RUP. Диаграмма деятельности – это и мой выбор.

    Мой опыт моделирования прецедентов

    Соображения о полезности использования при моделировании "строительных блоков" и о необходимости (особенно, при групповой работе) руководствоваться неким общим стандартом моделирования, я изложил в первой статье цикла.

    Строительные блоки для модели прецедентов (веб-публикация модели) представлены в приложении к первой статье.

    Пример указаний по моделированию прецедентов – в приложении к предыдущей статье.[9]

    Мы продолжим рассматривать пример модели прецедентов для проекта "Система управления оказанием услуг".

    Один прецедент ("Прием заявки") мы рассмотрим более подробно. Вот как выглядит структура описания прецедента в Project Explorer рабочего окна RSA:

     

    А вот как выглядит контекстная диаграмма для этого прецедента:

     

    Обратите внимание: кроме привычных модельных элементов на диаграмму прецедентов помещен элемент URL. Это ссылка. Двойное нажатие откроет MS Word со спецификацией прецедента[10].

    Хорошей практикой моделирование является краткое описание модельных элементов UML. Прецедент "Прием заявки имеет следующее описание:

    С началом регистрации заявка устанавливается в состояние "Инициирована".

    Автоматически отображаются:

    - дата и время регистрации

    - идентификатор регистратора

    - текущее состояние заявки

    При регистрации фиксируются:

    - название и контактные данные клиента

    - тип услуги

    - название и характеристики объекта услуги

    - скан-копии представленных документов

    - текстовый комментарий

    Регистрация может выполняться частями в нескольких последовательных сеансах.

    В ходе регистрации процесс может быть завершен по инициативе клиента или регистратора (с указанием причины). В этих случаях Заявка переходит в состояние "Отклонена".

    При успешном завершении регистрации Заявка переходит в состояние "Зарегистрирована".

    Если регистратор имеет права руководителя работ, Заявка может быть сохранена в состоянии "Принята".

    На следующей диаграмме представлено графическое описание рабочего потока прецедента:

     

    (нажать для увеличения)

    Для всех модельных элементов диаграммы (кроме узлов управления) я печатаю описания.

    • В описании начального узла я печатаю все предусловия для деятельности прецедента[11]
    • В описаниях конечных узлов я печатаю описания постусловий, например (для узла "Прекращен"):

    Завершение прецедента баз сохранения информации.

    Отображается главное окно системы.

    • В узлах действий я делаю краткие описания действий субъекта и системы, которые являются требованиями для разработчика, хотя грамматически они выражены в повествовательной форме. Например, фраза "Система инициализирует новую заявку клиента" (действие "Инициализация заявки") является требованием к разработчику, что в данной ситуации "система должна инициализировать заявку".

    Если за узлом действия следует узел решения, я описываю возможные альтернативы в узле действия. Например (действие "Выбор продолжения"):

    Регистратор использует средства управления для выбора способа продолжения:

    - создание новой заявки клиента

    - продолжение регистрации существующей заявки клиента в состоянии "Инициирована".

    - завершение прецедента без сохранения промежуточных результатов.

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

    В ином случае, делаю обычное краткое описание. Например (действие "Заполнение формы")[12]:

    Вызываемое поведение.

    Регистратор заполняет области и поля формы.

    Заполнение формы может выполняться в нескольких сеансах. Области формы можно заполнять в произвольном порядке.

    В процессе заполнения регистратор может:

    - зарегистрировать отмену заявки клиентом (заявке присваивается состояние "Отклонена")

    - отказать клиенту в выполнении заявки (заявке присваивается состояние "Отклонена")

    - временно отложить регистрацию (состояние заявки не изменяется)

    - завершить регистрацию и принять заявку клиента к исполнению (заявке присваивается состояние "Зарегистрирована")

    - (только регистратор с правами руководителя) принять заявку для дальнейшей работы (заявке присваивается состояние "Принята")

    При выполнении перечисленных действий информация заявки сохраняется и прецедент завершается.

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

    Вызываемое поведение в диаграммах деятельности используется в следующих целях:

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

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

    Многие аналитики забывают, что прецеденты используются не только для описания требований, но и для планирования итерационного инкрементного процесса разработки проекта:

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

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

    Двойное нажатие на элемент (в RSA, и, думаю, в большинстве других инструментов моделирования) откроет следующую диаграмму:

     

    (нажать для увеличения)

    Эта деятельность имеет параметры.

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

    Заключение

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

    Некоторые считают, что заказчики не знакомы с UML и не поймут картинки с "телепузиками". Категорически не согласен! Когда нужно объяснить что-то сложное, многие рисуют схемы, графики и т.д., и прекрасно понимают друг друга.

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

    И тут мне в голову закралась крамольная мысль: "А может быть некоторые аналитики не хотят моделировать потому, что не умеют?".

    Так давайте учиться!



    [1] Буч Г., Якобсон А., Рамбо Дж. UML. Классика CS. 2-е изд./ Пер. с англ. – СПб.: Питер, 2006. Стр. 689.

    [2] Не рекомендую использовать официальную русскую версию RUP (пока!). Перевод плохой. Например, одни и те же понятия обозначаются разными терминами.

    [3] Шаблон RUP Спецификация прецедента.dot на русском языке (перевод мой) представлен в приложении к этой статье. Он, как всегда, очень подробный и разработан "на все случаи жизни". Очень советую посмотреть. Конечно, он требует адаптации к вашим условиям.

    [4] В RUP есть два модельных элемента для отображения этой дихотомии: собственно прецедент (элемент Use Case в модели прецедентов) и реализация прецедента (кооперация со стереотипом Use Case Realization в модели анализа).

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

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

    [6] Это утверждение непосредственно следует из определения прецедента.

    [7] Ее структура и семантика основаны на свободной интерпретации сетей Петри.

    [8] Инструменты моделирования, которые строго выдерживают метамодель UML, физически не позволяют создать сообщение субъекту.

    [9] Хочу еще раз напомнить, что "строительные блоки", указания по моделированию и шаблоны отчетов (в том числе – шаблоны SoDA) я представляю как примеры. Они могут использоваться непосредственно. Но правил, независимых от ситуации, не бывает, иначе они неэффективны и "обходятся" при первом удобном случае! RUP предусматривает ревизии и настройки указаний и шаблонов для каждого проекта в дисциплине "Среда".

    [10] Вы можете попробовать сделать это, если скопируете приложение и откроете веб-публикацию модели. Интерфейс веб-публикации не совпадает с интерфейсом RSA, но обеспечивает все те же возможности.

    [11] Не могу удержаться и не съехидничать по поводу дискуссии на UML2: это не предусловия прецедента, а предусловия для его деятельности!

    [12] По желанию владельцев проекта я удалил диаграмму, детализирующую это действие. Из приведенного описания понятно, что на диаграмме были представлены параллельные потоки по числу заполняемых полей (простым вводом, с использованием перечислений или справочников). Прошу извинить!

    Категория: Повышение производительности аналитика | Добавил: lnew (25.08.2011)
    Просмотров: 2111 | Комментарии: 9 | Рейтинг: 0.0/0
    Всего комментариев: 9
    3  
    А разве перерыв в прецеденте автоматически не означает два разных прецедента? пусть и с тем же результатом. Предусловия то разные. А мы помним - начало всегда одно.

    Про аутентификацию - я бы указал это в предусловии. Но это мое имо. Вы имеете право делать как Вам хочется. Но для меня это ВКЛЮЧЕНИЕ всего прецедента раз за разом.

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

    4  
    Добрый вечер.
    Первый вопрос я не понял. Какой перерыв в прецеденте?
    Второй вопрос отражает фактически принятую реализацию в компании: вызов всегда выполняет проверку, т.е. проверка всегда выполняется внутри.
    Третий вопрос: я использую цель пользователя (отглагольное существительное в именительном падеже единственного числа). Знакомый лингвист рассказал, что так принято определять цель в русском языке. В отличие, например, от английского, где цель принято определять неопределенной формой глагола.
    В бизнес-моделировании я договариваюсь с бизнесом. Чаще всего - это цель бизнеса (по тем же грамматическим правилам).
    Спасибо.

    6  
    Что для Вас означает цель пользователя?
    Когда Вы договариваетесь (по цели бизнеса) - как это выглядит и к кому привязывается вариант использования?

    Спасибо

    9  
    У меня ошибка (описка) закралась. Имеется ввиду цель субъекта (actor).
    В бизнес-моделировании - это цель первичного бизнес-субъекта.
    Когда я договариваюсь с заказчиком о терминах, я стараюсь договориться о следующих правилах именования прецедентов:
    - для системных: краткое выражение цели субъекта (фактически - пользователя), например, "Прием заявки" (или, регистрация, как больше нравится).
    - для бизнес-процесса: антоним цели бизнес-субъекта. Заказчик (business actor) имеет цель получить от бизнеса услугу. Именование с точки зрения бизнеса ("Оказание услуги" (антоним от "получения услуги") для бизнеса естественнее).
    Бизнес-субъектом бизнес-процесса "Оказание услуги" (в RUP - синоним понятия "бизнес-прецедент") является "Клиент".

    5  
    Я понял, о чем речь!
    Конечно, продолжение приема заявки - это новый экземпляр прецедента. Пользователь может начать, прервать и продолжить несколько разных заявок. Вы, наверное, скачали приложение и прочитали спецификацию прецедента? Или посмотрели саму модель? Там сформулировано предусловие.

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

    8  
    Извините за задержку!
    Предусловия к прецеденту я рассматриваю как логическое выражение, которое может содержать "и", "или", "исключающее или". Естественно, описание рабочего потока (я использую диаграмму деятельности) может содержать логику обработку "или".
    Т.о., различных предусловий для разных экземпляров я не вижу.
    Преимущество очевидно: сокращение численности прецедентов ("Прием заявки" вместо набора "Создание", "Редактирование" и т.д.).

    2  
    Об этом можно много рассуждать. У нас есть только спецификация UML, которая однозначного ответа не дает. Все, что кроме спецификации, это личное мнение, даже, если это мнение "отцов-основателей".
    Как я это понимаю:
    Абстрактный прецедент потому и абстрактный, что он не имеет собственных экземпляров. К нему пользователь не обращается для достижения своей цели. Это всего лишь существенное поведение прецедента, которое, по каким то соображениям, выделяется как самостоятельный "модуль" поведения.
    Прецедент включения выделяется, т.к. он является многократно используемым. Если этот "кусок" многократно используемый, но, с т.з. разработки не существенный, выделять его нет смысла.
    Прецедент расширения - это архитектурно существенное поведение, которое выполняется по условию "редко", его реализацию можно планировать отдельно от основного: система, некоторое время, не будет иметь некоторой функциональности.
    Еще одно соображение.
    Прецедент может быть абстрактным "по конструкции" (он не может выполняться как самостоятельный для реализации цели пользователя, не имеет соответствующего интерфейса и т.п.) и "в контексте" (он может выполняться и самостоятельно, и как часть основного прецедента).
    На диаграммах прецедентов абстрактность прецедента включения и расширения показывается только с помощью отношений. О "курсиве" в имени я никогда не задумывался. В примерах курсив используется в обобщении, если набор потомков охватывает все возможности предка. А в расширении и включении это и так понятно!
    Почему каждый раз аутентификация/авторизация?
    Данное приложение разрабатывалось как веб. Есть части, доступные для всех, есть санкционированный доступ. Некоторые прецеденты доступны не для всех.
    Когда пользователь "входит" на сайт, он может зарегистрироваться, а может и нет. Операции (прецеденты), требующие разрешения, проверяют, зарегистрировался или нет. Если да, проверяют, есть право или нет.
    Я должен сказать разработчикам, что этот конкретный прецедент требует проверки права доступа.
    Мне кажется, Вы не прочитали спецификации прецедентов, которые в приложении. Выбор заявки происходит "после перерыва", и инициализация только для новой заявки.
    В приложении - два примера прецедентов. И все становится понятным.
    Спасибо.

    1  
    Добрый вечер.
    Вопрос по контекстной диаграмме. Насколько я понимаю, это диаграмма передает контекст системного прецедента. Системность придается прецедентами авторизация и выбор заявки (ни то, ни другое не является целью пользователя) и представляют собой абстрактные прецеденты. Если они абстрактны, то почему не передаются с помощью стереотипов или курсива? Или это не обязательно.
    Далее у меня как у разработчика при виде такой диаграммы сразу возникает вопрос: зачем при каждом приеме заявки требуется аутентификация (авторизация)
    Не совсем понятно почему всегда происходит Выбор заявки (причем на диаграмме деятельности - это условный переход, а не безусловный), при этом почему Инициализации заявки - осталась простым действием, а Выбор - прецедентом

    Спасибо

    Имя *:
    Email *:
    Код *: