1. Slide 1 Lecture 15 Enterprise Systems Development ( CSC447 ) COMSATS Islamabad Muhammad Usman, Assistant Professor

2. Slide 2 Component and Connector ViewType

3. Slide 3 Overview Defines models consisting of –elements having some runtime presence – processes, objects, clients, servers, data stores –Pathways of interaction – communication links, protocols, information flows, access to shares storage

4. Slide 4 Runtime entities and their interactions May contain many instances of the same component type Similar to object(collaboration) diagrams as against class diagrams(which define types of elements)

5. Slide 5 Summary of C&C Viewtype ElementsComponent Types: principal processing unit and datastores Connector Types: interaction mechanisms RelationsAttachments:component ports are associated with specific connector roles Properties of elements Component: Name, type(general functionality, number and type of ports) Other properties(like performance..) Connector: name, type(nature of interaction, number and type of roles..), other properties(protocol of interaction, performance values..) TopologyNo Inherent constraints

6. Slide 6 C & C Viewtype Styles Pipe-and-filter Shared-data Publish-subscribe Client-server Peer-to-peer Communicating processes

7. Slide 7 Components

8. Slide 8 Component Interfaces

9. Slide 9 Connectors

10. Slide 10 Connector Roles

11. Slide 11 Connector Role Examples

12. Slide 12 Relations

13. Slide 13 What is C&C for? To reason about runtime system quality attributes – performance, reliability, availability What are the systems principal executing components and how do they interact What are the major shared data resources Which parts of the system are replicated and how many times How does data progress through a system as it executes What protocols of interaction are used by communicating entities What parts of the system run in parallel How can the system’s structure change as it executes

14. Slide 14 What is C&C not for? Can not represent design elements which do not have a runtime presence Example – interface of an element - usability

15. Slide 15 C & C Viewtype Styles Pipe-and-filter Shared-data Publish-subscribe Client-server Peer-to-peer Communicating processes

16. Slide 16 From Clements etal

17. Slide 17 Pipes and Filters A filter transforms data that it receives from one or more pipes and transmits through one or more pipes A pipe is a connector that conveys streams of data from output port of one filter to input port of another Pipes buffer data The overall function is a composition of filter functions

18. Slide 18 What for.. Very useful in data transformation –Signal processing –compilers To reason about system performance, stream latency, pipe buffer requirements, schedulability

19. Slide 19 Pipes and filters - summary ElementsComponent Types: filter – ports must be input or output Connector Types: pipes – have data-in and data-out roles RelationsAttachments: associates filter output ports to data-in roles of a pipe and.. Out to in Properties of elementsComponent: Name, type(general functionality, number and type of ports) Other properties(like performance..) Connector: name, type(nature of interaction, number and type of roles..), other properties(protocol of interaction, performance values..) TopologyMight be restricted to acyclic graphs

20. Slide 20 Relationship with other styles Different from data flow projections/views In pipes-and-filters lines have specific meaning – transmit streams of data In dataflow relationships implies data communication – could be implemented as a procedure call, publish-subscribe, via a pipe..

21. Slide 21 Shared data style Useful in exchange of persistent data, which has multiple accessors How does the consumer know data is available? –Store informs the consumer – blackboard –Consumer is responsible - repository

22. Slide 22 Shared data access -summary ElementsComponent types: data stores, data accessors Connectors: data reading and writing RelationsWhich accessor is connected to which store Computational modelCommunication between accessors mediated by the store; communication may be initiated by either PropertiesSame as in C&C; types of data, data performance, data distribution TopologyData accessors are attached to connectors that are attached to stores ElementsComponent types: data stores, data accessors Connectors: data reading and writing RelationsWhich accessor is connected to which store Computational modelCommunication between accessors mediated by the store; communication may be initiated by either Properties of elementsSame as in C&C; types of data, data performance, data distribution TopologyData accessors are attached to connectors that are attached to stores

23. Slide 23 What for.. Used when there are multiple accessors and persistence Decouple producer from consumer Data store performance, security, privacy, compatibility with other stores…

24. Slide 24 Similarity to others Client-server style Publish-subscribe is similar without persistence

25. Slide 25 Publish-subscribe styles Components interact via announced events Components subscribe to a set of events P-S runtime ensures that each published event is delivered to all subscribers The connector is an event bus Used in message production/consumption

26. Slide 26 P-S summary ElementsComponent types: any component with a pub/sub interface Connectors: publish-subscribe RelationsAttachment associates components with pub-sub connector Computational modelA system of independent components that announce events and react to other announced events Properties of elementsSame as in C&C; TopologyAll components are connected to an event distributor

27. Slide 27 Where to use.. To send events and messages to recipients Set of recipients are unknown – can be added dynamically

28. Slide 28

29. Slide 29

30. Slide 30 Client-Server Components interact by requesting services of other components Communication is initiated by a client

31. Slide 31 Client-Server summary ElementsComponent types: clients – which ask for services; servers –which provide services Connectors: request-reply RelationsAttach clients to servers Computational modelClients initiate activity and wait for results PropertiesSame as in C&C; number and type of clients, performance TopologyUnrestricted; number of clients; tiers

32. Slide 32 What for.. Assignment of functionality is clear Can be independently assigned to tiers Can be used to argue about performance Example - WWW

33. Slide 33 Peer-to-peer Components interact with each other exchanging services No asymmetry as in client-server Connectors are bidirectional

34. Slide 34 Allocation Viewtype

35. Slide 35 Allocation viewtype styles Deployment style Implementation style Work assignment style

36. Slide 36 Summary of Allocation Viewtype ElementsSoftware elements and environment elements RelationsAllocated-to. A software element is allocated to an environmental element Properties of elements A software element has required properties. An environmental element has provided properties that need to be matched. TopologyVaries by style

37. Slide 37 Deployment style Elements of the C&C styles are allocated to execution platforms

38. Slide 38 Deployment style summary ElementsSoftware element: usually a process from the C$C view Environmental Element: computing hardware, processor, disk,.. RelationsAllocated to: showing the physical unit the element resides Migrates-to, copy-migrates to: if the allocation is dynamic Properties of elementsRequired properties of software elements Provided properties of software elements Properties of relationsAllocated to – either static or dynamic Topologyunrestricted

39. Slide 39 From Clements etal

40. Slide 40 Common Architectural Styles (Adapted from Shaw and Garlan) Dataflow systems –Batch sequential –Process control –Pipes and filters Call-and-return systems –Main program and subroutine –Object-oriented systems –Hierarchical layers

41. Slide 41 Common Architectural Styles (Cont’d) Independent components –Communicating processes –Event systems Virtual machines –Interpreters –Rule-based systems Repositories –Databases –Hypertext systems –Blackboards

42. Slide 42 42 Reference Bass, L., Clements, P. and Kazman, R., Software Architecture in Practice, Second Edition (2006), Addison-Wesley. Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, j., Little, R., Nord, R. and Stafford, J., Documenting Software Architectures: Views and Beyond, 2002, Addison-Wesley. Documenting Software Architectures