Modelling Requirements

Software requirements and its types, Requirements Engineering

BCSE301L SOFTWARE process, Requirement Elicitation, System Modeling – Requirements
Specification and Requirement Validation, Requirements Elicitation
ENGINEERING techniques, Requirements management in Agile.

Dr.D.KAVITHA
SCOPE
VIT, CHENNAI

Software requirements and its types

Types of Software Requirement Functional Requirements
There are three types of software requirements as follows: • Functional requirements are such software requirements that are
demanded explicitly as basic facilities of the system by the end-users.
1.Functional requirements So, these requirements for functionalities should be necessarily
2.Non-Functional requirements incorporated into the system as a part of the contract.
3.Domain requirements • They describe system behavior under specific conditions. In other
words, they are the functions that one can see directly in the final
product, and it was the requirements of the users as well. It describes
a software system or its components.
• These are represented as inputs to the software system, its behavior,
and its output. It can be a calculation, data manipulation, business
process, user interaction, or any other specific functionality which
defines what function a system is likely to perform.
Functional software requirements help us to capture the intended Non-functional Requirements(NFRs)
behavior of the system. • These requirements are defined as the quality constraints that the
Functional requirements can be incorporated into the system in many system must satisfy to complete the project contract.
ways as Non-functional requirements are more abstract. They deal with issues
1. Natural language like-
2. A structured or formatted language with no rigorous syntax and • Performance
formal specification language with proper syntax. • Reusability
Examples of functional requirements • Flexibility
1. Whenever a user logs into the system, their authentication is done. • Reliability
2. In case of a cyber attack, the whole system is shut down • Maintainability
3. Whenever a user registers on some software system the first time, a • Security
verification email is sent to the user. • Portability

Non-Functional Requirements are classified into many types. Some of Domain Requirements
them are as:
• Domain requirements are the requirements related to a particular
• Interface Constraints category like software, purpose or industry, or other domain of
• Economic Constraints projects. Domain requirements can be functional or non-functional.
• Operating Constraints These are essential functions that a system of specific domains must
necessarily exhibit.
• Performance constraints: storage space, response time, security, etc.
• The common factor for domain requirements is that they meet
• Life Cycle constraints: portability, maintainability, etc. established standards or widely accepted feature sets for that
category of the software project. Domain requirements typically arise
in military, medical, and financial industry sectors. They are identified
from that specific domain and are not user-specific.
 • Difference between Functional Requirement and Non-Functional
Examples of domain requirements are- medical equipment or
Requirement
educational software.
Software in medical equipment Functional Requirement Non-Functional Requirement
• In medical equipment, software must be developed per IEC 60601 It is used for defining a system and its components.
It is used for defining the quality attribute of a
software system.
regarding medical electrical equipment's basic safety and
performance. It focuses on what software will be doing.
It fixes the constraint on which software should fulfill
the functional requirement.
• The software can be functional and usable but not acceptable for The user specifies it.
Techies like architects or software developers specify
production because it fails to meet domain requirements. it.
It is compulsory. It is not compulsory.
An Academic Software It is easy to define. It is comparatively tough to define.

• Such software must be developed to maintain records of an institute It verifies the functionality of the system. It verifies the performance of the system.
efficiently. It is defined as a system at the component level. It is defined as a system as a whole.

• Domain requirement of such software is the functionality of being Example-System should be shut down if a cyber attack Example-Within 10 seconds, the processing should be
happens. done of each request.
able to access the list of faculty and list of students of each grade.

Requirements Engineering process

• Requirements engineering (RE) refers to the process of defining,
documenting, and maintaining requirements in the engineering design
process. Requirement engineering provides the appropriate mechanism to
understand what the customer desires, analyzing the need, and assessing
feasibility, negotiating a reasonable solution, specifying the solution clearly,
validating the specifications and managing the requirements as they are
transformed into a working system.
Requirement Engineering Process is a five-step process, which includes -
1.Feasibility Study
2.Requirement Elicitation and Analysis
3.Software Requirement Specification
4.Software Requirement Validation
5.Software Requirement Management
1. Feasibility Study: 2.Requirement Elicitation and Analysis:
• The objective behind the feasibility study is to create the reasons for • This is also known as the gathering of requirements. Here, requirements
developing the software that is acceptable to users, flexible to change are identified with the help of customers and existing systems processes, if
available.
and conformable to established standards.
• Analysis of requirements starts with requirement elicitation. The
Types of Feasibility: requirements are analyzed to identify inconsistencies, defects, omission,
1.Technical Feasibility - Technical feasibility evaluates the current etc. We describe requirements in terms of relationships and also resolve
conflicts if any.
technologies, which are needed to accomplish customer
requirements within the time and budget. Problems of Elicitation and Analysis
• Getting all, and only, the right people involved.
2.Operational Feasibility - Operational feasibility assesses the range in
which the required software performs a series of levels to solve • Stakeholders often don't know what they want
business problems and customer requirements. • Stakeholders express requirements in their terms.
3.Economic Feasibility - Economic feasibility decides whether the • Stakeholders may have conflicting requirements.
necessary software can generate financial profits for an organization. • Requirement change during the analysis process.
• Organizational and political factors may influence system requirements.

3. Software Requirement Specification:

• Software requirement specification is a kind of document which is created by a software analyst
after the requirements collected from the various sources - the requirement received by the
customer written in ordinary language. It is the job of the analyst to write the requirement in
technical language so that they can be understood and beneficial by the development team.
• The models used at this stage include ER diagrams, data flow diagrams (DFDs), function
decomposition diagrams (FDDs), data dictionaries, etc.
• Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely for modeling the requirements.
DFD shows the flow of data through a system. The system may be a company, an organization, a
set of procedures, a computer hardware system, a software system, or any combination of the
preceding. The DFD is also known as a data flow graph or bubble chart.
• Data Dictionaries: Data Dictionaries are simply repositories to store information about all data
items defined in DFDs. At the requirements stage, the data dictionary should at least define
customer data items, to ensure that the customer and developers use the same definition and
terminologies.
• Entity-Relationship Diagrams: Another tool for requirement specification is the entity-
relationship diagram, often called an "E-R diagram." It is a detailed logical representation of the
data for the organization and uses three main constructs i.e. data entities, relationships, and their
associated attributes.
4. Software Requirement Validation:
Requirements Validation Techniques
• After requirement specifications developed, the requirements
discussed in this document are validated. The user might demand • Requirements reviews/inspections: systematic manual analysis of
illegal, impossible solution or experts may misinterpret the needs. the requirements.
Requirements can be the check against the following conditions - • Prototyping: Using an executable model of the system to check
• If they can practically implement requirements.
• If they are correct and as per the functionality and specially of • Test-case generation: Developing tests for requirements to check
software testability.
• If there are any ambiguities • Automated consistency analysis: checking for the consistency of
structured requirements descriptions.
• If they are full
• If they can describe

5. Software Requirement management Some of the benefits of requirements management include:

A typical requirements management process complements the through
these steps: • Lower cost of development across the lifecycle
• Collect initial requirements from stakeholders • Fewer defects
• Analyze requirements
• Minimized risk for safety-critical products
• Define and record requirements
• Prioritize requirements • Faster delivery
• Agree on and approve requirements • Reusability
• Trace requirements to work items
• Traceability
• Query stakeholders after implementation on needed changes to requirements
• Utilize test management to verify and validate system requirements • Requirements being tied to test cases
• Assess impact of changes • Global configuration management
• Revise requirements
• Document changes
Requirements Elicitation Following tasks are the part of elicitation:
• Requirement elicitation can be done by communicating • Prepare for Elicitation: The purpose here is to
with stakeholders directly or by doing some research, understand the elicitation activity scope, select the right
experiments. The activities can be planned, unplanned, techniques, and plan for appropriate resources.
or both.
• Conduct Elicitation: The purpose here is to explore and
• Planned activities include workshops, experiments. identify information related to change.
• Unplanned activities happen randomly. Prior notice is • Confirm Elicitation Results: In this step, the information
not required for such activities. For example, you directly gathered in the elicitation session is checked for
go to the client site and start discussing the accuracy.
requirements however there was no specific agenda
published in advance.

Requirements Elicitation Techniques • Brainstorming technique is used to answer the below

• There are several techniques available for elicitation, questions:
however, the commonly used techniques are explained
below: • What is the expectation of a system?
1) Stakeholder Analysis • What are the risk factors that affect the proposed
• Stakeholders can include team members, customers, any system development and what to do to avoid that?
individual who is impacted by the project or it can be a • What are the business and organization rules required to
supplier. Stakeholder analysis is done to identify the follow?
stakeholders who will be impacted by the system.
• What are the options available to resolve the current
2) Brainstorming issues?
• This technique is used to generate new ideas and find a • What should we do so that this particular issue does not
solution for a specific issue. The members included for
brainstorming can be domain experts, subject matter happen in the future?
experts.
3) Interview • Document analysis includes reviewing the business plans,
technical documents, problem reports, existing requirement
Interview techniques should be used for building strong documents, etc. This is useful when the plan is to update an
relationships between business analysts and stakeholders. existing system. This technique is useful for migration
projects.
• If the interviewer has a predefined set of questions then it’s • 5) Focus Group
called a structured interview.
• The Focus group includes subject matter experts. The
• If the interviewer is not having any particular format or any objective of this group is to discuss the topic and provide
specific questions then it’s called an unstructured interview. information. A moderator manages this session.
• The moderator should work with business analysts to analyze
4) Document Analysis/Review the results and provide findings to the stakeholders.
This technique is used to gather business information by • If a product is under development and the discussion is
reviewing/examining the available materials that describe the required on that product then the result will be to update
business environment. This analysis is helpful to validate the the existing requirement or you might get new requirements.
If a product is ready to ship then the discussion will be on
implementation of current solutions and is also helpful in releasing the product.
understanding the business need.

• 6) Interface Analysis • 7) Observation

