1. EKT 421 SOFTWARE ENGINEERING
System Modelling
Part II
Dr. Nik Adilah Hanin Zahri

2. Today’s Topics Structural models Behavioral models
Model-driven engineering

3. 3. Structural Models
Class Diagram

4. Structural Models
Structural models of software display the organization of a system in terms of the components that make up that system and their relationships
Structural models types:
Static models shows the structure of the system design
Dynamic model shows the organization of the system when it is executing

5. Class Diagrams
Class diagrams are 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 that indicates that there is some relationship between these classes
Example : In MHC-PMS system, an object can represent as a patient, a prescription, doctor, etc.

6. Class
What is a class?
A class in an object oriented system provides an abstraction of a well defined set of responsibilities
A class consists of three parts:
Class Name
Class Attributes
Class Operations

7. Class Class Name: The name of the class appears in the first partition
Class Attributes:
Attributes are shown in the second partition.
The attribute type is shown after the colon.
Attributes map onto member variables (data members) in code.

8. Class Class Operations (Methods):
Operations are shown in the third partition. They are services the class provides.
The return type of a method is shown after the colon at the end of the method signature.
The return type of method parameters are shown after the colon following the parameter name.
Operations map onto class methods in code

9. Visibility and Access
The +, - and # symbols before an attribute and operation name in a class denote the visibility of the attribute and operation
+ denotes public attributes or operations
- denotes private attributes or operations
# denotes protected attributes or operations

10. Example : Consultation Class

11. Relationship between Classes
Inheritance (or Generalization):
Represents an “is-a” relationship.
An abstract class name is shown in italics.
SubClass1 and SubClass2 are specializations of SuperClass

12. Generalization Hierarchy

13. Generalization Hierarchy with Details

14. Generalization
Generalization is an everyday technique that we use to manage complexity
Rather than learn the detailed characteristics of every entity that we experience, we place these entities in more general classes (animals, cars, houses, etc.) and learn the characteristics of these classes
Different members of these classes have some common characteristics
e.g. squirrels and rats are rodents.

15. Generalization
In modeling systems, it is useful to examine if generalization is exist among the classes in a system
If changes are proposed, then you do not have to look at all classes in the system
In object-oriented languages (Java etc) generalization is implemented using the class inheritance mechanisms
The attributes and operations associated with higher-level classes are also associated with the lower-level classes

16. Relationship between Classes
Association
Simple association
A structural link between two peer classes.
There is an association between Class1 and Class2

17. Example : Classes and Association
Patient 1 1
Patient record

18. Example : Classes and Associations in the MHC-PMS

19. Relationship between Classes
Association
(i) Aggregation
A special type of association.
It represents a “part of” relationship.
Class2 is part of Class1.
Many instances (denoted by the *) of Class2 can be associated with Class1.
Objects of Class1 and Class2 have separate lifetimes.
Car
Engine

20. Example : Aggregation Association
Patient Record
Patient
Consultation

21. Relationship between Classes
Association
(ii) Composition
A special type of aggregation where parts are destroyed when the whole is destroyed.
Represents “ is entirely made of” relationship
Objects of Class2 live and die with Class1.
Class2 cannot stand by itself
Book
Page

22. Relationship between Classes
Association
(iii) Dependency
Exists between two classes if changes to the definition of one may cause changes to the other (but not the other way around).
Represent “uses temporarily” relationship
Class1 depends on Class2

23. Example of Complete Class Diagram

24. Example of Complete Class Diagram
The following can be observed from the above diagram:
Shape is an abstract class. It is shown in Italics.
Shape is a superclass. Circle, Rectangle and Polygon are derived from Shape. In other words, a Circle is-a Shape. This is a generalization / inheritance relationship.
There is an association between DialogBox and DataController.
Shape is part-of Window. This is an aggregation relationship. Shape can exist without Window.
Point is part-of Circle. This is a composition relationship. Point cannot exist without a Circle.
Window is dependent on Event. However, Event is not dependent on Window.
The attributes of Circle are radius and center. This is an entity class.
The method names of Circle are area(), circum(), setCenter() and setRadius().
The parameter radius in Circle is an in parameter of type float.
The method area() of class Circle returns a value of type double.
The attributes and method names of Rectangle are hidden. Some other classes in the diagram also have their attributes and method names hidden.

25. Exercise
Illustrate UML Class diagram for ATM Machine. The classes involved in the system are:
Bank, Account, Customer Info, Debit Card, Current Account, Saving Account, ATM Info, ATM Transaction, Withdraw Transaction, Change Pin, Transfer Money, Check Balance.
The Bank maintains personal and ATM information of each customer. The customer can access their account using Debit Card issued by the Bank. In this system there could be two types of Account: Current Account and Saving Account. Both use to share many of the properties and methods. The ATM Machine can perform multiple transactions such as Withdrawing cash, change pin, check balance and Transfer Money to each account.

