Embedded Systems Architecture Course

1
Embedded Systems Architecture Course

• Rajesh K. Gupta
• University of California, Irvine
• Ki-Seok Chung and Ali Dasdan
• University of Illinois at Urbana-Champaign
• Interstate Electronics Corporation, Anaheim, CA
• 3-5 December 1997
• 21-23 January 1998

2
Overview

• Software Design and Modeling
• Sections 4., 5., 13.
• 4 hours
• Scheduling Theory
• Sections 11.
• 4 hours
• Real-Time Operating Systems
• Sections 10.
• 4 hours
• Timing Issues
• 2 hours
• Performance Analysis
• 2 hours
• Design Automation for Embedded Systems
• 1 hour

3
Overview

• (Also discuss
• complexity theory - just a little to give the
  concepts needed during the discussion of
  scheduling theory
• trends in embedded systems
• trends for languages
• trends for compilers - give them a list of things
  that they can do as users to take more advantage
  of their compilers
• trends for processors
• trends for architectures
• trends for everything )

4
Software Design and Modeling
5
Real-Time System Design Concepts
6
Real-Time System Design Concepts

• Real-Time system design concepts
• Identifiable and Desirable Features
• Good features that a design should possess
• Some are identifiable.
• Identifiable features are related to the
  functioning of the system.
• Desirable features facilitate maintenance and
  reuse of the system.
• General Design Principles
• Those principles that apply to any software
  system.
• Real-Time-Specific Design Principles
• Those principles that are more important for
  real-time systems.

7
Real-Time System Design Concepts

• Identifiable and desirable features
• Identifiable features
• Fitness for purpose The system should work
  correctly according to its specifications.
• Robustness The system should be stable against
  changes to its file and data structure, user
  interface, etc.
• Desirable features
• Simplicity Simplify, simplify, simplify.
• Separation of concerns The different concepts
  and components should be separated out.
• Information hiding About what should be kept
  local to a module of the design and what should
  be visible outside that module.

8
Real-Time System Design Concepts

• General design principles
• Abstraction
• similar to abstract data types
• Modularity - related to separation of concerns
  and simplicity
• achieved through cohesion and coupling
• Information hiding
• Completeness - related to fitness for purpose
• an issue of whether the design meets all of the
  requirements of the specification
• Design for maintenance - related to robustness
• imposing means to facilitate maintenance of
  software
• Design for reuse
• Assessing a design
• how well the design meets the specification
  (completeness and correctness)
• how well-structured the design is (quality)
• Design verification
• the use of formal techniques to verify the design
  for completeness and consistency

9
Real-Time System Design Concepts

• Real-time-specific design principles
• Finite state machines
• may be used to model the behavioral aspects of a
  system
• many real-time (control) systems are highly
  state-dependent
• Concurrency
• a natural model for many real-world applications
• helps achieve separation of concerns
• helps reduce overall system execution time
• helps implement task criticality
• Information hiding
• makes software understandable, modifiable,
  maintainable, reusable
• can be applied to data structures (data
  abstraction), synchronization (monitor), and I/O
  devices (virtual interface)
• a basis for object-oriented design
• Timing constraints
• models performance constraints of real-time
  systems

10
Design Life-Cycle and Its Phases
11
Design Life-Cycle

• Truth about design life-cycle (Put at the end of
  life cycle disc.)
• a model and hence, an abstraction
• may not be followed strictly due to the practical
  matters such as budget and time limitations,
  changing customer requirements, etc.
• if so, can be faked by modifying the
  documentation after the project is completed
• transitions can occur from any phase to any other
  in the life cycle
• Phases of design life-cycle
• Concept phase
• Requirements phase
• Architecture design phase
• Detailed design phase
• Implementation phase
• Testing phase
• Maintenance phase

12
Design Life-Cycle

• (Put a picture of the phases)

13
Design Life-Cycle Phases

• Concept phase
• identifies product need and goals
• produces feasibility studies
• driven by management directive, customer input,
  technology changes, and marketing decisions
• usually produces no documentation other than
  internal feasibility studies, white papers, or
  memos

14
Design Life-Cycle Phases

• Requirements phase
• the phase in which ideas are committed to paper,
  usually as a requirements document or software
  specification
• requirements document is prepared by the customer
  in accordance with accepted standards
• identifies what the product is to do in terms of
  requirements such as
• timing/throughput
• user interface
• accuracy requirements
• interfaces to existing software and hardware
• etc.
• identifies requirements pertaining to the
  systems external behavior without describing how
  the system works internally
• writes test plan
• prepares project schedule
• can occur in parallel with concept phase

15
Design Life-Cycle Phases

• Architecture design phase
• identifies how the requirements are to be met in
  terms of functional components
