1. 程建群 博士(Dr. Jason Cheng) jason8407@yahoo.com.cn 13522913536 2008年03月
Software Engineering
Part 02
程建群 博士(Dr. Jason Cheng)
2008年03月

2. Software Process and Other Models

3. 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 Process and Other Models

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

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

6. Software Process Model
Process diagram for unit testing (without decision)
Software Process and Other Models

7. Software Process Model
Process diagram for unit testing (with decision)
Software Process and Other Models

8. Data Flow Diagrams Software Process and Other Models
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

9. 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 Process and Other Models

10. Data Flow Diagrams Software Process and Other Models
Example (unit testing)
Software Process and Other Models

11. 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 Process and Other Models

12. Data Flow Diagrams
Example
Software Process and Other Models

13. Petri Net Models Software Process and Other Models
Rules and interpretations for correct data flow diagrams
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.
Software Process and Other Models

14. Petri Net Models Software Process and Other Models
Rules and interpretations for correct data flow diagrams
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.
Software Process and Other Models

15. Petri Net Models
Example (unit test)
Software Process and Other Models

16. 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 Process and Other Models

17. 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 Process and Other Models

18. Object Models Software Process and Other Models
The three major types of relationships are:
Inheritance
Aggregation
Association
Software Process and Other Models

19. 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 Process and Other Models

20. 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 Process and Other Models

21. 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 Process and Other Models

22. Object Models Software Process and Other Models
Example (Construct an object model for a library)
Software Process and Other Models

23. Object Models Software Process and Other Models
Example (Construct an object model for a family-tree)
Software Process and Other Models

24. 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 Process and Other Models

25. Use Case Diagrams Software Process and Other Models
Example (Use case for simple library)
Software Process and Other Models

26. 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 Process and Other Models

27. Scenarios Software Process and Other Models
A scenario is a description of one sequence of actions that could occur in this problem domain.
Software Process and Other Models

28. 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 Process and Other Models

29. 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 Process and Other Models

30. Sequence Diagrams
Example:
Software Process and Other Models

31. 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 Process and Other Models

32. 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 Process and Other Models

33. Hierarchy Diagrams Software Process and Other Models
Example (Use case for simple library)
Software Process and Other Models

34. 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 Process and Other Models

35. Control Flow Graphs Software Process and Other Models
Rules and interpretations for 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.
Software Process and Other Models

36. Control Flow Graphs Software Process and Other Models Example
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;
Software Process and Other Models

37. Control Flow Graphs
Example
Software Process and Other Models

38. 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 Process and Other Models

39. 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 Process and Other Models

40. 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 Process and Other Models

41. State Diagrams Software Process and Other Models
Example 1: Draw a state diagram for a fixed-size stack
Software Process and Other Models

42. 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 Process and Other Models

43. State Diagrams Software Process and Other Models
Example 2: Draw a state diagram for a stack with all the error transitions shown.
Software Process and Other Models

44. 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?