CPE 310 SOFTWARE ENGINEERING

Spring Semester-2021

Dr. Nesrin AYDIN ATASOY

CONTENTS

Aim Of Lesson
Software engineering is about imagination and creativity. The process of creating something
apparently tangible from nothing. Software engineering methods have not yet been completely
analyzed and systematized. Software engineering is about the creation of large pieces of
software that consist of thousands of lines of code and involve many person months of human
effort.
Books, Videos and Online Course Documents
1. Software Engineering, Ian Sommerville, 9th edition, Addison-Wesley
2. Software Engineering For Students, Douglas Bell, 4th edition, AddisonWesley
3. Object - Oriented Software Engineering, Timothy C. Lethbridge and Robert Laganière,
2nd edition, McGraw- Hill
Evaluations
1 Mid-term, 1 Final Exam and 1 Project
WEEK 1: DEFINITION AND IMPORTANCE of SOFTWARE ENGINEERING

➢ What is software?

❖ Performing a defined function,

❖ With inputs and outputs,

❖ Working on any hardware,

❖ It is a product of computer program or programs.

❖ Configuration files used to set up these programs

❖ User documentation explaining how to use the software

❖ System documentation describing the structure of the software

❖ It includes all methods, tools, information and documents that can be used to
combine and manage logic, data, documents, human and program components
for a specific production purpose [1, 2].

❖
 The software can be examined as General and Special for Customer Software [3].

✓ General Software: It is software whose features are determined according to

the general need in the market. Ex: MS Office, Photoshop, AutoCAD.

✓ Special for Customer: It is the software whose features are determined

according to the needs of the customer. Ex: Pharmacy Stock Program,
University Automation Program.
➢ Hardware (Manufacturing)- Software (Development) Comparison

❖ Software is engineered, not manufactured.

❖ Once a hardware product has been manufactured, it is difficult or impossible to modify.
In contrast, software products are routinely modified and upgraded.
❖ In hardware, hiring more people allows you to accomplish more work, but the same
does not necessarily hold true in software engineering.
❖ Unlike hardware, software costs are concentrated in design rather than production.

➢ Software Deteriorates

❖ Software does not wear-out, but it does deteriorate due to changes

❖ Most software models a part of reality and reality evolves.
❖ If software does not evolve with the reality that is being modeled, then it deteriorates

➢ Where is the Software?

 ❖ In computer systems

Operating systems (eg: Windows, Linux)

End-user programs (eg:Photoshop,dreamveawer)

Compilers (eg: javac, pascal, gcc)

❖ Aircrafts, Space Shuttles (Eg: F16, Discovery Space Shuttle)

❖ Cellular Phones (Eg: IOS, Android etc.)
❖ Education (Eg: Distance Learning)
❖ Entertainment, Transportation
❖ Health systems, Military
❖ And many more….
➢ Granularity of Software

Trivial: 1 month, 1 programmer, 500 LOC, Ex: Intro programming assignments

Very small: 3 months, 1 programmer, 2000 LOC, Ex: Course project

Small: 1 year, 3 programmers, 50K LOC, Ex: Mobile App

Medium: 3 years, 10s of programmers, 100K LOC, Ex: Optimizing compiler

Large: 5 years, 100s of programmers, 1M LOC, Ex: MS Word, Excel

Very large: 10 years, 1000s of programmers, 10M LOC, Ex: Air traffic control,
Telecommunications, space shuttle

➢ What type of software?

❖ Small single-developer projects can typically get by without Software

Engineering.
o Typically no deadlines, small budget (freeware), not safetycritical

❖ Software Engineering is especially required for

o Medium to large projects (50,000 lines of code and up)
o Multiple subsystems
o Teams of developers (often geographically dispersed)
o Safety-critical systems (software that can kill people...)
 ➢ What is Software Engineering?

Software Engineering term first emerged in 1968 at the NATO Software Engineering
conference in Germany. It emerged with the evolution of Computer Science
discipline.[4].

Software Engineering has been described in many ways, some are as follows:

✓ Software engineering is obtained robust engineering principles to develop

economical software that works accurately and efficiently on real machines [5].

✓ Software engineering is an engineering science dealing with all situations related

to software production.

✓ Software engineering; applied for the development, operation and maintenance

of the software product; is a systematic, disciplined and measurable approach[6].

➢ Software Engineering is concerned with …

o Technical processes of software development
o Software project management
o Development of tools, methods and theories to support software production
o Getting results of the required quality within the schedule and budget
o Often involves making compromises
o Often adopt a systematic and organized approach
o Less formal development is particularly appropriate for the development of web-based
systems

➢ Software Engineering is important because

o Individuals and society rely on advanced software systems

o Produce reliable and trustworthy systems economically and quickly
o Cheaper in the long run to use software engineering methods and techniques for
software systems
 ➢ Fundamental activities being common to all software processes:

o Software specification: customers and engineers define software that is to be produced

and the constraints on its operation
o Software development: software is designed and programmed
o Software validation: software is checked to ensure that it is what the customer requires
o Software evolution: software is modified to reflect changing customer and market
requirements

➢ Software Engineer

Software Engineer is the software engineering job. However, person cannot do this job
without formal training. The software engineer is not just an encoder. The person who
knows best how to tell user requests to the computer. It is mostly related to people and
deals with the logical dimension of the software. Today, software engineering has
become a profession and has schools.

➢ Importance of Software Engineering

Computer software is now everywhere in our lives. For this, the goal of Software
Engineering;

• To eliminate the complexity of software development,

• True,
• Reliable,
• To produce suitable products.

Errors in software production show propagation. For this reason, error correction costs increase
gradually in the following stages. Its main goal is to realize the production with the lowest cost
and the highest quality. Therefore, the hardware cost is ineffective besides the cost of the
software. Table 1 shows error correction costs in software production [2].

Table 1. Error correction costs in software production.

Analysis 1

Design 5

Coding 10

Test 25

Acceptance
50
Test
 Operating 100

➢ Software Quality Assurance

The objectives of software quality assurance activities can be summarized as follows [2]:

✓ Reducing software costs,

✓ Facilitating software production management,
✓ Elimination of documentation and standard troubles.

Some software quality criteria are shown in Table 2.

Table 2. Sample software quality criteria.

Economy Completeness Reusability Effectiveness Integrity

Reliability Modularity Documentation Convenience Cleaning

Interchangeability Validity Generality Portability Maintainability

Essential attributes of good software:

➢ Maintainability

o Evolve to meet the changing needs of customers

o Software change is inevitable (see changing business environment)

➢ Dependability and security

o Includes reliability, security and safety

o Should not cause physical or economic damage in case of system failure

o Take special care for malicious users

➢ Efficiency

o Includes responsiveness, processing time, memory utilization

o Care about memory and processor cycles

➢ Acceptability
o Acceptable to the type of users for which it is designed

o Includes understandable, usable and compatible with other systems

➢ Software Perception by Individuals

Management, customers and analysts are the most important stakeholders in the perception of
software.

Administration according to an old belief, a good manager manages all projects. But this is
not true for today's projects. Because, In a constantly evolving world, a good manager must be
well-off with the latest technology.

Customer is the person who directs the project to be developed and determines the
qualifications of the project in line with his own wishes. Before starting software development,
it has a great role in understanding and analyzing the subject thoroughly.

Operator should analyze the subject very well before coding begins, design it with all the
details and then coding should begin.

➢ Participants and Roles

• Developing software requires collaboration of many people with different

backgrounds and interests.

• All the persons involved in the software project are called

participants (stakeholders)

• The set of responsibilities in the project of a system are defined

as roles.

• A role is associated with a set of tasks assigned to a participant.

• Role is also called stakeholder

• The same participant can fulfill multiple roles.

Case of roles:
➢ Why is software development difficult?

▪ Change (in requirements & technology)

o The “Entropy” of a software system increases with each change: Each implemented
change erodes the structure of the system which makes the next change even more
expensive (“Second Law of Software Dynamics”).
 o As time goes on, the cost to implement a change will be too high, and the system
will then be unable to support its intended task. This is true of all systems,
independent of their application domain or technological base.

➢ The problem domain (also called application domain) is difficult

➢ The solution domain is difficult
➢ The development process is difficult to manage
➢ Software offers extreme flexibility

▪ Dealing with Complexity

1. Abstraction

We use Models to describe Software Systems:

1. Object model: What is the structure of the system?

2. Functional model: What are the functions of the system?
3. Dynamic model: How does the system react to external events?
4. System Model: Object model + functional model + dynamic model

Other models used to describe Software System Development:

1. Task Model:
o PERT Chart: What are the dependencies between tasks?
o Schedule: How can this be done within the time limit?
o Organization Chart: What are the roles in the project?
2. Issues Model:
o What are the open and closed issues?
o What constraints were imposed by the client?
o What resolutions were made?
 2. Decomposition

➢ A technique used to master complexity (“divide and conquer”)

➢ Functional decomposition
➢ Object-oriented decomposition

3. Hierarchy

➢ We got abstractions and decomposition

o This leads us to chunks (classes, objects) which we view with object model
➢ Another way to deal with complexity is to provide simple relationships between the
chunks
➢ One of the most important relationships is hierarchy

➢ Software Classification

It is possible to classify the software into a number of classes according to development and
design.

✓ Ready commercial products

Produced to be sold to many different customers (Commercial Off The Shelf - COTS)

✓ Special Software

They are products prepared according to the needs of a single customer.

✓ System Software
It is the software that installs every time the computer is turned on and makes the computer
ready for use. The BIOS program on PCs does this task. This program is loaded into RAM
when the computer is started and remains in memory until it is turned off.

✓ Application Software

Usually, they are all programs outside of the system software. These softwares are programs
written to solve a certain problem using appropriate data processing techniques. Unlike system
and support software, it is written for a uniform application. For example; Microsoft Excel,
Microsoft Word, etc.

✓ Support Software

They are general-purpose computer programs that are not specific to any application and allow
certain commands to be performed. Sorting, copying, formatting, etc. like software that handles
transactions.

REFERENCES

1. Yazılım Mühendisliği Ders Notları; Yrd.Doç.Dr. Buket Doğan.