• structures the system into its constituent
  components
• maps the components into concurrent tasks
• determines the behavioral aspects of the system
  such as the sequence of events and states that
  the system experiences
• prepares architecture design document

16
Design Life-Cycle Phases

• Detailed design phase
• defines the algorithmic details of each system
  component
• maps the system tasks into hardware and software
• develops test cases
• identifies the problems in the requirements
  document such as conflicts, redundancies, or
  requirements that cannot be met with current
  technology
• if so, proposes changes to the requirements
  document
• prepares detailed design document
• Particular attention should be paid to algorithms
  for resource sharing, deadlock avoidance, and
  interfacing to hardware I/O devices.

17
Design Life-Cycle Phases

• Implementation phase
• implements each component in a programming
  language
• integrates the systems hardware and software
  components
• implements test cases
• can still detect problems in the original system
  requirements

18
Design Life-Cycle Phases

• Testing phase
• Unit testing
• tests each component before it is combined with
  other components
• achieves minimum test coverage, which is to make
  sure that each statement is executed at least
  once and that every possible outcome of each
  branch is tested at least once
• Integration testing
• involves combining tested components into
  progressively more complex groupings of
  components and testing them until the whole
  system has been put together and the interfaces
  tested
• System testing
• tests an integrated hardware and software system
  to verify that the system meets the specified
  requirements
• should be tested by an independent test team for
  objectivity
• should perform functional, load, and performance
  testing
• Cosimulation can be used for system testing.
• Acceptance testing
• carried out by the customer at the customer site
• tests the same criteria as system testing does

19
Design Life-Cycle Phases

• Maintenance phase
• consists of product deployment and customer
  support
• identifies the problems in the system, if exist,
  and areas for improvement
• modifies the system for correction and/or
  improvement and performs regression testing
• continues until the product is no longer
  supported

20
Design Modeling
21
Design Modeling

• Four major models
• Waterfall model
• Prototyping model
• Throwaway prototyping
• Evolutionary prototyping
• Rapid prototyping
• Spiral model
• Spiral-to-circle model

22
Design Modeling

• Waterfall model
• assumes that each phase in the life of a software
  product occurs in time sequence, with the clearly
  defined boundaries between phases
• a major successful improvement over the
  undisciplined approach
• the most widely used software life-cycle model
  (circa 1993)
• has the phases as discussed earlier
• Weaknesses
• It may better suit to hardware design (due to its
  sequence of largely irreversible phases) than to
  software design as the latter is an iterative
  process.
• Software requirements are not properly tested
  until a working system is available to
  demonstrate to the end users although errors in
  the requirements specification are usually the
  last to be detected and are the most costly to
  correct.
• A working system only becomes available in the
  life cycle thus, a major design or performance
  problem may go undetected until the system is
  almost operational, at which time it is usually
  too late to take effective action.
• Solution Prototyping

23
Design Modeling

• (Put a picture of the waterfall model from gomaa)

24
Design Modeling

• Prototyping
• Throwaway prototyping
• developing a working system rapidly and at low
  cost to help clarify user requirements
• may be performed between a preliminary and
  revised requirements specifications
• particularly useful for specifying requirements
  (e.g., for user interfaces) for interactive
  systems
• can also be performed for experimental
  prototyping to test correctness and performance
  of certain algorithms
• Evolutionary prototyping
• a form of incremental development - evolve the
  prototype all the way into the delivered system
• have a subset of the system working early that is
  then gradually improved
• best to have the first version test a complete
  path through the system from external inputs to
  outputs
• can be combined with the above technique - start
  with the throwaway and then evolve

25
Design Modeling

• Rapid prototyping (in the context of RASSP)
• also called Virtual Prototyping
• based on VHDL
• defined as preparing an executable specification
  of an embedded system (called a virtual
  prototype) and the stimuli that describe it in
  operation at multiple abstraction levels
• a top-down design process that produces virtual
  prototypes for hardware, software, and interface
  cospecification, codesign, cosimulation, and
  coverification
• more details at http//www.rassp.org/

26
Design Modeling

• (Put a picture of the RASSP design flow from
  madisetti)

27
Design Modeling

• Spiral model
• integrates prototyping and incremental
  development with Waterfall Model
• an iterative life cycle in which each loop of the
  spiral represents one iteration and the radial
  coordinate represents cumulative cost
• recognizes that the phase boundaries are not
  always clearly defined, nor the phases time
  sequential
• Each iteration carries out prototyping and risk
  assessment of the project.

28
Design Modeling

• (Put a picture of the spiral model from laplante)

29
Design Modeling

