EKT 421 SOFTWARE ENGINEERING System Modelling Part II Dr. Nik Adilah Hanin Zahri adilahhanin@unimap.edu.my

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

3. Structural Models Class Diagram

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

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.

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

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.

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

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

Example : Consultation Class

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

Generalization Hierarchy

Generalization Hierarchy with Details

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.

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

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

Example : Classes and Association Patient 1 1 Patient record

Example : Classes and Associations in the MHC-PMS

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

Example : Aggregation Association Patient Record Patient Consultation

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

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

Example of Complete Class Diagram

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.

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.

Exercise : Answer

4. Behavioral Models

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

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

Example : Activity Model of Insulin Pump’s Operation

Example : Sequence Diagram for Order Processing

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

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

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!

State Diagram Example

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

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

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

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

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

Example 2 : State Diagram of a Microwave Oven

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.

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.

Substates of Microwave Oven Operation

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

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

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

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

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.

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