Architectural Synthesis Approach Sheldon X. Liang Ph. D. February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

 Overview ( objective  problem  solution )  Story of System Development  Architectural Synthesis Approach  Compatible Composition Model  CCM-Centric System Transition  What Achieved and Expected Architectural Synthesis Approach February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

 Overview  Objectives  to develop an architectural model CCM 1  to bridge gap between prototype & product  to establish a synthesis approach enabling smooth evolution of prototype to product consistently engineering HDSIS 2 1 CCM: Compatible Composition Model 2 HDSIS: Highly Dependable Software-Intensive Systems February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

 Perspective confusion problem  Modeling difference problem  Constraint Attachment problem  CASE tool support problem  Overview  Problems February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

 Overview  Solutions  Modeling HDSIS through perspective views  Architecting prototype via CCM  Formulating dependability as constraints  Evolving prototype into generic framework February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

 Requirement and Decomposition Activity: Whole-Part issues  Collaboration via Communication Interaction: Roles and Responsibility  Interactive methods Architectural style  Architecture and Components Architectural elements  Story of System Development February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

 Story  Requirement & Decomposition Family Income1 Income2 Spending1 Spending2 Spending3 Husband Wife Child Income1 Income2 Spending1 Spending2 Spending3 Conceptual Component Monolithic: No Decomposition No Communication No Interaction No Collaboration Decomposed: Communication, Coordination Interaction February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

 Story  Prototyping for requirement acquisition Husband Wife Child Insurance Check Rebate Check Honey, I am home  Almost ready, just a second Hi, How’s schooling  It was great  When they are under the same roof, they do not need communication infrastructure February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

 Story  Prototyping for requirement acquisition Rapid Prototyping will capture the conceptual interaction with Dataflow streams without involving concrete facilities for communication February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

 Story  Collaboration & Communication  Communication facilities forming an architecture that is embodied as components from which system is built, interactions among those components Husband Wife Child Telcom  Caller Listener  Internet  Sender  Receiver February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

 Story  Interactive Method/Architectural Style  play roles  via styles (method)  comply with protocols  In architecture, components play roles and interact with each other via architectural styles, while complying with communication protocols. February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

 Story  Architecture & Components Smith MarthaLily Real persons (components) are derived from roles February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

 Story  Summary System Decomposition   Constructing Architecture Derivational Implementation  February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

 Architectural Synthesis Approach Prototyping February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

 Architectural Synthesis Approach CCM February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

 Conceptual Model Referring to the relationship among role, style, and protocol  Formal Representation Referring to formalism of syntax, semantics and constraints  Substantiated Interconnections Referring to the entity building interconnections  Constraint Attachment Referring to constraints associated with patterns  Compatible Composition Model February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

 CCM-Centric System Transition  Principle Figure 1 Conceptual Context for Quantifiable Architecture February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

 Computational Requirements Focusing on activities and information flows  Compositional Architecture Focusing on rules governing interactions  Componential Derivation Focusing on component and connectivity  Quantifiable Assessment Focusing on quantifying dependability  CCM-Centric System Transition  perspectives February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

 Explicitly define architecture for faster, better, cheaper systems  Clearly uncover perspective concerns for customer, architect, implementer  Incorporate requirements validation for prototyping / requirement adjustment  Quantify stable architecture for heterogeneity, granularity, compatibility  What Achieved and Expected (progressive) February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

Thank you very much! Questions? That is all February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

Sometimes they are even contradictory Customer Perspective Confusion Problem Architect Implementer Increased uncertainty about requirements Rapid Application Development Flexible Configuration in Organization February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

Hint: a transitional process can be applied to change one into the other with a dependability-reserved transformation. When modeling a system from various perspectives, we found it difficult to reflect various stakeholders’ concerns, because compatibility is not easily assured Modeling Difference Problem February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

Hint: dependability properties of HDSIS, such as,, are generally translated into quantitative constraints Hint: dependability properties of HDSIS, such as availability, reliability, integrity, security, maintainability, are generally translated into quantitative constraints How to attach dependability constraints on architectural artifacts, this becomes a key issue because it is not easy to find the crucial formal argument to which constraints are bound Constraint Attachment Problem February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

Hint: a well-formulated description provides the mechanism for reasoning and manipulation A real challenge is that intellectual models are not easily represented as semantic formulas that support efficient reasoning and manipulation by CASE tools CASE Tool Support Problem February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