• Spiral-to-Circle model
• based on the heuristic that complex systems will
  develop and evolve within an overall architecture
  much more rapidly if there are stable
  intermediate forms than if there are not
• For software development
• pause in the outward spiral from time to time by
  going into a closed circle for a stable version
• For hardware development
• schedule holds at the end of each step in the
  sequence to review the history of the development
  from its beginning to determine that the
  integrity of the system concept has not been
  violated - that is, everything necessary has been
  done and that nothing unnecessary has been added
• For combined development
• agree on stable hardware and software
  configurations that would come together for
  testing at planned times
• implies repeated hardware design reviews and
  prototypes and usable intermediate software
  products
• produces intermediate forms that can even be
  accepted as an acceptable end product, should
  circumstances so dictate

30
Design Modeling

• (Put a picture of the spiral-to-circle model from
  rechtin)

31
Design Representation and Models
32
Design-Related Definitions

• Software design how a software system is
  structured into components and defines the
  interfaces between the components
• Software design strategy an overall plan and
  direction for performing a design, e.g.,
  functional decomposition
• Software design concept a fundamental idea that
  can be applied to designing a system, e.g.,
  information hiding
• Software structuring criteria heuristics or
  guidelines used to help a designer in structuring
  a software system into its components
• Software design representation or notation a
  means of describing a software design- may be
  graphical, symbolic, or textual, e.g.,
  data/control flow graphs
• Software design method a systematic approach for
  creating a design
• helps identify the decision decisions to be made,
  the order to make them, and the criteria to use
  in making them
• usually describes a sequence of steps for a
  designer to follow when creating a design, given
  the software requirements of the system

33
Design-Related Definitions

• (for design methods, focus on
• structured analysis and design
• object-oriented design
• gomaas methods
• for design representation, focus on
• what is being used in the above methods)

34
Design Representation
35
Design Representation

• Defined as a means of describing a software
  design (typically can also describe the entire
  system)
• No one technique is a panacea hence, a
  combination of techniques should be used.
• The specification of temporal behavior is the
  most difficult, but the most important, aspect of
  specification/design in a real-time system.
  Nevertheless, it is not adequately supported.
• Task structuring is fundamental because breaking
  a larger system into smaller component subsystems
  is the most viable approach to beat the
  complexity.
• Representation techniques to be discussed
• Structure charts
• Pseudocode
• Finite state machines
• Statecharts
• Petri nets
• Data flow/control flow diagrams

36
Design Representation

• Structure charts
• used to show how a program is decomposed into
  modules, where a module is typically a procedure
  or function, and to show the interfaces between
  modules
• equivalently represent the run-time calling
  hierarchy of the modules forming a sequential
  program
• show the modular decomposition of a system, i.e.,
  hierarchical (tree-like) arrangement of the
  modules.
• Modules are represented by rectangles.
• Moving from left to right in the chart represents
  increasing sequence in execution.
• Moving from top to bottom along any branch
  indicates increasing detail.
• More suitable for small systems, which is why
  they are used for task structuring in the design
  methods to be discussed
• Not suitable for large systems, concurrent
  systems, and systems with rich conditional
  behavior

37
Design Representation

• (Show an example structure chart from gomaa or
  laplante)
• (in fact, I can use a structure chart to give the
  overview of all the topics to be discussed during
  this class)

38
Design Representation

• Pseudocode
• some specific-language-independent high-order
  language
• written in a manner that can easily be mapped to
  a certain programming language
• mostly suitable for designing the internals of
  the modules in a task, i.e., for designing the
  internals of each rectangle in a structure chart,
  but not suitable for large systems
• very common in computer science books to specify
  algorithms, which are usually less than one-page
  long

39
Design Representation

• (show an example pseudocode)

40
Design Representation

• Finite state machines (FSMs)
• A FSM is a conceptual machine with a given number
  of states.
• A FSM can be only in one of the states at any
  specific time
• State transitions are changes in state that are
  caused by input events.
• In response to an input event, the system may
  transition to the same or to a different state as
  well as an output event may be optionally
  generated.
• As real-time systems are typically highly state
  dependent, FSMs can help substantially by
  providing a means of understanding the complexity
  of these systems.
• widely used for the specification of state-driven
  systems.
• easy to develop, easy to generate code for
• have a very rich theory
• Biggest disadvantage difficulty in coping with
  complex systems, e.g., size, communication, etc.
• Notations used to represent FSMs
• state transition diagrams
• state transition tables

41
Design Representation

• (show an example of a FSM)

42
Design Representation

• Statecharts
• an extension of FSMs that provide a notation and
  approach for hierarchically structuring FSMs and
  allowing concurrent FSMs that interact with each
  other
• have a commercial development environment, i.e.,
  statemate from I-Logix with graphical design,
  simulation, and code generation capability

