Upload
marshall-harper
View
235
Download
0
Tags:
Embed Size (px)
Citation preview
Software Engineering 2007 - 2008
Software Process and Other Models
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
Software Engineering 2007 - 2008
Software Process Model
SPM Notation:
Ovals for tasks and processes
Rectangles for artifacts
Actors by stick figures
Diamonds as decisions
Software Process and Other Models
Software Engineering 2007 - 2008
Software Process Model
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.
Software Process and Other Models
Software Engineering 2007 - 2008
Software Process Model
Process diagram for unit testing (without decision)
Software Process and Other Models
Software Engineering 2007 - 2008
Software Process Model
Process diagram for unit testing (with decision)
Software Process and Other Models
Software Engineering 2007 - 2008
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.
Software Process and Other Models
Software Engineering 2007 - 2008
Data Flow Diagrams
Software Process and Other Models
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.
Software Engineering 2007 - 2008
Data Flow Diagrams
Software Process and Other Models
Example (unit testing)
Software Engineering 2007 - 2008
Data Flow Diagrams
Software Process and Other Models
Example
The calculation of the mathematical formula (X + Y) * (W+ Z) can be shown as a sequence of operations:
Software Engineering 2007 - 2008
Data Flow Diagrams
Software Process and Other Models
Example
Software Engineering 2007 - 2008
Petri Net Models
Software Process and Other 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
Software Engineering 2007 - 2008
Petri Net Models
Software Process and Other 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
Software Engineering 2007 - 2008
Petri Net Models
Software Process and Other Models
Example (unit test)
Software Engineering 2007 - 2008
Object Models
Software Process and Other 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.
Software Engineering 2007 - 2008
Object Models
Software Process and Other 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.
Software Engineering 2007 - 2008
Object Models
Software Process and Other Models
The three major types of relationships are:
Inheritance
Aggregation
Association
Software Engineering 2007 - 2008
Object Models
Software Process and Other 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.
Software Engineering 2007 - 2008
Object Models
Software Process and Other 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.
Software Engineering 2007 - 2008
Object Models
Software Process and Other 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.
Software Engineering 2007 - 2008
Object Models
Software Process and Other Models
Example (Construct an object model for a library)
Software Engineering 2007 - 2008
Object Models
Software Process and Other Models
Example (Construct an object model for a family-
tree)
Software Engineering 2007 - 2008
Use Case Diagrams
Software Process and Other Models
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.
Software Engineering 2007 - 2008
Use Case Diagrams
Software Process and Other Models
Example (Use case for simple library)
Software Engineering 2007 - 2008
Use Case Diagrams
Software Process and Other Models
Example (Use case for simple library)
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.
Software Engineering 2007 - 2008
Scenarios
Software Process and Other Models
A scenario is a description of one sequence of actions that
could occur in this problem domain.
Software Engineering 2007 - 2008
Scenarios
Software Process and Other Models
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.
Software Engineering 2007 - 2008
Sequence Diagrams
Software Process and Other Models
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.
Software Engineering 2007 - 2008
Sequence Diagrams
Software Process and Other Models
Example:
Software Engineering 2007 - 2008
Sequence Diagrams
Software Process and Other Models
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.
Software Engineering 2007 - 2008
Hierarchy Diagrams
Software Process and Other Models
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.
Software Engineering 2007 - 2008
Hierarchy Diagrams
Software Process and Other Models
Example (Use case for simple library)
Software Engineering 2007 - 2008
Control Flow Graphs
Software Process and Other Models
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.
Software Engineering 2007 - 2008
Control Flow Graphs
Software Process and Other Models
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
Software Engineering 2007 - 2008
Control Flow Graphs
Software Process and Other Models
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
Software Engineering 2007 - 2008
Control Flow Graphs
Software Process and Other Models
Example
Software Engineering 2007 - 2008
State Diagrams
Software Process and Other Models
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.
Software Engineering 2007 - 2008
State Diagrams
Software Process and Other Models
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.
Software Engineering 2007 - 2008
State Diagrams
Software Process and Other Models
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.
Software Engineering 2007 - 2008
State Diagrams
Software Process and Other Models
Example 1: Draw a state diagram for a fixed-size stack
Software Engineering 2007 - 2008
State Diagrams
Software Process and Other Models
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.
Software Engineering 2007 - 2008
State Diagrams
Software Process and Other Models
Example 2: Draw a state diagram for a stack with all the error transitions shown.
Software Engineering 2007 - 2008
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?