Форма входа

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

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

Поиск

Наш опрос

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

Друзья сайта

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


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

    Я - Аналитик!

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

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

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

    Информация для разработчиков

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

    Заказчик и разработчик по-разному видят будущую систему.

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

      Аналитик должен преобразовать информацию о потребностях заказчика в модели и документы требований, понятные заказчику: Техническое задание или Видение, Спецификации прецедентов и Дополнительные спецификации (для итерационной инкрементной разработки).

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

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

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

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

    Модель анализа

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

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

    Для моделирования анализа можно использовать профиль UML "RUPAnalysis". Но это не обязательно: вместо стереотипов анализа можно использовать ключевые слова.

    Класс анализа – это ранняя концептуальная модель "вещи в системе, которая имеет обязанности и поведение". Стереотипы классов анализа:

    Граничный класс
    Моделирует взаимодействие между средой системы и ее внутренним содержанием. Взаимодействие включает преобразование внешних событий и данных во внутрисистемное представление и обратно.

       Класс контроллер

    Моделирует управление поведением, определенным для одного или нескольких прецедентов. Объекты контроллеры (экземпляры класса) управляют другими объектами так, что их поведение имеет тип координирования.

      Класс сущность
    Моделирует информацию и связанное поведение, которое должно быть сохранено. Объекты сущности (экземпляры класса) используются для хранения и модифицирования информации о некотором явлении (событии или объекте реального мира). Они обычно стабильны, имеют атрибуты и отношения, необходимые в течение некоторого периода, иногда – жизненного цикла системы.

    Модель анализа – это одна из моделей набора моделей MDA[1].

     

    В технологии RUP модель анализа может быть временным артефактом или вообще не разрабатываться.

    Использование модели анализа для представления информации разработчику

    Аналитики, использующие преимущественно второй подход к документированию требований (см. выше), часто используют для представления детальной информации о процессах и данных заказчика т.н. "раскадровки"[2]

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

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

    • Трудоемкость поддержки в актуальном состоянии при необходимости изменения требований.

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

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

      Проектировщик анализирует текстовое описание и преобразует его в нужные проектные модели и код.
    • Косвенное ограничение творческих возможностей разработчика.

      Хотя артефакт "раскадровка" не рассматривается как документ требований, картинки интерфейса, представленные аналитиком, влияют на решения проектировщика.

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

    Концепция MDA предполагает (см. рисунок выше), что ответственным за создание и поддержку модели анализа является архитектор/проектировщик[3].

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

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

    Пример использования модели анализа

    Я начинаю работу над проектом с создания типовой структуры модели. Для этого я использую строительные блоки "Бизнес-модель", "Модель прецедентов" и "Модель анализа"[5].

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

    • В процессе осмысления бизнеса моделируются бизнес-процессы и действия участников бизнеса. Действия, выполняемые с использованием ПО – это прецеденты, которые я создаю и описываю в модели прецедентов.

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

    • При моделировании прецедента необходимо описать последовательность взаимодействий субъекта с системой. Взаимодействия с субъектом-человеком осуществляется с помощью GUI. Я моделирую требования к GUI в модели анализа следующим образом:
    • Логические группировки средств GUI (окна, веб-страницы, области окон и страниц и т.д.) – это граничные классы
    • Средства ввода и отображения информации (поля ввода, выпадающие списки и т.д.) – это атрибуты соответствующих граничных классов
    • Средства выбора действий продолжения (кнопки, гиперссылки и т.д.) – это операции граничных классов

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

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

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

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

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

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

    Интерфейс прецедента должен формироваться динамически в ответ на действия пользователя.

    - Выбор "Новая заявка" открывает форму приема заявки. Строка состояния заполнена служебной информацией. Ниже в форме размещается область информации клиента (общая часть) и информация объекта. Область контактного лица показывается после информации объекта. Последней показывается область приложений.

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

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

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

    Пользователь может:

    - Выбрать клиента из списка. Форма заполняется информацией клиента.

    - Отобразить полный список всех контрагентов и выбрать клиента из этого списка.

    - Заполнить поля области контрагента вручную и добавить клиента в справочник.

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

    Заполнение информации контактного лица выполняется аналогично тому, как это делается для клиента.

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

    Перечисления, используемые в реализации прецедента "Прием заявки"[6]:


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

    Примечание 1. Этот же способ моделирования может использоваться и для описания взаимодействия с субъектом-системой.

    Примечание 2. Обратите внимание, что граничные классы не могут иметь статических отношений с классами-сущностями. Ведь экземпляры граничных классов (как и контроллеров) существуют только во время выполнения!
    Для проектировщика (формальное нарушение) я рисую зависимости на диаграмме "Классы – участники прецедента <название>" от граничного класса к сущностям, содержащим соответствующую информацию.
    Динамические связи отображаются (проектировщиком) в виде сообщений на диаграммах последовательности.

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

    Вместо заключения

    Немного статистики

    Перефразируя известное выражение, можно сказать: "Аналитик – это не должность. Аналитик – это диагноз!"

    14 июля я опубликовал на сайте первую статью цикла "Повышение производительности аналитика". Всего опубликовано 6 выпусков (этот - седьмой). Предыдущий – 25 августа. Пора выполнить анализ![7]

    В таблице ниже представлена статистика просмотров и скачиваний:

    Выпуск

    Дата публикации

    Просмотры

    Скачивания

    1

    14.07.11

    817

    15

    2

    25.07.11

    203

    12

    3

    30.07.11

    128

    7

    4

    13.08.11

    185

    7

    5

    19.08.11

    73

    5

    6

    25.08.11

    107

    5

     

    29 августа я обратился к читателям с просьбой ответить на ряд вопросов. Я надеялся, что ответы помогут выявить интересы читателей и скорректировать направление дальнейшей работы над статьями.

    В опросе приняли участие 8 человек! Только два человека оценили полезность содержащейся в статьях информации.

    Статистика, надо признать, удручающая!

    Я не буду описывать свою работу над ошибками. Перейду сразу к результатам:

    1.      Не оправдавшиеся ожидания.

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

    2.      Читателей интересует не столько практический опыт, сколько рассуждения об опыте.

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

    Вывод:

    Продолжение публикации статей цикла "Повышение производительности аналитика" не имеет смысла: они не нашли своего читателя!

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

    Язык и технология

    "Если у вас есть молоток, это еще не значит, что Вы – архитектор."

    Английская поговорка

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

    Всегда ли это утверждение истинно? Конечно! Но…

    "Человеческие существа не общаются непосредственно с объективным миром и с обществом в том смысле, как это обычно понимается. Они в значительной мере зависят от того конкретного языка, который стал их средой общения. Это совершенная иллюзия – полагать, что кто-то может согласовать себя с сущностью реальности без использования языка, и что язык – всего лишь случайное средство решения конкретных задач общения и мышления. Суть вопроса в том, что "реальный мир" в значительной степени неосознанно строится на языковых привычках группы людей… Мы видим, слышим и испытываем остальные ощущения так, как мы это делаем, в значительной степени потому, что языковые обычаи нашего общества предрасполагают к определенному выбору способа интерпретации".

    Эдвард Сапир[8]

    Цитата подчеркивает, что язык, на котором мы говорим, непосредственно влияет на способ восприятия мира (мышление). Это утверждение тем более справедливо для искусственных языков (для нашей аудитории – языков программирования и моделирования).

    Размышления в этом направлении приводят к выводу, что язык влияет на технологию и даже, иногда, (крамольная мысль!) на проектные решения.[9]

    Мой опыт общения с аналитиками (начинающими и уже зрелыми) свидетельствует, что многие из них пренебрегает возможностями мышления на языке моделирования. Т.к. во многих организациях UML является стандартом представления проектной информации, они "переводят" результаты своих изысканий на UML[10]. Для этих людей моделирование – это бесполезная дополнительная нагрузка, или, в крайнем случае, выполняет презентационные функции.

    Для этих людей UML – это иностранный язык! Увы!

    Благодарю читателей. Цикл завершен!



    [1] См. раздел "Модель первична, документ – вторичен" в первой статье цикла.

    Обратите внимание, что "Бизнес-модель" (полное название: "Модель, независимая от вычислений"), показанная на иллюстрации, заимствованной из документации OMG, представляет три модели RUP: "Модель бизнес-прецедентов", "Модель анализа бизнеса" и "Модель прецедентов".  

    [2] Раскадровка (Storyboard) – это широко известная техника в кино и на телевидении, откуда сообщество разработчиков ПО заимствовало термин. Раскадровка позволяет оживить текстовый сценарий (в частности, прецедента), визуально проиллюстрировав требования. Это м.б. черновой набросок пользовательского интерфейса, позволяющий наглядно описать взаимодействие пользователя с системой. В предыдущих версиях RUP артефакт "раскадровка" рекомендовалось выполнять по шаблону документа "спецификация прецедента" и включать ремарки, содержащие детализацию требований (номенклатура и объем хранимой информации, время отклика на действия пользователя и т.п.). RUP содержал рекомендации по оформлению ремарок для различных типов дополнительной информации.

    Хотя раскадровки выполняются системным аналитиком, они не рассматриваются как официальные требования заказчика.

    [3] В RUP за модель анализа отвечает проектировщик.

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

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

    [6] Это промежуточная рабочая версия диаграммы, содержащая комментарии и, даже, обращения к участникам проекта.

    [7] Я начал писать это Заключение в начале сентября!

    [8] Цитировано по книге: Тимоти Бадд, Объектно-ориентированное программирование в действии, СПб, "Питер", 1997.

    [9] В программировании это не подлежит сомнению!

    [10] Как я перевожу с английского на русский. Обратно я даже не пытаюсь!

    Категория: Повышение производительности аналитика | Добавил: lnew (03.11.2011)
    Просмотров: 1940 | Комментарии: 6 | Рейтинг: 0.0/0
    Всего комментариев: 6
    5  
    Спасибо!

    P.S.: Жаль, что завершен, отличные статьи.

    6  
    Спасибо на добром слове!
    Скучно писать "в никуда". Потому и завершено.

    1  
    Хорошая статья, Леонид Борисович!

    Нашел ошибку
    функциональные и не функциональные требования
    нефункциональные пишется все-таки вместе, тут нет противопоставления, это два непересекающихся множества.

    Не отчаивайтесь о полезности или бесполезности. Факты таковы, что читать длинные статьи мало, кто будет. К тому же опыт ваш сильно завязан на Rational. Статьи были интересные и полезные. Правда, беда в том (как мне кажется), что не виден точный и ясный конечный результат. Понимаете, это как описывать варку супа, рассказав лишь о правилах подготовки ингредиентов перед закладкой их в кастрюлю.

    Рекламируйте свой опыт. Призываю Вас на конференцию objectsystems.ru или в журналы

    СПАСИБО

    2  
    Приятно, когда находят ошибки. Значит, читают.
    Что касается конференции, то для безработного участие дороговато. Увы!
    Спасибо. smile

    3  
    могу предложить соавторство

    4  
    Выбирайте!
    Но, наверное, такие вопросы неудобно обсуждать в общедоступных комментариях.
    lnew@yandex.ru

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