43
Design Representation

• (show an example of a statechart)

44
Design Representation

• Petri nets
• a (graphical) representation technique for
  modeling concurrent systems
• can be used as analysis tools as well as modeling
  tools
• used successfully to model hardware systems,
  communication systems, and software systems
• Two types of nodes supported
• places (denoted by circles)
• transitions (denoted by bars)
• Places represent conditions (state) and
  transitions represent events (action).
• The execution is causal and controlled by the
  position and movement or markers called tokens,
  which are denoted by black dots in the places.
• A transition is enabled to fire when all its
  input places have a token in them. When it fires,
  a token is removed from each input place and a
  token is placed on each output place.
• Timed versions, which associate finite times with
  transitions (more common) or places, exist.
• suitable for performance analysis of real-time
  systems

45
Design Representation

• (give an example of a Petri net)

46
Design Representation

• Data flow/control flow graphs
• used to show data flows (solid lines) and control
  flows (dashed lines)
• have data transformations (solid circles) and
  control transformations (dashed circles)
• A data flow can be discrete, arrives at specific
  time intervals, or continuous, arrives
  continuously.
• A control (or event) flows is a discrete signal
  and has no value. It is used to signal that some
  action has happened or to initiate a command.
• Three kinds of control flows
• trigger (to activate a data transformation to
  perform a specific action or to control the
  external environment occurs at a specific
  instant)
• enable (to activate a transformation)
• disable (to deactivate a previously-enabled
  transformation)

47
Design Representation

• (Give an example of data flow/control flow
  graphs)

48
Design Methods
49
System Design Simplified

• (Give an overview of a typical system design,
  with all the steps. Try to give that of codesign
  to illustrate both hardware and software. Also
  point out the similarities and differences
  between them. Emphasize which steps will be
  discussed in detail in the sequel)
• (Of course, this overview will be similar to the
  life cycle model but in this section, try to give
  the idea using circles/boxes by also discussing
  the decomposition, processor selection/assignment,
  interface problems, etc.)

50
History of Design Methods

• No systematic approach (60s)
• Structured programming (With Dijkstra in early
  70s)
• Top-down (hierarchical) design
• Stepwise refinement
• Structured Design methods (mid- to late 70s)
• Data flow oriented design (consider data flow
  thru the system)
• Jackson Structured Programming (mid- to late 70s)
• Data structured design (consider the data
  structures)
• Idea of separating logical and physical data
  (late 70s)
• led to the development of data base management
  systems
• introduced methods for logical design of data
  bases, e.g., entity-relationship modeling
• Idea of information hiding (With Parnas in early
  70s)
• Introduction of MASCOT notation for concurrent
  system design (With Simpson in late 70s)

51
History of Design Methods

• Maturation of software design methods (80s)
• Naval Research Lab Software cost reduction method
  (NRL - Parnas in 1984)
• Real-Time Structured Analysis and Design (RTSAD -
  Ward in 1985 and Hatley in 1988)
• Design Approach for Real-Time Systems (DARTS -
  Gomaa in 1984)
• Later extended to Ada-based DARTS (ADARTS) and
  COBRA-based DARTS (CODARTS) (COBRA Concurrent
  Object-Based Real-Time Analysis)
• Jackson System Development (JSD - Jackson in
  1983)
• Object-Oriented Design methods (OOD, e.g., Booch
  in 1986)

52
History of Design Methods

• (Draw a tree diagram of the methods showing which
  came first, which uses which, etc.)
• (Give better references for the methods as well
  not cover all of them)
• (Give a definition of the cruise control and
  monitoring system as well use it to illustrate
  the methods)
• (Note the classification on pp.40-41)

53
A Classification of Design Methods

• A classification based on the strategy used
• Design methods based on functional decomposition
• Real-Time Structured Analysis and Design (RTSAD)
• Design methods based on concurrent task
  structuring
• Design Approach for Real-Time Systems (DARTS)
• Design methods based on information hiding
• Naval Research Lab software cost reduction
  technique (NRL)
• Object-Oriented Design method (OOD)
• Design methods based on modeling the problem
  domain
• Jackson System Development method (JSD)
• Object-Oriented Design method (OOD)

54
Methods to be Discussed

• Goal To cover all the strategies on the previous
  slide
• Survey of the following
• Real-Time Structured Analysis and Design (RTSAD)
• Design Approach for Real-Time Systems (DARTS)
• Object-Oriented Design method (OOD)
• More detailed analysis of the following
• Concurrent Design Approach for Real-Time Systems
  (CODARTS)

55
Method Evaluation Methodology

