Transcript 10_sw - Lyle School of Engineering

Agenda for software
1. Expectations
2. Object-oriented approach
3. UML
4. Partitioning
5. Interfaces
6. Throughput and memory
7. Design elements
10. Software
1
1. Expectations
Problem 1
Approaches to problem 1
Problem 2
Approaches to problem 2
10. Software
1. Expectations
2
Problem 1
Requirement
• Provide a straight-line curve fit to a set of
N measurements
Higher-product viewpoint
• Provide a turn-key solution that meets the
requirement
Software product viewpoint
• Provide a solution that meets the
equations provided by the higher-product
10. Software
1. Expectations
3
Approaches to problem 1
System
System
CSCI
Algorithms
Algorithms
CSCI
Higher-product viewpoint -workable depends upon
CSCI skill level
Lower-product viewpoint -workable depends upon
CSCI skill level
The algorithm document can be located in either
place depending upon the skill of
the lower-product developer
10. Software
1. Expectations
4
Problem 2
Requirement
• Provide a method for describing
requirements for each lower-level
product
Higher viewpoint
• One higher-product process
Lower-product viewpoint
• Each lower-product process defines
higher-order process
• Example -- System requirements shall
be in VHDL or UML
10. Software
1. Expectations
5
Approaches to problem 2
System
spec
HWCI
System
spec
CSCI
spec
VHDL UML
Algorithms
Higher-product viewpoint
HWCI
CSCI
math
Algorithms
Lower-product viewpoint -multiple system views and
multiple languages --awkward
Having a single system viewpoint and language
is less awkward
10. Software
1. Expectations
6
2. Object-oriented (OO) approach
Reasons for OO approach
Objects
Communications
Classes
Observation
10. Software
2. Object-oriented (OO) approach
7
Reasons for OO approach
Merges data and methods that
• Reduces coupling
• Provides reusability
Allows use of OO design tools, specifically
• Design tools such as Object-Team and
COOLJEX
10. Software
2. Object-oriented (OO) approach
8
Objects
An object is an entity that has
• State -- the value of all the attributes at a
given time
• Behavior -- the actions and reactions of the
object in response to external input
• Identity -- distinguishes object from other
objects
an object is an instantiation of a class
10. Software
2. Object-oriented (OO) approach
9
Communications (1 of 4)
Categories of behavior
• Clients -- active objects that instigate an
interaction
• Servers -- passive objects that wait for other
objects to require their services
• Agents -- objects that can be either be either
active or passive
10. Software
2. Object-oriented (OO) approach
10
Communications (2 of 4)
Message content
• May carry data and/or control
Message types
• Constructors -- create objects
• Destructors -- delete objects
• Selectors -- return all or part of the state
• Modifiers -- changes all or part of the state
• Iterators -- visits the state of an object
10. Software
2. Object-oriented (OO) approach
11
Communications (3 of 4)
Synchronization types
• Simple broadcast -- message goes form the
active object to the passive object
• Synchronous broadcast -- sender is blocked
until recipient accepts the message
• Rendezvous broadcast -- recipient must go
into a wait-for-message mode before sender
can send message
10. Software
2. Object-oriented (OO) approach
12
Communications (4 of 4)
Synchronization types (continued)
• Timed broadcast -- sender waits a
period of time for acknowledgment
• Asynchronous broadcast -- sender
sends message without knowing when
or if the recipient will process message
10. Software
2. Object-oriented (OO) approach
13
Classes (1 of 4)
Definition
• A class is the definition of a set of
objects
• It specifies the data structure and
possible operational methods that apply
to each of the objects
• Class refers to the software
implementation of an object type
10. Software
2. Object-oriented (OO) approach
14
Classes (2 of 4)
Associations
• The bi-directional connection between
classes
• Links between objects are
instantiations of associations between
classes
10. Software
2. Object-oriented (OO) approach
15
Classes (3 of 4)
object
a link
Ms Smith: resident
object
a link
Ms Jones: resident
object
a link
Mr. Hall: resident
object
New York: city
object
Pittsburgh: city
a link
class
10. Software
city
Mr. Wilson: resident object
resident
2. Object-oriented (OO) approach
class
16
Classes (4 of 4)
Inheritance
• A technique to construct a class from
one or more classes
• Child classes inherit characteristics
from their parent classes
10. Software
2. Object-oriented (OO) approach
17
Observation
Hardware and systems tend to be objectoriented already so applying OO to them
often results in renaming things and
concepts with no particular advantage
10. Software
2. Object-oriented (OO) approach
18
3. UML
Introduction
(1) Use diagrams
(2) Sequence diagrams
(3) Object diagrams
(4) Collaboration diagrams
(5) Class diagrams
(6) State-chart diagrams
(7) Activity diagrams
(8) Deployment diagrams
(9) Component diagrams
10. Software
3. UML
19
Introduction (1 of 3)
Goals
• Represent complete systems using
object-oriented concepts
• Couple concepts and executable code
• Account for scaling factors needed in
complex systems
• Make language usable by humans &
computers
10. Software
3. UML
20
Introduction (2 of 3)
Practice
• Useful
• Complicated
• Difficult for customer and managers to use
10. Software
3. UML
21
Introduction (3 of 3)
Diagrams
UML
non-UML
•Use diagrams
•Sequence diagrams
•Object diagrams
•Collaboration diagrams
•Class diagrams
•.State-chart diagrams
•.Activity diagrams
•Deployment diagrams
•Component diagrams
10. Software
3. UML
•usage
•con ops
•physical
•interface
•physical
•decision table
•con ops
•physical
•physical
22
(1) Use-case diagrams (1 of 7)
Definition
• Use-case diagrams describe the
behavior of a system from the user
standpoint by using actions and
reactions
• Use-case diagrams are usage diagrams
10. Software
3. UML
23
(1) Use-case diagrams (2 of 7)
Use
• Use-case diagrams provides a
technique for specifying requirements
that was missing in early objet-oriented
methods
• Use-case provides an approach for
covering product development from
requirements to implementation
• Defining actors and use-cases defines
the system
10. Software
3. UML
24
(1) Use-case diagrams (3 of 7)
Example
• Use-case model Includes actors,
system, and the use cases
• System functionality determined by
requirements of each actor as
expressed in use cases
system
use-case 1
actor A
10. Software
use-case 2
3. UML
actor B
25
(1) Use-case diagrams (4 of 7)
Use cases
• Use cases are lists of activities the
actor performs
• The activities are textual sentences
10. Software
3. UML
26
(1) Use-case diagrams (5 of 7)
Actors
• An actor represents the role played by a
person or thing that interacts with the
system
• Actors determined by observing the main
users of the system and other systems that
interact with the system
• A single physical person may play the role
of several actors. Several people may play
the same role and be a single actor
10. Software
3. UML
27
(1) Use-case diagrams (6 of 7)
Actors (continued)
• An actor represents the role played by a
person or thing that interacts with the
system
• Actors determined by observing the main
users of the system and other systems that
interact with the system
• A single physical person may play the role
of several actors. Several people may play
the same role and be a single actor
10. Software
3. UML
28
(1) Use-case diagrams (7 of 7)
Application to verification
• Use cases may support verification
• Engineers may apply probabilities to
each use case and then exercise the
product statistically employing the use
cases
10. Software
3. UML
29
(2) Sequence diagrams (1 of 3)
Definition
• Sequence diagram display interactions
in time among objects
• Sequence diagrams are a form of timesequence diagrams
10. Software
3. UML
30
(2) Sequence diagrams (2 of 3)
Uses
• Sequence diagram focuses on showing
interactions
• Unlike collaboration diagram. Sequence
diagram does not explicitly show the
context
• Sequence diagrams represent an
interaction between objects that
focuses on messages being broadcast
• They are used to document use-cases
and to define classes
10. Software
3. UML
31
(2) Sequence diagrams (3 of 3)
Example
example
synchronous and
asynchronous
messages
example
transmission
delay
example of
an object sending
message to itself
object A
object B
synchronous msg
asynchronous msg
object A
object B
message
object A
reflexive
message
10. Software
3. UML
32
(3) Object diagrams (1 of 3)
Definition
• Object diagrams illustrate objects and
links. They are sometimes called
instance diagrams.
• Object diagrams are physical diagrams
• Objects are represented as rectangles
with the either the name of the object,
the name and class of the object, or the
class
10. Software
3. UML
33
(3) Object diagrams (2 of 3)
Use
• Object diagrams describe the system as
a set of nodes connected by links
• They are a static structure
• They are used to show a context
10. Software
3. UML
34
(3) Object diagrams
Example
:login_display
:login
:configuration_display
supervisor:list_of_people
10. Software
3. UML
35
(4) Collaboration diagrams (1 of 3)
Definition
• Collaboration diagram shows interaction
between objects
10. Software
3. UML
36
(4) Collaboration diagrams (2 of 3)
Use
• It displays a static relationship showing
how objects collaborate
10. Software
3. UML
37
(4) Collaboration diagrams (3 of 3)
Example
1. display
2. read
4. hide
:login_display
:login
5. display
:configuration_display
10. Software
3. correct password
supervisor:list_of_people
3. UML
38
(5) Class diagrams ( 1of 3)
Definition
• Class diagrams show the static
structure of the system in terms of
classes and relations between classes
• Class diagrams are physical diagrams
10. Software
3. UML
39
(5) Class diagrams (2 of 3)
Use
• They’re often determined by
generalizing the object diagram
• A class diagram doesn’t describe
anything specific about links
10. Software
3. UML
40
(5) Class diagrams (3 of 3)
Example
login_display
login
configuration_display
list_of_people
10. Software
3. UML
41
(6) State-chart diagrams (1 of 3)
Definition
• A state chart diagram represents a state
machine
10. Software
3. UML
42
(6) State-chart diagrams (2 of 3)
Use
• Used to show logical control among
objects and messages
10. Software
3. UML
43
(6) State-chart diagrams (3 of 3)
Example
login
read name
name read
read password
error
password read
verify
connection
10. Software
3. UML
44
(7) Activity diagrams (1 of 3)
Definition
• An activity diagram is a variant of a
state chart
• It is simpler than a state chart and
doesn’t need to have states
10. Software
3. UML
45
(7) Activity diagrams (2 of 3)
Use
• It helps to expand use-cases
10. Software
3. UML
46
(7) Activity diagrams (3 of 3)
Example
teacher
student
board
teach
learn
supervise
exams
take
exams
evaluate
10. Software
3. UML
47
(8) Deployment diagrams (1 of 3)
Definition
• A deployment diagram shows the
physical layout of hardware nodes and
the distribution of executable programs
to the nodes
10. Software
3. UML
48
(8) Deployment diagrams (2 of 3)
Use
• Nodes typically represented as cubes
10. Software
3. UML
49
(8) Deployment diagrams (3 of 3)
Example
comm
modem
10. Software
PC
(control
sw)
3. UML
IO port
Disk
(load
objects)
50
(9) Component diagrams (1 of 3)
Definition
• A component diagram describes
software components at the time of
implementation
10. Software
3. UML
51
(9) Component diagrams (2 of 3)
Use
• A component has a body and a
specification. In C++, the specification
is a file with .h extension and the body
is a file with extension .cpp
10. Software
3. UML
52
(9) Component diagrams (3 of 3)
Example
body
10. Software
3. UML
specification
53
4. Partitioning
Requirement
Criteria
Choosing criteria
Special considerations
Most common criteria
Cost as a criterion
10. Software
4. Partitioning
54
Requirement
Requirement
• Common to have no customer
requirement for partitioning
• Operating system and COTS are
exceptions although military emphasis
on reuse comes and goes
Design
• Developer chooses partitioning
10. Software
4. Partitioning
55
Criteria
Chose partitioning criteria
• Similarity to something done before
• Customer satisfaction
• Cost
• Risk
• Schedule
• Performance
• Reusability and COTS
• Functional cohesion and uncoupling
• Throughput and memory
• Other
10. Software
4. Partitioning
56
Choosing criteria
Choice of criteria depends upon what is
important to the product being developed
Criteria may vary from system to system
and may vary among products of the same
type within a system
10. Software
4. Partitioning
57
Special considerations
Application
Parallel processing
Available resources
Shared resources
Available people
Subcontracting
10. Software
4. Partitioning
58
Most common criteria
Functional cohesion and uncoupling
Throughput and memory
10. Software
4. Partitioning
59
Cost as a criterion
Although cost is a dominant criterion in
systems and hardware, it is less dominant
in software because the product of
software is lines of code, which doesn’t
have the costing problems of hardware
10. Software
4. Partitioning
60
5. Interfaces
Introduction
Examples
10. Software
5. Interfaces
61
Introduction
Interface definition -- The mechanism
whereby two products interact
Types of interfaces
• Physical interfaces
• Data interfaces
10. Software
5. Interfaces
62
Introduction (2 of 3)
Considerations for physical interfaces
• Physical characteristics
• Alignment
• Self test
• Instrumentation
• Data extraction
• Verification
• Format standards
• Reuse
10. Software
5. Interfaces
63
Introduction (3 of 3)
Considerations for data interfaces
• Time tagging
• Self test
• Instrumentation
• Data extraction
• Verification
• Format standards
• Reuse
• Throughput
10. Software
5. Interfaces
64
Example -- mechanical alignment
subsystem 1
frame
mechanical
subsystem 2
components
 Key considerations
 Alignment
 Vibration
 Thermal expansion
 Installation
 Maintenance
