Upload
lucas-reed
View
215
Download
0
Tags:
Embed Size (px)
Citation preview
Software Architecture
Motivation, Qualities and Development Cycle
June 2001
Siegfried ReichSunTREC Salzburg
2
Overview
Envisioning Architecture: Motivation, Definition, Development Cycle
Creating and Analysing Architectures: Qualities and Architectural Styles
Developing Architectures: Unified Process (UP) and Phases
Discussion: Implications for REGNET
3
Motivation: The Vasa (Bass, 1998)
King Gustavus Adolphus was at war with Poland and ordered the biggest battleship ever to be built (the "Vasa").
The ship was built, sent off to Poland and fired her guns in salute on leaving Stockholm's harbour in August 1628. She rolled over and sank immediately.
Lessons learned: enterprise goals influence requirements which lead to an architecture which in turn leads to a system. The architecture is based on the architect's experience and the technical facilities of the time - and both were not up to the needs in the case of the Vasa.
goals architecture system
4
Definition of "Architecture"
Following Bass (Bass, 1998) a software architecture is the structure of the system which comprises its components, the externally visible properties of these
components and their relationships.
5
Why Architectures?
We need architectures in order to (Jacobson et al., 1999) understand the system organise the system's development foster re-use evolve the system
This can/will be part of thetechnology implementationplan (TIP)
6
Influences on the Architecture
Architects are influenced by Customers and end users Developing organisation Technical environment Their (i.e., the architects')
experience
Architecture development is not a linear process: the environment influences the architecture which in turn influences the environment ("Feedback Loop", Lehmann, 1995).
Requirements: these are almost never understoodcompletely, hence involvementof stakeholders at early stagesand reviews are essential.
7
The Architecture Cycle 1/2
The architecture affects the structure of the developing organisation (e.g., individual groups work on the components identified)
The architecture can affect the enterprise goals of the developing organisation (e.g., focus on certain markets)
The architecture can affect the customer requirements for the next iteration of their system
The process of developing that system will affect the architect's experience
Few systems may influence the software engineering culture (e.g., RDBMS, CORBA, the WWW)
8
The Architecture Cycle 2/2
Architect
Customers and end users
Developing organisation
Technical environment
Architect's experience
Requirements
architecture
system
REGNET Architecture Cycle
Content Group, EU
Technical Group
Architects ("us")
9
Steps to Develop a System
Identifying the business case(s) Understanding the requirements (e.g., with use
cases, prototype development, etc.) Creating or selecting the architecture Communicating the architecture (e.g., using
Architecture Definition Languages (ADL), Unified Modelling Language (UML), etc.)
Analysing and evaluating the architecture Implementing the architecture (including ensuring its
conformance with the specification)
10
Some Practical Guidelines
Architecture should be done by a single architect or small group
Have a list of requirements at hand Document the architecture using an agreed notation Review the architecture with your stakeholders Use well defined modules that encapsulate properties
that might be subject to change The modules should allow teams to separately work on
their implementation Never rely on a particular version of a tool or product Modules that produce data should be separate from
those that consume data. This tends to increase modifiability.
11
Module Structure, Uses Structure
Information hiding: Interfaces of modules only reveal those aspects that are unlikely to change: the implementation details remain hidden.
Simplicity: modules should be simple enough to be understood on their own.
Modularity: modules should be exchangeable without affecting other modules.
Dependencies: the uses structure (of a module's procedures) is important for the runtime behaviour and for checking implications of changes, e.g. procedure p1 of module m1 uses p2 in module m3 - does that imply that we need to change m3 just because we modify p1?
Layering: the uses structure thus affects the layering of the modules.
12
Introduction to Quality Attributes
Architectural qualities describe the characteristics of a system: systems are often re-designed not because they are functionally deficient but because they are hard to maintain, port or are too slow, etc.
Architectural qualities can never be achieved in isolation: portability for instance, will typically hurt performance.
Qualities are separated into system qualities, business qualities, and architectural qualities.
13
Qualities 1/4
System qualities discernible at runtime Performance (e.g., intercomponent communication,
parallelism, etc.) Security (e.g., secure kernels, authentication servers,
etc.) Availability (e.g., fault tolerance with redundant
components, etc.) Functionality (i.e., work for what the system was
intended for) Usability: further broken into learnability, efficiency,
memorability, error avoidance, error handling, etc.
14
Qualities 1/4 in REGNET
Performance (e.g., intercomponent communication, parallelism, etc.): response time for queries, scalability (data, clients), etc.
Security (e.g., secure kernels, authentication servers, etc.): secure transactions (B2C, B2B)
Availability (e.g., fault tolerance with redundant components, etc.): downtime in seconds, replication of components, etc.
Functionality (i.e., work for what the system was intended for): querying (quality vs. response time), shopping, autonomy
of regional services, individualisation, data entry, publishing
Usability: further broken into learnability, efficiency, memorability, error avoidance, error handling, etc.
15
Qualities 2/4
System qualities not discernible at runtime Modifiability (e.g., modularised and encapsulated
components, etc.) Portability (e.g., via portability layer, etc.) Reusability (e.g., loose coupling of components,
etc.) Integrability (e.g., consistent component
interfaces, allowance for incremental builds, etc.) Testability (e.g., modularised and encapsulated
components, incremental builds, etc.) These qualities will form the basis for metrics to be
used for evaluating the REGNET architecture.
16
Qualities 2/4 in REGNET
Modifiability (e.g., modularised and encapsulated components, etc.): which components do we plan to modify
Portability (e.g., via portability layer, etc.): what platforms/systems do we need to support?
Reusability (e.g., loose coupling of components, etc.): important for technology implementation plan (TIP)
Integrability (e.g., consistent component interfaces, allowance for incremental builds, etc.): which existing components and interfaces (standards) do
we need to integrate? Testability (e.g., modularised and encapsulated components,
incremental builds, etc.)
17
Qualities 3/4
Business qualities Time-to-market Costs of the development effort Projected life-time of the system which affects e.g.
modifiability, etc. Targeted market (mass market vs. specific market)
which may impact portability and/or security aspects.
Use of legacy systems which implies extensive integration facilities.
18
Qualities 4/4
Architectural qualities Conceptual integrity: have one ( few)
architect(s), one set of design ideas, etc. Correctness and completeness Buildability, i.e., can the system actually be built in
a timely manner
19
The Architecture Development Process
The technical architecting process
The organisational architecting process: leading,
communicating, consulting, etc.
Architecturalrequirements
Structuring(Analysis, Design)
Evaluation(Implementation,
Testing)
cycle n+1
rework
20
Unified Modeling Language
Standardised language to support ... ... phases of the software life cycle (SLC) ... communication between stakeholders ... documentation of the results achieved ... development of a broad range of tools
UML and the SLC Every diagram can be used in every phase! Use Cases focus on requirements Activity/State/Collaboration Diagrams focus
on analysis Class/Package diagrams focus on design and
implementation Use Cases Test
21
Workflows and Phases
CoreWorkflows
Phases
Requirements
Analysis
Design
Implementation
Test
Inception Elaboration Construction Transition
iter#1
iter#2
--- --- --- ---iter#n-1
iter#n
Use Case driven Architecture centric
An iteration in theelaboration phase
Phases of a system's cycle (Unified Process, UP)
CoreWorkflows
Requirements
Analysis
Design
Implementation
Test
22
Workflow - Requirements Capture
Candidate Requirements List requirements of stakeholders in a feature list
Understand system context If project complexity requires build a domain or
business model to understand/clarify the system context
Capture functional requirements In a use-case model
Capture non-functional requirements Supplementary requirements description
23
Summary and Conclusions for REGNET
Architectures are important for understanding systems and organising the developing of systems fostering re-use and evolving systems.
There is no process or method that guarantees a successful architecture (and subsequent system).
Have iterations!
24
References
Bass, L., Clements, P., and Kazman, R. Software Architecture in Practice. Addison-Wesley, 1998.
Bredemeyer, Software Architecting - How is Software Architecture Created? Available from http://www.bredemeyer.com/, 2001.
Jacobson, I., Booch G., and Rumbaugh, J. The Unified Software Development Process. Addison-Wesley, 1999.
Lehmann, M. Process Improvement - The Way Forward, keynote at CAiSE ’95, Jyväskylä, Finland, Springer Verlag, LNCS 932, 1995.
25
Architectural Styles
These are in some ways analogous to architectural styles in building, such as Roman, Gothic, etc.
Architectural styles consist of some key features and rules for combining them.
Architectural styles are determined by the component types (e.g., data repository,
process, etc.) a topological layout semantic constraints (e.g., a data repository may
not itself change the values stored in it, etc.) a set of connectors (e.g., procedure calls, sockets,
data streams, etc.)
26
Style 1: Data-centred Architectures
Integrability of data is key Coordination via data store Clients can be added easily (good scalability of clients) If clients execute as separate processes this is referred
to as client-server style
Shared Data
ClientClient Client
ClientClient Client
computational component
passive data component
27
Style 2: Data-flow Architectures
Reuse and modifiability are key System is seen as a series of transformations of data E.g., batch style or UNIX pipes Pro: eases maintenance, high reusability (of
independent components) Con: batch mentality makes interactive applications
difficult, ordering of components can be tricky, performance can be poor as input/output have to be simple, e.g., unstructured ASCII data, so each component has to do parsing.
Validate Sort ReportUpdateTape Tape Tape
Tape
Tape Page
passive data component
28
Style 3: Virtual Machine Architectures
Goal is to achieve portability Interpreters, e.g., Java, as examples Performance costs due to additional computation
Program Data
InterpretationEngine
Program Being Interpreted
Internal State
Program Instructions
Selected Instruction
Selected Data
UpdatesData
Output
Input
State Data
29
Style 4: Call-And-Return Architectures
Goals are modifiability and scalability E.g., main-subroutine architectures, remote
procedure call systems, object-oriented systems The main-subroutine architecture decomposes
programs into smaller pieces to help achieve modifiability.
Main
Sub 1 Sub 2 Sub 3
30
Call-And-Return Architectures cont.
The object-oriented style: access to objects' internal states via interfaces only ( achieve modifiability via encapsulation).
Object
Object
Object
31
Call-And-Return Architectures cont.
Layered systems: higher layer builds on functionality provided by the lower layer
Goals are modifiability and portability
User Interface
Useful System
Basic Utility
Core