Přístup problémových rámců - Problem frames approach

Analýza problému nebo přístup problémových rámců je přístup k softwaru analýza požadavků. Byl vyvinut britským softwarovým konzultantem Michael A. Jackson v 90. letech.

Dějiny

Přístup problémových rámců poprvé načrtl Jackson ve své knize Softwarové požadavky a specifikace (1995) a v řadě článků v různých časopisech věnovaných softwarovému inženýrství. Obdržel svůj nejplnější popis Rámečky problémů: Analýza a strukturování problémů s vývojem softwaru (2001).

Zasedání o problémových rámcích bylo součástí 9. mezinárodního semináře o požadavcích na inženýrství: Nadace pro kvalitu softwaru (REFSQ)], který se konal v Klagenfurtu / Velden v Rakousku v roce 2003.[1] První mezinárodní seminář o aplikacích a pokrokech v problémových rámcích[2] se konalo jako součást ICSE’04 konané ve skotském Edinburghu. Jedním z výsledků tohoto semináře bylo zvláštní vydání 2005 o problémových rámcích v EU International Journal of Information and Software Technology.

Druhý mezinárodní seminář o aplikacích a pokroku v problémových rámcích[3] se konal jako součást ICSE 2006 v čínském Šanghaji. Třetí mezinárodní seminář o aplikacích a pokrokech v problémových rámcích (IWAAPF)[4] se konalo v rámci ICSE 2008 v německém Lipsku. V roce 2010 byly workshopy IWAAPF nahrazeny Mezinárodním workshopem o aplikacích a pokrokech v orientaci na problémy (IWAAPO). IWAAPO rozšiřuje zaměření workshopů o alternativní a doplňkové přístupy k vývoji softwaru, které sdílejí důraz na analýzu problémů.[5] IWAAPO-2010 se konalo jako součást ICSE 2010 v Kapském Městě v Jižní Africe.[6]

V současné době se výzkum přístupu k problémovým rámcům provádí na řadě univerzit, zejména na Otevřená univerzita ve Spojeném království jako součást jeho Související struktury problémů a řešení výzkumné téma[7][8]

Myšlenky v přístupu k problémovým rámcům byly zobecněny do konceptů problémově orientovaný rozvoj (POD) a problémově orientované inženýrství (POE), z toho problémové softwarové inženýrství (POSE) je zvláštní podkategorie. První Mezinárodní workshop o problémově orientovaném rozvoji se konalo v červnu 2009.

Přehled

Základní filozofie

Analýza problému nebo přístup problémových rámců je přístup - soubor konceptů -, který se má použít při shromažďování požadavků a vytváření specifikací pro počítačový software. Jeho základní filozofie se nápadně liší od ostatních metod softwarových požadavků a trvá na tom, že:

  • Nejlepší způsob, jak přistupovat k analýze požadavků, je proces paralelního - nikoli hierarchického - rozkladu požadavků uživatelů.[9]
  • Požadavky uživatelů se týkají vztahů v reálném světě doména aplikace - nejde o softwarový systém nebo dokonce o rozhraní se softwarovým systémem.

Je užitečnější ... uvědomit si, že řešení je umístěno v počítači a jeho softwaru a problém je ve světě mimo .... Počítače mohou poskytnout řešení těchto problémů, protože jsou propojeny se světem venku.[10]

Morálka je jasná: ke studiu a analýze problému se musíte zaměřit na studium a analýzu problémového světa do určité hloubky a při vyšetřování musíte být ochotni cestovat do určité vzdálenosti od počítače. ... [Při problému s přesměrováním ...] Musíte popsat, co tam je - lidé a kanceláře a svátky a stěhování a delegování odpovědnosti - a jaké účinky [v problémovém světě]chcete, aby systém dosáhl - volání na číslo A musí dosáhnout A, a [když je B na dovolené a C dočasně pracuje u stolu D] volání na číslo B nebo C musí dosáhnout C.[11]

Žádný z nich se neobjevuje na rozhraní s počítačem ... Přibližují se hlouběji do světa.[12]

Tento přístup využívá tři sady koncepčních nástrojů.

Nástroje pro popis konkrétních problémů

Koncepty používané k popisu konkrétních problémů zahrnují: jevy (různých druhů, včetně Události), kontext problému, problémová doména,doména řešení (aka stroj), sdílené jevy (které existují v doménová rozhraní), doménové požadavky (které existují v problémových doménách) a Specifikace (které existují v problémové doméně: rozhraní stroje).

Grafické nástroje pro popis problémů jsou: kontextový diagram a problémový diagram.

