Modeling a Software Architecture. Paolo Ciancarini

Transcription

1 Modelig a Software Architecture Paolo Ciacarii

2 Ageda Describig software architectures Architectural frameworks Models based o architectural laguages Models based o UML Mai architectural views 2

3 Why documet the architecture? I the software life cycle we: Create a architecture Usig architectural patters, desig patters, experiece Evaluate the architecture Usig ATAM for example (see lecture o SA evaluatio) Refie, update, ad refactor the architecture alog the way Use the architecture to guide the implemetatio (Try to) eforce the architecture durig the implemetatio ad throughout maiteace 3

4 Creatig a software architecture The architecture of a software system is closely related to its quality attributes Architectures allow or preclude early all of the system s quality attributes Without a proper architecture the quality of a system caot be esured or ca be highly expesive, or eve impossible, to implemet 4

5 Sw architecture ad fuctio Qualities are attributes of the system, while the fuctio is the purpose of the system Fuctioality describes what the system does; the quality fuctioal suitability describes how well the system does its fuctio Fuctioal suitability: the capability of a software product to provide fuctios which meet stated ad implied eeds whe the software is used uder specified coditios (ISO Systems ad software Quality Requiremets ad Evaluatio) 5

6 Architecture ad structure A software architecture icludes multiples structures Each structure represets a differet view of the system Each structure focusses o oe aspect of the system Aalogy: the architecture of a buildig has may structures: - Buildig structure - Electricity supply structure - Water supply structure ad so o

7 Static ad dyamic structures The static structures of a system defie its iteral desig-time elemets ad their arragemet The dyamic structures of a system defie its rutime elemets, their behaviors ad iteractios 7

8 Example Structure: the source code of a operatig system like Liux has a structure, that separates the kerel (eg. cocerig processes ad schedulig) from the services (eg. cocerig the file system) Behavior: the operatio of a operatig system like Liux ca be described as a set of cocurret processes which ca ivoke system calls; each call ca raise evets which ca susped or activate processes; we ca say that a ruig Liux system is made of processes coordiated by evets 8

9 Structure Behavior 9

10 Architectural views

11 Sw architecture ad resposibility The distictio betwee fuctio ad quality sometimes is vague for istace, if the fuctio of a software is to cotrol egie behavior, how ca it be correctly implemeted without cosiderig timig behavior? the ability to cotrol access through requirig a user ame/password combiatio is a fuctio eve though it is ot the purpose of ay system The word resposibility describes better the computatios that a system must perform Questios such as What are the timig costraits o that set of resposibilities?, What modificatios are aticipated with respect to that set of resposibilities?, ad What class of users is allowed to execute that set of resposibilities? make sese ad have value Thus, the achievemet of qualities iduces a defiitio of resposibility 11

12 Resposibility-drive desig Resposibility-drive desig is ispired by cotracts (iterfaces) betwee objects: DOING: what actios is this object resposible for? KNOWING: what iformatio does this object share? Example: who should be resposible for creatig a ew istace of a class? A object of class A ca create objects of class B if A aggregates objects B A cotais objects B A ca iitialize objects B ( A has the complete data for iitialize B) 12

13 Models ad views It is ot possible to capture the fuctioal features ad the quality properties of a complex system i a sigle model that is uderstadable by ad of value to all stakeholders A software architecture is modeled by may structures Code uits, their decompositio ad depedecies Processes ad how they iteract How software is deployed o hardware A view is a represetatio of a structure It illustrates how the architecture addresses oe or more cocers held by oe or more of its stakeholders 13

14 Architectural descriptio A architectural descriptio (AD) is a set of artifacts which collectively documet a architecture i a way uderstadable by its stakeholders, ad demostrates that the architecture meets their cocers The artifacts i a AD iclude views, models, decisios, priciples, costraits, etc., to preset the essece of the architecture ad its details, so that it ca be validated ad the described system ca be built The AD ca iclude other relevat iformatio like busiess drivers, scope or requiremets overview 14

15 Coceptual architecture view 15

16 The architecture documet: template Architectural goals Sigificat requiremets 1 2 Fuctioal Nofuctioal Decisios ad justificatios Key abstractios (Domai model) Architectural descriptio Logical compoet model Process model Physical compoets ad layers Developmet model Deploymet model 16

17 The ISO Stadard This stadard, the most recet versio of IEEE 1471, makes a distictio betwee Architectures ad Architecture Descriptios Architecture descriptio, idetificatio ad overview Idetificatio of stakeholders ad cocers Selectio of architecture viewpoits Architecture views Cosistecy ad correspodeces amog architectural views Architectural ratioale 17

18 A Coceptual Model of Architecture Descriptio 18

19 Documetig sw architectures: views A view is a descriptio of a system accordig to the perspective (viewpoit) of some stakeholder, who has to satisfy some iterest (cocer) Example: a user view describes the typical scearios where a system ca be used A architectural view is a descriptio of some relevat issues of a software architecture Example: the architectural view of packages ecessary to istall a software system, depictig their depedecies

