Software Architecture Architectural Viewpoints. Martin Pinzger Software Engineering Research Group

Size: px

Start display at page:

Download "Software Architecture Architectural Viewpoints. Martin Pinzger Software Engineering Research Group"

Johnathan Lindsey
5 years ago
Views:

1 Software Architecture Architectural Viewpoints Martin Pinzger Software Engineering Research Group

2 SERG Educa&on Programming, so1ware engineering MSc, BSc projects Research So1ware architecture So1ware tes&ng Repository mining Collabora&on Services Model- driven engineering End- user programming 2

3 3

Martin Pinzger Assistant Professor Delft University of Technology Research areas Software evolution and quality analysis, software visualization, software repository mining, collaborative software

4 Martin Pinzger Assistant Professor Delft University of Technology Research areas Software evolution and quality analysis, software visualization, software repository mining, collaborative software engineering Teaching Software engineering project (2nd year, BSc) Software architecture, software reengineering, software evolution (MSc) Supervising BSc, MSc and PhD students WWW: 4

5 Outline of the Lecture Defining a software architecture Architectural viewpoints Functional Information Concurrency Development Deployment Operation 5

6 Software Engineering Today 6

7 Architecture Definition Activities 1. Consolidate Input 2. Identify Scenarios 4. Produce Candidate Architecture 3. Identify Relevant Architecture Styles 5. Explore Architectural Options 7a. Rework Architecture 7b. Revisit Requirements 6. Evaluate Architecture with Stakeholders acceptable? not acceptable 7

8 MS Core Architecture Design Activities Figure 8

9 Questions for Designing an Architecture What are the main features of the system? What are the elements providing these features? Who will develop the system? On which hardware environment will the system run? Which technologies will be used? These questions can not be captured by only a single model 9

10 Key Design Strategy Use a set of interrelated architectural views to describe a software architecture Kruchten, Philippe. Architectural Blueprints The 4+1 View Model of Software Architecture. IEEE Software 12 (6), pp

11 Architectural Views A view is a representation of one or more structural aspects of a software architecture What stakeholders is the view addressing? Language How much do they need to know about this aspect? Level and amount of details Strategy Include only the details that help to explain and meet the stakeholder concerns 11

12 Architectural Viewpoints Collection of patterns, templates, and conventions for constructing one type of architectural view Reuse of architectural knowledge -> architectural patterns and style Nick Rozanski and Eoin Woods Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives ISBN:

13 Views and Viewpoints in Context Architectural Element n comprises Architecture relates to has an System is documented by addresses needs of n n Architecture documents for n Stakeholder Description n comprises n has n conforms addresses View Viewpoint Concern n n n 13

14 Catalogue of Viewpoints [Rozanski & Woods, 2005] 14

15 Functional Viewpoint 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 UML component diagram sketches 15

16 Example: Statistics Calculator Display Client StatsAccess {type=xml RPC, protocol=http, number=10 concurrent} Statistics Accessor Element interface and its use by other elements Tagged values used to make interface characteristics clear ReadStats Statistics Calculator Statistics Store StatsBatchUpdate {type=xml file} UML component represents a system element 16

17 Modeling Activities (1) Identify the elements (components) From the functional requirements Assign clear responsibilities to the elements Information managed by the element Services it offers to other elements Design the interfaces of the elements Each element has a well defined interface Operations, type of interface, input, output Precondition, postcondition 17

18 Example: Interface Definition Interface Type CORBA RPC Interface Definition struct Customer {... } interface ManageCustomer { custid addcustomer(customer newcustomer) raises invalidcustomer; void delcustomer(customer customer) raises nosuchcustomer; } Operations addcustomer Description: Adds a new customer... Precondition: First name, last name, address,... must not be null Postcondition: New customer is added, unique ID is allocated and returned. 18

19 Modeling Activities (2) Check the functional traceability Do the functions implement the functional requirements Walk through common scenarios Illustrate the stakeholders how the system will behave Analyze the interactions Try to minimize interaction (low coupling, high cohesion) Analyze the flexibility Walk through What if scenarios 19

20 Modeling Hints (1) Poorly defined interfaces Define interfaces clearly and as early as possible Review interfaces frequently Poorly understood responsibilities E.g., functionality is missing Infrastructure modeled as functional elements Do not model infrastructure elements, except it is necessary to understand the functionality -> they are part of the Deployment Viewpoint 20