Nástroje pro popis tříd problémů (problémové rámce)

Přístup k problémovým rámcům zahrnuje koncepty pro popis tříd problémů. Uznávaná třída problémů se nazývá a problémový rám (zhruba analogický k a návrhový vzor).

V problémovém rámci dostávají domény obecné názvy a jsou popsány z hlediska jejich důležitých charakteristik. Například doménu lze klasifikovat jako kauzální (reaguje na události deterministickým a předvídatelným způsobem) nebo poslušný (lze nabídnout nebo požádat, aby reagoval na události, ale nelze očekávat, že bude vždy reagovat na události jakýmkoli předvídatelným a deterministickým způsobem). (Doménu, kterou lze nabídnout, obvykle tvoří lidé.)

Grafický nástroj pro reprezentaci problémového rámce je a rámový diagram. Rámcový diagram vypadá obecně jako problémový diagram, kromě několika drobných rozdílů - domény mají spíše obecná než specifická jména; a obdélníky představující domény jsou anotovány, aby označovaly typ (kauzální nebo nabídnutelný) domény.

Seznam rozpoznaných tříd problémů (problémové rámce)

První skupina problémových rámců identifikovaných Jacksonem zahrnovala:

  1. požadované chování
  2. přikázané chování
  3. informační displej
  4. jednoduché obrobky
  5. proměna

Následně další vědci popsali nebo navrhli další problémové rámce.

Popsat problémy

Kontext problému

Analýza problému považuje softwarovou aplikaci za druh softwaru stroj. Projekt vývoje softwaru si klade za cíl změnit kontext problému vytvořením softwarového stroje a jeho přidáním do kontextu problému, kde přinese určité požadované efekty.

Zvláštní část kontextu problému, která je zajímavá v souvislosti s konkrétním problémem - konkrétní část kontextu problému, která tvoří kontext problému - se nazývá doména aplikace.

Po dokončení projektu vývoje softwaru a vložení softwarového stroje do kontextu problému bude kontext problému obsahovat doménu aplikace i stroj. V tom okamžiku bude situace vypadat takto:

ProblemFramesProblemContext1.svg

Kontext problému obsahuje stroj a doménu aplikace. The rozhraní stroje je místo, kde se stroj a doména aplikace setkávají a komunikují.

Stejná situace může být znázorněna na jiném druhu diagramu, a kontextový diagram, tudy:

ProblemFramesProblemContext2.png

Kontextový diagram

Prvním úkolem analytika problémů je skutečně porozumět problému. To znamená pochopit kontext, do kterého je problém zasazen. A to znamená kreslení a kontextový diagram.

Zde je Jacksonův popis zkoumání kontextu problému, v tomto případě kontextu pro stavbu mostu:

Jste inženýr, který plánuje postavit most přes řeku. Navštívíte tedy web. Stojíte na jednom břehu řeky a díváte se na okolní pevninu a na říční provoz. Cítíte, jak exponované je to místo a jak silně fouká vítr a jak rychle řeka teče. Podíváte se na břeh a přemýšlíte, jaké chyby ukáže geologický průzkum ve skalnatém terénu. Představujete si most, který budete stavět. (Softwarové požadavky a specifikace: „Problémový kontext“)

Analytik, který se snaží porozumět problému s vývojem softwaru, musí projít stejným procesem jako mostní inženýr. Začíná zkoumáním různých problémových domén v doméně aplikace. Tyto domény tvoří kontext, do kterého musí plánovaný počítač zapadat. Pak si představí, jak tento stroj zapadne do tohoto kontextu. A pak sestaví kontextový diagram ukazující jeho vizi problémového kontextu se strojem v něm nainstalovaným.

Kontextový diagram ukazuje různé problémové domény v doméně aplikace, jejich připojení a zařízení a jeho připojení k (některým) problémovým doménám. Takto vypadá kontextový diagram.

ProblemFramesContextDiagram1.svg

Tento diagram ukazuje:

  • the stroj být postaven. Tmavý rámeček pomáhá identifikovat pole, které představuje stroj.
  • the problémové domény které jsou relevantní k problému.
  • plné čáry představují doménová rozhraní - oblasti, kde se domény překrývají a sdílejí jevy společně.

Doména je prostě část světa, o kterou se zajímáme. Skládá se z jevy - jednotlivci, události, stavy věcí, vztahy a chování.

Rozhraní domény je oblast, kde se domény připojují a komunikují. Doménová rozhraní nejsou datové toky ani zprávy. Rozhraní je místo, kde se domény částečně překrývají, takže jevy v rozhraní jsou sdílené jevy - existují v obou překrývajících se doménách.

