# Presentation: 747119

## Software Engineering

- Dr. Thomas E. Potok
- Adjunct Professor UT
- Research Staff Member ORNL

## Agenda

- Team interactions
- OO Analysis and Design
- Dr. Reat

## 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

## 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

## 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_

## 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

## What is this?

## 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.

## THERAC-25 Radiation Therapy

## 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

## Airbus 320, not an F-14

## 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

## 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

## 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?

## 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.

## 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

## 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

## Example

- Most universities are organized around departments:
- Computer science
- Mathematics
- Physics
- Each department has faculty members who are experts in the department’s field

## 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

## 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.

## 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.

## 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

## 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

## 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

## Quick Review

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

## 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

## 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

## Example

- Person
-   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())

## 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

## 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

## 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

## 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

## Inheritance example

- Object

- Collection

- Name

- Print
- Copy

*Name*
- Type
- Members

*Print*
*Copy*
- Sort
- Add(element)
- Delete(element)

- Bag

*Name*
*Type*
*Members*

*Print*
*Copy*
- _Sort (Overridden)_
*Add(element)*
*Delete(element)*

## 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

## Name collisions

- floorWax
-   spread

- cakeIcing
-   spread

- Fertilizer
-   *spread*

- What spread method does fertilizer inherit from???

## 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

## 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

## 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

## 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

## 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

## 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

## 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.

## 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

## 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

## 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

## Design Classes and Objects

- Refine the analysis model converting from real-world terms to computer terms
- Expand the objects to include necessary system objects

## 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.

## 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

## 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

## Summary

- Exam Review
- Team interactions
- OO Analysis and Design