DESIGN BACKEND SYSTEM

School: APADE
Class: Level 4 SOD
Module Name: Backend System Design
Learning Hours: 100
Trainer: Ronald MUGABO

Elements of Competence and Performance Criteria

Elements of Performance criteria

Competence
1.1 FURPS requirements are effectively gathered based on system
application requirements
 1.2 Main objects are properly identified based on the system analysis
1. Analyze methodology
System Backend
1.3 System interactions are clearly described based on identified objects

1.4 System Backend Requirements are appropriately reported in line with

software requirements document

2.1 System structure design tools are properly identified based on analysis
report and design methodology

2.Develop
2.2 The hardware & software technologies are properly identified based on
System Structure system requirements

2.3 The system structure is neatly drawn based on the system requirements
and design methodology

3.1 The data flow of the system is appropriately developed based on the
system design Requirements

3. Build System
3.2 Physical Data Model is accurately designed based on the analysis report
Design
and system structure

3.3 The documentation of system design is properly based on system

analysis and architecture

Learning outcome 1: Analyse System Backend

1.1. FURPS requirements are effectively gathered based on system application requirements
1.2. Main objects are properly identified based on the system analysis methodology
1.3. System interactions are clearly described based on identified objects
1.4. System Backend Requirements are appropriately reported in line with software
requirements document
1.1. FURPS requirements are effectively gathered based on system application
requirements
• Gathering FURPS Requirements (Aletexsoft, 2021)
✓ Definition of key terms
Backend: The back end refers to parts of a computer application or a program's
code that allow it to operate and that cannot be accessed by a user. Most data and
operating syntax are stored and accessed in the back end of a computer system.
System: comprises interacting parts cooperating to accomplish a single objective
or a group of related goals.
Server: A server is a hardware device or software that processes requests sent
over a network and replies to them. The computer system that accepts requests
for online files and transmits those files to the client is referred to as a “server”
in the context of the Internet.
Database: is an organized collection of structured information, or data, typically
stored electronically in a computer system.
Operating System: is the program that, after being initially loaded into the
computer by a boot program, manages all of the other application programs in
a computer.
System Development Life Cycle (SDLC): is a structured process that is used
to design, develop, and test good-quality software.
API: Application Programming Interface, are mechanisms that enable two
software components to communicate with each other using a set of
definitions and protocols.
JSON: JavaScript Object Notation, is a lightweight data interchange format that
provides a standardized and efficient way for different systems to exchange data.
Framework: a collection of reusable software components that make it more
efficient to develop new applications.
UML: Unified Modelling Language, It is a generic developmental modelling
language used for analysis, design and implementation of software systems. The
purpose of UML is to provide a simple and common method to visualise a
software system's inherent architectural properties.
FURPS (Functionality, Usability, Reliability, Performance and Supportability) is
framework that helps software engineers and testers categorize and evaluate
software requirements.
 ✓ System development life cycle (SDLC)
Phases

1. Planning Stage – What Are the Existing Problems?

In this stage, the problem or pain the software targets is clearly defined. First,
developers and other team members outline objectives for the system and draw
a rough plan of how the system will work.
2. Analysis Stage – What Do We Want?
In this step, you incorporate more specific data for your new system. This includes
the first system prototype drafts, market research, and an evaluation of competitors.
To successfully complete the analysis and put together all the critical information for
a certain project, developers should do the following:
• Generate the system requirements. A Software Requirement Specification (SRS)
document will be created at this stage. Your DevOps team should have a high degree
of input in determining the functional and network requirements of the upcoming
project.
• Evaluate existing prototypes. Different prototypes should be evaluated to identify
those with the greatest potential.
• Conduct market research. Market research is essential to define the pains and
needs of end-consumers. In recent years, automated NLP (natural language
processing) research has been undertaken to glean insights from customer reviews

and feedback at scale.

• Set concrete goals. Goals are set and allocated to the stages of the system
development life cycle. Often, these will correspond to the implementation of
specific features.
3. Design Stage – What Will the Finished Project Look Like?
This step of the system development life cycle can significantly eliminate the time
needed to develop the software. It involves outlining the following:
• The system interface
• Databases
• Core software features (including architecture like microservices)
• User interface and usability
• Network and its requirement
4. Development Stage – Let’s Create the System
In the development stage of SDLC, the system creation process produces a working
solution. Developers write code and build the app according to the finalized
requirements and specification documents.
5. Testing Stage – Is It the Exact One We Needed?
The testing stage ensures the application’s features work correctly and coherently and
fulfils user objectives and expectations.

This process involves detecting the possible bugs, defects, and errors, searching for
vulnerabilities, etc., and can sometimes take up even more time compared to the app-
building stage.

6. Integration and Implementation Stage – How Will We Use It?

Once the product is ready to go, it’s time to make it available to its end users and
deploy it to the production environment.
 At this stage, the software undergoes final testing through the training or pre-
production environment, after which it’s ready for presentation on the market.

7. Maintenance Stage – Let’s Make the Improvements

During the first couple of months, developers might face problems that weren’t
detected during initial testing, so they should immediately react to the reported issues
and implement the changes needed for the software’s stable and convenient usage.

Models (Agile, V shaped, Waterfall, Prototyping, etc.)

The 6 SDLC Methodologies

These are the approaches that can help you to deliver a specific software model with
unique characteristics and features. Most developers and project managers opt for one of
these 6 approaches. Hybrid models are also popular.

Let’s discuss the major differences and similarities of each.

1. Waterfall Model

This approach implies a linear type of project phase completion, where each stage has
its separate project plan and is strictly related to the previous and next steps of system
development.
Typically, each stage must be completed before the next one can begin, and extensive
documentation is required to ensure that all tasks are completed before moving on to the
next stage. This is to ensure effective communication between teams working apart at
different stages.

2. Iterative Model

The Iterative model incorporates a series of smaller “waterfalls,” where manageable portions
of code are carefully analyzed, tested, and delivered through repeating development cycles.
Getting early feedback from an end user enables the elimination of issues and bugs in the
early stages of software creation.

The Iterative model is often favored because it is adaptable, and changes are comparatively
easier to accommodate.

3. Spiral Model
The Spiral model best fits large projects where the risk of issues arising is high. Changes are
passed through the different SDLC phases again and again in a so-called “spiral” motion.

It enables regular incorporation of feedback, which significantly reduces the time and costs
required to implement changes.
4. V-Model
Verification and validation methodology requires a rigorous timeline and large amounts
of resources. It is similar to the Waterfall model with the addition of comprehensive
parallel testing during the early stages of the SDLC process.

The verification and validation model tends to be resource-intensive and inflexible. For
projects with clear requirements where testing is important, it can be useful.

5. The Big Bang Model

Mostly used for creating and delivering a wide range of ideas, this model perfectly fits the
clients who don’t have a clear idea or vision of what their final product should look like.

A more concrete vision of project completion is gained via delivering different system
variations that may more accurately define the final output.
 6. Agile Model

The Agile model prioritizes collaboration and the implementation of small changes based
on regular feedback. The Agile model accounts for shifting project requirements, which
may become apparent over the course of SDLC.

Benefits of SDLC

Here are the benefits that the system development life cycle provides:

• Comprehensive overview of system specifications, resources, timeline, and the

project goals

• Clear guidelines for developers

• Each stage of the development process is tested and monitored

• Control over large and complex projects

• Detailed software testing

• Process flexibility
• Lower costs and strict time frames for product delivery

• Enhanced teamwork, collaboration, and shared understanding

Possible Drawbacks of SDLC
Just like any other software development approach, each SDLC model has its drawbacks:

• Increased time and costs for the • A high volume of documentation project
development if a complex which can slow down projects model is required
• Requires many different specialists

• All details need to be specified in

• Client involvement is usually high
advance
• Testing might be too complicated
• SDLC models can be restrictive for certain development teams

✓ Backend development Technologies (InterviewBit, 2023)

To provide any responsive and effective software solution, frontend, and backend are the
two most essential technologies that work together. A back-end framework is used to create
server-side web architectures stably and efficiently. Backend technologies focus on
improving the hidden aspects of the websites and are very important for the proper execution
of any web application. It enables the smooth creation and maintenance of a website.
What is Backend Development?
Whenever you use any application or website, the components that are not visible from the
front eye
However, they are responsible for handling 3 major components:

• Server
• Database
•Logic
Top Backend Technologies
Python and its Frameworks
Python is an interpreted, object-oriented, high-level programming language with dynamic
semantics. Its high-level built in data structures, combined with dynamic typing and dynamic
binding, make it very attractive for Rapid Application Development, as well as for use as a
scripting or glue language to connect existing components together.

• Django • Flask • Pyramid

• Backtrader • Tornado
• Bottle • Robot • BlueBream
• Giotto • CherryPy
 PHP and its Frameworks
PHP stands for Hypertext Preprocessor is a popular backend technology that is widely
used for Web Development. Basically, it is a server-side scripting language that is
primarily designed for creating dynamic web pages and web applications.
Examples of PHP frameworks
• Laravel • Laminas (Zend Framework)
• Symfony • Phalcon
• Yii 2 • Slim Framework
• CakePHP • FuelPHP
• CodeIgniter • PHPPixie
JAVA and its Frameworks
Java is a widely-used programming language for coding web applications. It has been a
popular choice among developers for over two decades, with millions of Java applications in
use today. Java is a multi-platform, object-oriented, and network-centric language that can
be used as a platform in itself. It is a fast, secure, reliable programming language for coding
everything from mobile apps and enterprise software to big data applications and server-side
technologies.
Examples of JAVA frameworks
• Spring • Dropwizard
• Hibernate • Play
• Struts • Vaadin
• Wicket • Blade
• GWT • Grails
JavaScript and its frameworks
A JavaScript framework helps you to design a website or an application,
while the JavaScript Library offers functions. Examples of Javascript
frameworks
• Angular • Vue.js
• React • Ember.js
• Node.js • Polymer
• Backbone.js • Mithril
• Aurelia • Meteor

Ruby and its Framework

Ruby on Rails is an open-source, high level and multipurpose web application framework
that is used to develop server-side applications written in the Ruby language. It follows
the Model View Controller (MVC) architecture. It uses HTML, CSS, and JavaScript to
develop a user interface and XML or JSON for transferring the data.
Examples of Ruby frameworks
• Ruby on Rails • Goliath
• Sinatra • Hanami
• Roda • Padrino
• Camping • NYNY
• Ramaze • Resque
✓ System Analysis tools (Cyblance, n.d.)
Grid chart
Grid charts are used to represent the relationship between two sets of factors in a tabular
method. A grid chart analysis is helpful in eradicating unnecessary reports or unnecessary
data items from reports. It can also be used for identifying the responsibilities of various
managers for a particular sub-system. Grid chart can be very effectively used to trace the
flow of various transactions and reports in the organization. System Flowchart
A system flowchart is a pictorial or diagrammatic representation of the logical flow of
operations and information of an organization. It depicts the clear relationship between input
processing and output considering the entire system. A set of standard symbols are
commonly used for the construction of system flow charts. Decision tree
Some decisions involve a series of steps. The outcome of the first decision guides the second;
the third decision depends on the outcome of the second, and so on. In such type of situations
of decision making uncertainty surrounds each step, so we face uncertainty, piled on
uncertainty.
Decision trees are the model to deal with such kind of problems. They are also very important
in decision making in a probabilistic situation where various opinions (or alternatives) can be
drawn (as if they are the branches of a tree) and the final outcomes can be understood.

Simulation
The simulation model describes the operation of the system in terms of individual events,
components of the system. Mainly, it involves the development of a model which is
mostly mathematical in nature rather than directly describing the behavior of the overall
system. Decision table
Decision tables are a graphical method of representing a sequence of logical decisions. It is
prepared in a tabular form. It lists all possible conditions and associated set of actions. A
decision table consists of the four parts-condition stub, condition entries, action stub, and
action entries.

✓ Data Gathering
The process of gathering and analyzing accurate data from various sources to find answers
to research problems, trends and probabilities, etc., to evaluate possible outcomes.

Why Should You Collect Data?

• It helps you focus your limited energy and resources on the pieces that have the most
impact.

• It aids you in understanding your customers better.

• It helps you analyze trends better, as to how customer opinions and behaviour change
over time.

• You can make quicker, more effective decisions based on the data collected.

• It enables you to segment audiences and curate dedicated marketing strategies for
each segment.
• Feedback data let’s you resolve issues and to improve your product/services where its
most needed.

• It helps improve customer relationships.

What are the Different Types of Data Collection?

Primary Data Collection

Primary data collection is the act of gathering raw data collected for a specific research.
Primary data collection methods can be further divided into two:

1. Qualitative Research Method

The qualitative research method basically depends on the non – calculable elements like the
emotions, opinions and feelings. This method does not involve any numbers or calculations
whatsoever. A fine example of a qualitative data collection method would be open-ended
feedback like a survey form you send out to customers.
2. Quantitative Method

As opposed to qualitative methods of data collection, quantitative method depends on

numbers and mathematical calculations to help you arrive at a conclusion. Any close-ended
question that demands calculated answers, like the ones involving mean, median, mode etc.
A classic example of this type of data collection is polls. You're mainly interested in the
numbers they produce to reach your conclusions/decisions.

Secondary Data Collection

In simple words, Secondary data collection takes place when you collect data from a
secondary source rather than from the original one. This kind of data can be sourced from
online portals, books and journals that have been already published. It is often the easier and
cheaper method when compared to primary data collection.

Effective Data Collection Methods

Primary & Secondary Data Definitions

Primary Data: Data that has been generated by the researcher himself/herself,
surveys, interviews, experiments, specially designed for understanding and solving the
research problem at hand.
Secondary Data: Using existing data generated by large government Institutions, healthcare
facilities etc. as part of organizational record keeping. The data is then extracted from more
varied datafiles.

Supplementary Data: A few years ago the Obama Administration judged that any research
that is done using Federal Public funds should be available for free to the public. Moreover
Data Management Plans should be in place to store and preserve the data for almost eternity.
These data sets are published as Supplementary Materials in the journal lliterature, and data
sets can be downloaded and manipulated for research.