Domény si můžete představit jako primitivní jednobuněčné organismy (jako améby). Jsou schopni rozšířit své části na pseudopody. Představte si, že dva takové organismy rozšiřují pseudopody k sobě jakousi potřesení rukou a že buněčný materiál v oblasti, kde si potřásají rukama, se mísí, takže patří oběma. To je rozhraní.

V následujícím diagramu je X rozhraní mezi doménami A a B. Jednotlivci, kteří existují, nebo události, ke kterým dochází v X, existují nebo se vyskytují v A i B.

ProblemFramesInterfaces.svg

Sdílené osoby, státy a události mohou vypadat odlišně od domén, které je sdílejí. Zvažte například rozhraní mezi počítačem a klávesnicí. Když doména klávesnice uvidí událost Operátor klávesnice stiskne mezerník počítač uvidí stejnou událost jako Ve vstupní vyrovnávací paměti se objeví hexadecimální bajt („20“).

Problémové diagramy

Základním nástrojem analytika problémů pro popis problému je a problémový diagram. Zde je obecný problémový diagram.

ProblemFramesProblemDiagram1.svg

Kromě druhů věcí zobrazených v kontextovém diagramu zobrazuje problémový diagram:

  • tečkovaný ovál představující požadavek dosáhnout určitých účinků v problémových doménách.
  • tečkované čáry představující reference na požadavky - odkazy v požadavku na jevy v problémových doménách.

Rozhraní, které spojuje problémovou doménu se strojem, se nazývá a specifikace rozhraní a jsou nazývány jevy ve specifikačním rozhraní specifikační jevy. Cílem analytika požadavků je vyvinout specifikaci chování, které musí Stroj vykazovat na rozhraní Stroje, aby vyhověl požadavku.

Zde je příklad reálného, ​​i když jednoduchého problémového diagramu.

ProblemFramesProblemDiagram2.png

Tento problém může být součástí počítačového systému v nemocnici. V nemocnici jsou pacienti připojeni k senzorům, které dokážou detekovat a měřit jejich teplotu a krevní tlak. Požadavkem je zkonstruovat stroj, který dokáže zobrazit informace o stavu pacienta na panelu v sesterské stanici.

Název požadavku je „Zobrazení ~ Stav pacienta“. Vlnovka (~) označuje, že požadavek se týká vztahu nebo korespondence mezi zobrazením na panelu a stavem pacienta. Šipka ukazuje, že odkaz na požadavek připojený k doméně Panel Display je také omezením požadavku. To znamená, že požadavek obsahuje určitý druh ustanovení, které musí panel splňovat. Stručně řečeno, požadavek je takový Panelový displej musí zobrazovat informace, které odpovídají a přesně hlásí stav pacientů.

Popisující třídy problémů

Problémové snímky

A problémový rám je popis rozeznatelné třídy problémů, kde třída problémů má známé řešení. V jistém smyslu jsou problémové rámce problémovými vzory.

Každý problémový rámec má svůj vlastní rámový diagram. Rámcový diagram vypadá v zásadě jako problémový diagram, ale místo zobrazení konkrétních domén a požadavků zobrazuje typy domén a typy požadavků; domény mají spíše obecná než specifická jména; a obdélníky představující domény jsou anotovány, aby označovaly typ (kauzální nebo nabídnutelný) domény.

Varianty rámů

v Problémové rámy Jackson diskutoval o variantách pěti základních problémových rámců, které identifikoval. Varianta obvykle přidává doménu do kontextu problému.

  • A varianta popisu zavádí popis lexikální domény
  • an varianta operátora zavádí operátor
  • A varianta připojení zavádí doménu připojení mezi strojem a centrální doménou, se kterou komunikuje
  • A varianta ovládání nezavádí žádnou novou doménu; mění řídicí vlastnosti jevů rozhraní

Problémové obavy

Jackson také pojednává o určitých druzích obav, které vznikají při práci s problémovými snímky.

Zvláštní obavy

  • obsadit
  • inicializace
  • spolehlivost
  • identity
  • úplnost

Složení se týká

  • srovnatelné popisy
  • konzistence
  • přednost
  • rušení
  • synchronizace

Rozpoznané problémové snímky

První problémové snímky identifikované Jacksonem zahrnovaly:

  1. požadované chování
  2. přikázané chování
  3. informační displej
  4. jednoduché obrobky
  5. proměna

Následně další vědci popsali nebo navrhli další problémové rámce.

Rámec problému požadovaného chování

