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.
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
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 assuming
you the librarian
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
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.
LIS-Classes and Associations
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.
SOFTWARE EVOLUTION
To Be COntinued