1. DT249/4 Information Systems Engineering
Systems Modelling

2. Diagrams Context Diagram Data Flow Diagram Activity Diagram
Use Case Diagram
Class Diagram

3. Context Diagram

4. Context Diagram
One of the first things you need to do when specifying a system is to decide on the system boundaries.
This means deciding what functionality should be included in the system and what is provided by the system’s environment.

5. Context Diagram
You should look at possible overlaps in functionality with existing systems and decide where new functionality should be implemented.
These decisions should be made early in the process to limit the system costs and the time.

6. The System we are developing
Context Diagram
Other
System 1
Other
System 3
Other
System 5
The System we are developing
Other
System 4
Other
System 6
Other
System 2

7. Context Diagram
ATM Machine

8. Data Flow Diagram

9. Data Flow Diagram Used to show end-to-end processing in a system
DFDs show the entire sequence of actions that take place from an input being processed to the corresponding output that is the system’s response.

10. Data Flow Diagram
Sink
External
Entities
Source

11. Data Flow Diagram Sink External Entities Source
An outside system that sends or receives data, communicating with the system being diagrammed.
Source

12. Data Flow Diagram
Data Flow

13. Data Flow Diagram Data Flow
The route that data takes between the external entities, processes and data stores.

14. Data Flow Diagram
Process

15. Data Flow Diagram Process
A process is anything that changes the data, to produce an output.

16. Data Flow Diagram
Data Store

17. Data Flow Diagram Data Store
Files or repositories that hold information for later use, such as a database table or a membership form.

18. Data Flow Diagram
Process
Source
Sink
Data Store
Data Flow

19. Data Flow Diagram
Data Flow
Process
Source
Sink
Data Store

20. Data Flow Diagram

21. Data Flow Diagram
A CUSTOMER orders food, and that process returns a bill to the customer. The order goes to the KITCHEN. The process of ordering the food, also sends inventory details to the INVENTORY database and the order to the ORDER database. The INVENTORY database sends inventory details onto a Generate Reports process, which also receives the order from the ORDER database. The Generate Reports process sends a Report to the MANAGER who sends the inventory order to the Order Inventory process, and that process sends the inventory details back to the INVENTORY database, and sends the inventory order to the SUPPLIER.

22. Data Flow Diagram
A CUSTOMER(EXTERNAL ENTITY) will ORDER FOOD(PROCESS); The ORDER FOOD process will send an ORDER to the KITCHEN(EXTERNAL ENTITY); The ORDER FOOD process will send an ORDER to the ORDER(DATA STORE); The ORDER FOOD process will send an INVENTORY DETAILS to the INVENTORY(DATA STORE); The INVENTORY data store sends the INVENTORY DETAILS to the GENERATE REPORTS(PROCESS); The ORDER data store sends the ORDER to the GENERATE REPORTS(PROCESS); The GENERATE REPORTS process sends REPORTS to the MANAGER(EXTERNAL ENTITY); The MANAGER external entity sends the INVENTORY ORDER to the ORDER INVENTORY(PROCESS); The ORDER INVENTORY process send INVENTORY DETAIL back to the INVENTORY(DATA STORE); The ORDER INVENTORY process send INVENTORY ORDER to the SUPPLIER(EXTERNAL ENTITY);

23. Data Flow Diagram

24. Data Flow Diagram

25. Data Flow Diagram
When renting a video, a CUSTOMER requests a video from the Rent Video process, which sends a bill back to the CUSTOMER. The Rent Video process send rental information to the RENTAL database which sends the rental information onto the Generate Rental Report process, which passes a Rental report onto the MANAGER. When returning a video, a CUSTOMER sends the Video and Rental Information onto the Return Video process, which sends a Return Receipt back to the CUSTOMER. The Return Video process sends Video Information onto the VIDEO LIBRARY database, which sends Video Information back to the Rent Video Process (mentioned previously). The Return Video process also sends Rental information onto the RENTAL database (mentioned previously).

