Software

Engineering
SYSTEM MODELING
 Goal
understand how graphical models can be used to represent software
systems
understand why different types of model are required and the
fundamental system modeling perspectives of context, interaction,
structure, and behavior
introduction to some of the diagram types in the Unified
Modeling Language (UML) and how these diagrams may be used in
system modeling;
Focus
◦ Context models
◦ Interaction models
◦ Structural models
◦ Behavioral models
◦ Model-driven engineering
 Introduction
is the process of developing abstract models of a system, with each
model presenting a different view or perspective of that system.
It represents the system using some kind of graphical notation
Models are used
◦ During the requirements engineering process to help derive the requirements
for a system,
◦ During the design process to describe the system to engineers implementing
the system
◦ After implementation to document the system’s structure and operation
You may develop models of both the existing system and the
system to be developed
Models

a system model leaves out detail.

It is an abstraction of the system being studied rather than an alternative representation
of that system.
An abstraction deliberately simplifies and picks out the most salient characteristics.
Different models to represent the system
1. An external perspective, where you model the context or environment
of the system. i.e ERP(Financial, data source)
2. An interaction perspective where you model the interactions between
a system and its environment or between the components of a system.
3. A structural perspective, where you model the organization of a
system or the structure of the data that is processed by the
system{systems architecture}.
4. A behavioral perspective, where you model the dynamic behavior of
the system and how it responds to events/external stimuli
Different models to represent the system
1. A structural perspective, where you model the organization of a
system or the structure of the data that is processed by the
system{systems architecture}.

2. A behavioral perspective, where you model the dynamic behavior of

the system and how it responds to events/external stimuli
Different models to represent the system
1. An external perspective, where you model the context or environment
of the system. i.e ATM System

2. An interaction perspective where you model the interactions between

a system and its environment or between the components of a system
Types of UML Diagrams To Represent a System
1. Activity diagrams,
◦ show the activities involved in a process or in data processing.
2. Use case diagrams,
◦ show the interactions between a system and its environment.
3. Sequence diagrams,
◦ show interactions between actors and the system and between
system components.
4. Class diagrams,
◦ show the object classes in the system and the associations
between these classes.
5. State diagrams,
◦ show how the system reacts to internal and external events
Use of the Diagrams
1. As a means of facilitating discussion about an existing or proposed
system amongst the software engineers
2. As a way of documenting an existing system.
3. As a detailed system description that can be used to generate a
system implementation.
Context models
Context models are used to illustrate the operational context
of a system
◦ they show what lies outside the system boundaries.
Identifies the entities outside the system that interface to it in
some way
normally show that the environment includes several other
automated systems.
Show the other systems in the environment, not how the
system being developed is used in that environment
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
Context models-Library Mng System
Context models-Mental Health Mng System
Context models- ATM SYSTEM
Interaction models
Systems involve
◦ User interactions
◦ System interactions
User Interaction
◦ Input/output-helps identify user needs
System interaction
◦ Between systems-Helps identify communication issues
◦ Component Interaction
◦ Between components in a system
Interaction models to Cover
Types
◦ Use case modeling
◦ Sequence diagrams
Interaction models-Use case modeling
a simple scenario that describes what a user expects from a
system.

aim to present a graphical overview of the functionality

provided by the system

Identifies the actors involved in an interaction and names the

type of interaction

identify the individual interactions between the system and

its users or other systems.
Actor
◦ an object or set of objects, external to the system, which interacts
with the system to get some meaningful work done.
◦ Actors could be human, devices, or even other systems
◦ Represented as stick figures
◦ a customer withdraws cash from an ATM. Here, customer is a
human actor
Use Case
◦ A functionality provided by a system
◦ represented as a named ellipse
◦ withdraw cash is a functionality that the ATM provides
◦ Name others
Subject
◦ Its simply the system under consideration. Use cases apply to a
subject. For example, an ATM is a subject,
Graphical Representation

An actor is represented by a stick figure and name of the actor

is written below it.
A use case is depicted by an ellipse and name of the use case
is written inside it.
The subject is shown by drawing a rectangle. Label for the
system could be put inside it.
Use cases are drawn inside the rectangle, and actors are drawn
outside the rectangle
Use case involving the role medical receptionist
Use Case Relationships

