Overviews of Software Engineering and Embedded Software

1
Overviews ofSoftware Engineering and Embedded
Software

• CSCI 589
• Software Engineering for Embedded Systems

2
Engineering

• Engineering is
• The application of scientific principles and
  methods
• To the construction of useful structures
  machines
• Examples
• Mechanical engineering
• Civil engineering
• Chemical engineering
• Electrical engineering
• Nuclear engineering
• Aeronautical engineering

3
Software Engineering

• The term is 35 years old NATO Conferences
• Garmisch, Germany, October 7-11, 1968
• Rome, Italy, October 27-31, 1969
• The reality is finally beginning to arrive
• Computer science as the scientific basis
• Other scientific bases?
• Many aspects have been made systematic
• Methods/methodologies/techniques
• Languages
• Tools
• Processes

4
Software Engineering in a Nutshell

• Development of software systems whose
  size/complexity warrants team(s) of engineers
• multi-person construction of multi-version
  software Parnas 1987
• Scope
• study of software process, development
  principles, techniques, and notations
• Goal
• production of quality software, delivered on
  time, within budget, satisfying customers
  requirements and users needs

5
Ever-Present Difficulties

• Few guiding scientific principles
• Few universally applicable methods
• As muchmanagerial / psychological /
  sociologicalas technological

6
Why These Difficulties?

• SE is a unique brand of engineering
• Software is malleable
• Software construction is human-intensive
• Software is intangible
• Software problems are unprecedentedly complex
• Software directly depends upon the hardware
• It is at the top of the system engineering food
  chain
• Software solutions require unusual rigor
• Software has discontinuous operational nature

7
Software Engineering ? Software Programming

• Software programming
• Single developer
• Toy applications
• Short lifespan
• Single or few stakeholders
• Architect Developer Manager Tester
  Customer User
• One-of-a-kind systems
• Built from scratch
• Minimal maintenance

8
Software Engineering ? Software Programming

• Software engineering
• Teams of developers with multiple roles
• Complex systems
• Indefinite lifespan
• Numerous stakeholders
• Architect ? Developer ? Manager ? Tester ?
  Customer ? User
• System families
• Reuse to amortize costs
• Maintenance accounts for over 60 of overall
  development costs

9
Economic and Management Aspects of SE

• Software production development maintenance
  (evolution)
• Maintenance costs gt 60 of all development costs
• 20 corrective
• 30 adaptive
• 50 perfective
• Quicker development is not always preferable
• higher up-front costs may defray downstream costs
• poorly designed/implemented software is a
  critical cost factor

10
Relative Costs of Fixing Software Faults
200
30
10
4
3
2
1
Requirements
Specification
Planning
Design
Implementation
Integration
Maintenance
11
Mythical Man-Monthby Fred Brooks

• Published in 1975, republished in 1995
• Experience managing development of OS/360 in
  1964-65
• Central argument
• Large projects suffer management problems
  different in kind than small ones, due to
  division in labor
• Critical need is the preservation of the
  conceptual integrity of the product itself
• Central conclusions
• Conceptual integrity achieved through chief
  architect
• Implementation achieved through well-managed
  effort
• Brookss Law
• Adding personnel to a late project makes it later

12
Software Development LifecycleWaterfall Model
Requirements
Design
Implementation
Integration
Validation
Deployment
13
Software Development LifecycleSpiral Model
14
Requirements

• Problem Definition ? Requirements Specification
• determine exactly what the customer and user want
• develop a contract with the customer
• specifies what the software product is to do
• Difficulties
• client asks for wrong product
• client is computer/software illiterate
• specifications are ambiguous, inconsistent,
  incomplete

15
Architecture/Design

• Requirements Specification ? Architecture/Design
• architecture decompose software into modules
  with interfaces
• design develop module specifications
  (algorithms, data types)
• maintain a record of design decisions and
  traceability
• specifies how the software product is to do its
  tasks
• Difficulties
• miscommunication between module designers
• design may be inconsistent, incomplete, ambiguous

16
Architecture vs. DesignPerry Wolf 1992

• Architecture is concerned with the selection of
  architectural elements, their interactions, and
  the constraints on those elements and their
  interactions necessary to provide a framework in
  which to satisfy the requirements and serve as a
  basis for the design.
