Software Architecture. Schahram Dustdar Distributed Systems Group TU Wien

Transcription

1 Software Architecture Schahram Dustdar Distributed Systems Group TU Wien 1

2 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

3 SOFTWARE ARCHITECTURE: INTRODUCTION 3

4 Main Goals Provide an orientation on architecture Improve the quality of the software Understand architectural thinking 4

5 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

6 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

7 Analogy in Civil Architecture 7

8 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

9 Inspiration from Civil Architecture In analogy to civil architecture, software architecture aims to manage the complexity of the systems we build 9

10 ARCHITECTURE AND ARCHITECTURE DISCIPLINES 10

11 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

12 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

13 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: Non-functional properties 13

14 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

15 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

16 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

17 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

18 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

19 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.

20 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

21 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

22 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

23 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

24 Examples of Connectors Procedure call connectors Shared memory connectors Message passing connectors Streaming connectors Distribution connectors Wrapper/adaptor connectors 24

25 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

26 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

27 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

28 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.

29 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

30 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

31 Stakeholders in a System s Architecture Architects Developers Testers Managers Customers Users Vendors 31

32 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

33 Influencing factors Functional requirements Non-functional requirements Organizational factors Cultural factors Architecture Social factors 33

34 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

35 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

36 Architectural Refinement Domain Architecture structures Domain Components uses uses Technical Architecture structures Technical Components uses uses Platform Architecture structures 36 Platform Components

37 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

38 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

39 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

40 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

41 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

42 ARCHITECTURAL REQUIREMENTS 42

43 Architecture is always a compromise Marcus Vitruvius Pollio (born c 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. 43

44 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

45 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

46 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

47 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

48 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: Basic+use+case+template

49 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

50 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

51 ARCHITECTURAL PRINCIPLES 51

52 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

53 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

54 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

55 Cohesion Cohesion measures the dependencies within a component A class consists of methods and variables Components can have sub-components 55

56 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

57 Interdependence: Coupling and Cohesion Most often: the higher the cohesion of individual components, the lower the coupling between the components 57

58 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

59 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

60 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

61 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

62 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

63 Example: Information Hiding using the Facade Pattern 63

64 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

65 Many thanks for your attention! Schahram Dustdar Distributed Systems Group TU Wien 65