2. Yazılım Mühendisliği; Ali Arifoğlu, Ali Doğru.
3. BBS-651 Yazılım Mühendisliği Ders Notu; A. Tarhan,2010
4. Yazılım Mühendisliği Yöntemleri İleri Konular, Dr. Çağatay Çatal, 2012.
5. Naur and Randell, 1969.
6. IEEE, 1990
7. Yazılım Mühendisliği Temelleri; Dr. M. Erhan Sarıdoğan
8. Software Engıneerıng Lecture Notes, Benjamin Sommer
9. Object- Oriented Software Engineering Using UML, Patterns, and Java , Bernd
Bruegge & Allen H. Dutoit
 CPE 310 SOFTWARE ENGINEERING

Spring Semester-2023

Dr. Nesrin AYDIN ATASOY

Week 2: Software Life Cycles Process

Studies are carried out on various process models and new technologies to systematize
software development. The model is a guide on how to do software development activity and
how the general development order will be. The main target of these models; To define the
engineering processes (workflow consisting of predetermined steps) recommended to be

followed throughout the software development life cycle for project success.

➢ Software Development Life Cycle

➢ It is defined as all stages that a software goes through, including the
production phase and the usage phase.
➢ Since software functions and needs are constantly changing and
developing, they are thought of in the form of a cycle.
➢ Software life cycles should not be considered as unidirectional, linear.

➢ Software Life Cycle Basic Steps

• Planning: It is the stage where personnel and equipment requirements are
determined, feasibility study is carried out and the project plan is created.
• Analysis: The stage in which system requirements and functions are detailed.
The existing works are examined, basic problems are revealed.
• Design: It is the stage in which the basic structure of the software system that
will respond to the specified requirements is formed.

o Logical design; The structure of the proposed system is explained,

o Physical design; the components that contain the software and their
details.

• Implementation: It is the stage where coding, testing and installation work is

done.
 • Maintenance: It is the stage of troubleshooting and making new additions
after delivery.

Figure 1: Software lifecycle key steps.

➢ Software Life Cycle Data

Software development standards require the preparation of life cycle data. Some standards
require the way and format of the data is prepared, while others only define the content and
release the document format.

Lifecycle data must be able to be updated, read, deleted, archived and, if necessary,
transferred with ownership rights. The main purpose of preparing a life cycle data is to:

Identifying and recording the information required throughout the life cycle of the software
product,

✓ Helping the usability of the software product,

✓ Defining and controlling lifecycle processes,
✓ Keeping a history of data change,

Life cycle data of projects are usually stored in documents. Thus, these documents are very
important for a healthy project and product maintenance. Because documents are regular
environments where information is collected. The characteristics that the information should
have are as follows:

➢ Contradiction
➢ Completeness
➢ Verifiability
➢ Consistency
➢ Interchangeability
➢ Traceability
➢ Exhibitability
➢ Privacy
➢ Preservation
➢ Sensitivity

➢ Software Process Models

With the development of software technologies, existing models and methodologies also
develop and new models emerge. The hardware and software technologies of the relevant
period and the needs of the sector played an important role in the emergence of the models.

Using appropriate software development models plays a very important role in the
development of the software as more secure, accurate, understandable, testable and
maintainable.

➢ What is Process?

✓ It is a chain of steps performed for a specific goal. [IEEE]

✓ A process is a series of steps involving activities, constraints, and resources that
produce intended output of some kind.
✓ A process involves a set of tools and techniques.

➢ What is the software process?

• Activities, methods, practices and transformations used to develop and

maintain the software and its related products.
• It is a set of activities aimed at software development and maintenance.
 ➢ What is the Software Process Model?
It is a simplified representation of a software process from a specific point of view. Sample
perspectives:

Workflow: How are the activities sequenced?

Data-stream: How is the information ordered?

Role-act: Who is doing what?

➢ Reasons for Modeling a Process

➢ To form a common understanding

➢ To find inconsistencies, redundancies, omissions

➢ To find and evaluate appropriate activities for reaching process goals

➢ To tailor a general process for a particular situation in which it will be used

➢ Software Process Model Types

1. Waterfall Model
2. V Model
3. Prototype Model
4. Spiral model
5. RAD Model
6. Iterative Model
7. Incremental Model

Let's examine these methods:

1. Waterfall Model
The waterfall model is a classical model used in system development life cycle to create a
system with a linear and sequential approach. It is termed as waterfall because the model
develops systematically from one phase to another in a downward fashion. This model is
divided into different phases and the output of one phase is used as the input of the next
phase. Every phase has to be completed before the next phase starts and there is no
overlapping of the phases.

The sequential phases described in the Waterfall model are:

Requirements

Analysis

Design

Coding

Testing

Deployment
Maintenance

Figure 2 : The different sequential phases of the classical waterfall model.

1. Requirement Gathering: All possible requirements are captured in product requirement

documents.

2. Analysis Read: The requirement and based on analysis define the schemas, models and
business rules.

3. System Design: Based on analysis design the software architecture.

4. Implementation- Coding: Development of the software in the small units with functional
testing.

5. Integration and Testing: Integrating of each unit developed in previous phase and post
integration test the entire system for any faults.

6. Deployment of System: Make the product live on production environment after all
functional and nonfunctional testing completed.

7. Maintenance: Fixing issues and release new version with the issue patches as required.

➢ Advantages of the Model:

1. Easy to use, simple and understandable,

2. Easy to manage as each phase has specific outputs and review process,

3. Clearly-defined stages,

4. Works well for smaller projects where requirements are very clear,

5. Process and output of each phase are clearly mentioned in the document.

➢ Disadvantages:

1. It doesn’t allow much reflection or revision. When the product is in testing phase, it is very
difficult to go back and change something which is left during the requirement analysis phase.

2. Risk and uncertainty are high.

3. Not advisable for complex and object-oriented projects.

4. Changing requirements can’t be accommodated in any phase.

5. As testing is done at a later phase. So, there is a chance that challenges and risks at earlier
phases are not identified.

2. V Model
V-Model also referred to as the Verification and Validation Model. In this, each phase of
SDLC (Software Development Life Cycle) must complete before the next phase starts. It
follows a sequential design process same as the waterfall model. Testing of the device is
planned in parallel with a corresponding stage of development.

SDLC: SDLC is Software Development Life Cycle. It is the sequence of activities carried out
by Developers to design and develop high-quality software.

STLC: STLC is Software Testing Life Cycle. It consists of a series of activities carried out by
Testers methodologically to test your software product.
 Figure 3. V model process steps.

Verification: It involves a static analysis method (review) done without executing code. It is
the process of evaluation of the product development process to find whether specified
requirements meet.

Validation: It involves dynamic analysis method (functional, non-functional), testing is done

by executing code. Validation is the process to classify the software after the completion of
the development process to determine whether the software meets the customer expectations
and requirements.

V-Model contains Verification phases on one side of the Validation phases on the other side.
Verification and Validation process is joined by coding phase in V-shape. Thus it is known as
V-Model.

➢ There are the various phases of Verification Phase of V-model:

Business requirement analysis: This is the first step where product requirements understood
from the customer's side. This phase contains detailed communication to understand
customer's expectations and exact requirements.
System Design: In this stage system engineers analyze and interpret the business of the
proposed system by studying the user requirements document.

Architecture Design: The baseline in selecting the architecture is that it should understand all
which typically consists of the list of modules, brief functionality of each module, their
interface relationships, dependencies, database tables, architecture diagrams, technology
detail, etc. The integration testing model is carried out in a particular phase.

Module Design: In the module design phase, the system breaks down into small modules.
The detailed design of the modules is specified, which is known as Low-Level Design

Coding Phase: After designing, the coding phase is started. Based on the requirements, a
suitable programming language is decided. There are some guidelines and standards for
coding. Before checking in the repository, the final build is optimized for better performance,
and the code goes through many code reviews to check the performance.

➢ There are the various phases of Validation Phase of V-model:

Unit Testing: In the V-Model, Unit Test Plans (UTPs) are developed during the module
design phase. These UTPs are executed to eliminate errors at code level or unit level. A unit is
the smallest entity which can independently exist, e.g., a program module. Unit testing
verifies that the smallest entity can function correctly when isolated from the rest of the codes/
units.

Integration Testing: Integration Test Plans are developed during the Architectural Design
Phase. These tests verify that groups created and tested independently can coexist and
communicate among themselves.

System Testing: System Tests Plans are developed during System Design Phase. Unlike Unit
and Integration Test Plans, System Tests Plans are composed by the client?s business team.
System Test ensures that expectations from an application developer are met.

Acceptance Testing: Acceptance testing is related to the business requirement analysis part.
It includes testing the software product in user atmosphere. Acceptance tests reveal the
compatibility problems with the different systems, which is available within the user
atmosphere. It conjointly discovers the non-functional problems like load and performance
defects within the real user atmosphere.
 ➢ When to use V-Model?
• When the requirement is well defined and not ambiguous.
• The V-shaped model should be used for small to medium-sized projects where
requirements are clearly defined and fixed.
• The V-shaped model should be chosen when sample technical resources are available
with essential technical expertise.

➢ Advantage of V-Model:
• Easy to Understand.
• Testing Methods like planning, test designing happens well before coding.
• This saves a lot of time. Hence a higher chance of success over the waterfall model.
• Avoids the downward flow of the defects.
• Works well for small plans where requirements are easily understood.

➢ Disadvantage of V-Model:
• Very rigid and least flexible.
• Not a good for a complex project.

Software is developed during the implementation stage, so no early prototypes of the software
are produced.

3. Prototype Model
The prototype model requires that before carrying out the development of actual software, a
working prototype of the system should be built. A prototype is a toy implementation of the
system. A prototype usually turns out to be a very crude version of the actual system, possible
exhibiting limited functional capabilities, low reliability, and inefficient performance as
compared to actual software.

In many instances, the client only has a general view of what is expected from the software
product. In such a scenario where there is an absence of detailed information regarding the
input to the system, the processing needs, and the output requirement, the prototyping model
may be employed.
 Figure 4. Prototyping model activity steps.

➢ Steps of Prototype Model

• Requirement Gathering and Analyst
• Quick Decision
• Build a Prototype
• Assessment or User Evaluation
• Prototype Refinement
• Engineer Product
 ➢ Advantage of Prototype Model
• Reduce the risk of incorrect user requirement
• Good where requirement are changing/uncommitted
• Regular visible process aids management
• Support early product marketing
• Reduce Maintenance cost.
• Errors can be detected much earlier as the system is made side by side.

➢ Disadvantage of Prototype Model

