System Modeling with UML

◇

Context models

◇

Interaction models

◇

Structural models

◇

Behavioral models

30/10/2014

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 involves most of the time a graphical notation, the most widely used one being the Unified Modeling Language (UML).

◇

System modelling helps the analyst understand the functionality of the system and models are used to better communicate with customers.

30/10/2014

Chapter 5 System Modeling

◇ 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.

30/10/2014

Chapter 5 System Modeling

◇

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.

◇

As a detailed system description that can be used to generate a system implementation

• Models have to be both correct and complete.

30/10/2014

Chapter 5 System Modeling

◇

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.

30/10/2014

Chapter 5 System Modeling

◇

Activity diagrams, which show the activities involved in a process or in data processing.

◇

Use case diagrams, which show the interactions between a system and its environment.

◇

Sequence diagrams, which show interactions between actors and the system and between system components.

◇

Class diagrams, which show the object classes in the system and the associations between these classes.

◇

State diagrams, which show how the system reacts to internal and external events.

30/10/2014

Chapter 5 System Modeling

Context models

30/10/2014

Chapter 5 System Modeling

◇

Context models are used to illustrate the operational context of a system - they show what lies outside the system boundaries.

◇

Architectural models show the system and its relationship with other systems.

30/10/2014

Chapter 5 System Modeling

◇

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.

30/10/2014

Chapter 5 System Modeling

30/10/2014

Chapter 5 System Modeling

Interaction models

30/10/2014

Chapter 5 System Modeling

◇

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.

◇

Use case diagrams and sequence diagrams may be used for interaction modeling.

30/10/2014

Chapter 5 System Modeling

◇

Use cases were developed originally to support requirements elicitation.

◇

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 diagramatically to provide an overview of the use case and in a more detailed textual form.

◇

Use case models and sequence diagrams present interactions at different levels of detail and so may be used together.

30/10/2014

Chapter 5 System Modeling

◇

Sequence diagrams are part of 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.

30/10/2014

Chapter 5 System Modeling

Sequence diagram for Transfer Data

30/10/2014

Chapter 5 System Modeling

Structural models

30/10/2014

Chapter 5 System Modeling

◇

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.

30/10/2014

Chapter 5 System Modeling

◇

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 instance of a class (an object) 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.

◇

When you are developing models during the early stages of the software engineering process, objects represent something in the real world, such as a patient, a prescription, doctor, etc.

30/10/2014

Chapter 5 System Modeling

Mode detail on

Use Case Diagram

“Use cases are a means for specifying required usages of a system. Typically, they are used to capture the requirements of a system.

The key concepts associated with use cases are actors, use cases, and the system under consideration.

The users and any other systems that may interact with the subject are represented as actors. Actors always model entities that are outside the system.

The required behavior of the subject is specified by one or more use cases.

Use cases, actors, and systems are described using use case diagrams.” Source: UML Superstructure Specification v2.4.1 omg.org (summarized)

Actors: ◇

An actor is an external entity, it specifies a role played by a user or any other system that interacts with the system.

◇

An actor represents any entity (or entities) that exchanges information with the system. An actor in a use case diagram interacts with a use case to accomplish a specific goal.

◇

For example, for modeling a banking application, a customer entity is represented by an actor in the diagram.

Similarly, the person who provides the service at the counter.

◇

System boundary: A system boundary defines the scope of what a system will be. A system cannot have infinite functionality. So, it follows that use cases also need to have definitive limits defined. A system boundary of a use case diagram defines the limits of the system. The system boundary is shown as a rectangle spanning all the use cases in the system.

◇

Extend: A relationship from an extending use case to an extended use case that specifies how and when the behavior defined in the extending use case can be inserted into the behavior defined in the extended use case.

◇

Extend relationship is also used to design handling exceptions.

Difference between Generalization and Extension: ◇

When you establish a generalization relationship between use cases, this implies that the target use case can be replaced by the source use case. On the other hand, an extend relationship between use cases implies that the source use case enhances the functionality of the target use. The target use case in an extend relationship cannot be replaced by the source use case.

