Lecture 2: Information Engineering

Dr. Taysir Hassan Abdel Hamid October 12, 2015

Outline

• UML Diagrams * Behavioral Diagrams: Use Case, Interaction

Diagrams (Activity, Sequence and Timing diagrams)

Business Use Case Diagram

• Business Use Case diagrams are used to represent the functionality provided by an organization as a whole

• They answer the questions "What does the business do?" and "Why are we building the system?"

• Business Use Case diagrams are drawn from the organizational perspective

• They do not differentiate between manual and automated processes

• Business Use Case diagrams show the interactions between business use cases and business actors

Business Use Case Diagram cont.

• When using UML to build software, business modeling can help to understand the context of the system to be build

• If we fail to understand the business, we may make faulty assumptions about what the software should do and how it can best be used by the business community

• The "world around the system" is an important consideration when building software

• Business modeling gives the team a view of the business itself, the workflows within it, and the way the new system will help automate portions of the workflow

Elements of Business Use CasesElement Representation Notation

Business use cases

Business actors

Business workers

A business actor is anyone or anything that is

external to the organization but interacts with it (Individual,

group, company,…)Secondary Actor

It represents the workflow within the organization. It keeps focus on what the

business is doing Named in the form of

<verb><noun>

A business worker is a role within the organization

Primary Actor

Associations

An arrow from a business actor or a business worker to a use

case suggests that the actor or worker initiates the use case

Business Use Case Diagram (Airlines Example)

Practice(Restaurant Example)

To Do

Use Case Diagram

• Use cases represent system functionality, the requirements of the system from the user's perspective

• Use cases just focus on automated processes

• Use Case diagrams show the interactions between use cases and actors

•There is not a one-to-one relationship between business use cases and use cases

Actor

• An actor is anyone or anything that is outside the system’s scope but interacts with it (Individual, group, company,…)

• There are three primary types of actors: • Users of the system

physical person, or a user who will be directly using the system

• Other systems that will interact with the system being built

• Time Time becomes an actor when the passing of a certain amount of

time triggers some event in the system (out of control)

Elements of Use Case Diagram

Use Case

• It is the functionality the system will provide a value to the end user

• Use cases are an implementation-independent:• High-level view of what the user expects from the system• Focus on what the system should do, not how the system will do it

• A typical system will have somewhere between 20 and 70 use cases

• The use cases should be named in user terms, not technical terms, and should be meaningful to the customer

Elements of Use Case Diagram

Use Case cont.

• So, when you have the final list of use cases, how do you know if you've found them all?

- Is each functional requirement in at least one use case? If a requirement is not in a use case, it will not be implemented.

- Have you considered how each end user will be using the system?

- What information will each end user be providing for the system?

- What information will each end user be receiving from the system?

- Have you considered maintenance issues? Someone will need to start the system and shut it down.

- Have you identified all of the external systems with which the system will need to interact?

- What information will each external system be providing to the system and receiving from the system?

Elements of Use Case Diagram

Use Case: Flow of Events

• To actually build the system, though, you'll need more specific details. These details are written as the flow of events

• The purpose of the flow of events is to document the flow of logic through the use case

• Although it is detailed, the flow of events is still implementation-independent

Elements of Use Case Diagram

Use Case: Flow of Events cont.

• This document will describe in detail what the user of the system will do and what the system itself will do

• Notice the pattern in the flow of events: • The user does something, then • The system does something in response, • Then the user does something, then the system responds, and so on

Elements of Use Case Diagram

Use Case: Flow of Events cont.

It includes:• *A brief description: Each use case should include a short description that explains what the use case will do

• Preconditions: list any conditions that have to be met before the use case can start at all. For example, the precondition for one use case may be that another use case has run

• *Flow of events

• Post conditions: are conditions that must always be true after the use case has finished executing. Like preconditions, post conditions can be used to add information about the order in which the use cases are run

Elements of Use Case Diagram

Use Case: Flow of Events Types

• There are three types of flows:

• Primary flow is the "happy day" scenario, or the most frequently used path through the use case

• Alternate flows are deviations from the primary flow that do not suggest an error condition

• Error flows are deviations from the primary or alternate flows that suggest some sort of error condition. Error flows suggest that there is a problem with the system itself

Elements of Use Case Diagram

Use Case: Flow of Events Users

• There are three primary users of the flow of events:

1- The customers will be reviewing this document to make sure it accurately reflects their expectations

2- The system designers will be using it to create the system design and eventually to build the system

3- The quality assurance team will use the flow of events to create test scripts

The flow of events must give them enough information to understand the sequence of events that needs to occur through the use case

Elements of Use Case Diagram

Relationships

• The association relationship is used to show the relationship between a use case and an actor

• There are three types of relationships between use cases

• Includes relationship • Extends relationship• Generalization relationship

These relationships are used when there is a certain amount of commonality between the use cases

There is only one relationship allowed between actors. This is a generalization relationship

Elements of Use Case Diagram

Relationships: Association

• Association relationship is used to show the relationship between a use case and an actor

• Every use case must be initiated by an actor, With the exception of use cases in includes and extends relationships

Elements of Use Case Diagram

Relationships: Includes

• Includes relationship allows one use case to use the functionality provided by another use case • This relationship can be used in one of two cases:

• First, if two or more use cases have a large piece of functionality that is identical•The second case where an includes relationship is helpful is a situation in which a single use case has an unusually large amount of functionality

• An includes relationship suggests that one use case always uses the functionality provided by another

Elements of Use Case Diagram

<<includes>>

Purchase Ticket Check Credit

Relationships: Extends