• An unstable/badly implemented prototype often becomes the final product.
• Require extensive customer collaboration
• Costs customer money
• Needs committed customer
• Difficult to finish if customer withdraw
• May be too customer specific, no broad market
• Difficult to know how long the project will last.
• Easy to fall back into the code and fix without proper requirement analysis,
design, customer evaluation, and feedback.
• Prototyping tools are expensive.
• Special tools & techniques are required to build a prototype.
• It is a time-consuming process.

4. Spiral model
The spiral model, initially proposed by Boehm, is an evolutionary software process model that
couples the iterative feature of prototyping with the controlled and systematic aspects of the
linear sequential model. It implements the potential for rapid development of new versions of
the software. Using the spiral model, the software is developed in a series of incremental
releases. During the early iterations, the additional release may be a paper model or prototype.
During later iterations, more and more complete versions of the engineered system are
produced.
 Figure 4. Spiral model.

➢ Each cycle in the spiral is divided into four parts:

Objective setting: Each cycle in the spiral starts with the identification of purpose for that
cycle, the various alternatives that are possible for achieving the targets, and the constraints
that exists.

Risk Assessment and reduction: The next phase in the cycle is to calculate these various
alternatives based on the goals and constraints. The focus of evaluation in this stage is located
on the risk perception for the project.

Development and validation: The next phase is to develop strategies that resolve
uncertainties and risks. This process may include activities such as benchmarking, simulation,
and prototyping.

Planning: Finally, the next step is planned. The project is reviewed, and a choice made
whether to continue with a further period of the spiral. If it is determined to keep, plans are
drawn up for the next step of the project.

The development phase depends on the remaining risks. For example, if performance or user-
interface risks are treated more essential than the program development risks, the next phase
may be an evolutionary development that includes developing a more detailed prototype for
solving the risks.

The risk-driven feature of the spiral model allows it to accommodate any mixture of a
specification-oriented, prototype-oriented, simulation-oriented, or another type of approach.
An essential element of the model is that each period of the spiral is completed by a review
that includes all the products developed during that cycle, including plans for the next cycle.
The spiral model works for development as well as enhancement projects.

➢ When to use Spiral Model?

• When deliverance is required to be frequent.
• When the project is large
• When requirements are unclear and complex
• When changes may require at any time
• Large and high budget projects
• Advantages
• High amount of risk analysis
• Useful for large and mission-critical projects.
• Disadvantages
• Can be a costly model to use.
• Risk analysis needed highly particular expertise
• Doesn't work well for smaller projects.

5. RAD (Rapid Application Development) Model

RAD is a linear sequential software development process model that emphasizes a concise
development cycle using an element based construction approach. If the requirements are well
understood and described, and the project scope is a constraint, the RAD process enables a
development team to create a fully functional system within a concise time period.

RAD is a concept that products can be developed faster and of higher quality through:

• Gathering requirements using workshops or focus groups

• Prototyping and early, reiterative user testing of designs
• The re-use of software components
• A rigidly paced schedule that refers design improvements to the next product version
 • Less formality in reviews and other team communication

6. Iterative Model

In this Model, you can start with some of the software specifications and develop the first
version of the software. After the first version if there is a need to change the software, then a
new version of the software is created with a new iteration. Every release of the Iterative
Model finishes in an exact and fixed period that is called iteration.

The Iterative Model allows the accessing earlier phases, in which the variations made
respectively. The final output of the project renewed at the end of the Software Development
Life Cycle (SDLC) process.

The various phases of Iterative model are as follows:

1. Requirement gathering & analysis: In this phase, requirements are gathered from
customers and check by an analyst whether requirements will fulfil or not. Analyst checks that
need will achieve within budget or not. After all of this, the software team skips to the next
phase.

2. Design: In the design phase, team design the software by the different diagrams like Data
Flow diagram, activity diagram, class diagram, state transition diagram, etc.

3. Implementation: In the implementation, requirements are written in the coding language

and transformed into computer programmes which are called Software.

4. Testing: After completing the coding phase, software testing starts using different test
methods. There are many test methods, but the most common are white box, black box, and
grey box test methods.

5. Deployment: After completing all the phases, software is deployed to its work
environment.

6. Review: In this phase, after the product deployment, review phase is performed to check
the behaviour and validity of the developed product. And if there are any error found then the
process starts again from the requirement gathering.
7. Maintenance: In the maintenance phase, after deployment of the software in the working
environment there may be some bugs, some errors or new updates are required. Maintenance
involves debugging and new addition options.

➢ When to use the Iterative Model?

• When requirements are defined clearly and easy to understand.
• When the software application is large.
• When there is a requirement of changes in future.

➢ Advantage of Iterative Model

• Testing and debugging during smaller iteration is easy.
• A Parallel development can plan.
• It is easily acceptable to ever-changing needs of the project.
• Risks are identified and resolved during iteration.
• Limited time spent on documentation and extra time on designing.

➢ Disadvantage of Iterative Model

• It is not suitable for smaller projects.
• More Resources may be required.
• Design can be changed again and again because of imperfect requirements.
• Requirement changes can cause over budget.

• Project completion date not confirmed because of changing requirements.

7. Incremental Model

Incremental Model is a process of software development where requirements divided into

multiple standalone modules of the software development cycle. In this model, each module
goes through the requirements, design, implementation and testing phases. Every subsequent
release of the module adds function to the previous release. The process continues until the
complete system achieved.
 ➢ The various phases of incremental model are as follows:

1. Requirement analysis: In the first phase of the incremental model, the product analysis
expertise identifies the requirements. And the system functional requirements are understood
by the requirement analysis team. To develop the software under the incremental model, this
phase performs a crucial role.

2. Design & Development: In this phase of the Incremental model of SDLC, the design of
the system functionality and the development method are finished with success. When
software develops new practicality, the incremental model uses style and development phase.

3. Testing: In the incremental model, the testing phase checks the performance of each
existing function as well as additional functionality. In the testing phase, the various methods
are used to test the behavior of each task.

4. Implementation: Implementation phase enables the coding phase of the development

system. It involves the final coding that design in the designing and development phase and
tests the functionality in the testing phase.

After completion of this phase, the number of the product working is enhanced and upgraded
up to the final system product.
➢ When we use the Incremental Model?
• When the requirements are superior.
• A project has a lengthy development schedule.
• When Software team are not very well skilled or trained.
• When the customer demands a quick release of the product.
• You can develop prioritized requirements first.

➢ Advantage of Incremental Model

• Errors are easy to be recognized.
• Easier to test and debug
• More flexible.
• Simple to manage risk because it handled during its iteration.
• The Client gets important functionality early.

➢ Disadvantage of Incremental Model

• Need for good planning
• Total Cost is high.
• Well defined module interfaces are needed.
 CPE 310 SOFTWARE ENGINEERING

Spring Semester-2021

Dr. Nesrin AYDIN ATASOY

CONTENTS

Week 3: Software Metrics

A software metric is a measure of software characteristics which are measurable or countable.
Software metrics are valuable for many reasons, including measuring software performance,
planning work items, measuring productivity, and many other uses.

Within the software development process, many metrics are that are all connected. Software
metrics are similar to the four functions of management: Planning, Organization, Control, or
Improvement.

• Classification of Software Metrics

Software metrics can be classified into two types as follows:

1. Product Metrics: These are the measures of various characteristics of the software product.

The two important software characteristics are:

o Size and complexity of software.

o Quality and reliability of software.

These metrics can be computed for different stages of SDLC.

2. Process Metrics: These are the measures of various characteristics of the software
development process. For example, the efficiency of fault detection. They are used to measure
the characteristics of methods, techniques, and tools that are used for developing software.

➢ Types of Metrics
Internal metrics: Internal metrics are the metrics used for measuring properties that are viewed
to be of greater importance to a software developer. For example, Lines of Code (LOC)
measure.

External metrics: External metrics are the metrics used for measuring properties that are
viewed to be of greater importance to the user, e.g., portability, reliability, functionality,
usability, etc.

Hybrid metrics: Hybrid metrics are the metrics that combine product, process, and resource
metrics. For example, cost per FP where FP stands for Function Point Metric.
Project metrics: Project metrics are the metrics used by the project manager to check the
project's progress. Data from the past projects are used to collect various metrics, like time and
cost; these estimates are used as a base of new software. Note that as the project proceeds, the
project manager will check its progress from time-to-time and will compare the effort, cost, and
time with the original effort, cost and time. Also understand that these metrics are used to
decrease the development costs, time efforts and risks. The project quality can also be
improved. As quality improves, the number of errors and time, as well as cost required, is also
reduced.

➢ Advantage of Software Metrics

• Comparative study of various design methodology of software systems.

• For analysis, comparison, and critical study of different programming language
concerning their characteristics.
• In comparing and evaluating the capabilities and productivity of people involved in
software development.
• In the preparation of software quality specifications.
• In the verification of compliance of software systems requirements and specifications.
• In making inference about the effort to be put in the design and development of the
software systems.
• In getting an idea about the complexity of the code.
• In taking decisions regarding further division of a complex module is to be done or
not.
• In guiding resource manager for their proper utilization.
• In comparison and making design tradeoffs between software development and
maintenance cost.
• In providing feedback to software managers about the progress and quality during
various phases of the software development life cycle.
• In the allocation of testing resources for testing the code.

➢ Disadvantage of Software Metrics

• The application of software metrics is not always easy, and in some cases, it is difficult
and costly.
• The verification and justification of software metrics are based on historical/empirical
data whose validity is difficult to verify.
• These are useful for managing software products but not for evaluating the performance
of the technical staff.
• The definition and derivation of Software metrics are usually based on assuming which
are not standardized and may depend upon tools available and working environment.
• Most of the predictive models rely on estimates of certain variables which are often not
known precisely.
➢ Size Oriented Metrics
o LOC Metrics

It is one of the earliest and simpler metrics for calculating the size of the computer program.
It is generally used in calculating and comparing the productivity of programmers. These
metrics are derived by normalizing the quality and productivity measures by considering
the size of the product as a metric.

Following are the points regarding LOC measures:

1. In size-oriented metrics, LOC is considered to be the normalization value.

2. It is an older method that was developed when FORTRAN and COBOL
programming were very popular.
3. Productivity is defined as KLOC / EFFORT, where effort is measured in person-
months.
4. Size-oriented metrics depend on the programming language used.
5. As productivity depends on KLOC, so assembly language code will have more
productivity.
6. LOC measure requires a level of detail which may not be practically achievable.
7. The more expressive is the programming language, the lower is the productivity.
8. LOC method of measurement does not apply to projects that deal with visual (GUI-
based) programming. As already explained, Graphical User Interfaces (GUIs) use
forms basically. LOC metric is not applicable here.
 9. It requires that all organizations must use the same method for counting LOC. This
