1. Chapter 5 – System Modeling

2. Chapter 5 System modeling
System modeling is the process of developing abstract models of a system, with each model presenting a different view or perspective of that system.
System modeling has now come to mean representing a system using some kind of graphical notation, which is now almost always based on notations in the Unified Modeling Language (UML).
System modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers.
Chapter 5 System modeling

3. Existing and planned system models
Models of the existing system are used during requirements engineering. They help clarify what the existing system does and can be used as a basis for discussing its strengths and weaknesses. These then lead to requirements for the new system.
Models of the new system are used during requirements engineering to help explain the proposed requirements to other system stakeholders. Engineers use these models to discuss design proposals and to document 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.
Chapter 5 System modeling

4. Chapter 5 System modeling
System perspectives
You may develop different models to represent the system from different perspectives. For example:
An external perspective, where you model the context or environment of the system.
An interaction perspective, where you model the interactions between a system and its environment, or between the components of a system.
A structural perspective, where you model the organization of a system or the structure of the data that is processed by the system.
A behavioral perspective, where you model the dynamic behavior of the system and how it responds to events.
Chapter 5 System modeling

5. Use of graphical models
There are three ways in which graphical models are commonly used:
As a means of facilitating discussion about an existing or proposed system
Incomplete and incorrect models are OK as their role is to support discussion.
As a way of documenting an existing system
Models should be an accurate representation of the system but need not be complete. (Because you may only wish to develop models for some parts of a system).
As a detailed system description that can be used to generate a system implementation
Models have to be both correct and complete.

6. Chapter 5 System modeling
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.
Chapter 5 System modeling

7. Chapter 5 System modeling
System boundaries
System boundaries are established to define what is inside and what is outside the system.
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.
Chapter 5 System modeling

8. The context of the MHC-PMS
Chapter 5 System modeling

9. Chapter 5 System modeling
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.
Chapter 5 System modeling

10. Process model of involuntary detention
Chapter 5 System modeling

11. Chapter 5 System modeling
UML diagram types
Chapter 5 System modeling

12. Chapter 5 System modeling
UML diagram types
Behavioral Diagrams (Dynamic):
Use case diagrams, which show the interactions between a system and its environment.
Activity diagrams, which show the activities involved in a process or in data processing .
Sequence diagrams, which show interactions between actors and the system and between system components.
State diagrams, which show how the system reacts to internal and external events.
Structural Diagrams (Static):
Class diagrams, which show the object classes in the system and the associations between these classes.
Chapter 5 System modeling

13. Chapter 5 System modeling
Use Case Diagram
Describes what the system does, without describing how the system does it
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.
Chapter 5 System modeling

14. Chapter 5 System modeling
Use Case Diagrams
A set of ACTORS : roles users can play in interacting with the system.
An actor is used to represent something that users our system.
A set of USE CASES: each describes a possible kind of interaction between an actor and the system.
Uses cases are actions that a user takes on a system
A number of RELATIONSHIPS between these entities (Actors and Use Cases).
Relationships are simply illustrated with a line connecting actors to use cases.
Use case
name
Chapter 5 System modeling

15. Chapter 5 System modeling
Use Case Relations
Chapter 5 System modeling

16. Examples of Use Cases, Behavioral Relationships for Student Enrollment
Both Enroll in Course and Arrange Housing include Pay Student Fees
in both cases students must pay their fees
The extended use case Student Health Insurance extends the basic use case Pay
Student Fees.
Communicates – used to connect an actor to a use case. The task of the use case is to give some sort of result that is beneficial to the actor in the system.
Includes – describes the situation in which a use case contains behavior that is common to more than one use case.
Extends - describes the situation in which one use case possesses the behavior that allows the new use case to handle a variation or exception from the basic use case.
Generalizes – implies that one thing is more typical than the other thing.

17. Extend and Include relationship
Includes
You have a piece of behavior that is similar across many use cases
Break this out as a separate use-case and let the other ones “include” it
Extend Relationship
Communicates – used to connect an actor to a use case. The task of the use case is to give some sort of result that is beneficial to the actor in the system.
Includes – describes the situation in which a use case contains behavior that is common to more than one use case.
Extends - describes the situation in which one use case possesses the behavior that allows the new use case to handle a variation or exception from the basic use case.
Generalizes – implies that one thing is more typical than the other thing.
Extends
A use-case is similar to another one but does a little bit more

18. Transfer-data use case
A use case in the MHC-PMS
Chapter 5 System modeling

19. Tabular description of the ‘Transfer data’ use-case
MHC-PMS: Transfer data
Actors
Medical receptionist, patient records system (PRS)
Description
A receptionist may transfer data from the MHC-PMS to a general patient record database that is maintained by a health authority. The information transferred may either be updated personal information (address, phone number, etc.) or a summary of the patient’s diagnosis and treatment.
Data
Patient’s personal information, treatment summary
Stimulus
User command issued by medical receptionist
Response
Confirmation that PRS has been updated
Comments
The receptionist must have appropriate security permissions to access the patient information and the PRS.
Use case scenarios are helpful in drawing sequence diagrams.