21 Modeling Hints (2) Overloaded view Create views from other viewpoints that address the aspects Difficulty in reconciling the needs of multiple stakeholders Use different modeling languages for different stakeholders Create simplified views for non-technical stakeholders (sketches) Inappropriate level of detail Avoid detailed design of internal structure of an element Aim for less than top-level elements God elements Avoid 50% of functionality in less than 25% of elements 21

22 Information Viewpoint Content How the system stores, manipulates, manages, and distributes information Concerns Models Information structure and content; information flow; data ownership; timeliness, latency, and age; references and mappings; transaction management and recovery; data quality; data volumes; archives and data retention; and regulation Static data structure models, Information flow models, Information lifecycle models, Data ownership models, Data quality analysis, Metadata models, Volumetric models 22

23 Example: Book Rental 23

24 Modeling Hints: ER Diagram Strive for max 20 entities (presentable on one page) Focus on the most important entities No need to have normalized data No need to present all details Column type, foreign keys, etc. 24

25 Example: Hydraulic Simulation 25

26 Example: Book Rental Published Acquired Available Disposed Checked out 26

27 Modeling Hints (1) Data incompatibilities Different systems use different data formats Develop a common, higher-level model of the data Poor data quality Identify and evaluate data sources Figure out which data is important (with stakeholders) Poor information latency Check distance to information sources/providers Measure latency and review with the stakeholders 27

28 Modeling Hints (2) Interface complexity Transfer of information between n systems: n*(n-1)/2 data converters Consider using an Integration Hub Systems are linked via an adapter (data converter) to one integration hub Inadequate volumetrics Capture data volumes Translate business data into physical data volumes E.g., How much bytes need to be transferred for an order? Take into account future expansions Data volume is typically growing 28

29 Concurrency Viewpoint Content Mapping functional elements to concurrency units to clearly identify the parts of the system that can execute concurrently, and how this is coordinated and controlled Concerns Task structure, mapping of functional elements to tasks, inter-process communication, state management, synchronization and integrity, startup and shutdown, task failure, and re-entrancy Models System-level concurrency models State models 29

30 Example: Statistics Calculator Functional elements mapped to runtime processes <<process>> Win32 Client Process <<process>> Statistics Service Proc. DisplayClient Statistics Accessor <<process group>> DBMS Processes. Statistics Calculator Stereotyped class used to represent a process <<mutex>> stats update mutex Stereotyped class used to represent an IPC mechanism <<process>> Statistics Calc. Proc. Stereotyped class representing a group of related processes to simplify the model Statistics Calculator Relationships representing communication between processes (in some cases involving IPC mechanisms) 30

31 Modeling Activities Map functional elements to tasks (processes, threads) Only introduce concurrency where required -> complexity Determine the sharing of resources Access to which resources needs to be protected Locking mechanisms Assign priorities to tasks More important tasks should be executed first Analyze deadlocks 31

32 Example: Course Enrollment 32

33 Modeling Hints Do not model the internal concurrency of elements Keep it simple Resource contention and deadlocks Use scenarios to identify high levels of concurrency Introduce more fine-grained locking Prevent shared resources where possible Race conditions Protect resources from multiple updates 33

34 Development Viewpoint Content How the architecture supports and constraints the software development process Concerns Module organization, common processing, standardization of design, standardization of testing, instrumentation, and codeline organization Models Module structure models Common design models Codeline models 34

35 Example: Movie Theater 35

36 Modeling Activities (1) Identify and classify the modules and their dependencies No cycles between packages (ACP) Depend in direction of stability (SDP) Stable packages should be abstract packages and at the bottom (SAP) Common-Reuse Principle (CRP) Functionality/classes that are reused together go in the same package Either all functionality/classes in a package are reused together or none of them are Common-Closure Principle (CCP) Functionality/classes in a package should be closed together against the same changes A change affects all the classes in a package and not other package 36

37 Common Design & Codeline Organization Common design models Message logging, internationalization Use of 3rd party libraries Database interaction Codeline Organization Configuration management (modules, releases, branches) Building and testing Scope of tests and when do they run Release process 37

38 Modeling Hints (1) Too much detail Prevent implementation details (e.g., detailed class design) Minimize the number of design constraints for developers Involve the developers and testers 38

39 Deployment Viewpoint Content The environment into which the system will be deployed, including the dependencies the system has on its runtime environment Concerns Types of hardware required, specification and quantity of hardware required, third-party software requirements, technology compatibility, network requirements, network capacity required, and physical constraints Models Runtime platform models Network models Technology dependency models 39