is so because some organizations use only executable statements, some useful
comments, and some do not. Thus, the standard needs to be established.
10. These metrics are not universally accepted.

Based on the LOC/KLOC count of software, many other metrics can be computed:

1. Errors/KLOC.
2. $/ KLOC.
3. Defects/KLOC.
4. Pages of documentation/KLOC.
5. Errors/PM.
6. Productivity = KLOC/PM (effort is measured in person-months).
7. $/ Page of documentation.

➢ Advantages of LOC

1. Simple to measure

➢ Disadvantage of LOC
1. It is defined on the code. For example, it cannot measure the size of the specification.
2. It characterizes only one specific view of size, namely length, it takes no account of
functionality or complexity
3. Bad software design may cause an excessive line of code
4. It is language dependent
5. Users cannot easily understand it

o Functional Point (FP) Analysis

Allan J. Albrecht initially developed function Point Analysis in 1979 at IBM and it has been
further modified by the International Function Point Users Group (IFPUG). FPA is used to
make estimate of the software project, including its testing in terms of functionality or function
size of the software product. However, functional point analysis may be used for the test
estimation of the product. The functional size of the product is measured in terms of the function
point, which is a standard of measurement to measure the software application.

o Objectives of FPA
The basic and primary purpose of the functional point analysis is to measure and provide the
software application functional size to the client, customer, and the stakeholder on their request.
Further, it is used to measure the software project development along with its maintenance,
consistently throughout the project irrespective of the tools and the technologies.

Following are the points regarding FPs:

1. FPs of an application is found out by counting the number and types of functions used
in the applications. Various functions used in an application can be put under five types,
as shown in Table:

Measurements Parameters Examples

1.Number of External Inputs(EI) Input screen and tables

2. Number of External Output (EO) Output screens and reports

3. Number of external inquiries (EQ) Prompts and interrupts.

4. Number of internal files (ILF) Databases and directories

5. Number of external interfaces (EIF) Shared databases and shared routines.

All these parameters are then individually assessed for complexity.

2. FP characterizes the complexity of the software system and hence can be used to depict the
project time and the manpower requirement.

3. The effort required to develop the project depends on what the software does.

4. FP is programming language independent.

5. FP method is used for data processing systems, business systems like information systems.

6. The five parameters mentioned above are also known as information domain
characteristics.

7. All the parameters mentioned above are assigned some weights that have been
experimentally determined and are shown in Table.

The functional complexities are multiplied with the corresponding weights against each
function, and the values are added up to determine the UFP (Unadjusted Function Point) of the
subsystem.
Here that weighing factor will be simple, average, or complex for a measurement parameter
type.

1. Based on the FP measure of software many other metrics can be computed:

2. Errors/FP
3. $/FP.
4. Defects/FP
5. Pages of documentation/FP
6. Errors/PM.
7. Productivity = FP/PM (effort is measured in person-months).
8. $/Page of Documentation.
8. LOCs of an application can be estimated from FPs. That is, they are interconvertible. This
process is known as backfiring. For example, 1 FP is equal to about 100 lines of COBOL
code.

9. FP metrics is used mostly for measuring the size of Management Information System (MIS)
software.

10. But the function points obtained above are unadjusted function points (UFPs). These (UFPs)
of a subsystem are further adjusted by considering some more General System Characteristics
(GSCs). It is a set of 14 GSCs that need to be considered. The procedure for adjusting UFPs is
as follows:

a. Degree of Influence (DI) for each of these 14 GSCs is assessed on a scale of 0 to 5. (b)
If a particular GSC has no influence, then its weight is taken as 0 and if it has a strong
influence then its weight is 5.
b. The score of all 14 GSCs is totaled to determine Total Degree of Influence (TDI).
c. Then Value Adjustment Factor (VAF) is computed from TDI by using the
formula: VAF = (TDI * 0.01) + 0.65

Remember that the value of VAF lies within 0.65 to 1.35 because

a. When TDI = 0, VAF = 0.65

b. When TDI = 70, VAF = 1.35
c. VAF is then multiplied with the UFP to get the final FP count: FP = VAF * UFP

Example: Compute the function point, productivity, documentation, cost per function for the
following data:

1. Number of user inputs = 24

2. Number of user outputs = 46
3. Number of inquiries = 8
4. Number of files = 4
5. Number of external interfaces = 2
6. Effort = 36.9 p-m
7. Technical documents = 265 pages
8. User documents = 122 pages
9. Cost = $7744/ month
Various processing complexity factors are: 4, 1, 0, 3, 3, 5, 4, 4, 3, 3, 2, 2, 4, 5.

Solution:

Measurement Count Process Weighing factor

Parameter

1. Number of 24 * 4 = 96
external inputs (EI)

2. Number of 46 * 4 = 184
external outputs
(EO)

3. Number of 8 * 6 = 48
external inquiries
(EQ)

4. Number of 4 * 10 = 40
internal files (ILF)

5. Number of 2 * 5 = 10
external interfaces 378
(EIF) Count-total →
 ➢ Differentiate between FP and LOC

FP LOC

1. FP is specification based. 1. LOC is an analogy based.

2. FP is language independent. 2. LOC is language dependent.

3. FP is user-oriented. 3. LOC is design-oriented.

4. It is extendible to LOC. 4. It is convertible to FP (backfiring)

 CPE 310 SOFTWARE ENGINEERING

Spring Semester-2021

Dr. Nesrin AYDIN ATASOY

Week 4: Planning

The first stage of the software development process is the planning stage. In order
to develop a successful project, the whole picture of the project must be taken.
This picture is produced as a result of the project planning phase. Project plan
components are as follows:
o Project Scope
o Project time-Work plan
o Project team structure
o Technical definitions of the proposed system, Special development
tools and environments
o Project standards, methods and methodologies
o Quality assurance plan
o Environmental management plan
o Resource management plan
o Education plan
o Test plan
o Maintenance plan

Things to be done at the project planning stage can be summarized as follows:

o Determination of project resources
o Project cost estimation
o Creating the project team structure
o Detailed project plan
o Project monitoring

The project plan, which is the main output of the planning phase, is a document
that will be used, reviewed and updated throughout the project. Therefore, the
Planning stage is different from other stages.
The resources to be used when planning a software project should be:

➢ Human Resources: It is determined who will take place for which period
and at which stages of the project.
 Project manager Hardware Team Leader

Software Team Hardware Engineer

Leader

Web Designer Network Specialist

System Designer Software Support Staff

Programmer Hardware Support Staff

System administrator Instructor

Database Manager supervisory

Quality Assurance Call Center Staff

Manager

➢ Software Resources: Software resources are computer aided platforms

used to develop code.

➢ Hardware Resources: Nowadays, hardware systems are gradually turning

into open system architecture. Brand loyalty in the past is gradually
disappearing. It is the determination of the environment such as Hosts,
Servers (Web, Email, Database), User computers (PC), Local area Network
(LAN) Infrastructure, Wide area network (WAN) infrastructure.

➢ Project Classes

o Discrete Projects: Like a human resources management

system working on Lan, which is small in size, by experienced
staff.

o Semi-Embedded Projects: Projects with both information

dimension and hardware deployment dimension.

o Embedded Projects: Projects aiming to drive equipment

(software driving a pilotless plane - hardware constraints are
high).
 ➢ Project Costs

Cost management has an important place in the development process. Thanks to

cost management;

• Facilitating the information system development process,

• Prevention of delays,
• Providing more effective resource use
• Effective implementation of the work schedule
• Healthy pricing of the product
• It is ensured that the product is finished on time and within the targeted
budget limits.

✓ Cost Estimation Methods

Information such as the total duration of the project, the total cost of the
project, the total number of lines, the number of staff-quality-working time,
the cost of a person-month gives important information about the cost
estimation for other projects after the project is finished or most of the
project is finished. The most commonly used cost estimation methods are
shown in Table 1.

Table 1. The most commonly used cost estimation methods

These methods are classified according to the size of the project and the way in
which the methods are applied. The common features of these methods are as
follows:

✓ The main steps of the project are input.

✓ Taking environmental features of the project as input,
✓ Using linear or nonlinear equations,
✓ Outputs of the project such as number of lines, number of function points,
time, labor, monetary cost

o Effective cost method -COCOMO

COCOMO is a cost estimation model that has received a lot of attention since it
was published by Boehm in 1981. The application can be done in three different
model formats depending on the level of detail to be used:

✓ Basic model
✓ Intermediate model
✓ Detail model

All COCOMO models take line number estimation as basic input and output
workforce and time as output. By dividing the workforce value by the time value,
approximately the number of people is estimated.

Figure 1. COCOMO models

All COCOMO models use nonlinear exponential formulas for workforce and time
values. The formulas used in Figure 2 can be seen. The COCOMO formulas used
different project types vary.
 Figure 2. COCOMO model formulas.

✓ Basic model: It is used for fast estimation for small and medium projects.
Formulas used;

Discrete projects:

K = 2.4 x S1.05 Labor

T = 2.5 x K0.38 Time

S: bin (103 ) türünden satır sayısı(Number of

Line)

Semi-Embedded projects:

K = 3.0 x S1.12 Labor

T = 2.5 x K0.35 Time

Embedded projects:

K = 3.6 x S1.20 Labor

T = 2.5 x K0.32 Time

Figure 3. COCOMO model formulas used in different projects.

Example: Calculate the time and labor costs of a 50,000-line semi-embedded

type project using the COCOMO basic model.

➢ Creating a Project Team Structure

In order for a software project to work effectively, the project team needs to be
determined well. Generally, all project management methodologies suggest a
project team structure. One of these, the PANDA project team structure is
basically created on the basis that each project unit operates directly under project
management. The main components are:

o Project Control Unit: Consists of top executives who are responsible for
developing the project. As high level problems are highly collected, it is
necessary to keep the interest of the top management with the project
constantly and be included in the project.

o Project Management Unit: It is the highest responsible unit for project

management. It consists of one or more managers according to the project
size. It is responsible to the Project Audit Unit and directly to the project
owner.

o Quality Management Unit: Checks and approves the compliance of the

