Software Engineering

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

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

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 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 Process Model • Process diagram for unit testing (without decision) Software Process and Other Models

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

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

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

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

Data Flow Diagrams • Example The calculation of the mathematical formula (X + Y) * (W+ Z) can be shown as a sequence of operations: Software Process and Other Models

Data Flow Diagrams • Example Software Process and Other Models

Petri Net 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

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

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

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

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

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

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

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

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

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

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

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

Use Case Diagrams • 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

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

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

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

Sequence Diagrams Example: Software Process and Other Models

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

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

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

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

Control Flow Graphs • 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

Control Flow Graphs • 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

Control Flow Graphs • Example Software Process and Other Models

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

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

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

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

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

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

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?

Software Engineering