• For each method,
• Overview
• Basic concepts
• Notation
• Steps in method
• Products of design process
• Assessment of method
• Extensions and/or variations
• Illustration of method (will use the cruise
  control example)

56
Real-Time Structured Analysis and Design (RTSAD)
57
Structured Analysis and Design (RTSAD)

• Overview
• an extension of Structured Analysis and
  Structured Design to address the needs of
  real-time systems
• generally viewed as primarily a specification
  method for the software requirements of the
  system
• has two variations Ward/Mellor (WM) and
  Boeing/Hatley (BH)

58
Structured Analysis and Design (RTSAD)

• Basic concepts
• Data and control flow analysis
• the system in the form of functions (called
  transformations or processes)
• the functions to be mapped into modules
• the interfaces in the form of data flows or
  control flows
• The transformations may be data and control
  transformations.
• Finite state machines
• used to define the behavioral characteristics of
  the system
• A control transformation represents the execution
  of a state transition diagram input event flows
  trigger state transitions and output event flows
  control the execution of data transformations.

59
Structured Analysis and Design (RTSAD)

• Entity-relationship modeling
• used to show the relationships between the data
  stores of the system
• not very common more suitable for data intensive
  systems
• Module cohesion
• used to module decomposition as a criterion for
  identifying the strength or unity within a module
• Module coupling
• used to module decomposition as a criterion for
  determining the degree of connectivity between
  modules

60
Structured Analysis and Design (RTSAD)

• Notation
• Data flow/control flow diagrams for data
  flow/control flow analysis
• State transition diagrams for finite state
  machines
• nodes represent states and arcs represent state
  transitions
• Entity-relationship diagrams for
  entity-relationship modeling
• shows the entities in the system, their
  attributes, and their relationships to each other
• Structure charts
• shows how a program is decomposed into modules,
  where a module is typically a procedure or
  function, and shows the interfaces between them

61
Structured Analysis and Design (RTSAD)

• (Put the picture in p. 46 to illustrate the
  notation)

62
Structured Analysis and Design (RTSAD)

• Steps in method Real-Time Structured Analysis
  (RTSA) part
• Develop the system context diagram
• define the boundary between the system and its
  external environment
• show all the inputs to and all the outputs from
  the system
• Perform data flow/control flow decomposition
• structure the system in the form of functions
  (called transformations or processes)
• define the interfaces in the form of data flows
  or control flows
• The transformations may be data and control
  transformations.
• Structure the system as a hierarchical set of
  data flow/control flow diagrams

63
Structured Analysis and Design (RTSAD)

• Develop control transformations or specifications
• use finite state machines, in the form of state
  transition diagrams or tables, to define the
  behavioral characteristics of the system
• use a state transition diagram to show a
  different state of the system or subsystem as
  well as to show the input events (or conditions)
  that cause state transitions and actions
  resulting from state transitions
• Develop mini-specifications (process
  specifications)
• write a mini-specification (usually in Structured
  English) for each leaf node data transformation
  on the data flow diagram
• Develop data dictionary
• develop a data dictionary that defines all data
  flows, even flows, and data stores

64
Structured Analysis and Design (RTSAD)

• Steps in method Real-Time Design (RTD) part
• Allocate transformations to processors
• allocate RTSA transformations (functions) to
  processors of the target system
• Allocate transformations to tasks
• allocate the transformations for each processor
  to concurrent tasks
• Each task represents a sequential program.
• Structured design
• allocate each task (or equivalently, each
  transformation) into modules
• use the criteria of module coupling and cohesion
  together with Transform Analysis and Transaction
  Analysis, used for mapping a data flow diagram
  into a structure chart, to develop a program
  design

65
Structured Analysis and Design (RTSAD)

• Products of RTSAD
• Real-Time Structured Analysis (RTSA)
• system context diagram
• hierarchical set of data flow/control flow
  diagrams
• data dictionary
• mini-specifications (for primitive
  transformations)
• state transition diagrams (for control
  transformations)
• Structured Design
• a structure chart for each program to show how it
  is decomposed into modules
• A module is defined in terms of its external
  specification, i.e., its input parameters, output
  parameters, function, and its internal
  specification using pseudocode.

66
Structured Analysis and Design (RTSAD)

• Assessment of method (Strengths)
• It has been used widely and there is much
  experience in applying the method.
• There are many CASE (Computer-Aided Software
  Engineering) tools to support it.
• The use of data flow/control flow diagrams can
  assist in understanding and reviewing the system.
• It emphasizes the use of state transition
  diagrams, which are very common in real-time
  control systems.
• Module decomposition criteria of cohesion and
  coupling help in assessing the quality of the
  design.

67
Structured Analysis and Design (RTSAD)

• Assessment of method (Weaknesses)
• There is not much guidance on how to perform a
  system decomposition, leading to different uses
  by different designers.
