Software ArchitectureArchitectural Viewpoints

Martin PinzgerSoftware Engineering Research Group

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

Assistant ProfessorDelft University of Technology

Research areasSoftware evolution and quality analysis, software visualization, software repository mining, collaborative software engineering

TeachingSoftware engineering project (2nd year, BSc)

Software architecture, software reengineering, software evolution (MSc)

Supervising BSc, MSc and PhD students

WWW: http://swerl.tudelft.nl/bin/view/MartinPinzger/

Martin Pinzger

4

Outline of the Lecture

Defining a software architecture

Architectural viewpointsFunctional

Information

Concurrency

Development

Deployment

Operation

5

Software Engineering Today

6

Architecture Definition Activities

2. Identify Scenarios

3. Identify Relevant Architecture Styles

5. Explore Architectural Options

6. Evaluate Architecture with Stakeholders

4. Produce Candidate Architecture

7a. Rework Architecture

7b. Revisit Requirements

not acceptableacceptable?

1. Consolidate Input

7

MS Core Architecture Design Activities

8

.NET Application Architecture Guide, 2nd Edition38

During the design process, you will create a list of the architecturally significant use cases, the architecture issues that require special attention, and the candidate architecture solutions that satisfy the requirements and constraints defined in the design process. A common technique for refining the design over time, until it satisfies all of the requirements and adheres to all of the constraints, is an iterative technique consisting of the five major stages shown in Figure 1.

Figure

Questions for Designing an Architecture

9

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

Key Design Strategy

10

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. 42-50.

Architectural Views

11

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

StrategyInclude only the details that help to explain and meet the stakeholder concerns

Architectural Viewpoints

Collection of patterns, templates, and conventions for constructing one type of architectural view

Reuse of architectural knowledge

-> architectural patterns and style

12

Nick Rozanski and Eoin WoodsSoftware Systems Architecture: Working With Stakeholders Using Viewpoints and PerspectivesISBN: 9780321112293

Views and Viewpoints in Context

13

Architectural Element

Architecture

Architecture Description

System

Stakeholderdocuments for

is documented by

has an

comprises

relates to

n

nn

View Viewpoint Concern

addresses needs ofn

conforms

n n n

addressesn

comprises hasnn

Catalogue of Viewpoints

14

[Rozanski & Woods, 2005]

Functional Viewpoint

15

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 diagramsketches

Example: Statistics Calculator

16

(C) 2004 Artechra Limited 2520040118

Overview of Viewpoints! Functional – Example Content Fragment

Display Client

StatisticsStore

StatisticsCalculatorReadStats

StatsBatchUpdate{type=XML file}

StatisticsAccessor

StatsAccess

{type=XML RPC,protocol=HTTP,number=10 concurrent}

Element interfaceand its use by otherelements

UML “component” representsa system element

Tagged values used to makeinterface characteristics clear

Modeling Activities (1)

17

Identify the elements (components)From the functional requirements

Assign clear responsibilities to the elementsInformation managed by the element

Services it offers to other elements

Design the interfaces of the elementsEach element has a well defined interface

Operations, type of interface, input, output

Precondition, postcondition

Example: Interface Definition

18

Interface TypeCORBA RPC

Interface Definitionstruct Customer { ...}

interface ManageCustomer {custID addCustomer(Customer newCustomer) raises invalidCustomer;void delCustomer(Customer customer) raises noSuchCustomer;

}

OperationsaddCustomerDescription: Adds a new customer ...Precondition: First name, last name, address, ... must not be nullPostcondition: New customer is added, unique ID is allocated and returned.

Modeling Activities (2)

Check the functional traceabilityDo the functions implement the functional requirements

Walk through common scenariosIllustrate the stakeholders how the system will behave

Analyze the interactionsTry to minimize interaction (low coupling, high cohesion)

Analyze the flexibilityWalk through “What if” scenarios

19

Modeling Hints (1)

Poorly defined interfacesDefine interfaces clearly and as early as possible

Review interfaces frequently

Poorly understood responsibilitiesE.g., functionality is missing

Infrastructure modeled as functional elementsDo not model infrastructure elements, except it is necessary to understand the functionality

-> they are part of the Deployment Viewpoint