10. Software
5. Interfaces
65
Example -- cooling
subsystem 1
generates
heat
thermal
subsystem 2
heat and cools
 Subsystems coupled
 Subsystem 2 may not be able to
control heating and cooling
10. Software
5. Interfaces
66
Example -- standard busses
DMA
RS-232
MIL-STD-1503
FDDI
HIPPI
Fibre channel
10. Software
5. Interfaces
67
Example -- LANS/MANS/WANS (1 of 3)
LAN
• Local area network
• Privately owned
• Short distance -- building, campus, few
miles
• Ethernet often used
10. Software
5. Interfaces
68
Example -- LANS/MANS/WANS (2 of 3)
MAN
• Metropolitan area network
• Bigger version of LAN
• Private or public
• Several buildings, a city
• Distributed queue dual bus often used
10. Software
5. Interfaces
69
Example -- LANS/MANS/WANS (3 of 3)
WAN
• Wide area network
• Large areas, countries, continents
• Complicated arrangement of subnets
10. Software
5. Interfaces
70
Example -- ethernet (1 of 3)
IEEE 802.3: Ethernet
Used with LANs
Protocol
• When a station wants to transmit, it
listens to the cable
• If the cable is busy, it waits; otherwise it
transmits
• If two stations transmit simultaneously,
both stop, wait a random time, and then
repeat the process again
10. Software
5. Interfaces
71
Example -- ethernet (2 of 3)
repeater
linear
10. Software
spine
tree
5. Interfaces
repeater
72
Example -- ethernet (3 of 3)
name
cable
length*
nodes*
nodes*
10Base5
thin coax
500 m
100
good for backbones
10Base2
thin coax
200 m
30
cheapest
10Base-T twisted pair
100 m
1024
easy to maintain
10Base-F
2000 m
1024
best between buildings
fiber optics
* per segment
10. Software
5. Interfaces
73
Example -- token bus
IEEE Standard 802.4: Token Bus
Used with LANs
Physical
• Linear, 75 ohm broadband cable
• 1.5 and 10 Mbps
• More complicated than ethernet
10. Software
5. Interfaces
74
Example -- token bus
Protocol
• Logically arranged as a ring
• Highest numbered station ma send first
• Then passes token
• Token propagates around ring
• Only holder of token can transmit
• No collisions occur
10. Software
5. Interfaces
75
Example -- token bus
station
broadband
coax cable
logical ring
10. Software
5. Interfaces
76
Example -- token ring (1 of 3)
IEEE Standard 802.5: Token Ring
Used with LANs
Physical
• Twisted, shielded pairs
• 4 Mbps
• Manchester coding
10. Software
5. Interfaces
77
Example -- token ring (2 of 3)
Protocol
• Special bit pattern, the token, circulates
when all stations are idle
• Station wanting to transmit must seize
the token and remove before
transmitting
• Station replaces ring after transmission
10. Software
5. Interfaces
78
Example -- token ring (3 of 3)
ring interface
unidirectional ring
station
one-bit delay at each station
10. Software
5. Interfaces
79
Example -- DQDB (1 of 6)
IEEE Standard 802.6: Distributed Queue
Dual Bus
Used with MANs
Physical layout
• Two parallel cables up to 160 km each
• 44,736 Mbits/sec (T3)
• Cells
•
•
•
•
10. Software
53 bytes
44 bytes of data
1 busy bit
1 request bit
5. Interfaces
80
Example -- DQDB (2 of 6)
A-bus
head
Station
A
Station
B
Station
C
Station
D
Station
E
RC=0
CD=0
RC=0
CD=0
RC=0
CD=0
RC=0
CD=0
RC=0
CD=0
B-bus
head
Initial conditions
Initially, request counter (RC) and CD are zero for stations A-E
10. Software
5. Interfaces
81
Example -- DQDB (3 of 6)
A-bus
head
Station
A
Station
B
Station
C
Station
D
Station
E
RC=1
CD=0
RC=1
CD=0
RC=1
CD=0
RC=0
CD=0*
RC=0
CD=0
B-bus
head
request
transmits
cell
D makes a request
Stations upstream from D on A-bus increment RC
10. Software
5. Interfaces
82
Example -- DQDB (4 of 6)
head
Station
A
Station
B
Station
C
Station
D
Station
E
RC=2
CD=0
RC=0
CD=1*
RC=1
CD=0
RC=0
CD=0*
RC=0
CD=0
B-bus
request
head
transmits
cell
B makes a request
Stations upstream from B on A-bus increment RC.
B moves RC to CD
10. Software
5. Interfaces
83
Example -- DQDB (5 of 6)
data
head
xmits
cell
Station
A
Station
B
Station
C
Station
D
Station
E
RC=1
CD=0
RC=0
CD=1*
RC=1
CD=0
RC=0
CD=0
RC=0
CD=0
B-bus
head
D sends data
Stations upstream from D on A-bus decrement RC and CD
10. Software
5. Interfaces
84
Example -- DQDB (6 of 6)
data
head
xmits
cell
Station
A
Station
B
Station
C
Station
D
Station
E
RC=0
CD=0
RC=0
CD=0
RC=1
CD=0
RC=0
CD=0
RC=0
CD=0
B-bus
head
B sends data
Stations upstream from B on A-bus decrement RC and CD
10. Software
5. Interfaces
85
Example -- OSI messaging (1 of 9)
1
application
application protocol
application
APDU
presentation
PPDU
session
SPDU
transport
TPDU
presentation protocol
2
presentation
3
session
4
transport
session protocol
transport protocol
communication subnet
5
network
network
network
network
packet
6
data link
data link
data link
data link
frame
7
physical
physical
physical
physical
bit
Host A
router
router
Host B
Tanenbaum: Computer Networks
10. Software
5. Interfaces
86
Example -- OSI messaging (2 of 9)
Physical layer
• Transmits raw bits over a
communication channel
• Deals with mechanical, electrical, and
procedural interfaces
• Includes transmission medium
10. Software
5. Interfaces
87
Example -- OSI messaging (3 of 9)
Data link layer
• Transforms raw data facility into a line that
is free of undetected transmission errors
• Controls sequence
• Breaks data into data frames
• Transmits frames sequentially
• Acknowledges frames sent by sender
10. Software
5. Interfaces
88
Example -- OSI messaging (4 of 9)
Data link layer (continued)
• Creates and recognizes frame or packet
boundaries
• Handles damaged frames by retransmission
and resolving duplication
• Regulates traffic loads
• Handles simplex, half-duplex, duplex, and
broadcast operation
• Controls access
10. Software
5. Interfaces
89
Example -- OSI messaging (5 of 9)
Network layer
• Controls operation of the subnet
• Routes packets from source to destination
• Regulates traffic
• Keeps count of traffic flow for billing
purposes
• Allows different networks to be
interconnected
• Resolves addressing, size, and protocols
10. Software
5. Interfaces
90
Example -- OSI messaging (6 of 9)
Transport layer
• Accepts data from session layer, breaks
data into smaller layers, sends data to
network layer, and ensures all pieces
arrive at other end
• Creates network session for each
transport session; although may use
more than one network session or
multiplex sessions
10. Software
5. Interfaces
91
Example -- OSI messaging (7 of 9)
Session layer
• Allows users on different machines to
establish sessions
• Resolves conflicts when two sessions
attempt to do same operation at the
same time
• Manages flow of large sets of data
10. Software
5. Interfaces
92
Example -- OSI messaging (8 of 9)
Presentation layer
• Handles functions that are used
commonly so that each user doesn’t
need to deal with them
• Handles syntax of data
• Converts nonstandard data structures
into form needed by lower layers
10. Software
5. Interfaces
93
Example -- OSI messaging (9 of 9)
Application layer
• Interfaces between session layer and
user
• Examples
• File transfer
• Terminal services
10. Software
5. Interfaces
94
Example -- TCP/IP messaging
OSI
TCP/IP
application
presentation
session
transport
network
data link
physical
Tanenbaum: Computer Networks
10. Software
application
n/a
transport
network
host-to-network
5. Interfaces
95
Example -- TCP/IP messaging
application
TELNET
FTP
SMTP
TCP
UDP
DNS
transport
protocols
network
IP
physical data link
networks
10. Software
ARPANET
SATNET
5. Interfaces
packet
radio
LAN
96
Example -- OS interfaces (1 of 2)
MS DOS
• Interfaces between user and basic
input/output system (BIOS)
• Vendor dependent
10. Software
5. Interfaces
97
Example -- OS interfaces (2 of 2)
POSIX
• Interfaces between user and OS kernel
• Broader than typical UNIX kernel
interface that are usually library
routines
• Vendor independent
• Supports open systems
10. Software
5. Interfaces
98
6. Throughput and memory
Throughput
Memory
10. Software
6. Throughput and memory
99
Throughput (1 of 5)
Example requirements
• All general purpose computers shall have 50
percent spare throughput capacity
• All digital signal processors shall have 25
percent spare throughput capacity
• All firmware shall have 30 percent spare
throughput capacity
• All communication channels shall have 40
percent spare throughput capacity
• All communication channels shall have 20
percent spare terminals
10. Software
6. Throughput and memory
100
Throughput (2 of 5)
There shall be 100 % spare throughput capacity
reference
capacity
throughput-used
usage
common
common
capacity
100 MOPS
100 MOPS
throughput-used
50 MOPS
50 MOPS
spare throughput 50 MOPS
50 MOPS
percent spare
50 percent
100 percent
pass/fail
fail
pass
There are two ways of interpreting spare throughput
capacity based on reference used as denominator
10. Software
6. Throughput and memory
101
Throughput (3 of 5)
Availability of spare throughput
• Available at the highest-priorityapplication level -- most common
• Available at the lowest-priority-application
level -- common
• Available in proportion to the times spent
by each segment of the application -- not
common
Assuming the spare throughput is available at the
highest-priority-application level is
the most common assumption
10. Software
6. Throughput and memory
102
Throughput (4 of 5)
Throughput capacity is most often verified
by test
• Analysis -- not common
• Time event simulation -- not common
• Execution monitor -- common but
requires instrumentation code and
hardware
10. Software
6. Throughput and memory
103
Throughput (5 of 5)
• Execution of a code segment that uses
at least the number of spare throughput
instructions required -- not common but
avoids instrumentation
Instrumenting the software to monitor runtime or
inserting a code segment that uses at least the
spare throughput are two methods of
verifying throughput
10. Software
6. Throughput and memory
104
Memory (1 of 3)
Example requirements
• All general purpose computers shall have 50
percent spare memory capacity
• All digital signal processors (DSPs) shall
have 25 percent spare on-chip memory
capacity
• All digital signal processors shall have 30
percent spare off-chip memory capacity
• All mass storage units shall have 40 percent
spare memory capacity
• All firmware shall have 20 percent spare
memory capacity
10. Software
6. Throughput and memory
105
Memory (2 of 3)
There shall be 50 % spare memory capacity
reference
capacity
memory-used
usage
common
less-common
capacity
100 Mbytes
100 Mbytes
memory-used
60 Mbytes
60 Mbytes
spare memory
40 Mbytes
40 Mbytes
percent spare
40 percent
67 percent
pass/fail
fail
pass
There are at least two ways of interpreting the meaning
of spare memory capacity based on the reference used
as the denominator in computing the percentage
10. Software
6. Throughput and memory
106
Memory (3 of 3)
Memory capacity is most often verified by
analysis of load files
Memory capacity is frequently tracked as
a technical performance parameter (TPP)
Contractors don’t like to consider that
firmware is software because firmware is
often not developed using software
development methodology and firmware is
not as likely to grow in the future
10. Software
6. Throughput and memory
107
7. Design elements
Introduction
Software
Hardware tools
Hardware
10. Software
7. Design elements
108
Introduction
There are commercial, off-the-shelf
products and tools to support software
design and development
Use of these tools increase productivity
by shortening development time and
providing reliable products
10. Software
7. Design elements
109
Software
System engineering tools
Real-time operating systems, kernels, and
executives
Compiler and language products
Debuggers
Libraries
Communications packages
Embedded internet packages
Java language products
Data bases
10. Software
7. Design elements
110
Hardware tools
In-circuit emulators
BDM/JTAG-based emulators
ROM emulators
Oscilloscopes
Logic and bus analyzers
10. Software
7. Design elements
111
Hardware
Integrated circuits
• Microcontrollers and embedded
microprocessors
• Digital signal processors
• Flash memory
Board-level products
• Single-board computers
10. Software
7. Design elements
112