• Interface analysis is used to review the system, people, • The main objective of the observation session is to
understand the activity, task, tools used, and events
and processes. This analysis is used to identify how the performed by others.
information is exchanged between the components. An • The plan for observation ensures that all stakeholders are
Interface can be described as a connection between two aware of the purpose of the observation session, they agree
components. This is described in the below image: on the expected outcomes, and that the session meets their
expectations
• During the session, the observer should record all the
activities and the time taken to perform the work by others
so that he/she can simulate the same. Observation can be
either active or passive.
The interface analysis focus on the below questions: • Active observation is to ask questions and try to attempt the
1.Who will be using the interface? work that other persons are doing.
2.What kind of data will be exchanged? • Passive observation is silent observation i.e. you sit with
3.When will the data be exchanged? others and just observe how they are doing their work
4.How to implement the interface? without interpreting them.
5.Why we need the interface? Can’t the task be completed without using
the interface?
• 8) Prototyping • 10) Survey/Questionnaire
• Prototyping is used to identify missing or unspecified • For Survey/Questionnaire, a set of questions is given to
requirements. In this technique, frequent demos are given to the stakeholders to quantify their thoughts. After collecting the
client by creating the prototypes so that client can get an idea of responses from stakeholders, data is analyzed to identify the area
how the product will look like. of interest of stakeholders.
• 9) Joint Application Development (JAD)/ Requirement Workshops • Questions should be based on high priority risks. Questions should
• This technique is more process-oriented and formal as compared be direct and unambiguous. Once the survey is ready, notify the
to other techniques. These are structured meetings involving end- participants and remind them to participate.
users. This is used to define, clarify, and complete requirements. • Two types of questions can be used here:
• This technique can be divided into the following categories: • Open-Ended: Respondent is given the freedom to provide answers
• Formal Workshops: These workshops are highly structured and in their own words rather than selecting from predefined
are usually conducted with the selected group of stakeholders. responses. This is useful but at the same time, this is time-
The main focus of this workshop is to define, create, refine, and consuming as interpreting the responses is difficult.
reach closure on business requirements. • Close Ended: It includes a predefined set of answers for all the
• Business Process Improvement Workshops: These are less formal questions and the respondent has to choose from those answers.
as compared to the above one. Here, existing business processes Questions can be multiple choice or can be ranked from not
are analyzed and process improvements are identified. important to very important.

System Modeling
• System modeling is the process of developing abstract models of a system, UML Diagram Types
with each model presenting a different view or perspective of that system.
• most models use some kind of graphical notation representing a system,  The System Perspectives (last slide) are modeled with diagrams
which is known as Unified Modeling Language (UML)  Activity diagrams, which show the activities involved in a process or
Benefits of System Modeling in data processing .
1. Ease project management tasks.  Use case diagrams, which show the interactions between a system
and its environment.
2. Can provide complete views of a system, as well as detailed views of
subsystems.  Sequence diagrams, which show interactions between actors and
the system and between system components.
3. Clarify structures and relationships.  Class diagrams, which show the object classes in the system and the
4. Offer a communication framework for ideas within and between teams. associations between these classes.
Can generate new ideas and possibilities.  State diagrams, which show how the system reacts to internal and
5. Allow quality assurance and testing scenarios to be generated. external events.

6. Platform independent.

Chapter 5 System modeling 32

Types of Models 1. Context Models

1. Context models
 Context models are used to illustrate the operational context of a
2. Interaction models system -
3. Structural models  They show what lies outside the system boundaries.
4. Behavioral models
 Social and organizational concerns may affect the decision on
5. Model-driven engineering where to position system boundaries.

 Architectural models show the system and its relationship with

other systems.

Chapter 5 System modeling 34

System Boundaries The Context of the MHC-PMS

 System boundaries are established to define what is inside and what is

outside the system.
 They show other systems that are used or depend on the system being
developed.

 The position of the system boundary has a profound effect on the

system requirements.

 Defining a system boundary is a political judgment

 There may be pressures to develop system boundaries that increase / decrease
the influence or workload of different parts of an organization.

Chapter 5 System modeling 35 Chapter 5 System modeling 36

Process Perspective Process Model of Involuntary Detention

 Context models simply show the other systems in the environment, not
how the system being developed is used in that environment.

 Process models reveal how the system being developed is used in

broader business processes.
 How it 'works' Detailed.

 UML activity diagrams may be used to define business process models.

Chapter 5 System modeling 37 Chapter 5 System modeling 38

2. Interaction Models Use Case Modeling (Interaction Model)

Modeling user interaction is used to identify user  Use cases were developed originally to support requirements
elicitation and now incorporated into the UML.
requirements.
We see structural connections and dynamic  Each use case represents a discrete task that involves external
(behavioral) interactions. interaction with a system.
We do this with graphical models.
 Actors in a use case may be people, devices, or other systems.

Use case diagrams and sequence diagrams may be  Represented diagramatically to provide an overview of the use case
used for interaction modeling. and in a more detailed textual form.
These are the most popular modeling mechanisms

Chapter 5 System modeling 39 Chapter 5 System modeling 40

Transfer-data Use Case Diagram (graphical Tabular Description of the ‘Transfer data’ use-
model) case
MHC-PMS: Transfer data

A use case in the MHC-PMS Actors Medical receptionist, patient records system (PRS)

Description A receptionist may transfer data from the MHC-PMS to a general patient record database that is maintained
by a health authority. The information transferred may either be updated personal information (address,
phone number, etc.) or a summary of the patient’s diagnosis and treatment.
Data Patient’s personal information, treatment summary

Stimulus User command issued by medical receptionist

Response Confirmation that PRS has been updated

Comments The receptionist must have appropriate security permissions to access the patient information and the PRS.

Chapter 5 System modeling

Chapter 5 System modeling 41 42

Use Cases in the MHC-PMS involving the role

‘Medical Receptionist’ (only showing one actor Sequence Diagrams (Interaction Model)
here)

 Sequence diagrams are part of the UML and are used to model the
interactions between the actors and the objects within a system.

 A sequence diagram shows the sequence of interactions that take

place during a particular use case or use case instance.

 The objects and actors involved are listed along the top of the
diagram, with a dotted line drawn vertically from these.

 Interactions between objects are indicated by annotated arrows.

Chapter 5 System modeling 43 Chapter 5 System modeling 44

Sequence diagram for View Patient Information Sequence diagram for Transfer Data

Chapter 5 System modeling 45 Chapter 5 System modeling 46

Key points
Requirements Specification and Requirement Validation
• For requirement specification write(SRS)
 A model is an abstract view of a system that ignores system details.
Complementary system models can be developed to show the system’s Once the SRS completed validation begins
context, interactions, structure and behavior.
Requirement Validation
 Context models show how a system that is being modeled is positioned in • The development of software begins once the requirements
an environment with other systems and processes.
document is ‘ready’
 Use case diagrams and sequence diagrams are used to describe the • Ensure that the requirements specification (SRS)contains no
interactions between users and systems in the system being designed. Use errors and that it specifies the user’s requirements correctly.
cases describe interactions between a system and external actors;
sequence diagrams add more information to these by showing interactions • If errors present in the SRS will adversely affect the cost if they
between system objects.
are detected later in the development process or when the
software is delivered to the user.

Chapter 5 System modeling 47

• So it is desirable to detect errors in the requirements before the • Requirements validation: Have we got the requirements right?
design and development of the software begins. • Requirements analysis: Have we got the right requirements?

• In the validation phase the requirements are examined for • The requirements document should be formulated and organized according to the standards of the organization.
• The organizational standards are specified standards followed by the organization according to which the
consistency, omissions, and ambiguity. system is to be developed.

• The basic objective is to ensure that the SRS reflects the actual
requirements accurately and clearly.
• objectives of the requirements document are given below.
1. To certify that the SRS contains an acceptable description of the system to be implemented
2. To ensure that the actual requirements of the system are reflected in the SRS
3. To check the requirements document for completeness, accuracy, consistency, requirement conflict‘,
The agreed actions is a list that displays the actions to be performed to resolve the problems
conformance to standards and technical errors.
depicted in the problem list.
• Requirements validation studies the ‘final draft’ of the
requirements document while requirements analysis studies the
‘raw requirements’ from the system stakeholders (users).

Requirements Review • In the review meeting check list are:

1. Is the initial state of the system defined?
• Requirements validation determines whether the requirements are substantial to design 2. Is there a conflict between one requirement and the other?
the system. 3. Are all requirements specified at the appropriate level of abstraction?
The problems encountered during requirements validation are listed below. 4. Is the requirement necessary or does it represent an add-on feature that may not be essentially
1.Unclear stated requirements implemented?
5. Is the requirement bounded and has a clear defined meaning?
2.Conflicting requirements are not detected during requirements analysis 6. Is each requirement feasible in the technical environment where the product or system is to be
3.Errors in the requirements elicitation and analysis used?
4.Lack of conformance to quality standards. 7. Is testing possible once the requirement is implemented?
• To avoid the problems stated above, a requirements review is 8. Are requirements associated with performance, behavior, and operational characteristics clearly
stated?
conducted, which consists of a review team that performs a 9. Are requirements patterns used to simplify the requirements model?
systematic analysis of the requirements. 10.Are the requirements consistent with the overall objective specified for the system/product?
11.Have all hardware resources been defined?
• The review team consists of software engineers, users, and 12.Is the provision for possible future modifications specified?
other stakeholders who examine the specification to ensure that 13.Are functions included as desired by the user (and stakeholder)?
14.Can the requirements be implemented in the available budget and technology?
the problems associated with consistency, omissions, and 15.Are the resources of requirements or any system model (created) stated clearly?
errors are detected and corrected.
Other Requirements Validation Techniques
Requirements Elicitation techniques
• A number of other requirements validation techniques are used either individually or in
conjunction with other techniques to check the entire system or parts of the system. The
selection of the validation technique depends on the appropriateness and the size of the https://www.softwaretestinghelp.com/requirements-elicitation-techniques/
system to be developed. Some of these techniques are listed below.
1. Test case generation: The requirements specified in the SRS document should be testable. The
test in the validation process can reveal problems in the requirement. In some cases test becomes
difficult to design, which implies that the requirement is difficult to implement and requires
improvement.
2. Automated consistency analysis: If the requirements are expressed in the form of structured or
formal notations, then CASE tools can be used to check the consistency of the system. A
requirements database is created using a CASE tool that checks the entire requirements in
the database using rules of method or notation. The report of all inconsistencies is identified and
managed.
3. Prototyping: Prototyping is normally used for validating and eliciting new requirements of the
system. This helps to interpret assumptions and provide an appropriate feedback about the
requirements to the user. For example, if users have approved a prototype, which consists of
graphical user interface, then the user interface can be considered validated.

Requirements management in Agile

