1. Software Engineering
Chapter 5 (Part 3)
System Modeling
Dr.Doaa Sami

2. 2
D. Behavioral Models

3. 3
1. Activity Diagrams

4. Activity Diagram  An activity diagram is a Data-driven Model.4
 An activity diagram is a Data-driven Model.
 An activity diagram is used to display the sequence of activities.
 Activity diagrams show the workflow from a start point to the finish point, include details of many decision paths that exist in progression of events contained in the activity.
 They may be used to detail situations where parallel processing may occur in the execution of some activities.

5. Activity elements that make up the activity.5
 Activity: it is shown as a round-cornered rectangle enclosing all the actions, control flows and other
elements that make up the activity.

6. Action 6
 An Action represents a single step within an activity. Actions are denoted by round-cornered
rectangles.
Perform an
action

7. Control Flow arrowhead.7
 A Control Flow shows the flow of control from one action to the next. Its notation is a line with an
arrowhead.
Send Accept
payment payment

8. Initial Node 8
 An Initial or Start Node is depicted by a large black spot, i.e. filled circle.
action

9. Final Node 9
 There are two types of Final Node:
The Activity Final Node is depicted as an empty circle with a dot inside it. It denotes the end of all control flows within the activity.
The Flow Final Node is depicted as an empty circle with a cross inside it. It denotes the end of a single control flow.

10. Decision and Merge Nodes10
 Decision Nodes and Merge Nodes have the same notation: a diamond shape but with opposite directions of arrowheads. They can both be named.
 The control flows coming away from a decision node will have guard conditions which will allow control to flow if the guard condition is met.