• RTSA is usually considered a requirements
  specification method, but it also addresses
  system decomposition, creating a tendency in many
  projects to make design decisions during this
  phase.
• Because of its weaknesses in task structuring, it
  is limited for designing concurrent systems, and
  hence real-time systems.
• It is limited in its application of information
  hiding.

68
Structured Analysis and Design (RTSAD)

• Extensions and/or variations
• The COBRA analysis and modeling method, to be
  discussed in conjunction with CODARTS, merges
  earlier RTSAD methods and eliminates their
  weaknesses.

69
Structured Analysis and Design (RTSAD)

• Illustration of method
• (use the cruise control example from the book -
  17 figures)

70
Design Approach for Real-Time Systems (DARTS)
71
Design Approach for RT Systems (DARTS)

• Overview
• proposed to address the weakness of RTSA in
  handling task structuring or concurrent tasks
• emphasizes the decomposition into concurrent
  tasks and defining the interfaces between them
• provides decomposition principles and steps to
  follow to proceed from a RTSA specification to a
  design consisting of concurrent tasks

72
Design Approach for RT Systems (DARTS)

• Basic concepts
• Task structuring criteria
• heuristics derived from experience obtained in
  the design of concurrent systems
• applied to transformations (functions) on the
  data flow/control flow diagrams to group
  functions together based on the temporal sequence
  in which they are executed
• Task interfaces
• message communication, event synchronization (for
  control), information hiding modules (for shared
  data)
• Information hiding
• used for encapsulating data stores
• Finite state machines as in RTSA
• Evolutionary prototyping and incremental
  development

73
Design Approach for RT Systems (DARTS)

• Notation
• Data flow/control flow diagrams as in RTSA
• State transition diagrams as in RTSA
• Task architecture diagrams
• show the decomposition of a system into
  concurrent tasks and the interfaces between them
  in the form of massages, events, and information
  hiding modules
• Structure charts as in RTSA

74
Design Approach for RT Systems (DARTS)

• (put the notation pictures on p. 70)

75
Design Approach for RT Systems (DARTS)

• Steps in method
• Develop system specifications using Real-Time
  Structured Analysis (RTSA)
• similar to RTSA steps 1 through 5
• Structure the system into concurrent tasks
• apply the task structuring criteria to the leaf
  nodes of the hierarchical set of data
  flow/control flow diagrams
• draw a preliminary task architecture diagram to
  show the task structuring
• map the transformations to such tasks as I/O,
  control, periodic, and aperiodic according to the
  sequential, temporal, or functional cohesion
  criteria

76
Design Approach for RT Systems (DARTS)

• Steps in method
• Define task interfaces
• define task interfaces by analyzing the data flow
  and control flow interfaces between the tasks
  identified in the previous stage
• map data flows to message interfaces, event flows
  to event signals, and data stores to information
  hiding modules
• perform timing analysis to allocate timing
  budgets to each task based on the external
  response times
• Design each task
• Each task represents the execution of a
  sequential program.
• structure each task into modules
• define the external interface and internals of
  each module

77
Design Approach for RT Systems (DARTS)

• Products of design process
• RTSA specification
• Task structure specification
• defines the concurrent tasks in the system
• defines the function of each task and its
  interface to other tasks
• Task decomposition
• defines the decomposition of each task into
  modules
• defines the function of each module and its
  external interface and internals

78
Design Approach for RT Systems (DARTS)

• Assessment of method (strengths)
• Emphasizes the decomposition of the system into
  tasks and provides criteria for identifying them.
• Provides detailed guidelines for defining the
  interfaces between tasks.
• Emphasizes the use of state transition diagrams.
• Provides a transition from a RTSA specification
  to a real-time design.

79
Design Approach for RT Systems (DARTS)

• Assessment of method (weaknesses)
• It does not use information hiding extensively
  enough for encapsulating data stores.
• A potential problem is its dependence on the RTSA
  phase if that phase is not done well, task
  structuring can be more difficult.

80
Design Approach for RT Systems (DARTS)

• Extensions and variations
• Extension of DARTS for distributed systems, where
  it is necessary to structure a system into
  subsystems before structuring the subsystems into
  tasks, is DARTS/DA.
• The DARTS weakness in information hiding is
  addressed by the ADARTS and CODARTS methods.
• The potential problem with using RTSA is
  addressed in the CODARTS method by using the
  COBRA analysis and modeling method instead of
  RTSA.

81
Design Approach for RT Systems (DARTS)

• Illustration of method
• (use the cruise control example from the book - 5
  figures)

82
Object-Oriented Design Method (OOD)
83
Object-Oriented Design Method (OOD)

