NFR & Architectuur:
Twee handen op één buik
Remco de Boer




                          1
Over mijzelf



                                               2009:
                                               Promot...
ArchiXL

•    IT-architectuur adviesbureau
•    Opgericht in januari 2008
•    Gehuisvest in Amersfoort
•    Focus op fina...
Agenda

• Requirements vs. architectuur

• Requirements engineering als probleemanalyse

• Architectuur: van „structuurgeo...
Requirements            vs.          Architectuur




             Wat?                     Hoe?

         Probleem       ...
Requirements engineering als probleemanalyse
                  ‘Indicatief’   ‘Optatief’




Problem domain               ...
Probleem en oplossing staan niet los van elkaar

        Probleem                       Oplossing




                    ...
Voorbeeld: KWIC

•   KWIC: “Key Word In Context”
     – Hans Peter Luhn (IBM, 1958)
     – Parnas (1972): On the criteria ...
KWIC Index
                           Context      Key Word       Context                               Publicatie

      ...
Pipe-and-filter architectuur voor KWIC




             Circular
Input                        Sorter         Output
      ...
Probleemanalyse voor en na architectuurkeuze

                                                                            ...
Architectuurkeuze verandert de probleemwereld




• Gebruik van pipes & filters
    – is een keuze (optatief), maar
    – ...
Architectuur is meer dan structuur

• Van „structuurgeoriënteerd‟ naar
  „kennisgeoriënteerd‟

• Architectuur =
  structuu...
Ontwerpbeslissingen: een beslislus




Concerns („problem‟) leiden tot ontwerpbeslissingen („solution‟) die weer tot nieuw...
Intermezzo: requirement of ontwerpbeslissing?




“The KWIC component must have effective space performance”




         ...
Requirements vs. ontwerpbeslissingen:
  Nogmaals het KWIC probleem

                            implicit
                 ...
Requirements vs. ontwerpbeslissingen:
Nogmaals het KWIC probleem


                    effective space
                   ...
Requirements en architectuur in de wensput van
architectuuruitspraken




                                                ...
Methoden en technieken rondom de wensput

   Requirements          de „wensput‟               Architectuur
    engineering...
Conclusie

•   Er is geen fundamenteel verschil tussen requirements en
    ontwerpbeslissingen
     – Beide zijn richtingg...
Upcoming SlideShare
Loading in …5
×

NFR & Architectuur: Twee handen op één buik

524 views
452 views

Published on

Plenary session SPIder (Dutch Software Process Improvement Network)

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
524
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

