Software Engineering

T. E. Potok - University of Tennessee

Software Engineering

Dr. Thomas E. PotokAdjunct Professor UT

Research Staff Member ORNL

Software Engineering CS 594


2

Agenda

Team interactions OO Analysis and Design Dr. Reat



3

When do you focus on risk? First the nature of the project dictates

the level of risk management necessary– If the project has challenging requirements

• Safety • Performance• Complexity• Size

A simple small project may not need much risk management



4

When to focus on risk

Next, are development concerns– Do you have the right people– Can you do the work within schedule

and budget– Is the problem well understood

You may have a small simple project that your team is incapable of developing



5

Last resort You believe that the challenger will explode

– People will be killed– The space program will be crippled for years

What do you do?– Write a tersely worded memo to your manager?– Leave a voice mail with your manager’s manager?– Call the president of the company?– Call the president, the news papers, the TV

stations? If you know disaster is coming, and you don’t

do everything within your power to prevent it, you have failed



6

Summary

Understanding the risks associated with a project is essential to the success of a project

The more aspects of a project that are not understood, the higher the chance that blind luck with guide the project



7

What is this?



8

The last picture taken from the Mars Lander Mars Lander

– … A software flaw probably caused the Mars Polar Lander to shut off its descent engines prematurely, sending it on a fatal plunge into the red planet, according to a report released Tuesday…

– "There was inadequate software design and testing. The software should have been designed to prevent premature engine shutdown," he said. "In space, one strike and you're out."

– The loss to taxpayers was approximately $165M.



9

THERAC-25 Radiation Therapy



10

Human Life

In 1986, two cancer patients at the East Texas Cancer Center in Tyler received fatal radiation overdoses from the Therac-25, a computer-controlled radiation-therapy machine. There were several errors, among them the failure of the programmer to detect a race condition (i.e., miscoordination between concurrent tasks).

6 people in total received massive overdoses of radiation from the Therac-25 directly resulting in two deaths



11

Airbus 320, not an F-14



12

290 Die

The 1988 shooting down of the Airbus 320 by the US Vicennes was attributed to the cryptic and misleading output displayed by the tracking software where the plane was mistaken for an F-14.

290 people die US-Iranian relations worsen Possibly resulting in increased terrorist

attacks against US interests


Team Interaction



14

History

Most early software productivity studies focused on the software development team as the main factor in increasing productivity.

The goal of a project manager was to hire the people with the most experience, and best talent

However, that was at a time when experience was hard to come by, and there was little formal education



15

Current Situation

Computer science degrees are common

Software development experience is common

However, demand still out paces the availability of computer skills

Is the software development team still important?



16

Not to Some

Kitchenham, Lawrence, and Jeffery et al. show that many of the personnel related factors in earlier studies had no effect on productivity in their studies.



17

What is a team?

A collection of people with a common mission or purpose.

Traditional departmental focus:– Group similar skills on the same

teams, architects with architects, programmers with programmers, testers with testers.

– Based on mass production efficiency concepts

• specialization of labor



18

Non-traditional Teams

Product focused:– The team is made up of members

that can contribute to the completion of the project:

• 1 architect• 6 programmers• 2 testers

– The team is charged with successfully completing the project



19

Example

Most universities are organized around departments:– Computer science– Mathematics– Physics

Each department has faculty members who are experts in the department’s field



20

Example

What if you organized the departments around the students?– The Freshman Engineering

Department may look like:• 4 Mathematicians• 2 Physicists• 2 Chemists• 4 English teachers



21

What drives a team

Locke and Latham’s“goal theory” reports that productivity increases with specific, challenging goals

There is a linear relationship between the degree of difficulty of a goal, and the performance required to achieve it.



22

Basic Experiment

Participants performing a group of tasks. – Some of the participants are given

challenging goals, – others are told to “do their best.” – In most cases, the participants given hard

goals significantly out performed the other participants.

This widely accepted theory supports the notion that programmer productivity can be strongly influenced by deadline “goals” set by a project schedule.



23

Leadership Look at successful software development efforts

and you will find a successful leader Some characteristics of a leader (Maxwell):

– A person of influence, not necessarily from title or position

– A person of character– Has the ability to learn and grow – Has passion and discipline for the task– Has the ability to lead

“The 21 Irrefutable Laws Of Leadership Follow Them And People Will Follow You”by John Maxwell



24

More on Leadership

Covey’s Seven habits– Proactive– Begin with the end in mind– First things first– Think win-win– Understand, then be understood– Synergize– Sharpen the saw

“The 7 Habits of Highly Effective People” by Stephen R. Covey



25

Five Temptations of a CEO Focus on career, not company

success Desire to be liked by staff Desire for correctness over clarity Desire for harmony Desire to be invulnerable “The Five Temptations of a CEO : A

Leadership Fable” by Patrick M. Lencioni


Object-Oriented Analysis and Design



27

Quick Review

Gather requirements Select a project life-cycle Plan the project Build a team Then start the development of the

software



28

Object-Oriented

Prior to OO was structured analysis– Keep function and data separate in

analysis– Use data model for databases,

functional models for software OO combines data and function

– Encapsulation– Inheritance– Polymorphism



29

Encapsulation

Provide a layer between the data of an object, and a calling method