Designing with greater flexibility through the agile requirements management lifecycle
• Agile requirements management is built on the principle of flexibility, so any
potential challenges are identified and resolved much earlier in The agile requirements management lifecycle is focused on clearly defining a project’s
the process, minimizing expensive and costly rework. A few benefits of the agile scope, so that you better understand what needs to happen to meet the desired end goal.
It provides a high-level understanding of business goals, and outlines what is needed for
approach include: the project to be a success.
• Improved product design and delivery. A recent report suggests that best-in-class Consider taking the following steps:
RM solutions can significantly improve product design and delivery
for agile development teams. “In the face of increasing regulations, connected • Understand user stories. User stories give you powerful information about the problem
products for the internet of things (IoT), and scaling Agile practices, AD&D you’re trying to solve. A user story is a quick description of everyday use cases and might
[application development and delivery] leaders long for something to bring include a few sentences about how the user expects the product to perform. A template
might be something like this: “As a [role], I need [product] to do [goal of the software]
traceability and auditability to their processes without sacrificing speed.” so that I can [benefit of the product].”
• Improved traceability. The right RM solution can enhance development • Outline the most important requirements. Identify what requirements are most essential
transparency through traceability. Traceability empowers teams to perform impact based on the high-level business strategy. These requirements may be supported by user
analysis more readily, which is critical to product development. stories, functional requirements and more based on the specific client goals.
• Achieve quicker time to market. Teams are facing more complexity and pressure to • Transform to product features. This stage is about fine-tuning and translating the details
comply with industry regulations, and need to measure customer value to search, that you’ve gathered into product features. The development team collaborates to ensure
track and connect interdependent requirements. Achieving faster time that any requirements are easily understood by anyone working to implement them. User
to market requires that teams collaborate faster and more effectively, working to stories are linked to features and tasks, so that developers understand what they need to
build traceability requirements and test case do – but also why they are doing it.
• Collaboration and Buy-In • Traceability and Change Management
• It’s difficult to get a company to agree on requirements, particularly for • Requirements traceability is a way to keep everyone in the loop.
large projects with many stakeholders. In practice, it’s not necessary to
achieve consensus through compromise. It’s more important to have team It organizes, documents and keeps track of all requirements,
buy-in (before or after management approves the project) so the from initial idea to testing. A simple metaphor for traceability is
development process can move forward. With buy-in, the team backs the connecting the dots to identify the relationships between items
best solution, makes a smart decision and does what is necessary to move within a project. The following figure shows an example of a
forward with the requirements management process. common downstream flow.
• Team collaboration is key to establishing good requirements. Collaborative
teams work hard to make sure everyone has a stake in the project and
provides feedback. When there is a commitment and understanding of
project goals, team members tend to support other’s decisions. It’s when
developers, testers or other stakeholders feel “out of the loop” that
communication issues arise, people get frustrated and projects get
delayed.

• Quality Assurance
• Companies should be able to trace each requirement back to its • Getting requirements right the first time means better quality, faster development cycles and
original business objective throughout the development process, not higher customer satisfaction with the product. Concise, specific requirements can help companies
merely after it’s complete. By tracing requirements, companies can detect and solve problems earlier rather than later, when they are much more expensive to fix.
identify the ripple effect changes have, see if they have completed a • Research has shown that project teams can eliminate 50 percent to 80 percent of project defects
requirement and if they tested it properly. With traceability, and by by effectively managing requirements. In addition, according to Borland Software (now Micro
Focus), it can cost up to 100 times more to correct a defect later in the development process,
managing changes effectively, managers gain the visibility to after it’s been coded, than when it’s still in written form.
anticipate issues and ensure continuous quality. • By integrating requirements management best practices into their quality assurance process,
• Traceability also makes sure the product meets all the vital companies can help teams increase efficiency and eliminate rework. According to the Carnegie
requirements that come from different stakeholders. By tracing Mellon Software Engineering Institute, 60 to 80 percent of the cost of software development is in
rework. In other words, development teams are wasting the majority of their budgets on efforts
requirements, all team members stay connected to each other and they didn’t perform correctly the first time.
to all interdependencies. And by managing changes well, a company • Requirements management best practices can appear to be a complex topic, but at its core, it’s a
can avoid scope creep — unplanned changes that occur when simple concept. It helps teams answer the question: Does everyone — from business leaders to
requirements are not clearly captured, understood and product managers and project leaders to developers, QA managers and testers — understand
communicated. The benefit of good requirements is a clear what is being built and why?
understanding of the product and the scope involved. This leads to a • When everyone is collaborating and has full context and visibility into the discussions, decisions
better development schedule and budget, which prevents delays and and changes involved in product development, they maintain high quality and almost always
ensure success.
cost overruns.
 Software Design
BCSE301L SOFTWARE Design concepts and principles - Abstraction - Refinement - Modularity
Cohesion coupling, Architectural design, Detailed Design Transaction
ENGINEERING Transformation, Refactoring of designs, Object oriented Design User-
Interface Design
Dr.D.KAVITHA
SCOPE
VIT, CHENNAI

Software Design concepts and principles • Problem Partitioning

Software design principles are concerned with providing means to For small problem, we can handle the entire problem at once but for the
handle the complexity of the design process effectively. Effectively significant problem, divide the problems and conquer the problem it means
to divide the problem into smaller pieces so that each piece can be captured
managing the complexity will not only reduce the effort needed for separately.
design but can also reduce the scope of introducing errors during For software design, the goal is to divide the problem into manageable
design. pieces.
• Benefits of Problem Partitioning
principles of Software Design
1.Software is easy to understand
2.Software becomes simple
3.Software is easy to test
4.Software is easy to modify
5.Software is easy to maintain
6.Software is easy to expand
Abstraction Modularity
• An abstraction is a tool that enables a designer to consider a component at an abstract
level without bothering about the internal details of the implementation. Abstraction can • Modularity specifies to the division of software into separate modules
be used for existing element as well as the component being designed. which are differently named and addressed and are integrated later on in
• Here, there are two common abstraction mechanisms to obtain the completely functional software. It is the only property that
1.Functional Abstraction allows a program to be intellectually manageable. Single large programs
2.Data Abstraction are difficult to understand and read due to a large number of reference
Functional Abstraction
variables, control paths, global variables, etc.
i. A module is specified by the method it performs. The desirable properties of a modular system are:
• The details of the algorithm to accomplish the functions are not visible to the user of the • Each module is a well-defined system that can be used with other
function. Functional abstraction forms the basis for Function oriented design applications.
approaches.
Data Abstraction • Each module has single specified objectives.
• Details of the data elements are not visible to the users of data. Data Abstraction forms • Modules can be separately compiled and saved in the library.
the basis for Object Oriented design approaches.
• Modules should be simple and easier to use.

Advantages of Modularity Disadvantages of Modularity

• It allows large programs to be written by several or different people • Execution time maybe longer
• It encourages the creation of commonly used routines to be placed in • Storage certainly increased
the library and used by other programs. • Compilation and loading time may be longer
• It simplifies the overlay procedure of loading a large program into • Inter-module communication problems may be increased
main storage.
• More linkage required, run-time may be longer, more source lines
• It provides more checkpoints to measure progress. must be written, and more documentation has to be done
• It provides a framework for complete testing, more accessible to test
• It produced the well designed and more readable program.
Modular Design • 2.Information hiding: The fundamental of Information hiding
• Modular design reduces the design complexity and results in easier and suggests that modules can be characterized by the design decisions
faster implementation by allowing parallel development of various parts of that protect from the others, i.e., In other words, modules should be
a system.
• 1. Functional Independence: Functional independence is achieved by specified that data include within a module is inaccessible to other
developing functions that perform only one kind of task and do not modules that do not need for such information.
excessively interact with other modules. Independence is important
because it makes implementation more accessible and faster. The • The use of information hiding for modular system provides the most
independent modules are easier to maintain, test, and reduce error significant benefits when modifications are required during testing's
propagation and can be reused in other programs as well. Thus, functional and later during software maintenance. This is because as most data
independence is a good design feature which ensures software quality.
It is measured using two criteria: and procedures are hidden from other parts of the software,
inadvertent errors introduced during modifications are less likely to
• Cohesion: It measures the relative function strength of a module.
propagate to different locations within the software.
• Coupling: It measures the relative interdependence among modules.

Strategy of Design • 1. Top-down Approach: This approach starts with the identification of
• A good system design strategy is to organize the program modules in the main components and then decomposing them into their more
such a method that are easy to develop and to change. Structured detailed sub-components.
design methods help developers to deal with the size and complexity
of programs. Analysts generate instructions for the developers about
how code should be composed and how pieces of code should fit
together to form a program.
• To design a system, there are two possible approaches:
1.Top-down Approach
2.Bottom-up Approach
 Coupling and Cohesion
2. Bottom-up Approach: A bottom-up approach begins with the lower • Module Coupling
details and moves towards up the hierarchy, as shown in fig. This • In software engineering, the coupling is the degree of interdependence between
approach is suitable in case of an existing system. software modules. Two modules that are tightly coupled are strongly dependent
on each other. However, two modules that are loosely coupled are not dependent
on each other. Uncoupled modules have no interdependence at all within them.
The various types of coupling techniques are shown in fig

• A good design is the one that has low coupling. Coupling is measured 1. No Direct Coupling: There is no direct coupling between M1 and M2.
by the number of relations between the modules. That is, the
coupling increases as the number of calls between modules increase
or the amount of shared data is large. Thus, it can be said that a
design with high coupling will have more errors.

In this case, modules are subordinates to different modules. Therefore, no direct coupling.

2. Data Coupling: When data of one module is passed to another module, this is called data coupling.
• 3.Stamp Coupling: Two modules are stamp coupled if they communicate using
composite data items such as structure, objects, etc. When the module passes
non-global data structure or entire structure to another module, they are said to
be stamp coupled. For example, passing structure variable in C or object in C++
language to a module.
• 4. Control Coupling: Control Coupling exists among two modules if data from one
module is used to direct the structure of instruction execution in another.
7. Content Coupling: Content Coupling exists among two modules if they share code, e.g., a branch
• 5. External Coupling: External Coupling arises when two modules share an from one module into another module.
externally imposed data format, communication protocols, or device interface.
This is related to communication to external tools and devices. Module Cohesion
In computer programming, cohesion defines to the degree to which the
• 6. Common Coupling: Two modules are common coupled if they share elements of a module belong together. Thus, cohesion measures the strength of
information through some global data items. relationships between pieces of functionality within a given module. For
example, in highly cohesive systems, functionality is strongly related.

Types of Modules Cohesion 1. Functional Cohesion: Functional Cohesion is said to exist if the different elements of a module, cooperate to
achieve a single function.
example of functional cohesion includes reading transaction records because all the elements related to single
transaction are involved in it.
2. Sequential Cohesion: A module is said to possess sequential cohesion if the element of a module form the
components of the sequence, where the output from one component of the sequence is input to the next.
3.Communicational Cohesion: A module is said to have communicational cohesion, if all tasks of the module
refer to or update the same data structure, e.g., the set of functions defined on an array or a stack.

4.Procedural Cohesion: A module is said to be procedural cohesion if the set of purpose of the module are all
parts of a procedure in which particular sequence of steps has to be carried out for achieving a goal, e.g., the
algorithm for decoding a message.
5.Temporal Cohesion: When a module includes functions that are associated by the fact that all the methods
must be executed in the same time, the module is said to exhibit temporal cohesion.
6.Logical Cohesion: A module is said to be logically cohesive if all the elements of the module perform a similar
operation. For example Error handling, data input and data output, etc.
7.Coincidental Cohesion: A module is said to have coincidental cohesion if it performs a set of tasks that are
associated with each other very loosely.
 Software Architecture Design