Draw a use case diagram for a university registration system:

The system is used by students to register for courses. Assume that the student accesses an electronic course catalog to find out about available courses.

Courses may have limited enrollment, so the registration process must include checks that places are available.

Students have to complete all pre-requisites of a course before being allowed to register to that course. A student may send a message to the department’s chair to request that the pre-requisite condition be overlooked if he is taking the required course in parallel.

◇ An ATM system has a switch that allows an operator to start and

shutdown the system. The operator can configure the system to connect it to the bank system. He can run a maintenance check process that checks that the system is working properly. When a problem is detected, the operator has to solve the problem or request a more specialized maintenance team to solve the problem.

The operator has to shut down the system until the other team arrives.

◇ A customer is required to insert his ATM card and enter his PIN. The

PIN and card ID will be sent to the bank for validation before any transaction. If the PIN is not valid, then a message “invalid PIN” is displayed. If the PIN is valid, the customer will be able to perform one of the following transactions: make a cash withdrawal, make a deposit, make a money transfer to previously saved accounts, make a balance inquiry.

Sequence Diagram

◇

An Interaction is a behaviour that comprises a set of messages exchanged between a set of objects within a context to accomplish a purpose.

◇

A message is a specification of a communication between objects that conveys information.

◇

In UML, interaction diagrams are used for the following purposes:

• to model the dynamic behavior of a system.
• To visualize the communication and sequence of message passing in the system

◇

A sequence diagram is two dimensional. Graphically a sequence diagram is a table that shows objects arranged along the X-axis and messages ordered in increasing time along the Y-axis.

◇

A Sequence Diagram should be modeled for the main scenario of the use case, and frequent or complex alternative scenarios.

◇

All systems/components are treated as black boxes

Actor: ◇

An Actor represents a role played by an entity that interacts with the system (e.g., by exchanging signals and data). An actor is external to the subject (i.e., in the sense that an instance of an actor is not a part of the instance of its corresponding subject). They typically represent roles played by human users, external hardware, or other systems.

◇

Note That:

1. An actor does not necessarily represent a specific physical entity but merely a particular role of some entity
2. A person/component may play the role of several different actors and, conversely, a given actor may be played by different persons.

Synchronous message A synchronous message is used when the sender waits for the receiver to process the message and returns before carrying on with another message. The arrowhead used to indicate this type of message is a solid one, like the one below.

◇

Asynchronous message

◇

An asynchronous message is used when the message caller does not wait for the receiver to process the message and return before sending other messages to other objects within the system. The arrowhead used to show this type of message is a line arrow like shown in the example below.

◇

The ordered sequence of events in a given sequence diagram is as follows:

◇

Place an order.

◇

Pay money to the cash counter.

◇

Order Confirmation.

◇

Order preparation.

◇

Order serving.

◇

Alternatives are used to designate a mutually exclusive choice between two or more message sequences.

◇

Alternatives allow the modeling of the classic “if then

else” logic (e.g. if I buy three items, then I get 20% off my purchases; else I get 10% off my purchase.)

◇

An alternative combination fragment is drawn using a frame.

◇

The word “alt” is placed inside the frame’s name box.

◇

The larger rectangle is then divided into what UML calls operand.

◇

Operands are separated by a dashed line (one are the messages following “then” path and another are the messages following “else” path).

◇

Each operand is given a guard to test against, and this guard is placed on the top of the operand. If an operand’s guard equates to “true”, then that operand is the operand to follow.

◇

Fig on the next slide shows the sequence starting at the top, with the bank object getting the check’s amount and the account’s balance.

◇

At this point in the sequence the alternative combination fragment takes over. Because of the guard “[balance >= amount]”, if the account’s balance is greater than or equal to the amount, then the sequence continues with the bank object sending the addDebitTransactrion and storePhotoOfCheck messages to the account object.

◇

However, if the balance is not greater than or equal to the amount, then the sequence proceeds with the bank object sending the addInsufficientFundFee and noteReturned Check message to the account object and the returnCheckmessage to itself. The second sequence is called when the balance is not greater than or equal to the amount because of the “[else]” guard.