This can insulate a calling method from having to be changed, in the initial data is changed



30

ExamplePerson Age Weight Height healthIndex

Person Age (getAge(), setAge(int)) Weight (getWeight(), setWeight(int)) Height (getHeight(), setHeight(int)) healthIndex (getIndex(), setIndex(float))

healthIndex := Age*(Weight/Height)

setIndex(getAge()*(getWeight()/getHeight())



31

Encapsulation Example

The setter methods can be used to put bounds on values, age can not be greater than 120, or less than 0

The getter methods can be used to translate units, height from feet to meters

A change in the bounds, or units will require only a change to a few methods, not all the code that uses the attributes

For big changes, age to birth date, encapsulation does not help



32

Inheritance

The objects within an OO system can be organized in a class hierarchy

This hierarchy provides two means of inheritance– Method inheritance– Attribute inheritance



33

Method inheritance

An object can make us of any method that is defined higher in the class hierarchy

The code does not have to be copied, or rewritten, it just works

The method can be overridden if needed



34

Attribute Inheritance

Attributed from object higher in the hierarchy tree are also inherited

These attribute become available to the object, and do not have to be copied or defined

They can be overridden as well



35

Inheritance example

Object

Collection

Name PrintCopy

NameTypeMembers

PrintCopySortAdd(element)Delete(element)

BagNameTypeMembers

PrintCopySort (Overridden)Add(element)Delete(element)



36

Multiple Inheritance

Allows methods and attributes to be inherited for multiple object

Highlights the challenge of developing a class hierarchy

Has the potential for name collisions



37

Name collisions

floorWax spread

cakeIcing spread

Fertilizer spread

What spread method does fertilizer inherit from???



38

Hierarchy Trees

Several ways to develop– Based on common functions or methods

• With a many common methods, there is the opportunity for reuse

– Based on common attributed• Common data can be an advantage particularly if

you are using databases

– Based on frequency of changes• Put stable methods higher in the hierarchy to

lower the impact of change



39

Example

A hardware store can be laid out in a similar way– Based on functionality

• Digging tools, cutting tools, hammering tools, ...– Based on data

• Metal tools, wooden tools, plastic tools, ...– Based on frequency

• Gum, nails, paint, rope, …– Based on domain

• Gardening, household, garage, bedroom

No optimum way of doing so



40

Polymorphism

Calling similar methods in different class the same name– print– new

Not a new concept, used for arithmetic operations in other languages

Widely used in OO



41

OO Analysis

The development of an Analysis Model in the OO methodology converts:– User requirements– Into a high-level system model– In user terms not computer terms

This analysis is focused on – Defining objects and their interactions



42

More on OOA

OOA models may be done informally or more formally in object diagrams, ER diagrams, DFD diagrams, state-transition diagrams, or Petri nets

The OOA model consists of an object model, and may include a process model and a state model. – A process model describes the functional interaction of

objects. This model is represented by the message paths among objects in an object model.

– A state model can be used to determine the valid states for each object in the model.

– An object state may change based on messages received from another object



43

Analysis Approaches

There are two main OO analysis methods used in the industry today– Booch– Rumbaugh NOT Rambaugh!

Booch tends to be less formal Rumbaugh has close similarities to

structure analysis



44

Booch Analysis

Booch’s methodology can be summarized with four basic steps [Booch (1991)]. – 1) Identify the classes and objects for a

given level of abstraction.

– 2) Identify the semantics of the objects and classes;

– 3) Identify relationships among the classes and objects

– 4) Design the classes and objects.



45

Identify Classes and Objects Assumes that you are given a

specification of the problem From this specification you underline

the nouns in the specification Then the nouns are used to create a

list of potential objects in the system This list is refined to define the

objects and attributes



46

Semantics of Objects and Classes Once the objects are defined, then

the verbs in the specification are underlined

The verbs are listed as potential methods

The methods are added to the appropriate classes to add meaning to the classes



47

Identify Relationships

Often CRC cards are used:– Class, Responsibilities, Collaborators

3 x 5 Cards with class information are arranged based on how objects flow in the system

This allows for modeling of the system, and defines how objects relate to each other



48

Design Classes and Objects Refine the analysis model

converting from real-world terms to computer terms

Expand the objects to include necessary system objects



49

Booch Summary

The strength of Booch’s methodology is the underlying object model.

This model consists of five diagram types, – class, – object, – state, – process, – module. – The class, object, and state diagrams represent the

logical structures. – The process and module diagrams represent

physical structures.



50

Rumbaugh’s OMT

Rumbaugh et al. produced the Object Modeling Technique (OMT) which presents a view of object-oriented development in three parts: – an object model, based on a modified ER

diagram that supports inheritance relationships.

– dynamic model, a state model based on state transition diagrams

– functional model, a data-flow diagram



51

OMT OMT defines three basic phases to create a

low-level object-oriented design. – the analysis phase, the problem is defined, and

solutions represented in object, dynamic, and functional models.

– The next phase is the system design where the analysis model is mapped to the physical system.

– The last phase is the object design where the analysis model is refined based on system model mapping, producing a low-level, language independent design ready for implementation



52

Summary

Exam Review Team interactions OO Analysis and Design

Software Engineering

Documents

Transcript of Software Engineering