project to its purpose throughout the production process. It only works
dependent on the Project management unit at a distance equal to all other
units.

o Project Office: It is the unit responsible for all kinds of administrative

works (correspondence, personnel monitoring) related to the project.

o Technical Support Unit: Technical support unit such as hardware,

operating system, database.

o Software Production Coordination Unit: Consists of Software

Production Teams (4-7 people will not increase much). If there is more than
one software Production Team, the Joint application becomes the Software
Support Team responsible for the development of the software parts.

o Education Unit: This unit is responsible for any training related to the
project.

Application Support Unit: For example, the unit that provides instant support
by phone.
 CPE 310 SOFTWARE ENGINEERING

Spring Semester-2021

Dr. Nesrin AYDIN ATASOY

Week 5: Software Request Analysis

➢ What is Request?

Request: Means that is required, desired or needed.

Request Definition: The requirements of a system are the definition of the services and functional
constraints provided by that system..

IEEE 729: Situation or support needed by the user to solve a problem or achieve a goal.

The requirement is not related to how the system or its functions will be fulfilled. It is about what it is.

• which database,

• which tables,

• how much memory is used,

these are handled during the realization phase.

➢ What is Request Engineering?

All services and restrictions,

• Identify,
• Analyzing,
• Certification
• Checking

The process is called Request Engineering.

➢ Why are request important?

Mistakes arising from requirements are noticed in the late stages. Often wrong information is caused by
negligence and inconsistency. In this case, correction costs will be high.

➢ Change of Request

Although the analysis of the requirements is very good, changes may occur during the process. Fort
his reasons:

• Communication between the customer and the developer is not sufficient,

• Some assumptions or assumptions have been made in order to pass the analysis of the
demands quickly,
 • Customer not knowing exactly what he wants and changing ideas frequently,
• The developer's lack of experience,
• The emergence of the necessity of new requests when we move on to detailed design

It should not be forgotten that no matter how much changes, all requests must be informed of the
customer and must be certified.

➢ Requirements Engineering Process

Requirements analysis, also called requirements engineering, is the process of determining user
expectations for a new or modified product. Requirements engineering is a major software engineering
action that begins during the communication activity and continues into the modeling activity. It must
be adapted to the needs of the process, the project, the product, and the people doing the work.
Requirements engineering builds a bridge to design and construction. It has four step process:

Feasibility Study: When the client approaches the organization for getting the desired product
developed, it comes up with rough idea about what all functions the software must perform and which
all features are expected from the software.

Referencing to this information, the analysts does a detailed study about whether the desired system and
its functionality are feasible to develop.

This feasibility study is focused towards goal of the organization. This study analyzes whether the
software product can be practically materialized in terms of implementation, contribution of project to
organization, cost constraints and as per values and objectives of the organization. It explores technical
aspects of the project and product such as usability, maintainability, productivity and integration ability.

The output of this phase should be a feasibility study report that should contain adequate comments and
recommendations for management about whether or not the project should be undertaken.

Requirement Gathering: If the feasibility report is positive towards undertaking the project, next phase
starts with gathering requirements from the user. Analysts and engineers communicate with the client
and end-users to know their ideas on what the software should provide and which features they want the
software to include.

Software Requirement Specification (SRS): SRS is a document created by system analyst after the
requirements are collected from various stakeholders.

SRS defines how the intended software will interact with hardware, external interfaces, speed of
operation, response time of system, portability of software across various platforms, maintainability,
speed of recovery after crashing, Security, Quality, Limitations etc.
The requirements received from client are written in natural language. It is the responsibility of system
analyst to document the requirements in technical language so that they can be comprehended and useful
by the software development team.

SRS should come up with following features:

• User Requirements are expressed in natural language.

• Technical requirements are expressed in structured language, which is used inside the
organization.
• Design description should be written in Pseudo code.
• Format of Forms and GUI screen prints.
• Conditional and mathematical notations for DFDs etc.

Software Requirement Validation: After requirement specifications are developed, the requirements
mentioned in this document are validated. User might ask for illegal, impractical solution or experts may
interpret the requirements incorrectly. This results in huge increase in cost if not nipped in the bud.
Requirements can be checked against following conditions:

• If they can be practically implemented

• If they are valid and as per functionality and domain of software
• If there are any ambiguities
• If they are complete
• If they can be demonstrated

➢ Requirement Elicitation Process

Requirement elicitation process can be depicted using the following diagram:

Requirements gathering: The developers discuss with the client and end users and know their
expectations from the software.

Organizing Requirements: The developers prioritize and arrange the requirements in order of
importance, urgency and convenience.

Negotiation & discussion: If requirements are ambiguous or there are some conflicts in requirements
of various stakeholders, if they are, it is then negotiated and discussed with stakeholders. Requirements
may then be prioritized and reasonably compromised.
The requirements come from various stakeholders. To remove the ambiguity and conflicts, they are
discussed for clarity and correctness. Unrealistic requirements are compromised reasonably.

Documentation: All formal & informal, functional and non-functional requirements are documented
and made available for next phase processing.

➢ Requirement Elicitation Techniques

Requirements Elicitation is the process to find out the requirements for an intended software system
by communicating with client, end users, system users and others who have a stake in the software
system development.

There are various ways to discover requirements:

1. Interviews

Interviews are strong medium to collect requirements. Organization may conduct several types of
interviews such as:

• Structured (closed) interviews, where every single information to gather is decided in advance,
they follow pattern and matter of discussion firmly.
• Non-structured (open) interviews, where information to gather is not decided in advance, more
flexible and less biased.
• Oral interviews
• Written interviews
• One-to-one interviews which are held between two persons across the table.
• Group interviews which are held between groups of participants. They help to uncover any
missing requirement as numerous people are involved.

2. Surveys

Organization may conduct surveys among various stakeholders by querying about their expectation and
requirements from the upcoming system.

3. Questionnaires

A document with pre-defined set of objective questions and respective options is handed over to all
stakeholders to answer, which are collected and compiled.
A shortcoming of this technique is, if an option for some issue is not mentioned in the questionnaire, the
issue might be left unattended.

4. Task analysis

Team of engineers and developers may analyze the operation for which the new system is required. If
the client already has some software to perform certain operation, it is studied and requirements of
proposed system are collected.

5. Domain Analysis

Every software falls into some domain category. The expert people in the domain can be a great help
to analyze general and specific requirements.

6. Brainstorming

An informal debate is held among various stakeholders and all their inputs are recorded for further
requirements analysis.

7. Prototyping

Prototyping is building user interface without adding detail functionality for user to interpret the features
of intended software product. It helps giving better idea of requirements. If there is no software installed
at client’s end for developer’s reference and the client is not aware of its own requirements, the developer
creates a prototype based on initially mentioned requirements. The prototype is shown to the client and
the feedback is noted. The client feedback serves as an input for requirement gathering.

8. Observation

Team of experts visit the client’s organization or workplace. They observe the actual working of the
existing installed systems. They observe the workflow at client’s end and how execution problems
are dealt. The team itself draws some conclusions which aid to form requirements expected from the
software.

➢ Software Requirements Characteristics

Gathering software requirements is the foundation of the entire software development project. Hence
they must be clear, correct and well-defined.
A complete Software Requirement Specifications must be:

• Clear
• Correct
• Consistent
• Coherent
 • Comprehensible
• Modifiable
• Verifiable
• Prioritized
• Unambiguous
• Traceable
• Credible source

➢ Software Requirements

We should try to understand what sort of requirements may arise in the requirement elicitation phase
and what kinds of requirements are expected from the software system.

Software requirements should be categorized in two categories:

1. Functional Requirements

Requirements, which are related to functional aspect of software fall into this category. They define
functions and functionality within and from the software system.

Examples:

• Search option given to user to search from various invoices.

• User should be able to mail any report to management.
• Users can be divided into groups and groups can be given separate rights.
• Should comply business rules and administrative functions.
• Software is developed keeping downward compatibility intact.

2. Non-Functional Requirements

Requirements, which are not related to functional aspect of software, fall into this category. They are
implicit or expected characteristics of software, which users make assumption of. Non-functional
requirements include:

• Security
• Logging
• Storage
• Configuration
• Performance
• Cost
• Interoperability
 • Flexibility
• Disaster recovery
• Accessibility

Requirements are categorized logically as:

Must Have: Software cannot be said operational without them.

Should have: Enhancing the functionality of software.

Could have: Software can still properly function with these requirements.

Wish list: These requirements do not map to any objectives of software.

While developing software, ‘Must have’ must be implemented, ‘Should have’ is a matter of debate with
stakeholders and negation, whereas ‘could have’ and ‘wish list’ can be kept for software updates.

➢ User Interface requirements

UI is an important part of any software or hardware or hybrid system. A software is widely accepted if
it is:

• easy to operate
• quick in response
• effectively handling operational errors
• providing simple yet consistent user interface

User acceptance majorly depends upon how user can use the software. UI is the only way for users to
perceive the system. A well performing software system must also be equipped with attractive, clear,
consistent and responsive user interface. Otherwise the functionalities of software system can not be
used in convenient way. A system is said be good if it provides means to use it efficiently. User interface
requirements are briefly mentioned below:

• Content presentation
• Easy Navigation
• Simple interface
• Responsive
• Consistent UI elements
• Feedback mechanism
• Default settings
• Purposeful layout
 • Strategical use of color and texture.
• Provide help information
• User centric approach
• Group based view settings

➢ Software System Analyst

System analyst in an IT organization is a person, who analyzes the requirement of proposed system and
ensures that requirements are conceived and documented properly & correctly. Role of an analyst starts
during Software Analysis Phase of SDLC. It is the responsibility of analyst to make sure that the
developed software meets the requirements of the client.

System Analysts have the following responsibilities:

• Analyzing and understanding requirements of intended software

• Understanding how the project will contribute in the organization objectives
• Identify sources of requirement
• Validation of requirement
• Develop and implement requirement management plan
• Documentation of business, technical, process and product requirements
• Coordination with clients to prioritize requirements and remove and ambiguity
• Finalizing acceptance criteria with client and other stakeholders

➢ Software Metrics and Measures

Software Measures can be understood as a process of quantifying and symbolizing various attributes
and aspects of software. Software Metrics provide measures for various aspects of software process and
software product.

Software measures are fundamental requirement of software engineering. They not only help to control
the software development process but also aid to keep quality of ultimate product excellent.

