Подход к проблемным фреймам

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

История

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

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

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

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

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

Обзор

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

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

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

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

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

Ничего из этого не появляется в интерфейсе с компьютером.... Это все глубже в мир, чем этот.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ту же ситуацию можно отобразить на другой диаграмме, контекстной диаграмме , следующим образом:

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

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

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

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

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

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

На этой диаграмме показано:

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

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

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

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

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

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

Диаграммы задач

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

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

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

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

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

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

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

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

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

Фрейм проблемы — это описание узнаваемого класса проблем, где этот класс проблем имеет известное решение. В некотором смысле проблемные фреймы — это проблемные паттерны.

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

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

В «Проблемных фреймах» Джексон обсудил варианты пяти основных проблем. рамки, которые он определил. Вариант обычно добавляет домен в контекст проблемы.

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

Проблема беспокоит

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

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

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

Проблемы с составом

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

Признанные проблемные фреймы

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

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

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

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

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

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

Рамка проблемы командного поведения

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

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

Проблема с отображением информации

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

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

Рамка задачи о простых заготовках

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

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

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

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

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

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

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

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

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

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

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

Похожие подходы

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

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

Внешние ссылки

• http://mcs.open.ac.uk/mj665/ — Майкла А. Джексона. домашняя страница
• http://www.jacksonworkbench.co.uk/stevefergspages/pfa/index.html содержит статьи и статьи по подходу «фреймы проблем».