20 Template for a architectural view 20

21 Example: cotext view 21

22 Example: cotext view 22

23 Example: cotext view 23

24 24

25 Example: requiremets view Purpose: documetig the system requiremets Stakeholders: architects, developers, customers, maagemet, testers, project lead, domai experts Cocers: What does the busiess cotext of the system looks like? What are the essetial requiremets the system must satisfy? Artifacts: problem descriptio ad busiess opportuities stakeholders busiess processes requiremets guidelies 25

26 Example: a module view 26

27 Module view: summary Modules are implemetatio uits, each providig a coheret set of resposibilities Relatios Is part of Depeds o Is a Goals: Providig a blueprit for costructig the code Facilitatig impact aalysis Supportig traceability aalysis Supportig the defiitio of of work assigmets 27

28 Example: a C2 view 28

29 What we put i a C&C view compoets ad compoet types coectors ad coector types compoet iterfaces represetig poits of iteractio betwee a C&C compoet ad its eviromet coector iterfaces (or roles) systems as graphs of compoets ad coectors decompositio: a meas of represetig substructure ad selectively hidig complexity properties: attributes (such as executio time or thread priority) that allow to aalyze the performace or reliability of a system styles: defiig a vocabulary of compoet ad coector types together with rules for how istaces of those types ca be combied to form a architecture i a give style. Commo styles iclude pipe-ad-filter, cliet-server, ad publish-subscribe 29

30 Architectural views ad cocers

31 Pre-rutime vs rutime views Architectural views ca be classified ito: Pre-rutime views: Module ad some Allocatio views. E.g. a implemetatio structure where implemetatio files are mapped to a file structure Rutime views: Compoet-ad-coector (C2) ad some Allocatio views. E.g. a deploymet view, ivolvig mobile code (e.g. mobile agets)

32 Researcher vs practitioers The researchers commuity i the academia The practitioers commuity i the idustry use differet approaches to describe software architectures

33 Researchers: use ADL Researchers advocates usig architecture descriptio laguages (ADLs), which represet formal otatios for describig architectures i terms of coarse-graied compoets ad coectors ADLs are usually domai-specific laguages ADLs provide solid support for formal verificatio ad correctio but it are cosiderably more difficult to use tha UML

34 ADL: examples ACME (ACMEStudio) Darwi Archimate 34

35 Practitioers: use UML UML is a very geeral purpose modelig laguage, as it ca be used for ay software product ad eve for hardware systems UML has become a stadard de facto for documetig software systems UML 2.0 icludes some extesios from the ADL world UML has bee exteded to SysML for documetig system egieerig artfacts

36 Example: compoet diagram A compoet diagram for a large system might iclude: Presetatio. The compoet that provides access to the user, typically ruig o a Web browser. Web service. Provides coectio betwee cliets ad servers. Use case cotrollers. Coduct the user through each sceario. Busiess core. Cotais classes based o the requiremets model, implemets the key operatios, ad imposes busiess costraits. Database. Stores the busiess objects. Loggig ad error hadlig compoets. 36

37 UML: disadvatages The descriptios ca be ambigous Weak tool support for detectig icosistecies Iability to establish traceability betwee desig ad code Icomplete architectural details (most of the times reverse egieerig is eeded to detect them) Lack of a architectural theory: which views are more importat to represet?

38 The theory of sw architectig The theory of sw architectig studies how architectures are described or built Architectural models (eg. UML/SysML) Architectural tools (eg. Archi, ACMEstudio) Architectural mechaisms i programmig models (eg. Coordiatio-based or aget-based) 38

39 Typical architectures to study World wide web Mobile applicatios (eg. Games + advertisig) Cloud-based services (eg. Elastic clouds) Multiaget systems Adaptive systems Software ecosystems (eg. App Store) Social applicatios (eg. Facebook, Twitter) Embedded social software (eg. Traffic maagemet based o social recommedatios) 39

40 Architectural frameworks Architectural frameworks are methods for creatig, iterpretig, aalyzig ad usig architectural models withi a domai of applicatio or a stakeholder commuity Kruchte s 4+1 Views framework Hofmeister & Nord & Soi s framework Rozaski & Woods framework Clemets & Bass framework C4 framework by Simo Brow TOGAF framework

41 Which views are available? 41

42 Which views are more useful? A architect usually cosiders at least four perspectives of the system: 1. How is it structured as a set of code uits? Module Views 2. How is it structured as a set of elemets that have rutime presece? Rutime Views 3. How are artifacts orgaized i the file system ad how is the system deployed to hardware? Deploymet Views 4. What are the data etities ad their relatioships? Data Model 42

43 Views (Krutche 4+1) pkruchte.wordpress.com/architecture/ 43

44 Logical view 44

45 Physical view 45

