Modelig a Software Architecture Paolo Ciacarii
Ageda Describig software architectures Architectural frameworks Models based o architectural laguages Models based o UML Mai architectural views 2
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
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
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 25010 Systems ad software Quality Requiremets ad Evaluatio) 5
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
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
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
Structure Behavior 9
Architectural views
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
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
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
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
Coceptual architecture view http://ruthmala.com/bytopic/architecture/coceptualarchitecture.htm 15
The architecture documet: template 1 2 3 4 5 6 Architectural goals Sigificat requiremets 1 2 Fuctioal Nofuctioal Decisios ad justificatios Key abstractios (Domai model) Architectural descriptio 1 2 3 4 Logical compoet model Process model Physical compoets ad layers Developmet model Deploymet model 16
The ISO Stadard 42010 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
A Coceptual Model of Architecture Descriptio http://www.iso-architecture.org/ieee-1471/cm/ 18
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
Template for a architectural view 20
Example: cotext view 21
Example: cotext view http://avadeurse.com/author/avadeurse/#cotet 22
Example: cotext view 23
24
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
Example: a module view 26
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
Example: a C2 view 28
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
Architectural views ad cocers
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)
Researcher vs practitioers The researchers commuity i the academia The practitioers commuity i the idustry use differet approaches to describe software architectures
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
ADL: examples ACME (ACMEStudio) Darwi Archimate 34
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
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. http://msd.microsoft.com/e-us/library/dd490886.aspx 36
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?
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
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
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
Which views are available? 41
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
Views (Krutche 4+1) pkruchte.wordpress.com/architecture/ 43
Logical view 44
Physical view 45
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
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, www.viewpoits-ad-perspectives.ifo/ 47
Rozaski ad Woods viewpoits Cotext Viewpoit Fuctioal Viewpoit Developmet Viewpoit Iformatio Viewpoit Deploymet Viewpoit Cocurrecy Viewpoit Operatioal Viewpoit 48
Perspectives ad views (Rozaski & Woods) 49
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
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
Relatioships amog views (Rozaski & Woods) 52
Depedecies amog views (Rozaski & Woods) 53
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. www.voxxed.com/blog/2014/10/simple-sketches-for-diagrammig-your-software-architecture/ 54
Cotext 55
Cotaiers 56
Compoets 57
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
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
Views ad stakeholders 60
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
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
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
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 2009 64
Examples of software architecture models www.ecs.csu.edu/~rligard/comp684/example2softarch.htm aosabook.org/e/idex.html Architecture of ope source systems delftswa.github.io Delft studets o Software architecture 65
Sites www.sei.cmu.edu/architecture wiki.sei.cmu.edu/sad www.iso-architecture.org www.viewpoits-ad-perspectives.ifo www.softwarearchitectureportal.org aosabook.org/e/idex.html eterprise-architecture-wiki.l www.bredemeyer.com/defiiti.htm www.booch.com/architecture www.ivecia.com/idex.html?/softwarearchitect/ stal.blogspot.com softwarearchitectureze.blogspot.com www.gaudisite.l 66
Questios?