程建群博士 (Dr. Jason Cheng) [email protected] 13522913536 2008 年 03 月 Software...

程建群博士 (Dr. Jason Cheng)[email protected]

13522913536

2008 年 03 月

Software EngineeringPart 02

Software Engineering 2007 - 2008

Software Process and Other Models



Software Process Model

A Software Process Model (SPM):

Describes the processes that are done to achieve software development.

Tasks

Artifacts (file, data, etc.)

Actors

Decisions



SPM Notation:

Ovals for tasks and processes

Rectangles for artifacts

Actors by stick figures

Diamonds as decisions




Rules and interpretations for correct process models:

Two tasks cannot be connected by an arc. Tasks must be separated by artifacts

A task is not executable until its input artifacts exist.

There are one or more start tasks and one or more terminal tasks.

All tasks must be reachable from start task.

There are a path from every task to the terminal task.




Process diagram for unit testing (without decision)




Process diagram for unit testing (with decision)



Data Flow Diagrams

A data flow diagram shows the flow of the data among a

set of components. The components may be tasks,

software components, or even abstractions of the

functionality that will be included in the software system.



Data Flow Diagrams


Rules and interpretations for correct data flow diagrams

Boxes are processes and must be verb phrases

Arcs represent data and must be labeled with noun phrases.

Control is not shown. Some sequencing may be inferred from the ordering.

A process may be a one-time activity, or it may imply a continuous processing.

Two arcs coming out a box may indicate that both outputs are produced or that one or the other is produced.


Data Flow Diagrams


Example (unit testing)


Data Flow Diagrams


Example

The calculation of the mathematical formula (X + Y) * (W+ Z) can be shown as a sequence of operations:


Data Flow Diagrams


Example


Petri Net Models


The condition nodes usually represent some required

condition – for instance, the existence of a test plan.

A token at the condition means that the condition is

met.

An event node (the horizontal line) represents an event

that can happen (fire) when all the requirements are met

(tokens in all the condition nodes).

Tokens are then placed at all the condition nodes that

follow the event.

Rules and interpretations for correct data flow diagrams


Petri Net Models


Example (unit test)


Object Models


In object-oriented development, both the problem in the

problem domain and the solution in the machine space

are described in terms of objects. In the solution, these

objects normally become classes.

At the requirements and design phases of software

development progress, the objects switch from being

representations of the things in the problem domain to

being programming structures in the software.


Object Models


Object models represent entities and relationships between

entities. Each box represents a type of object, and the name,

attributes, and the methods of the object are listed inside the

box. The top section of the box is for the name of the object,

the second section is for the attributes, and the bottom section

is for the methods. An arc between two objects represents a

relationship between the objects. Arcs may be labeled in the

center with a name of the association. The roles may be

labeled at the opposite end. Also, at each end a multiplicity

may be given indicating how many different associations of

the same kind are allowed.


Object Models


The three major types of relationships are:

Inheritance

Aggregation

Association


Object Models


Inheritance

Implies that the object at the bottom of the arc is a

special case of the object at the top of the arc.

This is often called an “is-a” relationship.


Object Models


Aggregation

Implies that the object at the bottom of the arc is a

component of the object at the top of the arc.

This is often called an “part-of” relationship.


Object Models


Association

Implies that somehow one of the objects is associated

with the other object.

The “father-son” relationship is an association.

This relationship may be two-way, or it might only be

one-way.


Object Models


Example (Construct an object model for a library)


Object Models


Example (Construct an object model for a family-

tree)


Use Case Diagrams


A use case diagram is part of the UML set of diagrams. It

shows the important actors and functionality of a system.

Actors are represented by stick figures and functions by

ovals. Actors are associated with functions they can

perform.


Use Case Diagrams


Example (Use case for simple library)


Use Case Diagrams



The functions in the ovals are methods of the classes in

the object model. The patron object can borrow and return

copies. The librarian actor is not an object on the object

model. The librarian in the use case shows that some

functions – for instance, catalog and shelve books – are

not functions available to the patron.


Scenarios