26. Data Flow Diagram
A CUSTOMER(EXTERNAL ENTITY) send a VIDEO REQUEST to RENT VIDEO(PROCESS); The RENT VIDEO process will send a BILL to the CUSTOMER(EXTERNAL ENTITY); The RENT VIDEO process will send RENTAL INFO to the RENTAL(DATA STORE); A CUSTOMER(EXTERNAL ENTITY) send VIDEO RENTAL INFO to RETURN VIDEO(PROCESS); The RETURN VIDEO process send a RETURN RECEIPT to the CUSTOMER(EXTERNAL ENTITY); The RETURN VIDEO process send VIDEO INFO to the VIDEO LIBRARY(DATA STORE); The RETURN VIDEO process send RENTAL INFO to the RENTAL(DATA STORE); The VIDEO LIBRARY data store send VIDEO INFO to RENT VIDEO(PROCESS); The RENTAL data store send RENTAL INFO to GENERATE RENTAL REPORT(PROCESS); The GENERATE RENTAL REPORT process sends a RENTAL REPORT to the MANAGER(EXTERNAL ENTITY) ;

27. Data Flow Diagram

28. Data Flow Diagram

29. Activity Diagram

30. Activity Diagram
Process models show the overall process and the processes that are supported by the system.

31. Activity Diagram
We’ll use UML Activity Diagrams to represent process flows.

32. Activity Diagram
Start
Stop

33. Activity Diagram Start Stop
The Start Node is also called the Initial Note.
Stop
The Stop Node is also called the Final Note.

34. Activity Diagram
Condition

35. Activity Diagram Condition
The condition defines a guard which must evaluate to true in order to traverse the node.

36. Activity Diagram
Action

37. Activity Diagram Action
An action may be physical, such as Inspect Forms, or electronic, such as Display Student Screen.

38. Activity Diagram
Decision

39. Activity Diagram Decision
The flows leaving a decision will normally include conditions

40. Activity Diagram
Fork
Join

41. Activity Diagram Fork Join
This denotes the beginning of parallel activity.
Join
All flows going into the join must reach it before processing can continue.

42. Activity Diagram
Join
Start
Action
Fork
Stop
Decision
Condition

43. Activity Diagram

44. Activity Diagram

45. Activity Diagram
To enrol in college: "Fill out enrolment forms", if they are filled out incorrectly, then if there is help available, "Obtain Help", but if there is no help available, retry to "Fill out enrolment forms". If it's a trivial problem or the form are filled out correctly, proceed to "Enrol in University. Once you've enrolled, two things can happen in parallel; (1) you can "Attend University Overview Presentation", and (2) you can "Enrol in Seminar(s), an "Make initial Tuition Payments".

46. Activity Diagram
Fill Out Enrollment Forms IF the forms are filled out incorrectly THEN IF it’s a big problem THEN IF there is help available THEN “Obtain Help” ELSE Return to “Fill Out Enrollment Forms” ELSE it’s a trivial problem so “Enrol in University” ELSE “Enrol in University” Happening in Parallel (Concurrently): Attend university Enrol in Seminar(s)  Make Initial Tuition Payment

47. Activity Diagram

48. Activity Diagram

49. Activity Diagram
To buy a ticket: "Show Your Ticket at the Check-In Counter" then "Verify that Ticket". If the Ticket has a problem, "Refer the Passenger to the Customer Services" and exit. Otherwise “Check-in the Luggage”. When "Accepting the Luggage", check if it is “Subject to a Fee”, if it is “Pay Fees”, otherwise don't. In either case “Issue a Boarding Pass” and exit.

50. Activity Diagram
Show Your Ticket at the Check-In Counter; Verify the Ticket; IF the Ticket is NOT OK THEN Refer to CUSTOMER SERVICES; EXIT; END IF; Check in Luggage; Accept Luggage; IF Luggage is Subject to Fee THEN Pay Fee; Issue Boarding Pass;