BASIS FOR COMPARISON PRIMARY DATA SECONDARY DATA

Meaning Primary data refers to the Secondary data means

first hand data gathered by data collected by someone
the researcher himself. else earlier.

Data Real time data Past data

Process Very involved Quick and easy

Source Surveys, observations, Government publications,

experiments, questionnaire, websites, books, journal
personal interview, etc. articles, internal records etc.

Cost effectiveness Expensive Economical

Collection time Long Short

Specific Always specific to the May or may not be specific

researcher's needs. to the researcher's need.

Available in Crude form Refined form

Accuracy and Reliability More Relatively less

Quantitative & Qualitative Research Methods

Quantitative Research Definition: Data that can be measured, quantified.

Basically Descriptive Statistics.
Qualitative Research Definition: Data collected that is not numerical, hence cannot be
quantified. It measures other characteristics through interviews, observation and
focused groups among a few methods. It can also be termed as "Categorical
Statistics".

Mixed methods research. When quantitative and qualitative research methods are used.

Qualitative Research Methods:

Method Overall purpose Advantages Challenges

Surveys Quickly and/or easily • can complete • might not get careful
gets lots of information anonymously feedback
from people in a non-
threatening way • inexpensive to • wording can bias
administer client's responses

Method Overall purpose Advantages Challenges

• easy to compare • impersonal

and analyze
• may need sampling
• administer to expert
many people
• doesn't get full story
• can get lots of
data

• many sample
questionnaires
already exist
Interviews • Understand • get full range • can take ime
someone's and depth of
• can be hard to analyze
impressions or information • and compare
experiences
develops
• can be costly
• Learn more relationship
about answers • interviewer can bias
with client
to client's responses
questionnaires
• can be flexible
with client

Observation • Gather firsthand • view • can be difficult to

information operations of interpret seen
about people,
events, or a program as behaviors
programs they are
• can be complex to
actually categorize
occurring observations

• can adapt to
events as they
occur

Method Overall purpose Advantages Challenges

• can influence
behaviors of program
participants

• can be expensive
 Focus • Explore a topic in • quickly and • can be hard to analyze
Groups depth through reliably get responses
group discussion
common
• need good facilitator
impressions
for safety and closure
• can be efficient
• difficult to schedule 6-
way to get
8 people together
much range and
depth of
information in
short time

• can convey key

information
about programs

Case • Understand an • depicts client's • usually time

Studies experience or experience in consuming to
conduct
comprehensiv program input, collect, organize
e examination process and and describe
through cross
results
comparison of • represents depth of
cases • powerful information, rather
means to than breadth
portray
program to
outsiders

✓ Identification of FURPS Requirements

Functionality requirements: specify actions that a system must be able to
perform, without taking physical constraints into consideration.
Functional requirements thus specify the input and output behavior of a
system.
Functional requirements may include:
• Feature sets
• Capabilities
 • Security
Usability requirements: refer to operational characteristics related to users,
such as the user interface, related work procedures, online help, and documentation
Usability requirements may include such subcategories as:
• Human factors • Wizards and agents

• Aesthetics • User documentation

• Consistency in the user interface • Training materials
• Online and context-sensitive help
Reliability requirements: refer to the requirements that describe system
dependability—how reliable the system and the risk of system to be crashed.
Reliability requirements to be considered are:
• Frequency and severity of failure
• Recoverability
• Predictability
• Accuracy
• Mean time between failure (MTBF)
Performance requirements: describe the operational characteristics related to
measures workload, such as throughput and response time.
A performance requirement imposes conditions on functional requirements. For example, for
a given action, it may specify performance parameters for:
• Speed • Throughput

• Efficiency • Response time

• Availability • Recovery time
• Accuracy • Resource usage
Security requirements: refer to the grant of access control to application and
data protection during storage and transmission.
Supportability: are requirements that define necessary system quality attributes
such as performance, usability and reliability, as well as global functional
requirements that are not captured in behavioral requirements artifacts such as
use-cases
Supportability requirements may include:
• Testability • Configurability
• Extensibility • Serviceability
• Adaptability • Installability
• Maintainability • Localizability (internationalization)
• Compatibility
 • Identification of Main objects of Backend System
✓ Define the Scope of Backend System: They are responsible for organizing how the
site's data is stored and retrieved, as well as processing information from other
sources such as databases, APIs, or servers.
✓ Databases: are used to organize and persist data.
✓ APIs: are the collection of clearly defined methods of communication between
different software components.
✓ Servers: This is the computer that receives requests.
✓ Frameworks: templates for a website's backend that software programmers user to
facilitate writing and editing code for their server.
• Description of System Interaction (Vissers, 2016)
✓ Purpose of System Interaction
System integration involves combining various subsystems and apps (backend, frontend,
middleware) into a single, cohesive system to ensure that they work together seamlessly.
✓ Main components of System Interaction Web server
A web server transmits documents to clients and consists of software and hardware. Web
servers can be used locally (in company networks) or mainly via the Internet, which in
turn makes the documents available locally, within the company or worldwide.
The function of a web server involves displaying page content by storing, processing and
making web pages available. They are used for web hosting and hosting data for websites
and applications.

Web servers support HTTP (Hypertext Transfer Protocol), SMTP (Simple Mail Transfer
Protocol) and FTP (File Transfer Protocol).
Application Server
It is system software that resides between the operating system (OS) on one side, the
external resources (such as a database management system [DBMS], communications and
Internet services) on another side and the users’ applications on the third side.
The function of the application server is to act as host (or container) for the user’s
business logic while facilitating access to and performance of the business application.
Database Server
A data server is a type of hardware that enables you to install database software – a
relational Database Management System (DBMS).
This specialist database application gives you two vital capabilities
 • The first is the right back-end infrastructure to store all your data in organised,
customisable tables.
• The second is client-facing services
The client being you, your employees and other stakeholders – enabling you and
authorised personnel to retrieve, change or update specific files wherever and whenever
you want. External Services and API
An external API is a software interface provided by a third-party service that allows
developers to integrate their applications with external systems. It enables access to
functionalities and data of the external service, facilitating seamless integration and
expanding the capabilities of applications by leveraging external services and resources.
Message queues or event Streams
Messaging Queues: Messages remain in the queue until they are consumed or until they
expire based on some policy.

• Typically ensure that messages are delivered in the order they are received.
• Messages are often consumed once and only once by a single consumer.
Streaming: Data in streaming platforms is often persisted for a specified period, allowing
consumers to replay the data if required.
• Maintains data order across multiple partitions.
• Allows multiple consumers to read the same data simultaneously, facilitating a
publish-subscribe model.
• Report of the System Backend Requirements (Bandakkanavar, 2021) ✓
Executive summary
An executive summary is a short introduction that summarises your business plan. Designed
to provide a brief but compelling overview of your plan, it should do the following:
Describe the purpose of your business.
Highlight your target market.
Explain what gap in the market it aims to fill.
Outline basic start-up costs and other important financial details.
✓ Detailed analysis of the Current State
A current state analysis is the evaluation of a business' processes to determine their
effectiveness. By identifying the strengths and weaknesses of various procedures, these
evaluations help businesses improve processes to increase profits and overall
efficiency. ✓ Findings on Gaps and issues
A research gap is a question or a problem that has not been answered by any of the
existing studies or research within your field. Sometimes, a research gap exists when there
is a concept or new idea that hasn't been studied at all.
✓ Recommendations
A recommendation is a suggestion or proposal for something that should be done, as
derived from the findings.

Recommendations can include:

• Improvements in a study approach or methodology

• Policy suggestions

• Worthwhile directions for further research

The purpose of recommendations in research is to provide practical and actionable

suggestions based on the study's findings, guiding future actions, policies, or interventions in
a specific field or context.
Learning outcome 2: System structure design tools are properly identified based on
analysis report and design methodology

2.1. System structure design tools are properly identified based on analysis report and design
methodology
2.2. The hardware & software technologies are properly identified based on system
requirements
2.3. The system structure is neatly drawn based on the system requirements and design
methodology
2.1. System structure design tools are properly identified based on analysis report and
design methodology
2.1.1. Identification of system design tools
2.1.1.1. UML (Unified Modeling Language)

Unified Modeling Language (UML) is a general-purpose modeling language. The main aim
of UML is to define a standard way to visualize the way a system has been designed. It is
quite similar to blueprints used in other fields of engineering. UML is not a programming
language , it is rather a visual language.

The primary goals in the design of the UML

 • Provide users with a ready-to-use, expressive visual modeling language so they can
develop and exchange meaningful models.

• Provide extensibility and specialization mechanisms to extend the core concepts.

• Be independent of particular programming languages and development processes.

• Provide a formal basis for understanding the modeling language.

• Encourage the growth of the OO tools market.

• Support higher-level development concepts such as collaborations, frameworks,

patterns and components.

• Integrate best practices.

Key Features of UML:

1. Visual Modeling: UML uses graphical notations (diagrams) to depict the system's
structure, interactions, and behavior, making it easier for developers and stakeholders to
understand the design.

2. Standardization: UML is a standardized language, meaning it's universally understood

and applied, ensuring consistency in software development projects.

3. Supports Object-Oriented Design (OOD): UML works particularly well with object-
oriented programming languages like Java, C++, and Python.

Components of UML:

UML includes diagrams that can be categorized into two main types:

1. Structural Diagrams: These depict the static aspects of a system, showing the system’s
architecture, components, and relationships between objects.

Examples:

o Class Diagram: Shows the system's classes, attributes, operations, and

relationships (e.g., inheritance, associations).

o Object Diagram: Depicts instances of classes at a particular point in time.

 o Component Diagram: Illustrates the components of a system, such as
libraries and frameworks, and their dependencies.

o Deployment Diagram: Shows the physical architecture of the system, such

as nodes, hardware, and network configurations.

2. Behavioral Diagrams: These show the dynamic behavior of objects in a system, how
they interact, and how the system behaves over time.

Examples:

o Use Case Diagram: Represents the interactions between users (actors) and
the system, showing system functionality from the user's perspective.

o Sequence Diagram: Depicts the order of interactions (messages) between

objects over time in a specific scenario.
o Activity Diagram: Models the workflow or the sequence of activities within
a system, showing control flow from one activity to another.

o State Machine Diagram: Represents the various states an object can be in

and the transitions between these states.

Common UML Diagrams:

1. Class Diagram: Models the static structure by showing classes, their attributes,
methods, and relationships (inheritance, association, aggregation, etc.).
 Class Diagram showing customers, order, Product, OrderLine and CorporateCustomer

2. Use Case Diagram: Represents the functionalities of a system from the user's
perspective, showing the interactions between actors (users) and the system.

3. Sequence Diagram: Shows the interaction between objects in terms of messages

exchanged in a time-ordered sequence.
 4. Activity Diagram: Represents workflows of a system, showing the sequence of
activities, decision points, and parallel processes.

For more details, visit this link: https://www.visual-paradigm.com/guide/uml-unified- modeling-

language/what-is-uml/
Importance of UML:

1. Communication: UML provides a common language that allows team members (developers,
architects, stakeholders) to communicate complex ideas more clearly.

2. Documentation: It serves as a blueprint of the system, providing valuable documentation for

future maintenance and development efforts.

3. System Design and Analysis: UML aids in both the analysis and design phases, allowing
developers to break down complex systems into manageable components.

4. Flexibility: It is not limited to any specific programming language or development process,

making it adaptable to various software development methodologies (e.g., Agile, Waterfall).

Benefits of Using UML:

• Visual Clarity: By representing the system in diagrams, UML makes it easier to

understand the structure and functionality at a glance.

• Facilitates Collaboration: Different stakeholders (e.g., developers, business analysts,

testers) can better understand the system’s design and communicate effectively.
• Improves Design Quality: UML encourages thorough planning, which can lead to more
robust and scalable software systems.

• Reusability: Well-designed UML diagrams can be reused across different projects or for
system upgrades, reducing redundancy.

2.1.1.2. Algorithm

An algorithm is a set of defined steps designed to perform a specific objective. Algorithms are
structured sets of instructions designed to solve specific problems or perform particular tasks.
They function through a series of well-defined steps, each contributing to the ultimate goal.

Here, we break down the typical stages involved in the functioning of an algorithm:

1. Input. The first step involves defining the inputs that the algorithm will use. Inputs
are the data on which the algorithm will operate. It could be anything from a single
value to a complex data structure.

2. Processing. This is the core phase where the algorithm performs operations on the
inputs using a series of computational steps. This phase is guided by logical and
 arithmetic calculations to process the data effectively. Within the processing phase,
there are often crucial substeps:

• Decision making. At various points during processing, decisions need to be

made based on certain conditions. This substep involves directing the flow of
the algorithm based on conditional statements, leading to different paths in the
algorithm.

• Looping. For many algorithms, certain steps need to be repeated multiple

times until a specific condition is met. Looping allows the algorithm to
execute the same steps repeatedly, optimizing the process and saving time.

3. Output. After processing the inputs through various computational and conditional
steps, the algorithm produces an output. This output is the result of the algorithm’s
operations and is used to solve the problem or perform the task at hand.

4. Termination. An algorithm must have a defined stopping point to ensure it doesn’t

run indefinitely. Once all the steps are executed successfully, and the output is
produced, the algorithm reaches its termination point.
What Makes a Good Algorithm?

In the world of computing and data science, creating a good algorithm is a fundamental goal.
A well-crafted algorithm can significantly enhance the efficiency and effectiveness of a system.
There are several principles that underpin whether an algorithm is effective and fit for use:

• Correctness. Foremost, a good algorithm must be correct, meaning it should always

produce the right output for any given input. It should be free of errors and bugs to
ensure reliable performance.

• Efficiency. Efficiency is a critical aspect of a good algorithm. It refers to the optimal

use of computational resources, including time and memory. An efficient algorithm
performs tasks swiftly, saving both time and energy.

• Simplicity. A good algorithm should be simple and straightforward, avoiding

unnecessary complexity. Simplicity facilitates easier understanding, implementation,
and maintenance, making the algorithm more user-friendly.
 • Flexibility. Flexibility is the ability of an algorithm to adapt to changes and varying
conditions. A flexible algorithm can accommodate different inputs and adjust to
modifications without compromising its performance.