Class Diagram

◇

Class diagram is a static diagram. It gives a static view of a system.

◇

Class diagram is not only used for visualizing, describing, and documenting different aspects of a system but also for constructing executable code of the software.

◇

UML Class diagram is a type of structure diagram.

◇

UML Class diagram gives an overview of a software system by displaying classes, attributes, operations, and their relationships.

◇

The attributes are generally written along with the visibility factor.

◇

Public, private, protected and package are the four visibilities which are denoted by +, -, #, or ~ signs respectively.

◇

Visibility describes the accessibility of an attribute of a class.

◇

Attributes must have a meaningful name that describes the use of it in a class

There are mainly three kinds of relationships in UML:

• Dependencies
• Generalizations
• Associations
  • Aggregation
  • composition

◇

A multiplicity is a factor associated with an attribute. It specifies how many instances of attributes are created when a class is initialized. If a multiplicity is not specified, by default one is considered as a default multiplicity.

◇

Let's say that there are 100 students in one college. The college can have multiple students (0..*).

Possible associations

• Zero to 1 (0…1)
• 1 to 1 (1..1)
• Zero to many (0… 6)
• 1 to many (1… *) : sometimes you want to stress out the fact that one is the minimum, like a plane has at least one engine, a course has at

Aggregation is a special type of association that models a whole-part relationship between aggregate and its parts.

In an aggregation relationship, the part object remains even when

the whole object is destroyed.

Aggregation relationship is denoted using a straight line with an empty arrowhead at one end.

◇

The composition is a special type of association which denotes strong ownership between two classes when one class is a part of another class.

◇

It is a two-way association between the objects.

◇

It is a whole/part relationship.

◇

If a composite is deleted, all other parts associated with it are deleted.

◇

Composition is described as an association decorated with a filled black diamond at the aggregate (whole) end.

◇

Here are some points which should be kept in mind while drawing a class diagram:

• The name given to classes in a diagram must be meaningful.
• The relationships between elements need to be identified and specified precisely (naming association ends, multiplicity, navigability).
• The responsibility for every class needs to be identified.
• For every class, a minimum number of properties should be specified.
• User notes should be included whenever you need to clarify some gray areas of the diagram.

Behavioral Models

30/10/2014

Chapter 5 System Modeling

◇

A UML activity diagram helps to visualize a certain use case at a more detailed level. It is a behavioral diagram that illustrates the flow of activities through a system.

◇

UML activity diagrams can also be used to depict a flow of events in a business process. They can be used to examine business processes in order to identify its flow and requirements.

◇

Activity diagram is another important behavioral diagram in UML diagram to describe dynamic aspects of the system.

e l p m ax E

• m a r g a i

D y t i v i t c A

◇

In the following slide we have an activity diagram that describes the workflow for processing an order:

◇

Once the order is received, the activities split into two parallel sets of activities. One side fills and sends the order while the other handles the billing.

◇

On the Fill Order side, the method of delivery is decided conditionally. Depending on the condition either the Overnight Delivery activity or the Regular Delivery activity is performed.

◇

Finally, the parallel activities combine to close the order.

30/10/2014

Chapter 5 System Modeling

◇

It’s a behavioral diagram. State diagrams are also referred to as State machines and Statechart Diagrams.

◇

The State machine diagram can be used for modeling discrete behaviour through finite state transition systems.

◇

A state diagram is used to model the dynamic behavior of a class in response to time and external stimuli.

◇

State – We use a rounded rectangle to represent a state.

A state represents the conditions or circumstances of an object of a class at an instant of time.

Figure – state notation

◇

Identify the initial state and the final terminating states.

◇

Identify the possible states in which the

• b j e c t c a n e x i s t (b o u n d a r y v a l u e s corresponding to different attributes guide us in identifying different states).

◇

Label the events which trigger these transitions.

State diagram of a microwave oven

power, a numeric keypad to input the cooking time, an alphanumeric display.