According to Tom DeMarco, a (Software Engineer), “You cannot control what you cannot measure.”
By his saying, it is very clear how important software measures are.

Let us see some software metrics:

Size Metrics: LOC (Lines of Code), mostly calculated in thousands of delivered source code lines,
denoted as KLOC.
Function Point Count is measure of the functionality provided by the software. Function Point count
defines the size of functional aspect of software.

Complexity Metrics: McCabe’s Cyclomatic complexity quantifies the upper bound of the number of
independent paths in a program, which is perceived as complexity of the program or its modules. It is
represented in terms of graph theory concepts by using control flow graph.

Quality Metrics: Defects, their types and causes, consequence, intensity of severity and their
implications define the quality of product.

The number of defects found in development process and number of defects reported by the client after
the product is installed or delivered at client-end, define quality of product.

Process Metrics: In various phases of SDLC, the methods and tools used, the company standards and
the performance of development are software process metrics.

Resource Metrics: Effort, time and various resources used, represents metrics for resource
measurement.

➢ Requirements Modeling: Scenarios, Information, And Analysis Classes Requirements

Analysis

o Requirements Modeling Approaches

Requirements analysis results in the specification of software’s operational characteristics, indicates

software’s interface with other system elements, and establishes constraints that software must meet.
Requirements analysis allows you to elaborate on basic requirements established during the inception,
elicitation, and negotiation tasks that are part of requirements engineering.

The requirements modeling action results in one or more of the following types of models:
 ➢ Scenario-based models of requirements from the point of view of various system

“actors”

➢ Data models that depict the information domain for the problem
➢ Class-oriented models that represent object-oriented classes (attributes and operations)

and the manner in which classes collaborate to achieve system requirements

• Flow-oriented models that represent the functional elements of the system and how they

transform data as it moves through the system

• Behavioral models that depict how the software behaves as a consequence of external

“events”.

The requirements model as a bridge between the system description and the design model:

The requirements model must achieve three primary objectives:

1. To describe what the customer requires,

2. to establish a basis for the creation of a software design, and

3. to define a set of requirements that can be validated once the software is built.

The analysis model bridges the gap between a system-level description that describes overall system or
business functionality as it is achieved by applying software, hardware, data, human, and other system
elements and a software design that describes the software’s application architecture, user interface, and
component-level structure.

1. Scenario-Based Modeling

Scenario-based elements depict how the user interacts with the system and the specific sequence of
activities that occur as the software is used.
A use case describes a specific usage scenario in straightforward language from the point of view of a
defined actor. These are the questions that must be answered if use cases are to provide value as a
requirements modeling tool.

(1) what to write about,

(2) how much to write about it,

(3) how detailed to make your description, and (4) how to organize the description?

To begin developing a set of use cases, list the functions or activities performed by a specific actor.

❖ Writing a Formal Use Case

• The typical outline for formal use cases can be in following manner
• The goal in context identifies the overall scope of the use case.
• The precondition describes what is known to be true before the use case is initiated.
• The trigger identifies the event or condition that “gets the use case started”
• The scenario lists the specific actions that are required by the actor and the appropriate system
responses.
• Exceptions identify the situations uncovered as the preliminary use case is refined Additional
headings may or may not be included and are reasonably self-explanatory.

Every modeling notation has limitations, and the use case is no exception. A use case focuses on
functional and behavioral requirements and is generally inappropriate for nonfunctional requirements.
However, scenario-based modeling is appropriate for a significant majority of all situations that you will
encounter as a software engineer. There is a simple use case diagram in the following figüre.
 2. Data Modeling Concepts

Data modeling is the process of documenting a complex software system design as an easily understood
diagram, using text and symbols to represent the way data needs to flow. The diagram can be used as a
blueprint for the construction of new software or for re-engineering a legacy application. The most
widely used data Model by the Software engineers is Entity Relationship Diagram (ERD), it addresses
the issues and represents all data objects that are entered, stored, transformed, and produced within an
application.

• Data Objects

A data object is a representation of composite information that must be understood by software. A data
object can be an external entity (e.g., anything that produces or consumes information), a thing (e.g.,
a report or a display), an occurrence (e.g., a telephone call) or event (e.g., an alarm), a role (e.g.,
salesperson), an organizational unit (e.g., accounting department), a place (e.g., a warehouse), or a
structure (e.g., a file).

For example, a person or a car can be viewed as a data object in the sense that either can be defined in
terms of a set of attributes. The description of the data object incorporates the data object and all of its
attributes.

A data object encapsulates data only there is no reference within a data object to operations that act on
the data. Therefore, the data object can be represented as a table as shown in following table. The
headings in the table reflect attributes of the object. Tabular representation of data objects in the
following figüre.
 • Data Attributes

Data attributes define the properties of a data object and take on one of three different characteristics.
They can be used to (1) name an instance of the data object, (2) describe the instance, or (3) make
reference to another instance in another table.

• Relationships

Data objects are connected to one another in different ways. Consider the two data objects, person and
car. These objects can be represented using the following simple notation and relationships are 1) A
person owns a car, 2) A person is insured to drive a car. There is a Relationships between data objects
in the following figure.

3. Class-Based Modeling

Class-based modeling represents the objects that the system will manipulate, the operations that will be
applied to the objects to effect the manipulation, relationships between the objects, and the
collaborations that occur between the classes that are defined. The elements of a class-based model
include classes and objects, attributes, operations, class responsibility collaborator (CRC) models,
collaboration diagrams, and packages.

• Identifying Analysis Classes

We can begin to identify classes by examining the usage scenarios developed as part of the requirements
model and performing a “grammatical parse” on the use cases developed for the system to be built.

Analysis classes manifest themselves in one of the following ways:

• External entities (e.g., other systems, devices, people) that produce or consume information to
be used by a computer-based system.
• Things (e.g., reports, displays, letters, signals) that are part of the information domain for the
problem.
 • Occurrences or events (e.g., a property transfer or the completion of a series of robot
movements) that occur within the context of system operation.
• Roles (e.g., manager, engineer, salesperson) played by people who interact with the system.
• Organizational units (e.g., division, group, team) that are relevant to an application.
• Places (e.g., manufacturing floor or loading dock) that establish the context of the problem and
the overall function of the system.
• Structures (e.g., sensors, four-wheeled vehicles, or computers) that define a class of objects or
related classes of objects.

Attributes describe a class that has been selected for inclusion in the requirements model. The attributes
that define the class that clarify what is meant by the class in the context of the problem space.

To develop a meaningful set of attributes for an analysis class, you should study each use case and select
those “things” that reasonably “belong” to the class.

Operations define the behavior of an object. Although many different types of operations exist, they
can generally be divided into four broad categories: (1) operations that manipulate data in some way
(e.g., adding, deleting, reformatting, selecting), (2) operations that perform a computation, (3) operations
that inquire about the state of an object, and (4) operations that monitor an object for the occurrence of
a controlling event. There is a Class diagram for the system class in the following figure.
 CPE 310 SOFTWARE ENGINEERING

Spring Semester-2021

Dr. Nesrin AYDIN ATASOY

Week 6: Modeling with UML

1. What is modeling?

➢ Modeling consists of building an abstraction of reality.

➢ Abstractions are simplifications because:
o They ignore irrelevant details and
o They only represent the relevant details.
➢ Focus only on relevant parts of the problem
➢ What is relevant or irrelevant depends on the purpose of the model.
➢ We need simpler representations for complex systems
o Modeling is a means for dealing with complexity

2. Why model software?

➢ Visualize software before its produced

➢ Code is not easily understandable by developers who did not write it
➢ Document the design decisions & Communicate Ideas
➢ Provide template for guiding the software production

Application Domain (Analysis): The environment in which the system is operating.

Solution Domain (Design, Implementation): The technologies used to build the system  Modeling
space of all possible systems.

Both domains contain abstractions that we can use for the construction of the system model.
Example:

3. What is UML(Unified Modeling Language)?

 The UML is a language for

➢ visualizing
➢ specifying
➢ constructing
➢ documenting the artifacts of a software-intense system

General Definition: The UML offers a standard way to write a system's blueprints, including
conceptual things such as business processes and system functions as well as concrete things such as
programming language statements, database schemas, and reusable software components.

Commercial tools: Rational (IBM), Together (Borland), Visual Paradigm

Open Source tools: ArgoUML, UMLet, Umbrello

The figure below shows the UML diagram hierarchy and the positioning of the UML Use Case
Diagram. As you can see, use case diagrams belong to the family of behavioral diagrams.

4. The Origin of UML

The goal of UML is to provide a standard notation that can be used by all object-oriented methods

and to select and integrate the best elements of precursor notations. UML has been designed for a

broad range of applications. Hence, it provides constructs for a broad range of systems and activities

(e.g., distributed systems, analysis, system design and deployment).

UML is a notation that resulted from the unification of OMT from

1. Object Modeling Technique OMT [James Rumbaugh 1991] - was best for analysis and
data-intensive information systems.

2. Booch [Grady Booch 1994] - was excellent for design and implementation. Grady Booch
had worked extensively with the Ada language, and had been a major player in the
development of Object Oriented techniques for the language. Although the Booch method
was strong, the notation was less well received (lots of cloud shapes dominated his models -
not very tidy)

3. OOSE (Object-Oriented Software Engineering [Ivar Jacobson 1992]) - featured a model

known as Use Cases. Use Cases are a powerful technique for understanding the behaviour of
an entire system (an area where OO has traditionally been weak).
The first thing to notice about the UML is that there are a lot of different diagrams (models) to get

used to. The reason for this is that it is possible to look at a system from many different viewpoints.

A software development will have many stakeholders playing a part.

For Example:
• Analysts
• Designers
• Coders
• Testers
• QA
• The Customer
• Technical Authors

All of these people are interested in different aspects of the system, and each of them require a
different level of detail. For example, a coder needs to understand the design of the system and be
able to convert the design to a low level code. By contrast, a technical writer is interested in the
behavior of the system as a whole, and needs to understand how the product functions. The UML
attempts to provide a language so expressive that all stakeholders can benefit from at least one UML
diagram.

4.1. What is a Class Diagram?

The class diagram is a central modeling technique that runs through nearly all object-oriented

methods. This diagram describes the types of objects in the system and various kinds of static

relationships which exist between them.

Relationships

There are three principal kinds of relationships which are important:

