WikiDer > Подход фреймов проблемы

Problem frames approach

Анализ проблемы или подход рамок проблем подход к программному обеспечению анализ требований. Он был разработан британским консультантом по программному обеспечению. Майкл А. Джексон в 1990-е гг.

История

Подход проблемных фреймов был впервые описан Джексоном в его книге. Требования и спецификации программного обеспечения (1995) и в ряде статей в различных журналах, посвященных программной инженерии. Наиболее полное описание он получил в его Рамки проблем: анализ и структурирование проблем разработки программного обеспечения (2001).

Сессия по проблемным рамкам была частью 9-го Международного семинара по разработке требований: основа качества программного обеспечения (REFSQ)], который проходил в Клагенфурте / Фельдене, Австрия, в 2003 году.[1] Первый международный семинар по приложениям и достижениям в фреймах задач[2] проходила в рамках ICSE’04 в Эдинбурге, Шотландия. Одним из результатов этого семинара стал специальный выпуск 2005 года о проблемных рамках в Международный журнал информационных и программных технологий.

Второй международный семинар по приложениям и достижениям в фреймах задач[3] проходил в рамках ICSE 2006 в Шанхае, Китай. Третий международный семинар по приложениям и достижениям в проблемных фреймах (IWAAPF)[4] проходил в рамках ICSE 2008 в Лейпциге, Германия. В 2010 году семинары IWAAPF были заменены Международным семинаром по приложениям и достижениям в решении проблем (IWAAPO). IWAAPO расширяет тематику семинаров, чтобы включить альтернативные и дополнительные подходы к разработке программного обеспечения, которые разделяют акцент на анализе проблем.[5] IWAAPO-2010 проводился в рамках ICSE 2010 в Кейптауне, ЮАР.[6]

Сегодня исследования подхода к проблемным фреймворкам проводятся в ряде университетов, в первую очередь в Открытый университет в Соединенном Королевстве в рамках своей Связь проблем и структур решения тема исследования[7][8]

Идеи подхода проблемных фреймов были обобщены в концепции проблемно-ориентированное развитие (POD) и проблемно-ориентированная инженерия (POE), из которых проблемно-ориентированная разработка программного обеспечения (POSE) - это особая подкатегория. Первый Международный семинар по проблемно-ориентированному развитию состоялся в июне 2009 года.

Обзор

Фундаментальная философия

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

  • Лучший способ приблизиться к анализу требований - это процесс параллельной, а не иерархической декомпозиции требований пользователей.[9]
  • Требования пользователей касаются отношений в реальном мире - домен приложения - не о программной системе или даже об интерфейсе с программной системой.

Более полезно ... признать, что решение находится в компьютере и его программном обеспечении, а проблема - во внешнем мире ... Компьютеры могут предоставить решения этих проблем, потому что они связаны с внешним миром.[10]

Мораль ясна: чтобы изучить и проанализировать проблему, вы должны сосредоточиться на изучении и анализе проблемного мира на некоторой глубине, а в своих исследованиях вы должны быть готовы отойти на некоторое расстояние от компьютера. ... [Проблема с переадресацией звонков ...] Вам нужно описать, что там - люди, офисы, праздники, переезд офиса и делегирование ответственности - и какие эффекты [в проблемном мире]вы хотите, чтобы система работала - звонки на номер A должны доходить до A, и [когда B в отпуске, а C временно работает за столом D] звонки на номера B или C должны доходить до C.[11]

Ничего из этого не появляется в интерфейсе с компьютером ... Они гораздо глубже этого мира.[12]

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

Инструменты для описания конкретных проблем

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

Графические инструменты для описания проблем - это контекстная диаграмма и диаграмма проблем.

Инструменты для описания классов проблем (проблемных рамок)

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

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

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

Список распознанных классов проблем (проблемные рамки)

Первая группа проблемных рамок, определенных Джексоном, включала:

  1. требуемое поведение
  2. управляемое поведение
  3. информационный дисплей
  4. простые заготовки
  5. трансформация

Впоследствии другие исследователи описали или предложили дополнительные рамки проблемы.

Описание проблем

Контекст проблемы

Анализ проблемы рассматривает программное приложение как разновидность программного обеспечения. машина. Проект разработки программного обеспечения направлен на изменение контекста проблемы путем создания программного обеспечения и добавления его в контекст проблемы, где это приведет к определенным желаемым эффектам.

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

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

ProblemFramesProblemContext1.svg

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

Та же самая ситуация может быть показана на диаграмме другого типа: контекстная диаграмма, Сюда:

ProblemFramesProblemContext2.png

Контекстная диаграмма

Первая задача проблемного аналитика - по-настоящему понять проблему. Это означает понимание контекста, в котором ставится проблема. А это значит рисовать контекстная диаграмма.