• Robustness. Robustness refers to the algorithm's ability to handle errors gracefully. A

robust algorithm can manage unexpected inputs or conditions without crashing,
providing stable and reliable performance.

• Stability. Stability is crucial; it ensures that the algorithm performs reliably and
consistently under various conditions, maintaining its accuracy and reliability over
time, even with varied inputs.

• Maintainability. Maintainability is about how easily an algorithm can be updated or

modified. A maintainable algorithm allows for smooth updates and alterations,
ensuring it remains up-to-date and functional over time.

• Documentation. Good algorithms come with comprehensive documentation that

outlines how the algorithm works, its limitations, and how to use it effectively. Well-
documented algorithms are easier to use and integrate into different systems.
• Security. In the current digital age, security is a paramount concern. A good algorithm
should be designed with security in mind, ensuring that it protects sensitive data and
resists attacks from malicious entities.

How to Create an Algorithm

Creating an algorithm can be a meticulous process that involves a deep understanding of the
problem at hand and the available computational resources. Here are the detailed steps along
with the tools and technologies that can be employed to create a successful algorithm:

1. Identify the problem. Clearly define the problem you want to solve. It is essential to
understand the problem's intricacies and requirements to develop an effective
algorithm.

2. Analyze the problem. Dive deep into the problem to gather all necessary
information. Utilize analytical tools such as Python libraries (like NumPy and pandas)
for data analysis to understand the data structure and patterns better.

3. Design the algorithm. Create a step-by-step procedure to solve the problem. At this
stage, you can use flowchart software like Lucidchart or Microsoft Visio to visually
 map out the algorithm's flow and structure. Developing a pseudocode can also be
beneficial, as it allows you to outline the algorithm's logic in a simplified manner.

4. Select appropriate tools and technologies. Depending on the complexity of the

algorithm, you might need to employ advanced tools and technologies. IDEs like
PyCharm or Visual Studio can be useful for coding the algorithm. Moreover,
leveraging machine learning frameworks such as TensorFlow or Scikit-learn can aid
in developing sophisticated algorithms.

5. Implement the algorithm. Translate your design into a working algorithm using a
programming language suitable for your project. Common choices include Python,
Java, or C++. Ensure to follow best coding practices for readability and
maintainability.

6. Test the algorithm. Rigorously test the implemented algorithm using various testing
tools like JUnit for Java or PyTest for Python. Verify the algorithm with different
inputs to ensure it produces the correct output consistently.
7. Optimize the algorithm. Post-testing, analyze the algorithm's performance and
optimize it for better efficiency. Profiling tools, such as Python’s cProfile, can help
identify bottlenecks, guiding improvements

8. Document the algorithm. Document the algorithm comprehensively, explaining each

step and its function. Tools like Doxygen can generate documentation automatically
from source code, facilitating understanding for other developers.

9. Deploy the algorithm. Deploy the algorithm in a real-world environment. Depending

on the application, use cloud platforms like AWS or Azure for deployment to ensure
scalability and accessibility

10. Maintain and update the algorithm. Post-deployment, maintain the algorithm,
updating it as necessary to adapt to changing conditions and requirements. Use
version control systems like Git to manage updates efficiently

For more details, visit this link: https://www.datacamp.com/blog/what-is-an-algorithm

2.1.1.3. Flowchart

A flowchart is a diagram that depicts a process, system or computer algorithm. A Flowchart

is a graphically representation of the structure of process or system, algorithm or the step-by-
step solution of the problem. The Flowchart describes the flow of data through an
information processing systems and the parts of the flows. The flow is a set of the logic
operations that meet the certain requirements.

Basic Symbols used in Flowchart Designs

Here are the five most common shapes used in a flowchart.

• Oval (Terminal symbol)

• Rectangle (Process symbol)

• Arrow (Arrow Symbol)

• Diamond (Decision symbol)

• Parallelogram (Input/Output symbol)

https://venngage.com/blog/flowchart-symbols/

Rules For Creating Flowchart :

A flowchart is a graphical representation of an algorithm. it should follow some rules while
creating a flowchart
Rule 1: Flowchart opening statement must be ‘start’ keyword.
Rule 2: Flowchart ending statement must be ‘end’ keyword.
Rule 3: All symbols in the flowchart must be connected with an arrow line.
Rule 4: The decision symbol in the flowchart is associated with the arrow line.

Advantages of Flowchart:

• Flowcharts are a better way of communicating the logic of the system.

• Flowcharts act as a guide for blueprint during program designed.

• Flowcharts help in debugging process.

• With the help of flowcharts programs can be easily analyzed.

• It provides better documentation.

• Flowcharts serve as a good proper documentation.

• Easy to trace errors in the software.

• Easy to understand.

• The flowchart can be reused for inconvenience in the future.

• It helps to provide correct logic.

Disadvantages of Flowchart:

• It is difficult to draw flowcharts for large and complex programs.

• There is no standard to determine the amount of detail.

• Difficult to reproduce the flowcharts.

• It is very difficult to modify the Flowchart.

• Making a flowchart is costly.

• Some developer thinks that it is waste of time.

• It makes software processes low.

 • If changes are done in software, then the flowchart must be redrawn

https://www.geeksforgeeks.org/an-introduction-to-flowcharts/

2.1.1.4. Data flow Diagram(DFD)

A data flow diagram offers a visual representation that maps the flow of information within a
system, emphasizing processes, data stores, and external entities. It helps security teams
identify and analyze data pathways, ensuring secure data handling and optimized processes.

Core DFD Symbols

1. Processes: Represented by circles, ovals, or rectangles, processes are used to

transform incoming data flow into outgoing data flow.
2. Data Flow: Represented by arrows, these show the direction and route of data as it
moves through the system. It signifies what kind of information will be input and
output from the system.

3. Data Stores: Often represented by two horizontal lines, these indicate data
repositories like databases or other storage mechanisms where data rests.

4. Entities: Represented by rectangles or squares, entities can be external actors or

system units interacting with the system. They can be sources or destinations of data.

Levels of DFD:

1. Level 0 DFD (Context Diagram):

o Purpose: Provides the highest-level view of the entire system, representing it

as a single process. It shows how the system interacts with external entities
(users, systems, etc.) but does not provide internal details of the system.

o Components: One single process (the entire system), external entities

(people, organizations, or other systems), and the data flows between them.

o Characteristics:

▪ No details of the internal structure of the system.

▪ Represents the entire system as a "black box."

▪ Focuses on inputs and outputs with external entities.

Example:

o In a library system, the context diagram would show a single process, like
"Library Management System," with data flows between entities such as
"Patron" and "Book Supplier."

2. Level 1 DFD:

o Purpose: Provides a detailed breakdown of the main process depicted in the

Level 0 DFD. It shows major sub-processes within the system, internal data
stores, and more specific data flows.
o Components: Multiple processes (sub-processes), data stores, external
entities (from Level 0), and data flows between processes, data stores, and
external entities.

o Characteristics:

▪ Breaks the single process from the Level 0 DFD into multiple, related
sub-processes.

▪ Identifies major data stores that store data used by the system.

▪ Shows how data moves between processes within the system.

Example:

o In the library system, the Level 1 DFD might break the "Library Management
System" into sub-processes such as "Manage Books," "Manage Users,"
"Loan Books," and "Manage Suppliers," with data stores such as "Book
Inventory" and "User Database."

3. Level 2 DFD (and Lower Levels):

o Purpose: Provides further decomposition of the sub-processes in the Level 1

DFD. It shows more detailed data flows and may introduce additional data
stores or sub-processes as necessary.

o Components: Further sub-processes within a single process from Level 1,

data stores, data flows, and external entities (which are typically inherited
from higher levels).
 o Characteristics:

▪ Focuses on a single process from the Level 1 DFD and breaks it down
into smaller, more detailed processes.

▪ Adds more granular details, often including error handling, specific

file accesses, and other lower-level details.

▪ Typically, not all processes from Level 1 will need a Level 2 DFD.
Only complex processes may need further breakdown.
Example:

o In the library system, the "Loan Books" process might be broken down into
smaller processes like "Check User Eligibility," "Update Book Availability,"
and "Record Loan Transaction," each with its own data flows and data stores.

General Rules for Creating DFDs at Different Levels:

1. Balancing: Each level should maintain consistency with the previous level. Inputs
and outputs for a process at one level should match those of the same process in the
higher level.

2. Decomposition: As you move to lower levels (e.g., from Level 1 to Level 2), you
decompose processes to provide more detail.

3. External Entities: External entities typically appear in all levels, as they interact
with the system as a whole.

4. Data Stores: Data stores are introduced at Level 1 and below and can appear in
multiple levels of DFDs if necessary.

2.1.1.5. Entity Relation diagram (ERD)

An entity relationship diagram (ERD), also known as an entity relationship model, is a

graphical representation that depicts relationships among people, objects, places, concepts or
events in an information technology (IT) system. An ERD uses data modeling techniques
that can help define business processes and serve as the foundation for a relational database.

How to create an entity relationship diagram

ERDs are generally depicted in one or more of these models:

 • A conceptual data model, which lacks specific detail but provides an overview of the
scope of the project and how data sets relate to one another.

• A logical data model, which is more detailed than a conceptual data model,
illustrating specific attributes and relationships among data points. While a
conceptual data model does not need to be designed before a logical data model, a
physical data model is based on a logical data model.

• A physical data model, which provides the blueprint for a physical manifestation --
such as a relational database -- of the logical data model. One or more physical data
models can be developed based on a logical data model.

The components of ERD include the following:

1. Entities, which are objects or concepts that can have data stored about them. Entities
refer to tables used in databases.

2. Attributes, which are properties or characteristics of entities. An ERD attribute can be

denoted as a primary key, which identifies a unique attribute, or a foreign key, which
can be assigned to multiple attributes.

3. The relationships between and among those entities.

4. Actions, which describe how entities share information in the database.

5. Connecting lines.

These are the three main cardinalities/ Relationships:

1. A one-to-one relationship (1-1). For example, if each customer in a database is

associated with one mailing address.

2. A one-to-many relationship (1-M). For example, a single customer might place an

order for multiple products. The customer is associated with multiple entities, but all
those entities have a single connection back to the same customer.

3. A many-to-many relationship (M-N). For example, at a company where all call

center agents work with multiple customers, each agent is associated with multiple
customers, and multiple customers might also be associated with multiple agents.

How to draw an ER diagram: Step-by-step guide

Step 1: Defining entities

Start by identifying the main entities in your system. Entities are objects or concepts that
have data to be stored. For example, in a university database, entities might include
"Student,"
"Course," and "Instructor."
Step 2: Establishing relationships

Establishing relationships between entities is a crucial aspect of an ER diagram.

Relationships define how entities are connected or associated with each other. For example,
a "Student" entity may be related to a "Course" entity through an "Enrolls In" relationship.

Step 3: Adding attributes

Attributes provide additional information about entities. Add relevant attributes to the
entities identified in the previous steps.

Specify the properties and characteristics of each attribute. For example, if you have an
attribute called "Age" for the "Student" entity, define its data type (integer, string, etc.) and
any constraints associated with it.

Step 4: Refining the Diagram

In this final step, we focus on refining the ER diagram to enhance clarity and
readability. Organize the entities and relationships in a logical and intuitive manner.
Group related entities together and arrange them in a way that reflects their connections.

For more dateils, visit these links:

https://www.techtarget.com/searchdatamanagement/definition/entity -relationship-diagram-
ERD

https://miro.com/diagramming/how-to-draw-an-er-diagram/

2.1.1.6. Context diagram

A context diagram outlines how external entities interact with an internal software
system. It’s primarily used to help businesses wrap their heads around the scope of a
system. As a result, they can figure out how best to design a new system and its
requirements or how to improve an existing system.
They map out an entire system in a way that’s simple, clear, and easy to
understand. For example, arrows are used to represent the flow of data between the
system and each external element.
Context diagrams vs. data flow diagrams
Context diagrams focus on how external entities interact with your system. It’s the
most basic form of a data flow diagram, providing a broad view of the system and
external entities in an easily digestible way. Because of its simplicity, it’s sometimes
called a level 0 data flow diagram.
Data flow diagrams contain additional information about a system that a context
diagram doesn’t.

What are the benefits of using a context diagram?

Easy to understand
Because a context diagram is a top-level overview, it’s easy for everyone to
follow and understand. You don’t need technical knowledge or expertise to know
what it means. Reduces risks
Context diagrams allow you to plan how your system interacts with external entities
before going live. This gives you the chance to identify potential issues before they
happen and put preventative measures in place.
Enables collaboration
Having a context diagram in place makes it easier for your team to collaborate. Think
about it. You can share the diagram with anyone you want. From colleagues to
management and even key project stakeholders, everyone can be involved in the
process.

Are there any downsides?

Lack of depth and detail
If you’re looking for a detailed diagram, a context diagram isn’t the right choice.
Time-consuming
Creating the actual diagram itself can be a time-consuming process, especially if
you’re using a platform like Word or Excel.
How to create a context diagram
At this stage, you’ve got a solid understanding of what a context diagram is and
when to use it. Now, let’s take a look at the steps required to create a successful
context diagram.
1. Understand your system
Before you create the diagram, you need to fully understand what you want your
system to be. Understanding how it currently works will help you identify areas
of improvement throughout the rest of the process.
2. Add your system to the diagram
Once you’ve got a firm handle on what the system should be, you can add it to your
context diagram.
So how exactly do you put your system into a context diagram?
It depends on the structure you want to use. Most context diagrams will have the
main system in the center circle, which is the focal point of the diagram. All the
external elements interact with this circle.

3. Add your external entities

Now that the system is in place, you can start to add the external elements.
Using squares, rectangles, or any other shapes you want, you can list external entities
that interact with the system.

4. Use arrows to outline the data flow

With all the elements on the diagram, it’s time to add arrows to create the direction of
the data flow. This will show how the external elements interact with the system.

5. Share the finished diagram

When the diagram is done, it’s time to share it with the relevant parties to get
feedback.
 Here are some of the people you might want to share it with:
• Team members: If there are team members that will be directly affected by changes
to an existing system, or the implementation of a new system, they should have their
say in how it performs. After all, they’re the ones that are likely to use it regularly.
• Management staff: Most of the time, you’ll need big changes like this to be signed
off and approved by high-level management.
• Key stakeholders and shareholders: If you’re making big changes to company
processes that can impact the financial success and performance of the business,
chances are there will be some stakeholders and shareholders that will need to sign it
off.
6. Make any necessary changes
When you’ve got all the feedback you need, make the necessary changes to the
diagram.
You’ll probably need more than one round of feedback, especially if you’re getting
input from various people across the business. Again, this is where using a
collaborative platform can be helpful. For more details, visit the link:
https://miro.com/blog/context-diagram/
2.1.1.7. Decision table
A decision table is a structured method for analyzing software behavior under
various conditions. It simplifies testing by organizing test cases into easy-to-read
tables, making it a valuable tool for testers.
A decision table is a good way to settle different combination inputs with their
corresponding outputs and is also called a cause-effect table.
• The reason to call the cause-effect table is a related logical diagramming
technique called cause-effect graphing that is used to obtain the decision
table.
• The information represented in decision tables can also be represented as
decision trees or in a programming language using if-then-else and switch-
case statements.
Importance of Decision Table

Decision tables are very helpful in test design techniques.

 1. Helps testers to search effects of combinations: It helps testers to search the effects
of combinations of different inputs and other software states that must correctly
implement business rules.
2. Helps to start complex business rules: It provides a regular way of starting
complex business rules, that is helpful for developers as well as for testers.
3. Helps in the development process: It assists in the development process with the
developer to do a better job. Testing with all combinations might be impractical.
4. Used in testing: A decision table is basically an outstanding technique used in both
testing and requirements management.
5. Helps to prepare requirements: It is a structured exercise to prepare requirements
when dealing with complex business rules.
6. Helps to model complicated logic: It is also used to model complicated logic.

Advantages of Decision Table

1. Easy conversion of business flow to test case: Any complex business flow can be
easily converted into test scenarios and test cases using this technique.

2. Works iteratively: Decision tables work iteratively which means the table created at
the first iteration is used as input tables for the next tables. The iteration is done only
if the initial table is not satisfactory.

3. Simple to understand: Simple to understand and everyone can use this method to
design the test scenarios & test cases.

4. Provides complete test case coverage: It provides complete coverage of test cases
which helps to reduce the rework on writing test scenarios & test cases.

5. Guarantees every combination is considered: These tables guarantee that we

consider every possible combination of condition values. This is known as its
completeness property.
Creating a Decision Table
A decision table has three components: condition entries, action entries, and rules.

• Conditions are the factors that influence the software’s response

• actions are the expected outcomes.
• The rules define outcomes based on different combinations of conditions and actions.
Creating a decision table involves a step-by-step process that allows testers to organize and
design test cases effectively:

1. Identifying conditions and actions. we start by identifying the relevant conditions

and actions for testing software behavior. For example, if we’re testing a login
feature, conditions could include a valid username and password while the action is
successful login.

2. Constructing the decision table matrix. Once we identify the conditions and
actions, we construct the decision table matrix. The matrix is made up of rows and
columns. Each row represents a particular scenario based on the conditions, and
each column represents the potential actions. The intersections between the rows
and columns define the rules for each scenario.

3. Defining rules for each scenario. We need to set the rules that specify the expected
actions for each combination of conditions. These rules help us determine the
software’s behavior under various conditions, making it easier to understand and
validate its responses.

Here’s what the decision table would look like:

This is a simple example of a decision table for determining scholarship eligibility based on
grades and extracurricular activities.

Advantages

• Decision tables provide a clear and structured representation of complex scenarios.

• They break down the information into manageable tables, making it easier to analyze
and validate the expected outcomes.
• Decision tables are an effective tool for managing multiple combinations of
conditions and actions.
• Decision tables are roadmaps for testers, aiding in visualizing and ensuring no test
cases are unintentionally left behind.
• Decision tables simplify the test case design process.

For more details, visit these links:

https://www.geeksforgeeks.org/software-engineering-decision-table/

https://www.baeldung.com/cs/software-testing-decision-table

2.1.1.8.Use case diagram

A Use Case Diagram in Unified Modeling Language (UML) is a visual representation that
illustrates the interactions between users (actors) and a system.

It captures the functional requirements of a system, showing how different users engage with
various use cases, or specific functionalities, within the system.
When to apply Use Case Diagram?

Use case diagrams are useful in several situations. Here’s when you should consider using
them:

• When you need to gather and clarify user requirements, use case diagrams help
visualize how different users interact with the system.

• If you’re working with diverse groups, including non-technical stakeholders, these

diagrams provide a clear and simple way to convey system functionality.

• During the system design phase, use case diagrams help outline user interactions and
plan features, ensuring that the design aligns with user needs.

• When defining what is included in the system versus what is external, use case
diagrams help clarify these boundaries.

Use Case Diagram Notations

1. Actors

Actors are external entities that interact with the system. These can include users, other
systems, or hardware devices. In the context of a Use Case Diagram, actors initiate use cases
and receive the outcomes. Proper identification and understanding of actors are crucial for
accurately modeling system behavior.

2. Use Cases
Use cases are like scenes in the play. They represent specific things your system can do. In
the online shopping system, examples of use cases could be “Place Order,” “Track
Delivery,” or “Update Product Information”. Use cases are represented by ovals.

3. System Boundary

The system boundary is a visual representation of the scope or limits of the system you are
modeling. It defines what is inside the system and what is outside. The boundary helps to
establish a clear distinction between the elements that are part of the system and those that
are external to it. The system boundary is typically represented by a rectangular box that
surrounds all the use cases of the system.

The purpose of system boundary is to clearly outlines the boundaries of the system, indicating
which components are internal to the system and which are external actors or entities
interacting with the system.

Use Case Diagram Relationships

1. Association Relationship

The Association Relationship represents a communication or interaction between an actor

and a use case. It is depicted by a line connecting the actor to the use case. This relationship
signifies that the actor is involved in the functionality described by the use case.

Example: Online Banking System

• Actor: Customer

• Use Case: Transfer Funds

• Association: A line connecting the “Customer” actor to the “Transfer Funds” use
case, indicating the customer’s involvement in the funds transfer process.
2. Include Relationship

The Include Relationship indicates that a use case includes the functionality of another use
case. It is denoted by a dashed arrow pointing from the including use case to the included
use case. This relationship promotes modular and reusable design.

Example: Social Media Posting

 Use Cases: Compose Post, Add Image

• Include Relationship: The “Compose Post” use case includes the functionality of
“Add Image.” Therefore, composing a post includes the action of adding an image.

3. Extend Relationship

The Extend Relationship illustrates that a use case can be extended by another use case under
specific conditions. It is represented by a dashed arrow with the keyword “extend.” This
relationship is useful for handling optional or exceptional behavior.

Example: Flight Booking System

• Use Cases: Book Flight, Select Seat

• Extend Relationship: The “Select Seat” use case may extend the “Book Flight”
use case when the user wants to choose a specific seat, but it is an optional step.
 •

4. Generalization Relationship

The Generalization Relationship establishes an “is-a” connection between two use cases,
indicating that one use case is a specialized version of another. It is represented by an
arrow pointing from the specialized use case to the general use case.

Example: Vehicle Rental System

• Use Cases: Rent Car, Rent Bike

• Generalization Relationship: Both “Rent Car” and “Rent Bike” are specialized
versions of the general use case “Rent Vehicle.”

How to draw a Use Case diagram in UML?

Below are the main steps to draw use case diagram in UML:

• Step 1: Identify Actors: Determine who or what interacts with the system. These
are your actors. They can be users, other systems, or external entities.

• Step 2: Identify Use Cases: Identify the main functionalities or actions the
system must perform. These are your use cases. Each use case should represent a
specific piece of functionality.
 • Step 3: Connect Actors and Use Cases: Draw lines (associations) between actors
and the use cases they are involved in. This represents the interactions between
actors and the system.
Step 4: Add System Boundary: Draw a box around the actors and use cases to
represent the system boundary. This defines the scope of your system.

• Step 5: Define Relationships: If certain use cases are related or if one use case is
an extension of another, you can indicate these relationships with appropriate
notations.

• Step 6: Review and Refine: Step back and review your diagram. Ensure that it
accurately represents the interactions and relationships in your system. Refine as
needed.

• Step 7: Validate: Share your use case diagram with stakeholders and gather
feedback. Ensure that it aligns with their understanding of the system’s
functionality.

Use Case Diagram example(Online Shopping System)

Let’s understand how to draw a Use Case diagram with the help of an Online Shopping
System:

• Actors:
o Customer
o Admin

• Use Cases:
o Browse Products
o Add to Cart
o Checkout
o Manage Inventory (Admin)

• Relations:

o The Customer can browse products, add to the cart, and complete
the checkout.

o The Admin can manage the inventory.

Below is the use case diagram of an Online Shopping System:
 •

What are Common Mistakes while making Use Case Diagram?

Avoiding common mistakes ensures the accuracy and effectiveness of the Use Case
Diagram.
Here are key points for each mistake:

• Adding too much detail can confuse people.

• Unclear connections lead to misunderstandings about system interactions.

• Different names for the same elements create confusion.

• Incorrectly using generalization can misrepresent relationships.

• Failing to define the system’s limits makes its scope unclear.

• Treating the diagram as static can make it outdated and inaccurate.

Best Practices for Use Case Diagram

Crafting clear and effective Use Case Diagrams is essential for conveying system
functionality and interactions. Here are some best practices to consider:

• Use Case Diagram focus on capturing the core functions of the system, avoiding
extraneous details.

• They uses a uniform naming scheme for use cases and actors throughout the
diagram to enhance clarity and prevent misunderstandings.
 They ensure uniformity in the appearance of elements such as ovals (for use cases),
stick figures (for actors), and connecting lines to create a polished presentation.

• They help in organizing use cases into coherent groups that represent distinct
modules or subsystems within the overall system.

• Use Case Diagrams adopt an iterative method, updating the diagram as the system
changes or as new information emerges.

What is the Purpose and Benefits of Use Case Diagrams?

The Use Case Diagram offers numerous benefits throughout the system development
process.
Here are some key advantages of using Use Case Diagrams:

• Use Case Diagrams offer a clear visual representation of a system’s functions and
its interactions with external users. This representation helps stakeholders,
including those without technical expertise, in grasping the system’s overall
behavior.

• They establish a shared language for articulating system requirements, ensuring

that all team members have a common understanding.

• Use Case Diagram illustrate the different ways users engage with the system,
contributing to a thorough comprehension of its functionalities.

• In the design phase, Use Case Diagrams help outline how users (actors) will
interact with the system. They support the planning of user interfaces and aid in
structuring system functionalities. For more details, visit this link:

https://www.geeksforgeeks.org/use-case-diagram/

2.1.1.9. Class Diagram

Class diagrams are a type of UML (Unified Modeling Language) diagram used in software
engineering to visually represent the structure and relationships of classes in a system.

What are class Diagrams?

Class diagrams are a type of UML (Unified Modeling Language) diagram used in software
engineering to visually represent the structure and relationships of classes within a system
i.e. used to construct and visualize object-oriented systems.
 •

In these diagrams, classes are depicted as boxes, each containing three compartments for
the class name, attributes, and methods. Lines connecting classes illustrate associations,
showing relationships such as one-to-one or one-to-many.

What is a class?

In object-oriented programming (OOP), a class is a blueprint or template for creating objects.

Objects are instances of classes, and each class defines a set of attributes (data members) and
methods (functions or procedures) that the objects created from that class will possess. The
attributes represent the characteristics or properties of the object, while the methods define
the behaviors or actions that the object can perform.

UML Class Notation

class notation is a graphical representation used to depict classes and their relationships in
object-oriented modeling.
 1. Class Name:

• The name of the class is typically written in the top compartment of the class
box and is centered and bold.

2. Attributes:

• Attributes, also known as properties or fields, represent the data members of

the class. They are listed in the second compartment of the class box and often
include the visibility (e.g., public, private) and the data type of each attribute.

3. Methods:

• Methods, also known as functions or operations, represent the behavior or

functionality of the class. They are listed in the third compartment of the class
box and include the visibility (e.g., public, private), return type, and
parameters of each method.

4. Visibility Notation:

• Visibility notations indicate the access level of attributes and methods.

Common visibility notations include:

o + for public (visible to all classes)

o - for private (visible only within the class)
o # for protected (visible to subclasses)

o ~ for package or default visibility (visible to classes in the same

package)

Parameter Directionality
In class diagrams, parameter directionality refers to the indication of the flow of information
between classes through method parameters. It helps to specify whether a parameter is an
input, an output, or both. This information is crucial for understanding how data is passed
between objects during method calls.
There are three main parameter directionality notations used in class diagrams:

• In (Input):

o An input parameter is a parameter passed from the calling object (client) to the
called object (server) during a method invocation.

o It is represented by an arrow pointing towards the receiving class (the class

that owns the method).

• Out (Output):

o An output parameter is a parameter passed from the called object (server) back
to the calling object (client) after the method execution.

o It is represented by an arrow pointing away from the receiving class.

• InOut (Input and Output):

o An InOut parameter serves as both input and output. It carries information

from the calling object to the called object and vice versa.

o It is represented by an arrow pointing towards and away from the receiving

class.

Relationships between classes

In class diagrams, relationships between classes describe how classes are connected or
interact with each other within a system.
There are several types of relationships in object-oriented modeling, each serving a specific
purpose. Here are some common types of relationships in class diagrams:

1. Association

An association represents a bi-directional relationship between two classes. It indicates that

instances of one class are connected to instances of another class. Associations are typically
depicted as a solid line connecting the classes, with optional arrows indicating the direction of
the relationship.

Let’s understand association using an example:

Let’s consider a simple system for managing a library. In this system, we have two main
entities: Book and Library. Each Library contains multiple Books, and each Book belongs
to a specific Library. This relationship between Library and Book represents an
association.

The “Library” class can be considered the source class because it contains a reference to
multiple instances of the “Book” class. The “Book” class would be considered the target class
because it belongs to a specific library.

