Bài giảng Introduction to Software Engineering - Week 5: System Modeling - Nguyễn Thị Minh Tuyền

 of the new system are used during
 requirements engineering
 p Help explain the proposed requirements to other system
 stakeholders.
 p Are used for discussing design proposals and for
 documenting the system for implementation.
£ In a model-driven engineering process, it is possible to
 generate a complete or partial system implementation
 from the system model. 4
 Model the interactions 
 System perspectivesbetween a system and its 
 environment, or between the 
Model the context or components of a system
environment of the 
system
 external interaction 
 perspective perspective
 System
 behavioral structural 
 perspective perspective
Model the dynamic Model the organization 
behavior of the of a system or the 
system and how it structure of the data 
responds to events. that is processed by the 
 system.
 5
 Các loại biểu đồ UML
NGUYỄN Thị Minh 
Tuyền
 UML diagram types
The UML has many diagram types and supports many different types of system model.
Five diagram types could represent the essentials of a system:
 Activity diagram
 Show the activities involved in a process or in data processing.
 Use case diagram
 Show the interactions between a system and its environment.
 Sequence diagram
 Show interactions between actors and the system and between system 
 components.
 Class diagram
 Show the object classes in the system and the associations between 
 these classes.
 State diagram
 Show how the system reacts to internal and external events. 7
 Teamwork: 30 minutes
£ Each group chooses one of five diagrams in
 previous slide: Activity diagram, Use case
 diagram, Sequence diagram, Class Diagram, State
 Diagram and make a presentation:
1. What is it ?
2. When we use it ?
3. What are main elements of this diagram ?
4. Give an example and explanation.
 Use of graphical models
£ As a means of facilitating discussion about an
 existing or proposed system
 p Incomplete and incorrect models are OK as their role is
 to support discussion.
£ As a way of documenting an existing system
 p Models should be an accurate representation of the
 system but need not be complete.
£ As a detailed system description that can be used
 to generate a system implementation
 p Models have to be both correct and complete.
 9
 Topics covered
1. Context models
2. Interaction models
3. Structural models
4. Behavioral models
5. Model-driven engineering
 10
 Context models
£ Context models are used to illustrate the
 operational context of a system - they show what
 lies outside the system boundaries.
£ Social and organisational concerns may affect the
 decision on where to position system boundaries.
£ Architectural models show the system and its
 relationship with other systems.
 11
 System boundaries
£ System boundaries are established to define what
 is inside and what is outside the system.
 p They show other systems that are used or depend on
 the system being developed.
£ The position of the system boundary has a
 profound effect on the system requirements.
£ Defining a system boundary is a political judgment
 p There may be pressures to develop system boundaries
 that increase / decrease the influence or workload of
 different parts of an organization.
 12
 The context of the Mentcare
 system
 «system»
 Patient record
 system
 «system»
 «system»
 Management
 Admissions
 reporting
 system
 system
 «system»
 Mentcare
 «system» «system»
HC statistics Prescription
 system system
 «system»
 Appointments
 system
 13
 The context of the ATM system
 >
> Security system
 >
Branch Accounting 
 Account DB
 system
 >
 ATM System
 >
 >
 Branch counter 
 Usage DB
 system >
 Mantainance 
 system
 Nguyễn Thị Minh Tuyền 14
 Process perspective
£ Context models simply show the other systems in
 the environment, not how the system being
 developed is used in that environment.
£ Process models reveal how the system being
 developed is used in broader business processes.
£ UML activity diagrams may be used to define
 business process models.
 15
 Process model of involuntary detention
 Transfer to
 [not available]
 Confirm police station
detention
 decision Find secure
 place
 Transfer to
 Inform
 [available] secure hospital
 [dangerous] social care
 Inform
 patient of Inform next
 rights of kin
 Record Update
 Admit to
 detention register
 hospital
 decision [not
 dangerous]
 «system»
 «system» Mentcare
 «system» Admissions
 Mentcare system
 16
 Topics covered
1. Context models
2. Interaction models
3. Structural models
4. Behavioral models
5. Model-driven engineering
 17
 Interaction models
£ Modeling user interaction is important as it helps to
 identify user requirements.
£ Modeling system-to-system interaction highlights
 the communication problems that may arise.
£ Modeling component interaction helps us
 understand if a proposed system structure is likely
 to deliver the required system performance and
 dependability.
£ Two approaches to interaction modeling:
 p Use case diagrams and
 p sequence diagrams.
 18
 Use case modeling
£ Use cases were developed originally to support
 requirements elicitation and now incorporated into
 the UML.
