Bro110 5 1_software_architecture

Copyright by Brockhaus GmbH, alle Rechte reserviert, unautorisierte Vervielfältigung untersagt1

Session: Software Architecture

Software Architectures

The Software Architekt

The Architectural process

Some words on patterns


Welcome

in

An investment in knowledge always pays the best interest

--- Benjamin Franklin


Objectives

✔ Get a general idea about :

➢ What Software Architecture is about

➢ The role and the duties of a software architect

➢ The architectural process


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


The Chaos Report


Module

Software Architecture:Definitions


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



✔ 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


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.



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)"



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.




✔ in between design and realisationarchitecture bridges problem domain, subject matter experts and technical realisation

✔ based upon various decisionssome of them deal with the components, some of them deal with the technologies used

✔ the framework for flexible systemsconsidering external changes (organisational / technical)

✔ is abstractionsystematically omit information not needed keeps architecture clear.



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.


Stakeholders

.. in a System’s Architecture

✔ Architects

✔ Developers

✔ Testers

✔ Managers

✔ Customers

✔ Users

✔ Vendors


Module

Software Architect


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


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.


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.


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


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 thelong 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.


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


Software architects

Architects document

✔ Look out for templates, try arc42 (http://www.arc42.de/)

Architects communicate

✔ .. as mentioned before

http://www.arc42.de/

http://www.arc42.de/


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."


Module

Software Architect and software development


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.



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.



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.



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.


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 qualitiesin 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



… 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


Module

The Architectural Process


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



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.



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.



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



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 risksLack of time, budget, knowledge

✔ Performance… matters, no doubt about that

✔ Maintainability and flexibility… design for changes with respect to performance

✔ Availability



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.



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.

http://www.swenet.org/materials/127/quality%20attribute%20scenarios.doc


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.



✔ 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)



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

➢ ...



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


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


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.


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.


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.


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.


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.


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

http://de.wikipedia.org/wiki/Erich_Gamma

http://de.wikipedia.org/w/index.php?title=Richard_Helm&action=edit&redlink=1

http://de.wikipedia.org/wiki/Ralph_Johnson

http://de.wikipedia.org/wiki/John_Vlissides


http://de.wikipedia.org/wiki/Erich_Gamma

http://de.wikipedia.org/w/index.php?title=Richard_Helm&action=edit&redlink=1

http://de.wikipedia.org/wiki/Ralph_Johnson




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.


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.


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


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.




✔ 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.




✔ Implementation issues:

➢ Effects of language (i.e., Java vs. C++).

➢ Alternative tactical approaches.


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



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



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.



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



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.


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


Session: Software Architecture

Software Architectures

The Software Architekt

The Architectural process

Some words on patterns



Welcome

in

An investment in knowledge always pays the best interest

--- Benjamin Franklin



Objectives

✔ Get a general idea about :

➢ What Software Architecture is about

➢ The role and the duties of a software architect

➢ The architectural process



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



The Chaos Report



Module

Software Architecture:Definitions




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




✔ 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




✔ 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.




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)"




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.





✔ in between design and realisationarchitecture bridges problem domain, subject matter experts and technical realisation

✔ based upon various decisionssome of them deal with the components, some of them deal with the technologies used

✔ the framework for flexible systemsconsidering external changes (organisational / technical)

✔ is abstractionsystematically omit information not needed keeps architecture clear.




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.



Stakeholders

.. in a System’s Architecture

✔ Architects

✔ Developers

✔ Testers

✔ Managers

✔ Customers

✔ Users

✔ Vendors



Module

Software Architect



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



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.



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.



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



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 thelong 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.



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



Software architects

Architects document

✔ Look out for templates, try arc42 (http://www.arc42.de/)

Architects communicate

✔ .. as mentioned before



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."



Module

Software Architect and software development




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.




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.




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.




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.




… 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 qualitiesin 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




… 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



Module

The Architectural 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




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.




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.




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




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 risksLack of time, budget, knowledge

✔ Performance… matters, no doubt about that

✔ Maintainability and flexibility… design for changes with respect to performance

✔ Availability




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.




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.

www.swenet.org/materials/127/quality%20attribute%20scenarios.doc

● Availability is concerned with system failure and duration of system failures. System failure means … when the system does not provide the service for which it was intended.

● Modifiability is about the cost of change, both in time and money. ● Performance is about time. Events occur and the system must respond in a timely fashion.● Security is the ability of the system to prevent or resist unauthorized access while providing access to

legitimate users. An attack is an attempt to breach security.● Testability refers to the ease with which the software can be made to demonstrate its faults or lack

thereof. To be testable the system must control inputs and be able to observe outputs.● Usability is how easy it is for the user to accomplish tasks and what support the system provides for the

user to accomplish this. Dimensions:Learning system featuresUsing the system efficientlyMinimizing the impact of errorsAdapting the system to the user’s needsIncreasing confidence and satisfaction

From wikipedia:ISO/IEC 9126 Software engineering — Product quality is an international standard for the evaluation of software quality. The fundamental objective of this standard is to address some of the well known human biases that can adversely affect the delivery and perception of a software development project. These biases include changing priorities after the start of a project or not having any clear definitions of "success." By clarifying, then agreeing on the project priorities and subsequently converting abstract priorities (compliance) to measurable values (output data can be validated against schema X with zero intervention), ISO/IEC 9126 tries to develop a common understanding of the project's objectives and goals.




✔ 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.

http://www.softwarearchitectures.com/go/Discipline/DesigningArchitecture/QualityAttributes/tabid/64/Default.aspx




✔ 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)




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

➢ ...




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



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



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.



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.

Design Patterns describe simple but sophisticated solutions for specific problems arising in the process of designing object oriented applications; they describe solutions tested in practice. Design Patterns are no libraries, functions, they are language agnostic by definition; they could be used in any programming language like Java, Smalltalk, C++ or C#.

Definition (taken from wikipedia)

In software engineering, a design pattern is a general solution to a common problem in software design. A design pattern isn't a finished design that can be transformed directly into code, it is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the exact classes or objects that are involved.

Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. Reusing design patterns helps to prevent subtle issues that can cause major problems.

Often, people only understand how to apply certain software design techniques to certain problems. These techniques are difficult to apply to a broader range of problems. Design patterns provide general solutions, documented in a format that doesn't require specifics tied to a particular problem.

Patterns allow developers to communicate using well-known, well understood names for software interactions. Common design patterns can be improved over time, making them likely to perform better than ad-hoc designs.



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.



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.



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.



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



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.

● Architectural Pattern ● 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 Pattern

● provides 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.

● Idiom ● low-level pattern specific to a programming language. ● describes how to implement particular aspects of components or the relationships

between them using the features of the given language.



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.



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





✔ 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.





✔ 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.





✔ Implementation issues:

➢ Effects of language (i.e., Java vs. C++).

➢ Alternative tactical approaches.




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




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




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.




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




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.



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?

Education

Bro110 5 1_software_architecture