2. Directed Association
A directed association in a UML class diagram represents a relationship between two classes
where the association has a direction, indicating that one class is associated with another in a
specific way.

• In a directed association, an arrowhead is added to the association line to indicate the

direction of the relationship. The arrow points from the class that initiates the
association to the class that is being targeted or affected by the association.
• Directed associations are used when the association has a specific flow or
directionality, such as indicating which class is responsible for initiating the
association or which class has a dependency on another.
Consider a scenario where a “Teacher” class is associated with a “Course” class in a
university system. The directed association arrow may point from the “Teacher” class to the
“Course” class, indicating that a teacher is associated with or teaches a specific course.

• The source class is the “Teacher” class. The “Teacher” class initiates the association
by teaching a specific course.
• The target class is the “Course” class. The “Course” class is affected by the
association as it is being taught by a specific teacher.

3. Aggregation

Aggregation is a specialized form of association that represents a “whole-part” relationship. It

denotes a stronger relationship where one class (the whole) contains or is composed of
another class (the part).

Aggregation is represented by a diamond shape on the side of the whole class. In this kind of
relationship, the child class can exist independently of its parent class.
Let’s understand aggregation using an example:

The company can be considered as the whole, while the employees are the parts. Employees
belong to the company, and the company can have multiple employees. However, if the company
ceases to exist, the employees can still exist independently.

4. Composition

Composition is a stronger form of aggregation, indicating a more significant ownership or

dependency relationship. In composition, the part class cannot exist independently of the
whole class. Composition is represented by a filled diamond shape on the side of the whole
class.

Let’s understand Composition using an example:

Imagine a digital contact book application. The contact book is the whole, and each contact
entry is a part. Each contact entry is fully owned and managed by the contact book. If the
contact book is deleted or destroyed, all associated contact entries are also removed.

This illustrates composition because the existence of the contact entries depends entirely on
the presence of the contact book. Without the contact book, the individual contact entries lose
their meaning and cannot exist on their own.
5. Generalization(Inheritance)

Inheritance represents an “is-a” relationship between classes, where one class (the subclass or
child) inherits the properties and behaviors of another class (the superclass or parent).
Inheritance is depicted by a solid line with a closed, hollow arrowhead pointing from the
subclass to the superclass.

In the example of bank accounts, we can use generalization to represent different types of
accounts such as current accounts, savings accounts, and credit accounts.

The Bank Account class serves as the generalized representation of all types of bank
accounts, while the subclasses (Current Account, Savings Account, Credit Account) represent
specialized versions that inherit and extend the functionality of the base class.
6. Realization (Interface Implementation)

Realization indicates that a class implements the features of an interface. It is often used in
cases where a class realizes the operations defined by an interface. Realization is depicted by
a dashed line with an open arrowhead pointing from the implementing class to the interface.

Let’s consider the scenario where a “Person” and a “Corporation” both realizing an “Owner”
interface.

• Owner Interface: This interface now includes methods such as “acquire(property)”

and “dispose(property)” to represent actions related to acquiring and disposing of
property.
• Person Class (Realization): The Person class implements the Owner interface,
providing concrete implementations for the “acquire(property)” and
“dispose(property)” methods. For instance, a person can acquire ownership of a house
or dispose of a car.
• Corporation Class (Realization): Similarly, the Corporation class also implements
the Owner interface, offering specific implementations for the “acquire(property)” and
“dispose(property)” methods. For example, a corporation can acquire ownership of

real estate properties or dispose of company vehicles.

Both the Person and Corporation classes realize the Owner interface, meaning they provide
concrete implementations for the “acquire(property)” and “dispose(property)” methods
defined in the interface.

7. Dependency Relationship
A dependency exists between two classes when one class relies on another, but the
relationship is not as strong as association or inheritance. It represents a more loosely
coupled connection between classes. Dependencies are often depicted as a dashed arrow.

Let’s consider a scenario where a Person depends on a Book.

• Person Class: Represents an individual who reads a book. The Person class depends
on the Book class to access and read the content.
• Book Class: Represents a book that contains content to be read by a person. The
Book class is independent and can exist without the Person class.
The Person class depends on the Book class because it requires access to a book to read
its content. However, the Book class does not depend on the Person class; it can exist
independently and does not rely on the Person class for its functionality.

8. Usage (Dependency) Relationship

A usage dependency relationship in a UML class diagram indicates that one class (the client)
utilizes or depends on another class (the supplier) to perform certain tasks or access certain
functionality.

The client class relies on the services provided by the supplier class but does not own or
create instances of it.
• Usage dependencies represent a form of dependency where one class depends on
another class to fulfill a specific need or requirement.
 • The client class requires access to specific features or services provided by the
supplier class.
• In UML class diagrams, usage dependencies are typically represented by a dashed
arrowed line pointing from the client class to the supplier class.
• The arrow indicates the direction of the dependency, showing that the client class
depends on the services provided by the supplier class.
Consider a scenario where a “Car” class depends on a “FuelTank” class to manage fuel
consumption.

• The “Car” class may need to access methods or attributes of the “FuelTank” class to
check the fuel level, refill fuel, or monitor fuel consumption.
• In this case, the “Car” class has a usage dependency on the “FuelTank” class because
it utilizes its services to perform certain tasks related to fuel management.

Purpose of Class Diagrams

The main purpose of using class diagrams is:

• This is the only UML that can appropriately depict various aspects of the OOPs
concept.
• Proper design and analysis of applications can be faster and efficient.

• It is the base for deployment and component diagram.

• It incorporates forward and reverse engineering.

Benefits of Class Diagrams

• Modeling Class Structure:

o Class diagrams help in modeling the structure of a system by representing

classes and their attributes, methods, and relationships.

o This provides a clear and organized view of the system’s architecture.

• Understanding Relationships:

o Class diagrams depict relationships between classes, such as associations,

aggregations, compositions, inheritance, and dependencies.

o This helps stakeholders, including developers, designers, and business

analysts, understand how different components of the system are connected. •

Communication:

o Class diagrams serve as a communication tool among team members and

stakeholders. They provide a visual and standardized representation that can
be easily understood by both technical and non-technical audiences.

• Blueprint for Implementation:

o Class diagrams serve as a blueprint for software implementation. They guide

developers in writing code by illustrating the classes, their attributes, methods,
and the relationships between them.

o This can help ensure consistency between the design and the actual
implementation.

• Code Generation:

o Some software development tools and frameworks support code generation

from class diagrams.
o Developers can generate a significant portion of the code from the visual
representation, reducing the chances of manual errors and saving development
time.

• Identifying Abstractions and Encapsulation:

 o Class diagrams encourage the identification of abstractions and the
encapsulation of data and behavior within classes.

o This supports the principles of object-oriented design, such as modularity and

information hiding.

How to draw Class Diagrams

Drawing class diagrams involves visualizing the structure of a system, including classes, their
attributes, methods, and relationships. Here are the steps to draw class diagrams:

1. Identify Classes:

• Start by identifying the classes in your system. A class represents a blueprint for
objects and should encapsulate related attributes and methods.

2. List Attributes and Methods:

• For each class, list its attributes (properties, fields) and methods (functions,
operations). Include information such as data types and visibility (public,
private, protected).

3. Identify Relationships:

• Determine the relationships between classes. Common relationships include

associations, aggregations, compositions, inheritance, and dependencies.
Understand the nature and multiplicity of these relationships.

4. Create Class Boxes:

• Draw a rectangle (class box) for each class identified. Place the class name in
the top compartment of the box. Divide the box into compartments for
attributes and methods.

5. Add Attributes and Methods:

• Inside each class box, list the attributes and methods in their respective
compartments. Use visibility notations (+ for public, – for private, # for
protected, ~ for package/default).

6. Draw Relationships:
 • Draw lines to represent relationships between classes. Use arrows to indicate
the direction of associations or dependencies. Different line types or
notations may be used for various relationships.

7. Label Relationships:

• Label the relationships with multiplicity and role names if needed. Multiplicity
indicates the number of instances involved in the relationship, and role names
clarify the role of each class in the relationship.

8. Review and Refine:

• Review your class diagram to ensure it accurately represents the system’s

structure and relationships. Refine the diagram as needed based on
feedback and requirements.

9. Use Tools for Digital Drawing:

• While you can draw class diagrams on paper, using digital tools can provide more
flexibility and ease of modification. UML modeling tools, drawing software, or
even specialized diagramming tools can be helpful.

Use cases of Class Diagrams

• System Design:

o During the system design phase, class diagrams are used to model the static
structure of a software system. They help in visualizing and organizing
classes, their attributes, methods, and relationships, providing a blueprint for
system implementation.

• Communication and Collaboration:

o Class diagrams serve as a visual communication tool between stakeholders,

including developers, designers, project managers, and clients. They facilitate
discussions about the system’s structure and design, promoting a shared
understanding among team members.

• Code Generation:
 o Some software development environments and tools support code generation
based on class diagrams. Developers can generate code skeletons, reducing
manual coding efforts and ensuring consistency between the design and
implementation.

• Testing and Test Planning:

o Testers use class diagrams to understand the relationships between classes and
plan test cases accordingly. The visual representation of class structures helps
in identifying areas that require thorough testing.

• Reverse Engineering:

o Class diagrams can be used for reverse engineering, where developers analyze
existing code to create visual representations of the software structure. This is
especially helpful when documentation is scarce or outdated.

https://www.geeksforgeeks.org/unified-modeling-language-uml-class-diagrams/

2.1.1.10. Decision tree

Decision trees are a popular and powerful tool used in various fields such as machine
learning, data mining, and statistics. They provide a clear and intuitive way to make decisions
based on data by modeling the relationships between different variables. This article is all
about what decision trees are, how they work, their advantages and disadvantages, and their
applications.

What is a Decision Tree?

A decision tree is a flowchart-like structure used to make decisions or predictions. It consists

of nodes representing decisions or tests on attributes, branches representing the outcome of
these decisions, and leaf nodes representing final outcomes or predictions.

Each internal node corresponds to a test on an attribute, each branch corresponds to the result
of the test, and each leaf node corresponds to a class label or a continuous value.

Structure of a Decision Tree

1. Root Node: Represents the entire dataset and the initial decision to be made.
 2. Internal Nodes: Represent decisions or tests on attributes. Each internal node has one
or more branches.

3. Branches: Represent the outcome of a decision or test, leading to another node.

4. Leaf Nodes: Represent the final decision or prediction. No further splits occur at these
nodes.

How Decision Trees Work?

The process of creating a decision tree involves:

1. Selecting the Best Attribute: Using a metric like Gini impurity, entropy, or information
gain, the best attribute to split the data is selected.

2. Splitting the Dataset: The dataset is split into subsets based on the selected attribute.

3. Repeating the Process: The process is repeated recursively for each subset, creating a
new internal node or leaf node until a stopping criterion is met (e.g., all instances in a
node belong to the same class or a predefined depth is reached).

Advantages of Decision Trees

• Simplicity and Interpretability: Decision trees are easy to understand and interpret.
The visual representation closely mirrors human decision-making processes.

• Versatility: Can be used for both classification and regression tasks.

• No Need for Feature Scaling: Decision trees do not require normalization or scaling
of the data.

• Handles Non-linear Relationships: Capable of capturing non-linear relationships

between features and target variables.
Disadvantages of Decision Trees

• Overfitting: Decision trees can easily overfit the training data, especially if they are
deep with many nodes.

• Instability: Small variations in the data can result in a completely different tree being
generated.
 • Bias towards Features with More Levels: Features with more levels can dominate
the tree structure.

Applications of Decision Trees

• Business Decision Making: Used in strategic planning and resource allocation.

• Healthcare: Assists in diagnosing diseases and suggesting treatment plans.

• Finance: Helps in credit scoring and risk assessment.

• Marketing: Used to segment customers and predict customer behavior.

Example of decision tree

Decision Tree Symbols

Symbols Derscription
Chance node

Terminal node

Branches
 Arrow

• Decision node: A point in the decision tree where a choice needs to be made.
Represents decisions that split the tree into branches, each representing a possible
choice.

• Chance node: A point where an outcome is uncertain. Represents different possible

outcomes of an event, often associated with probabilities.

• Terminal (or end) node: The end point of a decision path. Represents the final
outcome of a series of decisions and chance events, such as success or failure.

• Branches: Lines that connect nodes to show the flow from one decision or chance
node to the next. Represent the different paths that can be taken based on decisions
and chance events.

• Arrows: Indicate the direction of flow from one node to another. Show the
progression from decisions and chance events to outcomes.

Types of Decision Trees

Classification Trees

Classification trees are used when the target variable is categorical. The tree splits the dataset
into subsets based on the values of attributes, aiming to classify instances into classes or
categories. For example, determining whether an email is spam or not spam.
Regression Trees

Regression trees are employed when the target variable is continuous. They predict outcomes
that are real numbers or continuous values by recursively partitioning the data into smaller
subsets. For example, predicting the price of a house based on its features.

How to Make a Decision Tree in 7 Steps

Follow these steps and principles to create a robust decision tree that effectively predicts
outcomes and aids in making informed decisions based on data.

1. Define the decision objective

• Identify the goal: Clearly articulate what decision you need to make. This could be a
choice between different strategic options, such as launching a product , entering a
new market, or investing in new technology.

• Scope: Determine the boundaries of your decision. What factors and constraints are
relevant? This helps in focusing the decision-making process and avoiding
unnecessary complexity.

2. Gather relevant data

• Collect information: Gather all the necessary information related to your decision.
This might include historical data, market research, financial reports, and expert
opinions.

• Identify key factors: Determine the critical variables that will influence your
decision. These could be costs, potential revenues, risks, resource availability, or
market conditions.

3. Identify decision points and outcomes

• Decision points: Identify all the points where a decision needs to be made. Each
decision point should represent a clear choice between different actions.

• Possible outcomes: List all potential outcomes or actions for each decision point.
Consider both positive and negative outcomes, as well as their probabilities and
impacts.

4. Structure the decision tree

• Root node: Start with the main decision or question at the root of your tree. This
represents the initial decision point.

• Branches: Draw branches from the root to represent each possible decision or action.
Each branch leads to a node, which represents subsequent decisions or outcomes.
 • Nodes: At the end of each branch, add nodes that represent the next decision point or
