Overview of Sofware Architecture Sofware Architecture VO (706.706) - - PDF document

Overview of Sofware Architecture

Sofware Architecture VO (706.706)

Roman Kern 2020-10-04

Institute for Interactive Systems and Data Science, Graz University of Technology 1

# These slides should give an overview of the sofware architecture, and what its role is. # Why and when is sofware architecture important. # In other words: sofware architecture in a nutshell!

Overview - Motivation

Sofware Development in General Sofware entities are more complex for their size than perhaps any other human construct, because no two parts are alike (at least above the statement level). If they are, we make the two similar parts into one… In this respect sofware systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound. —Brooks, 1986

2

# In English, one refers to “it isn’t rocket science”, as if building rockets is the most complex task there is. # Now, let’s look, what could possibly the most complex part here… # Ariane 5 (4th June 1996) crash due to a sofware error: # https://www.youtube.com/watch?v=PK yguLapgA

Overview - Motivation

The big challenge of sofware development and sofware architecture: ⇒ Complexity (in various forms) Hint of a solution The technique of mastering complexity has been known since ancient times: Divide et impera (Divide and Rule). —Dijkstra, 1965

3

# I.e., the most important word in the context of sofware architecture: Com- plexity! # … this also the explanation, why big sofware projects appear to fail ofen. # There it also follows, that building complex systems is an team effort, and the sofware architect plays an vital role here.

Resources for Sofware Architecture

Books on sofware architecture

• A Sofware Architecture Primer by Reekie and McAdam
• Sofware Architecture in Practice by Bass, Kazman and Clemens
• The Process of Sofware Architecting by Eeles and Cripps
• Big Data: Principles and Best Practices of Scalable Realtime Data Systems by Marz

and Warrren

4

# There are also a number of great online resources, please have a look at the course website for links to a few selected ones!

Definitions of Sofware Architecture

Definition of sofware architecture

• http://www.sei.cmu.edu/architecture/start/glossary/community.cfm
• 100+ different definitions

5

# Ofen used analogy w.r.t. to sofware architecture, especially when we need sofware architecture: # For building a garden shell, one does not need a sophisticated architecture. # … but if one wants to build a skyscraper, this changes (need to take into account, many separate aspects: statics, plumbing, heating, elevators, es- cape paths, …)

Definitions of Sofware Architecture

Architecture is in Every System Ultimately, every sofware-intensive system has an architecture, be it intentional or

• accidental. Every such architecture serves to hold back the forces upon that system in

a manner that is functional, economical and elegant. – Booch 2009

6

— Booch; “Handbook of Sofware Architecture”

Sofware Architecture Process

(Over-)Simplified version of the sofware development process

• 1. Collect requirements
• What should the sofware do?
• 2. System architecture design
• What are the system components?
• How do they interact?
• 3. Implement the system
• Programming, documentation, testing, …
• 4. Deliver the system
• Deployment

Complimentary to this there are additional tasks

• Project management & administration
• Marketing, etc.

7

# In real life it is an ongoing effort throughout the project # Sofware architects work together with other specialists, e.g., business an- alysts are responsible to collect and also to weight requirements.

Sofware Architecture Process

In practice the sofware development process is more complex

• Many sofware development methodologies (e.g. waterfall vs. agile)
• Many types of type of sofware types (e.g. projects vs. products)
• Sofware architecture takes place during the whole process
• But with different emphasis
• In practice the requirements change; the setings change; the priorities change
• It is a sign of good architecture that it remains relatively stable

8

# E.g., for the practical part it would be realistic to the change the require- ment during the course (but will not happen).

Tasks of the Sofware Architecture

Part of sofware architecture

• Architecture on a high level
• Analyse the context (e.g. requirements, available skills)
• Design the structure of the system (e.g. components and their relationship)
• Design the behaviour of the system (e.g. sequence of operations)
• Define the environment (e.g. select libraries, deployment)

NOT part of sofware architecture

• Low-level design
• Class and variable names
• Implementation of algorithms
• Selection of data structures

9

# Some make a distinction b/w architecture and design.

Sofware Architecture Documentation

The output of the sofware architecture

• Documentation of the architecture
• Architecture description language (ADLs)
• Document the architecture in a formal way
• Typically graphical syntax
• Alternatively, existing programming languages have been adapted for architecture

specification

• Also document the design decisions
• Why has a certain decision being made?

10

# In general there is no common agreement, which language to use, i.e., there is not one single standard for how to formalise the architecture. # In this course a simple language will be presented (more simple than UML).

Stakeholders

Definition Stakeholder A stakeholder is an individual, team, or organisation (or classes thereof) with interests in, or concerns relative to a system. – IEEE 1471 2000

11

Stakeholders

Influence of stakeholders on the architect and architecture

12

Sofware Architecture Goals

Balance out the stakeholders needs

