Objectives Software Design 1 Fundamentals of Design
Transcript Of Objectives Software Design 1 Fundamentals of Design
ecture 11 - Software Design Overview
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
1
Software Design – 1 Fundamentals of Design
Deriving a solution which satisfies the software requirements
Hamlet Chapter 11 Additional Reading
Fall 200
Objectives
To define design To introduce the design process To preview two design strategies
• Functional decomposition • Object Oriented design
To give a short overview of software architecture
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
2
What is Design?
Design
• The creative process of transforming a problem into a solution
• In our case, transforming a requirements specification into a detailed description of the software
Design
• The description of the solution • In our case, we will develop a software design
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
3
General Design Process
Identify nature of requirement
Requirements specification
Analyze and build model of problem
External requirements
Functional specification
Postulate a design solution
Designer’s model
Seek new solution
Functional specification
Mismatch between model and
requirements
Implement solution
Design “blueprints”
Validate solution
Designer’s
Refine design solution
Fall 2002
CSci 5801 - Dr. Mats Heimdahl model
4
Stages of Design
Problem understanding
• Look at the problem from different angles to discover the design requirements
Identify one or more solutions
• Evaluate possible solutions and choose the most appropriate depending on the designer's experience and available resources
Describe solution abstractions
• Use graphical, formal or other descriptive notations to describe the components of the design
Repeat process for each identified abstraction until the design is expressed in primitive terms
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
5
From Informal to Formal Design
Informal Design Outline
Fall 2002
Informal Design
Finished Design
CSci 5801 - Dr. Mats Heimdahl
More Formal Design
6
Sci 5801 - Dr. Mats Heimdahl
ecture 11 - Software Design Overview
Fall 200
Phases in the Design Process
Requirements Specification
Architectural Design
Abstract Specification
Design Activities
Interface Design
Component Design
Data Design
Algorithm Design
System Architecture
Software Specification
Interface Specification
Component Specification
Design Products
Data Specification
Algorithm Specification
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
7
Design Phases
Architectural design
• Identify sub-systems
Abstract specification
• Specify sub-systems
Interface design
• Describe sub-system interfaces
Component design
• Decompose subsystems into components
Data structure design
• Design data structures to hold problem data
Algorithm design
• Design algorithms for problem functions
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
8
Design Strategies
Functional design
• The system is designed from a functional viewpoint
• The system state is centralized and shared between the functions operating on that state
Object-oriented design
• The system is viewed as a collection of interacting objects
• The system state is de-centralized and each object manages its own state
• Objects may be instances of an object class and communicate by exchanging messages
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
13
Functional View of a Compiler
Source Program
Scan Source
Fall 2002
Tokens
Object Code
Build Symbol Table
Symbols
Symbol Table
Tokens
Analyze
Syntax Tree
Generate Code
Symbols
Error Indicator
Output Errors
Error Messages
CSci 5801 - Dr. Mats Heimdahl
14
Object-Oriented View of a Compiler
Source Scan Program
Token Stream
Add Check
Symbol Table
Get
Syntax Tree
Generate
Build Grammar Print Error Message
Abstract Code Generate
Object Code
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
15
Key Points
Design is a creative process Design activities include architectural
design, system specification, component design, data structure design and algorithm design Functional decomposition considers the system as a set of functional units Object-oriented decomposition considers the system as a set of objects
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
16
Sci 5801 - Dr. Mats Heimdahl
ecture 11 - Software Design Overview
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
17
Architectural Design
The High-Level Structure of a Software Intensive System
Fall 200
Architectural Parallels
Architects are the technical interface between the customer and the contractor building the system
A bad architectural design for a building cannot be rescued by good construction
• The same is true for software
There are specialist types of building and software architects
There are schools or styles of building and software architecture
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
18
Architectural Design Process
System structuring
• The system is decomposed into several principal sub-systems and communications between these sub-systems are identified
Control modeling
• A model of the control relationships between the different parts of the system is established
Modular decomposition
• The identified sub-systems are decomposed into modules
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
19
Architectural Models
Structure, control and modular decomposition may be based on a particular model or architectural style
However, most systems are heterogeneous in that different parts of the system are based on different models
The architectural model used affects the performance, robustness, distributability and maintainability of the system
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
21
System Structuring
Concerned with decomposing the system into interacting sub-systems
The architectural design is normally expressed as a block diagram presenting an overview of the system structure
More specific models showing how subsystems share data, are distributed, and interface with each other may also be developed
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
22
Sci 5801 - Dr. Mats Heimdahl
Packing Robot Control System
Vision System
Object Identification
System
Arm Controller
Packaging Selection System
Gripper Controller
Packing System
Conveyor Controller
ecture 11 - Software Design Overview
Fall 200
The Repository Model
Sub-systems must exchange data This may be done in two ways:
• Shared data is held in a central database or repository and may be accessed by all subsystems
• Each sub-system maintains its own database and passes data explicitly to other sub-systems
When large amounts of data are to be shared, the repository model of sharing is most commonly used
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
24
CASE Toolkit Architecture
Vision System
Design Editor
Code Generator
Design Translator
Project Repository
Program Editor
Design Analyzer
Report Generator
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
25
Repository Characteristics Model
Advantages
• Efficient way to share large amounts of data
• Sub-systems need not be concerned with how data is produced
• Centralized management e.g., backup, security, etc
• Sharing model is published as the repository schema
Disadvantages
• Sub-systems must agree on a repository data model
• Inevitably a compromise
• Data evolution is difficult and expensive
• No scope for specific management policies
• Difficult to distribute efficiently
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
26
Client-Server Architecture
Distributed system model which shows how data and processing is distributed across a range of components
Set of stand-alone servers which provide specific services such as printing, data management, etc
Set of clients which call on these services Network which allows clients to access
servers
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
27
Film and Picture Library
Client 1
Client 2
Client 3
Client 4
High Bandwidth Network
Catalogue Server
Video Server
Picture Server
Hypertext Server
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
28
Client-Server Characteristics
Advantages
• Distribution of data is straightforward
• Makes effective use of networked systems
• May require cheaper hardware
• Easy to add new servers or upgrade existing servers
Disadvantages
• No shared data model so sub-systems use different data organization
• Data interchange may be inefficient
• Redundant management in each server
• No central register of names and services
• It may be hard to find out what servers and services are available
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
29
Sci 5801 - Dr. Mats Heimdahl
ecture 11 - Software Design Overview
Fall 200
Abstract Machine Model
Used to model the interfacing of subsystems
Organizes the system into a set of layers (or abstract machines) each of which provide a set of services
Supports the incremental development of sub-systems in different layers
• When a layer interface changes, only the adjacent layer is affected
However, often difficult to structure systems in this way
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
30
Version Management System
Version Manager Object Manager Database System Operating System
Hardware
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
31
Control Models
Are concerned with the control flow between sub-systems
• Distinct from the system decomposition model
Centralized control
• One sub-system has overall responsibility for control and starts and stops other sub-systems
Event-based control
• Each sub-system can respond to externally generated events from other sub-systems or the system’s environment
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
32
Centralized Control
A control sub-system takes responsibility for managing the execution of other sub-systems
Call-return model
• Top-down subroutine model where control starts at the top of a subroutine hierarchy and moves downwards
• Applicable to sequential systems
Manager model
• Applicable to concurrent systems • One system component controls the stopping, starting
and coordination of other system processes
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
33
Call-Return Model
Main Program
Routine 1
Routine 2
Routine 3
Routine 1.1
Routine 1.2
Routine 3.1
Routine 3.2
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
34
Real-Time System Control
Sensor Processes Sensor Processes Sensor Processes Sensor Processes Sensor Processes
Actuator Processes Actuator Processes Actuator Processes Actuator Processes
System Controller
Control Processes Control Processes Control Processes Control Processes
User Interface
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
Fault Handler Fault Handler Fault Handler Fault Handler
35
Sci 5801 - Dr. Mats Heimdahl
ecture 11 - Software Design Overview
Fall 200
Event-Driven Systems
Driven by externally generated events where the timing of the event is out with the control of the sub-systems which process the event
Two principal event-driven models
• Broadcast models
• An event is broadcast to all sub-systems • Any sub-system which can handle the event may do so
• Interrupt-driven models
• Used in real-time systems where interrupts are detected by an interrupt handler and passed to some other component for processing
Other event driven models include, for example, spreadsheets
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
36
Broadcast Model
Effective in integrating sub-systems on different computers in a network
Sub-systems register an interest in specific events
• When these occur, control is transferred to the subsystem which can handle the event
Control policy is not embedded in the event and message handler
• Sub-systems decide on events of interest to them
However, sub-systems don’t know if or when an event will be handled
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
37
Selective Broadcasting
Subsystem 1
Subsystem 1
Subsystem 1
Event and Message Handler
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
38
Interrupt-Driven Systems
Used in real-time systems where fast response to an event is essential
There are known interrupt types with a handler defined for each type
Each type is associated with a memory location and a hardware switch causes transfer to its handler
Allows fast response but complex to program and difficult to validate
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
39
Interrupt-Driven Control
Interrupts
Interrupt Vector
Handler 1 Handler 2 Handler 3 Handler 4
Process 1
Fall 2002
Process 2
Process 3
CSci 5801 - Dr. Mats Heimdahl
Process 4
40
Domain-Specific Architectures
Architectural models which are specific to some application domain
Two types of domain-specific model
• Generic models which are abstractions from a number of real systems and which encapsulate the principal characteristics of these systems
• Reference models which are more abstract, idealized model
• Provide a means of information about that class of system and of comparing different architectures
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
41
Sci 5801 - Dr. Mats Heimdahl
ecture 11 - Software Design Overview
Fall 200
Generic Models
Compiler model is a well-known example although other models exist in more specialized application domains
• Lexical analyzer • Symbol table • Syntax analyzer • Syntax tree • Semantic analyzer • Code generator
Generic compiler model may be organized according to different architectural models
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
42
Compiler Model
Symbol Table
Lexical Analysis
Fall 2002
Semantic Analysis
Syntactic Analysis
CSci 5801 - Dr. Mats Heimdahl
Code Generation
43
Language Processing System
Lexical Analysis
Syntactic Analysis
Semantic Analysis
Pretty Printer
Editor
Fall 2002
Symbol Table
Grammar Definition
Output definition
Abstract Syntax Tree
Repository
CSci 5801 - Dr. Mats Heimdahl
Optimizer
Code Generation
44
Modular Decomposition
Another structural level where sub-systems are decomposed into modules
Two modular decomposition models covered in this class
• An object model where the system is decomposed into interacting objects
• A data-flow model where the system is decomposed into functional modules which transform inputs to outputs
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
45
Key Points
The software architect is responsible for deriving a structural system model, a control model and a sub-system decomposition model
Large systems rarely conform to a single architectural model
System decomposition models include repository models, client-server models and abstract machine models
Control models include centralized control and event-driven models
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
46
Key Points
Modular decomposition models include data-flow and object models
Domain specific architectural models are abstractions over an application domain
• They may be constructed by abstracting from existing systems or may be idealized reference models
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
47
Sci 5801 - Dr. Mats Heimdahl
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
1
Software Design – 1 Fundamentals of Design
Deriving a solution which satisfies the software requirements
Hamlet Chapter 11 Additional Reading
Fall 200
Objectives
To define design To introduce the design process To preview two design strategies
• Functional decomposition • Object Oriented design
To give a short overview of software architecture
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
2
What is Design?
Design
• The creative process of transforming a problem into a solution
• In our case, transforming a requirements specification into a detailed description of the software
Design
• The description of the solution • In our case, we will develop a software design
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
3
General Design Process
Identify nature of requirement
Requirements specification
Analyze and build model of problem
External requirements
Functional specification
Postulate a design solution
Designer’s model
Seek new solution
Functional specification
Mismatch between model and
requirements
Implement solution
Design “blueprints”
Validate solution
Designer’s
Refine design solution
Fall 2002
CSci 5801 - Dr. Mats Heimdahl model
4
Stages of Design
Problem understanding
• Look at the problem from different angles to discover the design requirements
Identify one or more solutions
• Evaluate possible solutions and choose the most appropriate depending on the designer's experience and available resources
Describe solution abstractions
• Use graphical, formal or other descriptive notations to describe the components of the design
Repeat process for each identified abstraction until the design is expressed in primitive terms
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
5
From Informal to Formal Design
Informal Design Outline
Fall 2002
Informal Design
Finished Design
CSci 5801 - Dr. Mats Heimdahl
More Formal Design
6
Sci 5801 - Dr. Mats Heimdahl
ecture 11 - Software Design Overview
Fall 200
Phases in the Design Process
Requirements Specification
Architectural Design
Abstract Specification
Design Activities
Interface Design
Component Design
Data Design
Algorithm Design
System Architecture
Software Specification
Interface Specification
Component Specification
Design Products
Data Specification
Algorithm Specification
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
7
Design Phases
Architectural design
• Identify sub-systems
Abstract specification
• Specify sub-systems
Interface design
• Describe sub-system interfaces
Component design
• Decompose subsystems into components
Data structure design
• Design data structures to hold problem data
Algorithm design
• Design algorithms for problem functions
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
8
Design Strategies
Functional design
• The system is designed from a functional viewpoint
• The system state is centralized and shared between the functions operating on that state
Object-oriented design
• The system is viewed as a collection of interacting objects
• The system state is de-centralized and each object manages its own state
• Objects may be instances of an object class and communicate by exchanging messages
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
13
Functional View of a Compiler
Source Program
Scan Source
Fall 2002
Tokens
Object Code
Build Symbol Table
Symbols
Symbol Table
Tokens
Analyze
Syntax Tree
Generate Code
Symbols
Error Indicator
Output Errors
Error Messages
CSci 5801 - Dr. Mats Heimdahl
14
Object-Oriented View of a Compiler
Source Scan Program
Token Stream
Add Check
Symbol Table
Get
Syntax Tree
Generate
Build Grammar Print Error Message
Abstract Code Generate
Object Code
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
15
Key Points
Design is a creative process Design activities include architectural
design, system specification, component design, data structure design and algorithm design Functional decomposition considers the system as a set of functional units Object-oriented decomposition considers the system as a set of objects
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
16
Sci 5801 - Dr. Mats Heimdahl
ecture 11 - Software Design Overview
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
17
Architectural Design
The High-Level Structure of a Software Intensive System
Fall 200
Architectural Parallels
Architects are the technical interface between the customer and the contractor building the system
A bad architectural design for a building cannot be rescued by good construction
• The same is true for software
There are specialist types of building and software architects
There are schools or styles of building and software architecture
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
18
Architectural Design Process
System structuring
• The system is decomposed into several principal sub-systems and communications between these sub-systems are identified
Control modeling
• A model of the control relationships between the different parts of the system is established
Modular decomposition
• The identified sub-systems are decomposed into modules
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
19
Architectural Models
Structure, control and modular decomposition may be based on a particular model or architectural style
However, most systems are heterogeneous in that different parts of the system are based on different models
The architectural model used affects the performance, robustness, distributability and maintainability of the system
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
21
System Structuring
Concerned with decomposing the system into interacting sub-systems
The architectural design is normally expressed as a block diagram presenting an overview of the system structure
More specific models showing how subsystems share data, are distributed, and interface with each other may also be developed
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
22
Sci 5801 - Dr. Mats Heimdahl
Packing Robot Control System
Vision System
Object Identification
System
Arm Controller
Packaging Selection System
Gripper Controller
Packing System
Conveyor Controller
ecture 11 - Software Design Overview
Fall 200
The Repository Model
Sub-systems must exchange data This may be done in two ways:
• Shared data is held in a central database or repository and may be accessed by all subsystems
• Each sub-system maintains its own database and passes data explicitly to other sub-systems
When large amounts of data are to be shared, the repository model of sharing is most commonly used
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
24
CASE Toolkit Architecture
Vision System
Design Editor
Code Generator
Design Translator
Project Repository
Program Editor
Design Analyzer
Report Generator
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
25
Repository Characteristics Model
Advantages
• Efficient way to share large amounts of data
• Sub-systems need not be concerned with how data is produced
• Centralized management e.g., backup, security, etc
• Sharing model is published as the repository schema
Disadvantages
• Sub-systems must agree on a repository data model
• Inevitably a compromise
• Data evolution is difficult and expensive
• No scope for specific management policies
• Difficult to distribute efficiently
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
26
Client-Server Architecture
Distributed system model which shows how data and processing is distributed across a range of components
Set of stand-alone servers which provide specific services such as printing, data management, etc
Set of clients which call on these services Network which allows clients to access
servers
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
27
Film and Picture Library
Client 1
Client 2
Client 3
Client 4
High Bandwidth Network
Catalogue Server
Video Server
Picture Server
Hypertext Server
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
28
Client-Server Characteristics
Advantages
• Distribution of data is straightforward
• Makes effective use of networked systems
• May require cheaper hardware
• Easy to add new servers or upgrade existing servers
Disadvantages
• No shared data model so sub-systems use different data organization
• Data interchange may be inefficient
• Redundant management in each server
• No central register of names and services
• It may be hard to find out what servers and services are available
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
29
Sci 5801 - Dr. Mats Heimdahl
ecture 11 - Software Design Overview
Fall 200
Abstract Machine Model
Used to model the interfacing of subsystems
Organizes the system into a set of layers (or abstract machines) each of which provide a set of services
Supports the incremental development of sub-systems in different layers
• When a layer interface changes, only the adjacent layer is affected
However, often difficult to structure systems in this way
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
30
Version Management System
Version Manager Object Manager Database System Operating System
Hardware
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
31
Control Models
Are concerned with the control flow between sub-systems
• Distinct from the system decomposition model
Centralized control
• One sub-system has overall responsibility for control and starts and stops other sub-systems
Event-based control
• Each sub-system can respond to externally generated events from other sub-systems or the system’s environment
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
32
Centralized Control
A control sub-system takes responsibility for managing the execution of other sub-systems
Call-return model
• Top-down subroutine model where control starts at the top of a subroutine hierarchy and moves downwards
• Applicable to sequential systems
Manager model
• Applicable to concurrent systems • One system component controls the stopping, starting
and coordination of other system processes
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
33
Call-Return Model
Main Program
Routine 1
Routine 2
Routine 3
Routine 1.1
Routine 1.2
Routine 3.1
Routine 3.2
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
34
Real-Time System Control
Sensor Processes Sensor Processes Sensor Processes Sensor Processes Sensor Processes
Actuator Processes Actuator Processes Actuator Processes Actuator Processes
System Controller
Control Processes Control Processes Control Processes Control Processes
User Interface
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
Fault Handler Fault Handler Fault Handler Fault Handler
35
Sci 5801 - Dr. Mats Heimdahl
ecture 11 - Software Design Overview
Fall 200
Event-Driven Systems
Driven by externally generated events where the timing of the event is out with the control of the sub-systems which process the event
Two principal event-driven models
• Broadcast models
• An event is broadcast to all sub-systems • Any sub-system which can handle the event may do so
• Interrupt-driven models
• Used in real-time systems where interrupts are detected by an interrupt handler and passed to some other component for processing
Other event driven models include, for example, spreadsheets
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
36
Broadcast Model
Effective in integrating sub-systems on different computers in a network
Sub-systems register an interest in specific events
• When these occur, control is transferred to the subsystem which can handle the event
Control policy is not embedded in the event and message handler
• Sub-systems decide on events of interest to them
However, sub-systems don’t know if or when an event will be handled
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
37
Selective Broadcasting
Subsystem 1
Subsystem 1
Subsystem 1
Event and Message Handler
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
38
Interrupt-Driven Systems
Used in real-time systems where fast response to an event is essential
There are known interrupt types with a handler defined for each type
Each type is associated with a memory location and a hardware switch causes transfer to its handler
Allows fast response but complex to program and difficult to validate
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
39
Interrupt-Driven Control
Interrupts
Interrupt Vector
Handler 1 Handler 2 Handler 3 Handler 4
Process 1
Fall 2002
Process 2
Process 3
CSci 5801 - Dr. Mats Heimdahl
Process 4
40
Domain-Specific Architectures
Architectural models which are specific to some application domain
Two types of domain-specific model
• Generic models which are abstractions from a number of real systems and which encapsulate the principal characteristics of these systems
• Reference models which are more abstract, idealized model
• Provide a means of information about that class of system and of comparing different architectures
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
41
Sci 5801 - Dr. Mats Heimdahl
ecture 11 - Software Design Overview
Fall 200
Generic Models
Compiler model is a well-known example although other models exist in more specialized application domains
• Lexical analyzer • Symbol table • Syntax analyzer • Syntax tree • Semantic analyzer • Code generator
Generic compiler model may be organized according to different architectural models
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
42
Compiler Model
Symbol Table
Lexical Analysis
Fall 2002
Semantic Analysis
Syntactic Analysis
CSci 5801 - Dr. Mats Heimdahl
Code Generation
43
Language Processing System
Lexical Analysis
Syntactic Analysis
Semantic Analysis
Pretty Printer
Editor
Fall 2002
Symbol Table
Grammar Definition
Output definition
Abstract Syntax Tree
Repository
CSci 5801 - Dr. Mats Heimdahl
Optimizer
Code Generation
44
Modular Decomposition
Another structural level where sub-systems are decomposed into modules
Two modular decomposition models covered in this class
• An object model where the system is decomposed into interacting objects
• A data-flow model where the system is decomposed into functional modules which transform inputs to outputs
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
45
Key Points
The software architect is responsible for deriving a structural system model, a control model and a sub-system decomposition model
Large systems rarely conform to a single architectural model
System decomposition models include repository models, client-server models and abstract machine models
Control models include centralized control and event-driven models
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
46
Key Points
Modular decomposition models include data-flow and object models
Domain specific architectural models are abstractions over an application domain
• They may be constructed by abstracting from existing systems or may be idealized reference models
Fall 2002
CSci 5801 - Dr. Mats Heimdahl
47
Sci 5801 - Dr. Mats Heimdahl