20

Modeling Hints (2)

Overloaded viewCreate views from other viewpoints that address the aspects

Difficulty in reconciling the needs of multiple stakeholdersUse 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 15-20 top-level elements

“God elements”Avoid 50% of functionality in less than 25% of elements

21

Information Viewpoint

22

Content How the system stores, manipulates, manages, and distributes information

Concerns

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

Models

Static data structure models, Information flow models, Information lifecycle models, Data ownership models, Data quality analysis, Metadata models, Volumetric models

Example: Book Rental

23

Modeling Hints: ER Diagram

24

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 detailsColumn type, foreign keys, etc.

Example: Hydraulic Simulation

25

Example: Book Rental

26

Published Acquired Available Disposed

Checked out

Modeling Hints (1)

27

Data incompatibilitiesDifferent systems use different data formats

Develop a common, higher-level model of the data

Poor data qualityIdentify and evaluate data sources

Figure out which data is important (with stakeholders)

Poor information latencyCheck distance to information sources/providers

Measure latency and review with the stakeholders

Modeling Hints (2)

Interface complexityTransfer 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 volumetricsCapture 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

Concurrency Viewpoint

29

ContentMapping functional elements to concurrency units to clearly identify the parts of the system that can execute concurrently, and how this is coordinated and controlled

ConcernsTask 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

Example: Statistics Calculator

30

<<process>>Win32 Client Process

DisplayClient

<<process>>Statistics Service Proc.

Statistics Accessor

<<process>>Statistics Calc. Proc.

Statistics Calculator

<<mutex>>stats update mutex

<<process group>>DBMS Processes.

Statistics Calculator

Stereotyped classused to represent aprocess

Stereotyped class usedto represent an IPCmechanism

Stereotyped class representinga group of related processes tosimplify the model

Functional elements mappedto runtime processes

Relationships representingcommunication between processes(in some cases involving IPCmechanisms)

Modeling Activities

31

Map functional elements to tasks (processes, threads)Only introduce concurrency where required -> complexity

Determine the sharing of resourcesAccess to which resources needs to be protected

Locking mechanisms

Assign priorities to tasksMore important tasks should be executed first

Analyze deadlocks

Example: Course Enrollment

32

Modeling Hints

33

Do not model the internal concurrency of elementsKeep it simple

Resource contention and deadlocksUse scenarios to identify high levels of concurrency

Introduce more fine-grained locking

Prevent shared resources where possible

Race conditionsProtect resources from multiple updates

Development Viewpoint

34

Content How the architecture supports and constraints the software development process

ConcernsModule organization, common processing, standardization of design, standardization of testing, instrumentation, and codeline organization

ModelsModule structure modelsCommon design modelsCodeline models

Example: Movie Theater

35

Modeling Activities (1)

36

Identify and classify the modules and their dependenciesNo 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

Common Design & Codeline Organization

Common design modelsMessage logging, internationalization

Use of 3rd party libraries

Database interaction

Codeline OrganizationConfiguration management (modules, releases, branches)

Building and testing

Scope of tests and when do they run

Release process

37

Modeling Hints (1)

Too much detailPrevent implementation details (e.g., detailed class design)

Minimize the number of design constraints for developers

Involve the developers and testers

38

Deployment Viewpoint

39

Content The environment into which the system will be deployed, including the dependencies the system has on its runtime environment

ConcernsTypes of hardware required, specification and quantity of hardware required, third-party software requirements, technology compatibility, network requirements, network capacity required, and physical constraints

ModelsRuntime platform modelsNetwork modelsTechnology dependency models

Example: Product Line

40

Primary Server

{memory = 1Gb,

model = V880,

CPU = 2 x 750MHz,

mftr = Sun}

Data Capture Service

Data Access Service

Production Line

Interface

Disk Array

{mftr = sun,

model =

StorEdge4500}

Database Server

{model = E420R,

memory = 2Gb,

mftr = Sun,

CPU = 2 x 450MHz}

Oracle DBMS Instance

Prod. Line Operator PC

{CPU = 750MHz,

memory = 128Mb}

Operator Client

Production Planner PC

{memory = 512Mb,

CPU = 1.2GHz}