• Differentiate between Coupling and Cohesion
• The architecture of a system describes its major components,
Coupling Cohesion their relationships (structures), and how they interact with each
Coupling is also called Inter-Module Binding. Cohesion is also called Intra-Module Binding. other.
Coupling shows the relationships between modules. Cohesion shows the relationship within the module. • Software architecture and design includes several contributory
factors such as Business strategy, quality attributes, human
dynamics, design, and IT environment.
Coupling shows the relative independence between the Cohesion shows the module's relative functional strength.
modules.

While creating, you should aim for low coupling, i.e., While creating you should aim for high cohesion, i.e., a
dependency among modules should be less. cohesive component/ module focuses on a single function
(i.e., single-mindedness) with little interaction with other
modules of the system.

In coupling, modules are linked to the other modules. In cohesion, the module focuses on a single thing.

• Software Architecture and Design divided into two distinct • Further, it involves a set of significant decisions about the
phases: Software Architecture and Software Design. organization related to software development and each of
• In Architecture, nonfunctional decisions are cast and separated these decisions can have a considerable impact on quality,
by the functional requirements. In Design, functional maintainability, performance, and the overall success of the
requirements are accomplished. final product. These decisions comprise of −
Software Architecture • Selection of structural elements and their interfaces by which the
Architecture serves as a blueprint for a system. It provides an system is composed.
abstraction to manage the system complexity and establish a • Behavior as specified in collaborations among those elements.
communication and coordination mechanism among • Composition of these structural and behavioral elements into large
components. subsystem.
It defines a structured solution to meet all the technical and • Architectural decisions align with business objectives.
operational requirements, while optimizing the common quality • Architectural styles guide the organization.
attributes like performance and security.
Software Design
• Software design provides a design plan that describes the
elements of a system, how they fit, and work together to fulfill
the requirement of the system. The objectives of having a
design plan are as follows −
• To negotiate system requirements, and to set expectations
with customers, marketing, and management personnel.
• Act as a blueprint during the development process.
• Guide the implementation tasks, including detailed design,
coding, integration, and testing.
• It comes before the detailed design, coding, integration, and
testing and after the domain analysis, requirements analysis,
and risk analysis.

Goals of Architecture Limitations

• The primary goal of the architecture is to identify requirements that affect
the structure of the application. A well-laid architecture reduces the Software architecture is still an emerging discipline within
business risks associated with building a technical solution and builds a software engineering. It has the following limitations −
bridge between business and technical requirements.
• Lack of tools and standardized ways to represent architecture.
Some of the other goals are as follows −
• Expose the structure of the system, but hide its implementation details. • Lack of analysis methods to predict whether architecture will
result in an implementation that meets the requirements.
• Realize all the use-cases and scenarios.
• Try to address the requirements of various stakeholders. • Lack of awareness of the importance of architectural design to
• Handle both functional and quality requirements. software development.
• Reduce the goal of ownership and improve the organization’s market • Lack of understanding of the role of software architect and
position. poor communication among stakeholders.
• Improve quality and functionality offered by the system. • Lack of understanding of the design process, design experience
• Improve external confidence in either the organization or system. and evaluation of design.
 Dynamic Quality Attributes
Quality Attributes • Reflect the behavior of the system during its execution. They are directly related to
• Quality is a measure of excellence or the state of being free from system’s architecture, design, source code, configuration, deployment parameters,
environment, and platform.
deficiencies or defects. Quality attributes are the system properties • They are visible to the end-user and exist at runtime, e.g. throughput, robustness,
that are separate from the functionality of the system. scalability, etc.
Quality Scenarios
• Implementing quality attributes makes it easier to differentiate a • Quality scenarios specify how to prevent a fault from becoming a failure. They can be
good system from a bad one. Attributes are overall factors that divided into six parts based on their attribute specifications −
affect runtime behavior, system design, and user experience. • Source − An internal or external entity such as people, hardware, software, or physical
infrastructure that generate the stimulus.
They can be classified as − • Stimulus − A condition that needs to be considered when it arrives on a system.
Static Quality Attributes • Environment − The stimulus occurs within certain conditions.
• Artifact − A whole system or some part of it such as processors, communication
• Reflect the structure of a system and organization, directly related channels, persistent storage, processes etc.
to architecture, design, and source code. They are invisible to end- • Response − An activity undertaken after the arrival of stimulus such as detect faults,
recover from fault, disable event source etc.
user, but affect the development and maintenance cost, e.g.: • Response measure − Should measure the occurred responses so that the requirements
modularity, testability, maintainability, etc. can be tested.

Architectural Style
• The architectural style, also called as architectural
pattern, is a set of principles which shapes an application. • The software that is built for computer-based systems exhibit one
It defines an abstract framework for a family of system in of many architectural styles. Each style describes a system category
terms of the pattern of structural organization. that encompasses −
The architectural style is responsible to − • A set of component types which perform a required function by the
system.
• Provide a lexicon of components and connectors with rules • A set of connectors (subroutine call, remote procedure call, data
on how they can be combined. stream, and socket) that enable communication, coordination, and
• Improve partitioning and allow the reuse of design by cooperation among different components.
giving solutions to frequently occurring problems. • Semantic constraints which define how components can be
integrated to form the system.
• Describe a particular way to configure a collection of • A topological layout of the components indicating their runtime
components (a module with well-defined interfaces, interrelationships.
reusable, and replaceable) and connectors (communication
link between modules).
Types of Architecture
• There are four types of architecture from the viewpoint of an • Information architecture − Defines the logical and physical data
enterprise and collectively, these architectures are referred to assets and data management resources.
as enterprise architecture. • Information technology (IT) architecture − Defines the hardware
• Business architecture − Defines the strategy of business, and software building blocks that make up the overall information
governance, organization, and key business processes within system of the organization.
an enterprise and focuses on the analysis and design of Architecture Design Process
business processes. • The architecture design process focuses on the decomposition of a
system into different components and their interactions to satisfy
• Application (software) architecture − Serves as the blueprint functional and nonfunctional requirements. The key inputs to
for individual application systems, their interactions, and their software architecture design are −
relationships to the business processes of the organization. • The requirements produced by the analysis tasks.

• The hardware architecture (the software architect in turn • Many software projects and products are considered failures
provides requirements to the system architect, who configures because they did not actually solve a valid business problem or
have a recognizable return on investment (ROI).
the hardware architecture).
Identify Design Elements and their Relationships
• The result or output of the architecture design process is • In this phase, build a baseline for defining the boundaries and
an architectural description. The basic architecture design context of the system.
process is composed of the following steps − • Decomposition of the system into its main components based on
functional requirements. The decomposition can be modeled using a
Understand the Problem design structure matrix (DSM), which shows the dependencies
• This is the most crucial step because it affects the quality of the between design elements without specifying the granularity of the
elements.
design that follows. • In this step, the first validation of the architecture is done by
• Without a clear understanding of the problem, it is not possible describing a number of system instances and this step is referred as
functionality based architectural design.
to create an effective solution.
Evaluate the Architecture Design
Transform the Architecture Design
• Each quality attribute is given an estimate so in order to gather • This step is performed after an evaluation of the architectural design. The
qualitative measures or quantitative data, the design is architectural design must be changed until it completely satisfies the
evaluated. quality attribute requirements.
• It involves evaluating the architecture for conformance to • It is concerned with selecting design solutions to improve the quality
architectural quality attributes requirements. attributes while preserving the domain functionality.
• If all estimated quality attributes are as per the required • A design is transformed by applying design operators, styles, or patterns.
For transformation, take the existing design and apply design operator
standard, the architectural design process is finished. such as decomposition, replication, compression, abstraction, and
• If not, the third phase of software architecture design is resource sharing.
entered: architecture transformation. If the observed quality • The design is again evaluated and the same process is repeated multiple
attribute does not meet its requirements, then a new design times if necessary and even performed recursively.
must be created. • The transformations (i.e. quality attribute optimizing solutions) generally
improve one or some quality attributes while they affect others negatively

Key Architecture Principles • Use an Incremental and Iterative Approach

Following are the key principles to be considered while designing an architecture − • Start with baseline architecture and Iteratively add details to the design over
multiple passes to get the big or right picture and then focus on the details.
• Build to Change Instead of Building to Last
Key Design Principles
• Consider how the application may need to change over time to address new
requirements and challenges, and build in the flexibility to support this. Following are the design principles to be considered for minimizing cost,
• Reduce Risk and Model to Analyze maintenance requirements, and maximizing extendibility, usability of architecture
• Use design tools, visualizations, modeling systems such as UML to capture Separation of Concerns
requirements and design decisions. The impacts can also be analyzed. Do not • Divide the components of system into specific features so that there is no
formalize the model to the extent that it suppresses the capability to iterate and overlapping among the components functionality. This will provide high
adapt the design easily. cohesion and low coupling. This approach avoids the interdependency among
• Use Models and Visualizations as a Communication and Collaboration Tool components of system which helps in maintaining the system easy.
• Efficient communication of the design, the decisions, and ongoing changes to the Single Responsibility Principle
design is critical to good architecture. • Each and every module of a system should have one specific responsibility,
• Identify and understand key engineering decisions and areas where mistakes are which helps the user to clearly understand the system. It should also help with
most often made. integration of the component with other components.
Principle of Least Knowledge Identify Components and Group them in Logical Layers
• Any component or object should not have the knowledge about internal details of other • Identity components and the area of concern that are needed in system to satisfy the
components. This approach avoids interdependency and helps maintainability. requirements. Then group these related components in a logical layer, which will help
Minimize Large Design Upfront the user to understand the structure of the system at a high level. Avoid mixing
components of different type of concerns in same layer.
• Minimize large design upfront if the requirements of an application are unclear. If there is Define the Communication Protocol between Layers
a possibility of modifying requirements, then avoid making a large design for whole
system. • Understand how components will communicate with each other which requires a
Do not Repeat the Functionality complete knowledge of deployment scenarios and the production environment.
• Do not repeat functionality specifies that functionality of components should not to be Define Data Format for a Layer
repeated and hence a piece of code should be implemented in one component only. • Various components will interact with each other through data format. Do not mix the
Duplication of functionality within an application can make it difficult to implement data formats so that applications are easy to implement, extend, and maintain.
changes, decrease clarity, and introduce potential inconsistencies.
System Service Components should be Abstract
Prefer Composition over Inheritance while Reusing the Functionality
• Code related to security, communications, or system services like logging, profiling, and
• Inheritance creates dependency between children and parent classes and hence it blocks configuration should be abstracted in the separate components. Do not mix this code
the free use of the child classes. In contrast, the composition provides a great level of with business logic, as it is easy to extend design and maintain it.
freedom and reduces the inheritance hierarchies.

Design Exceptions and Exception Handling Mechanism Transaction Mapping

• Defining exceptions in advance, helps the components to In many software applications, a single data item triggers one or a
manage errors or unwanted situation in an elegant manner. number of information flows that effect a function implied by the
The exception management will be same throughout the triggering data item. The data item, called a transaction, and its
system. corresponding flow characteristics . In this section we consider
Naming Conventions design steps used to treat transaction flow.
• Naming conventions should be defined in advance. They An Example
provide a consistent model that helps the users to understand Transaction mapping will be illustrated by considering the user
the system easily. It is easier for team members to validate interaction subsystem of the SafeHome software.
code written by others, and hence will increase the
maintainability.
 • As shown in the figure, user commands flows into the system