the final outcome. Continue branching out until all possible decisions and outcomes
are covered.

5. Assign probabilities and values

• Probability of outcomes: Assign probabilities to each outcome based on data or

expert judgment. This step is crucial for evaluating the likelihood of different
scenarios.

• Impact assessment: Evaluate the impact or value of each outcome. This might
involve estimating potential costs, revenues, or other metrics relevant to your
decision.

6. Calculate expected values

• Expected value calculation: For each decision path, calculate the expected value by
multiplying the probability of each outcome by its impact, and summing these values.

o Example: For a decision to launch a product, you might have a 60% chance of
success with an impact of $500,000, and a 40% chance of failure with an impact
of -$200,000.

o Expected value: (0.6 * $500,000) + (0.4 * -$200,000) = $300,000 - $80,000 =

$220,000

• Compare paths: Compare the expected values of different decision paths to identify
the most favorable option.

7. Optimize and prune the tree

• Prune irrelevant branches: Remove branches that do not significantly impact the
decision. This helps in simplifying the decision tree and focusing on the most critical
factors.

• Simplify the tree: Aim to make the decision tree as straightforward as possible while
retaining all necessary information. A simpler tree is easier to understand and use.

Decision Tree Best Practices

Follow these best practices to develop and deploy decision trees that are reliable and effective
tools for making informed decisions across various domains.
1. Define clear objectives: Clearly articulate the decision you need to make and its
scope. This helps in focusing the analysis and ensuring the decision tree addresses
the right questions.

2. Gather quality data: Gather relevant and accurate data that will be used to build
and validate the decision tree. Ensure the data is representative and covers all
necessary factors influencing the decision.

3. Keep it simple: Aim for simplicity in the decision tree structure. Avoid unnecessary
complexity that can confuse users or obscure key decision points.

4. Understand and involve stakeholders: Involve stakeholders who will be impacted

by or involved in the decision-making process. Ensure they understand the decision
tree’s construction and can provide input on relevant factors and outcomes.

5. Validate and verify: Validate the data used to build the decision tree to ensure its
accuracy and reliability. Use techniques such as cross-validation or sensitivity
analysis to verify the robustness of the tree.

6. Interpretability: Use clear and intuitive visual representations of the decision tree.
This aids in understanding how decisions are made and allows stakeholders to follow
the logic easily.

7. Consider uncertainty and risks: Incorporate probabilities of outcomes and consider

uncertainties in data or assumptions. This helps in making informed decisions that
account for potential risks and variability.

How Can a Decision Tree Help with Decision Making?

A decision tree simplifies the decision-making process in several key ways:

1. Visual clarity: It presents decisions and their possible outcomes in a clear, visual
format, making complex choices easier to understand at a glance.

2. Structured approach: By breaking down decisions into a step-by-step sequence, it

guides you through the decision-making process, ensuring that all factors are
considered.
 3. Risk assessment: It incorporates probabilities and potential impacts of different
outcomes, helping you evaluate risks and benefits systematically.
4. Comparative analysis: Decision trees allow you to compare different choices side by
side, making it easier to see which option offers the best expected value or outcome.

5. Informed decisions: By organizing information logically, decision trees help you

make decisions based on data and clear reasoning rather than intuition or guesswork.

6. Flexibility: They can be easily updated with new information or adjusted to reflect
changing circumstances, keeping the decision-making process dynamic and relevant.

Advantages and Disadvantages of a Decision Tree

Understanding these advantages and disadvantages helps in determining when to use decision
trees and how to mitigate their limitations for effective machine learning applications.

Advantages Disadvantages

Easy to interpret and visualize. Can overfit complex datasets without proper
pruning.

Can handle both numerical and categorical Small changes in data can lead to different
data without requiring data normalization. tree structures.

Captures non-linear relationships between Tends to favor dominant classes in

features and target variables effectively. imbalanced datasets.

Automatically selects significant variables May struggle with complex

and feature interactions. interdependencies between variables.

Applicable to both classification and Can become memory-intensive with large

regression tasks across various domains. datasets.

https://creately.com/guides/decision-tree-guide/

https://www.geeksforgeeks.org/decision-tree/
2.2. Identification of Hardware and software technology
2.2.1. Computer Hardware
In order to use EdrawMax, you will need to have a minimum of:
 • 1GB of memory (RAM), 4 GB recommended
• 5GB of free hard disk space for application files
• Internet connection for product activation and Live Updates
• Laptop or Monitor, mouse, and keyboard
2.2.2. System software
• Windows 7 and above; macOS v10.13 to macOS v13; Work on Apple M1.M2;
and Linux.
2.2.3. Application Software
2.2.3.1. Microsoft Office
Microsoft Office is a suite of applications designed to help with productivity and
completing common tasks on a computer. You can create and edit documents
containing text and images, work with data in spreadsheets and databases, and create
presentations and posters.
2.2.3.2. Visual paradigm
Visual Paradigm is a software application designed for software development teams to
model business information systems and manage development processes. In addition
to modeling support, this technology provides report generation and code engineering
capabilities including code generation. You can download it from here:
https://www.visual-paradigm.com/download/
2.2.3.3.E-Drawmax
EdrawMax Pro is an all-in-one diagram application that allows you to create flow
charts, mind maps, org charts, network diagrams and floor plans with a rich gallery of
examples and templates. EdrawMax enables students, teachers and business
professionals to reliably create and publish many kinds of diagrams to represent any
ideas. It's an all-in-one graphics software that makes it simple to create professional
looking flowcharts, network diagrams, organizational charts, business presentations,
building plans, mind maps, fashion designs, UML diagrams, workflows, program
structures, web design diagrams, electrical engineering diagrams, directional maps,
database diagrams and more. You can download it from this link:
https://www.edrawmax.com/
2.3. Application of SSADM (Structured System Analysis and Design Methods)
2.3.1. Objective of SSADM (Structured Systems Analysis and Design Methodology)
Definition of SSADM
 Structured systems analysis and design method (SSAADM) refers to a methodology
to control and guide the process of system development in the information systems
industry. Developed in the early 1980s for the British government, SSADM became
the standard methodology for all public sector information system procurements.
Benefits of SSADM
• Timelines: Theoretically, SSADM allows one to plan, manage and control a
project well. These points are essential to deliver the product on time.
• Usability: Within SSADM special emphasis is put on the analysis of user
needs. Simultaneously, the systems model is developed and a comprehensive
demand analysis is carried out. Both are tried to see if they are well suited to
each other.6
• Respond to changes in the business environment: As in SSADM
documentation of the project’s progress is taken very seriously, issues like
business objectives and business needs are considered while the project is
being developed. This offers the possibility to tailor the planning of the project
to the actual requirements of the business.
• Effective use of skills: SSADM does not require very special skills and can
easily be taught to the staff. Normally, common modelling and diagramming
tools are used. Commercial CASE tools are also offered in order to be able to
set up SSADM easily.
• Better quality: SSADM reduces the error rate of IS by defining a certain
quality level in the beginning and constantly checking the system.
• Improvement of productivity: By encouraging on-time delivery, meeting
business requirements, ensuring better quality, using human resources
effectively as well as trying to avoid bureaucracy, SSADM improves the
overall productivity of the specific project and the company.
• Cuts costs: SSADM separates the logical and the physical systems design. So
the system does not have to be implemented again with new hard -or software.
https://www.grin.com/document/106034
2.3.2. SSADM Techniques
2.3.2.1. Logical Data modeling
Within this process the data requirements of an IS are investigated, identified,
modelled and documented. The logical data structure (LDS) is formed. It gives
information on the entities that need to be put down and on the relationships between
 these entities.13 Logical Data Modelling is mainly carried out in the first two stages
of the SSADM development. So, for the feasibility stage, a higher Data Flow
Diagram (DFD) and an Entity Relation Diagram are normally produced.
2.3.2.2. Data flow Modeling
While Data Flow Modelling focuses on IS requirements, Data Flow Modelling deals
with identifying, modelling and documenting how data flows around and within an
IS. Again a comprehensive DFD is produced.
This DFD shows the connection between various processes within the IS. The
transformation of the processes, however, are more likely to be represented in a
distinct description of processes. Furthermore, the DFD shows the data stores, which
could be directories, folders, servers and the way they are accessed. A description of
the external entities (persons or companies that do not belong to the systems but are
relevant to it) should be included, too. Finally, data flows between processes, data
stores and external entities are also represented.
2.3.2.3. Entity Behavior modeling
The process of Entity Event Modelling deals with the business events that have an
impact on each entity and its surrounding. This information is put down in a so called
Entity Life Histories file.
Finally, for each process, data flow, data store and external entity there is an entry in
the so called data dictionary. This data dictionary is the central catalogue of data
within an IS. It shows the structure, storage, connections, origin and use of data. The
data dictionary aims to give the possibility of describing the elementary data in an
appropriate verbal way.
2.3.3. Implementation of stages for drawing SSADM
Stage 0: Feasibility study
Investigation of economical and technical feasibility. The problems are defined and
the project identified. The best business option is chosen out of up to 5 propositions.
In SSADM the feasibility stage is not imperative.
Stage 1: Investigation of the current environment
Definition of broad requirements, investigation of current data and processing. The
project is being identified and costs calculated. This stage is especially important as
any omissions will have a bad effect on the whole project.1
Stage 2: Business Systems Options
 Formulation of business systems requirements. Evaluation of the implication and
benefit of each proposed option. Stage 3: Requirements specification
Identification of functional and non-functional requirements in detail. Proposal of new
methods and techniques in order to describe processing and data structures.
Produce a logical design of the proposed systems.
Stage 4: Technical systems options:
Definition and selection Maintenance of specific technical options, such as different
methods of implementation.
Stage 5: Logical design:
May be simultaneously to stage 4. User dialogues, update processes, enquiry
processes are defined and selected. Stage 6: Physical design:
After producing a physical design, creating a function and data design, the SSADM
cycle is completed and the applications are ready for delivery.
https://www.grin.com/document/106034
2.4. Application of Object-Oriented Analysis and Design (tutorialspoint, n.d.)
2.4.1. Introduction

Object-Oriented Analysis and Design (OOAD) is a way to design software by thinking of

everything as objects similar to real-life things. In OOAD, we first understand what the
system needs to do, then identify key objects, and finally decide how these objects will work
together. This approach helps make software easier to manage, reuse, and grow. It is a
software engineering paradigm that integrates two distinct but closely related processes:
Object- Oriented Analysis (OOA) and Object-Oriented Design (OOD).
Important Aspects of OOAD

• Object-Oriented Programming: In this the real-world items are

represented/mapped as software objects with attributes and methods that relate
to their actions.
• Design Patterns: Design patterns are used by OOAD to help developers in
building software systems that are more efficient and maintainable.
• UML Diagrams: UML diagrams are used in OOAD to represent the different
components and interactions of a software system.
• Use Cases: OOAD uses use cases to help developers understand the
requirements of a system and to design software systems that meet those
requirements.
Terminologies of Object Oriented

Some of the terminologies that are often encountered while studying Object Oriented
Concepts include:

1. Attributes: a collection of data values that describe a class.

2. Class: encapsulates the data and procedural abstractions required to describe the
content and behavior of some real-world entity. In other words, A class is a
generalized description that describes the collection of similar objects.
3. Objects: instances of a specific class. Objects inherit a class’s attributes and
operations.
4. Operations: also called methods and services, provide a representation of one of the
behaviors of the class.
5. Subclass: specialization of the super class. A subclass can inherit both attributes and
operations from a super class.
6. Superclass: also called a base class, is a generalization of a set of classes that are
related to it.

Object-Oriented Analysis

Object-Oriented Analysis (OOA) is the process of understanding and analyzing the system
requirements by looking at the problem scenario in terms of objects.

These objects represent real-world entities or concepts that are relevant to the system being
developed.
During OOA, the goal is to identify the objects, their attributes, behaviors, and relationships,
without focusing on how the system will be implemented.

Data Organization of Attributes:

OOD involves specifying how data attributes are organized within the objects.

This includes determining the types of data each object will hold and how they relate to one
another.

Procedural Description of Operations:

OOD requires a procedural description for each operation that an object can perform.

This involves detailing the steps or processes involved in carrying out specific tasks.
Below diagram shows a design pyramid for object-oriented systems. It is having the
following four layers.

Benefits of Object-Oriented Analysis and Design(OOAD)

• It increases the modularity and maintainability of software by encouraging the

creation of tiny, reusable parts that can be combined to create more complex systems.
• It provides a high-level, abstract representation of a software system, making
understanding and maintenance easier.
• It promotes object-oriented design principles and the reuse of objects, which lowers
the amount of code that must be produced and raises the quality of the program.
• Software engineers can use the same language and method that OOAD provides to
communicate and work together more successfully in groups.
• It can assist developers in creating scalable software systems that can adapt to
changing user needs and business demands over time.

Challenges of Object-Oriented Analysis and Design(OOAD)

• Because objects and their interactions need to be carefully explained and handled, it
might complicate a software system.
• Because objects must be instantiated, managed, and interacted with, this may result in
additional overhead and reduce the software’s speed.
• For beginner software engineers, OOAD might have a challenging learning curve
since it requires a solid grasp of OOP principles and methods.
 • It can be a time-consuming process that involves significant upfront planning and
documentation. This can lead to longer development times and higher costs.
• OOAD can be more expensive than other software engineering methodologies due to
the upfront planning and documentation required.
https://www.geeksforgeeks.org/object-oriented-analysis-and-design/
2.4.2. Advantage and disadvantages

Advantages of OOAD:

1. Improved modularity: OOAD encourages the creation of small, reusable objects that
can be combined to create more complex systems, improving the modularity and
maintainability of the software.
2. Better abstraction: OOAD provides a high-level, abstract representation of a
software system, making it easier to understand and maintain.
3. Improved reuse: OOAD encourages the reuse of objects and object-oriented design
patterns, reducing the amount of code that needs to be written and improving the
quality and consistency of the software.
4. Improved communication: OOAD provides a common vocabulary and methodology
for software developers, improving communication and collaboration within teams.
5. Reusability: OOAD emphasizes the use of reusable components and design patterns,
which can save time and effort in software development by reducing the need to
create new code from scratch.
6. Scalability: OOAD can help developers design software systems that are scalable and
can handle changes in user demand and business requirements over time.
7. Maintainability: OOAD emphasizes modular design and can help developers create
software systems that are easier to maintain and update over time.
8. Flexibility: OOAD can help developers design software systems that are flexible and
can adapt to changing business requirements over time.
9. Improved software quality: OOAD emphasizes the use of encapsulation,
inheritance, and polymorphism, which can lead to software systems that are more
reliable, secure, and efficient.

Disadvantages of OOAD

1. Complexity: OOAD can add complexity to a software system, as objects and their
relationships must be carefully modeled and managed.
 2. Overhead: OOAD can result in additional overhead, as objects must be instantiated,
managed, and interacted with, which can slow down the performance of the software.
3. Steep learning curve: OOAD can have a steep learning curve for new software
developers, as it requires a strong understanding of OOP concepts and techniques.
4. Complexity: OOAD can be complex and may require significant expertise to
implement effectively. It may be difficult for novice developers to understand and
apply OOAD principles.
5. Time-consuming: OOAD can be a time-consuming process that involves significant
upfront planning and documentation. This can lead to longer development times and
higher costs.
6. Rigidity: Once a software system has been designed using OOAD, it can be difficult
to make changes without significant time and expense. This can be a disadvantage in
rapidly changing environments where new technologies or business requirements may
require frequent changes to the system.
7. Cost: OOAD can be more expensive than other software engineering methodologies
due to the upfront planning and documentation required.
2.4.3. Phases in Object-Oriented Software development
We know that the Object-Oriented Modelling (OOM) technique visualizes things in
anapplication by using models organized around objects. Any software development
approach goes through the following stages: Analysis, Design and implementation.
2.4.3.1. Analysis
In this stage, the problem is formulated, user requirements are identified, and then a
model is built based upon real–world objects. The analysis produces models on how
the desired system should function and how it must be developed. The models do not
include any implementation details so that it can be understood and examined by any
non–technical application expert.
2.4.3.2. Design
Object-oriented design includes two main stages, namely, system design and object
design.
System Design:
In this stage, the complete architecture of the desired system is designed. The system
is conceived as a set of interacting subsystems that in turn is composed of a hierarchy
of interacting objects, grouped into classes. System design is done according to both
 the system analysis model and the proposed system architecture. Here, the emphasis
is on the objects comprising the system rather than the processes in the system.
Object Design
In this phase, a design model is developed based on both the models developed in the
system analysis phase and the architecture designed in the system design phase. All
the classes required are identified. The designer decides whether:
• New classes are to be created from scratch,
• any existing classes can be used in their original form, or
• new classes should be inherited from the existing classes.
The associations between the identified classes are established and the hierarchies of
classes are identified. Besides, the developer designs the internal details of the classes
and their associations., the data structure for each attribute and the algorithms for the
operations.
2.4.3.3. Implementation
In this stage, the design model developed in the object design is translated into code in
an appropriate programming language or software tool. The databases are created and
the specific hardware requirements are ascertained. Once the code is in shape, it is
tested using specialized techniques to identify and remove the errors in the code.
Learning outcome 3: Build System Design

3.1. Development of Data Flow

3.2. Application of Physical Data Model

3.3. Documentation of system design

3.1. Development of Data Flow

3.1.1. Data Flow Diagram (DFD)

A data flow diagram (DFD) is a graphical or visual representation that uses a standardized set
of symbols and notations to describe a business's operations through data movement. They're
often elements of a formal methodology, such as Structured Systems Analysis and Design
Method (SSADM). Superficially, DFDs can resemble flow charts or Unified Modeling
Language (UML), but they aren't meant to represent details of software logic.

How are data flow diagrams used?

 • DFDs make it easy to depict the business requirements of applications by representing
the sequence of process steps and flow of information using a graphical representation
or visual representation rather than a textual description.
• When used through an entire development process, they first document the results of
business analysis.
• They then refine the representation to show how information moves through and is
changed by application flows.
• Both automated and manual processes are represented.

Elements of DFD

DFD notions and symbols vary according to the methodology model employed. Some
organizations have adopted their own conventions, though this isn't recommended.

All DFD notions represent the following:

• External entities: Information enters from or exits the system being described.
• Flows: Define the movement of information to, from and within the system being
described.
• Stores: Places where information is maintained or held, most often databases or
database tables.
• Processes: Transform information.

Notation Yourdon and Coad Gane and Sarson

External Entity

Process

Data Store

Data Flow

Rules of Drawing a DFD

 • Each process should have at least one input and an output.
• Each data store should have at least one data flow in and one data flow out.
• Data stored in a system must go through a process.
• All processes in a DFD go to another process or a data store.

Levels of DFDs

A data flow diagram can dive into progressively more detail by using levels and layers,
zeroing in on a particular piece. DFD levels are numbered 0, 1 or 2, and occasionally go to
even Level 3 or beyond. The necessary level of detail depends on the scope of what you are
trying to accomplish.

Level 0 (Context)

DFD Level 0 is also called a Context Diagram. It’s a basic overview of the whole system or
process being analyzed or modeled. It’s designed to be an at-a-glance view, showing the
system as a single high-level process, with its relationship to external entities. It should be
easily understood by a wide audience, including stakeholders, business analysts, data analysts
and developers.

DFD Level 1

DFD Level 1 provides a more detailed breakout of pieces of the Context Level Diagram. You
will highlight the main functions carried out by the system, as you break down the high-level
process of the Context Diagram into its subprocesses.
DFD Level 2 (Functional decomposition)

DFD Level 2 then goes one step deeper into parts of Level 1. It may require more text to
reach the necessary level of detail about the system’s functioning.
 https://www.lucidchart.com/pages/data-flow-diagram

✓ Develop Data flow diagram of system

Now that you know what makes up a data flow diagram, let’s see how easy it is to make one
using our powerful, online tool. We provide a ton of templates to use as a starting point. In
this how-to, we’re going to create a Level 0 DFD for an online shopping experience. Log in
to your account (if you don’t have one, sign up to try Lucidchart free for a week) and follow
the steps below to make a DFD.

1. Select a data flow diagram template

In the Documents section, click on the orange +Document button and double-click on the
Blank ERD & Data Flow diagram.
2. Name the data flow diagram

Click on the Blank ERD & Data Flow header in the top left corner of the screen. A pop-up
screen opens, type the name of your diagram in the text box and click OK. The name of your
DFD appears in the top left corner of the screen.
3. Add an external entity that starts the process

In the left column of the screen, you’ll notice a lot of shapes and symbols. We’ve already
created the four symbols you’ll need to make a DFD. You can also add images to the diagram.
Scroll through the list of symbols until you get to the bottom and see the heading Data Flow.

These are all the DFD symbols you need. (Note: Mouse over each shape to see what they
represent: process, data stores, data flow, and external entities). We have symbols for Yourdon
and Coad, Yourdon and DeMarco, and Gane and Sarson methods. Click and hold External
Entity and drag it onto the workspace.

Click the highlighted text in the box and type the name of the external entity. For our
example, we’re typing “customer.”
You can use the curved arrow in the top left corner of the square to rotate the symbol. Delete
a symbol by clicking it and pressing delete on your keyboard.

4. Add a Process to the DFD

Click and hold on a process symbol and drag it to where you want it on the workspace. Type
the name of the process. We’re calling this process “add product to cart.”

5. Add a data store to the diagram

Click and hold on a data store symbol and drag it to where you want it on the workspace.
Type the data store name. We’re naming ours “shopping cart.”

6. Continue to add items to the DFD

Drag-and-drop the appropriate symbols to add all the external entities, processes, and data
stores to your diagram.
Move symbols around by clicking and holding on them, and then drag them to a new
location. Click on a symbol to resize it, then click and hold the blue box in one of the corners
and drag the corner to make the shape bigger or smaller. Use the background graph as a guide
for alignment and sizing.

7. Add data flow to the DFD

Double-click on an entity, process, or data store, and then click and hold one of the orange
circles and drag the line to the appropriate symbol.
Tip:

If you prefer to create the data flow process as you complete the diagram, click on an entity,
process, or data store and then click and hold one of the orange circles and drag the line to
draw an arrow. Release the mouse button and a box with DFD symbols will appear. Click on
the shape you want to add and it will automatically be created.

8. Name the data flow

Add a name to describe the data flow by double-clicking on the arrow line. An option to type
text will appear, type the data flow name.

9. Customize the DFD with colors and fonts

Once you have the basic design of your diagram, you can add colors to symbols, change
fonts, and adjust arrows. Here’s how to:

• Add colors to symbols: Click on a symbol on the diagram and then click the color-fill
icon and choose a color.
Tip:

To make multiple symbols the same color, click the first item and then hold the shift key and
click the remaining shapes. Next, click the color-fill icon and choose a color.

• Change the font: Choose Select All from the Edit option in the menu. Click the font
box, choose a new font, and click it. All text in the diagram will be updated. You can
use the other shortcuts (font color, size, bold, italic, underline, and alignment) to
customize the font even more.
 • Adjust arrow style: Click an arrow to select it. Next, click the arrow icon in the menu
bar and choose one of the nine other styles.

Tip:

To change the style of all the arrows, choose Select All from the Edit menu.

10. Add a title and share your data flow diagram

At the top of the symbols’ column, you’ll see a large letter T. Click it and drag it to where
you want to add a title to the diagram. Type the title, and if you’d like to, adjust the font
and type size using the shortcut keys at the top of the screen.
You can easily share your DFD with others either via email, link, social media (Facebook,
Twitter, Google+, and LinkedIn), or embed it on a website. Click the blue Share button in the
top right corner of the screen and a pop-up will appear. Choose how you’d like to share the
DFD and enter the appropriate information.
When you add a collaborator by sending a link to the DFD via email, you can work on the
data flow diagram simultaneously and use the chat feature (the yellow quote icon in the top
right corner of the screen) to have discussions.

3.2. Application of Physical Data Model

✓ Identify the database Objects

Physical database design consists of defining database objects and their relationships.

You can create the following database objects:

• Tables: Tables are logical structures maintained by the database manager and are
made up of columns and rows. Databases store persistent data in tables, but there are
also tables that are used for presenting results, summary tables and temporary tables.

• Constraints: Within any business, data must often adhere to certain restrictions or
rules. For example, an employee number must be unique. The database manager
provides constraints as a way to enforce such rules.
• Indexes: An index is a set of pointers that are logically ordered by the values of one
or more keys. The pointers can refer to rows in a table.

• Triggers: A trigger defines a set of actions that are performed in response to an insert,
update, or delete operation on a specified table. When such an SQL operation is
executed, the trigger is said to have been activated. Triggers are optional and are
defined using the CREATE TRIGGER statement.

• Sequences: A sequence is a database object that allows the automatic generation of

values, such as cheque numbers. Sequences are ideally suited to the task of generating
unique key values. Applications can use sequences to avoid possible concurrency and
performance problems resulting from column values used to track numbers. The
advantage that sequences have over numbers created outside the database is that the
database server keeps track of the numbers generated. A crash and restart will not
cause duplicate numbers from being generated.

• Views: A view is an efficient way of representing data without the need to maintain it.
A view is not an actual table and requires no permanent storage. A "virtual table" is
created and used.

• Cursor: A cursor is used in an application program to select a set of rows and then
process that returned data one row at a time. When a SELECT statement in an
embedded SQL application returns multiple rows of data, you need a mechanism that
makes this returned data or result set available to your application program, one row
after another.

• Member subsets overview: A member subset is a database object that expresses a

relationship between a database alias and a server list.

• Usage lists: A usage list is a database object that records each DML statement section
that references a particular table or index. A section is the executable form of the
query. Statistics are captured for each statement section as it executes. Use usage lists
when you want to determine which DML statements, if any, affected a table or index.

• Synonym: This database object is used to create an index in database. It simplifies

access to objects by creating a synonym (another name for an object). With synonyms,
you can ease referring to a table owned by another user and shorten lengthy object
names.
 To refer to a table owned by another user, you need to prefix the table name with the
name of the user who created it followed by a period. Creating a synonym eliminates
the need to qualify the object name with the schema and provides you with an
alternative name for a table, view, sequence, procedure, or other objects.

https://www.ibm.com/docs/en/db2/10.5?topic=concepts-database-objects

https://www.geeksforgeeks.org/database-objects-in-dbms/

✓ Design Database

Database design is the organization of data according to a database model. The designer
determines what data must be stored and how the data elements interrelate.

A good database design is, therefore, one that:

▪ Divides your information into subject-based tables to reduce redundant data.

▪ Provides Access with the information it requires to join the information in the tables
together as needed.

▪ Helps support and ensure the accuracy and integrity of your information.

▪ Accommodates your data processing and reporting needs.

A well-structured database:

• Saves disk space by eliminating redundant data.

• Maintains data accuracy and integrity.

• Provides access to the data in useful ways.

The design process

The design process consists of the following steps:

▪ Determine the purpose of your database

This helps prepare you for the remaining steps.

▪ Find and organize the information required

Gather all of the types of information you might want to record in the database, such as
product name and order number.
▪ Divide the information into tables

Divide your information items into major entities or subjects, such as Products or Orders.
Each subject then becomes a table.

▪ Turn information items into columns

Decide what information you want to store in each table. Each item becomes a field, and is
displayed as a column in the table. For example, an Employees table might include fields
such as Last Name and Hire Date.

▪ Specify primary keys

Choose each table’s primary key. The primary key is a column that is used to uniquely
identify each row. An example might be Product ID or Order ID.

▪ Set up the table relationships

Look at each table and decide how the data in one table is related to the data in other tables.
Add fields to tables or create new tables to clarify the relationships, as necessary.

▪ Refine your design

Analyse your design for errors. Create the tables and add a few records of sample data. See if
you can get the results you want from your tables. Make adjustments to the design, as
needed.

▪ Apply the normalization rules

Apply the data normalization rules to see if your tables are structured correctly.

Make adjustments to the tables, as needed.

https://en.wikipedia.org/wiki/Database_design

