Bro110 5 1_software_architecture

Copyright by Brockhaus GmbH, alle Rechte reserviert, unautorisierte Vervielfältigung untersagt
1
Session: Software Architecture
Software Architectures
The Software Architekt
The Architectural process
Some words on patterns

2
Welcome
in
An investment in knowledge
always pays the best interest
--- Benjamin Franklin

3
Objectives
✔ Get a general idea about :
➢ What Software Architecture is about
➢ The role and the duties of a software architect
➢ The architectural process

4
Only a joke ?
As proposed by
the project
sponsor.
As specified in
the project
request
As designed by
the senior
analyst
As implemented
by developers
As installed at
user's site
What the user
wanted

5
The Chaos Report

6
Module
Software Architecture:
Definitions

7
Software Architecture
What is it about?
✔ As a maturing discipline with no clear rules on the
right way to build a system, designing software
architecture is still a mix of art and science.
– Djikstra
✔ Software-Architektur deals with abstraction,
decomposition and assembly, with style and
aesthetics
– Kruchten
Edsger Wybe Dijkstra
Phillipe Kruchten

8
✔ What do we mean by a software architecture?
To me the term architecture
➢ conveys a notion of the core elements of the system
➢ the pieces that are difficult to change
➢ a foundation on which the rest must be built.
More than 50 different definitions to be found at:
http://www.sei.cmu.edu/architecture/start/glossary/community.cfm
Martin Fowler

9
Software architecture
✔ The software architecture of a program or computing system is the
structure of the system, which comprise:
➢ software components,
➢ the externally visible properties of those components,
➢ and the relationships between them
✔ "Externally visible" properties are those assumptions other
elements can make of an element, such as
➢ its provided services,
➢ performance characteristics,
➢ fault handling,
➢ shared resource usage, and so on.

10
Software architecture is
✔ commonly organized in views:
➢ Functional/logic view
➢ Code/module view
➢ Development/structural view
➢ Concurrency/process/thread view
➢ Physical/deployment view
➢ User action/feedback view
➢ Data view
✔ UML was established as a standard
"to model systems (and not just software)"

11
Software elements:
✔ An architecture is an abstraction of a system that
suppresses details of elements that do not affect
➢ how they use,
➢ are used by,
➢ relate to,
➢ or interact with other elements.
✔ Elements interact with each other by means of
interfaces that partition details about an element
into public and private parts.
✔ Architecture is concerned with the public side of this division;
private detail those having to do solely with internal
implementation are not architectural.

12
✔ in between design and realisation
architecture bridges problem domain, subject
matter experts and technical realisation
✔ based upon various decisions
some of them deal with the components,
some of them deal with the technologies used
✔ the framework for flexible systems
considering external changes (organisational /
technical)
✔ is abstraction
systematically omit information not needed keeps architecture
clear.

13
Why does it matter?
✔ Regarding the management software
architecture provides the first idea whether
requirements are met.
✔ Regarding new team members software
architecture provides the base to get familiar
with the structure of the system, it's design
and it's elements.
✔ Regarding maintenance and change of existing
systems, software architectures simplify impact
analysis of changes.

14
Stakeholders
.. in a System’s Architecture
✔ Architects
✔ Developers
✔ Testers
✔ Managers
✔ Customers
✔ Users
✔ Vendors

15
Module
Software Architect

16
The lawyer of the customer and the consultant of the implementation team
– Gernot Starke
Software Architect
Software Architect:
✔ A general term with many accepted definitions,
which refers to a broad range of roles in
➢ Design
➢ Communication
✔ With a lot of responsibilities in various fields

17
Software Architect
Design:
✔ high-level design choices much more often
than low-level choices.
✔ sometimes dictate technical standards,
including (but mot limited to)
coding standards, tools, or platforms
✔ rarely deal with the physical architecture of the
hardware environment, confining themselves to the design
methodology of the code.

18
Software Architect
Communication:
✔ have to communicate effectively, not only to
understand the business needs, but also to
advance their own architectural vision.
✔ can do so verbally, in writing, and through
various software architectural models that
specialize in communicating architecture.