and results in additional information flow along one of three
action paths. A single data item, command type, causes the data
flow to fan outward from a hub. Therefore, the overall data flow
characteristic is transaction oriented.

It should be noted that information flow along two of the three

action paths accommodate additional incoming flow (e.g., system
parameters and data are input on the "configure" action path).
Each action path flows into a single transform, display messages
and status.

Design Steps Step 4.

Identify the transaction center and the flow characteristics along each
• The design steps for transaction mapping are similar and in of the action paths. The location of the transaction center can be
some cases identical to steps for transform mapping . A major immediately discerned from the DFD.
difference lies in the mapping of DFD to software structure.
Step 1. Review the fundamental system model. The incoming path (i.e., the flow path along which a transaction is
Step 2. Review and refine data flow diagrams for the software. received) and all action paths must also be isolated. Boundaries that
define a reception path and action paths are also shown in the figure.
Step 3. Determine whether the DFD has transform or transaction
flow characteristics. Each action path must be evaluated for its individual flow
characteristic.
Steps 1, 2, and 3 are identical to corresponding steps in transform For example, the "password" path has transform characteristics.
mapping. Incoming, transform, and outgoing flow are indicated with boundaries.
• Step 5. Map the DFD in a program structure amenable to
transaction processing.
• Transaction flow is mapped into an architecture that contains an
incoming branch and a dispatch branch.
• Starting at the transaction center, bubbles along the incoming
path are mapped into modules.
• The structure of the dispatch branch contains a dispatcher
module that controls all subordinate action modules.
• Each action flow path of the DFD is mapped to a structure that
corresponds to its specific flow characteristics. This process is
illustrated schematically in figure below.

• Considering the user interaction subsystem data flow, first-level

factoring for step 5 is shown in below figure. • Step 6. Factor and refine the transaction structure and the structure
of each action path.
• Each action path of the data flow diagram has its own information
flow characteristics.

As an example, consider the password processing information flow

shown (inside shaded area) in figure
The flow exhibits classic transform characteristics. A password is input
(incoming flow) and transmitted to a transform center where it is
compared against stored passwords.
The bubbles read user command and activate/deactivate system map directly into the An alarm and warning message (outgoing flow) are produced (if a
architecture without the need for intermediate control modules. The transaction center, match is not obtained).
invoke command processing, maps directly into a dispatcher module of the same name.
Controllers for system configuration and password processing are created as illustrated in
The "configure" path is drawn similarly using the transform mapping.
figure.
The resultant software architecture is shown in the figure below
 Transform Mapping
Transform mapping is a set of design steps that allows a DFD with
transform flow characteristics to be mapped into a specific
architectural style.
example system—a portion of the SafeHome security software.
An Example
This product monitors the real world and reacts to changes that it
encounters.
Step 7. Refine the first-iteration architecture using design heuristics for improved
software quality. This step for transaction mapping is identical to the corresponding step
It also interacts with a user through a series of typed inputs and
for transform mapping. In both design approaches, criteria such as module independence, alphanumeric displays. The level 0 data flow diagram for
practicality (efficacy of implementation and test), and maintainability must be carefully SafeHome, is shown in figure
considered as structural modifications are proposed.

Design Steps
The preceding example will be used to illustrate each step in
transform mapping. The steps begin with a re-evaluation of work
done during requirements analysis and then move to the design
of the software architecture.
Step 1. Review the fundamental system model.
The fundamental system model encompasses the level 0 DFD and
supporting information.
The design step begins with an evaluation of both the System
During requirements analysis, more detailed flow models would be created for SafeHome. In
Specification and the Software Requirements Specification.
addition, control and process specifications, a data dictionary, and various behavioral Both documents describe information flow and structure at the
models would also be created. software interface. Figure 1 and 2 depict level 0 and level 1 data
flow for the SafeHome software.
Step 2. Review and refine data flow diagrams for the
software.
• Information obtained from analysis models contained in the
Software Requirements Specification is refined to produce
greater detail.
• For example, the level 2 DFD for monitor sensors is examined,
and a level 3 data flow diagram is derived .
• At level 3, each transform in the data flow diagram exhibits
relatively high cohesion.
• That is, the process implied by a transform performs a single,
distinct function that can be implemented in the SafeHome
software.

Step 3. Determine whether the DFD has transform or

transaction flow characteristics.
• In general, information flow within a system can always be
represented as transform.
• In this step, the designer selects global flow characteristics
based on the prevailing nature of the DFD.
• In addition, local regions of transform or transaction flow are
isolated.
• These subflows can be used to refine program architecture
derived from a global characteristic described previously.
• For now, we focus our attention only on the monitor sensors
subsystem data flow depicted in figure.
 Step 4. Isolate the transform center by specifying incoming
and outgoing flow boundaries.
• In the preceding section incoming flow was described as a path
in which information is converted from external to internal form;
• outgoing flow converts from internal to external form. Incoming
and outgoing flow boundaries are open to interpretation.
• That is, different designers may select slightly different points in
the flow as boundary locations.

Evaluating the DFD , we see data entering the software

along one incoming path and exiting along three outgoing
paths. No distinct transaction center is implied (although
the transform establishes alarm conditions that could be
perceived as such). Therefore, an overall transform
characteristic will be assumed for information flow.

• Step 5. Perform "first-level factoring." Program structure • Step 6. Perform "second-level factoring." Second-level
represents a top-down distribution of control. factoring is accomplished by mapping individual transforms
(bubbles) of a DFD into appropriate modules within the
• Factoring results in a program structure in which top-level architecture.
modules perform decision making and low-level modules
perform most input, computation, and output work. Middle- • Beginning at the transform center boundary and moving
level modules perform some control and do moderate amounts outward along incoming and then outgoing paths, transforms
of work. are mapped into subordinate levels of the software structure.
•
• Step 7. Refine the first-iteration architecture using design
heuristics for improved software quality. Refactoring of designs
• A first-iteration architecture can always be refined by applying Refactoring is the process of restructuring code, while not
concepts of module independence . Modules are exploded or changing its original functionality. The goal of refactoring is to
imploded to produce sensible factoring, good cohesion, improve internal code by making many small changes without
minimal coupling, and most important, a structure that can be altering the code's external behavior.
implemented without difficulty, tested without confusion, and software developers refactor code to improve the design,
maintained without grief. structure and implementation of software. Refactoring improves
code readability and reduces complexities.
These changes preserve the software's original behavior and do
not modify its behavior.

• Code modification is done without changing any functions of the

Purpose of refactoring program itself. Many basic editing environments support simple
refactorings like renaming a function or variable across an
Refactoring improves code by making it: entire code base.
• More efficient by addressing dependencies and complexities. • Refactoring can be performed after a product has
• More maintainable or reusable by increasing efficiency and been deployed, before adding updates and new features to
readability. existing code, or as a part of day-to-day programming.
• Cleaner so it is easier to read and understand. • A better time to perform refactoring, is before adding updates or
• Easier for software developers to find and fix bugs or new features to existing code.
vulnerabilities in the code.
Benefits of refactoring
• Makes the code easier to understand and read because the challenges of refactoring
goal is to simplify code and reduce complexities. • The process will take extra time if a development team is in a
• Improves maintainability and makes it easier to spot bugs or rush and refactoring is not planned for.
make further changes. • Without clear objectives, refactoring can lead to delays and
• Encourages a more in-depth understanding of code. extra work.
Developers have to think further about how their code will mix • Refactoring cannot address software flaws by itself, as it is
with code already in the code base. made to clean code and make it less complex.
• Focus remains only on functionality. Not changing the code's
original functionality ensures the original project does not lose
scope.

Code refactoring best practices Object-Oriented Design

• Plan for refactoring. It may be difficult to make time for the time-consuming practice otherwise.
• In the object-oriented design method, the system is viewed as a
• Refactor first. Developers should do this before adding updates or new features to existing code
to reduce technical debt. collection of objects (i.e., entities). The state is distributed among the
• Refactor in small steps. This gives developers feedback early in the process so they can find objects, and each object handles its state data.
possible bugs, as well as include business requests.
• Set clear objectives. Developers should determine the project scope and goals early in the code
refactoring process. This helps to avoid delays and extra work, as refactoring is meant to be a form
of housekeeping, not an opportunity to changes functions or features.
• Test often. This helps to ensure refactored changes do not introduce new bugs.
• Automate wherever possible. Automation tools make refactoring easier and faster, thus,
improving efficiency.
• Fix software defects separately. Refactoring is not meant to address software flaws.
Troubleshooting and debugging should be done separately.
• Understand the code. Review the code to understand its processes, methods, objects, variables
and other elements.
• Refactor, patch and update regularly. Refactoring generates the most return on investment when
it can address a significant issue without taking too much time and effort.
• Focus on code deduplication. Duplication adds complexities to code, expanding the software's
footprint and wasting system resources.
1.Objects: All entities involved in the solution design are known as 3.Abstraction In object-oriented design, complexity is handled using
objects. For example, person, banks, company, and users are abstraction. Abstraction is the removal of the irrelevant and the
considered as objects. Every entity has some attributes associated amplification of the essentials.
with it and has some methods to perform on the attributes. 5.Encapsulation: Encapsulation is also called an information hiding concept.
2.Classes: A class is a generalized description of an object. An object is The data and operations are linked to a single unit. Encapsulation not only
an instance of a class. A class defines all the attributes, which an bundles essential information of an object together but also restricts access
object can have and methods, which represents the functionality of to the data and methods from the outside world.
the object.
6.Inheritance: OOD allows similar classes to stack up in a hierarchical
3.Messages: Objects communicate by message passing. Messages manner where the lower or sub-classes can import, implement, and re-use
consist of the integrity of the target object, the name of the allowed variables and functions from their immediate superclasses.This
requested operation, and any other action needed to perform the property of OOD is called an inheritance. This makes it easier to define a
function. Messages are often implemented as procedure or function specific class and to create generalized classes from specific ones.
calls.

7. Polymorphism: OOD languages provide a mechanism where User Interface Design

methods performing similar tasks but vary in arguments, can be • The visual part of a computer application or operating system through
assigned the same name. This is known as polymorphism, which allows which a client interacts with a computer or software. It determines
a single interface is performing functions for different types. Depending how commands are given to the computer or the program and how
upon how the service is invoked, the respective portion of the code data is displayed on the screen.
gets executed. Types of User Interface
• There are two main types of User Interface:
• Text-Based User Interface or Command Line Interface
• Graphical User Interface (GUI)
Text-Based User Interface: This method relies primarily on the • GUI Characteristics
keyboard. A typical example of this is UNIX.
Advantages Characteristics Descriptions
Windows Multiple windows allow different information to be
• Many and easier to customizations options. displayed simultaneously on the user's screen.