Three types of relationships exist among use cases:

◦ Include relationship

◦ Extend relationship

◦ Use case generalization

Include Relationship
Are used to depict common behavior that are shared by
multiple use cases
For example, consider an email application. A user can send
a new mail, reply to an email he has received, or forward an
email. However, in each of these three cases, the user must
be logged in to perform those actions

Include relationship is
depicted by a dashed
arrow with a «include»
Extend Relationship
Are used to depict any variation to an existing use case.
Used to link an optional usecase to primary usecase
Puts additional behavior to an existing usecase
Generalization Relationship
Are used to represent the inheritance between use cases. A
derived use case specializes some functionality it has
already inherited from the base use case.
Identifying Actors
Who gets most of the benefits from the system?
Who keeps the system working?

Identifying Use cases

what are the functionality they can obtain from the system.
Any use case name should start with a verb like, "Check
balance"
Identify Actors, usecases
Actors Usecase

Consider a library, where a member can perform two

operations: issue book and return it. A book is issued to
a member only after verifying his credentials. Draw a
use case diagram for the problem.
Interaction models- Sequence diagrams
shows the sequence of interactions that take place during a
particular use case or use case instance
used to represent or model the flow of messages, events and
actions between the objects or components of a system
Characteristics
Represents an interaction (messages) exchanged among collaborating
objects for a specific result
It shows time sequence not easily shown in a collaboration diagram
It does not show relations between objects
It can show general forms that do not deal with objects but with class
interaction
Used more for real time types of applications

Try
1. Write down the sequence of exchange for issuing a book, for making a
sale,ATM withdrawal in a supermarket assuming you the librarian or
cashier or bank respectively
Structural models
Display the organization of a system in terms of the
components that make up that system and their relationships
Types
◦ Class diagrams
Class Diagrams
Graphical representation of static view of the system and represents
different aspects of the application
used when developing an object-oriented system model to show the
classes in a system and the associations between these classes.
an object class name
◦ as a general definition of one kind of system object
Attributes
◦ Property shared by all instances of a class. It lies in the
second compartment in class rectangle.
Operations
◦ An execution of an action can be performed for any object of a class
look at the world, identify the essential objects, and represent these as
classes
Structural Models-Class Diagram
Example
Classes
◦ Patient
◦ Patient Record
each patient has exactly one record and each record maintains
information about exactly one patient.
show the data entities, their associated attributes, and the relations
between these entities
LIS-Classes and Associations
Structure

1. The name of the object class is in the top section.

2. The class attributes are in the middle section.
◦ This must include the attribute names and, optionally,
their types.
3. The operations associated with the object class are in the
lower section of the rectangle.
Generalization

used to manage complexity.

Rather than learn the detailed characteristics of every
entity that we experience, we place these entities in more
general classes
Aggregation

Objects in the real world are often composed of different

parts
The UML provides a special type of association between
classes called aggregation that means that one object (the
whole) is composed of other objects (the parts).
we use a diamond shape next to the class that represents
the whole.
Class Diagram Example
Behavioral models
are models of the dynamic behavior of the 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.
Includes
◦ 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 but this is not always the case.

Ex
◦ a phone billing system will accept information about calls made by a customer,
calculate the costs of these calls, and generate a bill to be sent to that customer
◦ real-time systems are often event driven with minimal data processing
◦ a landline phone switching system responds to events such as ‘receiver off hook’ by generating a dial
tone, or the pressing of keys on a handset by capturing the phone number,
Data-driven modeling
show the sequence of actions involved in processing input data and
generating an associated output.
Show the entire sequence of actions that take place from an input being
processed to the corresponding output, which is the system’s response.
Include
◦ Activity Diagrams
◦ Data Flow Diagrams
Activity Diagram
◦ Its basically a flow chart to represent the flow form one activity
to another activity. The activity can be described as an operation
of the system.
The most important shape types:
◦ rounded rectangles represent actions;
◦ diamonds represent decisions;
◦ bars represent the start (split) or end (join) of concurrent
activities;
◦ a black circle represents the start (initial state) of the workflow;
◦ an encircled black circle represents the end (final state).
Activity Diagram Example
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
◦ For example, a system controlling a valve may move from a
state ‘Valve open’ to a state ‘Valve closed
◦ Do not show the flow of data within the system
◦ Suitable for real-time systems
Example
Software testing
Objectives
◦ understand the stages of testing from testing, during development to acceptance testing by
system customers