How to Model Relational Database Design with ERD?

Open visual paradigm, and follow the steps described below:

1. Create a new project by selecting Project > New from the application toolbar. In the
New Project window, enter Bus Route Management as project name and click Create
Blank Project.
2. To create an ERD, select Diagram > New from the toolbar. In the New
Diagram window, select Entity Relationship Diagram and click Next. Enter Bus
Route Management as diagram name and click OK.

3. Let's start by creating the first entity Route. Select Entity in diagram toolbar and click
on the diagram to create an entity. Name the entity Route and press Enter to confirm.

4. Create columns in Route. Let's start with a primary key. Right-click on entity Route
and select New Column from popup menu.

5. Enter +id : varchar(10) and press Enter. Note that the + sign means that the column
is a primary key. Varchar is the column type and 10 is the length.

6. Enter fare : float and press Enter, then Esc to create another column.

7. Create entity Stop. A bus route has many bus stops, while a stop can be shared by
many routes. Therefore, there is a many-to-many relationship between Route and
Stop. Place the mouse pointer over the Route entity. Drag out

the Resource Catalog icon at top right.

 8. Release the mouse button and select Many-to-Many Relationship -> Entity from
Resource Catalog.

Name the new entity Stop, You can see that a linked entity Route_Stop is
automatically created in between Route and Stop, with foreign key added.

9. Create the following columns in Stop:

Key Name Type

PK id int(10)

name varchar(255)

terminus blob

10.
The diagram should now become:
 11. A route has multiple bus schedules. Create an entity Schedule from Route with a one-
to-many relationship. Move the mouse pointer to Route. Press and drag out the
Resource Catalog icon. Select One-to-Many Relationship -> Entity to create entity
Schedule.

12. Create the following columns in Schedule:

Key Name Type

PK id int(10)

departure date

arrive date

13. A schedule is handled by a bus. Create an entity Bus from Schedule, with an one-to-
one relationship. Create the following columns in Bus:
Key Name Type

PK vehicle_id int(10)
 fleet_id varchar(10)

last_main date

14.
The diagram should become:

15. A bus is driven by a bus driver. Create entity Driver from Bus with a one-to-one
relationship. Add the following columns to Driver:

Key Name Type

PK id int(10)

name varchar(255)

employ_date date

16.
This is the final ERD.
3.3. Documentation of system design

✓ Types of documentation of system design

1. System Design document (SDD)

A software design document is created at the beginning of your project. This document
includes all the specifications of the software you want to build. You might also call it a
technical specification document. Whatever you call it, this document contains information
combining the purpose of your new software and your plan for how you will build it. This
includes your timeline and goals.

Key Components of a Software Design Document

A software product is a highly interconnected system with many dependent parts. So, when
you create your software design document, you need to include the following integral
elements in your documentation. This will ensure that it’s complete.
Introduction and Stakeholders

Introduce your new software project and list exactly who will be involved in your team.
Undoubtedly, your team will be cross-functional, and you can designate who will be
responsible for which aspects of software development. Then, team members know who they
can approach with any questions.
System Overview

Describe how the software system works and how you intend it to function. Connect this with
your ultimate aims and the benefits for your users. Include the particular specifications of the
system that you know you will need.

Scope and Context

Consider the scope and context of your software, which relates to the overall aims of your
business. It includes how the software fits into your business’s strategy and why this project
is necessary. You’re filling out the “why” of your team’s decision to embark on the project.

Architectural Design

Being explicit about the proposed architectural design of your software is essential for teams
that want to build working software. You may be able to cobble something together without a
plan, but it won’t be as good if you don’t create this blueprint for your system. Software
architecture documentation is essential for functioning systems.

Detailed Design

Include a section on a detailed design of your software so you can delve into a more detailed
discussion of your system architecture. You will need to discuss your components and maybe
even subcomponents.

User Interface Design

Many software products have a user interface. You’ll need to include instructions and
wireframes for your proposed UI. These will contribute to your overall user experience (UX).
Planning out how users will move through the interface, discover features, and unlock value
is crucial.
Error Handling and Recovery

Include instructions for how the system should handle errors and recover data in the event of
an incident. Your document will tell you how to design the system in the most effective way.
This will help you avoid errors and risk corrupting the system due to bad coding.

Dependencies

Part of the design process is taking into account dependencies. Include these in the SDD so
you can design a system that avoids breaking other components. This avoids system crashes
later on and removes the need to face difficult decisions about which features to keep. Don’t
slip into dependency hell.

https://document360.com/blog/software-design-document/

2. Functional Specification Document (FSD)

Functional Specification Document (FSD) is a comprehensive blueprint that outlines the

functional requirements of a software system or product. It serves as a bridge between the
client’s expectations and the development team’s execution strategy. Think of it as a detailed
roadmap that delineates what the system should accomplish and how it should function.

Components of a Functional Specification Document

1. Introduction: Provides an overview of the project, its objectives, and the stakeholders
involved.

2. Scope: Defines the boundaries of the project and lists the features and functionalities
to be included.

3. Functional Requirements: Details the specific functions the software must perform
to meet the user’s needs.

4. User Interface (UI) Design: Describes the layout, structure, and interactions within
the user interface.

5. Data Requirements: Specifies the data inputs, outputs, storage, and processing
requirements.

6. System Architecture: Outlines the high-level structure of the system, including

components and their interactions.
7. Dependencies: Identifies any external systems, libraries, or services that the project
relies on.

8. Testing Criteria: Sets the criteria for acceptance testing to ensure that the system
meets the specified requirements.

https://essentialdata.com/what-is-a-functional-specification-document-fsd/

3. Technical Specification Document (TSD)

A technical specification document is a technical design document, software design
document, or engineering design document is a detailed plan that outlines a software
development project’s requirements, objectives, and constraints. It serves as a roadmap that
guides the team in building the product, ensuring everyone is on the same page and working
towards a common goal.

The technical specification document typically includes:

• Functional and non-functional requirements of the software

• Scope of the project

• Timeline

• Internal standards

• Impact

• Work involved

• Budget

It may also include diagrams, mockups, and other visual aids to help the team understand the
project’s scope and details.

Technical Specification vs. Functional Specification

A functional specification outlines the software’s features and functionality from a user’s
perspective. In contrast, a technical specification focuses on the technical details such as
hardware and software requirements, data architecture, and programming languages used.

In other words, the functional specification answers the “what” of the software, while the
technical specification answers the “how.”
Both documents are essential for a successful software development project, and they should
be written with care to ensure everyone on the team understands the project’s objectives and
requirements.

Types of Technical Specification Document

IT Technical Specification
IT technical specification addresses technical projects, IT infrastructure issues, and system
updates for the IT team. This document type is commonly used in IT infrastructure projects,
such as server upgrades, network installations, and software implementations.

Some details in an IT technical specification document include hardware and software

specifications, network requirements, security protocols, and data migration strategies.

Website Technical Specification

The website technical specification outlines the technical requirements for developing a
website. It covers aspects such as design, functionality, and user experience. It describes the
website architecture, design elements, functionality, content management system, and third-
party integrations providing a clear roadmap for the project team.

Software Technical Specification

This gives clarity to any software development project. It describes the software application’s
technical requirements, including the software architecture, programming languages,
database schema, and user interface design.

In addition, it should describe any external systems or services that the software application
will interact with and how it will integrate with them. It should also outline the software
development process, including coding standards, testing metrics and requirements, and
version control procedures

Agile Technical Specification

This flexible and adaptable document outlines the technical requirements for each iteration or
sprint in Agile development. Unlike traditional technical specification documents, it is
created and updated incrementally throughout the software project development process. The
document is lightweight, includes a description of technical requirements, and reflects the
Agile principles of simplicity and adaptability.
It is critical to ensure the development team clearly understands technical requirements and
roles, providing a roadmap for delivering working software that meets customer needs.

Product Technical Specification

It serves as a blueprint for a product, outlining its general specifications and intended uses. It
includes a product summary, a description of features and functionality, technical
specifications, and design requirements. The document can guide the design and development
processes, make revisions based on user testing and customer input, and ensure the final
product meets user needs and expectations.

It is advisable to use tables and charts to make it clearer and more understandable for the
design and product team members.

Equipment Technical Specification

This specification provides detailed information about the technical aspects of equipment,
including manufacturing, power requirements, and safety considerations. It helps ensure the
safe and efficient operation of equipment. The document typically includes information about
equipment dimensions, materials, maintenance and repair procedures, and training or
certification requirements.

Technical Design Specification

This specification outlines the details of a product’s design and the technical requirements for
its development. It is a roadmap for engineers and developers to follow during the design and
implementation phase. The document specifies the technical attributes and requirements of
the product, including the tools, technologies, and programming languages that will be used.
It also describes the intended user experience, including the product’s features and
functionality. https://document360.com/blog/technical-specification-document/

4. Database design Document: the design work product that officially documents
the design of the databases that will be part of an application.

Objectives

The typical objectives of a database design document are to: Formally document the logical
and physical design of all application databases.

Benefits
The typical benefits of a database design document are to:

• Ensure that persistent data is correctly and efficiently stored.

• Clearly identify the documents, objects, or data that are persistent.

• Make it easier to install, configure, and maintain the databases.

• Make it easier for developers to integrate their executable software with the databases.
 • Provide a consistency check on the domain object model document.

https://www.opfro.org/Components/WorkProducts/DesignSet/DatabaseDesignDocument/Dat
abaseDesignDocument.html

5. Use case Document

The use case is made up of a set of possible sequences of interactions between systems and
users in a particular environment and related to a particular goal. The method creates a
document that describes all the steps taken by a user to complete an activity.

A use case explains how users interact with a product or system. It outlines the flow of user
inputs, establishing successful and failed paths to meeting goals. This allows product teams to
better understand what a system does, how it performs, and why errors occur. You can write
one out or diagram a use case model for visual thinkers.

Use cases vary in complexity depending on your audience or system. But across the board,
your use case should identify a few key components. The most important ones include:

• Actor: anything exhibiting behavior that interacts with a system, such as a single user,
a team, or another piece of software

• System: the product or service with defined functionality

• Goal: the purpose or objective users reach with a system’s features

Actors, systems, and goals build the foundation for a use case. When you begin tracking
system interactions, a few new elements come into play:

• Stakeholder(s): someone with a stake or interest in a system’s performance

• Primary actor: the actor who initiates a system’s function to reach a goal

• Preconditions: underlying factors required for the use case to happen

• Triggers: events that begin a use case

• Basic flows: use cases where systems work as intended to reach a goal

• Alternate flows: different outcomes based on when and how a system veers off
course

Types of use case

Use cases come in two forms: business and system.
A system use case is a detailed look at how users interact with each part of a system. It
highlights how unique inputs and contexts cause the system to reach different outcomes.
This level of detail highlights how a system’s individual functions work in any scenario.
Business use cases paint a more general picture of how a user might interact with your
business to reach their goals. Instead of focusing on technical detail, it’s a cause-and-effect
description of different inputs. For example, if you run a code debugging platform, your
business use case explains how users enter their code and receive error notices.
How to write a use case

Writing a use case sounds complex, but only requires understanding your system and its
users. You can write a use case by following these six steps:

1. Describe your system

Start by describing your system, or the product or service you and your team will build. Focus
your description on what your system does for users. In a business use case, you can keep this
background general and explain what it accomplishes. For a system use case, give an under-
the-hood description of how your product functions.

Define your system by asking:

• What form does it take: product, service, or software?

• What features does it offer?

• What goals can you accomplish with it?

• How does it meet those goals?

• What can you learn about the system from other documents like project charters?
2. Identify the actors

Actors generally refer to users and customers but can apply to any outside force that
engages with your system. Your actor needs well-defined behaviors explaining how and
why actors use your system.

Identify actors by asking:

• Are they individuals, teams, hardware, or another system?

 • Will primary and secondary actors share the same behavior?

• Will stakeholders take on the role of actors in your use case?

3. Define your actors’ goals

Use cases highlight the outcome actors want from a system. Remember to focus on your
actors’ wants over the system’s capabilities to understand why users come to your system. In
some cases, customers want to use systems for more than one objective. Listing each of these
objectives creates a more robust use case.

4. Create a scenario

In a use case, scenarios are the sequence of actions customers take when using a system and
the flow of effects from that interaction. Your basic flows cover scenarios where a system
works as intended. A user approaches the system, enters the right inputs, and your system
helps them reach their goals.

Start with these successful, basic flows to create a baseline. You can use process
mapping techniques to identify potential issues in the next flows.

5. Consider alternate flows

After writing a successful scenario, write alternate flows that lead to different outcomes.
Typically, alternate flows involve the misuse of a system that keeps actors from reaching their
goals. However, you can also note internal errors that cause a system to break down or
unintended ways systems can reach goals.

Alternate flows show how different actors use a system and succeed or fail. They give a more
nuanced view of everything your system can do to help you troubleshoot.
6. Repeat steps 2–5 to compile your use case

With enough variation of actors, goals, and scenarios, you can show how your
system functions. Compiling these flows together gives you a use case, which can
improve development and inform other documents like project status reports.

With simple systems, you can change a few elements to see every potential outcome.
However complex systems may have too many elements to see each outcome. In cases
like this, you can focus on testing the most common interactions.

Benefits of use cases

In the planning stage, use cases define your project scope, requirements, and roadmap. Teams
can also discuss the best user outcomes and design a path to them. With alternate flows, you
can also anticipate risks before they hurt a user’s experience. If that isn’t enough reason to
pen one, here are a few other benefits of use cases:

• Explains value: Use cases explain a system’s features in plain terms. So, when
pitching your plans to stakeholders, a use case makes your system easier to
understand.

• Predicts costs: A use case outlines the complexity of a system. More complexity
may come with additional features or safeguards. By learning how complex your
system is, you can estimate development costs.

• Improves planning: Without a use case, designers and developers focus on what a
system does, not how it does it. However, use cases help teams consider all the ways
to implement features and safeguards.

• Shares alternative uses: Not all alternative flows in a system lead to failed
outcomes. Mapping out different scenarios finds new solutions to old problems or
expands your understanding of what a system can accomplish.

Example of use case

End of Module