CCM provides a set of rules that govern the interactions among components with attached constraints Conceptual Model CCM is characterized as the interactions between two interactive roles via an architectural style while complying with the communication protocol Component1 Component2 February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

February 5, 2016 Formal Representation Component1 Component2 February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

 Dependable composers to promote interactions  Heterogeneous forms to establish communication  Topological connectivity to guide configuration  Constraint attachment to quantify interconnections Substantiated Interconnections Substantiated interconnections among components embodied as following four aspects: February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

Constraint Attachment composer Pipeline is generalized … role Outflow is port procedure Output(d: Data); procedure Produce(d: Data) is abstract; computation Produce (d); *[ Output (d)  latency(60)  Produce (d)  met(100) latency-signaled  LAT-EXCEPTION met-signaled  MET-EXCEPTION ] end Outflow; … … end Pipeline; Latency MET Latency: the upper bound of communication delay MET : Maximum Execution Time of computation Dynamic design inspection to monitor system execution Component1 Component2 February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

Topological Connectivity Topological connectivity simplifies the interconnection among components as the following four forms:  Fork (1~N): single producer to multiple consumers  Merge (N~1): multiple producers to single consumer  Unique (1~1): single producer to single consumer  Hierarchy: external producer to interact with the internal consumer, and vice versa February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

Topological Connectivity -- FORK Producer Consumer February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

The viewpoint for the customer focuses on the activities and information flows that accomplish the operational concept. The activities are also compartmentalized as hierarchical components through information links Computational Requirements Sub- February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

Computational Requirements P computation = [C c, I, Ct (C c, I)] C c : Conceptual component I: Interconnections Ct: Constraints on C c and I February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

Computational Requirements Fishier February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

The perspective from architect is concerned about the rules that govern the interactions between components through compositional patterns Compositional Architecture P S r o r i February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

Compositional Architecture P c omposition = [C c  R, R o ─ S / P →R i, Ct (R, S, P)] C c  R C c  R : component extracted as role R o ─ S / P →R i R o ─ S / P →R i : interaction between roles S: architectural style P: communication protocol February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

Compositional Architecture February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

The perspective from implementer refers to physical components, topological connectivity that will be instantiated to carry out the computational activity Componential Derivation P derivation = [R  C p, (C p  R o )─ S / P →(R i  C p ), Ct (C p S, P)] COM 1 2 P S r o r i glue R  C p R  C p : physical component derived from roles C p  R o C p  R o : instance component glued to role February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

Componential Derivation P derivation = [R  C p, (C p  R o )─ S / P →(R i  C p ), Ct (C p S, P)] R  C p R  C p : physical component derived from roles C p  R o C p  R o : instance component glued to role February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

Quantifiable Assessment This refers to the abstraction of dependability, its translation to quantitative constraints, and the handling of these constraints applied in the design, construction, and evolution of a software-intensive system DependabilityTranslationConstraintsLocalizationPatterns  Availability  Reliability  Security  Integrity  Flexibility  Consistency  Compatibility  Granularity  Heterogeneity  Real time  Synchronization  Role  Style  Protocol February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

DependabilityTranslationConstraintsLocalizationPatterns  Availability  Reliability  Security  Integrity  Flexibility  Consistency  Compatibility  Granularity  Heterogeneity  Real time  Synchronization  Role  Style  Protocol P quantification =[D r  Q c, Q c ─ Attach  CCM (R,S,P)] D r  Q c represents translation of dependability to quantitative constraints ─ attach  : represents the localization of constraints CCM(R, S, P): represents model parameterized as Role, Style, & Protocol Quantifiable Assessment February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

Quantifiable Assessment  Design Inspection Static Checking Check if the quantifiable attributes (constraints) meets the needs in specification at architectural level (artifacts) Data analysis, reasoning, and static schedule Dynamic Monitoring Test if the quantifiable attributes (properties) violates the predefined regulation at runtime February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,

Quantifiable Assessment  Dynamic Monitoring composer Pipeline is generalized … role Outflow is port procedure Output(d: Data); procedure Produce(d: Data) is abstract; computation Produce (d); *[ Output (d)  latency(60)  Produce (d)  met(100) latency-signaled  LAT-EXCEPTION met-signaled  MET-EXCEPTION ] end Outflow; … … end Pipeline; Latency MET Latency: the upper bound of communication delay MET : Maximum Execution Time of computation Dynamic design inspection to monitor system execution Component1 Component2 February 5, Software Engineering in CS at APU Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department of Computer Science,