51. Activity Diagram

52. Activity Diagram

53. Use Case Diagram

54. Use Case Diagram
Actor

55. Use Case Diagram Actor Can represent: Human
Peripheral device (hardware)
External system or subsystem
Time or time-based event

56. Use Case Diagram
Use Cases

57. Use Case Diagram Use Cases
A sequence of actions that provide something of measurable value to an actor.

58. Use Case Diagram
Associations

59. Use Case Diagram Associations
An association exists whenever an actor is involved with an interaction described by a use case.

60. Use Case Diagram
System
Boundary

61. Use Case Diagram System Boundary Optional
Indicates the scope of the system, anything within the box represents functionality that is in scope and anything outside the box is not.
Optional

62. Use Case Diagram
Packages

63. Use Case Diagram Packages Optional
Packages allow you to organize use cases into groups. When a Use Case becomes to complex, it’s better to divide it into packages.
Optional

64. Use Case Diagram
System
Boundary
Actor
Use Cases
Packages
Associations

65. Use Case Diagram
Actor
Use Case
Association
System
Boundary
Package

66. Use Case Diagram

67. Use Case Diagram
You see a "Man with Chainsaw“ walking down the road. You think “I wonder is that a Halloween costume (if so, it’s SCARY). Maybe there a defending against Zombies (if so, it’s SCARY and VIOLENT), or maybe they are a Psycho Killer (if so, it’s SCARY and VIOLENT again)” Then you think “Wait, maybe it’s their OCCUPATION, maybe they’re a Lumberjack or a Juggler”.

68. Use Case Diagram
A "Man with Chainsaw" is either: - Wearing a SCARY Halloween costume - a VIOLENT and SCARY Zombie Defender - a VIOLENT and SCARY Psycho Killer - has an OCCUPATION of Lumberjack - has an OCCUPATION of Juggler

69. Use Case Diagram

70. Use Case Diagram

71. Use Case Diagram
The Airport "Passenger Service" system presents the PASSENGER with the following menu options: (1) Check-In (2) Automated Check-In (3) Express Check-In (4) Boarding If they select (1) they get the help of a CHECK-IN REPRESENTATIVE. Both the CUSTOMS OF THE DESTINATION AIRPORT and the BAGGAGE TRANSPORTATION will be "Requesting a Passenger List".

72. Use Case Diagram
The PASSENGER actor can use the "Passenger Service“ system to choose between: (1) Check-In (with the help of a CHECK-IN REPRESENTATIVE actor) (2) Automated Check-In (3) Express Check-In (4) Boarding Both the CUSTOMS OF THE DESTINATION AIRPORT actor and the BAGGAGE TRANSPORTATION actor will be "Requesting a Passenger List“ from the "Passenger Service“ system.

73. Use Case Diagram

74. Use Case Diagram

75. Use Case Diagram (advanced features)

76. Use Case Diagram Generalization
A parent use case (or actor) may be specialized into one or more child use cases (or actors) that represent more specific forms of the parent.

77. Use Case Diagram
Generalization

78. Use Case Diagram
Generalization

79. Use Case Diagram <<include>> <<extend>>
The inclusion of the functionality of one use case within another. For example, if I am taking a car journey, then the Use Case “Drive Car” is definitely required.
<<extend>>
The extension of the use case to include optional functionality. For example, if I am taking a car journey, then the Use Case “Fill Petrol Tank” may be required.

80. Use Case Diagram System Boundary Actor Use Cases Packages Association
<<include>>
Generalization
<<extend>>

81. Use Case Diagram include Actor Use Case extend Association Package
Generalization
System Boundary

82. Use Case Diagram

83. Use Case Diagram

