Software Architecture Schahram Dustdar Distributed Systems Group TU Wien 1
Main Topics Software Architecture: Introduction Architecture and Architecture Disciplines Architectural Requirements Architectural Principles Architectural Styles and Patterns Important Architectural Styles and Patterns Modeling Architectures Model-Driven Design and Development Architectural Views Architectural Decisions Architecture in the Organization 2
SOFTWARE ARCHITECTURE: INTRODUCTION 3
Main Goals Provide an orientation on architecture Improve the quality of the software Understand architectural thinking 4
Typical process of developing software developer s point of view Starting point: A wishlist Next step: A concept is created Then: Changes are needed Deviations from the concept are necessary Result: Big Ball of Mud 5
Big Ball of Mud In computer programming, Big Ball of Mud is a term for a system or computer program that has no real distinguishable architecture. 6
Analogy in Civil Architecture 7
Many IT-Projects Fail The big ball of mud scenario is not exaggerated Most of the IT projects fail more or less E.g.: Only 16 % of the projects in the study by [Standish 1994] have been concluded successfully Examples for failing are [Yourdon 2004]: Exceeding the budget Exceeding the time Customers are not satisfied with the delivered product The project gets cancelled 8
Inspiration from Civil Architecture In analogy to civil architecture, software architecture aims to manage the complexity of the systems we build 9
ARCHITECTURE AND ARCHITECTURE DISCIPLINES 10
Civil Architecture as a Starting Point Architecture Definition (American Heritage Dictionary): The art and science of designing and erecting buildings A style and method of design and construction Orderly arrangement of parts That is, architecture includes: The structure of a building or software system The act of designing this structure 11
What is Software Architecture? Architecture does not specify the details, but the load carrying components Think of coarse-grained components and subsystems rather than of individual classes an algorithms Architecture reaches from analysis of the problem to the realization of the solution Architecture aims to make complexity manageable Architecture deals with decisions that have system-wide consequences 12
Definition: What is Software Architecture? A software system s architecture is the set of principal design decisions about the system Software architecture is the blueprint for a software system s construction and evolution Design decisions encompass every facet of the system under development Structure Behavior Interaction There are numerous definitions of SW architecture: http://www.sei.cmu.edu/architecture/definitions.html Non-functional properties 13
What is Principal? Principal implies a degree of importance that grants a design decision architectural status It implies that not all design decisions are architectural That is, they do not necessarily impact a system s architecture How one defines principal will depend on what the stakeholders define as the system goals 14
Other Definitions of Software Architecture Perry and Wolf Software Architecture = { Elements, Form, Rationale } what how why Shaw and Garlan Software architecture [is a level of design that] involves the description of elements from which systems are built, interactions among those elements, patterns that guide their composition, and constraints on these patterns. Kruchten Software architecture deals with the design and implementation of the high-level structure of software. Architecture deals with abstraction, decomposition, composition, style, and aesthetics. 15
Temporal Aspect Architecture has a temporal aspect At any given point in time the system has only one architecture A system s architecture will change over time 16
Prescriptive vs. Descriptive Architecture A system s prescriptive architecture captures the design decisions made prior to the system s construction It is the as-conceived or as-intended architecture A system s descriptive architecture describes how the system has been built It is the as-implemented or as-realized architecture 17
Architectural Evolution When a system evolves, ideally its prescriptive architecture is modified first In practice, the system and thus its descriptive architecture is often directly modified This happens because of Developer sloppiness Perception of short deadlines which prevent thinking through and documenting Lack of documented prescriptive architecture Need or desire for code optimizations Inadequate techniques or tool support 18
Implementation-Level View of an Application Complex and virtually incomprehensible! 19 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2008 John Wiley & Sons, Inc. Reprinted with permission.
Deployment A software system cannot fulfill its purpose until it is deployed Executable modules are physically placed on the hardware devices on which they are supposed to run The deployment view of an architecture can be critical in assessing whether the system will be able to satisfy its requirements Possible assessment dimensions Available memory Power consumption Required network bandwidth 20
Software Architecture s Elements A software system s architecture typically is not (and should not be) a uniform monolith A software system s architecture should be a composition and interplay of different elements Processing Data, also referred as information or state Interaction 21
Components Elements that encapsulate processing and data in a system s architecture are referred to as software components Definition A software component is an architectural entity that encapsulates a subset of the system s functionality and/or data restricts access to that subset via an explicitly defined interface has explicitly defined dependencies on its required execution context Components typically provide application-specific services 22
Connectors In complex systems interaction may become more important and challenging than the functionality of the individual components Definition A software connector is an architectural building block tasked with effecting and regulating interactions among components In many software systems connectors are usually simple procedure calls or shared data accesses Much more sophisticated and complex connectors are possible! Connectors typically provide applicationindependent interaction facilities 23
Examples of Connectors Procedure call connectors Shared memory connectors Message passing connectors Streaming connectors Distribution connectors Wrapper/adaptor connectors 24
Configurations Components and connectors are composed in a specific way in a given system s architecture to accomplish that system s objective Definition An architectural configuration, or topology, is a set of specific associations between the components and connectors of a software system s architecture 25
Architectural Styles Certain design choices regularly result in solutions with superior properties Compared to other possible alternatives, solutions such as this are more elegant, effective, efficient, dependable, evolvable, scalable, and so on Definition An architectural style is a named collection of architectural design decisions that are applicable in a given development context constrain architectural design decisions that are specific to a particular system within that context elicit beneficial qualities in each resulting system 26
Architectural Patterns Definition An architectural pattern is a set of architectural design decisions that are applicable to a recurring design problem and parameterized to account for different software development contexts in which that problem appears A widely used pattern in modern distributed systems is the three-tiered system pattern Science Banking E-commerce Reservation systems 27
Three-Tiered Pattern Front Tier Contains the user interface functionality to access the system s services Middle Tier Contains the application s major functionality Back Tier Contains the application s data access and storage functionality 28 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2008 John Wiley & Sons, Inc. Reprinted with permission.
Architectural Models, Views, and Visualizations Architecture Model An artifact documenting some or all of the architectural design decisions about a system Architecture Visualization A way of depicting some or all of the architectural design decisions about a system to a stakeholder Architecture View A subset of related architectural design decisions 29
Architectural design Architectural Processes Architecture modeling and visualization Architecture-driven system analysis Architecture-driven system implementation Architecture-driven system deployment, runtime redeployment, and mobility Architecture-based design for non-functional properties, including security and trust Architectural adaptation 30
Stakeholders in a System s Architecture Architects Developers Testers Managers Customers Users Vendors 31
Software Architecture as a Discipline Architecture does not only encompass the architectural description of a system (structure) But also the activities of the architect Sometimes called the architecting of a system This includes the work with all the stakeholders of the system 32
Influencing factors Functional requirements Non-functional requirements Organizational factors Cultural factors Architecture Social factors 33
The Architect s Tasks and Roles Architectures and architecture disciplines Architectural perspectives Architectural means Architect Architectural requirements Organizations and individuals Architectural methods and procedures 34
Different system views (domain view, logical view, realization view, ) are modeled using UML diagrams in the documentation Functional requirements Non-functional requirements: Extensibility, Changeability, System should be well tested Example: Small student Web project in Java Domain model is designed first Refined to technical model Mapped to platforms (technologies) Architectural perspectives Architectural requirements Architectures and architecture disciplines Architect Architectural methods and procedures 35 Architectural means Organizations and individuals Iterative Development Agile Approach Programming language: Java Technologies: Hibernate, Web Server Concept: Object- Orientation UML for modeling in the documentation 2 Students: Programmers for functional building blocks 1 Student: Planning, documentation, and integration Teacher ~ Customer role
Architectural Refinement Domain Architecture structures Domain Components uses uses Technical Architecture structures Technical Components uses uses Platform Architecture structures 36 Platform Components
Domain Architecture The domain architecture reflects the problem space for which the system is developed Driven by the character of the domain Driven by the functional requirements Example: In an order fulfillment system, domain components for order entry, order management, customer management can be identified 37
Technical Architecture The technical architecture is domain-neutral and deals with realizing the non-functional requirements Examples: Logging, Auditing, Security, Data Consistency, Data Persistence, Transaction Management Technical components use services of the platform They can be used platform-neutrally by domain components 38
Platform Architecture The platform architecture provides services for executing software components Can contain hardware and/or software components Example: JEE is a component platform that uses itself various operating system and hardware platforms 39
Other Architecture Disciplines in IT Software architecture is only one of the architecture disciplines in IT IT systems get more and more complex Hence a specialization is necessary Software Architecture Network Architecture Integration Architecture Data Architecture Security Architecture System Management Architecture System Enterprise Architecture 40
Components A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to third-party composition. -- Clemens Szyperski, Component Software This definition encompasses many different concepts, such as: Subsystems DLLs JavaBeans ActiveX Controls JEE-Components.NET-Components Components in scripting languages (Tcl, Python, Perl)... 41
ARCHITECTURAL REQUIREMENTS 42
Architecture is always a compromise Marcus Vitruvius Pollio (born c. 80 70 BC, died after c. 15 BC) was a Roman writer, architect and engineer [ ] Vitruvius is famous for asserting in his book De architectura that a structure must exhibit the three qualities of firmitas, utilitas, venustas that is, it must be strong or durable, useful, and beautiful. http://en.wikipedia.org/wiki/vitruvius 43
Architectural Requirements The system must be designed to fulfill its requirements They must be properly balanced They have a different influence on the architecture Architectural requirements can be seen as forces that influence and form a system design Requirement Requirement Requirement Architecture Requirement Requirement Requirement Requirement 44
Requirements and their Properties A requirement...... is a capability of a system needed by a user of the system to solve a problem or reach a goal.... is a capability of a system to fulfill a contract, a standard, a specification, or another formal document. A requirement should be... correct in the view of the users and stakeholders of the system implementable with the given resources and in the given environment unambiguously defined testable 45
Kinds of Architectural Requirements Organization-Level Requirements based on System-Level Requirements based on Component-Level Requirements Functional Requirements Non-Functional Requirements Design Time Requirements Runtime Requirements Organizational Environment Requirements abstraction level 46
Functional Requirements Functional Requirements define the functionalities needed: They define what a system is supposed to accomplish For example they can be modeled using use cases Create Diagram Create Class Diagram Create Use Case Diagram Save Diagram Modeler Create Object Diagram Open Diagram Create Sequence Diagram Example: Use Case Diagram for a modelling tool 47 Create Activity Diagram
Example using the Basic Use Case Template by Cockburn Use Case: 5 Buy Goods CHARACTERISTIC INFORMATION Goal in Context: Buyer issues request directly to our company, expects goods shipped and to be billed. Scope: Company Level: Summary Preconditions: We know Buyer, their address, etc. Success End Condition: Buyer has goods, we have money for the goods. Failed End Condition: We have not sent the goods, Buyer has not spent the money. Primary Actor: Buyer, any agent (or computer) acting for the customer Trigger: purchase request comes in. MAIN SUCCESS SCENARIO 1. Buyer calls in with a purchase request. 2. Company captures buyer s name, address, requested goods, etc. 3. Company gives buyer information on goods, prices, delivery dates, etc. 4. Buyer signs for order. 5. Company creates order, ships order to buyer. 6. Company ships invoice to buyer. 7. Buyers pays invoice. EXTENSIONS 3a. Company is out of one of the ordered items: 3a1. Renegotiate order. 48 4a. Buyer pays directly with credit card: 4a1. Take payment by credit card (use case 44) 7a. Buyer returns goods: 7a. Handle returned goods (use case 105) SUB-VARIATIONS 1. Buyer may use phone in, fax in, use web order form, electronic interchange 7. Buyer may pay by cash or money order check credit card RELATED INFORMATION Priority: top Performance Target: 5 minutes for order, 45 days until paid Frequency: 200/day Superordinate Use Case: Manage customer relationship (use case 2) Subordinate Use Cases: Create order (use case 15) Take payment by credit card (use case 44) Handle returned goods (use case 105) Channel to primary actor: may be phone, file or interactice Secondary Actors: credit card company, bank, shipping service Channels to Secondary Actors: OPEN ISSUES What happens if we have part of the order? What happens if credit card is stolen? SCHEDULE Due Date: release 1.0 Sample in table format: From: http://alistair.cockburn.us/ Basic+use+case+template
Non-functional Requirements Non-functional requirements (NFR) define expectations or criteria that can be used to judge the operation of a system NFRs with direct implications: qualities or quality attributes Examples: Performance, Extensibility, Reusability,... NFRs with indirect implications: Standards, parameters, or conditions that must be considered or reached Examples: Budget, Regulations, Legislatives, Business Policies 49
Relevance of NFRs Fulfilling the NFRs is essential to the acceptance of the functionality of the system Nevertheless NFRs are often neglected The focus is often clearly on the functional requirements Major task of the architect: Sensitize the stakeholders for the importance of the NFRs NFRs should be considered even in early phases of architecting 50
ARCHITECTURAL PRINCIPLES 51
Architectural Principles Given the many influencing factors on an architecture: How to decide whether an architecture is good? It is difficult to say that an architecture is good or bad per se It just fulfills its functional and non-functional requirements better or worse But there are principles that can help when designing a software architecture 52
Coupling Coupling measures the dependencies among the components of an architecture Characterizes the interactions of the components Can be measured by counting the relationships among components There are many kinds of coupling that can be measured, such as: Coupling of classes Coupling of runtime objects Coupling of modules or components Coupling of HW components 53
Principle of Loose Coupling The coupling of components should be kept as low as possible 1 st Goal: Keep the complexity of structures low The less a components is coupled with other components, the easier it is understandable on its own 2 nd Goal: Increase the changeability of the architecture The less components are affected by a change in a component, the easier it is to do a change locally in a component without looking at the environment 54
Cohesion Cohesion measures the dependencies within a component A class consists of methods and variables Components can have sub-components 55
Principle of High Cohesion The cohesion of a component should be as high as possible As in loose coupling, the goal is to support understandability and changeability of components: If a component contains all elements that are needed to understand or change it, it can be understood or changed without looking at other components 56
Interdependence: Coupling and Cohesion Most often: the higher the cohesion of individual components, the lower the coupling between the components 57
Principle of Design for Change Design for change means to plan for foreseeable changes when designing an architecture Requirements that are likely to arise can be considered during planning Inconsistencies and unclear parts of requirement specifications can requirements that are likely to arise Experiences from designing similar architectures can be considered when designing a new architecture 58
Risks of Design for Change A more changeable design can also bear risks More development time High costs for more elaborate designs More implementation effort More flexible architectures often consume more resources (memory, performance) 59
Separation of Concerns Principle Different aspects of a problem should be separated from each other, and each aspect of the problem should be treated on its own Main kind of area of Separation of Concerns in SW architecture: Modularization Separate a software system into a structure of components 60
Other Kinds of Separation of Concerns in SW Architecture Separation of requirements Separation of a complex architecture model into views Separation of organizational responsibilities Separation of process into sub-processes Multi-dimensional separation of concerns (Aspect- Orientation) 61
Information Hiding Principle To a client present only the really necessary parts of the whole information and hide all the rest Goal: Reduction of the complexity of a SW architecture. Example: Hiding implementation details behind an interface 62
Example: Information Hiding using the Facade Pattern 63
Other Important Architecture Principles Abstraction Principles are using abstractions to make a complex problem understandable by identifying important aspects and neglecting less important ones E.g. Abstraction Principles with a focus on interfaces: Explicit Interfaces Segregation of Interface and Implementation Many other more special architecture principles: Modularization Principle (see above) Traceability Principle Self Documentation Principle Incremental Evolution Principle 64
Many thanks for your attention! Schahram Dustdar Distributed Systems Group TU Wien http://www.infosys.tuwien.ac.at/staff/sd 65