11. Fork and Join horizontal or vertical bar (dependent on whether the11
 Forks and Joins have the same notation: either a
horizontal or vertical bar (dependent on whether the
control flow is running left to right or top to bottom).
 They indicate the start and end of concurrent threads
of control.
 Fork: denotes the beginning of parallel activity.
 Join: denotes the end of parallel processing.

12. Example: Creating Document Activity12
Open the word processing package.
Create a file.
Save the file under a unique name within its directory.
Type the document.
If graphics are necessary, open the graphics package, create the graphics, and paste the graphics into the document.
If a spreadsheet is necessary, open the spreadsheet package, create the spreadsheet, and paste the spreadsheet into the document
Save the file.
Print a hard copy of the document.
Exit the word processing package.

13. Solution 13

14. 14
2. State Diagrams

15. State Diagrams  A State diagram is an Event-driven Model.15
 A State diagram is an Event-driven Model.
 State diagrams show system states and events that cause transitions from one state to another.
 State diagrams do not show the flow of data within the system but may include additional information on the computations carried out in each state.

16. State Diagrams Cont. 16
 In UML state diagrams, rounded rectangles represent System States.
 They may include a brief description (following ‘do’) of the actions taken in that state.
 The labeled arrows represent Stimuli that force a transition from one state to another.
 Start and End States indicated by using filled circles, as in the activity diagrams.

17. State Diagram Example  A very simple microwave oven system: 17
 The microwave has a switch to select full or half power, a numeric keypad to input time, a start/stop button, and an alphanumeric display.
 We assumed that the sequence of actions using the microwave is:
1. Select the power level (either half power or full power).
2. Input the cooking time using a numeric keypad.
3. Press Start and the food is cooked for the given time.
 For safety reasons, oven should not operate when door is open.

18. Solution 18

19. Example
Software Engineering
Behavioral Diagrams

20. Example
Software Engineering Behavioral Diagrams

21. When to Use Statecharts
They are good at describing the behaviour of an object across several scenarios of use.
They are not good at describing behaviour that involves a number of collaborating objects (use interaction diagrams for this).
Not usually worthwhile to draw a statechart for every class in the system.
Use them only for those classes that exhibit interesting behaviour.
Software Engineering
Behavioral Diagrams

22. Data-Flow Diagrams
Data-flow diagrams describe systems as collections of data that are manipulated by functions.
Data can be organized in several ways: They can be stored in data repositories, they can flow in data flows, and they can be transferred to or from the external environment.

23. Symbols Used for Constructing DFDs
There are different types of symbols used to construct DFDs:
Function symbol:
External entity:
Data-flow symbol:
Data-store symbol:
Output Symbol:

24. Example
Construct a DFD that describes the arithmetic expression (a + b) * (c + a * d).
Assume that the data a, b, c, and d are read from a keyboard and the result is printed.

25. Solution

26. Example
Construct a DFD that describes a simplified information system for a public library The data and functions shown are not necessarily computer data and computer functions.
The DFD describes physical objects, such as books and shelves, together with data stores that are likely to be, but are not necessarily, realized as computer files.

27. Solution

28. A Supermarket DFD

29. Levels of a DFD
The initial level is called the context level or fundamental system model or a 0-level DFD.
If we expand the 0-level processes then we get the 1st-level DFD and if we further expand the 1st-level processes then we get the 2nd-level DFD and so on.

30. General Guidelines for Constructing DFDs
Remember that a DFD is not a flowchart.
All names should be unique.
Processes are always running; they do not start or stop.
All data flows are named.
Give unique names to all the processes and external entities.

31. General Guidelines for Constructing DFDs
Avoid complex DFDs (if possible).
Every process should have a minimum of one input and one output.
Only data needed to perform the process should be an input to the process.
The direction of flow is from source to destination.

32. Decision Tables
Decision tables provide a mechanism for recording complex decision logic.
A decision table is segmented into four quadrants:
Condition stub and Condition entry.
Action stub and action entry.

33. Basic Elements of a Decision Table

34. Limited Entry Decision Table

35. An Ambiguous Decision Table

36. An Ambiguous Decision Table
If more than one decision rule has identical (Y, N, -) entries, the table is said to be ambiguous.
Ambiguous pairs of decision rules that specify identical actions are said to be redundant, and those specifying different actions are contradictory.

37. An Incomplete Decision Table
A decision table is complete if every possible set of conditions has a corresponding action prescribed.
Failure to specify an action for any one of the combinations results in an incomplete decision table.

38. An Incomplete Decision Table

39. Example
A computer-based system performs two actions (A1 and A2) based on the status of 3 switches.
If at least one of the three switches is ON, it performs A1.
If at least two of the switches are ON, it performs A2.
Construct a decision table for the system.
Is the decision table complete? Why?
Is there any contradictory or redundant rules? Why?

40. Solution 1 2 3 4 5 6 7 8
SW1 N Y
SW2
SW3 A1 X A2

41. Library Requisition Example
The Head of the Department (HOD) recommends books to be bought by the Library.
If funds are available, then the books are bought.
In case funds don’t permit, a textbook is kept waitlisted for purchase during the next year, whereas the Library returns the requisitions for all other books to the Head of the Department.

42. Library Requisition Flowchart

43. Decision Table for Library Requisition

44. Advantages of Decision Tables
Decision rules are clearly structured.
Mangers can be relieved from decision-making.
Consistency in decision-making.
Communication is easier between managers and analysts.
Documentation is easily prepared, changed, or updated.

45. Advantages of Decision Tables
Easy to use.
Easier to draw or modify compared to flowcharts.
Facilitate more compact documentation.
Easier to follow a particular path down one column than through complex and lengthy flowcharts.

46. Disadvantages of Decision Tables
Impose an additional burden.
Do not depict the flow.
Not easy to translate.
Cannot list all the alternatives.

47. Model-Driven Engineering19
 Model-Driven Engineering (MDE): is an approach to software development where models rather than programs are principal outputs of development process.
Programs that execute on a hardware/software platform are then generated automatically from the models.
 Proponents of MDE argue that this raises the level of
abstraction in SWE, so that engineers no longer have to be concerned with programming language details.

48. Model Driven Architecture20
 Models at different levels of abstraction are created. From a high-level, platform independent model, it is possible, to generate a working program without manual intervention.
 Model-driven engineering (MDE) has its roots in model- driven architecture (MDA).
 MDA focuses on the design and implementation stages of software development whereas MDE is concerned with all aspects of the software engineering process.

49. Summery and external actors; sequence diagrams add more21
 A model is an abstract view of a system that ignores system details. Complementary system models can be developed to show the system’s context, interactions, structure and behaviour.
 Use case diagrams and sequence diagrams are used to describe the interactions between users and systems in the system being designed.
 Use cases describe interactions between a system
and external actors; sequence diagrams add more
information to these by showing interactions between system objects.

50. Summery 22
 Class diagram is used to define the static structure of classes in a system and their associations.
 Activity diagrams maybe used to model processing of data, where each activity represents one process step.
 A State diagrams show system states and events that cause transitions from one state to another.
 Model-driven engineering is an approach to SW development in which a system is represented as a set of models that automatically transformed to executable code.

51. Reference 23
 Fowler, Martin. UML distilled. Addison-Wesley Professional, 2004.
 Schmuller, Joseph. Sams teach yourself UML in
24 hours. Sams publishing, 2004. 
ntroduction_to_uml_sequence_diagrams/ 
utorial/