84. Use Case Diagram
When using the ONLINE SHOPPING system, a WEB CUSTOMER can either be an already REGISTERED CUSTOMER or a NEW CUSTOMER. A REGISTERED CUSTOMER can "View Items" and "Make a Purchase". A NEW CUSTOMER can also "View Items", but they cannot yet "Make a Purchase" as they have to add their name to the "Client Register". "Make a Purchase" is made up of several processes, two of which must be: "View Items" and "Checkout". "View Items" requires two external processes, both an "Authentication" process and an "Identity Provider“ process. "Checkout" requires three external processes, an "Authentication" process, an "Identity Provider“ process, and a "Paypal" process. "Client Register" requires the "Authentication" process.

85. Use Case Diagram
There is a general WEB CUSTOMER actor, and two instances of it, the REGISTERED CUSTOMER actor and the NEW CUSTOMER actor. When using the ONLINE SHOPPING system, a REGISTERED CUSTOMER can "View Items" and "Make a Purchase". When using the ONLINE SHOPPING system, a NEW CUSTOMER can also "View Items", but they cannot yet "Make a Purchase" as they have to add their name to the "Client Register". "Make a Purchase" is a Use Case that has to include two other use cases: "View Items" and "Checkout". "View Items" requires two external actors, both an "Authentication" actor and an "Identity Provider“ actor. "Checkout" requires three external actors, an "Authentication" actor, an "Identity Provider“ actor, and a "Paypal" actor. "Client Register" requires the "Authentication" actor.

86. Use Case Diagram

87. Use Case Diagram

88. Use Case Diagram
When using the BANK SYSTEM, the first thing a CUSTOMER has to do is "Open an Account" with the help of a BANK EMPLOYEE. Once their account is open, they can either "Deposit Funds" or "Withdraw Funds", both of which will "Update the Balance". If the Amount in the Account exceeds £10,000 because of a "Deposit Funds" action, a bonus is added to the balance. Also if the Account is over 55 years, the Balance gets a bonus added. As well as a CUSTOMER actor, there is a FOREIGN EXCHANGE CUSTOMER actor, who can do everything a CUSTOMER actor can do, as well as bring able to "Convert Currency".

89. Use Case Diagram
In the BANK SYSTEM, there is a CUSTOMER actor who can do the following: (1) "Open an Account" (with the help of a BANK EMPLOYEE actor) (2) "Deposit Funds“, which will include "Update the Balance“. (3) "Withdraw Funds", which will “include Update the Balance". The "Deposit Funds“ will check if the balance exceeds £10,000, and based on that CONDITION, a “Calculate Bonus” will occur. Also if the Account is over 55 years , a “Calculate Bonus” will occur. As well as a regular CUSTOMER, there is a FOREIGN EXCHANGE CUSTOMER, who can do everything a CUSTOMER can do, as well as bring able to "Convert Currency".

90. Use Case Diagram

91. Use Case Diagram
BANK
SYSTEM

92. Class Diagram

93. Class Diagram
Name
Attributes
Class
Methods

94. Class Diagram Class Attributes Methods Name
The class includes a name, and a collection of attributes and methods. The classes will be added to and altered as the design becomes more and more refined.
Methods

95. Class Diagram
Association

96. Class Diagram Association
An association exists whenever a class is involved with an interaction with another class.

97. Class Diagram
Generalization

98. Class Diagram Generalization
A parent class may be specialized into one or more child classes that represent more specific forms of the parent. In design this is called Generalization, in development it’s Inheritance.

99. Class Diagram
Name
Attributes
Class
Methods
Generalization
Association

100. Class Diagram Association Class Generalization Name Name Attributes
Methods
Methods
Association
Class
Generalization
Name
Attributes
Methods

101. Class Diagram

102. Class Diagram
In general a CUSTOMER can place more than one ORDER. The CUSTOMER has a credit rating. The ORDER can dispatch and close orders.
There are two specific types of CUSTOMER, a CORPRATE CUSTOMER and a PERSONAL CUSTOMER. The difference being that a CORPRATE CUSTOMER will be given a reminder to pay their invoices, and they can request a total bill for the month.

