System modeling 

is the process of developing abstract models of a system, with each model

presenting a different view or perspective of that system. It is about representing a system
using some kind of graphical notation, which is now almost always based on notations in
the Unified Modeling Language (UML). Models help the analyst to understand the functionality
of the system; they are used to communicate with customers.
Models can explain the system from different perspectives:

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

Five types of UML diagrams that are the most useful for 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.

Models of both new and existing system are used during requirements engineering. Models of
the existing systems 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.

Context and process models

Context models are used to illustrate the operational context of a system - they show what lies
outside the system boundaries. Social and organizational concerns may affect the decision on
where to position system boundaries. Architectural models show the system and its
relationship with other systems.
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. Defining a system
boundary is a political judgment since there may be pressures to develop system boundaries
that increase/decrease the influence or workload of different parts of an organization.
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.

https://www.edrawmax.com/context-diagram/

Use case diagram

 Actors: The users that interact with a system. An actor can be a person, an
organization, or an outside system that interacts with your application or system.
They must be external objects that produce or consume data.
 Actor is someone interacting with use case (system function). Named by noun.
 Use Case
A use case represents a function or an action within the system. It’s drawn as an oval
and named with the function.

 Use Cases - System function (process – automated or manual).

• Named by verb. Do something

• Each Actor must be linked to a use case, while some use cases may not be linked to
actors.
How to Create a Use Case Diagram

1. Identifying Actors
Actors are external entities that interact with your system. It can be a person, another system
or an organization. In a banking system, the most obvious actor is the customer. Other actors
can be bank employee or cashier depending on the role you’re trying to show in the use case.

An example of an external organization can be the tax authority or the central bank. The loan
processor is a good example of an external system associated as an actor.

2. Identifying Use Cases

Now it’s time to identify the use cases. A good way to do this is to identify what the actors need
from the system. In a banking system, a customer will need to open accounts, deposit and
withdraw funds, request check books and similar functions. So all of these can be considered as
use cases.

3. Look for Common Functionality to use Include

Look for common functionality that can be reused across the system. If you find two or more
use cases that share common functionality you can extract the common functions and add it to
a separate use case. Then you can connect it via the include relationship to show that it’s
always called when the original use case is executed.

4. Is it Possible to Generalize Actors and Use Cases

There may be instances where actors are associated with similar use cases while triggering a
few use cases unique only to them. In such instances, you can generalize the actor to show the
inheritance of functions. You can do a similar thing for use case as well.

One of the best examples of this is “Make Payment” use case in a payment system. You can
further generalize it to “Pay by Credit Card”, “Pay by Cash”, “Pay by Check” etc. All of them
have the attributes and the functionality of payment with special scenarios unique to them

Include relationships - One use case (base) includes the functionality of another (inclusion case)
• Supports re-use of functionality

• Include relationship – a standard case linked to a mandatory use case.

Example: to Authorize Car Loan (standard use case), a clerk must run Check Client’s Credit
History (include use case).

• The standard UC includes the mandatory UC (use the verb to figure direction arrow).

• Standard use case can NOT execute without the include case ->tight coupling .

Extend relationships - One use case (extension) extends the behavior of another (base)

• Extend relationship – linking an optional use case to a standard use case. Extend relationship

• Example: Register Course (standard use case) may have

-Register for Special Class (extend use case)

– class for non-standard students, in unusual time, with

- special topics, requiring extra fees…).

 Standard use case can execute without the extend case -> loose coupling
Generalization example
EX2.

EX:3
The Pizza Ordering System
The Pizza Ordering System allows the user of a web browser to order pizza for home delivery.
To place an order, a shopper searches to find items to purchase, adds items one at a time to a
shopping cart, and possibly searches again for more items. When all items have been chosen,
the shopper provides a delivery address. If not paying with cash, the shopper also provides
credit card information. The system has an option for shoppers to register with the pizza shop.
They can then save their name and address information, so that they do not have to enter this
information every time that they place an order. Develop a use case diagram, for a use case for
placing an order, PlaceOrder. The use case should show a relationship to two previously
specified use cases, IdentifyCustomer, which allows a user to register and log in, and
PaybyCredit, which models credit card payments.
Class Diagram
Class diagrams are the main building block in object-oriented modeling. They are used to show
the different objects in a system, their attributes, their operations and the relationships among
them.
. For example, in an airline reservation system there would be classes such as Flight, Passenger
and Airport.
The main symbols shown on class diagrams are:
■ Classes, which represent the types of data themselves.
■ Associations, which show how instances of classes reference instances of other classes.
■ Attributes, which are simple data found in instances.
■ Operations, which represent the functions performed by the instances.
■ Generalizations, which are used to arrange classes into inheritance hierarchies.

Associations and multiplicity

 A multiplicity of 1 indicates that there must be exactly one instance linked to each
