SOFTWARE ARCHITECTURE INTRODUCTION TO SOFTWARE ENGINEERING PHILIPPE LALANDA

Transcription

1 SOFTWARE ARCHITECTURE INTRODUCTION TO SOFTWARE ENGINEERING PHILIPPE LALANDA

2 PURPOSE OF THIS CLASS An introduction to software architecture What is an architecture Why it is important How it is represented 2

3 OUTLINE Definition An important activity A difficult activity Representation Conclusion 3

4 SOFTWARE ARCHITECTURE DEFINITION Software architecture is the high level structure of a software system, the discipline of creating such a high level structure, and the documentation of this structure. Documenting Software Architecture Views and Beyond, Clements, Bachmann, Bass, Garlan, Ivers, Little, Merson, Nord, Stafford; Addison-Wesley,

5 THREE TYPE OF VIEWS Module-based Structure as a set of implementation units Packages, Bundles, Jars, Projects Component and Connector (C&C) Structure as a set of elements that have runtime behavior and interactions Allocation-Centric How it relates to non-software elements 5

6 C&C - DEFINITION How a software system is decomposed into functional units in interaction Functional units are called components Interactions are called connectors Call-Return Event 6

7 C&C - DEFINITION What C&C views are for Showing how the system works Guiding development by specifying the structure and the behavior of runtime elements Helping architects and others to reason about runtime system quality attributes, such as performance, reliability and availability 7

8 COMPONENTS - DEFINITION Components Components are the principal computational elements and data stores that execute in a system. Components have interfaces called ports. Ports A port is an interface of a component. A port defines a point of interaction of a component with its environment. 8

9 CONNECTOR - DEFINITION Connector A connector is a runtime pathway of interaction between two or more components. Connectors endpoints are component ports. Role A role is an interface of a connector. A role defines a point of interaction of a connector and indicates how components may use a connector in interactions. 9

10 SOFTWARE COMPONENT - 1 Components Provided and Required functions / ports Properties, constraints (formal or informal) Possible some code Considered independently all along lifecycle Admin APIs provided ports required ports 10

11 SOFTWARE COMPONENT - 2 Two types of components Simple / Primitive / Scalar Contains an implementation Composites Abstract Component Provided functions Required functions Properties Constraints Contains Simple Component code Composite 11

12 CONNECTORS 1 Interaction specification First order objects The role, type of interactions Possibly a middleware to be used Architecture Contains Name Constraints Properties Contains (1,n) (1,n) Component (2,n) Connects (1,n) Connector 12

13 DIFFERENT TYPES OF CONNECTORS Some examples Data-flow Call-Return Eventbased Batch sequential Pipe and filter Client Server Peer to peer Serviceorientation Restful Publishsubscribe Point to point messaging Pipeline Unix Pipe and Filter Multi-tier client server Repository Shared data 13

14 EXAMPLE Logger Evt C/S Firewall Load balancer C/S C/S Web server II Web server I C/S C/S Application server DBMS C/S 14

15 EXAMPLE Logger Evt C/S Firewall C/S C/S Web server II Web server I C/S C/S Application server DBMS C/S 15

16 A SA IS A NEW LEVEL OF ABSTRACTION Used at design time and/or at runtime It does not bother with implementation details It provides relevant properties of components and connectors Abstraction Architectural elements Classes, procedures Data structures Assembly language 16

17 A SOFTWARE ARCHITECTURE IS A MODEL It provides an abstract, simplified view It is focused on some aspects At design time and at runtime Drives implementation and deployment Drives maintenance Execution 17

18 A SA IS A COMPLETE SPECIFICATION It is a guideline for developers/maintainers Must give all the necessary information Possibly used by partners, remote teams, Must be precise No place for fuzzy information Complete regarding the covered aspects! 18

19 ARCHITECTURE AND LIFECYCLE First design step Decompose the system into software components to reduce its complexity 2 Architectural design 1 Specification 3 Analyse Validation Legacy + wrapper 4 Detailed design 19

20 CONCLUSION Architecture explicitly appears in every software process Design time Cornerstone Agile methods stress the role of architecture Also important during maintenance Locate issues / bugs Retro-engineering is often required 20

21 OUTLINE Definition An important activity A difficult activity Representation Conclusion 21

22 A KEY STEP Budget Deadline Specification 22

23 A KEY STEP Communication Project structuration Lead technology choices Impact on quality and business 23

24 COMMUNICATION VECTOR Architecture provides a framework allowing most stakeholders to interact Presentation Negotiation Change requests Project management Quality evaluation, progress assessment Sometimes, too many interactions! 24