1. Association - represent relationships between instances of types (a person works for a
company, a company has a number of offices.
2. Inheritance - the most obvious addition to ER diagrams for use in OO. It has an immediate
correspondence to inheritance in OO design.
3. Aggregation - Aggregation, a form of object composition in object-oriented design.

Class Diagram Example

4.2. What is Component Diagram?

In the Unified Modeling Language, a component diagram depicts how components are wired together

to form larger components or software systems. It illustrates the architectures of the software

components and the dependencies between them. Those software components including run-time

components, executable components also the source code components.

Component Diagram Example

4.3. What is a Deployment Diagram?

The Deployment Diagram helps to model the physical aspect of an Object-Oriented software system.

It is a structure diagram which shows architecture of the system as deployment (distribution) of

software artifacts to deployment targets. Artifacts represent concrete elements in the physical world

that are the result of a development process. It models the run-time configuration in a static view and

visualizes the distribution of artifacts in an application. In most cases, it involves modeling the

hardware configurations together with the software components that lived on.

Deployment Diagram Example

4.4. What is an Object Diagram?

An object diagram is a graph of instances, including objects and data values. A static object diagram

is an instance of a class diagram; it shows a snapshot of the detailed state of a system at a point in
time. The difference is that a class diagram represents an abstract model consisting of classes and their

relationships. However, an object diagram represents an instance at a particular moment, which is

concrete in nature. The use of object diagrams is fairly limited, namely to show examples of data

structure.
Class Diagram vs Object Diagram - An Example
Some people may find it difficult to understand the difference between a UML Class Diagram and a

UML Object Diagram as they both comprise of named "rectangle blocks", with attributes in them, and

with linkages in between, which make the two UML diagrams look similar. Some people may even

think they are the same because in the UML tool they use both the notations for Class Diagram and

Object Diagram are put inside the same diagram editor - Class Diagram.

But in fact, Class Diagram and Object Diagram represent two different aspects of a code base. In this

article, we will provide you with some ideas about these two UML diagrams, what they are, what are

their differences and when to use each of them.

Relationship between Class Diagram and Object Diagram

You create "classes" when you are programming. For example, in an online banking system you may

create classes like 'User', 'Account', 'Transaction', etc. In a classroom management system you may

create classes like 'Teacher', 'Student', 'Assignment', etc.

In each class, there are attributes and operations that represent the characteristic and behavior of the

class. Class Diagram is a UML diagram where you can visualize those classes, along with their

attributes, operations and the inter-relationship.

UML Object Diagram shows how object instances in your system are interacting with each other at a

particular state. It also represents the data values of those objects at that state. In other words, a UML

Object Diagram can be seen as a representation of how classes (drawn in UML Class Diagram) are

utilized at a particular state.

If you are not a fan of those definition stuff, take a look at the following UML diagram examples. I

believe that you will understand their differences in seconds.

Class Diagram Example
The following Class Diagram example represents two classes - User and Attachment. A user can

upload multiple attachment so the two classes are connected with an association, with 0..* as

multiplicity on the Attachment side.

Object Diagram Example

The following Object Diagram example shows you how the object instances of User and Attachment

class "look like" at the moment Peter (i.e. the user) is trying to upload two attachments. So there are

two Instance Specification for the two attachment objects to be uploaded.

4.5. What is a Package Diagram?

Package diagram is UML structure diagram which shows packages and dependencies between the

packages. Model diagrams allow to show different views of a system, for example, as multi-layered

(aka multi-tiered) application - multi-layered application model.

Package Diagram Example
 4.6. What is a Use Case Diagram?

A use-case model describes a system's functional requirements in terms of use cases. It is a model of

the system's intended functionality (use cases) and its environment (actors). Use cases enable you to

relate what you need from a system to how the system delivers on those needs.

Think of a use-case model as a menu, much like the menu you'd find in a restaurant. By looking at the

menu, you know what's available to you, the individual dishes as well as their prices. You also know

what kind of cuisine the restaurant serves: Italian, Mexican, Chinese, and so on. By looking at the

menu, you get an overall impression of the dining experience that awaits you in that restaurant. The

menu, in effect, "models" the restaurant's behavior.

Because it is a very powerful planning instrument, the use-case model is generally used in all phases

of the development cycle by all team members.

Use Case Diagram Example

4.7. What is an Activity Diagram?

Activity diagrams are graphical representations of workflows of stepwise activities and actions with

support for choice, iteration and concurrency. It describes the flow of control of the target system,

such as the exploring complex business rules and operations, describing the use case also the business

process. In the Unified Modeling Language, activity diagrams are intended to model both

computational and organizational processes (i.e. workflows).

Activity Diagram Example

4.8. What is a State Machine Diagram?

A state diagram is a type of diagram used in UML to describe the behavior of systems which is based

on the concept of state diagrams by David Harel. State diagrams depict the permitted states and

transitions as well as the events that effect these transitions. It helps to visualize the entire lifecycle

of objects and thus help to provide a better understanding of state-based systems.

State Machine Diagram Example

4.9. What is a Sequence Diagram?

The Sequence Diagram models the collaboration of objects based on a time sequence. It shows how

the objects interact with others in a particular scenario of a use case. With the advanced visual

modeling capability, you can create complex sequence diagram in few clicks. Besides, some modeling
tool such as Visual Paradigm can generate sequence diagram from the flow of events which you have

defined in the use case description.

Sequence Diagram Example

4.10. What is Timing Diagram?

Timing Diagram shows the behavior of the object(s) in a given period of time. Timing diagram is a

special form of a sequence diagram. The differences between timing diagram and sequence diagram

are the axes are reversed so that the time are increase from left to right and the lifelines are shown in

separate compartments arranged vertically.

Timing Diagram Example

5. UML Glossary and Terms

• Abstract Class - A class that will never be instantiated. An instance of this class will never
exist.
• Actor - An object or person that initiates events the system is involved with.
• Activity: A step or action within an Activity Diagram. Represents an action taken by the
system or by an Actor.
• Activity Diagram: A glorified flowchart that shows the steps and decisions and parallel
operations within a process, such as an algorithm or a business process.
• Aggregation - Is a part of another class. Shown with a hollow diamond next to the
containing class in diagrams.
• Artifacts - Documents describing the output of a step in the design process. The description
is graphic, textual, or some combination.
• Association - A connection between two elements of a Model. This might represent a
member variable in code, or the association between a personnel record and the person it
represents, or a relation between two categories of workers, or any similar relationship. By
default, both elements in an Association are equal, and are aware of each other through the
Association. An Association can also be a Navigable Association, meaning that the source
end of the association is aware of the target end, but not vice versa.
• Association Class: A Class that represents and adds information to the Association between
two other Classes.
• Attributes - Characteristics of an object which may be used to reference other objects or
save object state information.
• Base Class: A Class which defines Attributes and Operations that are inherited by a
Subclass via a Generalization relationship.
• Branch: A decision point in an Activity Diagram. Multiple Transitions emerge from the
Branch, each with a Guard Condition. When control reaches the Branch, exactly one Guard
Condition must be true; and control follows the corresponding Transition.
• Class: A category of similar Objects, all described by the same Attributes and Operations
and all assignment-compatible.
• Class Diagram - Shows the system classes and relationships between them.
• Classifier: A UML element that has Attributes and Operations. Specifically, Actors,
Classes, and Interfaces.
• Collaboration: A relation between two Objects in a Communication Diagram, indicating
that Messages can pass back and forth between the Objects.
• Communication Diagram - A diagram that shows how operations are done while
emphasizing the roles of objects.
• Component: A deployable unit of code within the system.
• Component Diagram: A diagram that shows relations between various Components and
Interfaces.
• Concept - A noun or abstract idea to be included in a domain model.
• Construction Phase - The third phase of the Rational Unified Process during which several
iterations of functionality are built into the system under construction. This is where the
main work is done.
• Dependence: A relationship that indicates one Classifier knows the Attributes and
Operations of another Classifier, but isn't directly connected to any instance of the second
Classifier.
• Deployment Diagram: A diagram that shows relations between various Processors.
• Domain -The part of the universe that the system is involved with.
• Elaboration Phase - The second phase of the Rational Unified Process that allows for
additional project planning including the iterations of the construction phase.
• Element: Any item that appears in a Model.
• Encapsulation - Data in objects is private.
• Generalization - Indicates that one class is a subclass on another class (superclass). A
hollow arrow points to the superclass.
• Event: In a State Diagram, this represents a signal or event or input that causes the system
to take an action or switch States.
• Final State: In a State Diagram or an Activity Diagram, this indicates a point at which the
diagram completes.
• Fork: A point in an Activity Diagram where multiple parallel control threads begin.
• Generalization: An inheritance relationship, in which a Subclass inherits and adds to the
Attributes and Operations of a Base Class.
• GoF - Gang of Four set of design patterns.
• High Cohesion - A GRASP evaluative pattern which makes sure the class is not too
complex, doing unrelated functions.
• Low Coupling - A GRASP evaluative pattern which measures how much one class relies on
another class or is connected to another class.
• Inception Phase - The first phase of the Rational Unified Process that deals with the
original conceptualization and beginning of the project.
• Inheritance - Subclasses inherit the attributes or characterics of their parent (superclass)
class. These attributes can be overridden in the subclass.
• Initial State: In a State Diagram or an Activity Diagram, this indicates the point at which
the diagram begins.
• Instance - A class is used like a template to create an object. This object is called an
instance of the class. Any number of instances of the class may be created.
• Interface: A Classifier that defines Attributes and Operations that form a contract for
behavior. A provider Class or Component may elect to Realize an Interface (i.e., implement
its Attributes and Operations). A client Class or Component may then Depend upon the
Interface and thus use the provider without any details of the true Class of the provider.
• Iteration - A mini project section during which some small piece of functionality is added
to the project. Includes the development loop of analysis, design and coding.
• Join: A point in an Activity Diagram where multiple parallel control threads synchronize
and rejoin.
• Member: An Attribute or an Operation within a Classifier.
• Merge: A point in an Activity Diagram where different control paths come together.
• Message - A request from one object to another asking the object receiving the message to
do something. This is basically a call to a method in the receiving object.
• Method - A function or procedure in an object.
• Model - The central UML artifact. Consists of various elements arranged in a hierarchy by
Packages, with relations between elements as well.
• Multiplicity - Shown in a domain model and indicated outside concept boxes, it indicates
object quantity relationship to quantiles of other objects.
• Navigability: Indicates which end of a relationship is aware of the other end. Relationships
can have bidirectional Navigability (each end is aware of the other) or single directional
Navigability (one end is aware of the other, but not vice versa).
• Notation - Graphical document with rules for creating analysis and design methods.
• Note: A text note added to a diagram to explain the diagram in more detail.
• Object - Object: In an Activity Diagram, an object that receives information from Activities
or provides information to Activities. In a Collaboration Diagram or a Sequence Diagram,
an object that participates in the scenario depicted in the diagram. In general: one instance
or example of a given Classifier (Actor, Class, or Interface).
• Package - A group of UML elements that logically should be grouped together.
• Package Diagram: A Class Diagram in which all of the elements are Packages and
Dependencies.
• Pattern - Solutions used to determine responsibility assignment for objects to interact. It is
a name for a successful solution to a well-known common problem.
• Parameter: An argument to an Operation.
• Polymorphism - Same message, different method. Also used as a pattern.
• Private: A Visibility level applied to an Attribute or an Operation, indicating that only code
for the Classifier that contains the member can access the member.
• Processor: In a Deployment Diagram, this represents a computer or other programmable
device where code may be deployed.
• Protected: A Visibility level applied to an Attribute or an Operation, indicating that only
code for the Classifier that contains the member or for its Subclasses can access the
member.
• Public: A Visibility level applied to an Attribute or an Operation, indicating that any code
can access the member.
• Reading Direction Arrow - Indicates the direction of a relationship in a domain model.
• Realization: Indicates that a Component or a Class provides a given Interface.
• Role - Used in a domain model, it is an optional description about the role of an actor.
• Sequence Diagram: A diagram that shows the existence of Objects over time, and the
Messages that pass between those Objects over time to carry out some behavior. State chart
diagram - A diagram that shows all possible object states.
• State: In a State Diagram, this represents one state of a system or subsystem: what it is
doing at a point in time, as well as the values of its data.
• State Diagram: A diagram that shows States of a system or subsystem, Transitions between
States, and the Events that cause the Transitions.
• Static: A modifier to an Attribute to indicate that there's only one copy of the Attribute
shared among all instances of the Classifier. A modifier to an Operation to indicate that the
Operation stands on its own and doesn't operate on one specific instance of the Classifier.
• Stereotype: A modifier applied to a Model element indicating something about it which
can't normally be expressed in UML. In essence, Stereotypes allow you to define your own
"dialect" of UML.
• Subclass: A Class which inherits Attributes and Operations that are defined by a Subclass
via a Generalization relationship.
• Swimlane: An element of an Activity Diagram that indicates what parts of a system or a
domain perform particular Activities. All Activities within a Swimlane are the responsibility
of the Object, Component, or Actor represented by the Swimlane.
• Time Boxing - Each iteration will have a time limit with specific goals.
• Transition: In an Activity Diagram, represents a flow of control from one Activity or
Branch or Merge or Fork or Join to another. In a State Diagram, represents a change from
one State to another.
• Transition Phase - The last phase of the Rational Unified Process during which users are
trained on using the new system and the system is made available to users.
• UML - Unified Modeling Language utilizes text and graphic documents to enhance the
analysis and design of software projects by allowing more cohesive relationships between
objects.
• Use Case: In a Use Case Diagram, represents an action that the system takes in response to
some request from an Actor.
• Use Case Diagram: A diagram that shows relations between Actors and Use Cases.
• Visibility: A modifier to an Attribute or Operation that indicates what code has access to the
member. Visibility levels include Public, Protected, and Private.
• Workflow - A set of activities that produces some specific result.
 CPE 310 SOFTWARE ENGINEERING

Spring Semester-2021

Dr. Nesrin AYDIN ATASOY

Week 7: UML Use Case Diagrams

7.1Purpose of Use Case Diagram

Use case diagrams are typically developed in the early stage of development
and people often apply use case modeling for the following purposes:

• Specify the context of a system

• Capture the requirements of a system

• Validate a systems architecture

• Drive implementation and generate test cases

• Developed by analysts together with domain experts

7.2 Use Case Diagram at a Glance

• A standard form of use case diagram is defined in the Unified Modeling
Language as shown in the Use Case Diagram example below:
Use case diagrams are considered for high level requirement analysis of a system.
When the requirements of a system are analyzed, the functionalities are captured
in use cases.

We can say that use cases are nothing but the system functionalities written in an
organized manner. The second thing which is relevant to use cases are the actors.
Actors can be defined as something that interacts with the system.

Actors can be a human user, some internal applications, or may be some external
applications. When we are planning to draw a use case diagram, we should have
the following items identified.

• Functionalities to be represented as use case

• Actors

• Relationships among the use cases and actors.

Use case diagrams are drawn to capture the functional requirements of a system.
After identifying the above items, we have to use the following guidelines to
draw an efficient use case diagram

• The name of a use case is very important. The name should be chosen in
such a way so that it can identify the functionalities performed.

• Give a suitable name for actors.

• Show relationships and dependencies clearly in the diagram.

• Do not try to include all types of relationships, as the main purpose of the
diagram is to identify the requirements.

• Use notes whenever required to clarify some important points.

Following is a sample use case diagram representing the order management

system. Hence, if we look into the diagram then we will find three use
cases (Order, SpecialOrder, and NormalOrder) and one actor which is the
customer.

The SpecialOrder and NormalOrder use cases are extended from Order use case.
Hence, they have extended relationship. Another important point is to identify
the system boundary, which is shown in the picture. The actor Customer lies
outside the system as it is an external user of the system.

7.3 How to Identify Actor

Often, people find it easiest to start the requirements elicitation process by
identifying the actors. The following questions can help you identify the actors
of your system (Schneider and Winters - 1998):

• Who uses the system?

• Who installs the system?

• Who starts up the system?

• Who maintains the system?

• Who shuts down the system?

 • What other systems use this system?

• Who gets information from this system?

• Who provides information to the system?

• Does anything happen automatically at a present time?

7.4 How to Identify Use Cases?

Identifying the Use Cases, and then the scenario-based elicitation process carries
on by asking what externally visible, observable value that each actor desires.
The following questions can be asked to identify use cases, once your actors
have been identified (Schneider and Winters - 1998):

• What functions will the actor want from the system?

• Does the system store information? What actors will create, read, update
or delete this information?

• Does the system need to notify an actor about changes in the internal
state?

• Are there any external events the system must know about? What actor
informs the system of those events?
Notation Description Visual Representation

Actor

• Someone interacts with use case

(system function).

• Named by noun.

• Actor plays a role in the business

• Similar to the concept of user, but a

user can play different roles

• For example:

• A prof. can be instructor and

also researcher

• plays 2 roles with two

systems

• Actor triggers use case(s).

• Actor has a responsibility toward

the system (inputs), and Actor has
expectations from the system
(outputs).

Use Case

• System function (process -

automated or manual)

• Named by verb + Noun (or Noun

Phrase).

• i.e. Do something
 • Each Actor must be linked to a use
case, while some use cases may not
be linked to actors.

Communication Link

• The participation of an actor in a

use case is shown by connecting an
actor to a use case by a solid link.

• Actors may be connected to use

cases by associations, indicating
that the actor and the use case
communicate with one another
using messages.
Boundary of system

• The system boundary is potentially

the entire system as defined in the
requirements document.

• For large and complex systems,

each module may be the system
boundary.

• For example, for an ERP system for

an organization, each of the
modules such as personnel, payroll,
accounting, etc.

• can form a system boundary for use

cases specific to each of these
business functions.

• The entire system can span all of

these modules depicting the overall
system boundary
7.3 Structuring Use Case Diagram with Relationships
Use cases share different kinds of relationships. Defining the relationship
between two use cases is the decision of the software analysts of the use case
diagram. A relationship between two use cases is basically modeling the
dependency between the two use cases. The reuse of an existing use case by
using different types of relationships reduces the overall effort required in
developing a system. Use case relationships are listed as the following:

Use Case Relationship Visual Representation

Extends

• Indicates that
an "Invalid
Password" use case
may include (subject
to specified in the
extension) the
behavior specified
by base use
case "Login
Account".

• Depict with a
directed arrow
having a dotted line.
The tip of arrowhead
points to the base
use case and the
child use case is
 connected at the
base of the arrow.

• The stereotype
"<<extends>>"
identifies as an
extend relationship

Include

• When a use case is

depicted as using the
functionality of
another use case, the
relationship between
the use cases is
named as include or
uses relationship.

• A use case includes

the functionality
described in another
use case as a part of
its business process
flow.

• A uses relationship
from base use case
to child use case
indicates that an
instance of the base
use case will include
the behavior as
specified in the child
use case.
 • An include
relationship is
depicted with a
directed arrow
having a dotted line.
The tip of arrowhead
points to the child
use case and the
parent use case
connected at the
base of the arrow.

• The stereotype
"<<include>>"
identifies the
relationship as an
include relationship.

Generalization

• A generalization
relationship is a
parent-child
relationship between
use cases.

• The child use case is

an enhancement of
the parent use case.

• Generalization is
shown as a directed
arrow with a triangle
arrowhead.
 • The child use case is
connected at the
base of the arrow.
The tip of the arrow
is connected to the
parent use case.

7.4. Use Case Examples

1. Use Case Example - Association Link

A Use Case diagram illustrates a set of use cases for a system, i.e. the actors and
the relationships between the actors and use cases.

2. Use Case Example - Include Relationship

The include relationship adds additional functionality not specified in the base
use case. The <<Include>> relationship is used to include common behavior
from an included use case into a base use case in order to support the reuse of
common behavior.
3. Use Case Example - Extend Relationship
The extend relationships are important because they show optional functionality
or system behavior. The <<extend>> relationship is used to include optional
behavior from an extending use case in an extended use case. Take a look at the
use case diagram example below. It shows an extend connector and an extension
point "Search".

4. Use Case Example - Generalization Relationship

A generalization relationship means that a child use case inherits the behavior
and meaning of the parent use case. The child may add or override the behavior
of the parent. The figure below provides a use case example by showing two
generalization connectors that connect between the three use cases.

5. Use Case Diagram - Vehicle Sales Systems

The figure below shows a use case diagram example for a vehicle system. As
you can see even a system as big as a vehicle sales system contains not more
than 10 use cases! That's the beauty of use case modeling.

The use case model also shows the use of extend and include. Besides, there are
associations that connect between actors and use cases.
6. Use-Case Examples
7. Simple example on Use case scenarios