• Typically capable of more important tasks. Icons Icons different types of information. On some
systems, icons represent files. On other icons
• Disadvantages describes processes.

• Relies heavily on recall rather than recognition. Menus Commands are selected from a menu rather than
typed in a command language.

• Navigation is often more difficult. Pointing A pointing device such as a mouse is used for
selecting choices from a menu or indicating items
Graphical User Interface (GUI): GUI relies much more heavily on the of interests in a window.

mouse. A typical example of this type of interface is any versions of the

Windows operating systems. Graphics Graphics elements can be mixed with text or the
same display.

Advantages UI Design Principles

• Less expert knowledge is required to use it.

• Easier to Navigate and can look through folders quickly in a guess and
check manner.
• The user may switch quickly from one task to another and can
interact with several different applications.
• Disadvantages
• Typically decreased options.
• Usually less customizable. Not easy to use one button for tons of
different variations.
 • Structure: Design should organize the user interface purposefully, in the meaningful and
usual based on precise, consistent models that are apparent and recognizable to users,
putting related things together and separating unrelated things, differentiating dissimilar
things and making similar things resemble one another. The structure principle is
concerned with overall user interface architecture.
• Simplicity: The design should make the simple, common task easy, communicating
clearly and directly in the user's language, and providing good shortcuts that are
meaningfully related to longer procedures. State Diagrams
• Visibility: The design should make all required options and materials for a given function
visible without distracting the user with extraneous or redundant data.
• Feedback: The design should keep users informed of actions or interpretation, changes
of state or condition, and bugs or exceptions that are relevant and of interest to the user
through clear, concise, and unambiguous language familiar to users.
• Tolerance: The design should be flexible and tolerant, decreasing the cost of errors and
misuse by allowing undoing and redoing while also preventing bugs wherever possible by
tolerating varied inputs and sequences and by interpreting all reasonable actions.

Object-Oriented Software Systems Engineering – Chapter 5 Slide 1

Objectives Statechart Diagrams

In this chapter we will: State diagrams describe the life of an object using
Introduce the terms used with respect to state three main elements:
diagrams States of an object
Transitions between states
Discuss the context in which state diagrams are Events that trigger the transitions
used
Introduce substates A state diagram or statechart specifies a state
Discuss concurrent state diagrams machine
A state machine is described for a class
Each object has it’s own state machine

Object-Oriented Software Systems Engineering – Chapter 5 Slide 2 Object-Oriented Software Systems Engineering – Chapter 5 Slide 3
 Why Use Statechart Diagrams? States

Statecharts typically are used to describe state-dependent Show what the dependencies are between the
behaviour for an object state of an object and its reactions to messages
An object responds differently to the same event depending on or other events
what state it is in State
Usually applied to objects but can be applied to any element is a condition or situation during the life of an object
that has behaviour within which it performs some activity, or waits for some
Actors, use cases, methods, subsystems, systems
events
Has a name
Statecharts are typically used in conjunction with interaction Has actions -- execute the state
diagrams (usually sequence diagrams) Has internal transitions -- transitions cause no change in
a state
A statechart describes all events (and states and transitions for substates -- the nested structure of a state involving
a single object) disjoint or concurrent substates
A sequence diagram describes the events for a single
interaction across all objects involved

Object-Oriented Software Systems Engineering – Chapter 5 Slide 4 Object-Oriented Software Systems Engineering – Chapter 5 Slide 5

States Initial and Final States

For example: The initial state of a state machine is indicated

with a solid circle
Known as a pseudo-state
At Work state name A transition from this state will show the first real state
entry/unlock door action performed on entry to state
do/prepare materials activity performed while in state The final state of a state machine is shown as
telephone rings/answer telephone action performed on arrival of named event
include/lecture state name of a sub-state machine concentric circles
exit/lock door action performed on leaving state
A closed loop state machine does not have a final state;
the object lives until the entire system terminates
An open loop state machine represents an object that
may terminate before the system terminates

Object-Oriented Software Systems Engineering – Chapter 5 Slide 6 Object-Oriented Software Systems Engineering – Chapter 5 Slide 7
 Initial and Final States

An example:

At Work go home At Home

go to work

die die

Object-Oriented Software Systems Engineering – Chapter 5 Slide 8

 Actions and Activities

Action
is an executable atomic computation
includes operation calls, the creation or destruction of
another object, or the sending of a signal to an object
associated with transitions and during which an action is
not interruptible -- e.g., entry, exit
Activity is associated with states
Non-atomic or ongoing computation
May run to completion or continue indefinitely
Will be terminated by an event that causes a transition
from the state in which the activity is defined

Object-Oriented Software Systems Engineering – Chapter 5 Slide 13

Events Events

An event signature is described as A time event occurs after a specified time has
Event-name (comma-separated-parameter-list) elapsed
Events appear in the internal transition Event name is specified as keyword after
compartment of a state or on a transition between Parameter list is an expression evaluating to a time
states interval
An event may be one of four types after(10 seconds after state “At Work” is entered)
Signal event No specified start time implies “since entry to the current
Corresponding to the arrival of an asynchronous message state”
or signal
Call event after(2 seconds)
Corresponding to the arrival of a procedural call to an
operation
Time event
Change event

Object-Oriented Software Systems Engineering – Chapter 5 Slide 14 Object-Oriented Software Systems Engineering – Chapter 5 Slide 15
 Events Transitions

A change event occurs whenever a specified A transition is drawn as an arrow between states
condition is met annotated with a transition string
Event name is specified as keyword when The transition string denotes the event and
Parameter list is a boolean expression consequent action
The event occurs when both of the following conditions Only one form of arrowhead is used on statecharts
are met, irrespective of the order when they happen
The distinction between call events and signal events must be
The expression evaluates to true deducted from elsewhere e.g. an interaction diagram
The object is in the required state
For example
A transition string is described as
when (state = At Work)
Event-signature [guard-condition]/action-expression^object.message
when (date = January 1 2007)
If the guard condition is met the transition occurs immediately

Object-Oriented Software Systems Engineering – Chapter 5 Slide 16 Object-Oriented Software Systems Engineering – Chapter 5 Slide 17

Transitions Transitions

A transition whose string contains neither an A transition is triggered when its event occurs
event signature nor a guard condition is said to be If the guard condition is met, the transition is fired
unlabeled If the condition is not met the event is discarded
The guard condition is checked only once
Occurs immediately
If there is no guard condition, triggering will
May still carry an action expression
always cause firing
Note the distinction between a guard condition
and a change event
A guard condition is evaluated once, when the
associated event occurs
A change event occurs whenever its associated
condition is met
Behaviour is as if the condition were being continually
evaluated

Object-Oriented Software Systems Engineering – Chapter 5 Slide 18 Object-Oriented Software Systems Engineering – Chapter 5 Slide 19
 State Diagrams notation State Diagram Example
get first item all items
in stock
[all items checked &&
*[all items checked]
all items available]
get next item Checking Dispatching
Dispatch items
Initial state event final state do / check
name Item do / initiate
[all items checked delivery
&& some items not
Invoice Invoice in stock] delivery
created paying destroyed Order Item
Unpaid Paid

some items Ordering Delivering

not in stock cancelled
transition entry / deliver
state Exit/ Item received
do / order Item Items

Canceling
do / Remove
Item
Object-Oriented Software Systems Engineering – Chapter 5 Slide 20 Object-Oriented Software Systems Engineering – Chapter 5 Slide 21

State Diagram Example including substates

State Diagram - Nested States get first item

*[all items checked]

[all items checked && all items available]
get next item
Checking Dispatch items Dispatching
event-1 Super-state do / check do / initiate
A B Item delivery
event-1
A B [all items checked &&
some items not in stock]
event-2 event-2 Order item delivery

C event-2 Ordering
Exit/ Item received
C do / order Item

Canceling Delivering
cancelled
do / Remove entry / deliver
Item Items
Object-Oriented Software Systems Engineering – Chapter 5 Slide 22 Object-Oriented Software Systems Engineering – Chapter 5 Slide 23
 Concurrent State models
UNIT I UML DIAGRAMS
B
s Finishing
Starting
A C
Introduction to OOAD – Unified Process –

E T
UML diagrams – Use Case – Class Diagrams–
Explicit control
branching(fork)
D G
Interaction Diagrams – State Diagrams –

F Activity Diagrams –

Orthogonal Components and Concurrency Package, component and Deployment Diagrams.

shown separated by dashed line
supports concurrency
Objects must be in only one state from each of the
orthogonal components
Object-Oriented Software Systems Engineering – Chapter 5 Slide 24

Overview
• State Diagram  Model the dynamic aspect of a system

State Diagram – Define different states of an object during its lifetime.

– Describes the flow of control from one state to another state.

Describe all of the possible states • A Statechart diagram describes a state machine.

that a particular object can get into and

how the object's state changes as a result of events • A state machine can be defined as a machine
that reach the object. – It defines different states of an object and

These states are controlled by external or internal events.

 Purpose Points to be Clarified
• To model dynamic aspect of a system. • Before a Statechart diagram, clarified the following points:
1. Identify important objects to be analyzed.

2. Identify the states.

• To model life time of a reactive system. • A state is the condition of an object at a moment in time—the time between events

3.Identify the events.

• To describe different states of an object during its life time. An event is a significant or noteworthy occurrence.

For example:

A telephone receiver is taken off the hook

• Define a state machine to model states of an object.
Transition:
• A transition is a relationship between two states that indicates that
when an event occurs, the object moves from the prior state to the
subsequent state.

Transitions are shown as arrows, labeled with their event. Subject of a Statechart Diagram:
States are shown in rounded rectangles. A statechart diagram may be applied to a variety of UML
elements, including:
• classes (conceptual or software)
• use cases
Since an entire "system" may be represented by a class,
it too may have its own statechart diagram.
 Basic notational elements How to Draw: State Diagrams
• Filled circle
– Represent the initial state

• Hollow circle containing a smaller filled circle,

– Indicate the final state (if any)

• Rounded rectangle
– Denote a state.
Activity section of the state symbol depicts
what activities the object will be doing while it is in that state.
• Arrow, denoting transition.

How to Draw: State Diagrams Example: State Diagrams

Conditions based on the activities When the object enters the Checking state
can determine what the next state it performs the activity "check items."
the object transitions to.

After the activity is completed the object transitions to next state based on conditions
[all items available] or [an item is not available].

If an item is not available the order is canceled.

If all items are available then the order is dispatched.

In Dispatching state the activity "initiate delivery" is performed.

After this activity is complete the object transitions to the Delivered state.
 Super-State Super-State
• State diagrams can also show a super-state for the object.

• A super-state is used when many transitions lead to the a certain state.