• Design is concerned with the modularization and
  detailed interfaces of the design elements, their
  algorithms and procedures, and the data types
  needed to support the architecture and to satisfy
  the requirements.

17
Implementation Integration

• Design ? Implementation
• implement modules verify that they meet their
  specifications
• combine modules according to the design
• specifies how the software product does its tasks
• Difficulties
• module interaction errors
• order of integration may influence quality and
  productivity

18
Component-Based Development

• Develop generally applicable components of a
  reasonable size and reuse them across systems
• Make sure they are adaptable to varying contexts
• Extend the idea beyond code to other development
  artifacts
• Question what comes first?
• Integration, then deployment
• Deployment, then integration

19
Different Flavors of Components

• Third-party software pieces
• Plug-ins / add-ins
• Applets
• Frameworks
• Open Systems
• Distributed object infrastructures
• Compound documents
• Legacy systems

20
Verification and Validation

• Analysis
• Static
• Science
• Formal verification
• Informal reviews and walkthroughs
• Testing
• Dynamic
• Engineering
• White box vs. black box
• Structural vs. behavioral
• Issues of test adequacy

21
Deployment Evolution

• Operation ? Change
• maintain software during/after user operation
• determine whether the product still functions
  correctly
• Difficulties
• rigid design
• lack of documentation
• personnel turnover

22
Configuration Management (CM) Tichy 1988

• CM is a discipline whose goal is to control
  changes to large software through the functions
  of
• Component identification
• Change tracking
• Version selection and baselining
• Software manufacture
• Managing simultaneous updates (team work)

23
CM in Action
1.0
24
Software Engineering Principles

• Rigor and formality
• Separation of concerns
• Modularity and decomposition
• Abstraction
• Anticipation of change
• Generality
• Incrementality
• Scalability
• Compositionality
• Heterogeneity

25
From Principles to Tools
26
Software Qualities

• Qualities (a.k.a. ilities) are goals in the
  practice of software engineering
• External vs. Internal qualities
• Product vs. Process qualities

27
External vs. Internal Qualities

• External qualities are visible to the user
• reliability, efficiency, usability
• Internal qualities are the concern of developers
• they help developers achieve external qualities
• verifiability, maintainability, extensibility,
  evolvability, adaptability

28
Product vs. Process Qualities

• Product qualities concern the developed artifacts
• maintainability, understandability, performance
• Process qualities deal with the development
  activity
• products are developed through process
• maintainability, productivity, timeliness

29
Some Software Qualities

• Correctness
• ideal quality
• established w.r.t. the requirements specification
• absolute
• Reliability
• statistical property
• probability that software will operate as
  expected over a given period of time
• relative

30
Some Software Qualities (cont.)

• Robustness
• reasonable behavior in unforeseen circumstances
• subjective
• a specified requirement is an issue of
  correctnessan unspecified requirement is an
  issue of robustness
• Usability
• ability of end-users to easily use software
• extremely subjective

31
Some Software Qualities (cont.)

• Understandability
• ability of developers to easily understand
  produced artifacts
• internal product quality
• subjective
• Verifiability
• ease of establishing desired properties
• performed by formal analysis or testing
• internal quality

32
Some Software Qualities (cont.)

• Performance
• equated with efficiency
• assessable by measurement, analysis, and
  simulation
• Evolvability
• ability to add or modify functionality
• addresses adaptive and perfective maintenance
• problem evolution of implementation is too easy
• evolution should start at requirements or design

33
Some Software Qualities (cont.)

• Reusability
• ability to construct new software from existing
  pieces
• must be planned for
• occurs at all levels from people to process,
  from requirements to code
• Interoperability
• ability of software (sub)systems to cooperate
  with others
• easily integratable into larger systems
• common techniques include APIs, plug-in
  protocols, etc.

34
Some Software Qualities (cont.)

• Scalability
• ability of a software system to grow in size
  while maintaining its properties and qualities
• assumes maintainability and evolvability
• goal of component-based development

35
Some Software Qualities (cont.)

• Heterogeneity
• ability to compose a system from pieces developed
  in multiple programming languages, on multiple
  platforms, by multiple developers, etc.
• necessitated by reuse
• goal of component-based development
• Portability
• ability to execute in new environments with
  minimal effort
• may be planned for by isolating
  environment-dependent components
