1 A Multi-Paradigm Approach to Describe Software Systems presented by Adel Smeda

2 A Multi-Paradigm Approach to Describe Software Systems Introduction COSA approach Connectors in COSA Operational mechanisms of COSA Conclusion and future work

3 A Multi-Paradigm Approach to Describe Software Systems Introduction Object Based Software Architecture (OBSA) Based on object-oriented notations Object oriented modeling notations, e.g. UML (Unified Modeling language) Component Based Software Architecture (CBSA) Based on components (locus of computation) and connectors (locus of relations among components) Architecture Description Langues (ADL). e.g. UniCon, Rapide, Wright, C2, ACME, SOFA, etc.

4 A Multi-Paradigm Approach to Describe Software Systems Differences between the two approaches 1. Level of granularity. 2. Definition of interactions. 3. Definition of a system’s global architecture. 4. Support for non-functional properties ( e.g. performance, safety, security, schedulability, portability, conformance to standards, and reliability) 5. Community support. 6. Standardization of concepts. 7. Refinement to source code.

5 A Multi-Paradigm Approach to Describe Software Systems COSA: Component-Object based Software Architecture. Basic concepts of COSA Components, Connectors, Interfaces, Configurations, Properties, Constraints.

6 A Multi-Paradigm Approach to Describe Software Systems

7 Connectors in COSA What is a connector? They are explicit architectural entities that bind components together and act as mediators between them, their functions separate them from components. What does a connector do? (services) communication (e.g. data exchange), conversion (e.g. wrappers), coordination (e.g. function calls), and facilitation (e.g. load balancing )

8 A Multi-Paradigm Approach to Describe Software Systems Why should connectors be treated separately from components? Complexity of components’ interactions makes it desirable to separate interactions from components. Separating the notions of interaction (communication, coordination, conversion, facilitation) from the notion of computation allows components to be replaced, reused, evolved easily. Components could be dynamically changing; in this case a separate connector is needed to mediate the relations among them.

9 A Multi-Paradigm Approach to Describe Software Systems If components are localized at different nodes of a distributed system, the cooperation of the distant components is determined by the semantics of the connectors, which connect them. If connectors are defined as first-class entities, then new connectors out of old ones can be obtained by instantiating, inheriting, composing, existing ones.

10 A Multi-Paradigm Approach to Describe Software Systems Connectors in OBSA Defined implicitly through function invocations and shared data access. Connectors in CBSA 1 st group: Implicit connections, e.g. Darwin 2 nd group: An enumerated set of built-in connectors, e.g. UniCon (FileIO, ProcedureCall, RemoteProcedureCall, DataAccess, RTScheduler, and PLBundler) 3 rd group: User defined connectors, e.g. ACME

11 A Multi-Paradigm Approach to Describe Software Systems Definition of connectors in COSA

12 A Multi-Paradigm Approach to Describe Software Systems

13 A Multi-Paradigm Approach to Describe Software Systems An example of describing a client-server system using COSA Class Configuration client-server { Interface {Port External {External-protocol;} } Class Component server { Interface{ Port provide {provide-protocol;} external-port { External-port-protocol ;}} Properties { connection-mode=sync; data-type =format-1;} Constraints {max-clients=2;} }

14 A Multi-Paradigm Approach to Describe Software Systems Class Component client { Interface{ Port request {sent-request;}} Properties { data-type =format-2;}} Class Connector RPC{ Interface { Roles {participator-1, participator-2 } Service-type = conversion; Connection-mode = sync; Transfer-mode = serial; Properties {throughput=10kb;} // properties of the interface Constraints {no-of-roles <= 2;} }

15 A Multi-Paradigm Approach to Describe Software Systems Glue { Define-Service{ read participator-1; convert from format-1 to format-2; write participator-2;} Properties {bidirectional;}} // properties of the glue constraints {max-roles =2;} // constraints of the connector } Binding { server.external-port to External;} } Instance client-server arch-1 { Instances { S1: server; C1: client; C1-S1: RPC; } Attachments { C1.request to C1-S1. participator-1; S1.provide to C1-S1. participator-2; } }

16 A Multi-Paradigm Approach to Describe Software Systems Operational mechanisms of COSA Instantiation Inheritance Compositionality Genericity

17 A Multi-Paradigm Approach to Describe Software Systems Inheritance Configuration client-server-2 inherits client-server. Class Configuration client-server-2 extend client-server { Class Component server-2 extend server without Interface{ Interface{ Port provide {provide-protocol;} Other-interfaces {Broadcast; } }

18 A Multi-Paradigm Approach to Describe Software Systems Class Component client-2 extend client without Properties { Properties { data-type =format-1;} } Class Connector RPC-2 extend RPC without Glue { Interface { Glue { Connection-type { read in; write out;} Properties {bidirectional; }} }

19 A Multi-Paradigm Approach to Describe Software Systems Instance Configuration example-inheritance { Instances { S1: server-2; C1: client; C2: client-2; C1-S1: RPC; C2-S2: RPC-2; } Attachments { S1.provide to C1-S1. participator-1; C1.request to C1-S1. participator-2; S1.provide to C2-S2.in; C2.request to C2-S2.out; }

20 A Multi-Paradigm Approach to Describe Software Systems Genericity Class Configuration client-server { Class Generic Component Component-general{ Interface{ Port P {port-protocol;} } Properties { connection-mode=sync; max-ports=N;} }

21 A Multi-Paradigm Approach to Describe Software Systems Class Generic Connector G-C { Interface { Role R1, R2 {roles protocol; }} Glue { Connection-type C { communication, conversion, coordination, or facilitation } Properties {bidirectional;}} Properties {max-roles =M;} }

22 A Multi-Paradigm Approach to Describe Software Systems Instance client-server arch-1 { Instances { Server : Component-general ; Client : Component-general ; Server-to-Client: G-C ; } Attachments { Server.Port to Server-to-Client.request; Client.Port to Server-to-Client.provide; } }

23 A Multi-Paradigm Approach to Describe Software Systems Compositionality Example: Connector composed-pipe is composed of C1 and C2. Class Connector composed-pipe { Interface {Roles {read; write;}} Glue { Define-Composition{ Components { Connector-1; Connector-2; } Binding { read to connector-1.request; connector-1.provide to connector-2.request; connector-2.provide to write; } } }

24 A Multi-Paradigm Approach to Describe Software Systems Conclusion and future work Refinement Active connectors