NFR & Architectuur: Twee handen op één buik

  1. 1. NFR & Architectuur: Twee handen op één buik Remco de Boer 1
  2. 2. Over mijzelf 2009: Promotie (VU) 2003: Onderzoeker / ontwikkelaar kennistechnologie 2005: Promotieonderzoek “Architectuur- 1999: kennismanagement” Software- 2002: ontwikkelaar Econometrie / Bestuurlijke Informatica (EUR) 2
  3. 3. ArchiXL • IT-architectuur adviesbureau • Opgericht in januari 2008 • Gehuisvest in Amersfoort • Focus op financiële en publieke sector • Onafhankelijk • Kennisgebieden: – IT-architectuur (BPM, EAI/SOA, ECM, IDM, BI, Portals) – Enterprise-architectuur methoden, technieken en tools (TOGAF, ArchiMate) – Sectorkennis (verzekeren, pensioenuitvoering, gemeentes, onderwijs) • Met ingang van 2010 ook architectuuropleidingen 3-10-2010 3
  4. 4. Agenda • Requirements vs. architectuur • Requirements engineering als probleemanalyse • Architectuur: van „structuurgeoriënteerd‟ naar „kennisgeoriënteerd‟ • Requirements vs. architectuurontwerpbeslissingen • Conclusie en aanbevelingen 4
  5. 5. Requirements vs. Architectuur Wat? Hoe? Probleem Oplossing Vóór ondertekening Na ondertekening Swartout & Waltzer (1982): On the inevitable intertwining of specification and implementation “Staat vast” “Nog te bepalen” 5
  6. 6. Requirements engineering als probleemanalyse ‘Indicatief’ ‘Optatief’ Problem domain Requirements Machine specification Het deel van de Beschrijving van wat Beschrijving van het wereld waar het de klant waar zou gewenste gedrag van probleem zich willen laten zijn in de de machine in de bevindt probleemwereld probleemwereld (black box) Jackson (2001): Problem frames 6
  7. 7. Probleem en oplossing staan niet los van elkaar Probleem Oplossing 7
  8. 8. Voorbeeld: KWIC • KWIC: “Key Word In Context” – Hans Peter Luhn (IBM, 1958) – Parnas (1972): On the criteria to be used in decomposing systems into modules • Doel: – Alfabetisch kunnen zoeken op individuele woorden in een titel • Werking van een KWIC index: – „circular shifting‟ (cyclische permutatie) van een regel tekst • haal het eerste woord weg • plak dit aan het eind van de regel – resultaat: lexicografisch geordende lijst van alle gepermuteerde regels • Circular shifting: Software Architecture in Practice (Bass e.a., 2003) – Software Architecture in Practice – Architecture in Practice / Software – in Practice / Software Architecture – Practice / Software Architecture in 8
  9. 9. KWIC Index Context Key Word Context Publicatie Software Architecture in Practice Bass et al. (2003) Design & Use of Software Architectures Bosch (2000) Design & Use of Software Architectures Bosch (2000) Software Engineering Principles and Practice Van Vliet (2009) Software Architecture in Practice Bass et al. (2003) Software Engineering Principles and Practice Van Vliet (2009) Software Engineering Principles and Practice Van Vliet (2009) Software Architecture in Practice Bass et al. (2003) Design & Use of Software Architectures Bosch (2000) Software Engineering Principles and Practice Van Vliet (2009) Design & Use of Software Architectures Bosch (2000) 9
  10. 10. Pipe-and-filter architectuur voor KWIC Circular Input Sorter Output Shifter 10
  11. 11. Probleemanalyse voor en na architectuurkeuze KWIC: KWIC Pipe & Filter architectuur Rapanotti et al. (2004): Architecture-driven Problem Decomposition 11
  12. 12. Architectuurkeuze verandert de probleemwereld • Gebruik van pipes & filters – is een keuze (optatief), maar – wordt vervolgens een gegeven (indicatief) • NB. Pipe&filter is maar één van de mogelijke architectuurkeuzen – mogelijke alternatieven: shared data, abstract data type, implicit invocation – Geschiktheid hangt mede af van de gestelde (niet-functionele) eisen en hun relatieve onderlinge prioriteit. (cf. Chung et al. (1999), Architectural Design to Meet Stakeholder Requirements) 12
  13. 13. Architectuur is meer dan structuur • Van „structuurgeoriënteerd‟ naar „kennisgeoriënteerd‟ • Architectuur = structuur + ontwerpbeslissingen Decision graph (Kruchten et al., 2005)) 13
  14. 14. Ontwerpbeslissingen: een beslislus Concerns („problem‟) leiden tot ontwerpbeslissingen („solution‟) die weer tot nieuwe concerns leiden 14
  15. 15. Intermezzo: requirement of ontwerpbeslissing? “The KWIC component must have effective space performance” 15
  16. 16. Requirements vs. ontwerpbeslissingen: Nogmaals het KWIC probleem implicit invocation (cf. Chung et al. 1999) implicit invocation effective space (cf. Chung et al. performance 1999) effective space performance, good time performance, pipe & filter., high extensibility shared data, abstract data type, implicit invocation, how to limit amount of data stored 16
  17. 17. Requirements vs. ontwerpbeslissingen: Nogmaals het KWIC probleem effective space performance number of items in effective space catalog expected to performance increase rapidly increasing number of items; budget effective space restrictions performance; scalable data storage how to cope with increasing amount of data? 17
  18. 18. Requirements en architectuur in de wensput van architectuuruitspraken 18
  19. 19. Methoden en technieken rondom de wensput Requirements de „wensput‟ Architectuur engineering Elicitation creation of statements Decision making Negotiation Trade-off analyses Specification drop statements in the Design well Validation compare well contents Assessment with reality Documentation write down well contents Description Requirements structure well contents Architectural knowledge management management 19
  20. 20. Conclusie • Er is geen fundamenteel verschil tussen requirements en ontwerpbeslissingen – Beide zijn richtinggevende uitspraken die het uiteindelijke ontwerp beïnvloeden – Onderscheid is arbitrair (maar kan wel nuttig zijn in een gegeven context) • Aanbevelingen: – Maak onderscheid waar dat nuttig is • Bijv. formele verantwoordelijkheden (voordat/nadat het contract is ondertekend) – Wees je bewust van de wederzijdse afhankelijkheden • De architect heeft een rol in het requirementsproces – Maak gebruik van de overeenkomsten! • Kennismanagement • Traceerbaarheid • Methoden en technieken 20

×