• necessitated by the emergence of
  highly-distributed systems (e.g., the Internet)
• an aspect of heterogeneity

36
Software Process Qualities

• Process is reliable if it consistently leads to
  high-quality products
• Process is robust if it can accommodate
  unanticipated changes in tools and environments
• Process performance is productivity
• Process is evolvable if it can accommodate new
  management and organizational techniques
• Process is reusable if it can be applied across
  projects and organizations

37
Assessing Software Qualities

• Qualities must be measurable
• Measurement requires that qualities be precisely
  defined
• Improvement requires accurate measurement
• Currently most qualities are informally defined
  and are difficult to assess

38
Software Engineering Axioms

• Adding developers to a project will likely result
  in further delays and accumulated costs
• Basic tension of software engineering
• better, cheaper, faster pick any two!
• functionality, scalability, performance pick
  any two!
• The longer a fault exists in software
• the more costly it is to detect and correct
• the less likely it is to be properly corrected
• Up to 70 of all faults detected in large-scale
  software projects are introduced in requirements
  and design
• detecting the causes of those faults early may
  reduce their resulting costs by a factor of 100
  or more

39
Embedded Software

• Interaction with physical world
• Executes on machines, not computers
• Written by engineers who are domain experts
• Current methods offered by computer scientists
  are not always satisfactory
• Complexity and size of embedded software are
  growing rapidly
• severe constraints remain.

40
Properties of Embedded Software

• Timeliness
• speed up in software not hardware
• Concurrency
• Current methods not reliable
• Predictability and adaptability
• Liveness
• Non-terminating
• Interfaces
• Processes not procedures
• Temporal/dynamic properties in OOP reqd.
• Heterogeneity
• Reactivity
• Continuously changing to adapt to changing
  environment

41
Limitations of current SE Methods

• Object Orientation
• Procedures are terminating
• Objects are passive
• Hardware Design
• Highly constrained
• RTOS
• Hand built microkernels for task scheduling
• Priority-based inappropriate
• ROOM
• Required parameters hard to predict accurately
  enough

42
Actor-Oriented Design

• Actor
• Encapsulation of parameterized actions
• Interface defined by ports and parameters
• Port
• Communication between input and output data
• Without call-return semantics
• Model of computation
• Communication semantics among ports
• Flow of control
• Implementation is a framework
• Examples
• Simulink(The MathWorks)
• LabVIEW ( from National Instruments)
• Easy 5x (from Boeing)
• ROOM(Real-time object-oriented modeling)
• ADL(Wright)

43
Comparing with Object/middleware-oriented design

• Object/middleware-oriented design
• Object abstraction, class inheritance, and method
  call interfaces
• Flow of control
• Ignore system properties such as concurrency and
  communication
• Decompose the system into components, but how to
  compose the components?
• Static structure
• In term of actors and framework in actor-oriented
  design

44
Examples of Model of Computations

• Dataflow
• Connections represents data streams
• Actors compute their output data stream for input
  streams
• Useful for designing signal processing algorithms
  and sampled control laws
• Time Triggered
• Follow the principle of global progress of time
• Strong composability,diagnostically, and formal
  analysis
• Synchronous/reactive model
• Stimulated by events from the environment, but
  responds instantaneously
• Excellent for applications with concurrent and
  complex control logic
• Discrete Events
• Actors share a global notion of time and
  communication through events that placed on a
  continuous line
• Used in modeling hardware and software timing
  properties, communication networks, and queuing
  systems

45
Examples of Model of Computations (Cont.)

• Process Networks
• Asynchronous communication between processes
• Excellent for signal processing
• Difficult to interoperate with models including
  notion of time
• Rendezvous
• Synchronous communication between processes or
  threads
• Excellent for applications where resource sharing
  is a key element Poor in maintaining determinacy
• Difficult to interoperate with models including
  notion of time
• Publish and Subscribe
• Connections are event stream Components produce
  or consume events
• Good for distributed applications
• Continuous Time
• Connection carries a continuous-time signal
  Actors denote the relation among these signals
• Used in control system design for modeling
  physical dynamics and continuous control laws
• Finite State Machines
• Component is called state or node. The connection
  represent transitions of transfer of the control
  between states
• Sequential execution
• Excellent for describing control logic