ANALYZING SOFTWAREARCHITECTURES:A SEMANTIC MODELAli Mili, NJITAlpen Adria UniversitaetJune 15, 2012
PLAN    • Software Quality Attributes    • Software Architectures and          Architectural Styles    • Requirements for ...
SOFTWARE QUALITY ATTRIBUTESA talk on software architecture starts with a  discussion of software quality attributes… Why?...
SOFTWARE QUALITY ATTRIBUTESAttribute          Measure     DefinitionReliability        Hrs/days    Failure FreedomSafety  ...
Menu                                                 Reliability                                                 SafetySOF...
Menu                                                 Reliability                                                 SafetySOF...
Menu                                                 Reliability                                                 SafetySOF...
Menu                                                 Reliability                                                 SafetySOF...
PLAN    • Software Quality Attributes    • Software Architectures and          Architectural Styles    • Requirements for ...
SOFTWARE ARCHITECTURE ANDARCHITECTURAL STYLESSoftware architecture consists of the rules and principles for how a system i...
SOFTWARE ARCHITECTURE ANDARCHITECTURAL STYLESArchitectural Models: Used to document an architectural  design. Static stru...
SOFTWARE ARCHITECTURE ANDARCHITECTURAL STYLESThree important characteristics of an Architecture: Structure Communication...
SOFTWARE ARCHITECTURE ANDARCHITECTURAL STYLESSystem Structure Module Structure: Modules and Dependencies. Conceptual Str...
SOFTWARE ARCHITECTURE ANDARCHITECTURAL STYLESSystem Communication Hardware infrastructure, communication medium. Synchro...
SOFTWARE ARCHITECTURE ANDARCHITECTURAL STYLESSystem Control Procedure Call       Remote Procedure Call, Concurrent, Seq...
SOFTWARE ARCHITECTURE ANDARCHITECTURAL STYLESArchitectural Styles: Architecture Families, defined  by: Component Types, ...
SOFTWARE ARCHITECTURE ANDARCHITECTURAL STYLESArchitectural Styles: Different classifications, Independent Components, aut...
SOFTWARE ARCHITECTURE ANDARCHITECTURAL STYLESSoftware architecture as a prerequisite for reuse: Because a prerequisite fo...
SOFTWARE ARCHITECTURE ANDARCHITECTURAL STYLESSoftware architecture as a prerequisite for reuse: Because a prerequisite fo...
SOFTWARE ARCHITECTURE ANDARCHITECTURAL STYLESPre-architecture software reuse experiments: Large software repositories, S...
SOFTWARE ARCHITECTURE ANDARCHITECTURAL STYLESWhile software products in  general do not have a  common architecture, the  ...
SOFTWARE ARCHITECTURE AND ARCHITECTURAL STYLESAttribute          Architectural OptionReliability        Duplicate function...
PLAN     • Software Quality Attributes     • Software Architectures and           Architectural Styles     • Requirements ...
REQUIREMENTS FOR AN ARCHITECTURAL    DESCRIPTION LANGUAGE                                    24
REQUIREMENTS FOR AN ARCHITECTURAL    DESCRIPTION LANGUAGEAttribute       Sequential Arch.   Parallel Arch.Response Time   ...
REQUIREMENTS FOR AN ARCHITECTURAL    DESCRIPTION LANGUAGEGeneralizing this type of reasoning for: Arbitrary topologies, ...
REQUIREMENTS FOR AN ARCHITECTURAL    DESCRIPTION LANGUAGEADL         Author         Institution   YearACME        Garlan, ...
REQUIREMENTS FOR AN ARCHITECTURAL    DESCRIPTION LANGUAGEADL         Author       Institution        YearRapide      Luckh...
REQUIREMENTS FOR AN ARCHITECTURAL    DESCRIPTION LANGUAGERequirements for an Architectural Description  Language Support ...
REQUIREMENTS FOR AN ARCHITECTURAL    DESCRIPTION LANGUAGETo our surprise, none of the existing languages do  that. ACME d...
PLAN     • Software Quality Attributes     • Software Architectures and           Architectural Styles     • Requirements ...
ACME AND ACME+ACME Ontology Components       Ports   Connectors       Roles Systems Properties Representations Rep...
ACME AND ACME+ACME Ontology… Focus on: Components       Ports   Connectors       Roles Systems Properties Represent...
ACME AND ACME+Component                  Connector Computational               Mediates interaction  Element, or        ...
ACME AND ACME+                 35
ACME AND ACME+ACME Properties Representing extra-structural attributes, in an open-  ended manner, Arbitrary list of pro...
ACME AND ACME+                 37
ACME AND ACME+ACME+: Requirements, Formal definition of properties   From a selected catalog (response time, throughput,...
ACME AND ACME+Relationships between ports of a component,  relationships between roles of a connector. At a minimum, we w...
ACME AND ACME+When more than one port is involved (as in all of, or most of) we must also specify whether they are synchro...
ACME AND ACME+As for output ports, in addition to designating them as such, we also need to determine the degree of overla...
ACME AND ACME+Specified as part of a fundep statement (functional dependency), that specifies the relation between ports, ...
ACME AND ACME+Adequacy of the notation, availability of needed  information: Aegis Weapons System,       Allen, CMU, Pit...
PLAN     • Software Quality Attributes     • Software Architectures and           Architectural Styles     • Requirements ...
AN ATTRIBUTE GRAMMAR FOR ACME+We consider canonical architectures as architectures  that satisfy the following conditions:...
AN ATTRIBUTE GRAMMAR FOR ACME+Given a canonical architecture, we associate  attributes (in the sense of attribute grammars...
AN ATTRIBUTE GRAMMAR FOR ACME+Distinction between three concepts: System level properties: response time, throughput,  MT...
AN ATTRIBUTE GRAMMAR FOR ACME+While there is no one-to-one correspondence between component/ connector properties and port...
AN ATTRIBUTE GRAMMAR FOR ACME+Base Attribute Values        Attribute Values at Sink   source.outPort.RT = 0;      sink.i...
AN ATTRIBUTE GRAMMAR FOR ACME+How do we propagate the attribute values from the  source to the sink?Inductive rules: Atta...
AN ATTRIBUTE GRAMMAR FOR ACME+Propagation within components/ connectors (RT):   Component, Single input port, single outp...
AN ATTRIBUTE GRAMMAR FOR ACME+Multiple ports, roles (component, RT):   fundep {three2two,                input(allof(asyn...
AN ATTRIBUTE GRAMMAR FOR ACME+Multiple ports, roles (component, RT):   fundep {three2two,                input(anyof(asyn...
AN ATTRIBUTE GRAMMAR FOR ACME+Multiple ports, roles (component, RT):   fundep {three2two,                input(mostof(asy...
AN ATTRIBUTE GRAMMAR FOR ACME+Multiple ports, roles (component, RT):   fundep {three2two,                input(xxxxx(sync...
PLAN     • Software Quality Attributes     • Software Architectures and           Architectural Styles     • Requirements ...
COMPILING ACME+ ARCHITECTURESACME+: ACME     - ACME-style properties     + fundep statements, along with their properti...
COMPILING ACME+ ARCHITECTURESAvailable Functionalities, Computer system level Properties from component/  connector level...
PLAN     • Software Quality Attributes     • Software Architectures and           Architectural Styles     • Requirements ...
DEMO: AUTOMATED ARCHITECTURAL    ANALYSISAegis Weapons System                                60
PLAN     • Software Quality Attributes     • Software Architectures and           Architectural Styles     • Requirements ...
CONCLUSION: SUMMARY ANDPROSPECTSSummary Software qualities cannot be achieved  simultaneously, and must be prioritized. ...
CONCLUSION: SUMMARY ANDPROSPECTSProspects Extend to non canonical architectures (cyclic  topologies, concurrent processin...
PLAN     • Software Quality Attributes     • Software Architectures and           Architectural Styles     • Requirements ...
REFERENCES Lamia Labed Jilani, Imen Derbel, Khaled Bsaies,  Hamdi Nasreddine, Ali Mili. Reasoning About  Quantitative Arc...
PLAN     • Software Quality Attributes     • Software Architectures and           Architectural Styles     • Requirements ...
Upcoming SlideShare
Loading in …5
×

Analyzing Software Architectures: A Semantic Model

1,853 views

Published on

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,853
On SlideShare
0
From Embeds
0
Number of Embeds
311
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Analyzing Software Architectures: A Semantic Model

  1. 1. ANALYZING SOFTWAREARCHITECTURES:A SEMANTIC MODELAli Mili, NJITAlpen Adria UniversitaetJune 15, 2012
  2. 2. PLAN • Software Quality Attributes • Software Architectures and Architectural Styles • Requirements for An Architectural Description Language • ACME and ACME+ • An Attribute Grammar for ACME+ • Compiling ACME+ Architectures2 • Demo: Automated Architectural Analysis • Conclusion: Summary and Prospects • References
  3. 3. SOFTWARE QUALITY ATTRIBUTESA talk on software architecture starts with a discussion of software quality attributes… Why? Architectural decisions determine quality (non functional) attributes.  Whereas design/ programming decisions determine functional attributes/ properties. Architectural decisions are taken according to selected attributes.  Prioritizing attributes as a major system level decision. We cannot have them all. Study of software architectures inseparable from the study of quality (non functional) attributes. 3
  4. 4. SOFTWARE QUALITY ATTRIBUTESAttribute Measure DefinitionReliability Hrs/days Failure FreedomSafety Hrs/days Freedom from catastrophic failureSecurity Hrs/days Freedom from security breachesAvailability Percent. Ratio of operational timeThroughput Trans/sec Volume of processingMaintainability PM/loc yr Unitary Cost of Maintenance / yearResponse Time Sec Time between query and responsePortability PM/ migr Ease of migration between platformsFailure Prob Prob Probability of failure/ unit of op timeEase of Use Qualitat. Ease of Use, even an adult can use itEase of Learning Hrs Required Effort to learn 4Modularity Cpl+Coh Coupling and Cohesion
  5. 5. Menu Reliability SafetySOFTWARE QUALITY ATTRIBUTES SecurityFrom application domain to quality attributes. Availability Application Attribute Throughput Maintainability Heart Monitor Response Time E-commerce Portability Online Banking Failure Prob Batch Banking Ease of Use Ease of Learning Social Media Modularity Incomplete Specs 5 Compiler
  6. 6. Menu Reliability SafetySOFTWARE QUALITY ATTRIBUTES SecurityFrom application domain to quality attributes. Availability Application Attribute Throughput Maintainability Heart Monitor Safety Response Time E-commerce Availability Portability Online Banking Reliability Failure Prob Batch Banking Throughput Ease of Use Ease of Learning Social Media Security Modularity Incomplete Specs Maintainability 6 Compiler Portability
  7. 7. Menu Reliability SafetySOFTWARE QUALITY ATTRIBUTES SecurityFrom application domain to quality attributes. Availability Application Attribute Throughput Maintainability Heterogeneous App Response Time Flight Info Server Portability US Census 2020 Failure Prob Office Automation Ease of Use Ease of Learning Flight Control Modularity Flight Simulator 7 Database Query
  8. 8. Menu Reliability SafetySOFTWARE QUALITY ATTRIBUTES SecurityFrom application domain to quality attributes. Availability Application Attribute Throughput Maintainability Heterogeneous App Modularity Response Time Flight Info Server Ease of use Portability US Census 2020 Throughput Failure Prob Office Automation Ease of Learning Ease of Use Ease of Learning Flight Control Safety Modularity Flight Simulation Reliability 8 Database Query Response Time
  9. 9. PLAN • Software Quality Attributes • Software Architectures and Architectural Styles • Requirements for An Architectural Description Language • ACME and ACME+ • An Attribute Grammar for ACME+ • Compiling ACME+ Architectures9 • Demo: Automated Architectural Analysis • Conclusion: Summary and Prospects • References
  10. 10. SOFTWARE ARCHITECTURE ANDARCHITECTURAL STYLESSoftware architecture consists of the rules and principles for how a system is decomposed into its component parts, the rationale for how responsibilities are allocated among those parts, and the policies and mechanisms that coordinate the interactions between those parts as they collaborate to fulfill the purpose of the system. Software architecture is at once the partitioning of a system into its significant elements, and the organization and integration of those elements into a cohesive whole. 10
  11. 11. SOFTWARE ARCHITECTURE ANDARCHITECTURAL STYLESArchitectural Models: Used to document an architectural design. Static structural model that shows the major system components. But there is more to architecture than structure (Boxes and Arrows). Dynamic process model that shows the process structure of the system. How control flows in the system. Interface model that defines sub-system interfaces. Relationships model such as a data-flow model that shows sub-system relationships. Distribution model that shows how sub-systems are 11 distributed across computers.
  12. 12. SOFTWARE ARCHITECTURE ANDARCHITECTURAL STYLESThree important characteristics of an Architecture: Structure Communication Control 12
  13. 13. SOFTWARE ARCHITECTURE ANDARCHITECTURAL STYLESSystem Structure Module Structure: Modules and Dependencies. Conceptual Structure: Functional units and data flow. Process Structure: Processes, execution threads, synchronization constraints. Call Structure: Call relationships between processes. Physical Structure: Deployment of Data and Functions across computers, and across geographic sites. 13
  14. 14. SOFTWARE ARCHITECTURE ANDARCHITECTURAL STYLESSystem Communication Hardware infrastructure, communication medium. Synchronous/ Asynchronous communication. Shared data, duplicated shared data. Parameter passing, global variables. Message passing. Routing, packet switching. 14
  15. 15. SOFTWARE ARCHITECTURE ANDARCHITECTURAL STYLESSystem Control Procedure Call  Remote Procedure Call, Concurrent, Sequential, Event Based, Interrupt Based 15
  16. 16. SOFTWARE ARCHITECTURE ANDARCHITECTURAL STYLESArchitectural Styles: Architecture Families, defined by: Component Types, Connector Types, Communication Protocols, Semantic Constraints. 16
  17. 17. SOFTWARE ARCHITECTURE ANDARCHITECTURAL STYLESArchitectural Styles: Different classifications, Independent Components, autonomous control, message communication. Event Based Systems, events trigger reactions (XL). Virtual Machines, layered architecture (old OS). Data Flow Architectures, availability of data as control (DP). Example: Pipe and Filter. Data Centered Architectures, shared data, communication medium (DBMS). Call and Return Architectures, single control thread 17 (traditional PL code).
  18. 18. SOFTWARE ARCHITECTURE ANDARCHITECTURAL STYLESSoftware architecture as a prerequisite for reuse: Because a prerequisite for CB development. Why are cars built from components (tires, batteries, engines, transmissions, horns, A/C, etc) and software products are not? 18
  19. 19. SOFTWARE ARCHITECTURE ANDARCHITECTURAL STYLESSoftware architecture as a prerequisite for reuse: Because a prerequisite for CB development. Why are cars built from components (tires, batteries, engines, transmissions, horns, A/C, etc) and software products are not? Because cars have had the same architecture for more than a century,  Software products don’t. To build a system from components, the provider of the component and the builder of the system must agree on a common architecture. 19
  20. 20. SOFTWARE ARCHITECTURE ANDARCHITECTURAL STYLESPre-architecture software reuse experiments: Large software repositories, Sophisticated search algorithms, High quality software components, All paid for by the government, provided for free, Open for business.What happens? Nothing, despite cost/ risks of software.  It is not about functions, it is about architecture/ architectural assumptions. No common architecture, no reuse. 20
  21. 21. SOFTWARE ARCHITECTURE ANDARCHITECTURAL STYLESWhile software products in general do not have a common architecture, the elements of a product family may… Hence product line engineering. Most common form of successful reuse. E-commerce, compilers, banking, etc. 21
  22. 22. SOFTWARE ARCHITECTURE AND ARCHITECTURAL STYLESAttribute Architectural OptionReliability Duplicate functions, fault tolerance.Safety Delegate safety critical functions to one component.Security Safeguard data, control access, multiply hoops.Availability Duplicate/ distribute data, functions.Throughput Coarse grain components, minimize message traffic.Maintainability Fine grain components.Response Time Avoid bottlenecks, duplicate/distribute data, funs.Portability Isolate platform dependent components.Failure Prob Redundancy, fault removal.Ease of Use No architectural impact.Ease of Learning Uniform interaction protocols. 22Modularity High cohesion, low coupling, contract programming.
  23. 23. PLAN • Software Quality Attributes • Software Architectures and Architectural Styles • Requirements for An Architectural Description Language • ACME and ACME+ • An Attribute Grammar for ACME+ • Compiling ACME+ Architectures23 • Demo: Automated Architectural Analysis • Conclusion: Summary and Prospects • References
  24. 24. REQUIREMENTS FOR AN ARCHITECTURAL DESCRIPTION LANGUAGE 24
  25. 25. REQUIREMENTS FOR AN ARCHITECTURAL DESCRIPTION LANGUAGEAttribute Sequential Arch. Parallel Arch.Response Time Ra+Rb Min(Ra, Rb) 25Throughput Min(Ta, Tb) Ta+Tb
  26. 26. REQUIREMENTS FOR AN ARCHITECTURAL DESCRIPTION LANGUAGEGeneralizing this type of reasoning for: Arbitrary topologies, Arbitrary quantitative attributes, Arbitrary number of links per component, Arbitrary relationships between links. 26
  27. 27. REQUIREMENTS FOR AN ARCHITECTURAL DESCRIPTION LANGUAGEADL Author Institution YearACME Garlan, Shaw CMU 1995AESOP Garlan, Shaw CMU 1994Wright Robert Allen CMU 1997MetaH Vestal Honeywell 1996Lileanna Tracz IBM, Loral 1993ArTek London Teknowledge 1995C2 Taylor UC Irvine 1996 27Modechart Al Mok UT Austin 1996
  28. 28. REQUIREMENTS FOR AN ARCHITECTURAL DESCRIPTION LANGUAGEADL Author Institution YearRapide Luckham Stanford 1995UniCon Shaw CMU 1995Darwin Kramer Imperial College 1995SADL Moriconi SRI 1995Demeter Lieberherr NEU 1996CHAM Berry INRIA 1992PSDL/CAPS LuQi NPS 1993 28Resolve Weide Ohio State 1995
  29. 29. REQUIREMENTS FOR AN ARCHITECTURAL DESCRIPTION LANGUAGERequirements for an Architectural Description Language Support the ability to represent quantitative attributes of architectural components, Support a generic ontology of architectural components (adequate vocabulary), Support a rich vocabulary of functional dependencies to enable quantitative analysis (topology is insufficient), Automate analysis of system-level attributes from component-level attributes (compiling ADL to 29 relevant equations).
  30. 30. REQUIREMENTS FOR AN ARCHITECTURAL DESCRIPTION LANGUAGETo our surprise, none of the existing languages do that. ACME does represent quantitative attributes, but treats them as comments, Wright does represent operational information, but it is too detailed (yet at times fails to reflect the functional dependencies we are interested in), and it does not represent quantitative attributes, Etc.Surprising given that architecture deals with quality / non-functional attributes. 30
  31. 31. PLAN • Software Quality Attributes • Software Architectures and Architectural Styles • Requirements for An Architectural Description Language • ACME and ACME+ • An Attribute Grammar for ACME+ • Compiling ACME+ Architectures31 • Demo: Automated Architectural Analysis • Conclusion: Summary and Prospects • References
  32. 32. ACME AND ACME+ACME Ontology Components  Ports Connectors  Roles Systems Properties Representations Representation Map 32
  33. 33. ACME AND ACME+ACME Ontology… Focus on: Components  Ports Connectors  Roles Systems Properties Representations Representation Map 33
  34. 34. ACME AND ACME+Component Connector Computational  Mediates interaction Element, or between components, Data Store (stores and  Has roles, each defining controls access to) a particular function in an interaction, Has ports, used to  Binary connectors: communicate with caller/ callee; sender/ other components via receiver; reader/ writer. connectors  N-ary connectors: broadcaster/ receivers. 34
  35. 35. ACME AND ACME+ 35
  36. 36. ACME AND ACME+ACME Properties Representing extra-structural attributes, in an open- ended manner, Arbitrary list of properties, Property, defined by: name, optional type, value. Any ACME entity may be annotated with a list of properties. 36
  37. 37. ACME AND ACME+ 37
  38. 38. ACME AND ACME+ACME+: Requirements, Formal definition of properties  From a selected catalog (response time, throughput, failure probability, MTTF, MTTR, etc),  Predefined units (seconds, transactions per second, probability scale, hours, hours, etc),  Relationships between ports of a component (input, output, duplicate, complementary, synchronous, asynchronous),  Relationships between roles of a connector (input, output, duplicate, complementary, synchronous, asynchronous, blocking, non-blocking, etc). 38
  39. 39. ACME AND ACME+Relationships between ports of a component, relationships between roles of a connector. At a minimum, we wish to specify which are input ports and which are output ports. Among input ports, we wish to specify how they related to each other in providing input information.  input(anyof(P1,P2,P3)).  input(allof(P1,P2,P3)).  input(mostof(P1,P2,P3)). 39
  40. 40. ACME AND ACME+When more than one port is involved (as in all of, or most of) we must also specify whether they are synchronous or asynchronous:  input(anyof(P1,P2,P3)).  input(allof(asynch(P1,P2,P3))).  input(mostof(asynch(P1,P2,P3))).  input(allof(synchro(P1,P2,P3))).  input(mostof(synchro(P1,P2,P3))). 40
  41. 41. ACME AND ACME+As for output ports, in addition to designating them as such, we also need to determine the degree of overlap between them (duplicate, exclusive, overlap), as well as the synchronization between them (simultaneous, asavailable).  output(duplicate(P4,P5)).  output(overlap(asavailable(P4,P5))).  output(exclusive(simultaneous(P4,P5))).  output(exclusive(asavailable(P4,P5))). 41
  42. 42. ACME AND ACME+Specified as part of a fundep statement (functional dependency), that specifies the relation between ports, and associates properties to the relation.  fundep {three2two input(mostof(synchro(P1,P2,P3))), output(exclusive(asavailable(P4,P5))), properties(processingTime=0.02, throughput=45, bufferCapacity=256, mttf=2000)}. 42
  43. 43. ACME AND ACME+Adequacy of the notation, availability of needed information: Aegis Weapons System,  Allen, CMU, Pittsburg, US Video Animation Repairing System,  Bonta, Bernardo, Univ di Bologna, Padova, Italy E-Bay e-commerce platform,  Ahmed, McGill University, Montreal, Canada Rule Based System.  Garlan and Shaw, Pittsburg, US 43
  44. 44. PLAN • Software Quality Attributes • Software Architectures and Architectural Styles • Requirements for An Architectural Description Language • ACME and ACME+ • An Attribute Grammar for ACME+ • Compiling ACME+ Architectures44 • Demo: Automated Architectural Analysis • Conclusion: Summary and Prospects • References
  45. 45. AN ATTRIBUTE GRAMMAR FOR ACME+We consider canonical architectures as architectures that satisfy the following conditions: A single component with no input port and a single output port: the source. A single component with no output port and a single input port: the sink. Each component has designated input ports and output ports. Each connector has designated origin roles and destination roles. Each component/ connector has relevant fundep relations, with relevant associated attributes. 45
  46. 46. AN ATTRIBUTE GRAMMAR FOR ACME+Given a canonical architecture, we associate attributes (in the sense of attribute grammars) to each port and each role. These attributes represent the characteristics of a computation that initiates at the source component and reaches the port or role of interest. These attributes are synthesized from component and connector properties in light of:  Functional dependencies of components and connectors upstream of the port/ role.  Component and connector properties associated with these functional dependencies. 46
  47. 47. AN ATTRIBUTE GRAMMAR FOR ACME+Distinction between three concepts: System level properties: response time, throughput, MTTF, MTTR, etc. We represent these with upper case letters. Component/ connector-level properties, which are described by ACME+’s properties construct, and are attached to components and connectors. Port and role attributes that we define in the sense of attribute grammars.  There is no one-to-one correspondence between properties and attributes.  Component: Processing Time. Connector: Transmission Time. Attribute: Response time.  Component/ connector: throughput, buffer capacity. 47 Attribute: throughput.
  48. 48. AN ATTRIBUTE GRAMMAR FOR ACME+While there is no one-to-one correspondence between component/ connector properties and port/ role attributes, there is one between port/ role attributes and system level properties.Port/ Role Attributes System level PropertiesRT Response TimeTP ThroughPutFP Failure ProbabilityMTTR MeanTimeToRepairMTTF MeanTimeToFailure 48
  49. 49. AN ATTRIBUTE GRAMMAR FOR ACME+Base Attribute Values Attribute Values at Sink source.outPort.RT = 0;  sink.inPort.RT = source.outPort.TP= ; system.ResponseTime; source.outPort.FP=0;  sink.inPort.TP = system.Throughput; source.outPort.MTTF= ;  sink.inPort.FP = system.FailureProb;  sink.inPort.MTTF = system.MeanTimeToFail. 49
  50. 50. AN ATTRIBUTE GRAMMAR FOR ACME+How do we propagate the attribute values from the source to the sink?Inductive rules: Attachment statements: simple equations.  attachment {C.outPort to N.originRole}  We generate:  C.outPort.RT = N.originRole.RT,  C.outPort.TP = N.originRole.TP,  C.outPort.FP = N.originRole.FP,  C.outPort.MTTF = N.originRole.MTTF,  Etc… 50
  51. 51. AN ATTRIBUTE GRAMMAR FOR ACME+Propagation within components/ connectors (RT): Component, Single input port, single output port.  C.outPort.RT = C.inPort.RT + C.ProcessingTime. Connector, Single origin role, single destination role.  N.destinationRole.RT = N.originRole.RT + N.TransmissionTime. 51
  52. 52. AN ATTRIBUTE GRAMMAR FOR ACME+Multiple ports, roles (component, RT): fundep {three2two, input(allof(asynch(P1,P2,P3))), output(P4), properties {processingTime= , …}} C.P4.RT = C.ProcessingTime + max(C.P1.RT,C.P2.RT,C.P3.RT). 52
  53. 53. AN ATTRIBUTE GRAMMAR FOR ACME+Multiple ports, roles (component, RT): fundep {three2two, input(anyof(asynch(P1,P2,P3))), output(P4), properties {processingTime= , …}} C.P4.RT = C.ProcessingTime + min(C.P1.RT,C.P2.RT,C.P3.RT). 53
  54. 54. AN ATTRIBUTE GRAMMAR FOR ACME+Multiple ports, roles (component, RT): fundep {three2two, input(mostof(asynch(P1,P2,P3))), output(P4), properties {processingTime= , …}} C.P4.RT = C.ProcessingTime + med(C.P1.RT,C.P2.RT,C.P3.RT). 54
  55. 55. AN ATTRIBUTE GRAMMAR FOR ACME+Multiple ports, roles (component, RT): fundep {three2two, input(xxxxx(synchro(P1,P2,P3))), output(P4), properties {processingTime= , …}} C.P4.RT = C.ProcessingTime + max(C.P1.RT,C.P2.RT,C.P3.RT). 55
  56. 56. PLAN • Software Quality Attributes • Software Architectures and Architectural Styles • Requirements for An Architectural Description Language • ACME and ACME+ • An Attribute Grammar for ACME+ • Compiling ACME+ Architectures56 • Demo: Automated Architectural Analysis • Conclusion: Summary and Prospects • References
  57. 57. COMPILING ACME+ ARCHITECTURESACME+: ACME  - ACME-style properties  + fundep statements, along with their properties. To generate ACME+ architectures:  We use ACME Studio to generate plain architecture,  Check its syntax, validate it using GUI,  Add fundep statements,  Run ACME+ compiler.  Output: a set of equations linking all attribute values, from source to sink, and sink values to system properties. 57
  58. 58. COMPILING ACME+ ARCHITECTURESAvailable Functionalities, Computer system level Properties from component/ connector level properties. Produces explicit expression of system level Properties from component/ connector level properties. For some system level Properties, identifies the component/ connector that causes the bottleneck with respect to that property. 58
  59. 59. PLAN • Software Quality Attributes • Software Architectures and Architectural Styles • Requirements for An Architectural Description Language • ACME and ACME+ • An Attribute Grammar for ACME+ • Compiling ACME+ Architectures59 • Demo: Automated Architectural Analysis • Conclusion: Summary and Prospects • References
  60. 60. DEMO: AUTOMATED ARCHITECTURAL ANALYSISAegis Weapons System 60
  61. 61. PLAN • Software Quality Attributes • Software Architectures and Architectural Styles • Requirements for An Architectural Description Language • ACME and ACME+ • An Attribute Grammar for ACME+ • Compiling ACME+ Architectures61 • Demo: Automated Architectural Analysis • Conclusion: Summary and Prospects • References
  62. 62. CONCLUSION: SUMMARY ANDPROSPECTSSummary Software qualities cannot be achieved simultaneously, and must be prioritized. Software Architecture represent early design decisions that affect quality attributes of the final product.  Hence the architecture of a software product must be designed according to the selected quality attributes. A proliferation of ADL, mostly during the nineties. Contribution: an ACME extension and support tool that enable us to reason about quality attributes. 62
  63. 63. CONCLUSION: SUMMARY ANDPROSPECTSProspects Extend to non canonical architectures (cyclic topologies, concurrent processing), Other Quality Attributes, User Defined Quality Attributes, Broaden the analysis of architectures, notably by means of the explicit expression of system level properties, For more complex functional dependencies:  Replace equations with inequations,  Replace equation resolution with optimization. 63
  64. 64. PLAN • Software Quality Attributes • Software Architectures and Architectural Styles • Requirements for An Architectural Description Language • ACME and ACME+ • An Attribute Grammar for ACME+ • Compiling ACME+ Architectures64 • Demo: Automated Architectural Analysis • Conclusion: Summary and Prospects • References
  65. 65. REFERENCES Lamia Labed Jilani, Imen Derbel, Khaled Bsaies, Hamdi Nasreddine, Ali Mili. Reasoning About Quantitative Architectural Attributes (Invited Paper). Journal of Software (4): 574-583 (2011) http://web.njit.edu/~mili/jsw.pdf Imen Derbel, Lamia Labed Jilani, Ali Mili: A model for analyzing architectural attributes. AICCSA 2010: 1-7. http://web.njit.edu/~mili/compiling.pdf 65
  66. 66. PLAN • Software Quality Attributes • Software Architectures and Architectural Styles • Requirements for An Architectural Description Language • ACME and ACME+ • An Attribute Grammar for ACME+ • Compiling ACME+ Architectures66 • Demo: Automated Architectural Analysis • Conclusion: Summary and Prospects • References

×