Анализ проблем или подход фреймов проблем — это подход к анализу требований к программному обеспечению . Он был разработан британским консультантом по программному обеспечению Майклом А. Джексоном в 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 года.
Анализ проблем или подход фреймов проблем — это подход — набор концепций — который следует использовать при сборе требований и создании спецификаций для программного обеспечения. Его основная философия разительно отличается от других методов требований к программному обеспечению, настаивая на том, что:
Гораздо полезнее ... признать, что решение находится в компьютере и его программном обеспечении, а проблема - во внешнем мире. ... Компьютеры могут предоставить решения этих проблем, потому что они подключены к внешнему миру. [10]
Мораль ясна: чтобы изучить и проанализировать проблему, вы должны сосредоточиться на изучении и анализе проблемного мира на некоторой глубине, и в своих исследованиях вы должны быть готовы отойти на некоторое расстояние от компьютера. ... [В проблеме переадресации вызовов...] Вам нужно описать, что там есть – люди, офисы, праздники, переезд офиса и делегирование ответственности – и какие эффекты [в проблемном мире] вы хотели бы, чтобы достигала система – звонки на номер A должны доходить до A, и [когда B в отпуске, а C временно работает за столом D] звонки на номера B или C должны доходить до C. [11]
Ни один из них не появляется в интерфейсе с компьютером... Они все глубже в мире. [12]
Подход использует три набора концептуальных инструментов.
Концепции, используемые для описания конкретных проблем, включают: явления (различных видов, включая события ), контекст проблемы , проблемную область , область решения (иначе называемую машиной ), общие явления (которые существуют в интерфейсах доменов ), требования домена (которые существуют в проблемных областях) и спецификации (которые существуют в интерфейсе проблемная область:машина).
Графическими инструментами описания проблем являются контекстная диаграмма и проблемная диаграмма .
Подход «Фреймы проблем» включает концепции для описания классов проблем. Признанный класс проблем называется фреймом проблем (примерно аналогично шаблону проектирования ).
В проблемном фрейме домены получают общие названия и описываются в терминах их важных характеристик. Например, домен может быть классифицирован как каузальный (реагирует детерминированным, предсказуемым образом на события) или biddable (можно предложить или попросить отреагировать на события, но нельзя ожидать, что он всегда будет реагировать на события каким-либо предсказуемым, детерминированным образом). (biddable domain обычно состоит из людей.)
Графическим инструментом для представления проблемного фрейма является фреймовая диаграмма . Фреймовая диаграмма в целом выглядит как проблемная диаграмма, за исключением нескольких незначительных отличий — домены имеют общие, а не конкретные названия; и прямоугольники, представляющие домены, аннотированы для указания типа (причинный или подразумеваемый) домена.
Первая группа проблемных фреймов, выявленная Джексоном, включала:
Впоследствии другие исследователи описали или предложили дополнительные проблемные фреймы.
Анализ проблемы рассматривает программное приложение как своего рода программную машину . Проект по разработке программного обеспечения направлен на изменение контекста проблемы путем создания программной машины и добавления ее в контекст проблемы, где она будет приносить определенные желаемые эффекты.
Конкретная часть контекста проблемы, представляющая интерес в связи с конкретной проблемой — конкретная часть контекста проблемы, которая формирует контекст проблемы — называется областью применения .
После завершения проекта разработки ПО и вставки программной машины в контекст проблемы, контекст проблемы будет содержать как домен приложения, так и машину. В этот момент ситуация будет выглядеть следующим образом:
Контекст проблемы содержит машину и домен приложения. Интерфейс машины — это место, где встречаются и взаимодействуют машина и домен приложения.
Эту же ситуацию можно отобразить на диаграмме другого типа, контекстной диаграмме , следующим образом:
Первая задача аналитика проблемы — по-настоящему понять проблему. Это означает понимание контекста, в котором проблема задана. А это означает построение контекстной диаграммы.
Вот как Джексон описывает изучение контекста проблемы, в данном случае контекста строительства моста:
Аналитик, пытающийся понять проблему разработки программного обеспечения, должен пройти тот же процесс, что и инженер-мост. Он начинает с изучения различных проблемных доменов в прикладной области. Эти домены формируют контекст, в который должна вписаться запланированная Машина. Затем он представляет, как Машина впишется в этот контекст. А затем он строит контекстную диаграмму, показывающую его видение проблемного контекста с установленной в нем Машиной.
Контекстная диаграмма показывает различные проблемные области в прикладной области, их связи, а также Машину и ее связи с (некоторыми) проблемными областями. Вот как выглядит контекстная диаграмма.
На этой диаграмме показано:
Домен — это просто часть мира, которая нас интересует. Он состоит из явлений — людей, событий, положений дел, отношений и поведения.
Интерфейс домена — это область, где домены соединяются и общаются. Интерфейсы домена — это не потоки данных или сообщения. Интерфейс — это место, где домены частично перекрываются, так что явления в интерфейсе являются общими явлениями — они существуют в обоих перекрывающихся доменах.
Вы можете представить себе домены как примитивные одноклеточные организмы (например, амебы). Они способны расширять части себя в псевдоподии. Представьте, что два таких организма расширяют псевдоподии друг к другу в своего рода рукопожатии, и что клеточный материал в области, где они пожимают руки, смешивается, так что он принадлежит им обоим. Это интерфейс.
На следующей диаграмме X является интерфейсом между доменами A и B. Индивиды, которые существуют, или события, которые происходят в X, существуют или происходят как в A, так и в B.
Общие лица, состояния и события могут выглядеть по-разному для доменов, которые их разделяют. Рассмотрим, например, интерфейс между компьютером и клавиатурой. Когда домен клавиатуры видит событие Оператор клавиатуры нажимает пробел, компьютер увидит то же самое событие, что и Byte hex("20"), появляющееся во входном буфере.
Основным инструментом аналитика проблем для описания проблемы является диаграмма проблем . Вот общая диаграмма проблем.
В дополнение к типам вещей, показанным на контекстной диаграмме, проблемная диаграмма показывает:
Интерфейс, который соединяет проблемную область с машиной, называется интерфейсом спецификации , а явления в интерфейсе спецификации называются явлениями спецификации . Цель аналитика требований — разработать спецификацию поведения, которое Машина должна демонстрировать в интерфейсе Машины, чтобы удовлетворить требованию.
Вот пример реальной, хотя и простой, диаграммы проблемы.
Эта проблема может быть частью компьютерной системы в больнице. В больнице пациенты подключены к датчикам, которые могут определять и измерять их температуру и артериальное давление. Требуется построить Машину, которая может отображать информацию о состоянии пациента на панели на посту медсестры.
Название требования — «Отображение ~ Состояние пациента». Тильда (~) указывает на то, что требование касается взаимосвязи или соответствия между дисплеем панели и состояниями пациента. Стрелка указывает на то, что ссылка на требование, связанная с доменом дисплея панели, также является ограничением требования. Это означает, что требование содержит некое условие, которому должен соответствовать дисплей панели. Короче говоря, требование заключается в том, что дисплей панели должен отображать информацию, которая соответствует и точно сообщает о состоянии пациентов.
Рамка проблемы — это описание узнаваемого класса проблем, где класс проблем имеет известное решение. В некотором смысле рамки проблемы — это шаблоны проблем.
Каждый проблемный фрейм имеет свою собственную фреймовую диаграмму . Фреймовая диаграмма по сути похожа на проблемную диаграмму, но вместо отображения конкретных доменов и требований она показывает типы доменов и типы требований; домены имеют общие, а не конкретные названия; и прямоугольники, представляющие домены, аннотированы для указания типа (причинный или подразумеваемый) домена.
В «Фреймах проблем» Джексон обсудил варианты пяти основных фреймов проблем, которые он определил. Вариант обычно добавляет домен к контексту проблемы.
Джексон также обсуждает определенные виды проблем, возникающих при работе с проблемными фреймами.
Особые опасения
Проблемы с составом
Первые проблемные кадры, выявленные Джексоном, включали:
Впоследствии другие исследователи описали или предложили дополнительные проблемные фреймы.
Интуитивная идея, лежащая в основе этой рамочной задачи, такова:
Интуитивная идея, лежащая в основе этой рамочной задачи, такова:
Интуитивная идея, лежащая в основе этой рамочной задачи, такова:
Интуитивная идея, лежащая в основе этой рамочной задачи, такова:
Интуитивная идея, лежащая в основе этой рамочной задачи, такова:
Когда анализ проблем включен в процесс разработки программного обеспечения , жизненный цикл разработки программного обеспечения начинается с аналитика проблем, который изучает ситуацию и:
На этом этапе анализ проблемы — декомпозиция проблемы — завершен. Следующий шаг — обратить процесс вспять и построить желаемую программную систему через процесс композиции решения .
Процесс составления решения пока еще не до конца понятен и по-прежнему остается предметом исследований. Экстраполируя намеки в Требованиях и спецификациях программного обеспечения , мы можем предположить, что процесс разработки программного обеспечения будет продолжаться разработчиками, которые:
Есть еще несколько идей разработки программного обеспечения, которые в некотором роде похожи на анализ проблем.