40 Example: Product Line IAF23 interface to production line monitoring hardware. Production Line Interface Disk Array {mftr = sun, model = StorEdge4500} UML nodes used to represent hardware elements within deployment environment Primary Server {memory = 1Gb, model = V880, CPU = 2 x 750MHz, mftr = Sun} Data Capture Service Database Server {model = E420R, memory = 2Gb, mftr = Sun, CPU = 2 x 450MHz} SCSI connection, not network Oracle DBMS Instance Data Access Service Inter-node relationships show required interconnection paths Calculation Server {model = V880, mftr = Sun, memory = 1Gb, CPU = 4 x 1.1GHz} Prod. Line Operator PC {CPU = 750MHz, memory = 128Mb} Production Planner PC {memory = 512Mb, CPU = 1.2GHz} Predictive Calculator Operator Client Planner Client Functional elements mapped to hardware 40

41 Modeling Activities Design the deployment environment Identify the (available) server and client computers Identify the network links between computers Add special purpose hardware Map elements to hardware Which functional element/process is running on which hardware? Evaluate the hardware requirements 41

42 Modeling Hints Specify details of the hardware and software needed to run the system Software, version number, patches Use technology that you know Get advice from experts on new technology Create prototypes to learn and test the new technology Design the deployment view as part of your architecture Often deployment is considered after the system has been developed Did not know that the system also needs to run on Sun? 42

43 Operational Viewpoint Content Describes how the system will be operated, administered, and supported when it is running in its production environment Concerns Installation and upgrade, functional migration, data migration, operational monitoring and control, configuration management, performance monitoring, support, and backup and restore Models Installation models Migration models Configuration management models Administration models Support models 43

44 Example: Installation Model Installation Groups Win32 Desktop Client: Installation via InstallShield Database Schema: SQL script executed using the Perl script Web Interface: WEBINTERFACE component will be manually copied to Apache directory x/y/z Dependencies Win32 Desktop Client, Web Interface depend on Database Schema Constrains A restart of the Win32 Desktop Client will be required Backout Strategy Uninstallation all groups: Win32 Desktop Client: Run installer and select uninstall Database Schema: Execute Perl script with option --uninstall Web Interface: Delete the WEBINTERFACE component from the apache directory x/y/z 44

45 Relationships Between Viewpoints Functional Development Information Deployment Concurrency Operational 45

46 Consistency Between Viewpoints Design quality properties early Do not wait with consistency until your views are nearly complete Assign unique identifiers to model elements 46

47 Limitations of Viewpoints Viewpoints don t explicitly consider quality properties Their focus is more on the structure(s) of a software system Quality properties usually need cross-viewpoint consideration Viewpoints may lead to late consideration of quality properties Adding them later often is expensive 47

48 Summary Architectural viewpoints Guidelines to model the different structural aspects Keep views consistent early on Review views with stakeholders 48

49 Recommended Reading Nick Rozanski and Eoin Woods Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives ISBN:

50 Additional Reading Microsoft Microsoft Application Architecture Guide, 2nd Edition Online: 50

Additional Literature Software Architecture in Practice

Software Architectures: Views and Beyond Clements,

ISBN: 0-201-70372-6 Software Architecture: Foundations,

51 Additional Literature Software Architecture in Practice Bass, Clements, Kazman ISBN: Documenting Software Architectures: Views and Beyond Clements, Bachmann, Bass, Garlan, Ivers, Little, Nord, Stafford ISBN: Software Architecture: Foundations, Theory, and Practice Taylor, Medvidovic, Dashofy ISBN:

52 Further Architecture Resources Web sites, portals SEI s Software Architecture for Software-Intensive Systems The Gaudí System Architecting page: The Bredemeyer Architecture page: Software Product Lines: SoftwareArchitectures.com: Grady Booch s Handbook of Software Architecture: 52

53 Further Architecture Resources (cont.) Conferences WICSA ECSA SPLC Associations and working groups IFIP WG 2.10 Software Architecture: Portal: WWISA World-wide Institute of Software Architects: IASA International Association of Software Architects 53

OT TU1 Software Architecture Using Viewpoints and Perspectives

OT TU1 Software Architecture Using Viewpoints and Perspectives Eoin Woods Artechra Limited OT2004 - TU1 Software Architecture Using Viewpoints and Perspectives Nick Rozanski French Thornton eoin.woods@ nick.rozanski@ artechra.com french-thornton.co.uk (C) 2004 Artechra