A scenario is a description of one sequence of actions that

could occur in this problem domain.


Scenarios


Example:

Write a scenario for the library problem. Fred, a patron,

goes the library and check out a book. Two months later,

he bring the overdue library book back to the library.


Sequence Diagrams


A sequence diagram is part of the UML set of diagrams.

The diagram has vertical lines, which represent instances

of classes. Each vertical line is labeled at the top with the

class name followed by a colon followed by instance

name.

Horizontal arrows depict function calls. The tail of the

arrow is on the line of the calling class, and the head of

the arrow is on the line of called class.


Sequence Diagrams


Example:


Sequence Diagrams


Example:

The name of the function is on the arrow. The wide block

on the vertical line shows the execution time of called

function. Returns are normally not shown. Multiple calls to

the same function are often shown as just one arrow.


Hierarchy Diagrams


A hierarchy diagram shows the calling structure of a

system. Each box represents a function. A line is drawn

from one function to another function if the first function

can not call the second function. All possible calls are

shown.

It is a very useful diagram to understand the dynamic

structure of a system.


Hierarchy Diagrams




Control Flow Graphs


A control flow graph (CFG) shows the control structure of

code. Each node (circle) represents a block of code that

has only one way through the code. That is, there is one

entrance at the beginning of the block and one exit at the

end.


Control Flow Graphs


There must be one start node.

From the start node, there must be a path to each

node.

From each node, there must be a path to a halt node.

Rules and interpretations for Control Flow Graphs


Control Flow Graphs


Draw a control flow graph for the following triangle problem.Read x, y, z;Type = “scalens”;If (x==y or x==z or y==z) type = “isosceles”;If (x==y and x==z) type = “equilateral”;If (x>=y+z or y >= x+z or z>=x+y) type = “not a triangle”;If (x <=0 or y <=0 or |z <= 0) type =“bad inputs”;Print type;

Example


Control Flow Graphs


Example


State Diagrams


The state of a machine of problem is the collection of all the

values of all the variables, registers, and so on. A state

diagram shows the states of the system and the possible

transitions between these states.

A program or machine will have an extremely large number

of different states. However, many states will be similar in

how the machine will behave on the next input, and so forth.


State Diagrams


A group of states with similar behaviors can be grouped

together into a state. These states can be diagrammed to

show the transitions between the states.

Many programs are best described with a state diagram.


State Diagrams


Rules for correct state diagrams:

There is one initial state.

Every state can be reached from the initial state.

From each state, there must be a path to a stop state.

Every transition between states must be labeled with an

event that will cause that transition.


State Diagrams


Example 1: Draw a state diagram for a fixed-size stack


State Diagrams


Example 1: Draw a state diagram for a fixed-size stack

There are two approaches to a state diagrams. In this

example, only legal or non-error transitions are specified. It

is assumed that any transition that is not shown is illegal.

For example, there is no push transition from the full state.

Another approach is to show all transitions, including

transitions that cause errors.


State Diagrams


Example 2: Draw a state diagram for a stack with all the error transitions shown.


Homework One

1: How does a phased life cycle model assist software management?

2: Draw a diagram that represents an iterative life cycle model.

3: What are the differences between a software life cycle model and a process model?

4: Why should tasks in a process model be separated by an artifact?

5: What changes in an object model from requirements to design?

程建群博士 (Dr. Jason Cheng) [email protected] 13522913536 2008 年 03 月 Software...

Documents

Transcript of 程建群博士 (Dr. Jason Cheng) [email protected] 13522913536 2008 年 03 月 Software...

程建群 博士 (Dr. Jason Cheng) [email protected] 13522913536 2008 年 03 月 Software...

Documents

Transcript of 程建群 博士 (Dr. Jason Cheng) [email protected] 13522913536 2008 年 03 月 Software...

程建群博士 (Dr. Jason Cheng) [email protected] 13522913536 2008 年 03 月 Software...

Transcript of 程建群博士 (Dr. Jason Cheng) [email protected] 13522913536 2008 年 03 月 Software...