• Instead of showing all transitions from each state to the redundant state
– A super-state can be used to show that all the states inside of the super-state • Both Checking and Dispatching states can transition into Canceled state
can transition to the redundant state.

• So a transition is shown from a super-state named Active to the state

• This helps make the state diagram easier to read. Cancel.

Example
 Main Usage of State Diagram

1. To model object states of a system.

Activity Diagram
2. To model reactive system.
– Reactive system consists of reactive objects.

A flow chart to represent the flow form one activity to

1. To identify events responsible for state changes. another activity.

2. Forward and reverse engineering.

A UML activity diagram offers rich notation to show

a sequence of activities.
 Overview Purpose
• Activity diagram is used • Draw the activity flow of a system.
– To show message flow from one activity to another.

• Describe the sequence from one activity to another.

• Activity is a particular operation of the system.

• Describe the parallel, branched and concurrent flow of the

• Purposes of activity diagram can be described as: system.
– Draw the activity flow of a system.

– Describe the sequence from one activity to another.

– Describe the parallel, branched and concurrent flow of the system.

Basic Components in an Activity Diagram Basic Components in an Activity Diagram

R e c e iv e d f o r m
• Initial node • Fork
– The filled circle is the starting point – A black bar ( horizontal/vertical )
of the diagram with one flow going into it and
R e c e iv e d f o r m
• Final node several leaving it. This denotes the P a y m e n t fe e s
H o s te l
M e d ic a l c h e c k
a llo t m e n t
– The filled circle with a boarder is the beginning of parallel activities
ending point. An activity diagram • Join
can have zero or more activity final P a y m e n t f e e s H o s te l
state. a llo t m e n t
M e d ic a l c h e c k
– A block bar with several flows I s s u e id e n t it y Is s u e lib r a r y
c a rd c a rd
• Activity entering it and one leaving it. this
– The rounded circle represents denotes the end of parallel activities
activities that occur. An activity is I s s u e id e n t it y I s s u e lib r a r y • Merge
not necessarily a program, it may be c a rd c a rd
– A diamond with several flows
a manual thing also entering and one leaving. The
• Flow/ edge implication is that all incoming flow
– The arrows in the diagram. No label to reach this point until processing
is necessary continues

05 October, 2007 Information System Design 05 October, 2007 Information System Design
IT60105, Autumn 2007 IT60105, Autumn 2007
 Basic Components in an Activity Diagram Basic Components in an Activity Diagram

• Difference between Join and Merge • Decision

– A diamond with one flow
entering and several leaving. The
– A join is different from a merge in that the join synchronizes two flow leaving includes conditions
inflows and produces a single outflow. The outflow from a join cannot as yes/ no state
execute until all inflows have been received • Flow final
– The circle with X though it. This
– A merge passes any control flows straight through it. If two or more indicates that Process stop at this
inflows are received by a merge symbol, the action pointed to by its point
outflow is executed two or more times • Swim lane R e c e iv e d f o r m

– A partition in activity diagram by P a y m e n t fe e s

H o s te l
a llo t m e n t
M e d ic a l c h e c k

means of dashed line, called

swim lane. This swim lane may
I s s u e id e n t it y I s s u e lib r a r y
c a rd c a rd

be horizontal or vertical

05 October, 2007 Information System Design 05 October, 2007 Information System Design
IT60105, Autumn 2007 IT60105, Autumn 2007

Points to be Clarified Main usages of activity diagram

• Before drawing an activity diagram, identify the following • Modeling work flow by using activities.
elements:
1. Activities
• Modeling business requirements.
2. Association

3. Conditions
• High level understanding of the system's functionalities.
4. Constraints

• Once these mentioned parameters are identified

• Investigate business requirements at a later stage.
– Make a mental layout of the entire flow.

• This mental layout is then transformed into an activity diagram.

 Basic Activity Diagram Notations Example
• A black circle represents the start (initial state) of the workflow; • Order management system
• An encircled black circle represents the end (final state). – 4 activities are identified which are associated with conditions
• Rounded rectangles represent actions; 1. Send order by the customer
• Diamonds represent decisions; 2. Receipt of the order
• Bars represent the start (split) or end (join) of concurrent activities; 3. Confirm order
Arrows run from the start towards
the end and represent the order in which 4. Dispatch order
activities happen.

After receiving the order request

Condition checks are performed to check if it is normal or special order.

After the type of order is identified

Dispatch activity is performed
and that is marked as
the termination of the process
 1

Duration : 3 Hrs

Ramakant Soni
Assistant Professor
Dept. of Computer Science
B K Birla Institute of Engineering & Technology, Pilani, India

Ramakant Soni @ BKBIET Pilani

Activity Diagram Purpose

Activity diagram is basically a flow chart to Activity diagrams are not only used for visualizing
represent the flow from one activity to another dynamic nature of a system but they are also used to
construct the executable system by using forward and
activity.
reverse engineering techniques.

The activity can be described as an operation It does not show any message flow from one activity to
of the system. another.

This flow can be sequential, branched or

concurrent.

Ramakant Soni @ BKBIET Pilani 2 Ramakant Soni @ BKBIET Pilani 3

How to draw Activity Diagram

So the purposes can be described as to: Before drawing an activity diagram we must have a
clear understanding about the elements used in activity
• Draw the activity flow of a system. diagram.

First we should identify the following elements :

• Describe the sequence from one activity to another.
1. Activities
2. Association
• Describe the parallel, branched and concurrent flow 3. Conditions
of the system. 4. Constraints

Once the above mentioned parameters are identified we need to

make a mental layout of the entire flow. This mental layout is then
transformed into an activity diagram.

Ramakant Soni @ BKBIET Pilani 4 Ramakant Soni @ BKBIET Pilani 5

Example of an order management system Activity Diagram for order management system
The diagram is drawn with the four main activities :
• Send order by the customer
• Receipt of the order
• Confirm order
• Dispatch order

After receiving the order request condition checks are

performed to check if it is normal or special order.

After the type of order is identified dispatch activity is

performed and that is marked as the termination of the
process.

Ramakant Soni @ BKBIET Pilani 6 Ramakant Soni @ BKBIET Pilani 7

Activity Diagram components

Activity
 Initial node The rounded rectangle represents activities that occur. An
activity is not necessarily a program, it may be a manual thing
The filled circle is the starting point of the diagram also.

 Final node
The filled circle with a boarder is the ending point. An Flow/ edge
activity diagram can have zero or more activity final The arrows in the diagram. No label is necessary.
state.

Ramakant Soni @ BKBIET Pilani 8 Ramakant Soni @ BKBIET Pilani 9

  Merge
 Fork A diamond with several flows entering and one leaving. The
A black bar ( horizontal/vertical ) with one flow going into it implication is that all incoming flow to reach this point until
and several leaving it. This denotes the beginning of parallel processing continues
activities.

 Join  Sub-activity indicator

A block bar with several flows entering it and one leaving it. The rake in the bottom corner of an activity, indicates that
this denotes the end of parallel activities the activity is described by a more finely detailed activity
diagram.

Ramakant Soni @ BKBIET Pilani 10 Ramakant Soni @ BKBIET Pilani 11

Difference between Join and Merge  Decision

› A diamond with one flow entering and several leaving.
› A join is different from a merge in that the join synchronizes The flow leaving includes conditions as yes/ no state.
two inflows and produces a single outflow. The outflow from
a join cannot execute until all inflows have been received.

› A merge passes any control flows straight through it. If two

or more inflows are received by a merge symbol, the action
pointed to by its outflow is executed two or more times.  Flow final
› The circle with X through it. This indicates that Process
stop at this point.

Ramakant Soni @ BKBIET Pilani 12 Ramakant Soni @ BKBIET Pilani 13

  Send Signal Action
 Accept Event Action
Send Signal Action is an action that creates a
Accept Event Action is an action that waits for the
signal instance from its inputs, and transmits it to
occurrence of an event meeting specified
the target object, where it may cause the firing of
condition.
a state machine transition or the execution of an
activity.

Ramakant Soni @ BKBIET Pilani 14 Ramakant Soni @ BKBIET Pilani 15

 Swim lane Activity Diagram notation

A partition in activity diagram by means of dashed line,
called swim lane. This swim lane may be horizontal or
vertical. text  Start at the top black circle
 If condition 1 is TRUE, go
right; if condition 2 is TRUE,
go down
 At first bar (a synchronization
bar), break apart to follow two
parallel paths
 At second bar, come together
to proceed only when both
parallel activities are done

Vertical Swimlane Horizontal Swimlane

Ramakant Soni @ BKBIET Pilani 16 Ramakant Soni @ BKBIET Pilani 17

Activity Diagram notation Use Case: Receiving an Order Use Case: Receiving a Supply
 Activity – an oval

text  Trigger – path exiting an activity text

 Guard – each trigger has a guard, a
logical expression that evaluates to
“true” or “false”
 Synchronization Bar – can break a
trigger into multiple triggers
operating in parallel or can join
multiple triggers into one when all
are complete
 Decision Diamond – used to
describe nested decisions (the first
decision is indicated by an activity
with multiple triggers coming out
of it)

Ramakant Soni @ BKBIET Pilani 18 Ramakant Soni @ BKBIET Pilani 19

Swimlane Activity Diagram

Swimlanes -
Activity Diagrams that show
activities by class.

Arrange activity diagrams

into vertical zones separated
by lines.

Each zone represents the

responsibilities of a particular
class.
(for example a particular
department).

Use Case: Receiving an Order and Receiving a Supply

Ramakant Soni @ BKBIET Pilani 20 Ramakant Soni @ BKBIET Pilani 21
Exercise 1: Online Shopping Process Activity diagram: Online Shopping Process

Scenario:

“Online customer can browse or search items,

view specific item, add it to shopping cart, view
and update shopping cart, checkout. User can
view shopping cart at any time. Checkout is
assumed to include user registration and login.”

Ramakant Soni @ BKBIET Pilani 22 Ramakant Soni @ BKBIET Pilani 23

Exercise 2: Ticket Vending Machine Activity diagram: Ticket Vending Machine

Scenario:
“Activity is started by Commuter actor who needs to buy a
ticket. Ticket vending machine will request trip information from
Commuter. This information will include number and type of
tickets, e.g. whether it is a monthly pass, one way or round
ticket, route number, destination or zone number, etc.

Based on the provided trip info ticket vending machine will

calculate payment due and request payment options. Those
options include payment by cash, or by credit or debit card. If
payment by card was selected by Commuter, another actor,
Bank will participate in the activity by authorizing the payment.
“

Ramakant Soni @ BKBIET Pilani 24 Ramakant Soni @ BKBIET Pilani 25

 Activity diagram: Resolving issues in Software
Exercise 3: Resolving issues in Software

Scenario:

“Prepare an activity diagram which shows how to

resolve an issue in a software design. After ticket is
created by some authority and the issue is reproduced,
issue is identified, resolution is determined, issue is fixed
and verified, and ticket is closed, if issue was resolved.”