25 PROJECT STRUCTURATION Development plan definition Tasks definition Task allocation definition Roles / duties definition Interaction definition How teams are going to interact Methods, documents to be produced 25

26 TECHNOLOGIES DEFINITION Technological choices Technologies to be used JavaEE,.Net, Components to be developed Components to be reused Components to be bought Components Off the Shelves (COTS) Partnership definition IBM, Microsoft support 26

27 EXAMPLE Acquisition Logger Load balancer Evt C/S Firewall Reuse Web server II C/S C/S Open Source Web server I C/S Application server DBMS C/S C/S Internal JavaEE expertise Internal DBMS expertise 27

28 IMPACT ON SOFTWARE QUALITY Architecture has a strong impact on the system final properties An architecture favors or degrades non functional properties Performance and efficiency Security and safety Reliability and availability, A first compromise is made at the architectural level. In a definitive manner 28

29 EXAMPLE Application server DBMS On the same machine + reliability + performance On two different machines + availability (caches, ) + maintainability + large scale performance 29

30 EXAMPLE More examples A small number of components favors performance but not maintainability A large number of components favors maintenance but not performance Redundancy favors safety but not security It is the beginning of design headaches 30

31 IMPACT ON BUSINESS Deployment of an architecture allows the creation of a common assets Reusable components, specialized tools, training sessions Various optimizations Learning curve, infrastructure costs, An enterprise architecture is an infrastructure shared by the whole company Hard to change! 31

32 CONCLUSION Architectural decisions have an important, lasting impact Architectures must be carefully validated as soon as possible Evaluation reviews Prototypes development Key technologies evaluation Architecture influences quality but does not provide any guarantees 32

33 OUTLINE Definition An important activity A difficult activity Representation Conclusion 33

34 MULTIPLE INFLUENCES Organizational factors Technological factors Different actor The architect Starting from the same requirements, two architects will end up with two architectures. Why? 34

35 DEALING WITH PEOPLE, DEALING WITH INFLUENCES User Customer Project Leader Marketing/ Strategy Ops Customer Architect Developers 35

36 MARKETING / STRATEGY User Customer Project Leader Marketing/ Strategy Market tendency Coherence with company plans Coherence with company image (innovative, safe, ) Partnership coherence Ops Customer Architect Developers 36

37 PROJECT LEAD User Customer Project Leader Marketing/ Strategy Customer Overall simplicity Opportunity to assess progress Requirements meeting Mastered technology Structuration in line with existing teams Reuse of internal components and expertise Risk management Architect Ops Developers 37

38 DEVELOPERS User Customer Project Leader Marketing/ Strategy Well defined components, simple interfaces Hot technology No constraints on his components Ops Customer Architect Developers 38

39 OPS User Customer Project Leader Marketing/ Strategy Component isolation Administration oriented interfaces Known technologies Ops Customer Architect Developers 39

40 CUSTOMER User Customer Project Leader Marketing/ Strategy Guarantee of good behavior Efficient, cheap technologies Deadline meetings Ops Customer Architect Developers 40

41 USER User Customer Project Leader Marketing/ Strategy To the job Easiness of use Performance, security, robustness Ops Customer Architect Developers 41

42 EXAMPLE Architect : necessary to meet the requirements I have! User : interface stability? Web server Developer : cool! Ops: no, too instable! Client : no, too expensive! Application server Manager : cool, it is going to cost a lot! 42

43 ORGANIZATIONAL FACTORS Architectural decisions are deeply influenced by the organization goals and strategy Use of existing expertise and targeted expertise Existing internal methods Needs regarding reuse (to amortize past investments) Partnerships 43

44 EXAMPLE ORACLE : DBMS rules. No need for an application server! JBOSS: Application server matters. DBMS is not an issue.! Application server 1 1..* Database server Microsoft : Ok, but forget about Java! IBM : Good! Both are needed (WS et DB2)! 44

45 TECHNOLOGICAL FACTORS Technological changes Centralized vs. Distributed Rich client vs. thin client XML vs. JSON vs. YAML Web services vs. RestFul There is a fashion dimension! 45

46 ARCHITECT INFLUENCE Architects use their past experiences Good experiences will lead to reuse successful solutions Bad experiences will lead them to give up related solutions but conditions have changed Tools, runtimes, technologies evolve a lot! 46

47 ORGANIZATIONAL FACTORS Architectural decisions are deeply influenced by the organization goals and strategy Use of existing expertise and targeted expertise Existing internal methods Needs regarding reuse (to amortize past investments) Partnerships The architect must have a deep knowledge of the development team and technologies 47

48 OUTLINE Definition An important activity A difficult activity Representation Conclusion 48

