View
3
Download
0
Category
Preview:
Citation preview
Chalmers University of Technology
#1 Jörgen Hansson, 2010 DAT 220/DIT 542
Advanced Software Architecture���
Lecture #1 - Introduction
Professor Jörgen Hansson Department of Computer Science and Engineering
Chalmers University of Technology jorgen.hansson@chalmers.se
Chalmers University of Technology
#2 Jörgen Hansson, 2010 DAT 220/DIT 542
Introductions
• Who am I?
• Who are you?
• Why are you here?
Course Introduction
Chalmers University of Technology
#3 Jörgen Hansson, 2010 DAT 220/DIT 542
Who is this lecturer anyway?
Work Experience 2010 - Professor at Chalmers in the area of software engineering 2005-2010 Senior Member of Technical Staff ��� Software Engineering Institute, Carnegie Mellon Univ., USA
– Focus on architectural descriptions and validation using the industry standard AADL, which was created by the SEI.
2000-2007 Professor at Linköping University in the area of real-time systems
– Focus on management of real-time data in embedded real-time systems, including QoS/QoD, real-time component models, database systems
Chalmers University of Technology
#4 Jörgen Hansson, 2010 DAT 220/DIT 542
Who is this lecturer anyway?
Domain experience: • Governmental experience: Dept of Defense (DoD), Dept of Energy
(DoE), Dept of Interior (DoI), Veterans Administration (VA), National Security Agency (NSA), U.S. Nuclear Regulatory Commission (NRC)
Industrial experience: • Aviation: AVSI, including Boeing, Airbus, BAE, Rockwell-Collins • Automotive: Toyota Research (Tokyo), Volvo CE, Saab Automobile,
Fiat/GM powertrain, Mecel
Other: • Worked as a consultant and advisor in the areas of embedded real-time
systems, networked systems, and software engineering • Started a spin-off company in the area of real-time data management
Chalmers University of Technology
#5 Jörgen Hansson, 2010 DAT 220/DIT 542
Rules of Engagement
• To complete everything and get the most from the course, ���we will need to follow some rules of engagement:
– Your participation is essential. – Feel free to ask questions at any time. – Discussion is good, but we might need to cut some discussions short in the
interest of time. – Please try to limit side discussions during the lectures. – Please turn off your cell phone ringers and computers. – Let’s try to start on time.
Course Introduction
Chalmers University of Technology
#6 Jörgen Hansson, 2010 DAT 220/DIT 542
Course Objective
We will in this course focus our attention on • principles and methods that aid the designer/developer/architect to gain
increased confidence in the architectural design • quantitative modeling using architecture description languages such as
AADL and MARTE, and • qualitative architecture evaluation methods, e.g., ATAM • specific challenges related to scale, dynamics, and heterogeneity as
found in system of systems, and ultra-large scale systems.
Chalmers University of Technology
#7 Jörgen Hansson, 2010 DAT 220/DIT 542
Learning Objectives After successfully completing the course, the student should be able to: • Understand the role and applicability of methods for evaluating architectures • Describe inter-dependencies among quality-attributes and understand how they
affect architecting • Develop an ability to assess an architecture quantitatively and qualitatively • Understand architectural models using ADLs, and understand the intentionality
of models throughout the system life-cycle • Understand incremental and multi-fidelity architecture-centric verification and
validation • Understand the characteristics and challenges of architecting system-of-
systems and ultra-large-scale systems • Distinguish between software architecture, system architecture, and run-time
architectures
Chalmers University of Technology
#8 Jörgen Hansson, 2010 DAT 220/DIT 542
Course Content Prerequisites: Same as for the Master Programme in Software Engineering and
Technology.
Organization: Lectures, seminars and projects. Each student shall write an essay, give a seminar, and participate in other seminars.
Literature: Research papers and provided material; see course web page
Examination: A written exam at the end of course. The project/essay must also be approved, and presented at a seminar. Attendance at other students’ presentations.
Exam grades U, 3, 4, or 5; alternatively G or VG ���Essay/project grades: U or G (Pass or Fail)
Final grade: Determined by exam grade; pass in essay/project is required
Chalmers University of Technology
#9 Jörgen Hansson, 2010 DAT 220/DIT 542
Course Topics
• Introduction; Role of architecture; Case study from Avionics • Quality Attributes; Architectural Assessment; • Assurance cases • Overview of ADLs; AADL • OMG MARTE • Evolution and variability • Systems engineering via OMG SysML • Partitioned and layered architectures, e.g., ARINC 653, Separation
Kernels • Ultra-large scale systems - challenges for the future
Chalmers University of Technology
#10 Jörgen Hansson, 2010 DAT 220/DIT 542
Schedule
• Lectures and Seminar on (but weekly schedule differs) – Tuesdays 13:15 – 15:00 – Fridays 10:00-11:45
• Specific schedule can be found on course web page or in TimeEdit (here)
Chalmers University of Technology
#11 Jörgen Hansson, 2010 DAT 220/DIT 542
Seminar/Essay/Project
Alternative 1 (default): Each student is involved in writing an essay/report reviewing the state-of-the-art on an approved topic (you can choose topics and identify critical references; I will also provide proposed topics and starting points). Each essay will be presented in a seminar to the rest of the class.
Two students/report.
Alternative 2: Each student reviews some articles (1-4 articles in the same area; one article will be the main article; articles are provided by me), develops a presentation (guidelines will be given), and presents the material to the class (30 minutes + 15 min of discussion). All students in class reads the main article.
Two students per review and presentation.
Chalmers University of Technology
#12 Jörgen Hansson, 2010 DAT 220/DIT 542
Let us get the show on the road…
Chalmers University of Technology
#13 Jörgen Hansson, 2010 DAT 220/DIT 542
What are the problems? ���
And what do they have to do with architecture?
Chalmers University of Technology
#14 Jörgen Hansson, 2010 DAT 220/DIT 542
Late Discovery of System Problems • Mismatched assumptions
• Units, range, delta, base value (Ariane)
• False promises of time partitioning • DMA impact across partitions (JSF)
• Unmanaged resource sharing • Overload of device bus (Daimler)
• Unexpected Latency variation • Unexpected latency jitter (F16)
• Trusting scheduling analysis • Detection of priority inversion (Mars Rover)
Chalmers University of Technology
#15 Jörgen Hansson, 2010 DAT 220/DIT 542
System Level Fault Root Causes Violation of data stream assumptions
– Stream miss rates, mismatched data representation, latency jitter & age Partitions as Isolation Regions
– Space, time, and bandwidth partitioning – Isolation not guaranteed due to undocumented resource sharing – Fault containment, security levels, safety levels, distribution
Virtualization of time & resources – Logical vs. physical redundancy – Time stamping of data & asynchronous systems
• Inconsistent System States & Interactions – Modal systems with modal components – Concurrency & redundancy management – Application level interaction protocols
Chalmers University of Technology
#16 Jörgen Hansson, 2010 DAT 220/DIT 542
Observations and Facts • Systems outlive their anticipated life expectancy • Costly faults due to mismatch of assumptions between components and systems • Tiny proportion of failures due to bugs * • Largest proportion due to eliciting, recording, and analysis of requirements* • Scientific evaluation of software failures hard due to lack of reliable data* • Certification regimes and standards reliance on testing, not enough for high
dependability* • Result:
– system integration – high risk; evolvability – very expensive – life cycle support – very expensive; leads to rapidly outdated components
* Software for Dependable Systems: Sufficient Evidence? By Daniel Jackson et al.
Chalmers University of Technology
#17 Jörgen Hansson, 2010 DAT 220/DIT 542
5x
Software Architectural
Design
System Design
Component Software Design
Code Development
Unit Test
System Test
Integration Test
Acceptance Test
Requirements Engineering
30x
Source: NIST Planning report 02-3, “The Economic Impacts of Inadequate Infrastructure for Software Testing”, May 2002.
Where are faults introduced? Where are faults found?
What is the estimated nominal cost for fault
removal? 20.5%
1x
20%, 16%
10%, 50.5%
0%, 9% 15x
70%, 3.5%
10x
20x
1x
Chalmers University of Technology
#18 Jörgen Hansson, 2010 DAT 220/DIT 542
Defect Economics
Phase Defects
originating in phase (%)
Relative defect removal cost ���of each phase of origin
Req’s Design Unit test Integration Documentation
Requirements 15% 1
Design 35% 2.5 1
Unit coding 30% 6.5 2.5 1
Integration 10% 16 6.4 2.5 1
Documentation 10% 1
System/Accep-tance test - 40 16 6.2 2.5 2.5
Operation N/A 110 44 17 6.9 6.8
Source: D. Galin, “Software Quality Assurance: From Theory to Implementation”, Pearson/Addison-Wesley (2004) & ���B.W. Boehm, “Software Engineering Economics”, Prentice Hall (1981)
Chalmers University of Technology
#19 Jörgen Hansson, 2010 DAT 220/DIT 542
0.0x
200.0x
400.0x
600.0x
800.0x
1000.0x
1200.0x
1400.0x
Req.eng -‐ arch design Code dev. & unit test Integra>on & system test Acceptance test User Tradi>onal approach Improved scenario 1 Improved scenario 2 Improved scenario 3
• Req – Arch design phase: 45.5 (of 70) faults introduced are detected (change from 3.5) • Integration phase: Reduction in detection from 50.5 faults to 20 faults • Number of faults detected by user is decreased from 20 to 10 faults
Reduction of faults in code development from 20 to 2 faults.
• Req – Arch design phase: 60 (of 70) of faults introduced are detected (change from 45.5) • Integration phase: Reduction in detection from 50.5 to 10 (change from 20) • Acceptance test: Reduction in detection from 9 faults to 4.5 faults • Number of faults detected by user is further decreased from 20 to 5 (change from 10)
Number of faults: 100���Fault removal cost: x$ for one fault introduced in the same phase y-axis represents cumulative cost over the phases
46.8% reduction
50.3% reduction
71.8% reduction
Chalmers University of Technology
#20 Jörgen Hansson, 2010 DAT 220/DIT 542
Traditional Embedded System Engineering
System Engineer Control Engineer
System
Under
Control
Control
System
Chalmers University of Technology
#21 Jörgen Hansson, 2010 DAT 220/DIT 542
Software-Intensive Embedded Systems
System Engineer Control Engineer
Application D
eveloper Har
dwar
e En
gine
er
System
Under
Control
Control
System
Compute
Platform
Runtime
Architecture
Application
Software
Embedded SW System Engineer
Chalmers University of Technology
#22 Jörgen Hansson, 2010 DAT 220/DIT 542
Mismatched Assumptions
System Engineer Control Engineer
Application D
eveloper H
ardw
are
Engi
neer
System Under Control
Control System
Compute Platform
Runtime Architecture
Application Software
Embedded SW System Engineer
Physical Plant Characteristics
Data Stream Characteristics
Precision Units
Concurrency Communication
Distribution Redundancy
Why do system level failures still occur despite fault tolerance techniques being deployed in systems?
Chalmers University of Technology
#23 Jörgen Hansson, 2010 DAT 220/DIT 542 23
Mismatched Assumptions
System Engineer Control Engineer
Application D
eveloper Har
dwar
e En
gine
er
System���Under ���Control
Control���System
Compute���Platform
Runtime���Architecture
Application ���Software
Embedded SW System Engineer
Physical Plant Characteristics
Data Stream Characteristics
Precision Units
Concurrency Communication Distribution
Redundancy
Chalmers University of Technology
#24 Jörgen Hansson, 2010 DAT 220/DIT 542
Performance Improvement Gone Bad
• Ground station to accommodate sensor load growth – Reduce load in network – Two subsystems communicate state change instead of state
• The impact – Other subsystems increase network load sporadically – Receiving subsystem goes down
• The cause – Transmission protocol without guaranteed delivery – Overload result in dropping of transmitted state deltas – Missing deltas result in inconsistent receiver state
A real customer experience
Chalmers University of Technology
#25 Jörgen Hansson, 2010 DAT 220/DIT 542
Avoiding Future Mistakes
• Relevant characteristics as properties
– State vs. state-change communication through ports
– Bus protocols with or without guaranteed delivery
• Annotating the model
– Application engineer characterizes data stream
– Embedded system engineer characterizes hardware & protocols
• The analysis tool
– Check that connections carrying state changes are bound to buses with guaranteed delivery
Chalmers University of Technology
#26 Jörgen Hansson, 2010 DAT 220/DIT 542
Embedded Software System
Software & System Engineering
ADL
Embedded Software System Engineering
System Engineering
Physical System Model
SysML
Physical Component
Computing Platform
Embedded Software
Application Domain
Operational System
Physical characteristics relevant to embedded application as properties in AADL model
Chalmers University of Technology
#27 Jörgen Hansson, 2010 DAT 220/DIT 542
About Time to Discuss What an Architecture is…
Chalmers University of Technology
#28 Jörgen Hansson, 2010 DAT 220/DIT 542
Hot topic: Is architecture more than “structure”?
“Structuralists": No. • Structure is the key issue for architecture– Most ‘software
architecture’ approaches focus solely on structure
“Contextualists”: Yes. • Structure is “design”; fitness for use is the key issue – Architecture
should be different from Top-Level Design But ...Structure of what?
Chalmers University of Technology
#29 Jörgen Hansson, 2010 DAT 220/DIT 542
No Lack of Attempts to Define “Architecture”
INCOSE SAWG – Systems Architecture: Fundamental and unifying system structure defined in terms of system elements, interfaces, processes, constraints and behaviors
IEEE 610.12 – Architecture: organizational structure of a system or component. Architecture is the highest-level concept of a system in its environment
Rechtin & Maier – Systems Architecting is that part of systems engineering most concerned with purpose determination, concept formulation, and certification for use
Perry & Garlan – The structure of the components of a system, their interrelationships, and principles and guidelines governing their design and evolution over time
And if that is not enough, see http://www.sei.cmu.edu/architecture/start/community.cfm
Chalmers University of Technology
#30 Jörgen Hansson, 2010 DAT 220/DIT 542
Definition of a 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 between them.
The term also refers to documentation of a system's software architecture. Documenting software architecture facilitates communication between stakeholders, documents early decisions about high-level design, and allows reuse of design components and patterns between projects.
Bass, Len; Paul Clements, Rick Kazman (2003). Software Architecture In Practice, Second Edition. Boston: Addison-Wesley. pp. 21–24. ISBN 0-321-15495-9.
Chalmers University of Technology
#31 Jörgen Hansson, 2010 DAT 220/DIT 542
Definition of a Architecture
• Many views and opinions, e.g., – http://www.sei.cmu.edu/architecture/start/community.cfm
Chalmers University of Technology
#32 Jörgen Hansson, 2010 DAT 220/DIT 542
IEEE 1471
• http://www.iso-architecture.org/ieee-1471/
Chalmers University of Technology
#33 Jörgen Hansson, 2010 DAT 220/DIT 542
Implications of Previous Definition
• Architecture defines software elements, embodying information how elements relate to each other (and omits certain information not pertaining to their interaction, e.g., internal implementation), i.e., it is an abstraction
• Systems can and do comprise more than one structure, and no one structure can irrefutably claim to be the architecture
• Every computing system with software has a software architecture • Behavior of each element is part of the architecture insofar as that the
behavior can be observed or discerned from the point of view of another element.
• Definition is indifferent to whether the architecture for a system is a good one or a bad one. There are only architectures allowing or preventing the system from meeting its behavioral, performance, and life-cycle requirements
Chalmers University of Technology
#34 Jörgen Hansson, 2010 DAT 220/DIT 542
Is it important to have an 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 maintenance process”
- Barry Boehm, 1995
Chalmers University of Technology
#35 Jörgen Hansson, 2010 DAT 220/DIT 542
Architectural Patterns • Blackboard • Client-server (2-tier, n-tier, peer-to-
peer, Cloud Computing all use this model)
• Database-centric architecture (broad division can be made for programs which have database at its center and applications which don't have to rely on databases, E.g. desktop application programs, utility programs etc.)
• Distributed computing • Event Driven Architecture • Front-end and back-end • Implicit invocation • Monolithic application
• Peer-to-peer • Pipes and filters • Plugin • Representational State Transfer • Rule evaluation • Search-oriented architecture (A
pure SOA implements a service for every data access point)
• Service-oriented architecture • Shared nothing architecture • Software componentry (strictly
module-based, usually object-oriented programming within modules, slightly less monolithic)
• Space based architecture • Structured (module-based but
usually monolithic within modules) • Three-tier model (An architecture
Chalmers University of Technology
#36 Jörgen Hansson, 2010 DAT 220/DIT 542
Why is an Architecture Important��� The Technical Perspective
• Communication among stakeholders – Software architecture represents a common abstraction of a system that
most if no all of the system’s stakeholders can use as a basis for mutual understanding, negotiation, consensus, and communication
• Early design decisions – Software architecture manifests the earliest design decisions about a
system, and these early bindings carry weigh far out of proportion to their individual gravity with respect to the system’s remaining development, its deployment, and its maintenance life.
• Transferable abstraction of a system – Software architecture constitutes a relatively small, intellectually
graspable model for how a system is structured and how its elements work together.
– The model is transferable across systems, e.g., it can be applied to other systems exhibiting similar quality attribute and functional requirements, thus promoting large-scale reuse.
Chalmers University of Technology
#37 Jörgen Hansson, 2010 DAT 220/DIT 542
Architecture Manifests Earliest Set of Design Decisions
Architecture • 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
Chalmers University of Technology
#38 Jörgen Hansson, 2010 DAT 220/DIT 542
Architecture Stakeholders
• An architecture is the result of business and technical decisions among stakeholders
• Architectures are influenced by – System stake holders include: Customer, end users, project manager,
maintainers, system owners, marketers (e.g., think of cloud, iPhone, SOA, WWW, etc)
– Developing organization – Background and experience of architects – Technical environment (e.g., WWW, Middleware, SOA)
Chalmers University of Technology
#39 Jörgen Hansson, 2010 DAT 220/DIT 542
Software Processes and Architecture Business Cycle
• Creating the business case for the system • Understanding the requirements • Creating or selecting the architecture • Documenting and communicating the architecture • Analyzing or evaluating the architecture • Implementing the system based on the architecture • Ensuring that the implementation conforms to the architecture
Chalmers University of Technology
#40 Jörgen Hansson, 2010 DAT 220/DIT 542
What makes a “good” architecture
• An architecture is not inherently good or bad. • An architecture is only more (or less) fit for a stated purpose. • The architecture should enable the system to meet its intended mission
and business goals and technical requirements – It follows that there are might be multiple designs
Chalmers University of Technology
#41 Jörgen Hansson, 2010 DAT 220/DIT 542
Process recommendations
• 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
Chalmers University of Technology
#42 Jörgen Hansson, 2010 DAT 220/DIT 542
A Current Real-World Scenario
Chalmers University of Technology
#43 Jörgen Hansson, 2010 DAT 220/DIT 542 43
Does Model-Based Development Scale?
Systems Developed Using MBD
• Flight Control
• Auto Pilot
• Flight Warning
• Cockpit Display
• Fuel Management
• Landing Gear
• Braking
• Steering
• Anti-Icing
• Electrical Load Management
Airbus A380 Length 239 ft 6 in Wingspan 261 ft 10 in Maximum Takeoff Weight 1,235,000 lbs Passengers Up to 840 Range 9,383 miles
Chalmers University of Technology
#44 Jörgen Hansson, 2010 DAT 220/DIT 542
Chalmers University of Technology
#45 Jörgen Hansson, 2010 DAT 220/DIT 542
System and Software Integration Verification
Texas Engineering Experiment Station
Chalmers University of Technology
#46 Jörgen Hansson, 2010 DAT 220/DIT 542
Project Overview
• Overall Concept of Operations – Design and production based on early and continuous integration
(virtual => physical) – Integrate, then build
• Objective – Shift architecting, design, and production activities to explicitly
address integration issues early, reducing program execution risks, cycle time and cost
• Approach – Adopt/develop “integration-based” software and system
development processes with emphasis on integrating component-based, model-based and proof-based development
Version
Chalmers University of Technology
#47 Jörgen Hansson, 2010 DAT 220/DIT 542
Participants
– Active – BAE, Boeing, DoD (Army, Navy), FAA, GE Aerospace (Smiths), Honeywell, Lockheed Martin, Rockwell Collins, Airbus, Dassault-Aviation, JPL/NASA
– General Dynamics, Raytheon, Thales – Software Engineering Institute, Carnegie Mellon
Version
Chalmers University of Technology
#48 Jörgen Hansson, 2010 DAT 220/DIT 542
Expanded Objectives • Integrate system, software, and hardware integration models in one framework
– Support component-based system assurance through analysis of functionality, performance, safety and security
– Increase the degree of standardization and commonality for technical data exchanged between airframers, suppliers, and regulatory authorities
• Integrate – then build – Predict system behavior through analysis to ensure it is acceptable – Build to the requirements determined through the analysis
• Reduce the cost of developing avionic systems
– Maintain or improve existing levels of safety and security
• Start with the aerospace industry – Leverage capabilities developed in related domains – Coordinate with related domains when advantageous
• Foster U.S. Government and Aerospace industry Cooperation – Complement the large, government/industry funded European R&D efforts
Version August 7, 2007
Chalmers University of Technology
#49 Jörgen Hansson, 2010 DAT 220/DIT 542
Single Information and Relationships Repository • Integrate information and
relationships in a single repository with a “model bus”
Better requirements Better integration Better communication Better consistency
Chalmers University of Technology
#50 Jörgen Hansson, 2010 DAT 220/DIT 542
Overview of Multi-Aspect Model Repository & Model Bus
Version
Model Repository
MatLab
Esterel
TOPCASED
SCADE
SimuLink
Eclipse
Rhapsody
DOORS
OSATE
?
AADL
SysML
Requirements
Design
Verification
Integration/Deployment
Chalmers University of Technology
#51 Jörgen Hansson, 2010 DAT 220/DIT 542
Modified Business Model • System Integrator defines a new product using internal repository of virtual “parts” • Specifications for virtual subcomponents sent to suppliers
Chalmers University of Technology
#52 Jörgen Hansson, 2010 DAT 220/DIT 542
Modified Business Model (continued) • Virtual parts returned for virtual integration into a virtual product
– Cost savings realized by finding problems early on virtual parts • Once the virtual product is satisfactory, the actual product is developed
– Cycle-time reduction realized since re-work on physical parts virtually eliminated
Chalmers University of Technology
#53 Jörgen Hansson, 2010 DAT 220/DIT 542
Model-Based Engineering Benefits
• Benefits of modeling and architecture standards
Analyzable models drive development Prediction of runtime characteristics at different fidelity Bridge between control & software engineer Prediction early and throughout lifecycle Reduced integration & maintenance effort
Common modeling notation across organizations Single architecture model augmented with properties Interchange & integration of architecture models Tool interoperability & integrated engineering environments
Chalmers University of Technology
#54 Jörgen Hansson, 2010 DAT 220/DIT 542
Software Architectural
Design
System Design
Component Software Design
Code Development
Unit Test
System Test
Integration Test
Acceptance Test
Top-Level Verification Items
High-level ADL Model
Detailed ADL Model
Specify Model- Code Interfaces
Low fidelity
Adequate confidence
High fidelity
Strong confidence
Requirements Engineering
Virtual System Integration
Predictive Architecting
→ generation of test cases ← updating models with actual data
Chalmers University of Technology
#55 Jörgen Hansson, 2010 DAT 220/DIT 542
Summary
• Course goals, content, examination • Real-world scenarios and challenges • Discussion on what constitutes a software architecture and its role
Recommended