Ramakant Soni @ BKBIET Pilani 26 Ramakant Soni @ BKBIET Pilani 27

Exercise 4: Single Sign- on for Google Apps Activity diagram: Single Sign- on for Google Apps
Scenario:
To interact with partner companies Google uses single sign-on based on OASIS SAML 2.0
protocol. Google acts as service provider with services such as Gmail or Start Pages. Partner
companies act as identity providers and control user names, passwords, and other information
used to identify, authenticate and authorize users for web applications that Google hosts. Each
partner provides Google with the URL of its SSO service as well as the public key that Google will
use to verify SAML responses.

When a user attempts to use some hosted Google application, such as Gmail, Google generates
a SAML authentication request and sends redirect request back to the user's browser. Redirect
points to the specific identity provider. SAML authentication request contains the encoded URL
of the Google application that the user is trying to reach.

The partner identity provider authenticates the user by either asking for valid login credentials
or by checking for its own valid authentication cookies. The partner generates a SAML response
and digitally signs it. The response is forwarded to Google's Assertion Consumer Service (ACS).

Google's ACS verifies the SAML response using the partner's public key. If the response is valid
and user identity was confirmed by identity provider, ACS redirects the user to the destination
URL. Otherwise user will see error message.
Ramakant Soni @ BKBIET Pilani 28 Ramakant Soni @ BKBIET Pilani 29
 1

References:
[1] http://www.uml-diagrams.org/

[2] http://en.wikipedia.org/wiki/Activity_diagram
2nd December 2014
[3] http://www.visual-paradigm.com/VPGallery/diagrams/Activity.html 14h 00-17h 00

[4] http://www.ibm.com/developerworks/rational/library/3101. html

[5] http://www.uml-diagrams.org/activity-diagrams-examples.html

Ramakant Soni
Assistant Professor
Thanks Dept. of Computer Science
B K Birla Institute of Engineering & Technology, Pilani, India
[email protected]
Ramakant Soni @ BKBIET Pilani 4/26/2015 30

Ramakant Soni @ EISTI Cergy 12/2/2014

Sequence Diagram Definition Its Significance

A Sequence diagram is an interaction diagram that An organization's technical staff can find sequence
shows diagrams useful in documenting how a future system
should behave.
-- how the objects and classes involved in the scenario
operate with one another. During the design phase, architects and developers
can use the diagram to force out the system's object
-- the sequence of messages exchanged . interactions, thus fleshing out overall system design.

Ramakant Soni @ EISTI Cergy 12/2/2014 2 Ramakant Soni @ EISTI Cergy 12/2/2014 3
Its Use Targets
One of the primary uses of sequence diagrams is in the
transition from requirements expressed as use cases to Objects as well as classes can be targets which means
the next level of refinement. that messages can be sent to them.

Use cases are often refined into one or more sequence A target is displayed as a rectangle with some text in it.
diagrams.
Below the target, its lifeline(vertical dashed line) extends
In addition to their use in designing new systems, for as long as the target exists.
sequence diagrams can be used to document how
objects in an existing system currently interact. Target

This documentation is very useful when transitioning a

Lifeline
system to another person or organization.

Ramakant Soni @ EISTI Cergy 12/2/2014 4 Ramakant Soni @ EISTI Cergy 12/2/2014 5

Multi Object Class

The basic notation for a class is:

To show how a client interacts with the elements of a
collection, you can use a multi-object.

Its basic notation is:

Only class messages (e.g. shared or static methods in some

programming languages) can be sent to a class. Generally text of
a class is not underlined, which is how you can distinguish it from an
object.

Ramakant Soni @ EISTI Cergy 12/2/2014 6 Ramakant Soni @ EISTI Cergy 12/2/2014 7
Messages Message Notation

Message is a named element that defines one specific

kind of communication between lifelines of an A message is represented by an arrow between the life
interaction. lines of two objects.

The message specifies not only the kind of

communication, but also the sender and the receiver.
-Self calls are also allowed

-The time required by the receiver object to process

the message is denoted by an activation-box.

A message is labeled at minimum with the message

name.

Ramakant Soni @ EISTI Cergy 12/2/2014 8 Ramakant Soni @ EISTI Cergy 12/2/2014 9

Message Types & representation Call Message

Call message is a kind of message that represents an

invocation of operation of target lifeline.

Its type:

- Synchronous Call
- Asynchronous Call

Ramakant Soni @ EISTI Cergy 12/2/2014 10 Ramakant Soni @ EISTI Cergy 12/2/2014 11
Synchronous Call Asynchronous Call- Send

Synchronous call typically represents operation call - Asynchronous call - send message and proceed
send message and suspend execution while waiting for immediately without waiting for return value.
response. Synchronous call messages are shown with Asynchronous messages have an open arrow head.
filled arrow head.

Ramakant Soni @ EISTI Cergy 12/2/2014 12 Ramakant Soni @ EISTI Cergy 12/2/2014 13

Create Message Destroy Message

Create message is sent to a lifeline to create itself. It is Delete message is sent to terminate another lifeline. The
shown as a dashed line with open arrowhead. lifeline usually ends with a cross in the form of an X at
the bottom denoting destruction occurrence.

Ramakant Soni @ EISTI Cergy 12/2/2014 14 Ramakant Soni @ EISTI Cergy 12/2/2014 15
Return Message Self Message

Reply message to an operation call is shown as a A self message can represent a

dashed line with open arrow head (looks similar to recursive call of an operation, or one
creation message). method calling another method
belonging to the same object.

It is shown as creating a nested focus

of control in the lifeline’s execution
occurrence.

Ramakant Soni @ EISTI Cergy 12/2/2014 16 Ramakant Soni @ EISTI Cergy 12/2/2014 17

Combined Fragments fragments

A combined fragment is one or more processing Seq - There are two or more operand fragments. Messages
sequence enclosed in a frame and executed under involving the same lifeline must occur in the order of the fragments.
specific named circumstances. Where they do not involve the same lifelines, messages from
different fragments may be interleaved in parallel.
The fragments available are:
strict - Strict sequencing fragment encloses a series of messages
which must occur in the given order.
alt- Alternative fragment models if…then…else constructs. Only one
sequence occurs on any occasion.
neg - Negative fragment encloses an invalid series of messages.
opt- Optional. Encloses a sequence that might or might not happen.
loop - Loop fragment encloses a series of messages which are
You can specify, in the guard, the condition under which it
repeated.
occurs.
Loop combined fragments have the properties Min and Max,
break- If this fragment is executed, the rest of the sequence is
which indicate the minimum and maximum number of times that
abandoned.
the fragment can be repeated. The default is no restriction.
Par- Parallel fragment denotes concurrent processing.
Ramakant Soni @ EISTI Cergy 12/2/2014 18 Ramakant Soni @ EISTI Cergy 12/2/2014 19
fragments Combined Fragment Example

ignore - Ignore fragment declares a message or message to be of

no interest if it appears in the current context.

consider - Consider fragment is in effect the opposite of the ignore

fragment: any message not included in the consider fragment
should be ignored.

assert - Assertion fragment designates that any sequence not

shown as an operand of the assertion is invalid.

Ramakant Soni @ EISTI Cergy 12/2/2014 20 Ramakant Soni @ EISTI Cergy 12/2/2014 21

Combined Fragment Example

Ramakant Soni @ EISTI Cergy 12/2/2014 22 Ramakant Soni @ EISTI Cergy 12/2/2014 23
Interaction Operands Interaction Operands Example

Interaction operand is a named element representing

the most general interaction unit. Each interaction
fragment is conceptually like an interaction by itself.

Every combined fragment contains at least one

interaction operand, which can contain messages,
interaction uses, and smaller combined fragments.

Ramakant Soni @ EISTI Cergy 12/2/2014 24 Ramakant Soni @ EISTI Cergy 12/2/2014 25

Sequence Diagram Examples Example: Facebook Authentication

Scenario:- Facebook uses OAuth 2.0 protocol framework which enables
web application (called "client"), which is usually not the FB resource
Example 1: owner but is acting on the FB user's behalf, to request access to
resources controlled by the FB user and hosted by the FB server. Instead
of using the FB user credentials to access protected resources, the web
Order booking application obtains an access token.
scenario
Web application should be registered by Facebook to have an
application ID (client_id) and secret (client_secret). When request to
some protected Facebook resources is received, web browser ("user
agent") is redirected to Facebook's authorization server with application
ID and the URL the user should be redirected back to after the
authorization process.

User receives back Request for Permission form. If the user authorizes the
application to get his/her data, Facebook authorization server redirects
back to the URI that was specified before together with authorization
code ("verification string"). The authorization code can be exchanged
by web application for an OAuth access token.
Ramakant Soni @ EISTI Cergy 12/2/2014 26 Ramakant Soni @ EISTI Cergy 12/2/2014 27
 Sequence
Diagram
For
Facebook
If web application obtains the access token for a FB user, it can
perform authorized requests on behalf of that FB user by including the
Authentication
access token in the Facebook Graph API requests. If the user did not Process
authorize web application, Facebook issues redirect request to the URI
specified before, and adds the error_reason parameter to notify the
web application that authorization request was denied.

Ramakant Soni @ EISTI Cergy 12/2/2014 28 Ramakant Soni @ EISTI Cergy 12/2/2014 29

UML Diagrams for ATM: Use Case UML Diagrams for ATM: Sequence diagram

Ramakant Soni @ EISTI Cergy 12/2/2014 30 Ramakant Soni @ EISTI Cergy 12/2/2014 31
UML Diagrams for ATM: class diagram Exercise:
To generate sequence diagram using use case

Steps:-
1. Designate actors and business system—Who is taking part?

2. Designate initiators—Who starts interactions?

3. Describe the message exchange between actors and business

system—Which messages are being exchanged?

4. Identify the course of interactions—What is the order?

5. Insert additional information—What else is important?

6. Verify the view—Is everything correct?

Ramakant Soni @ EISTI Cergy 12/2/2014 32 Ramakant Soni @ EISTI Cergy 12/2/2014 33

Exercise: Credit card processing system Use case

Exercise: Home heating system

Home Heating

Power Up «includes» Temp. High

«includes»
Power Down Adjust Temp
«includes»

Change Temp. «includes»

Temp. Low

Home Owner

Ramakant Soni @ EISTI Cergy 12/2/2014 34 Ramakant Soni @ EISTI Cergy 12/2/2014 35
Exercise: Online Shopping
References:
[1] http://www.uml-diagrams.org/

[2] http://www.wikipedia.com/UML%diagrams

[3] http://staruml.sourceforge.net/docs/user-guide%28en%29/ch05_3.html

[4] http://www.ibm.com/developerworks/rational/library/3101. html

[5] http://www.uml-diagrams.org/sequence-diagrams-examples.html

Ramakant Soni @ EISTI Cergy 12/2/2014 36 Ramakant Soni @ EISTI Cergy 12/2/2014 37