£ Each use case represents a discrete task that
 involves external interaction with a system.
£ Actors in a use case may be people or other
 systems.
£ Represented diagrammatically to provide an
 overview of the use case and in a more detailed
 textual form.
 19
 Transfer-data use case
£ A use case in the Mentcare system
 Transfer data
 Medical receptionist Patient record system
 20
 Use cases in the Mentcare system 
involving the role ‘Medical Receptionist’
 Register
 patient
 Unregister
 patient
 View patient
 info.
 Medical
 receptionist
 Transfer data
 Contact
 patient
 21
Example: Use-case specification
 Sequence diagrams
£ Sequence diagrams are part of the UML and are
 used to model the interactions between the actors
 and the objects within a system.
£ A sequence diagram shows the sequence of
 interactions that take place during a particular use
 case or use case instance.
£ The objects and actors involved are listed along
 the top of the diagram, with a dotted line drawn
 vertically from these.
£ Interactions between objects are indicated by
 annotated arrows.
 25
 Sequence diagram for View patient 
 information
 Medical Receptionist
 P: PatientInfo D: Mentcare-DB AS: Authorization
 ViewInfo (PID) Object 
 report (Info, PID,
 UID) and actor
 authorize (Info,
 message UID)
 lifeline
 authorization
 alt
 [authorization OK] Patient info
 return 
 message
Condition
 [authorization fail] Error (no access)
 Alternatives
 26
Sequence diagram for Transfer Data
 Medical Receptionist PRS
 P: PatientInfo D: MHCPMS-DB AS: Authorization
 login ( )
 ok
 alt
 [sendInfo]
 updateInfo( ) updatePRS (UID )
 authorize (TF, UID)
 authorization
 update (PID)
 update OK
 Message (OK)
 [sendSummary]
 UpdateSummary( )
 summarize (UID )
 authorize (TF, UID)
 authorization
 :summary
 update (PID)
 update OK
 Message (OK)
 logout ( ) 27
 Topics covered
1. Context models
2. Interaction models
3. Structural models
4. Behavioral models
5. Model-driven engineering
 28
 Structural models
£ Display the organization of a system in terms of
 the components that make up that system and
 their relationships.
£ May be
 p static models, which show the structure of the system
 design, or
 p dynamic models, which show the organization of the
 system while executing.
£ Create structural models of a system when you are
 discussing and designing the system architecture.
 29
 Class diagrams
£ Used when developing an object-oriented
 system model to show the classes in a system
 and the associations between these classes.
£ An object class can be thought of as a general
 definition of one kind of system object.
£ An association is a link between classes.
£ During the early stages of the software
 engineering process, objects represent
 something in the real world.
 p For example: a patient, a prescription, doctor, etc.
 30
 UML classes and association
 1 1 Patient
 Patient record
 Association
Class
 31
Classes and associations in the MHC-
 PMS 
 Consultant
 1
 referred-to
 1..*
 1..* 1..* 1..* 1
 Condition Patient General
 practitioner
 diagnosed- referred-by
 with 1..*
 attends
 1..*
 prescribes
 Consultation Medication
 1..* 1..*
 1..*
 runs prescribes
 1..4 Treatment
 1..*
 Hospital
 Doctor
 32
The Consultation classClass name
 Consultation
 Doctors
 Date Attributes
 Time
 Clinic
 Reason
 Medication prescribed
 Treatment prescribed
 Voice notes
 Transcript
 ...
 Operations
 New ( )
 Prescribe ( )
 RecordNotes ( )
 Transcribe ( )
 ...
 33
 Generalization [1]
£ Is an everyday technique to manage complexity.
£ Rather than learn the detailed characteristics of
 every entity, we place these entities in more
 general classes (animals, cars, houses, etc.) and
 learn the characteristics of these classes.
£ Allows us to infer that different members of these
 classes have some common characteristics.
 34
 Generalization [2]
£ In object-oriented languages, such as Java,
 generalization is implemented using the class
 inheritance mechanisms built into the language.
£ In a generalization:
 p The attributes and operations associated with higher-
 level classes are also associated with the lower-level
 classes.
 p The lower-level classes are subclasses inherit the
 attributes and operations from their superclasses.
 These lower-level classes then add more specific
 attributes and operations.
 35
 A generalization hierarchy
 Doctor
 Hospital General
 doctor practitioner
Consultant Team doctor
 Trainee Qualified
 doctor doctor
 36
