10. software1 agenda for software r1. expectations r2. object-oriented approach r3. uml r4....

10. Software 1

Agenda for software

1. Expectations2. Object-oriented approach3. UML4. Partitioning5. Interfaces6. Throughput and memory7. Design elements

10. Software 2

1. Expectations

Problem 1 Approaches to problem 1Problem 2 Approaches to problem 2

1. Expectations

10. Software 3

Problem 1

Requirement• Provide a straight-line curve fit to a set of N

measurementsHigher-product viewpoint• Provide a turn-key solution that meets the

requirementSoftware product viewpoint• Provide a solution that meets the equations

provided by the higher-product

1. Expectations

10. Software 4

Approaches to problem 1

System

Algorithms

System

Algorithms

CSCI

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

The algorithm document can be located in either place depending upon the skill of

the lower-product developer1. Expectations

10. Software 5

Problem 2

Requirement • Provide a method for describing requirements

for each lower-level productHigher 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

1. Expectations

10. Software 6

Approaches to problem 2

System

AlgorithmsCSCI

Higher-product viewpoint

Having a single system viewpoint and language is less awkward

Having a single system viewpoint and language is less awkward

HWCI

spec spec spec

System

AlgorithmsCSCI

Lower-product viewpoint --multiple system views and

multiple languages --awkward

HWCI

VHDL UML math

1. Expectations

10. Software 7

2. Object-oriented (OO) approach

Reasons for OO approachObjectsCommunicationsClassesObservation


10. Software 8

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 9

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

objectsan object is an instantiation of a class


10. Software 10

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 11


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 12


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 13


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 14

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 15

Classes (2 of 4)

Associations• The bi-directional connection between

classes• Links between objects are instantiations

of associations between classes


10. Software 16

Classes (3 of 4)

New York: city

Ms Smith: resident

Ms Jones: resident

Pittsburgh: city

Mr. Hall: resident

Mr. Wilson: resident

a link

a link

a link

a link

city resident

object

object

object

object

object

object

class class


10. Software 17

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 18

Observation

Hardware and systems tend to be object-oriented already so applying OO to them often results in renaming things and concepts with no particular advantage


10. Software 19

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

3. UML

10. Software 20

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

3. UML

10. Software 21


Practice• Useful• Complicated• Difficult for customer and managers to use

3. UML

10. Software 22


UML non-UML

•Use diagrams•Sequence diagrams•Object diagrams•Collaboration diagrams•Class diagrams•.State-chart diagrams•.Activity diagrams•Deployment diagrams•Component diagrams

•usage•con ops•physical•interface•physical•decision table•con ops•physical•physical

Diagrams

3. UML

10. Software 23