26. Exercise : Answer

27. 4. Behavioral Models

28. Behavioral Models
Behavioral models are models of the dynamic behavior of a system as it is executing
shows what happens or what is supposed to happen when a system responds to a stimulus from its environment
Type of stimuli:
Data : Some data arrives that has to be processed by the system
Events : Some event happens that triggers system processing. Events may have associated data, although this is not always the case
Types of behavioral models:
Data-driven modelling
Event-driven modelling
Model driven engineering

29. Data-driven Modeling
Many business systems are data-processing systems that are primarily driven by data
controlled by the data input to the system
Data-driven models show the sequence of actions involved in processing input data and generating an associated output
Useful during the analysis of requirements as they can be used to show end-to-end processing in a system
Can be illustrated using data-flow diagrams (DFD) i.e. activity diagram and sequence diagram

30. Example : Activity Model of Insulin Pump’s Operation

31. Example : Sequence Diagram for Order Processing

32. Event-driven Modeling
Real-time systems are often event-driven, with minimal data processing.
e.g. : landline phone switching system responds to events such as ‘receiver off hook’ by generating a dial tone
Event-driven modeling shows how a system responds to external and internal events
Based on the assumption that a system has a finite number of states and that events (stimuli) may cause a transition from one state to another
Can be illustrated using state machine model

33. State Machine Models
Modelling the behaviour of the system in response to external and internal events
Are often used for modelling real-time systems
State machine models show system states as nodes and events as arcs between these nodes.
During an event, 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

34. UML State Diagrams
State diagram: Depicts data and behavior of a single object throughout its lifetime.
set of states (including an initial start state)
transitions between states
entire diagram is drawn from that object's perspective
What objects are best used with state diagrams?
large, complex objects with a long lifespan
domain ("model") objects
not useful to do state diagrams for every class in the system!

35. State Diagram Example

36. States state: conceptual description of the data in the object
represented by object's field values
entire diagram is drawn from the central object's perspective
only include states / concepts that this object can see and influence
don't include every possible value for the fields; only ones that are conceptually different

37. Transitions transition: movement from one state to another
signature [guard] / activity
signature: event that triggers (potential) state change
guard: boolean condition that must be true
activity: any behavior executed during transition (optional)
transitions must be mutually exclusive (deterministic)
must be clear what transition to take for an event
most transitions are instantaneous, except "do" activities

38. Internal activities
Internal activity: actions that the central object takes on itself
sometimes drawn as self-transitions (events that stay in same state)
entry/exit activities
reasons to start/stop being in that state

39. Super/Substates
When one state is complex, you can include substates in it.
drawn as nested rounded rectangles within the larger state
Caution: Don't over-use this feature.
easy to confuse separate states for sub-states within one state

40. Example 1 : State Diagram for ATM Machine
ATM software states at a bank

41. Example 2 : State Diagram of a Microwave Oven

42. States of Microwave Oven
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.

43. Stimuli of Microwave Oven
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.

44. Substates of Microwave Oven Operation

45. Model-driven Engineering (MDE)
MDE is an approach to software development where models are the principal outputs of the development process
The programs that execute on a hardware/software are generated automatically from the models platform
Engineers is no longer have to be concerned with programming language details or the specifics of execution platforms

46. Usage of Model-driven Engineering
Pros
Allows systems to be considered at higher levels of abstraction
Generating code automatically means that it is cheaper to adapt systems to new platforms
Cons
Models for abstraction and not necessarily right for implementation
Savings from generating code may be outweighed by the costs of developing translators for new platforms

47. Model-driven Architecture (MDA)
MDA is a model-focused approach to software design and implementation that uses a subset of UML models to describe a system
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

48. Types of Abstract System Model
A computation independent model (CIM)
These model the important domain abstractions used in a system. CIMs are sometimes called domain models.
A platform independent model (PIM)
These model the operation of the system without reference to its implementation
Usually described using UML models that show the static system structure and how it responds to external and internal events
Platform specific models (PSM)
These are transformations of the platform-independent model with a separate PSM for each application platform

49. Key Points
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.
Context models show how a system that is being modeled is positioned in an environment with other systems and processes.
Use case diagrams and sequence diagrams are used to describe the interactions between users and systems. Use cases describe interactions between a system and external actors; sequence diagrams add more information to these by showing interactions between system objects.
Structural models show the organization and architecture of a system. Class diagrams are used to define the static structure of classes in a system and their associations.

50. Key Points
Behavioral models are used to describe the dynamic behavior of an executing system. This behavior can be modeled from the perspective of the data processed by the system, or by the events that stimulate responses from a system.
Activity diagrams may be used to model the processing of data, where each activity represents one process step.
State diagrams are used to model a system’s behavior in response to internal or external events.
Model-driven engineering is an approach to software development in which a system is represented as a set of models that can be automatically transformed to executable code