A generalization hierarchy with added detail
 Doctor
 Name
 Phone #
 Email
 register ( )
 de-register ( )
 Hospital doctor General practitioner
 Staff # Practice
 Pager # Address
 37
 Object class aggregation models
£ Show how classes that are collections are
 composed of other classes.
£ Are similar to the part-of relationship in semantic
 data models.
 38
The aggregation association
 Patient record
 1 1
 1 1..*
 Patient Consultation
 39
 Topics covered
1. Context models
2. Interaction models
3. Structural models
4. Behavioral models
5. Model-driven engineering
 40
 Behavioral models
£ Models of the dynamic behavior of a system as it
 is executing.
 p They show what happens or what is supposed to
 happen when a system responds to a stimulus from its
 environment.
£ You can think of these stimuli as being of two
 types:
 p Data Some data arrives that has to be processed by the
 system.
 p Events Some event happens that triggers system
 processing. Events may have associated data, although
 this is not always the case.
 41
 Data-driven modeling
£ Many business systems are data-processing
 systems that are primarily driven by data.
 p They are controlled by the data input to the system, with
 relatively little external event processing.
£ Data-driven models show the sequence of actions
 involved in processing input data and generating
 an associated output.
£ They are particularly useful during the analysis of
 requirements as they can be used to show end-to-
 end processing in a system.
 42
 An activity model of the insulin pump’s 
 operation
 processing step
 data flow (represented as activities)
 (represented as objects) 
Blood sugar Get sensor Sensor Compute Blood sugar
 sensor value data sugar level level
 Calculate
 insulin
 delivery
 Calculate
 Insulin Control Pump control Insulin
 pump
 pump pump commands requirement
 commands
 43
 Order processing
Purchase officer Supplier
 «datastore»
 :Order Budget
 Orders
 Fillin ( )
 Validate ( )
 [validation ok]
 Update (amount)
 Save ( )
 Send ( )
 44
 Event-driven modeling
£ Real-time systems are often event-driven, with
 minimal data processing.
£ Event-driven modeling shows how a system
 responds to external and internal events.
£ It is based on the assumption that
 p a system has a finite number of states and
 p events (stimuli) may cause a transition from one state to
 another.
 45
 State machine models
£ These model the behaviour of the system in
 response to external and internal events.
£ They show the system’s responses to stimuli so
 are often used for modelling real-time systems.
£ State machine models show system states as
 nodes and events as arcs between these nodes.
 p When an event occurs, the system moves from one
 state to another.
£ State charts are an integral part of the UML and
 are used to represent state machine models.
 46
 State diagram of a microwave 
 oven
 Full
 power Full power
 do: set power
 = 600
 Timer
 Waiting
 Number
 do: display
 Full Set time Operation
 time
 power do: get number do: operate
 exit: set time oven
 Half
 Half power
 Door
power
 Timer closed Cancel
 Start
 Door
 open Door
 Waiting
 Half power Enabled open
 do: set power Door do: display do: display
 = 300 closed 'Ready' time
 Disabled
 do: display
 'Waiting'
 47
 States and stimuli for the microwave 
 oven (a)
State Description
Waiting The oven is waiting for input. The display shows the current time.
Half power The oven power is set to 300 watts. The display shows ‘Half power’.
Full power The oven power is set to 600 watts. The display shows ‘Full power’.
Set time The cooking time is set to the user’s input value. The display shows
 the cooking time selected and is updated as the time is set.
Disabled Oven operation is disabled for safety. Interior oven light is on.
 Display shows ‘Not ready’.
Enabled Oven operation is enabled. Interior oven light is off. Display shows
 ‘Ready to cook’.
Operation Oven in operation. Interior oven light is on. Display shows the timer
 countdown. On completion of cooking, the buzzer is sounded for five
 seconds. Oven light is on. Display shows ‘Cooking complete’ while
 buzzer is sounding.
 48
States and stimuli for the microwave 
 oven (b)
 Stimulus Description
 Half power The user has pressed the half-power button.
 Full power The user has pressed the full-power button.
 Timer The user has pressed one of the timer buttons.
 Number The user has pressed a numeric key.
 Door open The oven door switch is not closed.
 Door closed The oven door switch is closed.
 Start The user has pressed the Start button.
 Cancel The user has pressed the Cancel button.
 49
Microwave oven operation
 Operation
 Time
 Checking
 OK Cook
 do: check do: run
 status generator
 Turntable Emitter Timeout
 fault fault
 Done
 Alarm
 do: buzzer on
 do: display
 for 5 secs.
 event
 Door open Cancel
 Disabled Waiting
 50