Intuitivní myšlenka za tímto problémovým rámcem je:

  • Existuje určitá část fyzického světa, jejíž chování je třeba kontrolovat tak, aby splňovalo určité podmínky. Problém je postavit stroj, který tuto kontrolu uloží.
ProblemFramesRequiredBehaviorFrame.svg

Rámec problému s přikázaným chováním

Intuitivní myšlenka za tímto problémovým rámcem je:

  • Existuje určitá část fyzického světa, jejíž chování má být řízeno v souladu s příkazy vydanými operátorem. Problém je postavit stroj, který bude přijímat příkazy operátora a odpovídajícím způsobem ukládat ovládací prvky.
ProblemFramesCommandedBehaviorFrame.svg

Rámeček problému se zobrazením informací

Intuitivní myšlenka za tímto problémovým rámcem je:

  • Existuje určitá část fyzického světa, o jejíž stavech a chování jsou neustále potřebné určité informace. Problém je postavit stroj, který získá tyto informace ze světa a předloží je na požadovaném místě v požadované formě.
ProblemFramesInformationDisplayFrame.svg

Jednoduchý problémový rám obrobků

Intuitivní myšlenka za tímto problémovým rámcem je:

  • Je zapotřebí nástroj, který uživateli umožní vytvářet a upravovat určitou třídu textů nebo grafických objektů zpracovatelných počítačem nebo podobných struktur, aby je bylo možné následně kopírovat, tisknout, analyzovat nebo používat jinými způsoby. Problém je postavit stroj, který může fungovat jako tento nástroj.
ProblemFramesSimpleWorkpiecesFrame.svg

Rámec problému transformace

Intuitivní myšlenka za tímto problémovým rámcem je:

  • Existují některé dané počítačem čitelné vstupní soubory, jejichž data musí být transformována, aby poskytly určité požadované výstupní soubory. Výstupní data musí být v určitém formátu a musí být odvozena ze vstupních dat podle určitých pravidel. Problém je postavit stroj, který bude produkovat požadované výstupy ze vstupů.
ProblemFramesTransformationFrame.svg

Analýza problémů a proces vývoje softwaru

Když je analýza problému začleněna do proces vývoje softwaru, životní cyklus vývoje softwaru začíná u analytika problémů, který studuje situaci a:

  • vytvoří kontextový diagram
  • shromažďuje seznam požadavků a do kontextového diagramu přidává ovál požadavků a vytváří tak velký problémový diagram „vše v jednom“. (Avšak v mnoha případech může být vytvoření diagramu problému typu „vše v jednom“ nepraktické nebo neužitečné: bude zde příliš mnoho požadavků, které křížem krážem přejdou diagram, aby byl velmi užitečný.)
  • rozloží problém a diagram problému vše v jednom na jednodušší problémy a jednodušší diagramy problémů. Tyto problémy jsou projekce, nikoli podmnožiny, schématu vše v jednom.
  • pokračuje v rozkládání problémů, dokud není každý problém dostatečně jednoduchý na to, aby byl považován za instanci rozpoznaného rámce problému. Každý popis dílčího problému obsahuje popis specifikačních rozhraní pro stroj, který má být sestaven.

V tomto okamžiku bude analýza problému - problémový rozklad - je kompletní. Dalším krokem je zvrátit proces a vybudovat požadovaný softwarový systém prostřednictvím procesu složení roztoku.

Proces složení řešení není dosud dobře znám a je stále velmi výzkumným tématem. Extrapolace z náznaků v Softwarové požadavky a specifikace, můžeme hádat, že proces vývoje softwaru by pokračoval s vývojáři, kteří by:

  • sestavit specifikace více dílčích strojů do specifikace pro jeden stroj all-in-one: specifikace pro softwarový stroj, který splňuje všechny požadavky zákazníka. Toto je netriviální aktivita - proces složení se může velmi dobře zvýšit problémy se složením to je třeba vyřešit.
  • implementujte stroj vše v jednom tím, že projdete tradičním procesem kódování / testování / nasazení.

Podobné přístupy