Вот описание Джексоном исследования контекста проблемы, в данном случае контекста для строительства моста:

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

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

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

ProblemFramesContextDiagram1.svg

Эта диаграмма показывает:

  • в машина быть построенным. Темная рамка помогает идентифицировать прямоугольник, представляющий Машину.
  • в проблемные области которые имеют отношение к проблеме.
  • сплошные линии представляют доменные интерфейсы - области, где области пересекаются и имеют общие явления.

Домен - это просто часть мира, которая нам интересна. Он состоит из явления - люди, события, положение дел, отношения и поведение.

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

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

На следующей диаграмме X - это интерфейс между доменами A и B. Лица, которые существуют или события, которые происходят в X, существуют или происходят как в A, так и в B.

ProblemFramesInterfaces.svg

Общие лица, состояния и события могут отличаться от общих доменов. Рассмотрим, например, интерфейс между компьютером и клавиатурой. Когда домен клавиатуры видит событие Оператор клавиатуры нажимает пробел компьютер увидит то же событие, что и Во входном буфере появляется шестнадцатеричный байт («20»).

Диаграммы проблем

Основным инструментом аналитика проблемы для описания проблемы является диаграмма проблем. Вот общая диаграмма проблемы.

ProblemFramesProblemDiagram1.svg

В дополнение к тому, что показано на контекстной диаграмме, диаграмма проблем показывает:

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

Интерфейс, который соединяет проблемный домен с машиной, называется интерфейс спецификации и явления в интерфейсе спецификации называются явления спецификации. Задача специалиста по анализу требований - разработать спецификацию поведения, которое Машина должна демонстрировать в интерфейсе машины, чтобы удовлетворить требование.

Вот пример реальной, пусть и простой, диаграммы проблемы.

ProblemFramesProblemDiagram2.png

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

Название требования - «Показать ~ Состояние пациента». Тильда (~) указывает, что требование касается взаимосвязи или соответствия между дисплеем панели и состоянием пациента. Стрелка указывает, что ссылка на требование, связанная с доменом отображения панели, также является ограничением требования. Это означает, что требование содержит какое-то условие, которому должен соответствовать дисплей Panel. Короче говоря, требуется, чтобы На панельном дисплее должна отображаться информация, которая соответствует и точно сообщает о состоянии пациентов.

Описание классов проблем

Проблемные кадры

А рамка проблемы - это описание узнаваемого класса проблем, для которого существует известное решение. В некотором смысле проблемные рамки - это шаблоны проблем.

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

Варианты рамы

В Рамки для проблем Джексон обсудил варианты пяти выявленных им основных проблемных рамок. Вариант обычно добавляет домен в контекст проблемы.

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

Проблемы, связанные с проблемами

Джексон также обсуждает некоторые виды проблем, возникающих при работе с проблемными фреймами.

Особые опасения

  • набегать
  • инициализация
  • надежность
  • идентичности
  • полнота

Композиция касается

  • соизмеримые описания
  • последовательность
  • приоритет
  • вмешательство
  • синхронизация

Распознанные проблемные кадры

Первые проблемные кадры, идентифицированные Джексоном, включали:

  1. требуемое поведение
  2. управляемое поведение
  3. информационный дисплей
  4. простые заготовки
  5. трансформация

Впоследствии другие исследователи описали или предложили дополнительные рамки проблемы.

Фрейм проблемы требуемого поведения

Интуитивная идея, лежащая в основе этой проблемы, такова:

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

Фрейм задачи командного поведения

Интуитивная идея, лежащая в основе этой проблемы, такова:

  • Есть некоторая часть физического мира, поведение которой должно контролироваться в соответствии с командами, подаваемыми оператором. Проблема состоит в том, чтобы построить машину, которая будет принимать команды оператора и соответственно вводить управление.
ProblemFramesCommandedBehaviorFrame.svg

Рамка проблемы отображения информации

Интуитивная идея, лежащая в основе этой проблемы, такова:

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

Рамка для простых заготовок

Интуитивная идея, лежащая в основе этой проблемы, такова:

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

Рамка проблемы трансформации

Интуитивная идея, лежащая в основе этой проблемы, такова:

  • Есть некоторые заданные машиночитаемые входные файлы, данные которых необходимо преобразовать, чтобы получить определенные требуемые выходные файлы. Выходные данные должны быть в определенном формате, и они должны быть получены из входных данных в соответствии с определенными правилами. Проблема состоит в том, чтобы построить машину, которая будет производить требуемые выходные данные из входных данных.
ProblemFramesTransformationFrame.svg

Анализ проблем и процесс разработки программного обеспечения

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

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

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

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

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