• Qality atributes (e.g. usability, security)
• System administrators (e.g. ease of administration)
• Marketing (e.g. competitive features)
• Cost & schedule (e.g. deliver on time to the client)
• Developers (e.g. clear requirements)
• Project management
• Deployment & maintenance

⇒ Functional and non-functional requirements

13

Sofware Architecture Aspects

Additional factors that influence the architecture

• Teams
• Skills
• Existing tools and off-the-shelf components
• Elegant solution

Geographically dispersed teams The architectural partitioning should reflect the geographic partitioning, and vice

• versa. Architectural responsibilities should be assigned so decisions can be made

(geographically) locally. – Coplien, 2005

14

# Coplien et al. Organizational Paterns of Agile Sofware Development.

Sofware Architecture

What is sofware architecture?

• … a science?
• Established series of conferences and journals
• … an art?
• At least it requires a considerable amount of creativity
• … an engineering discipline?
• What this course is about

⇒ All of the above.

15

Sofware Architect

Definition Sofware Architect [An architect is] the person, team, or organisation responsible for systems architecture. – IEEE 1471 2000 ⇒ Sofware architect is a role, i.e. it could be a group of people, or a single person could have additional roles in the project (e.g., project manager)

16

# Note: Comparison with film: architect = director, project manager = pro- ducer.

Sofware Architect

A sofware architect need to

• … understand the sofware development process
• … understand the business domain
• … needs design skills
• … needs programming skills
• … need to understand (organisational) politics

17

# In fact, many sofware architects have been hardcore hackers. # Architects sometimes get down to the details (to gain respect from devel-

• pers).

# Many technical people are scared by politics (b/w ambiguities), but e.g., people want to be treated differently.

Sofware Architect

Sofware architecture skills

One does not acquire design prowess overnight; instead, such skill is the result of years of experience. Even expert designers look back on their early work and shudder at how bad it was. As with every other skill, one must practise design in order to obtain proficiency. – Coplien, 2005

Sofware architecture life

The life of a sofware architect is a long and rapid succession of suboptimal design decisions taken partially in the dark. – Kruchten, 1999

18

— Kruchten, 1999, The architects: the sofware architecting team.

Sofware Architecture Approaches

Need to cut down the complexity

• Top down
• Start with the high level requirements
• Botom up
• Start with the existing infrastructure (e.g. existing components, libraries)

19

# Now, since complexity is the big challenge for sofware architecture, # … what tactics are there to address these challenges?

Sofware Architecture Approaches

Need to cut down the complexity

• Organise the architecture according to views
• Each view has a target audience
• Each view might represent a perspective (e.g. security perspective)
• Each view has one or more models
• Model are typically diagrams
• Plus additional documentation

Perspective An architectural perspective is a collection of activities, tactics, and guidelines that are used to ensure that a system exhibits a particular set of related quality properties that require considerations across a number of the system’s architectural views. – Rozanski, 2005

20

# Boing 747, 6 million parts, 75k engineering drawings. # Rozanski, Sofware Systems Architecture: Working with stakeholders Us- ing Viewpoints and Perspectives.

Sofware Architecture Approaches

Reuse #1: Architectural styles

• Re-use not only of sofware components, but also of concepts
• Known and understood templates of components, behaviour and constraints
• E.g. client-server architecture
• Also helps in the communication with the sofware engineering teams

Reuse #2: Existing skills

• Follow best practices for the individual teams

Reuse #3: Existing components

• Use existing sofware components
• Commercial or open-source off-the-shelf components
• Components internally developed by the organisation

21

Sofware Architecture Execution

During the implementation of the architecture

• Make sure that the exact architecture is implemented as planned
• Change in requirements and unforeseen problems will arise
• Sign of a good architecture
• The requirement and the context do change
• … but the architecture remains largely stable

22

# The notion of a stable architecture is just an intuition on how to measure the “quality” of an architecture. # … but we need a more rigorous concepts of measuring sofware archi- tecture quality.

Sofware Architecture Validation

Evaluate the quality of sofware architecture

• Have the goals been achieved?
• What has been the impact of the chosen architecture?
• … ofen neglected in practice

23

# We need to learn from existing architectures, gain experience. # … important to document design decisions.

Sofware Architecture Implications

Figure 1: Code complexity rises for added features depending on the sofware architecture

24

# Example of a sofware project. # The same system has been implemented twice. # … once just ad-hoc and a second time with proper sofware architecture. # Spit into 3 phases: # … initial system # … added another user interface # … added/changed the database (from SQL to NoSQL) # For the ad-hoc system, not making using of the best practice in sofware architecture, the initial costs (see via the code complexity) where the same. # But the more changes were introduces to the system, the bigger the dif- ference between a sound architecture and just badly planned architecture. # … so it pays of in investing in architecture!

The End

… of the overview of the sofware architecture process.

25