103. Class Diagram CUSTOMER(a:name, address, m:creditRating())
ORDER(a:date received, isPrepaid, number, price, m:dispatch(), close())
CORPORATE CUSTOMER(a:contactName, creditRating, creditLimit, m:remind(), billForMonth())
PERSONAL CUSTOMER(a:creditCard#, m:)
CUSTOMER (1 –– n) ORDER
CUSTOMER  CORPORATE CUSTOMER
CUSTOMER  PERSONAL CUSTOMER

104. Class Diagram
ORDER
CUSTOMER
CORPRATE CUSTOMER
PERSONAL CUSTOMER

105. Class Diagram

106. Class Diagram
A STUDENT takes a specific ENROLLMENT of a given SEMINAR. Once they are enrolled the STUDENT name is added to the SEMINAR list. The STUDENT has to be eligible to enroll, and must record the number of seminars taken. The SEMINAR can add and drop students. The ENROLLMENT can get the average mark to date and get the final mark.
A PROFESSOR will give the SEMINAR, and one PROFESSOR can give zero or more seminars.

107. Class Diagram
STUDENT(a:Name, Address, Phone, , Student#, AverageMark, m:isEligibleToEnroll(), getSeminarsTaken())
SEMINAR(a:Name, Seminar#,Fees, m:addStudent(), dropStudent())
ENROLLMENT(a:MarksRecieved m:getAverageToDate(), getFinalMark())
PROFESSOR(a:Name, Address, Phone#, , Salary m:)
STUDENT (1 –– n) ENROLLMENT
SEMINAR (1 –– n) ENROLLMENT
STUDENT (n –– n) SEMINAR
PROFESSOR (1 –– n) SEMINAR

108. Class Diagram
ENROLLMENT
STUDENT
SEMINAR
PROFESSOR

109. Class Diagram

110. Class Diagram (advanced features)

111. Class Diagram Aggregation Composition
A relationship where the child can exist independently of the parent, e.g. Class (parent) and Student (child). Delete the Class and the Students still exist.
Composition
A relationship where the child cannot exist independent of the parent, e.g. House (parent) and Room (child). Delete the House and the Rooms cease to exist.

112. Class Diagram Association Generalization Aggregation Class Composition
Name
Generalization
Attributes
Methods
Aggregation
Class
Composition

113. Class Diagram Association Class Aggregation Generalization Composition
Name
Name
Attributes
Attributes
Methods
Methods
Association
Class
Aggregation
Generalization
Name
Name
Attributes
Attributes
Methods
Methods
Composition

114. Class Diagram

115. Class Diagram A CUSTOMER can own several TICKETs.
Each TICKET can be associated with from 1 to 4 COUPONs.

116. Class Diagram CUSTOMER(a:dateOfBirth, name m:)
TICKET(a:ticketCode, number m:)
COUPON(a:dateOfRedemption, Class, standBy, mealCode m:)
CUSTOMER ( n) TICKET
COUPON (1, <> 1) TICKET

117. Class Diagram
CUSTOMER
TICKET
COUPON

118. Class Diagram

119. Class Diagram
An ADDRESSBOOK is composed of several CONTACTs, each contact has an ADDRESS and a PHONE number.
The ADDRESS can be either a main postal address or the alternative postal address.
The PHONE number can be either a main phone number or an alternative phone number.

120. Class Diagram ADDRESSBOOK(a:Introduction m:) CONTACT(a:name, email m:)
ADDRESS (a:name, postalCode, city, country m:)
PHONE(a:internationalAreaCode, prefix, number m:)
CONTACT ( <*> n) ADDRESSBOOK
CONTACT (1 –--main–-- 1) ADDRESS
CONTACT (1 –alternative– 1) ADDRESS
CONTACT (1 –--main–-- 1) PHONE
CONTACT (1 –alternative– 1) PHONE

121. Class Diagram
AddressBook
Contact
Address
Phone

122. Class Diagram