• Extends relationship allows one use case the option to extend the functionality provided by another use case

• It is very similar to an includes relationship, because in both of these types of relationships, you separate some common functionality into its own use case

Elements of Use Case Diagram

• An abstract use case is one that is not started directly by an actor. Instead, an abstract use case provides some additional functionality that can be used by other use cases.

• Abstract use cases are the use cases that participate in an includes or extends relationship

<<extends>>

Change Reservation Check Credit

Relationships: Generalization

• Generalization relationship is used to show that several actors or use cases have some commonality

• For example, you may have two types of customers. If the type A customers will be initiating some use cases that type B customers will not, it's probably worth including the actor generalizations. If both types of customers use the same use cases, it's probably not necessary to show an actor generalization

Elements of Use Case Diagram

Salaried Employee

Employee

Hourly Employee

Phone Salesperson

Salesperson

In person Salesperson

Interaction Diagrams

• Shows, step-by-step, flows through a use case:- What objects are needed for the flow- What messages the objects send to each other- What actor initiates the flow - What order the messages are sent

• Sequence and Collaboration diagrams: - Show the same information but is organized differently

- Show it in a way that is more useful to developers- Help to define how the system will do- Focus on objects (classes) that will be created to

implement the functionality spelled out in the use cases

Interaction Diagrams

• The steps involved in creating them:- Find the Objects

(Examine the nouns in the flow of events)

(Take care of attributes)- Finding the Actors

(External stimulus (who or what) that starts flow of events)

- Add Messages(Communication)

Sequence Diagrams

• Sequence diagrams are interaction diagrams ordered by time

• Each diagram represent one of the flows through a use case

•Sequence Diagram users:•Users can look at these diagrams to see the specifics of their business processing

•Analysts see the flow of processing in the Sequence diagrams

•Developers see objects that need to be developed and operations for those objects

•Quality assurance engineers can see the details of the process and develop test cases based on the processing

Sequence Diagrams

• Actors and Objects shown at the top of the diagram

• Each object has a lifeline, drawn as a vertical dashed line below the object - The lifeline begins when the object is instantiated and ends when the object is destroyed

• A Message is drawn between the lifelines of two objects to show that the objects communicate (each message will become an operation). Messages can also be reflexive, showing that an object is calling one of its own operations

28

Sequence Diagram

• A sequence diagram is • An interaction diagram that

details how operations are carried out.

• What messages are sent and when.

• Sequence diagrams are organized according to time

Object: Class

Lifeline

Operations

Message

• Depending on the type of action that was used to generate the message, message could be one of:

• synchronous call• asynchronous call• asynchronous signal• create• delete• reply

Messages (synchronous call)

• Synchronous call typically represents operation call - send message and suspend execution while waiting for response. Synchronous call messages are shown with filled arrow head.

Messages (asynchronous call)

• Asynchronous call - send message and proceed immediately without waiting for return value. Asynchronous messages have an open arrow head.

Create Message

• Create message is sent to a lifeline to create itself. It is shown as a dashed line with open arrowhead (looks the same as reply message), and pointing to the created lifeline's head.

Delete Message

• Delete message (called stop in previous versions of UML) is sent to terminate another lifeline.

Reply Message

• Reply message to an operation call is shown as a dashed line with open arrow head (looks similar to creation message).

Activity Diagrams

• Activity contains activity nodes which could be:

• action• object• control

May contain actions such as

• Occurrences of primitive functions, such as arithmetic functions.

• Communication actions, such as sending of signals.

• Manipulations of objects, such as reading or writing attributes or associations.

38

Activities Diagram

Activity diagrams describe the workflow behaviour of a system

Start

Fork

Branch

MergeJoint

End

Activity partition

• Activity partition may be shown using a swimlane notation - with two, usually parallel lines, either horizontal or vertical, and a name labeling the partition in a box at one end. Any activity nodes, e.g. actions and edges placed between these lines are considered to be contained within the partition.

Example of process order

Examples of Activity Diagrams (1. Online Shopping)

• Online customer can browse or search items, view specific item, add it to shopping cart, view and update shopping cart, checkout. User can view shopping cart at any time. Checkout is assumed to include user registration and login.

Examples of Activity Diagrams (2. Document Management Process)

• A document goes through different state or stages - it is created, reviewed, updated, approved, and at some point archived. Different roles participating in this process are Author, Reviewer, Approver, and Owner. These roles are represented on the diagram by partitions rendered as horizontal "swimlanes".

2. Document Management Process

Timing Diagrams

• Timing diagrams are UML interaction diagrams used to show interactions when a primary purpose of the diagram is to reason about time.

• Timing diagrams focus on conditions changing within and among lifelines along a linear time axis.

• Timing diagrams describe behavior of both individual classifiers and interactions of classifiers, focusing attention on time of events causing changes in the modeled conditions of the lifelines.

Timing Diagrams (Cont…)

• The following nodes and edges are typically drawn in a UML timing diagram: lifeline, state or condition timeline, destruction event, duration constraint, time constraint.

Timing Diagrams (Cont…)

• Lifeline is a named element which represents an individual participant in the interaction.

Timing Diagrams (Cont…)

• Timing diagram could show states of the participating classifier or attribute, or some testable conditions, such as a discrete or enumerable value of an attribute.

Timing Diagrams (Cont…)

• Duration constraint is an interval constraint that refers to a duration interval. The duration interval is duration used to determine whether the constraint is satisfied.

Timing Diagrams (Cont…)

• Time constraint is an interval constraint that refers to a time interval. The time interval is time expression used to determine whether the constraint is satisfied.

Example 1: Alzheimer’s Stages