(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

3. UML

10. Software 24


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

3. UML

10. Software 25


Example

• Use-case model Includes actors, system, and the use cases

• System functionality determined by requirements of each actor as expressed in use cases

use-case 1

use-case 2actor A actor B

system

3. UML

10. Software 26


Use cases• Use cases are lists of activities the

actor performs• The activities are textual sentences

3. UML

10. Software 27


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

3. UML

10. Software 28


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

3. UML

10. Software 29


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

3. UML

10. Software 30

(2) Sequence diagrams (1 of 3)

Definition• Sequence diagram display interactions

in time among objects• Sequence diagrams are a form of time-

sequence diagrams

3. UML

10. Software 31


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

3. UML

10. Software 32


object A object B

synchronous msg

asynchronous msg

object A object B

message

object A

reflexivemessage

exampletransmission

delay

examplesynchronous and

asynchronous messages

example ofan object sendingmessage to itself

Example

3. UML

10. Software 33

(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

3. UML

10. Software 34

(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

3. UML

10. Software 35

(3) Object diagrams

:login_display

:configuration_display

:login

supervisor:list_of_people

Example

3. UML

10. Software 36

(4) Collaboration diagrams (1 of 3)

Definition • Collaboration diagram shows interaction

between objects

3. UML

10. Software 37

(4) Collaboration diagrams (2 of 3)Use• It displays a static relationship showing

how objects collaborate

3. UML

10. Software 38

(4) Collaboration diagrams (3 of 3)

:login_display

:configuration_display

:login

supervisor:list_of_people

1. display2. read4. hide

3. correct password5. display

Example

3. UML

10. Software 39

(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

3. UML

10. Software 40

(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

3. UML

10. Software 41

(5) Class diagrams (3 of 3)

login_display

configuration_display

login

list_of_people

Example

3. UML

10. Software 42

(6) State-chart diagrams (1 of 3)

Definition• A state chart diagram represents a state

machine

3. UML

10. Software 43


Use• Used to show logical control among

objects and messages

3. UML

10. Software 44


login

connection

read name

read password

verify

name read

password read

error

Example

3. UML

10. Software 45

(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

3. UML

10. Software 46


Use• It helps to expand use-cases

3. UML

10. Software 47


teacher student board

teach

learn

superviseexams

takeexams

evaluate

Example

3. UML

10. Software 48

(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

3. UML

10. Software 49


Use• Nodes typically represented as cubes

3. UML

10. Software 50


modemPC

(controlsw)

Disk(load

objects)

comm IO port

Example

3. UML

10. Software 51

(9) Component diagrams (1 of 3)

Definition• A component diagram describes

software components at the time of implementation

3. UML

10. Software 52


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

3. UML

10. Software 53


body specification

Example

3. UML

10. Software 54

4. PartitioningRequirementCriteriaChoosing criteriaSpecial considerationsMost common criteriaCost as a criterion

4. Partitioning

10. Software 55

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

4. Partitioning

10. Software 56

CriteriaChose partitioning criteria• Similarity to something done before• Customer satisfaction• Cost• Risk• Schedule• Performance• Reusability and COTS• Functional cohesion and uncoupling• Throughput and memory• Other

4. Partitioning

10. Software 57

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

4. Partitioning

10. Software 58

Special considerations

ApplicationParallel processingAvailable resourcesShared resourcesAvailable peopleSubcontracting

4. Partitioning

10. Software 59

Most common criteria

Functional cohesion and uncouplingThroughput and memory

4. Partitioning

10. Software 60

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

4. Partitioning

10. Software 61

5. Interfaces

IntroductionExamples

5. Interfaces

10. Software 62

Introduction

Interface definition -- The mechanism whereby two products interact

Types of interfaces• Physical interfaces• Data interfaces

5. Interfaces

10. Software 63


Considerations for physical interfaces• Physical characteristics• Alignment• Self test• Instrumentation• Data extraction• Verification• Format standards• Reuse

5. Interfaces

10. Software 64


Considerations for data interfaces• Time tagging• Self test• Instrumentation• Data extraction• Verification• Format standards• Reuse• Throughput

5. Interfaces

10. Software 65

Example -- mechanical alignment

subsystem 1frame

subsystem 2components

Key considerations Alignment Vibration Thermal expansion Installation Maintenance

mechanical

5. Interfaces

10. Software 66

Example -- cooling

subsystem 1generates

heat

subsystem 2heat and cools

Subsystems coupled Subsystem 2 may not be able to control heating and cooling

thermal

5. Interfaces

10. Software 67

Example -- standard busses

DMARS-232MIL-STD-1503FDDIHIPPIFibre channel

5. Interfaces

10. Software 68

Example -- LANS/MANS/WANS (1 of 3)

LAN • Local area network• Privately owned• Short distance -- building, campus, few

miles• Ethernet often used

5. Interfaces

10. Software 69

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

5. Interfaces

10. Software 70

Example -- LANS/MANS/WANS (3 of 3)WAN• Wide area network• Large areas, countries, continents• Complicated arrangement of subnets

5. Interfaces

10. Software 71

Example -- ethernet (1 of 3)

IEEE 802.3: EthernetUsed with LANsProtocol• 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

5. Interfaces

10. Software 72


repeater

linear spine tree repeater

5. Interfaces

10. Software 73


10Base-F

10Base-T

10Base2

10Base5

name

fiber optics

twisted pair

thin coax

thin coax

cable

2000 m

100 m

200 m

500 m

length*

1024

1024

30

100

nodes*

* per segment

best between buildings

easy to maintain

cheapest

good for backbones

nodes*

5. Interfaces

10. Software 74

Example -- token bus

IEEE Standard 802.4: Token BusUsed with LANsPhysical• Linear, 75 ohm broadband cable• 1.5 and 10 Mbps• More complicated than ethernet

5. Interfaces

10. Software 75


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

5. Interfaces

10. Software 76


broadbandcoax cable

logical ring

station

5. Interfaces

10. Software 77

Example -- token ring (1 of 3)

IEEE Standard 802.5: Token RingUsed with LANsPhysical• Twisted, shielded pairs• 4 Mbps• Manchester coding

5. Interfaces

10. Software 78


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

5. Interfaces

10. Software 79


station

unidirectional ring

ring interface

one-bit delay at each station

5. Interfaces

10. Software 80

Example -- DQDB (1 of 6)

IEEE Standard 802.6: Distributed Queue Dual Bus

Used with MANsPhysical layout• Two parallel cables up to 160 km each• 44,736 Mbits/sec (T3)• Cells• 53 bytes • 44 bytes of data• 1 busy bit• 1 request bit

5. Interfaces

10. Software 81


RC=0CD=0

StationA

head

RC=0CD=0

RC=0CD=0

RC=0CD=0

RC=0CD=0

head

A-bus

Initially, request counter (RC) and CD are zero for stations A-EInitially, request counter (RC) and CD are zero for stations A-E

StationB

StationC

StationD

StationE

Initial conditionsInitial conditions

B-bus

5. Interfaces

10. Software 82


RC=1CD=0

StationA

head

RC=1CD=0

RC=1CD=0

RC=0CD=0*

RC=0CD=0

head

A-bus

Stations upstream from D on A-bus increment RCStations upstream from D on A-bus increment RC

StationB

StationC

StationD

StationE

D makes a requestD makes a request

B-bus

requesttransmits

cell

5. Interfaces

10. Software 83


RC=2CD=0

StationA

head

RC=0CD=1*

RC=1CD=0

RC=0CD=0*

RC=0CD=0

head

Stations upstream from B on A-bus increment RC. B moves RC to CD

Stations upstream from B on A-bus increment RC. B moves RC to CD

StationB

StationC

StationD

StationE

B makes a requestB makes a request

B-bus

request transmitscell

5. Interfaces

10. Software 84


RC=1CD=0

StationA

head

RC=0CD=1*

RC=1CD=0

RC=0CD=0

RC=0CD=0

head

Stations upstream from D on A-bus decrement RC and CD Stations upstream from D on A-bus decrement RC and CD

StationB

StationC

StationD

StationE

D sends dataD sends data

B-bus

data

xmitscell

5. Interfaces

10. Software 85


RC=0CD=0

StationA

head

RC=0CD=0

RC=1CD=0

RC=0CD=0

RC=0CD=0

head

Stations upstream from B on A-bus decrement RC and CD Stations upstream from B on A-bus decrement RC and CD

StationB

StationC

StationD

StationE

B sends dataB sends data

B-bus

data

xmitscell

5. Interfaces

10. Software 86

Example -- OSI messaging (1 of 9)application

presentation

session

transport

network

data link

physical

network

data link

physical

network

data link

physical

application

presentation

session

transport

network

data link

physical

APDU

PPDU

SPDU

TPDU

packet

frame

bit

1

2

3

4

5

6

7

Host A Host B

communication subnet

application protocol

presentation protocol

session protocol

transport protocol

router router

Tanenbaum: Computer Networks

5. Interfaces

10. Software 87

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

5. Interfaces

10. Software 88


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

5. Interfaces

10. Software 89


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

5. Interfaces

10. Software 90


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

5. Interfaces

10. Software 91


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

5. Interfaces

10. Software 92


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

5. Interfaces

10. Software 93


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

5. Interfaces

10. Software 94


Application layer• Interfaces between session layer and

user• Examples• File transfer• Terminal services

5. Interfaces

10. Software 95

Example -- TCP/IP messaging

applicationpresentation

sessiontransportnetworkdata linkphysical

application

n/a

transportnetwork

host-to-network

OSI TCP/IP

Tanenbaum: Computer Networks

5. Interfaces

10. Software 96

Example -- TCP/IP messaging

TELNET FTP SMTP DNS

application

TCP UDP

transport

IP

network

ARPANET SATNETpacketradio

LAN

physical data link

protocols

networks

5. Interfaces

10. Software 97

Example -- OS interfaces (1 of 2)MS DOS• Interfaces between user and basic

input/output system (BIOS)• Vendor dependent

5. Interfaces

10. Software 98

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

5. Interfaces

10. Software 99

6. Throughput and memory

ThroughputMemory


10. Software 100

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 101

Throughput (2 of 5)

There shall be 100 % spare throughput capacityreference 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

There are two ways of interpreting spare throughput capacity based on reference used as denominator


10. Software 102

Throughput (3 of 5)Availability of spare throughput• Available at the highest-priority-application 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

Assuming the spare throughput is available at the highest-priority-application level is

the most common assumption


10. Software 103

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 104

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

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 105

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 106

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

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 percentage6. Throughput and memory

10. Software 107

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 108

7. Design elementsIntroductionSoftwareHardware toolsHardware

7. Design elements

10. Software 109

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

7. Design elements

10. Software 110

SoftwareSystem engineering toolsReal-time operating systems, kernels, and

executivesCompiler and language productsDebuggersLibrariesCommunications packagesEmbedded internet packagesJava language productsData bases

7. Design elements

10. Software 111

Hardware tools

In-circuit emulatorsBDM/JTAG-based emulatorsROM emulatorsOscilloscopesLogic and bus analyzers

7. Design elements

10. Software 112

HardwareIntegrated circuits• Microcontrollers and embedded

microprocessors• Digital signal processors• Flash memory

Board-level products• Single-board computers

7. Design elements

10. software1 agenda for software r1. expectations r2. object-oriented approach r3. uml r4....

Documents