20. Use cases in the MHC-PMS involving the role ‘Medical Receptionist’
Chapter 5 System modeling

21. A Use Case Example of Student Enrollment
Use case diagrams provide the basis for creating other types of diagrams, such as class diagrams and activity diagrams
Use case diagrams provide the basis for creating other types of diagrams such as class diagrams and activity diagrams.

22. Chapter 5 System modeling
Activity Diagram
Show the sequence of activities in a process, including sequential and parallel activities, and decisions that are made. It is usually created for one use case.
Symbols
Rectangle with rounded ends represents an activity.
Arrow represents an event.
Diamond represents either decision (also called a branch) or a merge.
Long, flat rectangle represents a synchronization bar. These are used to show parallel activities, and may have one event going into the synchronization bar and several events going out of it, called a fork. A synchronization in which several events merge into one event is called a join.
Filled-in circle represents the initial state.
Black circle surrounded by a white circle represents the final state.
Swimlanes (Rectangles surrounding other symbols) indicate partitioning and are used to show which activities are done on which platform, such as a browser, server, or to show activities done by different user groups.
Chapter 5 System modeling

23. Activity Diagram (Generic Symbols).
Chapter 5 System modeling

24. Simple activity Diagram example
Chapter 5 System modeling

25. Activity Diagram example
Change Student Information use case.
Chapter 5 System modeling

26. Chapter 5 System modeling
Sequence diagrams
Illustrate a succession of interactions between classes or object instances over time.
Often used to show the processing described in use case scenarios.
Each use case scenario may create one sequence diagram.
Used to show the overall pattern of the activities or interactions in a use case.
A sequence diagram emphasizes the time ordering (sequence) of messages.
Chapter 5 System modeling

27. Specialized Symbols Used to Draw a Sequence Diagram
Actors and classes or object instances are shown in boxes along the top of the diagram
The leftmost object is the starting object and may be a person (for which a use case actor symbol is used), window, dialog box, or other user interface.
A vertical dashed line represents the lifeline for the class or object. While the vertical rectangle on the lifeline shows the focus of control when the object is busy doing things
Horizontal arrows show messages or signals that are sent between the classes. Solid arrowheads
represent synchronous calls, which are the most common. These are used when the sending class waits for a response from the receiving class, and control is returned to the sending class when the class receiving the message finishes executing.
Half (or open) arrowheads represent asynchronous calls, or those that are sent without an expectation of returning to the sending class.
Chapter 5 System modeling

28. Chapter 5 System modeling
A Sequence Diagram for Student Admission: Sequence Diagrams Emphasize the Time Ordering of Messages
Chapter 5 System modeling

29. Sequence diagram for View patient information
Chapter 5 System modeling

30. Sequence diagram for Transfer Data
Chapter 5 System modeling

31. Chapter 5 System modeling
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 may be static models, which show the structure of the system design, or dynamic models, which show the organization of the system when it is executing.
You create structural models of a system when you are discussing and designing the system architecture.
Chapter 5 System modeling

32. Chapter 5 System modeling
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.
Chapter 5 System modeling

33. Class diagrams.. A Class Diagram for Course Offerings
Chapter 5 System modeling

34. UML classes and association
Chapter 5 System modeling

35. Classes and associations in the MHC-PMS
Chapter 5 System modeling

36. The Consultation class
Chapter 5 System modeling

37. Class diagrams.. Associations (Multiplicity Constraints)
An association is a relationship among object classes.
The simplest type of relationship
Associations are shown as a simple line on a class diagram.
It has the same as cardinality on an entity-relationship diagram.

38. Class diagrams.. Associations Examples
Chapter 5 System modeling

39. Class diagrams.. Associations Examples
Chapter 5 System modeling

40. Class diagrams.. Whole/Part Relationships
When one class represents the whole object, and other classes represent parts.
The whole acts as a container for the parts. These relationships are shown on a class diagram by a line with a diamond on one end.
The diamond is connected to the object that is the whole.
Categories
Aggregation
Composition
Chapter 5 System modeling

41. Class diagrams.. Aggregation
Described as a “has a” relationship
Provides a means of showing that the whole object is composed of the sum of its parts (other objects).
Example: the department has a course and the course is for a department.
This is a weaker relationship, because a department may be changed or removed and the course may still exist.
The diamond at the end of the relationship line is not filled in..
Chapter 5 System modeling

42. Class diagrams.. Composition
Composition, a whole/part relationship in which the whole has a responsibility for the part.
It is a stronger relationship, and is usually shown with a filled-in diamond.
Keywords for composition are one class “always contains” another class. If the whole is deleted, all parts are deleted.
Think of composition as a stronger form of aggregation. Composition means something is a part of the whole, but cannot survive on it’s own.
Chapter 5 System modeling