49 APPLICATION TO SOFTWARE Several views also coexist in software programs (Parnas, 74) Organization, control flow, data flow Different programming tools are provided to express these structures Type definition, loop operators, This has to be applied to software architecture As for any software structure 49

50 SOFTWARE VIEWS - DEFINITION A view provides a focused perspective on a software It deals with a specific aspect It is a model A view defines Software artifacts Relationships between these artifacts Constraints and properties A formalism and a vocabulary Concerned with the target aspect 50

51 USUAL VIEWS A number of different views can be described There is no consensus depends on target domains Most commonly used Module views Code structuration C&C / Structural views How the software is structured into components Dynamic/Behavior views What are the interactions between components at runtime Allocation views Where the components are executed 51

52 SYNTHESIS Architecture = high-level structure Representation = a set of views 52

53 COMPONENT & CONNECTOR VIEW It defines the structure of the architecture Decomposition into functional elements All components and connectors are described Connections are potential Connectors can be complex Component 1 port1 connector port2 Component 2 receiver sender 53

54 C&C What C&C views are for Showing how the system works Showing where are the data Guiding development by specifying the structure and the behavior of runtime elements Helping architects and others to reason about runtime system quality attributes, such as performance, reliability and availability 54

55 C&C Elements Components: principal processing unit and data stored. Connectors: pathways of interaction between components Relations Attachment: component s ports are associated with connector roles to yield a graph of components Interface delegation: component s ports may be associated with one or more ports of a composite Constraints Components are attached to connectors Connectors are attached to components Attachments can be made only between two compatible ports 55

56 COMPONENTS - DEFINITION Components Components are the principal computational elements and data stores that execute in a system. Components have interfaces called ports. Properties (performance, persistence, robustness, ) Constraints Ports A port is an interface of a component. A port defines a point of interaction of a component with its environment. 56

57 CONNECTOR - DEFINITION Connector A connector is a runtime pathway of interaction between two or more components. Connectors endpoints are component ports. Provided service / Required Service Constraints Pre/Post-conditions Ordering, Orchestration 57

58 LOGICAL VIEW: INTERACTIONS Role A role is an interface of a connector. A role defines a point of interaction of a connector and indicates how components may use a connector in interactions. Type Communication: Data-Flow Coordination: Control Flow Mediation: Data Transformation, monitoring, nonfunctional operations Communication modes Procedure Call: CR, RPC, C/S Event-based: broadcast, Publish/Subscribe,... 58

59 TYPES OF CONNECTORS Data-flow Call-Return Eventbased Batch sequential Pipe and filter Client Server Peer to peer Serviceorientation RestFul Publishsubscribe Point to point messaging Pipeline Unix Pipe and Filter Multi-tier client server Repository Shared data 59

60 C&C VIEW: FORMALISM Port component port1 port2 Connector Component 1 port1 Client/server port2 Component 2 receiver sender Type Role 60

61 C&C VIEW: UML FORMALISM Port Connector Role Type 61

62 C&C VIEW: INTERESTS Provides answers to the following questions What are the main computing elements? What are the main data sources? What are the main control flows? What are the critical paths and the performance criteria? What are the possible bottlenecks? What are the needs in terms of computing platforms? What are the levels of coupling and cohesion? 62

63 LOGICAL VIEW: USAGE EXAMPLE Bottlenecks, Not used ports C2 C1 C3 C5 C4 63

64 OUTLINE Definition An important activity A difficult activity Representation Conclusion 64

65 MAJOR POINTS Software Architecture is a model Module C&C Allocation 65

66 MAJOR POINTS Decomposition of a system into components and connectors Hard to remain in sync with developments Hard to recover Hard to change once defined 66

67 SOFTWARE ARCHITECT The architectʼs role is to define architectures and to make them resilient Project and organization level A hard job High technical skills Ability to abstract problems out Good knowledge of SE principles High communication skills 67

68 ARCHITECTURE IMPORTANCE Today recognized as a major step in software production This is reinforced by outsourcing Creation of the software architect position In many companies since 2000ʼs Bill Gates was Microsoft chief architect! 68

69 PROBLEMS A recent, immature domain No standard representation No standard process No evaluation tools Many different types of architectures: functional, technique, etc. Many companies are struggling to define/install guiding processes Ad-hoc solutions today 69

70 REFERENCES Software architecture in practice - second edition Len Bass, Paul Clements, Rick Kazman Addison Wesley, 2003 Pattern-oriented software architecture Buschmann, Meunier, Rohnert, Sommerlad, Stal Wiley, 1996 Applied software architecture Hofmeister, Nord, Soni Addison Wesley, 2000 Design and use of software architectures Jan Bosch Addison Wesley,