Подобные подходы

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

  • Понятие о шаблон дизайна похоже на представление Джексона о фрейме проблемы. Он отличается тем, что шаблон проектирования используется для распознавания и обработки проблем проектирования (часто проблем проектирования в конкретных объектно-ориентированных языках программирования, таких как C ++ или Java), а не для распознавания и обработки проблем требований. Кроме того, одно отличие состоит в том, что шаблоны проектирования охватывают решения в то время как в проблемных кадрах проблемы представлены. Однако шаблоны проектирования также имеют тенденцию учитывать семантические результаты, которые не являются родными для языка программирования, в котором они должны быть реализованы. Итак, еще одно отличие состоит в том, что проблемные кадры являются родной мета-нотацией для области проблем, тогда как шаблоны проектирования представляют собой каталог технического долга, оставленного разработчиками языка.
  • Аспектно-ориентированное программирование, АОП (также известный как аспектно-ориентированная разработка программного обеспечения, AOSD) аналогичным образом заинтересован в параллельной декомпозиции, которая обращается к тому, что сторонники АОП называют сквозные проблемы или же аспекты. АОП решает проблемы, которые гораздо ближе к этапу проектирования и генерации кода, чем к этапу анализа требований.
  • АОП переместилось в нотацию инженерных требований, такую ​​как нотация требований пользователя (URN) ITU-T Z.151. В URN АОП стоит над всеми намеренными элементами. АОП также может применяться к моделированию требований, которое использует проблемные кадры в качестве эвристики. Модели URN, основанные на мышлении проблемных рамок и перемежающиеся с аспектами, позволяют включить архитектурную тактику в модель требований.
  • Книга Мартина Фаулера Шаблоны анализа очень похож на анализ проблем в поиске закономерностей. Однако на самом деле он не представляет нового метода анализа требований. И понятие параллельной декомпозиции, которое так важно для анализа проблем, не входит в структуру анализа Фаулера.
  • Джон Дж. Холл, Люсия Рапанотти вместе с Джексоном разработали фреймворк проблемно-ориентированной программной инженерии (POSE).[13] который разделяет проблемные основы основы. С 2005 года Холл и Рапанотти расширили POSE на проблемно-ориентированное проектирование (POE), которое обеспечивает основу для инженерного проектирования, включая модель процесса разработки и проектирование, основанное на гарантиях.[14] и может быть масштабируемым для проектов, которые включают множество заинтересованных сторон и сочетают различные инженерные дисциплины, такие как программное обеспечение и предоставление образования.[15]

Рекомендации

  1. ^ 9-й международный семинар по разработке требований: фундамент качества программного обеспечения (REFSQ) проходил в Клагенфурте / Фельдене, Австрия, в 2003 году.
  2. ^ Первый международный семинар по приложениям и достижениям в фреймах задач
  3. ^ Второй международный семинар по приложениям и достижениям в фреймах проблем В архиве 2007-08-19 на Wayback Machine
  4. ^ «Третий международный семинар по применению и развитию проблемных фреймов». Архивировано из оригинал 24 декабря 2010 г.. Получено 2010-06-19.
  5. ^ Международный семинар по применению и развитию проблемно-ориентированного подхода В архиве 2011-01-11 на Wayback Machine
  6. ^ «ИВААПО-2010». Архивировано из оригинал на 2010-01-28. Получено 2010-06-19.
  7. ^ Связь проблем и структур решения тема исследования.
  8. ^ Например: «Связь требований к программному обеспечению и архитектур с использованием проблемных рамок» Холла, Дж. Дж .; Джексон, М .; Laney, R.C .; Nuseibeh, B .; Rapanotti, L., в Труды совместной международной конференции IEEE по разработке требований (2002), стр. 137–144.
  9. ^ Джексон, Майкл (1995). «Декомпозиция задачи для повторного использования». С. 1, 2.
  10. ^ Джексон, Майкл (2001). Рамки для проблем. Эддисон-Уэсли. С. 3, 4.
  11. ^ Джексон, Майкл (2001). Рамки для проблем. Эддисон-Уэсли. п. 9.
  12. ^ Джексон, Майкл (2001). Рамки для проблем. Эддисон-Уэсли. С. 9, 10.
  13. ^ Дж. Г. Холл, Л. Рапанотти и М. Джексон. Проблемно-ориентированная разработка программного обеспечения: решение задачи управления маршрутизатором пакетов. IEEE Trans. Software Eng., 2008. Дои:10.1109 / TSE.2007.70769.
  14. ^ Дж. Г. Холл и Л. Рапанотти. Дизайн, основанный на гарантиях. В материалах третьей Международной конференции по достижениям программной инженерии. 2008 г.
  15. ^ Л. Рапанотти и Дж. Г. Холл. Создание онлайн-мастера философии с частичной занятостью. В материалах Четвертой Международной конференции по Интернету и веб-приложениям и службам. IEEE Press, 24–28 мая 2009 г.

внешняя ссылка