object at the other end of the association. For example, there can only be one Company
associated with each Employee
 A very common multiplicity is ∗, which is normally read as ‘many’, and means any
integer greater than or equal to zero. For example, many employees can be associated
 with a company; one possibility being that a company has no employees. Although
there is no theoretical upper bound, there is a practical upper bound that depends on
the amount of memory and processing capacity available.
 If there can be either zero or one object linked to an object at the other end of the
association, then the multiplicity is said to be ‘optional’, and the notation 0..1 is used.
So, for example, Figure 5.2 shows that there can be zero or one office per employee. In
other words, it is optional that an employee is assigned to an office (some may work at
home or in a job that does not require an office).
 You can also specify the multiplicity to be an interval, which is shown as two dots
between the lower and upper bound. An interval is also sometimes called a range. If, for
example, you determine that a sailboat can have between 1 and 3 masts, then you
would write 1..3 on the Mast end of the association. The 0..1 notation discussed above
is a special case of an interval. If an interval has no upper bound, then you use the
asterisk; therefore 0..∗ and ∗ mean the same thing, while 1..∗ means ‘at
least one’.

The notation 0..* in the diagram means “zero to many”.

Labeling associations

 An association name should be a verb or verb phrase, and is placed next to the middle
of the association. One class becomes the subject and the other class becomes the
object of the verb.
 The association between Employee and Company is called worksFor. You can read the
association in one direction as, ‘an employee works for a company’.
 Another way of labeling an association is to use a role name. Role names can be
attached to either or both ends of an association. A role name acts, in the context of the
 association, as an alternative name for the class to which it is attached. For example, in
the association between Person and BoardOfDirectors, boardMember is a role name
that describes the people who happen to be members of the board. You can read this
association as, ‘a board of directors has either zero or 3 to 8 persons as board
members’.
 For example, in the association between Company and BoardOfDirectors, we have
chosen not to add any label; the association would read, ‘a company has a board of
directors’

We can tell that for each Booking there must always be exactly one Passenger, but each
Passenger can have any number of Bookings (i.e. on different flights and dates). Similarly, for
each Booking there must always be exactly one SpecificFlight, but each SpecificFlight can have
any number of Bookings (up to the capacity of the aircraft, of course).

Reflexive associations

Reflexive Association

This occurs when a class may have multiple functions or responsibilities. For
example, a staff member working in an airport may be a pilot, aviation
engineer, a ticket dispatcher, a guard, or a maintenance crew member. If the
maintenance crew member is managed by the aviation engineer there could
be a managed by relationship in two instances of the same class.
Sequence Diagram and Communication Diagram
In the case of synchronous messages, the sender waits until it has received a response
Message before continuing.Theresponse message is represented by a dashed line with an open
arrowhead. If the content of the response message and the point at which the response
message is sent and received are clear from the context, then the response message may be
omitted in the diagram. In asynchronous communication, the sender continues after having
sent the message

Figure 8.1
You represent a message using an arrow, labeled with the message name and
optional arguments. You specify the order in which messages are sent by prefixing
each message using some numbering scheme.

Figure 8.4
The actor initiates the interaction via the user interface; the user interface sends a
requestToRegister message to the CourseSection, which in turn creates a Registration. The
Registration object then asks the Student to add it to the list of courses the student is taking,
and also asks the CourseSection to add it to the list of registered students.

Class diagram for the above sequence diagram.

In some cases, a sequence of messages must be repeated – in other words iteration must occur.
You show iteration using a combined fragment marked ‘loop’, as is illustrated in Figure 8.5. The
number of times to loop is specified
 A sequence diagram can show the destruction of an object using a big X symbol on a
lifeline. For example, Figure 8.7 shows what might happen when a booking in the airline
system is canceled.

Ex: Before drawing the sequence diagram, it’s necessary to identify the objects or actors that
would be involved in creating a new user account. These would be;

 Librarian
 Online Library Management system
 User credentials database
 Email system

Here are the steps that occur in the use case named ‘Create New Library User Account’.

 The librarian request the system to create a new online library account
 The librarian then selects the library user account type
 The librarian enters the user’s details
 The user’s details are checked using the user Credentials Database
 The new library user account is created
 A summary of the of the new account’s details are then emailed to the user

From each of these steps, you can easily specify what messages should be exchanged between
the objects in the sequence diagram. Once it’s clear, you can go ahead and start drawing the
sequence diagram.
EX 2:
Sequence diagram based on the class diagram
 Activity Diagram

Activity Diagram Example - Process Order

Process Order - Problem Description

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.

Activity Diagram Example - Student Enrollment

 An applicant wants to enroll in the university.

 The applicant hands a filled out copy of Enrollment Form.

 The registrar inspects the forms.

 The registrar determines that the forms have been filled out properly.
 The registrar informs student to attend in university overview presentation.

 The registrar helps the student to enroll in seminars

 The registrar asks the student to pay for the initial tuition.