• Overview
• based on two essential concepts abstraction and
  information hiding
• usually also includes inheritance as the third
  essential concept

84
Object-Oriented Design Method (OOD)

• Basic concepts
• Abstraction
• used in the separation of an objects
  specification from its body, i.e., separating the
  external interface from the internals
• Information hiding
• used in structuring the object, deciding what
  information should be visible and what
  information should be hidden
• Objects
• based on the information hiding concept
• Each has state (internal data) that can only be
  modifiable by calling the operations provided by
  the object. Each also provides operations for
  outside use uses operations provided by others
  is a unique instance of some class has
  restricted visibility of and by other objects.

85
Object-Oriented Design Method (OOD)

• Basic concepts
• Class
• an object type, can be considered to be a
  template for objects. An object is an instance of
  a class.
• Inheritance
• a relationship among classes where a child class
  can share the structure and operations of a
  parent class and adapt it for its own use

86
Object-Oriented Design Method (OOD)

• Notation
• Class diagrams
• used to show the relationships between classes in
  the logical design of a system
• intended to show the static structure of a
  system, particularly, inheritance and uses
  relationships
• Object diagrams
• used to show both the objects in the system and
  the relationships between them
• intended to show the dynamic structure of a
  system, e.g., a snapshot in time of a group of
  communicating objects (thru messages)
• State transition diagram
• shows the states of an object and the events that
  cause transition between these states

87
Object-Oriented Design Method (OOD)

• Notation
• Timing diagrams
• used to show the dynamic interaction of a group
  of objects by showing the time-ordered sequence
  of execution of operations provided by the
  objects
• Module diagrams
• show the allocation of classes and objects to
  modules in the physical design of the system
• Process diagrams
• show the allocation of concurrent processes
  (tasks) to processors in the physical design of
  the system

88
Object-Oriented Design Method (OOD)

• Steps in method
• Identify the classes and objects
• identify objects by determining the entities in
  the problem domain
• This step is usually difficult and informal - the
  latest trend is information modeling techniques
  in which each class or entity us defined by means
  of its attributes and its relationships to other
  classes.
• Identify the semantics of the classes and objects
• determine each objects interface
• determine each objects operations, the
  operations that it uses
• develop preliminary class and object diagrams

89
Object-Oriented Design Method (OOD)

• Steps in method
• Identify the relationships among classes and
  objects
• determine the static (inheritance and uses
  relationships) and dynamic dependencies between
  objects
• may create new classes to define the common
  behavior of a group of similar objects
• refine the class and object diagrams and develop
  preliminary module diagrams
• Possible object types
• servers - provide operations for other objects
  but do not use operations from other objects
• actors - use operations from other objects but do
  not provide any
• agents - provide operations and also use
  operations from other objects

90
Object-Oriented Design Method (OOD)

• Steps in method
• Implement classes and objects
• allocate classes and objects to information
  hiding modules
• allocate programs to processors
• design the internals of each object, i.e., design
  the data structures and infernal logic of each
  object

91
Object-Oriented Design Method (OOD)

• Products of design process
• Class diagrams, with which the specification of
  the individual classes is associated
• Object diagrams, with which the specification of
  the individual objects is associated
• State transition diagrams
• Timing diagrams
• Module diagrams, with which the specification of
  the individual modules
• Process diagrams, with which the specification of
  the individual processes and processors are
  associated

92
Object-Oriented Design Method (OOD)

• Assessment of method (strengths)
• The method is based on the concepts of
  information hiding, classes, and inheritance,
  which are key concepts in the software design.
• Structuring of a system into objects makes the
  system more maintainable and components
  potentially reusable.
• Providing inheritance allows components to
  modified in a controlled manner where necessary.
• Maps well to languages that information hiding
  modules (such as Ada and Modula-2), and to
  languages that support classes and inheritance
  (such as C, Smalltalk, Eiffel).

93
Object-Oriented Design Method (OOD)

• Assessment of method (weaknesses)
• Does not adequately address the important issues
  of task structuring, which is an important
  limitation in real-time design, as it assumes
  that the same criteria may be used for
  identifying tasks as information hiding modules.
• The method assumes a very iterative procedure in
  developing a design. As a result, it is not
  specific as to what procedures should be applied
  at each step.
• The object structuring criteria are not
  comprehensive enough.
• Although it uses timing diagrams, the method does
  not adequately address timing constraints.

94
Object-Oriented Design Method (OOD)

• Extensions and variations
• The COBRA analysis method provides a set of
  object structuring criteria oriented to
  identifying objects in the problem domain.

95
Object-Oriented Design Method (OOD)

• Illustration of method
• (put pictures on p. 107, 6 figures)