Planner Client

IAF23 interface

to production line

monitoring hardware.

Calculation Server

{model = V880,

mftr = Sun,

memory = 1Gb,

CPU = 4 x 1.1GHz}

Predictive Calculator

SCSI connection,

not network

UML nodes used to represent

hardware elements within

deployment environment

Functional

elements mapped

to hardware

Inter-node relationships

show required

interconnection paths

Modeling Activities

41

Design the deployment environmentIdentify the (available) server and client computers

Identify the network links between computers

Add special purpose hardware

Map elements to hardwareWhich functional element/process is running on which hardware?

Evaluate the hardware requirements

Modeling Hints

Specify details of the hardware and software needed to run the system

Software, version number, patches

Use technology that you knowGet advice from experts on new technology

Create prototypes to learn and test the new technology

Design the deployment view as part of your architectureOften deployment is considered after the system has been developed

Did not know that the system also needs to run on Sun?

42

Operational Viewpoint

43

Content Describes how the system will be operated, administered, and supported when it is running in its production environment

ConcernsInstallation and upgrade, functional migration, data migration, operational monitoring and control, configuration management, performance monitoring, support, and backup and restore

Models

Installation modelsMigration modelsConfiguration management modelsAdministration modelsSupport models

Example: Installation Model

44

Installation GroupsWin32 Desktop Client: Installation via InstallShieldDatabase Schema: SQL script executed using the Perl scriptWeb Interface: WEBINTERFACE component will be manually copied to Apache directory x/y/z

DependenciesWin32 Desktop Client, Web Interface depend on Database Schema

ConstrainsA restart of the Win32 Desktop Client will be required

Backout StrategyUninstallation all groups:Win32 Desktop Client: Run installer and select uninstallDatabase Schema: Execute Perl script with option “--uninstall”Web Interface: Delete the WEBINTERFACE component from the apache directory x/y/z

Relationships Between Viewpoints

45

Functional

Information

Concurrency

Development

Deployment

Operational

Consistency Between Viewpoints

46

Design quality properties early

Do not wait with consistency until your views are nearly complete

Assign unique identifiers to model elements

Limitations of Viewpoints

Viewpoints don’t explicitly consider quality propertiesTheir 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

Summary

48

Architectural viewpointsGuidelines to model the different structural aspects

Keep views consistent early on

Review views with stakeholders

49

Recommended Reading

Nick Rozanski and Eoin WoodsSoftware Systems Architecture: Working With Stakeholders Using Viewpoints and PerspectivesISBN: 9780321112293

Additional Reading

MicrosoftMicrosoft Application Architecture Guide, 2nd EditionOnline: http://msdn.microsoft.com/en-us/library/ff650706.aspx

50

51

Additional Literature

Software Architecture in PracticeBass, Clements, KazmanISBN: 9780321154958

Documenting SoftwareArchitectures: Views and BeyondClements, Bachmann, Bass, Garlan, Ivers, Little, Nord, StaffordISBN: 0-201-70372-6

Software Architecture: Foundations, Theory, and Practice Taylor, Medvidovic, DashofyISBN: 9780470167748

52

Further Architecture Resources

Web sites, portalsSEI’s Software Architecture for Software-Intensive Systems http://www.sei.cmu.edu/architecture/

The Gaudí System Architecting page: http://www.gaudisite.nl/

The Bredemeyer Architecture page: http://www.bredemeyer.com/

Software Product Lines: http://softwareproductlines.com/

SoftwareArchitectures.com: http://www.softwarearchitectures.com

Grady Booch’s Handbook of Software Architecture:http://www.booch.com/architecture/index.jsp

Further Architecture Resources (cont.)

ConferencesWICSA http://www.softwarearchitectureportal.org/WICSA/conferences/

ECSA http://www.ecsa2011.org/

SPLC http://softwareproductlines.com/

Associations and working groupsIFIP WG 2.10 Software Architecture:http://www.ifip.org/bulletin/bulltcs/memtc02.htm#wg210

Portal: http://www.softwarearchitectureportal.org

WWISA World-wide Institute of Software Architects:http://www.wwisa.org

IASA International Association of Software Architectshttp://www.iasarchitects.org

53