Lecture10
CopyrightRichardN.Taylor,NenadMedvidovic,andEricM.Dashofy.Allrightsreserved.
Software ModelingandNotations
SoftwareArchitecture Architecture: Foundations, Theory, and Practice
ContinuingOurSurvey
Genericapproaches x Naturallanguage x PowerPointstylemodeling x UML,theUnifiedModelingLanguage Earlyarchitecturedescriptionlanguages x Darwin x Rapide x Wright Domainandstylespecificlanguages x Koala x Weaves x AADL Extensiblearchitecturedescriptionlanguages x Acme x ADML x xADL
2
Software Architecture: Foundations, Theory, and Practice
ContinuingOurSurvey
Genericapproaches x Naturallanguage x PowerPointstylemodeling x UML,theUnifiedModelingLanguage Earlyarchitecturedescriptionlanguages x Darwin x Rapide x Wright Domainandstylespecificlanguages x Koala x Weaves x AADL Extensiblearchitecturedescriptionlanguages x Acme x ADML x xADL
3
Software Architecture: Foundations, Theory, and Practice
EarlyArchitectureDescription Languages
EarlyADLsproliferatedinthe1990sandexploredways tomodeldifferentaspectsofsoftwarearchitecture x Manyemergedfromacademia x Focusonstructure:components,connectors, interfaces,configurations x Focusonformalanalysis x Noneusedactivelyinpracticetoday,toolsupporthas waned Ideasinfluencedmanylatersystems,though
4
Software Architecture: Foundations, Theory, and Practice
Darwin
Generalpurposelanguagewithgraphicalandtextual visualizationsfocusedonstructuralmodelingofsystems Advantages x Simple,straightforwardmechanismformodelingstructural dependencies x Interestingwaytospecifyrepeatedelementsthrough programmaticconstructs x Canbemodeledinpicalculusforformalanalysis x Canspecifyhierarchical(i.e.,composite)structures Disadvantages x Limitedusefulnessbeyondsimplestructuralmodeling x Nonotionofexplicitconnectors Althoughcomponentscanactasconnectors
5
Software Architecture: Foundations, Theory, and Practice
DarwinExample
component DataStore{ provide landerValues; } component Calculation{ require landerValues; provide calculationService; } component UserInterface{ require calculationService; require landerValues; } component LunarLander{ inst U: UserInterface; C: Calculation; D: DataStore; bind C.landerValues -- D.landerValues; U.landerValues -- D.landerValues; U.calculationService -- C.calculationService; }
Canonical Textual Visualization
Graphical Visualization
6
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2010 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
ProgrammaticDarwinConstructs
component WebServer{ provide httpService; } component WebClient{ require httpService; } component WebApplication(int numClients){ inst S: WebServer; array C[numClients]: WebClient; forall k:0..numClients-1{ inst C[k] @ k; bind C[k].httpService -- S.httpService; } }
7
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2010 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
DarwinEvaluation
Scopeandpurpose
x
Basicelements
x
Modelingsoftwarestructure Components,interfaces, configurations,hierarchy Limitedsupportthrough programmaticconstructs
Style
x
Static&DynamicAspects
x
DynamicModels
x
Mostlystaticstructure;some additionalsupportfor dynamicaspectsthrough lazyanddynamic instantiation/binding N/A N/A
Ambiguity x Rigorous,butstructuralelements canbeinterpretedinmanyways Accuracy x Picalculusanalysis Precision x Modelerschooseappropriate levelofdetailthroughhierarchy Viewpoints x Structuralviewpoints Viewconsistency x N/A
NonFunctionalAspects
x
8
Software Architecture: Foundations, Theory, and Practice
Rapide
Languageandtoolsetforexploringdynamicpropertiesof systemsofcomponentsthatcommunicatethroughevents Advantages x Uniqueandexpressivelanguagefordescribing asynchronouslycommunicatingcomponents x Toolsetsupportssimulationofmodelsandgraphical visualizationofeventtraces Disadvantages x Nonaturalorexplicitmappingtoimplementedsystems x Highlearningcurve x Importanttoolsupportisdifficulttorunonmodern machines HasmorphedintotheCEPproject,however
9
Software Architecture: Foundations, Theory, and Practice
RapideExample
type DataStore is interface action in SetValues(); out NotifyNewValues(); behavior begin SetValues => NotifyNewValues();; end DataStore; type Calculation is interface action in SetBurnRate(); out DoSetValues(); behavior action CalcNewState(); begin SetBurnRate => CalcNewState(); DoSetValues();; end Calculation; type Player is interface action out DoSetBurnRate(); in NotifyNewValues(); behavior TurnsRemaining : var integer := 1; action UpdateStatusDisplay(); action Done(); 10
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
RapideExample(contd)
type DataStore is interface action in SetValues(); out NotifyNewValues(); behavior begin begin (start or UpdateStatusDisplay) where \ SetValues => NotifyNewValues();; ($TurnsRemaining > 0) => \ end DataStore; if ( $TurnsRemaining > 0 ) then \ TurnsRemaining := $TurnsRemaining - 1; \ type Calculation is interface DoSetBurnRate(); \ action in SetBurnRate(); end if;; out DoSetValues(); NotifyNewValues => UpdateStatusDisplay();; behavior UpdateStatusDisplay where $TurnsRemaining == 0 \ action CalcNewState(); => Done();; begin end UserInterface; SetBurnRate => CalcNewState(); DoSetValues();; end Calculation; architecture lander() is P1, P2 : Player; type Player is interface C : Calculation; action out DoSetBurnRate(); D : DataStore; in NotifyNewValues(); connect behavior P1.DoSetBurnRate to C.SetBurnRate; TurnsRemaining : var integer := 1; P2.DoSetBurnRate to C.SetBurnRate; action UpdateStatusDisplay(); C.DoSetValues to D.SetValues; action Done(); D.NotifyNewValues to P1.NotifyNewValues(); D.NotifyNewValues to P2.NotifyNewValues(); end LunarLander;
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2010 John Wiley & Sons, Inc. Reprinted with permission.
11
Software Architecture: Foundations, Theory, and Practice
SimulationOutput
1-player 2-player
12
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2010 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
RapideEvaluation
Scopeandpurpose
x
Basicelements
x
Interactionsbetween componentscommunicating withevents Structures,components/ interfaces,behaviors N/A
Style
x x
Static&DynamicAspects DynamicModels
x
Staticstructureanddynamic behaviorcomodeled Sometoolsprovidelimited animationcapabilities
NonFunctionalAspects x N/A
Ambiguity x Welldefinedsemanticslimit ambiguity Accuracy x Compilerschecksyntax, simulatorscanbeusedto checksemanticsalthough simulationresultsarenon deterministicandnon exhaustive Precision x Detailedbehavioralmodeling possible Viewpoints x Singlestructural/behavioral viewpoint Viewconsistency x N/A 13
Software Architecture: Foundations, Theory, and Practice
Wright
AnADLthatspecifiesstructureandformalbehavioral specificationsforinterfacesbetweencomponentsand connectors Advantages x StructuralspecificationsimilartoDarwinorRapide x Formalinterfacespecificationscanbetranslated automaticallyintoCSPandanalyzedwithtools Candetectsubtleproblemse.g.,deadlock Disadvantages x Highlearningcurve x Nodirectmappingtoimplementedsystems x Addressesasmallnumberofsystemproperties relativetocostofuse
14
Software Architecture: Foundations, Theory, and Practice
WrightExample
Component DataStore Port getValues (behavior specification) Port storeValues (behavior specification) Computation (behavior specification) Component Calculation Port getValues (behavior specification) Port storeValues (behavior specification) Port calculate (behavior specification) Computation (behavior specification) Component UserInterface Port getValues (behavior specification) Port calculate (behavior specification) call return Caller[] Computation (behavior specification) call return Callee[] Connector Call Caller = Role Caller .call Callee.call Glue Role Callee =return Caller.return Glue []Callee. [] Glue =
15
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
WrightExample
16
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2010 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
WrightEvaluation
Scopeandpurpose
x
Basicelements
x
Structures,behaviors,and Ambiguity stylesofsystemscomposed x Welldefinedsemanticslimit ofcomponents& ambiguity connectors
Style
x
Components,connectors, interfaces,attachments, styles Supportedthrough predicatesoverinstance models Staticstructuralmodels annotatedwithbehavioral specifications N/A
Static&DynamicAspects
x
DynamicModels
x
NonFunctionalAspects x N/A
Accuracy x Wrightmodelscanbe translatedintoCSPfor automatedanalysis Precision x Detailedbehavioralmodeling possible Viewpoints x Singlestructural/behavioral viewpointplusstyles Viewconsistency x Stylecheckingcanbedone automatically
17
Software Architecture: Foundations, Theory, and Practice
DomainandStyleSpecificADLs
Notationswehavesurveyedthusfarhavebeen genericallyapplicabletomanytypesofsoftwaresystems Ifyourestrictthetargetdomain,youcanprovidemore advancedfeaturesand/orreducecomplexity x Welltalkalotmoreaboutdomainspecificsoftware engineeringlaterinthecourse
18
Software Architecture: Foundations, Theory, and Practice
Koala
Darwininspirednotationforspecifyingproductlinesof embeddedconsumerelectronicsdevices Advantages x Advancedproductlinefeaturesletyouspecifymany systemsinasinglemodel x Directmappingtoimplementedsystemspromotes designandcodereuse Disadvantages x Limitedtostructuralspecificationwithadditionalfocus oninterfaces
19
Software Architecture: Foundations, Theory, and Practice
KoalaExample
interface IDataStore{ void setAltitude(int altitudeInMeters); int getAltitude(); void setBurnRate(int newBurnRate); int getBurnRate(); ... }
Single system
Product line of two systems20
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2010 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
KoalaEvaluation
Scopeandpurpose
x
Basicelements
x
Structuresandinterfacesof productlinesofcomponent basedsystems Components,interfaces, elementsforvariation points:switches,diversity interfaces,etc. Productlinesmightbeseen asverynarrowstyles
Style
x
Static&DynamicAspects
x
DynamicModels
x
Staticstructureonly N/A
NonFunctionalAspects x N/A
Ambiguity x Closemappingsto implementationlimitambiguity Accuracy x Closemappingsto implementationsshouldreveal problems Precision x Structuraldecisionsarefully enumeratedbutotheraspects leftout Viewpoints x Structuralviewpointwith explicitpointsofvariation Viewconsistency x N/A
21
Software Architecture: Foundations, Theory, and Practice
Weaves
Anarchitecturalstyleandnotationformodelingsystems ofsmallgraintoolfragmentsthatcommunicatethrough dataflowsofobjects Advantages x Extremelyoptimizednotation EvensimplerthanDarwindiagrams x Closemappingtoimplementedsystems Disadvantages x Addressesstructureanddataflowsonly
22
Software Architecture: Foundations, Theory, and Practice
WeavesExample
Generic Weaves System
Lunar Lander in Weaves
23
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2010 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
WeavesEvaluation
Scopeandpurpose
x
Basicelements
x
Structuresofcomponentsand connectorsintheWeaves style Components,queues,directed interconnections Weavesstyleimplicit Staticstructureonly
Style
x x
Static&DynamicAspects DynamicModels
x
NonFunctionalAspects x N/A
N/A,althoughthereisa11 correspondencebetween modelandimplementation elements
Ambiguity x MeaningsofWeaveselements arewelldefinedalthough importantelements(e.g., protocols)aresubjectto interpretation Accuracy x Syntactic(e.g.,structural)errors easytoidentify Precision x Structuraldecisionsarefully enumeratedbutotheraspectsleft out Viewpoints x Structuralviewpoint Viewconsistency x N/A 24
Software Architecture: Foundations, Theory, and Practice
AADL:TheArchitectureAnalysis& DesignLanguage
Notationandtoolsetformodelinghardware/softwaresystems, particularlyembeddedandrealtimesystems Advantages x Allowsdetailedspecificationofbothhardwareandsoftware aspectsofasystem x Automatedanalysistoolscheckinterestingendtoend propertiesofsystem Disadvantages x Verbose;largeamountofdetailrequiredtocaptureevensimple systems x EmergingtoolsupportandUMLprofilesupport
25
Software Architecture: Foundations, Theory, and Practice
AADL(Partial)Example
data lander_state_data end lander_state_data; bus lan_bus_type end lan_bus_type; bus implementation lan_bus_type.ethernet properties Transmission_Time => 1 ms .. 5 ms; Allowed_Message_Size => 1 b .. 1 kb; end lan_bus_type.ethernet; system calculation_type features network : requires bus access lan_bus.calculation_to_datastore; request_get : out event port; response_get : in event data port lander_state_data; request_store : out event port lander_state_data; response_store : in event port; end calculation_type; system implementation calculation_type.calculation subcomponents the_calculation_processor : processor calculation_processor_type; the_calculation_process : process calculation_process_type.one_thread;
26
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
AADL(Partial)Example
data lander_state_dataconnections end lander_state_data; bus access network -> the_calculation_processor.network; bus lan_bus_type event data port response_get -> end lan_bus_type; the_calculation_process.response_get; event port the_calculation_process.request_get -> bus implementation lan_bus_type.ethernet request_get; properties event data port response_store -> Transmission_Time => 1 ms .. 5 ms;the_calculation_process.response_store; Allowed_Message_Sizeproperties 1 kb; => 1 b .. end lan_bus_type.ethernet; Actual_Processor_Binding => reference system calculation_type the_calculation_processor applies to features the_calculation_process; network : requires bus access end calculation_type.calculation; lan_bus.calculation_to_datastore; request_get : outprocessor calculation_processor_type event port; response_get : in features event data port lander_state_data; request_store : out event port requires bus access network : lander_state_data; response_store : in event port; lan_bus.calculation_to_datastore; end calculation_type; end calculation_processor_type; system implementation process calculation_process_type calculation_type.calculation subcomponents features the_calculation_processor : request_get : out event port; processor response_get calculation_processor_type; : in event data port lander_state_data; the_calculation_processequest_store : out event data port lander_state_data; r : process calculation_process_type.one_thread;port; response_store : in event end calculation_process_type;
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2008 John Wiley & Sons, Inc. Reprinted with permission.
27
Software Architecture: Foundations, Theory, and Practice
AADL(Partial)Example
data lander_state_dataconnections end lander_state_data; bus access network -> the_calculation_processor.network; thread response_get -> bus lan_bus_type event data portcalculation_thread_type features end lan_bus_type; the_calculation_process.response_get; equest_get : out event port; event portrthe_calculation_process.request_get -> response_get bus implementation lan_bus_type.ethernet request_get; : in event data port lander_state_data; rport response_store -> equest_store : out event data port lander_state_data; properties event data response_store : in event port; Transmission_Time => 1 ms .. 5 ms;the_calculation_process.response_store; properties Allowed_Message_Sizeproperties 1 kb; => 1 b .. Dispatch_Protocol => periodic; end lan_bus_type.ethernet; Actual_Processor_Binding => reference end the_calculation_processor applies to calculation_thread_type; system calculation_type process implementation calculation_process_type.one_thread features the_calculation_process; subcomponents network : requires bus access end calculation_type.calculation; calculation_thread : thread client_thread_type; lan_bus.calculation_to_datastore; connections request_get : outprocessor calculation_processor_type event port; event data port response_get -> response_get : in features event data port lander_state_data; alculation_thread.response_get; request_store : out event port requires buscaccess network : lander_state_data; : response_store in event port; event port calculation_thread.request_get -> request_get; lan_bus.calculation_to_datastore; event port response_store -> end calculation_type; end calculation_processor_type; calculation_thread.response_store; event data port system implementation process calculation_process_type calculation_type.calculationrequest_store -> request_store; properties subcomponents features D the_calculation_processor : request_getispatch_Protocolport; : out event => Periodic; Period in event data port lander_state_data; processor response_get calculation_processor_type; : => 20 ms; end the_calculation_processequest_store : out event data port lander_state_data; r : process calculation_process_type.one_thread; calculation_process_type.one_thread;port; response_store : in event end calculation_process_type;
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2010 John Wiley & Sons, Inc. Reprinted with permission.
28
Software Architecture: Foundations, Theory, and Practice
AADLExampleExplainedaBit
Notethelevelofdetailatwhichthesystemisspecified x Acomponent(calculation_type.calculation)runson x aphysicalprocessor(the_calculation_processor),which runs x aprocess(calculation_process_type.one_thread),whichin turncontains x asinglethreadofcontrol(calculation_thread),allofwhich canmaketwokindsofrequestresponsecallsthrough x ports(request_get/response_get, request_store/response_store)over x anEthernetbus(lan_bus_type.Ethernet). Allconnectedthroughcomposition,portmapping,andsoon ThisdetailiswhatgivesAADLitspowerandanalyzability
29
Software Architecture: Foundations, Theory, and Practice
AADLEvaluation
Scopeandpurpose
x
Basicelements
x
Interconnectedmultilevel systemsarchitectures Multitudecomponents, threads,hardware elements,configurations, mappings N/A
Style
x x
Static&DynamicAspects
DynamicModels
x
Primarilystaticstructurebut additionalpropertiesspecify dynamicaspects N/A
NonFunctionalAspects x N/A
Ambiguity x Mostelementshaveconcrete counterpartswithwellknown semantics Accuracy x Structuralaswellasother interestingpropertiescanbe automaticallyanalyzed Precision x Manycomplexinterconnected levelsofabstractionand concerns Viewpoints x Manyviewpointsaddressing differentaspectsofthesystem Viewconsistency x Mappingsandrefinementcan generallybeautomatically checkedordonotoverlap
30
Software Architecture: Foundations, Theory, and Practice
ExtensibleADLs
Thereisatensionbetween x TheexpressivenessofgeneralpurposeADLsand x Theoptimizationandcustomizationofmorespecialized ADLs Howdowegetthebestofbothworlds? x Usemultiplenotationsintandem (Difficulttokeepconsistent,oftenmeansexcessive redundancy) x OverloadanexistingnotationorADL(e.g.,UMLprofiles) Increasesconfusion,doesntworkwellifthecustom featuresdontmapnaturallyontoexistingfeatures x AddadditionalfeatureswewanttoanexistingADL ButexistingADLsprovidelittleornoguidanceforthis ExtensibleADLsattempttoprovidesuchguidance
31
Software Architecture: Foundations, Theory, and Practice
Acme
EarlygeneralpurposeADLwithsupportfor extensibilitythroughproperties Advantages x Structuralspecificationcapabilitiessimilarto Darwin x Simplepropertystructureallowsforarbitrary decorationofexistingelements x ToolsupportwithAcmeStudio Disadvantages x Nowaytoaddnewviews x Propertyspecificationscanbecomeextremely complexandhaveentirelyseparate syntax/semanticsoftheirown
32
Software Architecture: Foundations, Theory, and Practice
AcmeExample
//Global Types Property Type returnsValueType = bool; Connector Type CallType = { Roles { callerRole; calleeRole; }; Property returnsValue : returnsValueType; }; System LunarLander = { //Components Component DataStore = { Ports { getValues; storeValues; } }; Component Calculation = { Ports { calculate; getValues; storeValues; } }; Component UserInterface = { Ports { getValues; calculate; } }; // Connectors Connector UserInterfaceToCalculation : CallType { Roles { callerRole; calleeRole; }; Property returnsValue : returnsValueType = true; } Connector UserInterfaceToDataStore : CallType { Roles { callerRole; calleeRole; }; Property returnsValue : returnsValueType = true; }
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2010 John Wiley & Sons, Inc. Reprinted with permission.
33
Software Architecture: Foundations, Theory, and Practice
Connector CalculationToDataStoreS : CallType { Roles { callerRole; calleeRole; }; Property returnsValue : returnsValueType = false; } //Global Types Connector CalculationToDataStoreG : CallType { Property Type returnsValueType = bool; Roles { callerRole; calleeRole; }; Connector Type CallType = { Property returnsValue : returnsValueType = true; Roles { callerRole; calleeRole; }; } Property returnsValue : returnsValueType; Attachments { }; UserInterface.getValues to UserInterfaceToDataStore.callerRole; System LunarLander = { UserInterfaceToDataStore.calleeRole to //Components DataStore.getValues; Component DataStore = { UserInterface.getValues to Ports { getValues; storeValues; } UserInterfaceToDataStore.callerRole; }; UserInterfaceToDataStore.calleeRole to Component Calculation = { DataStore.getValues; Ports { calculate; getValues; storeValues; } UserInterface.calculate to }; UserInterfaceToCalculation.callerRole; Component UserInterface = { UserInterfaceToCalculation.calleeRole to Ports { getValues; calculate; } Calculation.calculate; }; Calculation.storeValues to CalculationToDataStoreS.callerRole; // Connectors CalculationToDataStoreS.calleeRole to Connector UserInterfaceToCalculation : CallType { DataStore.storeValues; Roles { callerRole; calleeRole; }; Calculation.getValues to Property returnsValue : returnsValueType CalculationToDataStoreG.callerRole; = true; } CalculationToDataStoreG.calleeRole to Connector UserInterfaceToDataStore : CallType { DataStore.getValues; Roles { callerRole; calleeRole; }; }; Property returnsValue : returnsValueType = true; } 34 }
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2010 John Wiley & Sons, Inc. Reprinted with permission.
AcmeExample
Software Architecture: Foundations, Theory, and Practice
Connector CalculationToDataStoreS : CallType { Roles { callerRole; calleeRole; }; //Global Types Property returnsValue : returnsValueType = false; Property Type returnsValueType = bool; } Connector Type CallType = { Connector CalculationToDataStoreG : CallType { Roles { callerRole; calleeRole; }; R Property returnsValue : returnsValueType; oles { callerRole; calleeRole; }; Property returnsValue : returnsValueType = true; }; } Attachments { System LunarLander = { Property Type StoreType = enum { file, UserInterface.getValues to //Components relationalDatabase, UserInterfaceToDataStore.callerRole; objectDatabase }; Component DataStore = { UserInterfaceToDataStore.calleeRole to Ports { getValues; storeValues; } Component DataStore = DataStore.getValues; { }; Ports { UserInterface.getValues to Component Calculation = { getValues; storeValues; UserInterfaceToDataStore.callerRole; Ports { calculate; getValues; storeValues; } } UserInterfaceToDataStore.calleeRole to }; Property storeType :DataStore.getValues; StoreType = Component UserInterface = { relationalDatabase; UserInterface.calculate to Ports { getValues; calculate; } Property tableName :UserInterfaceToCalculation.callerRole; String = LanderTable; }; Property numReplicas: int = 0; UserInterfaceToCalculation.calleeRole to }; Calculation.calculate; // Connectors Calculation.storeValues to Connector UserInterfaceToCalculation : CallType { CalculationToDataStoreS.callerRole; Roles { callerRole; calleeRole; }; CalculationToDataStoreS.calleeRole to Property returnsValue : returnsValueType = true; DataStore.storeValues; } Calculation.getValues to Connector UserInterfaceToDataStore : CallType { CalculationToDataStoreG.callerRole; Roles { callerRole; calleeRole; }; CalculationToDataStoreG.calleeRole to Property returnsValue : returnsValueType = true; DataStore.getValues; } }; } 35
AcmeExtensions
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2010 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
AcmeEvaluation
Scopeandpurpose
x
Basicelements
x
Structuresofcomponents andconnectorswith extensibleproperties Components,connectors, interfaces,hierarchy, properties Throughtypesystem
Ambiguity
x
Accuracy
x
Meaningsofelementssubjectto someinterpretation,properties mayhavearbitrarylevelof rigor/formality Checkablesyntactically,viatype system,andpropertiesbyexternal tools Propertiescanincreaseprecision butcannotaddnewelements
Style
x x
Staticstructureismodeled Viewpoints natively,dynamicaspectsin x Structuralviewpointisnative, properties propertiesmightprovideadditional DynamicModels viewpoints x AcmeLiballows Viewconsistency programmaticmodel x Viaexternaltoolsthatmustbe manipulation developed NonFunctionalAspects
x
Static&DynamicAspects
Precision
x
Throughproperties
36
Software Architecture: Foundations, Theory, and Practice
ADML
EfforttostandardizetheconceptsinAcmeandleverage XMLasasyntacticbase Advantages x XMLparsersandtoolsreadilyavailable x Addedsomeabilitytoreasonabouttypesof propertieswithmetaproperties Disadvantages x Propertiesarestillnamevaluepairs x DidnottakeadvantageofXMLextension mechanisms
37
Software Architecture: Foundations, Theory, and Practice
ADMLExample
SimilartoAcme,exceptinanXMLformat
<Component ID=datastore name=Data Store> <ComponentDescription> <ComponentBody> <Port ID=getValues name=getValues/> <Port ID=storeValues name=storeValues/> </ComponentBody> </ComponentDescription> </Component>
38
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
xADL
ModularXMLbasedADLintendedtomaximize extensibilitybothinnotationandtools Advantages x Growingsetofgenericallyusefulmodules availablealready x ToolsupportinArchStudioenvironment x Userscanaddtheirownmodulesviawelldefined extensibilitymechanisms Disadvantages x Extensibilitymechanismscanbecomplexand increaselearningcurve x Heavyrelianceontools
39
Software Architecture: Foundations, Theory, and Practice
xADLExample
<types:component xsi:type="types:Component" types:id="myComp"> <types:description xsi:type="instance:Description"> MyComponent </types:description> <types:interface xsi:type="types:Interface" types:id="iface1"> <types:description xsi:type="instance:Description"> Interface1 </types:description> <types:direction xsi:type="instance:Direction"> inout </types:direction> </types:interface> </types:component>
40
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2010 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
xADLExample
<types:component xsi:type="types:Component" types:id="myComp"> <types:description xsi:type="instance:Description"> MyComponent </types:description> <types:interface xsi:type="types:Interface" types:id="iface1"> <types:description xsi:type="instance:Description"> Interface1 component{ </types:description> id = "myComp"; <types:direction xsi:type="instance:Direction"> description = "MyComponent"; inout interface{ </types:direction> id = "iface1"; </types:interface> description = "Interface1"; </types:component> direction = "inout"; } }
41
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2010 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
xADLExample
<types:component xsi:type="types:Component" types:id="myComp"> <types:description xsi:type="instance:Description"> MyComponent </types:description> <types:interface xsi:type="types:Interface" types:id="iface1"> <types:description xsi:type="instance:Description"> Interface1 component{ </types:description> id = "myComp"; <types:direction xsi:type="instance:Direction"> description = "MyComponent"; inout interface{ </types:direction> id = "iface1"; </types:interface> description = "Interface1"; </types:component> direction = "inout"; } }
42
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2010 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
xADLTools
Tools that implement Tools that implement xxADLsemantics ADL semantics
(Other Tools) (Other Tools)
use
Faadeinterface Fa ade interface for data binding for data binding library library wraps
xArchADT xArchADT
uses
Tree-based syntax- Tree-based syntax directed editor directed editor for xxADLdocuments for ADL documents
ArchEdit ArchEdit
Data Binding Library Data Binding Library
generates Provides object-oriented Provides object-oriented interface to xxADL interface to ADL documents documents uses
XML schema to XML schema to JJavadata ava data bbindinggenerator inding generator
Apigen Apigen
uses
(e.g., Crimson, Xerces) ) (e.g., Crimson, Xerces Manipulates XML documents Manipulates XML documents as data structure of elements as data structure of elements and attributes and attributes parses/edits edits
DOM Implementation DOM Implementation
Off-the-shelf XML Off-the-shelf XML ddevelopment evelopment environment environment
XML Spy XML Spy
parses
xADL 2.0 Schemas
validates
Off-the-shelf XML Off-the-shelf XML sschemavvalidator chema alidator
XSV XSV
43
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2010 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
ArchStudioEnvironment
44
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2010 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
xADLSchemas(Modules)
Schema Structure & Types Features Defines basic structural modeling of prescriptive architectures: components, connectors, interfaces, links, general groups, as well as types for components, connectors, and interfaces. Basic structural modeling of descriptive architectures: components, connectors, interfaces, links, general groups.
Instances
Mappings from structural element types (component Abstract Implementation types, connector types) to implementations. Mappings from structural element types to Java Java Implementation implementations. Allows structural elements to be declared optional included or excluded from an architecture depending Options on specified conditions. Variants Allows structural element types to be declared varianttaking on different concrete types depending on specified conditions. Defines version graphs; allows structural element types to be versioned through association with versions in version graphs.
Versions
45
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
xADLEvaluation
Scopeandpurpose
x
Basicelements
x
Modelingvarious architecturalconcernswith explicitfocusonextensibility
Ambiguity
x
Style
x x
Components,connectors, interfaces,links,options, variants,versions,,plus extensions
Accuracy
x
Baseschemasarepermissive; extensionsaddrigororformality ifneeded Correctnesscheckersincludedin ArchStudioanduserscanadd additionaltoolsthroughwell definedmechanisms Baseschemasareabstract, precisionaddedinextensions Severalviewpointsprovided natively,newviewpointsthrough extensions Checkablethroughexternaltools andadditionalconsistencyrules
46
Static&DynamicAspects
Limited,throughtypesystem Mostlystaticviewswith behavioranddynamic aspectsprovidedthrough extensions Modelscanbemanipulated programmatically Throughextensions
Precision
x
Viewpoints
x
DynamicModels
x
Viewconsistency
x
NonFunctionalAspects
x
Software Architecture: Foundations, Theory, and Practice
Caveat1
Theprecedingoverviewoptimizedforbreadthrather thandepth x Semanticsandcapabilitiesofmanyofthesenotations quitedeepandsubtle Someevenhaveentirebookswrittenaboutthem x Youareencouragedtoinvestigateindividualnotations moredeeply
47
Software Architecture: Foundations, Theory, and Practice
Caveat2
Somesystemsaredifficulttomodelintraditional ways x Agilesystemsthatarenotexplicitlydesigned abovethelevelofcodemodules x Extremelylarge,complex,ordynamicsystems (e.g.,theWeb) Canmodellimitedorlesscomplexaspects Canmodeloneinstanceofthesystem(e.g., oneWebapplication) Exploitregularity Modelthestyle Modeltheprotocols
48