Existuje několik dalších nápadů na vývoj softwaru, které jsou v některých ohledech podobné analýze problémů.

  • Pojem a návrhový vzor je podobný Jacksonově pojetí problémového rámce. Liší se tím, že se návrhový vzor používá spíše pro rozpoznávání a řešení problémů s návrhem (často problémy s návrhem v konkrétních objektově orientovaných programovacích jazycích, jako je C ++ nebo Java), než pro rozpoznávání a řešení problémů s požadavky. Jeden rozdíl navíc spočívá v tom, že návrhové vzory pokrývají řešení zatímco v problémových rámcích problémy jsou zastoupeny. Návrhové vzory však také mají tendenci zohledňovat sémantické výsledky, které nejsou nativní pro programovací jazyk, ve kterém mají být implementovány. Dalším rozdílem je tedy to, že problémové rámce jsou nativní meta-notací pro doménu problémů, zatímco designové vzory jsou katalogem technického dluhu, který zanechali jazykoví implementátoři.
  • Aspektově orientované programování, AOP (také známý jako aspektově orientovaný vývoj softwaru, AOSD) se podobně zajímá o paralelní rozklad, který řeší to, co navrhovatelé AOP nazývají průřezové obavy nebo aspekty. AOP řeší obavy, které jsou mnohem blíže fázi návrhu a generování kódu než fázi analýzy požadavků.
  • AOP se přesunul do notací technických požadavků, jako je ITU-T Z.151 Notation Requirements Notation (URN). V URN je AOP nad všemi úmyslnými prvky. AOP lze také aplikovat na modelování požadavků, které používá problémové snímky jako heuristiku. Modely URN založené na uvažování problémových rámců a prokládané s aspekty umožňují začlenění architektonické taktiky do modelu požadavků.
  • Kniha Martina Fowlera Vzory analýzy je velmi podobný analýze problémů při hledání vzorů. Ve skutečnosti však nepředstavuje novou metodu analýzy požadavků. A pojem paralelního rozkladu - který je tak důležitý pro analýzu problémů - není součástí Fowlerových analytických vzorců.
  • Jon G. Hall, Lucia Rapanotti spolu s Jacksonem vyvinuli rámec POSE (Problem Oriented Software Engineering)[13] který sdílí základy problémových rámců. Od roku 2005 Hall a Rapanotti rozšířili POSE na Problem Oriented Engineering (POE), který poskytuje rámec pro konstrukční design, včetně modelu vývojového procesu a designu založeného na ujištění,[14] a může být škálovatelný pro projekty, které zahrnují mnoho zúčastněných stran a které kombinují různé inženýrské disciplíny, jako je software a poskytování vzdělávání.[15]

Reference

  1. ^ 9. mezinárodní workshop o inženýrství požadavků: Foundation for Software Quality (REFSQ) se konala v Klagenfurtu / Velden v Rakousku v roce 2003.
  2. ^ První mezinárodní seminář o aplikacích a pokroku v problémových rámcích
  3. ^ Druhý mezinárodní seminář o aplikacích a pokroku v problémových rámcích Archivováno 2007-08-19 na Wayback Machine
  4. ^ „Třetí mezinárodní seminář o aplikacích a pokroku v problémových rámcích“. Archivovány od originál dne 2010-12-24. Citováno 2010-06-19.
  5. ^ Mezinárodní seminář o aplikacích a pokrokech v orientaci na problémy Archivováno 2011-01-11 na Wayback Machine
  6. ^ „IWAAPO-2010“. Archivovány od originál dne 28. 1. 2010. Citováno 2010-06-19.
  7. ^ Související struktury problémů a řešení výzkumné téma.
  8. ^ Například: „Související softwarové požadavky a architektury využívající problémové rámce“ od Hall, J.G .; Jackson, M .; Laney, R.C .; Nuseibeh, B .; Rapanotti, L., v Proceedings of the IEEE Joint International Conference on Requirements Engineering (2002), str. 137–144
  9. ^ Jackson, Michael (1995). "Problémový rozklad pro opětovné použití". s. 1, 2.
  10. ^ Jackson, Michael (2001). Problémové rámy. Addison-Wesley. 3, 4.
  11. ^ Jackson, Michael (2001). Problémové rámy. Addison-Wesley. p. 9.
  12. ^ Jackson, Michael (2001). Problémové rámy. Addison-Wesley. 9, 10.
  13. ^ J. G. Hall, L. Rapanotti a M. Jackson. Problémově orientované softwarové inženýrství: řešení problému s řízením routeru balíčku. IEEE Trans. Software Eng., 2008. doi:10.1109 / TSE.2007.70769.
  14. ^ J. G. Hall a L. Rapanotti. Design založený na ujištění. Ve sborníku ze třetí mezinárodní konference o softwarovém inženýrství. 2008.
  15. ^ L. Rapanotti a J. G. Hall. Navrhování online magisterského studia filozofie na částečný úvazek. Ve sborníku ze čtvrté mezinárodní konference o internetových a webových aplikacích a službách. IEEE Press, 24. – 28. Května 2009.

externí odkazy