scaling software systems - uvic.ca
TRANSCRIPT
Engineering System SoftwareZAHRA NIKDEL
SPRING 2019
What is software architecture? Software architecture is
the fundamental structures of a software system,
the discipline of creating such structures,
the documentation of those structures
Each structure comprises software elements, relations among them, and properties of both elements and relations, along with rationale for the introduction and configuration of each element[1].
The architecture of a software system is a metaphor, analogous to the architecture of a building[2].
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 - 2019
Architecture Role
Yet, architecture must influence requirements “The art of the possible” Helps stakeholder understanding of risk/cost Helps stakeholder understanding of possibilities
Documenting software architecture facilitates communication between stakeholders, captures decisions about the architecture design, and allows reuse of design components between projects.
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 5
Architecture as a series of decisions Software architecture is about making fundamental structural choices
which are costly to change once implemented.
Each project normally has several alternative solutions. The job of architecture is to choose between these options which we call it Architectural options.
The Architecture makes an architectural decision to resolve each sub- problem. This process involves choosing the best option from among the alternatives.
6
Making decisions To make each design decision, the software engineer uses: Knowledge of
the requirements
Creative solutions
7
Making decisions example System: controller of the space shuttle which launch vehicle
Requirements: 1-being fast 2- being reliable.
To be fast, an appropriate real-time computing language would need to be chosen.
To satisfy the need for reliability the choice could be made to have multiple redundant and independently produced copies of the program, and to run these copies on independent hardware while cross-checking results.
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 356 - 2019
Architectural model A software architectural style is determined by the following:
A set of components
A topological layout of these components indicating their runtime interrelationships
A set of semantic constraints (e.g. a data repository is not allowed to changed the values in it)
A set of connectors that mediate communication, coordination, or cooperation among components
8
Architectural model example
Component Self-contained piece of a system with clearly defined interfaces
A component can be isolated, allowing you to replace it with a different component that has equivalent functionality.
Components should be designed to be reusable.
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 11
Connectors A linkage between components via an interface Way that two components talk
e.g. Webserver talks http or Database server talks sql
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 12
Architecture view points A system’s architecture can be described in terms of several different views The logical breakdown into subsystems
The interfaces among the subsystems
The dynamics of the interaction among components at run time
The data that will be shared among the subsystems
The components that will exist at run time, and the machines or devices on which they will be located
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 13
Architecture view points Popular viewpoint models include the 4+1 views on software architecture, the viewpoints and perspectices catalog by Nick Rozanski and Eoin Woods, and the IBM ADS viewpoint model by Phlippe Spaas et al.
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 14
Architecture view example Functional Viewpoint (logical view)
Purpose: capture the functional structure of the system
Content: the system’s runtime functional elements and their responsibilities, interfaces, and primary interactions
Concerns: functional capabilities, external interfaces, internal structure, and design philosophy
Models: functional structure model
Architecture view example
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 16
Design stable architecture To ensure the maintainability and reliability of a system, an architectural model must be designed to be stable.
Being stable means that the new features can be easily added with only small changes to the architecture
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 17
Developing an architectural model[3] Start by sketching an outline of the architecture Based on the principal requirements
and use cases
Choose among the various architectural patterns
https://msdn.microsoft.com/en-us/library/ff647894.aspx
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 18
Developing an architectural model[3] Refine the architecture Identify the main ways in which the components will interact and the interfaces
between them
Decide how each piece of data and functionality will be distributed among the various components
Determine if you can re-use an existing framework, if you can build a framework
Consider each use case and adjust the architecture to make it realizable
Mature the architecture
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 19
Describing an architecture using UML All UML diagrams can be useful to describe aspects of the
architectural model
Four UML diagrams are particularly suitable for architecture modelling: Package diagrams
Component diagrams
Deployment diagrams
Package diagrams[3]
Component diagrams[3]
Deployment diagrams[3]
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 23
Architectural Styles The notion of patterns can be applied to software architecture. These are called architectural patterns or architectural styles.
Each allows you to design flexible systems using components
Garlan and Shaw define an architectural style as:
“ family of systems in terms of a pattern of structural organization. More specifically, an architectural style determines the vocabulary of components and connectors that can be used in instances of that style, together with a set of constraints on how they can be combined. These can include topological constraints on architectural descriptions (e.g., no cycles). Other constraints—say, having to do with execution semantics—might also be part of the style definition.” [4]
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 24
Architectural Styles There are several common styles for architecture:
Client/Server Architectural Style
Component-Based Architectural Style
Layered Architectural Style
Message-bus Architectural Style
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 25
Client/Server Architectural Style Segregates the system into two applications, where the client makes requests to the server. In many cases, the server is a database with application logic represented as stored procedures. [5]
A system composed of various software components that are distributed over several hosts.
There is at least one component that has the role of server, waiting for and then handling connections.
There is at least one component that has the role of client, initiating connections in order to obtain some service.
A further extension is the Peer-to-Peer pattern.
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 26
An example of a distributed system[3]
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 27
Component-Based Architectural Style Decomposes application design into reusable functional or logical components that expose
well-defined communication interfaces[5].
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 28
Domain Driven Design Architectural Style An object-oriented architectural style focused on modeling a business domain and defining business objects based on entities within the business domain.
Domain Driven Design Architectural Style Picture from: https://cdn.infoq.com/statics_s2_ 20191122- 0331/resource/articles/ddd-in- practice/en/resources/Architecture Diagram_lg.gif
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 29
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 30
Layered architectural Style Partitions the concerns of the application into stacked groups (layers).
Each layer has a well-defined interface used by the layer immediately above. The higher layer sees the lower layer as a set of services.
It is important to have a separate layer for the UI. Layers immediately below the UI layer provide the application functions determined by the use-cases.
Bottom layers provide general services.
e.g. network communication, database access
Layered Architectural Style
Message-bus Architectural Style
Prescribes use of a software system that can receive and send messages using one or more communication channels, so that applications can interact without needing to know specific details about each other[5].
https://msdn.microsoft.com/en-us/library/aa302165.aspx
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 33
N-Tier / 3-Tier Architectural Style Segregates functionality into separate segments in much the same way as the layered style, but with each segment being a tier located on a physically separate computer[5].
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 34
Object-Oriented Architectural Style A design paradigm based on division of responsibilities for an application or system into individual reusable and self-sufficient objects, each containing the data and the behavior relevant to the object[5].
http://www.hostitwise.com/software_design/nenios_architectural_component_llevel_design.html
Service-Oriented Architectural Style Refers to applications that expose and consume functionality as a service using contracts and messages.
https://www.eclipse.org/edt/papers/topics/egl_soa_overview.html
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 356 - 2019
reference 1. Clements, Paul; Felix Bachmann; Len Bass; David Garlan; James Ivers; Reed
Little; Paulo Merson; Robert Nord; Judith Stafford (2010). Documenting Software Architectures: Views and Beyond, Second Edition. Boston: Addison-Wesley. ISBN 0- 321-55268-7.
2. Perry, D. E.; Wolf, A. L. (1992). "Foundations for the study of software architecture" . ACM SIGSOFT Software Engineering Notes. 17 (4): 40. doi:10.1145/141874.141884
3. Timothy C. Lethbridge and Robert Laganière (2002)Object-Oriented Software Engineering: Practical Software Development using UML and Java .
4. [David Garlan and Mary Shaw, January 1994, CMU-CS-94-166, see "An Introduction to Software Architecture" at http://www.cs.cmu.edu/afs/cs/project/able/ftp/intro_softarch/intro_softarch.pdf]
5. https://msdn.microsoft.com/en-ca/library/ee658117.aspx#LayeredStyle
SPRING 2019
What is software architecture? Software architecture is
the fundamental structures of a software system,
the discipline of creating such structures,
the documentation of those structures
Each structure comprises software elements, relations among them, and properties of both elements and relations, along with rationale for the introduction and configuration of each element[1].
The architecture of a software system is a metaphor, analogous to the architecture of a building[2].
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 - 2019
Architecture Role
Yet, architecture must influence requirements “The art of the possible” Helps stakeholder understanding of risk/cost Helps stakeholder understanding of possibilities
Documenting software architecture facilitates communication between stakeholders, captures decisions about the architecture design, and allows reuse of design components between projects.
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 5
Architecture as a series of decisions Software architecture is about making fundamental structural choices
which are costly to change once implemented.
Each project normally has several alternative solutions. The job of architecture is to choose between these options which we call it Architectural options.
The Architecture makes an architectural decision to resolve each sub- problem. This process involves choosing the best option from among the alternatives.
6
Making decisions To make each design decision, the software engineer uses: Knowledge of
the requirements
Creative solutions
7
Making decisions example System: controller of the space shuttle which launch vehicle
Requirements: 1-being fast 2- being reliable.
To be fast, an appropriate real-time computing language would need to be chosen.
To satisfy the need for reliability the choice could be made to have multiple redundant and independently produced copies of the program, and to run these copies on independent hardware while cross-checking results.
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 356 - 2019
Architectural model A software architectural style is determined by the following:
A set of components
A topological layout of these components indicating their runtime interrelationships
A set of semantic constraints (e.g. a data repository is not allowed to changed the values in it)
A set of connectors that mediate communication, coordination, or cooperation among components
8
Architectural model example
Component Self-contained piece of a system with clearly defined interfaces
A component can be isolated, allowing you to replace it with a different component that has equivalent functionality.
Components should be designed to be reusable.
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 11
Connectors A linkage between components via an interface Way that two components talk
e.g. Webserver talks http or Database server talks sql
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 12
Architecture view points A system’s architecture can be described in terms of several different views The logical breakdown into subsystems
The interfaces among the subsystems
The dynamics of the interaction among components at run time
The data that will be shared among the subsystems
The components that will exist at run time, and the machines or devices on which they will be located
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 13
Architecture view points Popular viewpoint models include the 4+1 views on software architecture, the viewpoints and perspectices catalog by Nick Rozanski and Eoin Woods, and the IBM ADS viewpoint model by Phlippe Spaas et al.
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 14
Architecture view example Functional Viewpoint (logical view)
Purpose: capture the functional structure of the system
Content: the system’s runtime functional elements and their responsibilities, interfaces, and primary interactions
Concerns: functional capabilities, external interfaces, internal structure, and design philosophy
Models: functional structure model
Architecture view example
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 16
Design stable architecture To ensure the maintainability and reliability of a system, an architectural model must be designed to be stable.
Being stable means that the new features can be easily added with only small changes to the architecture
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 17
Developing an architectural model[3] Start by sketching an outline of the architecture Based on the principal requirements
and use cases
Choose among the various architectural patterns
https://msdn.microsoft.com/en-us/library/ff647894.aspx
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 18
Developing an architectural model[3] Refine the architecture Identify the main ways in which the components will interact and the interfaces
between them
Decide how each piece of data and functionality will be distributed among the various components
Determine if you can re-use an existing framework, if you can build a framework
Consider each use case and adjust the architecture to make it realizable
Mature the architecture
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 19
Describing an architecture using UML All UML diagrams can be useful to describe aspects of the
architectural model
Four UML diagrams are particularly suitable for architecture modelling: Package diagrams
Component diagrams
Deployment diagrams
Package diagrams[3]
Component diagrams[3]
Deployment diagrams[3]
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 23
Architectural Styles The notion of patterns can be applied to software architecture. These are called architectural patterns or architectural styles.
Each allows you to design flexible systems using components
Garlan and Shaw define an architectural style as:
“ family of systems in terms of a pattern of structural organization. More specifically, an architectural style determines the vocabulary of components and connectors that can be used in instances of that style, together with a set of constraints on how they can be combined. These can include topological constraints on architectural descriptions (e.g., no cycles). Other constraints—say, having to do with execution semantics—might also be part of the style definition.” [4]
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 24
Architectural Styles There are several common styles for architecture:
Client/Server Architectural Style
Component-Based Architectural Style
Layered Architectural Style
Message-bus Architectural Style
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 25
Client/Server Architectural Style Segregates the system into two applications, where the client makes requests to the server. In many cases, the server is a database with application logic represented as stored procedures. [5]
A system composed of various software components that are distributed over several hosts.
There is at least one component that has the role of server, waiting for and then handling connections.
There is at least one component that has the role of client, initiating connections in order to obtain some service.
A further extension is the Peer-to-Peer pattern.
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 26
An example of a distributed system[3]
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 27
Component-Based Architectural Style Decomposes application design into reusable functional or logical components that expose
well-defined communication interfaces[5].
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 28
Domain Driven Design Architectural Style An object-oriented architectural style focused on modeling a business domain and defining business objects based on entities within the business domain.
Domain Driven Design Architectural Style Picture from: https://cdn.infoq.com/statics_s2_ 20191122- 0331/resource/articles/ddd-in- practice/en/resources/Architecture Diagram_lg.gif
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 29
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 30
Layered architectural Style Partitions the concerns of the application into stacked groups (layers).
Each layer has a well-defined interface used by the layer immediately above. The higher layer sees the lower layer as a set of services.
It is important to have a separate layer for the UI. Layers immediately below the UI layer provide the application functions determined by the use-cases.
Bottom layers provide general services.
e.g. network communication, database access
Layered Architectural Style
Message-bus Architectural Style
Prescribes use of a software system that can receive and send messages using one or more communication channels, so that applications can interact without needing to know specific details about each other[5].
https://msdn.microsoft.com/en-us/library/aa302165.aspx
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 33
N-Tier / 3-Tier Architectural Style Segregates functionality into separate segments in much the same way as the layered style, but with each segment being a tier located on a physically separate computer[5].
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 34
Object-Oriented Architectural Style A design paradigm based on division of responsibilities for an application or system into individual reusable and self-sufficient objects, each containing the data and the behavior relevant to the object[5].
http://www.hostitwise.com/software_design/nenios_architectural_component_llevel_design.html
Service-Oriented Architectural Style Refers to applications that expose and consume functionality as a service using contracts and messages.
https://www.eclipse.org/edt/papers/topics/egl_soa_overview.html
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 356 - 2019
reference 1. Clements, Paul; Felix Bachmann; Len Bass; David Garlan; James Ivers; Reed
Little; Paulo Merson; Robert Nord; Judith Stafford (2010). Documenting Software Architectures: Views and Beyond, Second Edition. Boston: Addison-Wesley. ISBN 0- 321-55268-7.
2. Perry, D. E.; Wolf, A. L. (1992). "Foundations for the study of software architecture" . ACM SIGSOFT Software Engineering Notes. 17 (4): 40. doi:10.1145/141874.141884
3. Timothy C. Lethbridge and Robert Laganière (2002)Object-Oriented Software Engineering: Practical Software Development using UML and Java .
4. [David Garlan and Mary Shaw, January 1994, CMU-CS-94-166, see "An Introduction to Software Architecture" at http://www.cs.cmu.edu/afs/cs/project/able/ftp/intro_softarch/intro_softarch.pdf]
5. https://msdn.microsoft.com/en-ca/library/ee658117.aspx#LayeredStyle