19
Software Architect
Architects construct and design:
✔ Components and subcomponents and
their respective responsibilities
✔ Interfaces through those the components interact
(design by contract)
✔ Interaction described by statical and
dynamical structures
Dr. Gernot Starke

20
Software architects
Architects decide
✔ Which components, which interfaces, which frameworks, to make
or to buy, which team develops which component, …
✔ All decisions might affect the system on the
long run, very often architects have to deal
with innovative frameworks
(so all decisions need to be documented well).
Architects guarantee meeting the requirements
✔ Feasibility and fulfillment are in the scope
of an architect as well
✔ Prototypes are unevitable part and also costs
are not out of scope.

21
Software architects
Architects consult
✔ Regarding project plan and project organisation
✔ Project lead regarding management of the team, management of
technological risks
✔ The implementation teams in terms of
explaining, convincing and coaching

22
Software architects
Architects document
✔ Look out for templates, try arc42 (http://www.arc42.de/)
Architects communicate
✔ .. as mentioned before

23
Successful architects
According to „The mythical man month“
by Frederick P. Brooks (in 1975), an architect:
✔ "suggests" ("not dictates") implementation because
the programmer/coder/builder has the "inventive
and creative responsibility."
✔ should have an idea of how to implement his or
her architecture, but should be "prepared to accept any other way
that meets the objectives as well."
✔ should be "ready to forego credit for suggested improvements."
✔ should "listen to the builder's suggestions for architecture
improvements."
✔ should strive for work to be "spare and clean," avoiding "functional
ornamentation" and "extrapolation of functions that are obviated
by changes in assumptions and purposes."

24
Module
Software Architect
and software development

25
Software architects don't code?
or: the Microsoft perspective (from Microsoft Architect
Certificate)
✔ Enterprise architects: set the overall vision and framework
for the IT environment from a strategic business perspective.
✔ Solutions architects: design the solution to take advantage of
the existing assets, integrate them into the existing environment,
follow the enterprise architecture, and solve the business problems
of the business owner or unit.
✔ Infrastructure architects: responsible for creating an
architecture that meets the business and service level
agreement requirements of the business owners and supports the
applications and solutions that are required to operate their day-
to-day businesses.

26
According to previous slide, software architects:
✔ talk with the business, comes up with solutions and make bright
key decisions about architecture.
✔ they don’t program/implement
✔ during the course of the project
they ensure that developers
don’t spoil this great
architecture.

27
But in contrast, some architects:
✔ Might have outdated programming
knowledge and experience, loss of touch
with modern development approaches and
practices.
✔ Might don’t know much about evolving
system internals, but makes key technical
decisions.
✔ Might have often a completely irrelevant and unreal picture what is
happening with the system.

28
But in contrast, architects:
✔ Might tends to complex, premature and
generic solutions when the system is still
in infancy and nothing is clear.
✔ Applies latest modern buzzword
technologies as SOA, MDA, SaaS,
Software Factories, etc. which look so
beautiful in technical magazines,
conferences and CV, but cause unnecessary headache for
developers.

29
Successfull architects
… in addition to Frederick P. Brooks:
✔ Guards a system against failure,
sensing worrying changes in the
project dynamic, system code and
business requests.
✔ Keeps the trinity of system qualities
in a balance and prevent degradation
and entropy:
➢ Firmitas (Strength) – the system is reliable, secure, has good
performance and easy to support
➢ Utilitas (Utility) – the system is usable, meets business business needs
and add business value every day instead of drifting into technology
trenches
➢ Venustas (Beauty) – code and system structure are clean, easy to
understand, minimal

30
… in addition to Frederick P. Brooks (cont.):
✔ Encourages constant improving of the code design, enhancing
system abstractions and structure, removing duplication, defining
boundaries and interfaces of the subsystems.
✔ Keeps solutions as simple as possible, maintains intellectual control
over system and avoids over-engineering.
✔ Most important – grows and coaches
other developers to become architects

31
Module
The Architectural Process

32
Architectual process
An overview
As an architect you might follow/obey the following:
✔ Gather information
✔ Develop an idea about the system
✔ Identify drivers and boundary conditions
✔ Identify the risks
✔ Define the quality
✔ Develop strategies

33
Gather information
✔ How did others before?
Only very few things are build completely new, try to find similar
solutions.
✔ Scan for patterns
✔ Use your experience as the customer
expects profound knowledge technically
as well as within the domain
✔ In most of the cases, wide parts of
existing solutions can be reused.

34
Develop an idea about the system
Some of the most important aspects of the system should be known:
✔ What is the purpose of the system
✔ Who uses the system and how is the
system used
✔ What kind of user interface will be used
✔ Where are interfaces to other systems
✔ How to use / store data
✔ How to administer the system
✔ What about printing, reporting, etc.

35
Identify drivers and boundary conditions
Software architecture isn't dealing with technologies alone, a lot of
other things have some influence on the architecture
✔ Organisational aspects
✔ Resources
✔ Existing standards
✔ Rules and regulation

36
Identify the risks
There will be no single project where everything goes as expected, an
architect has to know about the risks and has to deal with them.
✔ Organisational risks
Lack of time, budget, knowledge
✔ Performance
… matters, no doubt about that
✔ Maintainability and flexibility
… design for changes with respect to
performance
✔ Availability

37
Define the quality
✔ Quality can't be measured directly as only specific features can be
measured (e.g. resource efficiency)
✔ Different stakeholders have different ideas of quality:
➢ Management: cost efficency, flexibility, maintainability
➢ Users: performance, usability
➢ Ops: administrability, security
✔ Architecture is prerequisite for quality but not
a guarantee (maybe poorly implemented),
excellent code does not imply good
architecture.

38
Define the quality
✔ Quality of software systems is alway in relation to characteristics,
e.g. performance, availability, interoperability, usability, …
(@see DIN/ISO 9126)
✔ Quality attribute scenarios capture non-functional requirements of
a system in terms of standard quality attributes,
such as Availability, Modifiability, and so on.
✔ These are independent of specific functional
requirements and describe desired qualities
of a system.

39
Quality attribute scenarios
✔ Statements like “a system will have high performance” or “a
system will be user friendly” are acceptable in the really early
stages of requirements elicitation process.
✔ As more information becomes available, the above statements
become useless as they are meaningless for the purpose of
actually designing a solution.
✔ Both statements are useless as they provide no tangible way of
measuring the behavior of the system.
✔ Writing detailed statements is only possible
when relevant requirements have been
identified and an idea of components has
been proposed.

40
✔ The quality attributes must be described in terms of scenarios,
such as “when 100 users initiate ‘complete payment’ transition, the
payment component, under normal circumstances, will process the
requests with an average latency of three seconds.”
✔ These kind of statements, or scenarios, allows an architect to make
quantifiable arguments about a system.
✔ A scenario defines:
➢ the source of stimulus (users),
➢ the actual stimulus (initiate transaction),
➢ the artifact affected (payment component),
➢ the environment in which it exists (normal operation),
➢ the effect of the action (transaction processed),
➢ and the response measure (within three seconds)

41
Develop strategies
✔ against lack of resources and be aware of:
➢ No one performs better if put under pressure
➢ Putting more members of a project team might
cause a bigger delay
➢ If management does not back the
project it will never become a
success
✔ towards increased performance
➢ Use profilers even at the early stages
➢ Hardware is cheaper than redesign
➢ Decrease abstraction
➢ ...

42
Develop strategies
✔ covering adaptability and flexibility
➢ Figure out, where it is needed (functionality, data model, 3rd
party
software, user interface, operating system, ...)
➢ Almost every time in contrast to performance
➢ What-if scenarios might be helpful

43
Module
Introduction to Patterns
Each pattern describes a problem which occurs over and over again in our environment,
and then describes the core of the solution to that problem, in such a way that you can use
this solution a million times over, without ever doing it the same way twice.
--- Christopher Alexander

44
Design, Architecture and … Patterns
Design is a challenging task:
➢ Balancing concerns, e.g. performance, adaptability, reliability.
➢ Defining components and their interrelationships.
Thus experienced designers:
➢ Rarely start from first principles
➢ Look for similarities to problems solved in the past.
➢ Apply a working "handbook" of approaches
Patterns make expert knowledge widely available
➢ Supports focusing on the truly distinctive design problems.
➢ Aids design evaluation at higher level of abstraction
➢ Provides a useful working vocabulary for design.

45
What is it about ?
A Pattern:
✔ ... solves a real problem, reuse of solutions already designed.
✔ ... faculitates sharing of knowledge.
✔ ... forms a vocabulary for communication between software
architects.
✔ ... limits possible solutions to best practices.

46
Types of pattern
Architectural Patterns:
✔ expresses a fundamental structural organization or schema for
software systems.
✔ provides a set of predefined subsystems, specifies their
responsibilities, and includes rules and guidelines for organizing
the relationships between them.
Design Patterns:
✔ a scheme for refining the subsystems or components of a software
system, or the relationships between them.
✔ describes commonly recurring structure of
communicating components that solves a
general design problem within a particular
context.

47
Types of pattern
Idioms:
✔ low-level pattern specific to a programming language.
✔ An idiom describes how to implement particular aspects of
components or the relationships between them using the features
of the given language.

48
History of ...
Overview:
✔ 1977: Christopher Alexander developed at Center
For Environmental Structure at Berkeley a theory of
using patterns within architecture.
✔ 1991: Erich Gamma wrote his Ph.D. dissertation about the usage
of patterns within software developments – only recognized
withing germany.
✔ 1995: Inspired by Alexander Ward Cunningham and Kent Beck
introduced the first five patterns for design of user interfaces.
✔ 1996: The book of the so-called „Gang-Of-Four“ sets
the pace to broad acceptance of patterns within
Software-Engineering.

49
Patterns everywhere?
✔ Gang of Four Pattern: Erich Gamma, Richard Helm,
Ralph Johnson and John Vlissides
✔ POSA 1 Pattern: Pattern oriented software
architecture (Frank Buschmann et. al.)
✔ Core J2EE Pattern: Alur, Cupri, Malks
✔ Patterns of Enterprise Application Architecture:
Martin Fowler et. al.
✔ Enterprise Integration Patterns:
Hophe, Woolf et. al.
✔ Workflow Pattern: van der Aalst et. al.
✔ SOA Design Pattern: Thomas Erl
✔ SOA Pattern: Presentation of Michael Stal

50
Why using Patterns?
Pattern:
✔ ... are explicitly based on fundamental priciples of constructing
robust applications like information hiding or loose coupling.
✔ ... adress the importance of non-functional aspects like
maintainability or reliability.
✔ ... complement problem-centric methods to develop software by
guidelines to design.
✔ ... support analysis and design.

51
Keys to Using Patterns Effectively
✔ Recognition comes with experience
✔ Searching is aided by a catalog taxonomy
✔ Recognize, search, instantiate:
➢ Recognize a problem as common (déjà vu).
➢ Recognize the key elements of the problem.
➢ Search a pattern catalog from proven solution templates.
➢ Instantiate the template for the specific problem.
➢ Algorithm and data structure selection.

52
Patterns, the silver bullet ?
Pattern:
✔ ... If used wrong might make systems more complex than
needed.
✔ ... if used wrong might cause problems by themselves.
✔ ... shouldn‘t be used for the sake of themselves
„As a rule of thumb, the value of a method
is inversely proportional to it‘s universality. “
--- Michael A. Jackson 1995

53
Pattern taxonomy/catalogues
… or: How to describe and order them?
✔ Name:
➢ A good, descriptive name is critical.
➢ Good names communicate.
➢ Poor names obfuscate.
➢ Goal: Increase design vocabulary.
➢ Goal: Raise level of design discussion.
✔ Problem:
➢ Brief, abstract description.
➢ Includes design context.

54
✔ Solution:
➢ Components (classes/objects) and interconnections.
➢ Generic control and data flow supported by the pattern.
➢ Template, not a cookbook.
✔ Consequences & Tradeoffs:
➢ Positive results.
➢ Negative implications.
➢ Tradeoffs: time, space, flexibility, performance, etc.

55
✔ Implementation issues:
➢ Effects of language (i.e., Java vs. C++).
➢ Alternative tactical approaches.

56
Pattern and Frameworks
What is a framework
✔ A set of reusable designs and objects used to build applications
✔ Defines how objects work together to get something done
✔ Defines the superclasses or public interface for the object that you
develop
✔ Your objects work within the framework
✔ A framework is a "semi-complete" application

57
What is a framework
✔ A framework usually supports a very specific domain
➢ GUI (large)
➢ Collections (small)
✔ Usual characteristics of a good framework
➢ Relatively easy to understand and use
➢ Provides a solution to a common problem
➢ Can be used over and over again

58
Benefits of OO application frameworks:
✔ Modularity:
➢ enhance modularity by encapsulating volatile implementation details
behind stable interfaces
➢ reduces the effort required to understand and maintain existing
software.
✔ Reusability
➢ stable interfaces define generic components that can be reapplied to
create new applications.
➢ avoid re-creating and re-validating common solutions
to recurring application requirements and
software design challenges.

59
Benefits of OO application frameworks (contd.):
✔ Extensibility
➢ providing explicit hook methods that allow applications to extend its
stable interfaces.
➢ decouple the stable interfaces and behaviors of an application domain
from the variations required by instantiations of an application in a
particular context.
✔ Inversion of control
➢ allows the framework (rather than each application) to determine which
set of application-specific methods to invoke in response
to external events

60
Conclusion:
✔ Patterns:
➢ focus on reuse of abstract designs and software micro-architectures.
➢ an be viewed as more abstract micro-architectural elements of
frameworks
➢ document and motivate the semantics of frameworks in an effective
way
✔ Frameworks:
➢ concrete reification of families of design patterns that are targeted for a
particular application-domain.
➢ represent recurring solutions to software development problems within
a particular context.
Patterns and frameworks both facilitate reuse by capturing successful
software development strategies.

61
Review
Session Review:
✔ What is the role of a software architect?
✔ Do software architects implement code by themselfes?
✔ How to get an idea of the software architecture within you
projects?
✔ What about pattern?

Copyright by Brockhaus AG - Brockhaus GmbH © 2009 - 1
1
Session: Software Architecture
Software Architectures
The Software Architekt
The Architectural process
Some words on patterns

2
Welcome
in
An investment in knowledge
always pays the best interest
--- Benjamin Franklin

3
Objectives
✔ Get a general idea about :
➢ What Software Architecture is about
➢ The role and the duties of a software architect
➢ The architectural process

4
Only a joke ?
As proposed by
the project
sponsor.
As specified in
the project
request
As designed by
the senior
analyst
As implemented
by developers
As installed at
user's site
What the user
wanted

5
The Chaos Report

6
Module
Software Architecture:
Definitions

7
What is it about?
✔ As a maturing discipline with no clear rules on the
right way to build a system, designing software
architecture is still a mix of art and science.
– Djikstra
✔ Software-Architektur deals with abstraction,
decomposition and assembly, with style and
aesthetics
– Kruchten
Edsger Wybe Dijkstra
Phillipe Kruchten

8
✔ What do we mean by a software architecture?
To me the term architecture
➢ conveys a notion of the core elements of the system
➢ the pieces that are difficult to change
➢ a foundation on which the rest must be built.
More than 50 different definitions to be found at:
http://www.sei.cmu.edu/architecture/start/glossary/community.cfm
Martin Fowler

9
✔ The software architecture of a program or computing system is the
structure of the system, which comprise:
➢ software components,
➢ the externally visible properties of those components,
➢ and the relationships between them
✔ "Externally visible" properties are those assumptions other
elements can make of an element, such as
➢ its provided services,
➢ performance characteristics,
➢ fault handling,
➢ shared resource usage, and so on.