Lecture-7.ppt
- 1. 1/6/2024 1 Adama Science and Technology University School of Electrical Engineering and Computing Department of Computer Science and Engineering Summery on Software Architecture (Reading Assignment) Lecture -7 Dr. Teklu Urgessa (PhD) Lecture By
- 2. Outline Software architecture and component-based Software architecture Describes multiple views of a Software architecture Introduces the concept of Software architectural patterns How to document patterns Describes Software components and interfaces An overview of designing software architectures 1/6/2024 2
- 3. Software Architecture and Component Based Software Architecture (Cont..) Software architecture is structured into subsystems, in which each subsystem should be relatively independent of other. It is necessary to study the software architecture from: Static and Dynamic Functional and Nonfunctional A structural perspective on SW architecture is given by the widely held concept of component-based SW architecture. A component is either a composite object composed of other objects or a simple object. 1/6/2024 3
- 4. Software Architecture and Component Based Software Architecture (Cont..) A component provides an interface through which it communicates with other components. All information that is needed by one component to communicate with another component is contained in the interface, which is separate from the implementation. A sequential design is a program in which the components are classes and component instances are objects; the components are passive classes without a thread of control. In a sequential design, the only communication pattern is call/return. 1/6/2024 4
- 5. SW Architecture and Component Based SW Architecture (Cont..) In a concurrent or distributed design, the components are active (concurrent) and capable of being deployed to different nodes in a distributed environment. In concurrent design component can be communicated with each other using several different types of communication pattern such as: synchronous, asynchronous, brokered, or group communication. 1/6/2024 5
- 6. Multiple Views of a SW Architecture In UML 2, a modeling element can be described with more than one stereotype. Analysis modeling: role characteristic of modeling element. (boundary, entity) Design modeling: architectural characteristics. (subsystem, component, service or concurrent task) SW architecture design can be depicted from different perspective Structural view: class diagram Dynamic view: communication diagram Deployment view: deployment diagram Component view : component diagram 1/6/2024 6
- 7. Software Architecture Patterns SW architectural patterns provide the skeleton or template for the overall software architecture or high-level design of an application. (architecture style or pattern) Software architectural pattern can be grouped into two: Architectural structure pattern: provide the skeleton or template (layer of abstraction) Architectural communication pattern: dynamic communication (call/return, Asynchronous Message Communication patterns, and the Synchronous Message Communication with Replay pattern ) 1/6/2024 7
- 8. Layers of Abstraction Architectural Pattern Layers of Abstraction is a common architectural pattern. A strict hierarchy, each layer uses services in the layers immediately below it. In flexible hierarchy, it can invoke services at more than one layer below. Software architectural structural pattern: Centralized Control Pattern Distributed Control Pattern Hierarchical Control Pattern Layers of Abstraction Pattern 1/6/2024 8
- 9. Software Architecture Pattern Software architectural structural pattern: Multiple Client / Multiple Service Pattern Multiple Client / Single Service Pattern Multi-tier Client/ Service Pattern Software architectural communication pattern Asynchronous Message Communication Pattern Asynchronous Message Communication with Callback Pattern Bidirectional Asynchronous Message Communication Broadcast Pattern 1/6/2024 9
- 10. Software Architecture Pattern Software architectural communication pattern Broker Forwarding Pattern Broker Handle Pattern Call/ Return Negotiation Pattern Service Discovery Pattern Service Registration Subscription/ Notification Pattern Synchronous Message Communication with Replay Pattern Synchronous Message Communication without Relay Pattern 1/6/2024 10
- 11. Software Architecture Pattern Call / Return Pattern The simplest form of communication b/n objects. A sequential design consists of passive classes, which are instantiated as passive objects. The only possible form of communication between objects in a sequential design is operation (also known as method) invocation, which is also referred to as the Call/Return pattern. 1/6/2024 11
- 12. Software Architecture Pattern Call / Return Pattern 1/6/2024 12
- 13. Software Architecture Pattern Asynchronous Message Communication Pattern In concurrent and distributed designs, other forms of communication are possible. The Asynchronous (Loosely Coupled) Message Communication pattern, the producer component sends a message to the consumer component and does not wait for a reply. Asynchronous Message Communication pattern is used wherever possible for greater flexibility. It is also possible to have peer-to-peer communication between two components, which send asynchronous messages to each other. This kind of communication is referred to as bidirectional asynchronous communication. 1/6/2024 13
- 14. Software Architecture Pattern Asynchronous Message Communication Pattern 1/6/2024 14
- 15. Software Architecture Pattern Synchronous Message Communication with Reply Pattern The client component sends a message to the service component and then waits for a reply from the service. When the message arrives, the service accepts it, processes it, generates a reply, and then sends the reply. The client and service then both continue. The service is suspended if no message is available. There might be one client and one service, it is more likely that synchronous involves multiple clients and one service. This pattern is fundamental to client/server architectures. 1/6/2024 15
- 16. Software Architecture Pattern Synchronous Message Communication with Reply Pattern 1/6/2024 16
- 17. Documenting Software Architectural Pattern For the sake of easy referencing, comparison with other patterns and reuse patterns need documenting. Three important aspects of a pattern that need to be captured are: Context: the situation that gives rise to a problem. Problem: a recurring problem that arise in this context. Solution: a proven resolution to the problem. A template for describing a pattern usually also addresses its strength, weakness, and related patterns. 1/6/2024 17
- 18. Documenting Software Architectural Pattern A typical template looks like this: Pattern name: Aliases: Other name by which this pattern is known Context: The situation that gives rise to this problem Problem: Brief description of the problem Summary of solution: Brief description of the solution Strengths of solution: Weaknesses of solution: Applicability: When you can use the pattern Related patterns: Reference: Where you can find more information about the pattern. 1/6/2024 18
- 19. Documenting Software Architectural Pattern 1/6/2024 19
- 20. Interface Design An important goal of both object-oriented design and component-based software architecture is the separation of the interface from the implementation. An interface specifies the externally visible operations of a class, service, or component without revealing the internal structure (implementation) of the operations. An interface can be depicted with a different name from the class or component that realizes the interface. 1/6/2024 20
- 21. Interface Design By convention, the name starts with the letter “I.” An interface can be depicted in two ways: simple and expanded. Simple case: the interface is depicted as a little circle with the interface name next to it. The class or component that provides the interface is connected to the small circle. (provided / required) Expanded case: the interface is depicted in a rectangular box with the static modeling notation, with the stereotype «interface» and the interface name in the first compartment. 1/6/2024 21
- 23. Design of SW Architecture Object oriented Software Architectures: Using the concepts of information hiding, classes, and inheritance. Client/ Server Architecture A typical design consists of one service and multiple clients. Service-Oriented Architecture Typically consist of multiple distributed autonomous services that can be composed into distributed software applications. 1/6/2024 23
- 24. Design of Software Architecture Distributed Component –based Software Architecture It describes the component structuring criteria for designing components that can be deployed to execute on distributed platforms in a distributed configuration. Concurrent and Real Software Architecture Which are concurrent architectures usually having to deal with multiple streams of input events? state-dependent Software Product Line Architecture Which are architectures for families of products that need to capture both the commonality and variability in the family? 1/6/2024 24
- 25. II. Software Subsystem Architecture Design 1/6/2024 25
- 26. Outline Describes issues in software architectural design. Integrate the use case–based interaction models into an initial software architecture. Determine the subsystems using separation of concerns and subsystem structuring criteria. Determine the precise type of message communication among the subsystems. 1/6/2024 26
- 27. Issues in Software Architecture Design During analysis modeling, the problem is analyzed by breaking it down and studying it on a use case–by–use case basis. During design modeling, the solution is synthesized by designing a software architecture that defines the structural and behavioral properties of the software system. In the analysis of the problem domain and structuring a system into subsystem, the emphasis is on functional decomposition. 1/6/2024 27
- 28. Issue in Software Architecture Design The design goal is a major function that is relatively independent of the other subsystems functionality. Some subsystems can be determined relatively easily because of geographical distribution or server responsibility. E.g. client and server 1/6/2024 28
- 29. Issue in Software Architecture Design In other applications, it is not so obvious how to structure the system into subsystem. One of the goals of subsystem structuring is to have objects that are functionally related and highly coupled in the same subsystem, a good place to start is with the use cases. Objects that participate in the same use case are candidates to be grouped into the same subsystem. Because of this, subsystem structuring is often done after the interaction among the constituent objects of each use case has been determined during dynamic modeling. 1/6/2024 29
- 30. Issue in Software Architecture Design A subsystem provides a larger-grained information hiding solution than an object. To structure the system into subsystems, start with the use cases. Objects that realize the same use case have higher coupling because they communicate with each other and have lower (or no) coupling with objects in other use cases. 1/6/2024 30
- 31. Issue in Software Architecture Design Whereas an object can participate in more than one use case, it can only be part of one subsystem; thus, an object that participates in more than one use case needs to be allocated to a single subsystem, usually the subsystem with which it is most highly coupled. However, there are also situations in which objects that participate in the same use case need to be assigned to different subsystems (e.g., because they are located in separate geographical locations). 1/6/2024 31
- 32. Integrated Communication Diagrams In the analysis model, at least one communication diagram is developed for each use case. The integrated communication diagram is a synthesis of all the communication diagrams to support the use cases. On way to reduce the clutter of the integrated communication diagram is to aggregate the messages. The aggregate message does not represent an actual message sent from one object to another rather it represents messages sent at different times between the same pair of objects. 1/6/2024 32
- 35. Separation of Concerns in Subsystem Design Some important structuring decision need to be made when designing subsystem. The goal is to make subsystem more self-contained, so that different concerns are addressed by different subsystems. Composite Objects Objects that are parts of the same composite object should be in the same subsystem.(they are created, live and die together) Geographical Location If two objects separated in different geographical locations, they should be in different subsystem. 1/6/2024 35
- 36. Separation of Concerns in Subsystem Design Clients and Services Clients and services should be in separate subsystem. User Interaction The most flexible option is to keep user interaction objects in separate subsystems. Interface to External Objects An external real-world object should interface to only one subsystem. Scope of Control A control object and all the entity and I/O objects it directly controls should all be part of one subsystem. 1/6/2024 36
- 37. Subsystem Structuring Criteria A subsystem can satisfy more than one of the structuring criteria. (design considerations) Client Subsystem It include: user interaction, control and I/O subsystems. User Interaction Subsystem There may be more than one user interaction subsystem – one for each type of user. Service Subsystem A service subsystem provides a service for client subsystem. It include entity, coordinator and business logic objects. 1/6/2024 37
- 38. Subsystem Structuring Criteria Control Subsystem A control subsystem controls a given part of the system. The subsystem receives its inputs from the external environment and generates outputs to the external environment, usually without any human intervention. A control subsystem is often state dependent, in which case it includes at least one state-dependent control object. 1/6/2024 38
- 39. Subsystem Structuring Criteria Coordinator Subsystem Coordinator subsystems coordinate the execution of other subsystems, such as control or service subsystems. In software architectures with multiple control subsystems, it is sometimes necessary to have a coordinator subsystem that coordinates the control subsystems. Input / Output Subsystem An input, output, or input/output subsystem is a subsystem that performs input and/or output operations on behalf of other subsystems. It can be designed to be relatively autonomous. 1/6/2024 39
- 40. Decisions about message communication between subsystems In the transition from the analysis model to the design model, one of the most important decisions relates to what type of message communication is needed between the subsystems. A second related decision is to determine more precisely the name and parameters of each message (i.e. the interface specification) 1/6/2024 40
- 41. Decisions about message communication between subsystems In design modeling, after the subsystem structure is determined, a decision has to be made about the precise semantic of message communication, such as whether message communication will be synchronous or asynchronous. Message communication between two subsystems can be unidirectional or bidirectional. 1/6/2024 41
- 42. Decisions about message communication between subsystems 1/6/2024 42
- 43. Decisions about message communication between subsystems 1/6/2024 43
- 45. Thank You !!! It was nice to have you as my Students 1/6/2024 45