◦ techniques that help you choose test cases that are geared to discovering program defects

◦ understand test-first development, where you design tests before writing code and run these
tests automatically

◦ Understand differences between component, system, and release testing

Testing
◦ helps to show that a program does what it is intended to do and to discover program defects
before it is put into use

Goals
◦ To demonstrate to the developer and the customer that the software meets its requirements
◦ Custom-Test for every requirement
◦ Generic-Test for all features plus combination of them

{Validation Testing used}

◦ To discover situations in which the behavior of the software is incorrect, undesirable, or does
not conform to its specification
◦ system crashes, unwanted interactions with other systems, incorrect computations, and data corruption

{Defect Testing used}

Validation Vs Defect Testing

Testing can only show the presence of errors, not their absence
Testing is part of a broader process of software verification and validation (V & V).
◦ ‘Validation: Are we building the right product?’

◦ ‘Verification: Are we building the product right?’

V&V concerned with checking that software being developed meets its specification
and delivers the functionality expected by the people paying for the software.
verification is to check that the software meets its stated functional and non-functional
requirements

Validation is to ensure that the software meets the customer’s expectations

Ultimate goal of V&V

establish confidence that the software system is ‘fit for purpose’.

◦ system’s purpose, the expectations of the system users, and the current marketing
environment for the system
1. Software purpose
◦ The more critical the software, the more important that it is reliable
◦ safety-critical system vs data collection system

2. User expectations
◦ May tolerate failures at beginning if benefit outway but expect with time to be more
reliable {iTax}

3. Marketing environment
◦ Presence of competing products, the price that customers are willing to pay for a
system, and the required schedule for delivering that system
Test cases
◦ are specifications of the inputs to the test and the expected output
from the system (the test results), plus a statement of what is being
tested

Test data
◦ are the inputs that have been devised to test a system
Types of Test Cases

Testing can either be done manually or using an automated testing

tool.
◦ Manual - This testing is performed without taking help of automated
testing tools.
◦ Automated This testing is a testing procedure done with aid of automated
testing tools
Sample Test Case

Test Case 1: Check results on entering valid User Id & Password

Test Case 2: Check results on entering Invalid User ID &

Password

Test Case 3: Check response when User ID is Empty & Login

Button is pressed
Sample Test Case

http://testing4easy.blogspot.co.ke/2012/01/test-cases-for-atm.html
Standard Test Cases

Prepare a test case for Card Validation at ATM

Types of Testing
1. Development testing,
◦ where the system is tested during development to discover bugs and defects. System
designers and programmers

2. Release testing,
◦ where a separate testing team tests a complete version of the system before it is
released to users.
◦ The aim
◦ check that the system meets the requirements of system stakeholders

3. User testing,
◦ where users or potential users of a system test the system in their own environment
◦ Acceptance Testing-Customer tests before accepting
Development testing
◦ includes all testing activities that are carried out by the team developing the system.

Include
1. Unit testing,
◦ individual program units or object classes are tested.
◦ focus on testing the functionality of objects or methods.
◦ Loops, statements etc.

2. Component testing,
◦ where several individual units are integrated to create composite components.
◦ Component testing should focus on testing component interfaces.

3. System testing,
◦ where some or all of the components in a system are integrated and the system is tested
as a whole.
◦ focus on testing component interactions. i.e ATM.
Release Testing

the process of testing a particular release of a system that is

intended for use outside of the development team
◦ Done by customers and intended users
Aim
◦ to convince the supplier of the system that it is good enough for use.
◦ show that the system delivers its specified functionality, performance, and dependability, and
that it does not fail during normal use.
◦ Include black-box testing and White-Box testing
Release Testing Include

Black Box testing-

It is carried out to test functionality of the program. It is also
called ‘Behavioral’ testing.
The tester in this case, has a set of input values and
respective desired results.
On providing input, if the output matches with the desired
results, the program is tested ‘ok’, and problematic otherwise
White-box testing

It is conducted to test program and its implementation, in order to

improve code efficiency or structure.
In this testing method, the design and structure of the code are
known to the tester.
To Be COntinued
To Be COntinued