43. Class diagrams.. Composition Example..
In a university there is a composition relationship between a course and an assignment as well as between a course and an exam. If the course is deleted, assignments and exams are deleted as well.
Chapter 5 System modeling

44. Class diagrams.. Example of aggregation and composition
A Library contains students and books.
Relationship between library and student is aggregation as a student can exist without a library and therefore it is aggregation.
Relationship between library and book is composition as a book cannot exist without a library and therefore its a composition.
Chapter 5 System modeling

45. Class diagrams.. General example of Class relations
Chapter 5 System modeling

46. Class diagrams.. Generalization/Specialization Diagrams
Describes a relationship between a general kind of thing and a more specific kind of thing
Described as an “is a” relationship
Used for modeling class inheritance and specialization
General class is a parent, base, or superclass
Specialized class is a child, derived, or subclass.
For example, a car is a vehicle and a truck is a vehicle. In this case, vehicle is the general thing, whereas car and truck are the more specific things.
Generalization relationships are used for modeling class inheritance
Chapter 5 System modeling

47. Class diagrams.. Inheritance example

48. Chapter 5 System modeling
Behavioral models
Behavioral models are models of the dynamic behavior of a system as it is executing. 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:
Data-driven models: Some data arrives that has to be processed by the system.
Events-driven models: Some event happens that triggers system processing. Events may have associated data, although this is not always the case.
Chapter 5 System modeling

49. Chapter 5 System modeling
Data-driven modeling
Many business systems are data-processing systems that are primarily driven by data. 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.
Chapter 5 System modeling

50. Sequence diagram is of illustrating the processing steps in a system
Chapter 5 System modeling

51. Event-driven modeling
Real-time systems are often event-driven, with minimal data processing. For example, a 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.
It is 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.
Chapter 5 System modeling

52. Chapter 5 System modeling
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. When an event occurs, the system moves from one state to another.
Statecharts are an integral part of the UML and are used to represent state machine models.
State diagrams show system states and events that cause transitions from one state to another. They do not show the flow of data within the system.
Chapter 5 System modeling

53. State diagram of a microwave oven
Chapter 5 System modeling

54. States and stimuli for the microwave oven (a)
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.
Chapter 5 System modeling

55. 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.
Chapter 5 System modeling

56. Microwave oven operation
For large system models, you need to hide detail in the models. One way to do this is by using the notion of a superstate that encapsulates a
number of separate states.
Chapter 5 System modeling

57. Model-driven engineering
Model-driven engineering (MDE) is an approach to software development where models rather than programs are the principal outputs of the development process.
The programs that execute are then generated automatically from the models.
Proponents of MDE argue that engineers no longer have to be concerned with programming language details or the specifics of execution platforms.
Chapter 5 System modeling

58. Usage of model-driven engineering
Model-driven engineering is still at an early stage of development, and it is unclear whether or not it will have a significant effect on software engineering practice.
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.
Chapter 5 System modeling

59. Model driven architecture
Model-driven architecture (MDA) was the precursor of more general model-driven engineering
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, in principle, to generate a working program without manual intervention.
Chapter 5 System modeling

60. Chapter 5 System modeling
Types of 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. The PIM is 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. In principle, there may be layers of PSM, with each layer adding some platform-specific detail.
Chapter 5 System modeling

61. Chapter 5 System modeling
MDA transformations
Chapter 5 System modeling

62. Multiple platform-specific models
Chapter 5 System modeling

63. Chapter 5 System modeling
Agile methods and MDA
The developers of MDA claim that it is intended to support an iterative approach to development and so can be used within agile methods.
The notion of extensive up-front modeling contradicts the fundamental ideas in the agile manifesto and I suspect that few agile developers feel comfortable with model- driven engineering.
If transformations can be completely automated and a complete program generated from a PIM, then, in principle, MDA could be used in an agile development process as no separate coding would be required.
Chapter 5 System modeling

64. Chapter 5 System modeling
Executable UML
The fundamental notion behind model-driven engineering is that completely automated transformation of models to code should be possible.
This is possible using a subset of UML 2, called Executable UML or xUML.
Chapter 5 System modeling

65. Features of executable UML
To create an executable subset of UML, the number of model types has therefore been dramatically reduced to these 3 key types:
Domain models that identify the principal concerns in a system. They are defined using UML class diagrams and include objects, attributes and associations.
Class models in which classes are defined, along with their attributes and operations.
State models in which a state diagram is associated with each class and is used to describe the life cycle of the class.
The dynamic behavior of the system may be specified declaratively using the object constraint language (OCL), or may be expressed using UML’s action language.
Chapter 5 System modeling

66. Chapter 5 System modeling
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 behavior.
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 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.
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.
Chapter 5 System modeling

67. Chapter 5 System modeling
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.
Chapter 5 System modeling