96
Concurrent Design Approach for Real-Time Systems
(CODARTS)
97
CODARTS

• Overview
• CODARTS is the latest refinement of the DARTS and
  ADARTS methods.
• ADARTS is oriented towards the design of
  Ada-based concurrent and real-time systems.
• CODARTS, being a general purpose design method
  that is not oriented toward a particular
  language, provides two extensions to ADARTS
• It provides an alternative approach, called COBRA
  for Concurrent Object-Based Real-Time Analysis,
  to RTSA for analyzing and modeling the system.
• It provides the support for the design of
  distributed applications.
• CODARTS is built on all of the methods below and
  addresses their major limitations
• Real-Time Structured Analysis and Design (RTSAD)
• Design Approach for Real-Time Systems (DARTS)
• Jackson System Development (JSD)
• Naval Research Lab Method (NRL)
• Object-Oriented Design (OOD)

98
CODARTS

• Steps in Method
• Develop environmental and behavioral model of the
  system
• use the COBRA method for analyzing and modeling
  the problem domain.
• COBRA provides guidelines for developing the
  environmental model based on the system context
  diagram and structuring criteria for decomposing
  a system into subsystems that may potentially be
  distributed.
• COBRA provides criteria for determining the
  objects and functions within a subsystem.
• COBRA provides a behavioral approach for
  determining how the objects and functions within
  a subsystem interact with each other using event
  sequencing scenarios.
• Structure the system into distributed subsystems
• An optional step taken for distributed concurrent
  and distributed real-time applications.

99
CODARTS

• Steps in Method
• Structure the system (or subsystem) into
  concurrent tasks
• determine the concurrent tasks in the system by
  applying the task structuring criteria
• determine the intertask communication and
  synchronization interfaces
• Structure the system into information hiding
  modules
• determine the information hiding modules in the
  system by applying the module structure criteria
• Integrate the task and module views
• integrate task and module views to produce a
  software architecture
• Define component interface specifications
• define them for tasks and modules
• These specifications represent the externally
  visible view of each component.
• Define the software incrementally
• identify system subsets to be used for each of
  the detailed, coding, and testing stages

100
CODARTS

• Notation
• Real-Time Structured Analysis (RTSA) notation
• Task architecture diagram notation
• Software architecture diagram notation
• ADA architecture diagram notation (not to be
  covered)
• Notation for distributed applications (not to be
  covered)
• (put pictures of these notations from gomaa pp.
  146-149)

101
CODARTS - Step 1

• Step 1 - Develop environmental and behavioral
  model of the system
• Developing the environmental model
• System decomposition into subsystems
• Notation for behavioral model
• Modeling objects in the problem domain
• Modeling functionality in the problem domain
• Behavioral analysis

102
CODARTS - Step 1

• Developing the environmental model
• Developing the system context diagram
• The environmental model defines the boundary
  between the system to be developed and the
  external environment. It is described by means of
  the system context diagram. This diagram shows
  the external entities that the system has to
  interface to as well as the inputs to and the
  outputs from the system.
• In concurrent and real-time systems, the I/O with
  the external entities is usually via discrete
  data flows.
• The external entities that the system has to
  interface to are represented by terminators.
• A terminator can be a source of data, a sink of
  data, or both.
• Three kinds of terminators those that represent
  I/O devices, those that represent users, and
  those that represent other systems (or
  subsystems).
• A human user is a terminator only if (s)he
  interacts with the system via standard I/O
  devices such as a keyboard/display.

103
CODARTS - Step 1

• Developing the environmental model
• Developing subsystem context diagrams
• used when the system is a large one
• For each subsystem, a context diagram is
  developed in which the other subsystems in
  interaction with this one are shown as
  terminators.
• Some subsystems can represent those developed by
  other organizations or the existing ones that the
  system has to interface to.
• System decomposition into subsystems
• used to manage the inherent complexity of
  large-scale software systems successfully
• A system should be decomposed into at most 72
  subsystems.
• A subsystem should be relatively independent of
  other subsystems but unity between the components
  within the subsystem should be high.

104
CODARTS - Step 1

• System decomposition into subsystems
• Guidelines for decomposition
• Aggregate object A subsystem supports
  information hiding at a more abstract level than
  an object, and so a subsystem (or aggregate
  object) is typically composed of a group of
  related objects that work together in a
  coordinated fashion.
• A subsystem deals with a subset of the external
  entities shown on the context diagram. An
  external entity should only interface to one
  subsystem.
• A data store should be encapsulated within one
  subsystem, which is responsible for managing the
  data store. A data store is never at interface
  between subsystems. A subsystem may encapsulate
  more than one data store.
• A control object (transformation) and all the
  data transformations that it directly controls