46 Siemes approach Soi, Nord, ad Hofmeister of Siemes Corporate Research described some views of software architectures they observed i use i idustrial practice The coceptual view describes a system i terms of its major desig elemets ad the relatioships amog them The module itercoectio view combies two orthogoal structures: fuctioal decompositio ad layers The executio view describes the dyamic structure of a system Fially, the code view describes how the source code, biaries, ad libraries are orgaized i the developmet eviromet 46

47 Rozaski ad Woods approach Cotext viewpoit: describes the relatioships, depedecies, ad iteractios betwee the system ad its eviromet (the people, systems, ad exteral etities with which it iteracts). Fuctioal viewpoit: models the rutime elemets which deliver fuctioality, icludig their resposibilities, iterfaces ad iteractios Iformatio viewpoit: how the architecture stores, maipulates, maages, ad distributes iformatio Cocurrecy viewpoit: state-related structure ad costraits Developmet viewpoit: module orgaizatio ad related tools Deploymet viewpoit: physical eviromet i which the system rus Operatioal viewpoit: how the system will be operated, admiistered, 47

48 Rozaski ad Woods viewpoits Cotext Viewpoit Fuctioal Viewpoit Developmet Viewpoit Iformatio Viewpoit Deploymet Viewpoit Cocurrecy Viewpoit Operatioal Viewpoit 48

49 Perspectives ad views (Rozaski & Woods) 49

50 Impact of perspectives o viewpoits (Rozaski & Woods) Viewpoits Security Performace Availability Evolutio Cotext High Low Medium High Fuctioal Medium Medium Low High Iformatio Medium Medium Low High Cocurrecy Low High Medium Medium Developmet Medium Low Low High Deploymet High High High Low Operatioal Medium Low Medium Low 50

51 Example: most importat views for typical system types (Rozaski & Woods) Iformatio system Middleware Military if. system High volume Web portal Etreprise package Cotext High Low High Medium Medium Fuctioal High High Low High High Iformatio Medium Low High Medium Medium Cocurrecy Low High Low Medium variable Developmet High High Low High High Deploymet High High High High High Operatioal variable Low Medium Medium High 51

52 Relatioships amog views (Rozaski & Woods) 52

53 Depedecies amog views (Rozaski & Woods) 53

54 C4 (cotexts cotaiers compoets classes) Cotext: a simple block diagram showig your system as a box i the cetre, surrouded by its users ad the other systems that it iterfaces with A cotaier is aythig that ca host code or data; it s a executio eviromet or data storage The compoets diagram is used to zoom i ad decompose a cotaier The class diagram is a optioal level of detail used to explai how a particular patter or compoet will be (or has bee) implemeted. 54

55 Cotext 55

56 Cotaiers 56

57 Compoets 57

58 Clemets ad Bass approach Module views: orgaizatio of source code Compoets-ad-coectors views: descriptio of the mai fuctioal parts of a system ad of their depedecies Allocatio views: mappig betwee software ad physical compoets wiki.sei.cmu.edu/sad 58

59 Depedecies amog views (Clemets ad Bass) Architectural descriptio C&C views <<implemet>> C1 <<maifest>> Structural views Allocatio views C1 <<build>> <<artifact>> C1.jar <<deploy>> <<host>> PC <<executio ev>> JVM 59

60 Views ad stakeholders 60

61 Coclusios Views ca be orgaized i three differet categories: Module: module views represet structures icludig uits of fuctioality as elemets. E.g. module decompositio ad the class iheritace view Compoet-ad-coector: represet structures cotaiig rutime elemets such as processes ad threads. E.g. cocurrecy ad commuicatio processes views Allocatio: represet structures ivolvig assigmet relatios. E.g. I a deploymet structure, software elemets are assiged to hardware elemets

62 Summary Creatig a software architecture starts from o fuctioal qualities, the we deal with features ad fuctios Differet architectural theories prescribe differet views ad approaches to the descriptio of software architectures Software architecture is a matter of social cosesus, its descriptio has the goal to facilitate the cosesus 62

63 Self test What is a architectural view? Which are the mai approches to describig a software architecture? What is the C2 view? Describe the approach by Rozaski ad Woods Describe some depedecies amog views 63

64 Refereces Bass, Sw architecture i practice, 3ed. AW 2013 Rozaski, Software Systems Architecture, 2ed. AW 2012 Bass, Documetig Software Architectures, 2ed. AW 2010 Taylor, Foudatios of Software Architecture, Wiley 2009 Spiellis, Beautiful Architecture, O Reilly

65 Examples of software architecture models aosabook.org/e/idex.html Architecture of ope source systems delftswa.github.io Delft studets o Software architecture 65

66 Sites wiki.sei.cmu.edu/sad aosabook.org/e/idex.html eterprise-architecture-wiki.l stal.blogspot.com softwarearchitectureze.blogspot.com 66

67 Questios?