• Save
NFR & Architectuur: Twee handen op één buik
Upcoming SlideShare
Loading in...5
×
 

NFR & Architectuur: Twee handen op één buik

on

  • 527 views

Plenary session SPIder (Dutch Software Process Improvement Network)

Plenary session SPIder (Dutch Software Process Improvement Network)

Statistics

Views

Total Views
527
Views on SlideShare
526
Embed Views
1

Actions

Likes
0
Downloads
0
Comments
0

1 Embed 1

http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

NFR & Architectuur: Twee handen op één buik NFR & Architectuur: Twee handen op één buik Presentation Transcript

  • NFR & Architectuur: Twee handen op één buik Remco de Boer 1
  • Over mijzelf 2009: Promotie (VU) 2003: Onderzoeker / ontwikkelaar kennistechnologie 2005: Promotieonderzoek “Architectuur- 1999: kennismanagement” Software- 2002: ontwikkelaar Econometrie / Bestuurlijke Informatica (EUR) 2
  • 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
  • Agenda • Requirements vs. architectuur • Requirements engineering als probleemanalyse • Architectuur: van „structuurgeoriënteerd‟ naar „kennisgeoriënteerd‟ • Requirements vs. architectuurontwerpbeslissingen • Conclusie en aanbevelingen 4
  • 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
  • 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
  • Probleem en oplossing staan niet los van elkaar Probleem Oplossing 7
  • 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
  • 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
  • Pipe-and-filter architectuur voor KWIC Circular Input Sorter Output Shifter 10
  • Probleemanalyse voor en na architectuurkeuze KWIC: KWIC Pipe & Filter architectuur Rapanotti et al. (2004): Architecture-driven Problem Decomposition 11
  • 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
  • Architectuur is meer dan structuur • Van „structuurgeoriënteerd‟ naar „kennisgeoriënteerd‟ • Architectuur = structuur + ontwerpbeslissingen Decision graph (Kruchten et al., 2005)) 13
  • Ontwerpbeslissingen: een beslislus Concerns („problem‟) leiden tot ontwerpbeslissingen („solution‟) die weer tot nieuwe concerns leiden 14
  • Intermezzo: requirement of ontwerpbeslissing? “The KWIC component must have effective space performance” 15
  • 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
  • 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
  • Requirements en architectuur in de wensput van architectuuruitspraken 18
  • 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
  • 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