introduction to software architecture - · pdf fileintroduction to software architecture ......
TRANSCRIPT
Introduction to Software
Architecture
Imed Hammouda
Chalmers | University of Gothenburg
Introduction to Software Architecture
Who am I?
• Associate Professor of Software Engineering, previously in Tampere, Finland
• Research interests
– Software Architecture, Open Source, Software Development
Methods and Tools, Variability Management
• Developing and supporting open software architectures
• Studying socio-technical dependencies in software development
• Software ecosystems
• Coordinates:
[email protected], [email protected]
• Room 416, floor 4, Jupiter building, Campus Lindholmen
• Phone +46 31 772 60 40
2
Introduction to Software Architecture
• What is software architecture?
• Architectural drivers
• Addressing architectural drivers
• Architectural views
• Stakeholders and concerns
• Example system
3
Introduction to Software Architecture
What is Software Architecture?
• Software Architecture is the global organization of a software system, including
– the division of software into subsystems/components,
– policies according to which these subsystems interact,
– the definition of their interfaces.
T. C. Lethbridge & R. Laganière
4
Introduction to Software Architecture
What is Software Architecture?
• "The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them."
5
Len Bass
Introduction to Software Architecture
What is Software Architecture?
• “fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.”
ISO/IEC/IEEE 42010
http://www.iso-architecture.org/ieee-1471/defining-architecture.html
6
Introduction to Software Architecture
Architectural Information Increases
• Add your own definition:http://www.sei.cmu.edu/architecture/start/glossary/community.cfm
7
Architecture is everythingeverythingeverythingeverything that a (group of)
person(sperson(sperson(sperson(s) needs to let a large teamteamteamteam successfully
develop a (family of) productsproductsproductsproducts
Rob van Ommering, Philips Natlab
Introduction to Software Architecture
Levels of Architecture*
8* Mowbray and Malveau
Macro-architecture Frameworks
Micro-architecture Design patternsObserver
update()
Subjectattach(Observer)detach(Observer)
notify()
ConcreteObserver
update()
ConcreteSubject
getState()
forall o in observers
o.update()
System architecture Subsystem
Enterprise architecture
Application architecture Application
Introduction to Software Architecture
Types of Architecture
9
Mobile System
Operating
SystemMessagingDisplay
Screenshape
Color capacity
Screensize
Keypad
Keypad
type
Camera
SymbianLinux
Connectivity
FaxSMS MMS Email BluetoothCable Infrared Internet
Web
S60 S80Simultaneous
Key press
No Simultaneous
Key press
Key press
type
Large Medium Small
Rationale:
”Large” for game applications
Composition Rule:
”Web” requires ”Internet”
Single Product
Product family
Introduction to Software Architecture
Increasing Amount of Software in
Systems
10
Introduction to Software Architecture
The Importance of Architecture
11
Requirements &
Architecting
Design
Implementation
Testing
Deployment
Operation
SW fault repair
costs
≥ 100x
1x
10% of the lifecycle determines
90% of the costs and risks
Introduction to Software Architecture
The Importance of Architecture
• “If a project has not achieved a system architecture, including its rationale, the project should not proceed to full-scale system development. Specifying the architecture as a deliverable enables its use throughout the development and maintenanceprocess”
12
Barry Boehm
Introduction to Software Architecture
The Importance of Architecture
• Software architecture:
– provides a communication among stakeholders
– captures early design decisions
– acts as a transferable abstraction of a system
– defines constraints on implementation
– dictates organizational structure
– inhibits or enables a system’s quality attributes
– is analyzable and a vehicle for predicting system qualities
– makes it easier to reason about and manage change
– helps in evolutionary prototyping
– enables more accurate cost and schedule estimates
13
Introduction to Software Architecture
What Drives Software Architecture?
• System requirements:
– Functional needs (what the system should do)
– Quality needs (properties that the system must possess such as
availability, performance, security,…
• Design constraints
– Development process
– Technical constraints
– Business constraints
– Contractual requirements
– Legal obligations
– Economic factors
14
Introduction to Software Architecture
What Drives Software Architecture?*
Plain Old Telephone System
• Feature:
– Call subscriber
• Architecture:
– Centralized hardware switch
• Good qualities:
– Works during power shortage
– Reliable
– Emergency calls get location
information
15
*George Fairbanks
Skype
• Feature:
– Call subscriber
• Architecture:
– Peer-to-peer software
• Good qualities:
– Scales without central
hardware changes
– Easy to add new features
– Easy deployment
Introduction to Software Architecture
Architectural Drivers
• Architectural drivers are the design forces that will influence the early design decisions the architects make
• Architectural drivers are not all of the requirements for a system, but they are an early attempt to identify and capture those requirements, that are most influential to the architect making early design decisions.
� architecturally significant requirements
Archietcts pay more attention to qualities that arrisefrom architecture choices
16
Introduction to Software Architecture
Functional Requirements
• Functional requirements specify what the software needs to do. They relate to the actions that the product must carry out in order to satisfy the fundamental reasons for its existence.
• Business Level: defines the objective/goal of the project and the measurable business benefits for doing it.
• User Level: user requirements are written from the user's point-of-view.
• System Level: defines what the system must do to process input and provide the desired output.
17
Introduction to Software Architecture
Functional Requirements
• MoSCoW Method:
– M - MUST: Describes a requirement that must be satisfied in the
final solution for the solution to be considered a success.
– S - SHOULD: Represents a high-priority item that should be
included in the solution if it is possible. This is often a critical
requirement but one which can be satisfied in other ways if strictly
necessary.
– C - COULD: Describes a requirement which is considered desirable
but not necessary. This will be included if time and resources
permit.
– W - WON'T: Represents a requirement that stakeholders have
agreed will not be implemented in a given release, but may be
considered for the future.
18
Introduction to Software Architecture
Functionality and Software Architecture
• It is the ability of the system or application to satisfy the purpose for which it was designed.
• It drives the initial decomposition of the system.
• It is the basis upon which all other quality attributes are specified.
• It is related to quality attributes like validity, correctness, interoperability, and security.
Functional requirements often get the most focus in a development project. But systems are often redesigned, not because of functional requirements.
19
Introduction to Software Architecture
Quality Attributes
• A quality attribute is a measurable or testable property of a system that is used to indicate how well the system satisfies the needs of its stakeholders.*
• A quality requirement is a specification of the acceptable values of a quality attribute that must be present in the system.
• Quality attributes should be:
– Not subjective
– In sufficient detail
– Of a value and context (e.g: 180 seconds)
20
*Bass Clements Kazman
Introduction to Software Architecture
Quality Attributes*
21
Attribute Description
Performance How fast does it respond or execute?
Availability Is it available when an where I need to use it?
Safety How well does it protect against damage?
Usability How easy it is for people to learn and use?
Interoperability How easily does it interconnect with other systems?
Integrity Does it protect against unauthorized access and data loss?
Installability How easy is it to correctly install the product?
Robustness How well does it respond to unexpected operating conditions?
Reliability How long does it run before experiencing a failure?
Recoverability How quickly can the user recover from a failure?
*EnfocusSolutions
Introduction to Software Architecture
Quality Attributes
22
Attribute Description
Recoverability How quickly can the user recover from a failure?
Efficiency How well does it utilize processor capacity, disk space,
memory, bandwidth, and other resources?
Flexibility How easily can it be updated with new functionality?
Maintainability How easy is it to correct defects or make changes?
Portability How easily can it be made to work on other platforms?
Reusability How easily can we use components in other systems?
Scalability How easily can I add more users, servers, or other
extensions?
Supportability How easy will it be support after installation?
Testability Can I verify that it eas implemented correctly?
Introduction to Software Architecture
ISO/IEC 25010:2011 Quality Model
23
Functional suitability
Functional completeness
Functional correctness
Functional appropriateness
Compatibility
Co-existence
Interoperability
Reliability
Maturity
Availability
Fault tolerance
Recoverability
Maintainability
Modularity
Reusability
Analysability
Modifiability
Testability
Performance efficiency
Time behaviour
Resource utilization
Capacity
Usability
Appropriateness recognizability
Learnability
Operability
User error protection
User interface aesthetics
Accessibility
Security
Confidentiality
Integrity
Non-repudiation
Accountability
Authenticity
Portability
Adaptability
Installability
Replaceability
Introduction to Software Architecture
ISO/IEC 25010:2011 Quality in Use
Characteristics
24
Effectiveness Efficiency
Satisfaction
Usefulness
Trust
Pleasure
Comfort
Freedom from risk
Economic risk mitigation
Health and safety risk mitigation
Environmental risk mitigation
Context coverage
Context completeness
Flexibility
Introduction to Software Architecture
Quality Attributes & Software Architecture
• Different architectural styles address different sets of quality attributes and to varying degrees
– Architecture decides range of quality possibilities
• The specification of quality attributes affects the architecturalstyle of the system
– Architectures are evaluated w.r.t quality attributes
• Not all quality attributes are addressed by the architectural design, e.g. some aspects of usability (e.g. layouts) and some aspects of performance (e.g. algorithms)
• Impossible to maximize all quality attributes at once
– Tradeoff: More of this � less of that
– Performance versus security
– Everything versus time-to-market (or cost)
25
Introduction to Software Architecture
Specifying Quality Requirements
• A Quality Attribute Scenario is a quality attribute specificrequirement.
– Stimulus – a condition that needs to be considered
– Source of stimulus (e.g., human, computer system, etc.)
– Environment - what are the conditions when the stimulus occurs?
– Artifact – what elements of the system are stimulated.
– Response – the activity undertaken after arrival of the stimulus.
– Response measure – when the response occurs it should be
measurable so that the requirement can be tested.
26
Introduction to Software Architecture
Specifying Quality Requirements
27
Reliability
Stimulus Database unresponsive/crash
Source of Stimulus System
Environment Runtime
Artifact Database
Response Detect the failure, inform the system, use redundant database server
Response Measure Degraded mode not to exceed 5 mins
Introduction to Software Architecture
Addressing Quality Attributes
• Quality attributes can be addressed through different (architectural) tactics:
– Architectural styles: for example pipes-and-filters, MVC,
blackboard, publish-subscribe,…
– Design patterns: for example Abstract Factory, Adapter,
Command, Observer,…
– Tactics: A design decision: for example encapsulate, limit access
– Converting quality requirement to functionality: for example
exception handling, logging
• Quality requirements can be distributed at the system level tothe subsystems or components that make up the system.
28
Introduction to Software Architecture
Example Architectural Style
29
Remote Interaction System
Pipes and Filters
Introduction to Software Architecture
Example Design Pattern
30
display
predict
Statistics
Observer
Introduction to Software Architecture
Example Architectural Tactics
31
Introduction to Software Architecture
Evaluating Quality Attributes
• Quality attributes can be evaluated through:
– Scenario-based evaluation: for example change scenarios for
assessing maintainability
– Simulation: for example Prototyping is a form of simulation where
a part of the architecture is implemented and executed in the actual
system context.
– Mathematical modeling: for example, checking for potential
deadlocks.
– Experience-based assessment: this is based on subjective
factors like intuition and expertise of software engineers.
32
Introduction to Software Architecture
Views
33
Introduction to Software Architecture
Views
• A view is a projection of a model showing a subset of itsdetails
– Think of a Master Model that has all the details of the system
(master model may not concretely exist)
– Views are projections of the master model
• A view is a representation of the whole system, as seen through the prism of specific concerns. A view consists of one or more models that represent it.
34
Requirements
Concern
Identifier
Business Logic Persistence
Security Logging[Laddad 2002]
Introduction to Software Architecture
Stakeholders and Concerns
• A stakeholder is any person with interest in the project. Example: customers, developers, maintainers, and management.
• A concern is any matter of interest in a software system
– Architectual (e.g. security) versus non-architectural (e.g. single
responsibilities)
– Reifiable (e.g. functional feature) versus non-reifiable (e.g. usabililty
attributes)
• Example Concern categories:
– Functional requirements
– Quality attributes
– Business issues
– User experience
35
Introduction to Software Architecture
Viewpoints/Viewtypes
• A viewpoint is a pattern or generalization of a view. The viewpoint defines the rules for the viewpoint.
• Viewpoints are selected according to the concerns of the stakeholders.
• A viewpoint repository or viewpoint library is a name for the set of viewpoints that an architect knows about and which she can use to find a suitable viewpoint suitable for her immediate needs and interests.
• Example frameworks: 4+1 View Model, SEI, Zachmann, SoniHofmeister Nord
36
Introduction to Software Architecture
’4 + 1’ View Model*
37
* Philippe Kruchten
Introduction to Software Architecture
’4 + 1’ View Model*
• Logical
– Focus: Functional requirements of the system.
– Contents: Class diagrams, Sequence diagrams, Layer diagrams.
• Development (implementation)
– Focus: Static organization of the software in its development environment
– Contents: Component diagram, Package diagrams.
• Process
– Focus: Runtime behavior of the system, such as the system processes and
communication, concurrency, performance and scalability.
– Contents: Activity diagrams.
• Physical (Deployment)
– Focus: System Engineer’s perspective, looking at the system topology,
deployment and communication.
– Contents: Deployment diagrams.
• Scenarios
– Focus: Use cases for illustrating and validating the architecture.
– Contents: Use case diagrams.
38
Introduction to Software Architecture
The ”Sad” Reality
39
Introduction to Software Architecture
Example System
• Solutions for Open Land Administration (SOLA) is a 3 year project to develop open source software that supports cadastreand registration functions in a typical land office.
• Plan is to Support the pilot customization and implementation of the software in Ghana, Nepal and Samoa.
• The project started in June 2010. Pilot customization has been done in the first quarter of 2012.
40
FLOSS SOLASolutions for Open Land Administration
http://www.flossola.org/
Introduction to Software Architecture
SOLA: Business Needs
41
Identifier Description
BN-1 Reduce processing times for applications for registration and cadastre changes
BN–2 Provide better access to land information and improved delivery of registration and cadastre related services
BN-3 Ensure an acceptable of quality is maintained with respect to
registration and cadastre transactions and the associated official
record of land, properties, rights, restrictions and rightholders(including ownership)
BN-4 Reduce the processing effort for the maintenance of the official
record of land, properties, rights, restrictions and rightholders and the cadastre
BN-5 Provide the means of monitoring and managing the processing of
applications for registration and cadastre changes (including performance reporting)
Introduction to Software Architecture
SOLA: Functional Requirements
• Case Management
• Spatial Capability (View & Spatial Editing)
• Rights Management
• Cadastre Management
• Business Rule Management
• Generate Certificates
• Access to Property & Cadastre Information
• Digital Archive
• Electronic Data Interchange
• Auditing & Logging
• System Administration
42
Introduction to Software Architecture
SOLA: Functional Requirements
43
Identifier Capability Feature Priority
1 – Neutral
10 - Vital
Traces To BN
FN-1 Display.
Service
Requirements
Client explains their situation and
Public Counter Officer determines the
relevant service (including transaction
type). Public Counter Officer enters
type of service and system presents a
checklist of supporting documents
required for the selected service with the option to print this out for the client
8 BN - 2
FN-2 Log.serviceEnquiry
When Public Counter Officer enters
type of service (in FN – 1
Display.service Requirement), system
logs a service enquiry for a particular
type of service has been made by the Public Counter Officer.
5 BN - 5
Introduction to Software Architecture
Quality Attributes for SOLA
• System Security
• System Performance
• Software Maintainability
• System Scalability
• Software Deployment
• Data Migration
• Low Power Environments
44
Introduction to Software Architecture
Quality Requirements for SOLA
45
Identifier Feature Description Priority
QL-1 The system will capable of supporting multiple languages and
compatible with Unicode 3.0+ and UTF-8 encoding.
10
QL-2 The system will support optimistic concurrency control for real time
transaction processing.
10
QL-3 The system will support a rules engine that will allow definition and maintenance of business rules.
6
General Quality Requirements
Introduction to Software Architecture
Quality Requirements for SOLA
46
Identifier Feature Description Priority
QL-35 The system will be capable of supporting peak user volumes up to
100 users
10
QL-36 The system will process and respond to login requests in less than 5
seconds 90% of the time when subjected to peak user volumes.
10
QL-37 The system will process and respond to general transactions in less
than 5 seconds 90% of the time when subjected to peak user
volumes.
10
QL-38 The system will process and response to process intensive
transactions in less than 8 seconds 90% of the time when subjected
to peak user volumes.
10
QL-39 The system will perform document generation in less than 30 seconds 90% of the time when subjected to peak user volumes.
10
Performance Requirements
Introduction to Software Architecture
Design Constraints for SOLA
• Open source
• Portability
• Low power environments
• Compatibility with national e-strategies (Ghana, Samoa, and Nepal)
47
Introduction to Software Architecture
Stakeholders for SOLA
• Software Development Team
• Citizens
• Land Administration Agencies
• Goverments
• Commercial Companies
• Open Source Communities
• Universities
• NGO’s
48
Introduction to Software Architecture
SOLA: Overview
49
Da
taP
rese
nta
tion
Other Clients
Customizations
SOLA Desktop
SO
LA
Se
rvic
es
Security
Au
ditin
gA
uth
en
ticationWeb Sites Other Clients
SOLA Database
Sch
em
a
EJB
Se
rvic
e
Other DBs
Sch
em
a
Sch
em
a
Sch
em
a
EJB EJB EJB EJB
Se
rvic
e
Se
rvic
e
Se
rvic
e
Se
rvic
e
Se
rvic
e
Se
rvic
e
Se
rvic
e
Au
tho
riza
tio
n
Introduction to Software Architecture
SOLA: Logical View
50
External Systems
+ Email Server
+ Print Server
+ Scanner
«layer»
Data Layer
+ ETL Tool
+ PostGIS Template
+ SOLA Database
«layer»
Serv ices Layer
+ Boundary
+ Services Common
+ EJBs
«layer»
Presentation Layer
+ Geotools UI
+ SOLA Desktop
+ SOLA GIS
Common
+ Help
+ Messaging
+ Rules
+ Util ities
Introduction to Software Architecture
SOLA: Logical View
51
«system»
SOLA Desktop
+ Beans
+ Cache
+ Configuration
+ Converters
+ Desktop
+ Forms
+ Localization
+ Renderers
+ Reports
+ Resources
+ Tasks
+ Uti li ties
Geotools UI
+ Data
+ Layers
+ Map Actions
+ Map Tools
+ UI
SOLA GIS
+ Data
+ GIS
+ Layers
+ Map Actions
+ Tools
+ UI
Messaging
+ Localized Message
+ Message Util ity
+ Client Message Bundle
+ GIS Message Bundle
+ Server Message Bundle
(from Common)
Help
+ Help Uti li ty
+ Default Helpset
(from Common)
Web Serv ice Clients
+ Administration Client Impl
+ Case Management Client Impl
+ Digital Archive Client Impl
+ Reference Data Client Impl
+ Search Client Impl
+ Security Client Impl
+ Spatial Client Impl
+ WS Client Factory
+ Administration Client
+ Case Management Client
+ Digital Archive Client
+ Reference Data Client
+ Search Client
+ Security Client
+ Spatial Client
+ Generated Sources
+ Security Configuration
(from Boundary)
Utilities
+ Date Uti li ty
+ File Uti l ity
+ Log Uti l ity
(from Common)
Introduction to Software Architecture
SOLA: Process View
52
Introduction to Software Architecture
SOLA: Physical View
53
Application Serv erDB Serv er
Desktop PC (SOLA User)PostgreSQL 9.0
SOLA Database
PostGIS
Glassfish 3.1.1 / Metro
SOLA Services EAR
Jav a 7 (JDK)
SOLA Desktop
Jav a 7 Web Start (JRE)
SOLA Desktop Web Start
Internet Zone
JDBCHTTP
HTTP / JNLP
Introduction to Software Architecture
SOLA: Scenarios View
54
UC01 Serv ice
Enquiry
UC03 Lodge
Application
UC04 Rev iew Quality
UC05 Register or
Approv e
UC06 Ceate New
Property
Land Office Client
Public Counter Officer
Notification Serv iceQuality Rev iewer
Registrar or Approv ing
Officer
Land Officer Specialist
Archiv ist
Architecturally Significant Use Cases
Introduction to Software Architecture
SOLA: Scenarios View
55
Search Results
Screen
Public Counter Officer Search Criteria
Screen
Subsystem
Control ler
Search and EDI
Service
SOLA DatabaseSearch Service
Agent
Case Management
Service
Case Management
Service Agent[Enter criteria and click
Search]:Search(Criteria) :
SearchResults
Search(Criteria) :SearchResultsTranslate(Criteria)
:CriteriaDTO
Search(CriteriaDTO) :SearchResultsDTOTranslate(CriteriaDTO) :
Criteria
Search(Criteria) :Results
Translate(Results) :
ResultsDTO
Translate(SearchResultsDTO) :
SearchResultsDisplay(SerachResults)
[Select Result]:
Get(ResultId) :ResultDetailGet(ResultId) :ResultDetailDTO
Get(ResultId) :ResultDetail
Translate(ResultDetail) :
ResultDetailDTO
Translate(ResultDetailDTO) :
ResultDetail
Display(ResultDetail)
Introduction to Software Architecture
SOLA: Data View
56
SOLA Database
+ Address
+ Administrative
+ Application
+ Cadastre
+ Document
+ Extra Spatial Functions
+ Party
+ Source
+ System
(from Data Model)
SOLA Database Schemas
Introduction to Software Architecture
SOLA: Security View
57
Glassfish / Metro
SOLA Desktop SOLA Database
Log4J Serv er Log
Log4J Desktop Log
SOLA Serv ices
+ Administrative
+ Case Management
+ Cadastre
+ Document Archive
+ Reference Data
+ Search
+ Security
+ Spatial
Server Certificate
(Public)
Server Certificate
(Private)
Database User Credentails,
No Transport SecurityUser Credentials,
Message Security
Exceptions &
Faults
No Credentials, No
Transport Security
DB Exceptions
DB Audit
Exceptions
Service Faults
SOLA Security Model
Introduction to Software Architecture
Wrap-up: IEEE-Std-1471 Conceptual Framework
58
Rationale
Architectural Description
Model
View
Concern
Architecture System
Environment Mission
Viewpoint
LibraryViewpoint
Stakeholder
provides
1..*aggregates
participates in
consists of
participates in
1..*
1..*organized by
establishes methods for
described by
selects1..*
used to cover1..*identifies
1..*
has is important to
1..*
1..*
identifies 1..*
1..*
has
conforms to1..* has source
has an
1..*fulfillsinhabits
influences
1..*
is addressed to
Introduction to Software Architecture
Wrap-up
• Architecture should be the product of a single architect or a small group of architects with an identified leader.
• Architect team should have functional requirements for the system and an articulated prioritized list of quality attributes that the architecture is expected to satisfy.
• Architecture should be well documented, and circulated and reviewed by system stakeholders.
• Architecture should be analyzed for applicable quantitative measures and formally evaluated for quality attributes before it is too late to make changes to it.
• Architecture should lend itself to incremental refinement and implementation.
59
Introduction to Software Architecture 60
Tack så mycket!
Frågor?