GITAM School of Technology

OOSE Based Application

Development
Unit 3 Syllabus
• System Design
• System Design: Decomposing the System
• System Design Concepts: Subsystems and Classes, Services and Subsystem
Interfaces, Coupling and Cohesion, Layers and Partitions, Architectural Styles
System Design Activities: From Objects to Subsystems, Analysis Model for a
Route Planning System, Identifying Design Goals, Identifying Subsystems
• Static Modelling:
• Package Diagrams, Composite Structures, Component Diagrams, Deployment
Diagrams, System Design Activities: Addressing Design Goals: Mapping
Subsystems to Processors and Components, Identifying and Storing Persistent
Data, Providing Access Control, Designing the Global Control Flow, Identifying
Services, Identifying Boundary Conditions, Reviewing System Design
 System Design: Decomposing the System
• Explanation:
System design involves breaking down a complex system into smaller,
manageable subsystems. This helps in understanding and organizing the
components of the system.

• Subsystems and Classes:

Subsystems are modules that perform specific functions, and classes
represent the blueprint for objects.

For example, in a banking system, a "Transaction" subsystem may have

classes like "Deposit" and "Withdrawal."
System Design: Decomposing the System
System design is decomposed into several activities, each addressing part of the
overall problem of decomposing the system:

• Identify design goals. Developers identify and prioritize the qualities of the
system that they should optimize.
• Design the initial subsystem decomposition. Developers decompose the system
into smaller parts based on the use case and analysis models. Developers use
standard architectural styles as a starting point during this activity.
• Refine the subsystem decomposition to address the design goals. The initial
decomposition usually does not satisfy all design goals. Developers refine it until
all goals are satisfied.
Introduction: A Floor Plan Example
• System design, object design, and implementation constitute the construction of
the system.
• During these three activities, developers bridge the gap between the
requirements specification, produced during requirements elicitation and
analysis, and the system that is delivered to the users.
• System design is the first step in this process and focuses on decomposing the
system into manageable parts.
• During requirements elicitation and analysis, we concentrated on the purpose
and the functionality of the system.
• During system design, we focus on the processes, data structures, and software and
hardware components necessary to implement it.
• The challenge of system design is that many conflicting criteria and constraints must
be met when decomposing the system.
EXAMPLE:

• Figure 6-1 shows three successive revisions to a floor plan for a residential house. We
set out to satisfy the following constraints:
1. This house should have two bedrooms, a study, a kitchen, and a living room area.
2. The overall distance the occupants walk every day should be minimized.
3. The use of daylight should be maximized.
• In the first version of our floor plan (at the top of Figure 6-1), we find that the dining
room is too far from the kitchen. To address this problem,

• we exchange it with bedroom 2 (see gray arrows in Figure 6-1). This also has the
advantage of moving the living room to the south wall of the house.
• In the second revision, we find that the kitchen and the stairs are too far from the
entrance door.

• To address this problem, we move the entrance door to the north wall.
This allows us to reorient bedroom 2 and move the bathroom closer to both
bedrooms. The living area is increased, and we satisfied all original constraints.
Figure 6-1 Example of floor plan design.
Three successive versions show how we
minimize walking distance and take
advantage of sunlight.
• The design of a floor plan in architecture is similar to system design in
software engineering (Table 6-1).
 An Overview of System Design

Analysis results in the requirements model described by the following

products:

• a set of nonfunctional requirements and constraints, such as maximum response time,

minimum throughput, reliability, operating system platform, and so on

• a use case model, describing the system functionality from the actors’ point of view

• an object model, describing the entities manipulated by the system

• a sequence diagram for each use case, showing the sequence of interactions among objects
participating in the use case.
System design results in the following products:

• design goals, describing the qualities of the system that developers should
optimize

• software architecture, describing the subsystem decomposition in terms of

subsystem responsibilities, dependencies among subsystems, subsystem mapping
to hardware, and major policy decisions such as control flow, access control, and
data storage

• boundary use cases, describing the system configuration, startup, shutdown, and
exception handling issues.
Figure 6-2 The activities of system design (UML activity diagram)
System Design Concepts
• A service is a set of related operations that share a common purpose. During
system design, we define the subsystems in terms of the services they provide.
Later, during object design, we define the subsystem interface in terms of the
operations it provides.
• Coupling measures the dependencies between two subsystems, whereas
cohesion measures the dependencies among classes within a subsystem. Ideal
subsystem decomposition should minimize coupling and maximize cohesion.
• Layering allows a system to be organized as a hierarchy of subsystems, each
providing higher-level services to the subsystem above it by using lower-level
services from the subsystems below it.
• Partitioning organizes subsystems as peers that mutually provide different
services to each other.
System Design Concepts
• Subsystems and Classes

• Services and Subsystem Interfaces

• Coupling and Cohesion

• Layers and Partitions

• Architectural Styles
Subsystems and Classes
• In order to reduce the complexity of the application domain, we identified smaller parts called
“classes” and organized them into packages.

• Similarly, to reduce the complexity of the solution domain, we decompose a system into simpler
parts, called “subsystems,” which are made of a number of solution domain classes.

• A subsystem is a replaceable part of the system with well-defined interfaces that encapsulates the
state and behavior of its contained classes.

• In the case of complex subsystems, we recursively apply this principle and decompose a subsystem
into simpler subsystems (see Figure 6-3).
Figure 6-3
Subsystem
decomposition
(UML class
diagram)
Figure 6-4 Subsystem decomposition for an accident management system (UML component diagram).
Subsystems are shown as UML components. Dashed arrows indicate dependencies between subsystems.vv

Figure 6-4 Subsystem decomposition for an accident management system (UML component diagram).
Subsystems are shown as UML components. Dashed arrows indicate dependencies between subsystems
Subsystems and Classes:(Example)

Library Management Application:

Subsystems: "User Management," "Book Management," "Transaction
Management."
Classes: In the "User Management" subsystem, you might have classes like
Member and Librarian.
In "Book Management," classes could include Book and Author.
 Services and Subsystem Interfaces
Definition:
Services are functionalities provided by subsystems, and subsystem interfaces define
how these services can be accessed.
Example: The "Payment Processing" subsystem provides services like
processPayment and validateCreditCard, and its interface specifies how other
subsystems can interact with these services.

Library Management Application:

• Services: "Borrow Book," "Return Book," "Search Books."
• Subsystem Interfaces: The "User Management" subsystem provides services like
validateMember and updateMemberInfo to other subsystems.
Services and Subsystem Interfaces
• A service is a set of related operations that share a common purpose.

• A subsystem providing a notification service, for example, defines operations to

send notices, look up notification channels, and subscribe and unsubscribe to a
channel. The set of operations of a subsystem that are available to other
subsystems form the subsystem interface.

• The subsystem interface includes the name of the operations, their parameters,
their types, and their return values.
• Provided and required interfaces can be depicted in UML with assembly connectors,
also called ball-and-socket connectors. The provided interface is shown as a ball
icon (also called lollipop) with its name next to it. A required interface is shown as a
socket icon. The dependency between two subsystems is shown by connecting the
corresponding ball and socket in the component diagram.
• Figure 6-5 depicts the dependencies among the FieldOfficerInterface,
DispatchterInterface and ResourceManagement subsystems.
• The FieldOfficerInterface requires the ResourceUpdateService to update the status
and location of the FieldOfficer.
• The DispatcherInterface requires the ResourceAllocationService to identify available
resources and allocating them to new Incidents.
• The ResourceManagement subsystem provides both services. Note that we use the
ball-and-socket notation when the subsystem decomposition is already fairly stable
and that our focus has shifted from the identification of subsystems to the definition
of services.
Figure 6-5 Services provided by the ResourceManagement subsystem (UML component
diagram, balland-socket notation depicting provided and required interfac
Coupling and Cohesion
• Coupling is the number of dependencies between two subsystems. If two
subsystems are loosely coupled, they are relatively independent, so modifications
to one of the subsystems will have little impact on the other.

• If two subsystems are strongly coupled, modifications to one subsystem is likely

to have impact on the other. A desirable property of a subsystem decomposition is
that subsystems are as loosely coupled as reasonable.

• This minimizes the impact that errors or future changes in one subsystem have on
other subsystems.
Coupling and Cohesion:
• Consider, for example, the emergency response system depicted in Figure 6-4 (Earlier
slide) . During system design, we decide to store all persistent data (i.e., all data that
outlive a single execution of the system) in a relational database.
• This leads to an additional subsystem called Database (Figure 6-6). Initially, we design
the interface of the database subsystem so that subsystems that need to store data simply
issue commands in the native query language of the database, such as SQL.
• For example, the IncidentManagement subsystem issues SQL queries to store and retrieve
records representing Incidents in the database.
Figure 6-6 Example of reducing the coupling of
subsystems (UML component diagram,
subsystems FieldOfficerInterface,
DispatcherInterface, and Notification omitted for
clarity).
Alternative 1 depicts a situation where all
subsystems access the database directly, making
them vulnerable to changes in the interface of
the Database subsystem.
Alternative 2 shields the database with an
additional subsystem (Storage). In this situation,
only one subsystem will need to change if there
are changes in the interface of the Database
subsystem. The assumption behind this design
change is that the Storage subsystem has a more
stable interface than the Database subsystem.
• Cohesion is the number of dependencies within a subsystem. If a subsystem
contains many objects that are related to each other and perform similar tasks, its
cohesion is high.
• If a subsystem contains a number of unrelated objects, its cohesion is low. A
desirable property of a subsystem decomposition is that it leads to subsystems
with high cohesion.
• For example, consider a decision tracking system for recording design problems,
discussions, alternative evaluations, decisions, and their implementation in terms
of tasks (Figure 6-7). DesignProblem and Option represent the exploration of the
design space: we formulate the system in terms of a number of DesignProblems
and document each Option they explore. The Criterion class represents the
qualities in which we are interested. Once we assessed the explored Options
against desirable Criteria, we implement Decisions in terms of Tasks. Tasks are
recursively decomposed into Subtasks small enough to be assigned to individual
developers. We call atomic tasks ActionItems.
Figure 6-7 Decision tracking system (UML component diagram). The DecisionSubsystem has a low cohesion: The
classes Criterion, Option, and DesignProblem have no relationships with Subtask, ActionItem, and Task
Figure 6-8 Alternative subsystem decomposition for the decision tracking system of Figure 6-7 (UML component diagram,
ball-and-socket notation). The cohesion of the RationaleSubsystem and the PlanningSubsystem is higher than the
cohesion of the original DecisionSubsystem. The RationaleSubsystem and PlanningSubsystem subsystems are also simpler.
However, we introduced an interface for realizing the relationship between Task and Decision.
Layers and Partitions
• A hierarchical decomposition of a system yields an ordered set of layers.
• A layer is a grouping of subsystems providing related services, possibly
realized using services from another layer.
• Layers are ordered in that each layer can depend only on lower level layers and
has no knowledge of the layers above it. The layer that does not depend on any
other layer is called the bottom layer, and the layer that is not used by any other is
called the top layer (Figure 6-9).
• In a closed architecture, each layer can access only the layer immediately below
it. In an open architecture, a layer can also access layers at deeper levels.
Figure 6-9 Subsystem decomposition of a system into three layers (UML object diagram, layers depicted as
packages). A subset from a layered decomposition that includes at least one subsystem from each layer is called a
vertical slice. For example, the subsystems A, B, and E constitute a vertical slice, whereas the subsystems D and
G do not
• An example of a closed architecture is the Reference Model of Open Systems
Interconnection (in short, the OSI model),

• which is composed of seven layers.

• Each layer is responsible for performing a well-defined function. In addition, each

layer provides its services by using services of the layer below (Figure 6-10).
Figure 6-10 An example of closed architecture: the OSI model
(UML component diagram). The OSI model decomposes
network services into seven layers, each responsible for a
different level of abstraction.
• Until recently, only the four bottom layers of the OSI model were well
standardized. Unix and many desktop operating systems,
• for example, provide interfaces to TCP/IP that implemented the Transport,
Network, and Datalink layers.
• The application developer still needed to fill the gap between the Transport layer
and the Application layer.
• With the growing number of distributed applications, this gap motivated the
development of middleware such as CORBA and Java RMI. CORBA and Java
RMI allow us to access remote objects transparently by sending messages to them
as messages are sent to local objects, effectively implementing the Presentation
and Session layers (see Figure 6-11).
Figure 6-11 An example of closed architecture (UML component diagram). CORBA enables the access of objects
implemented in different languages on different hosts. CORBA effectively implements the Presentation and Session layers
of the OSI stack.
Architectural Styles:
• Architectural styles in Object-Oriented Analysis and Design (OOAD) refer to the high-
level design patterns or paradigms that guide the organization and structure of
software systems.

• These styles provide a blueprint for the overall structure and communication among
components in a system.

• Several architectural styles are commonly used in OOAD.As the complexity of systems
increases, the specification of system decomposition is critical.

• A software architecture includes system decomposition, global control flow, handling

of boundary conditions, and intersubsystem communication protocols.
 Repository:
• In the repository architectural style (see
Figure 6-13), subsystems access and modify a
single data structure called the central
repository.

• Subsystems are relatively independent and

interact only through the repository.

• Control flow can be dictated either by the

central repository (e.g., triggers on the data
invoke peripheral systems) or by the subsystems
(e.g., independent flow of control and
synchronization through locks in the
repository).
Figure 6-13 Repository architectural style (UML component
diagram). Every Subsystem depends only on a central data structure
called the Repository. The Repository has no knowledge of the
other Subsystems.
Figure 6-14 An instance of the repository architectural style (UML component diagram). A
Compiler incrementally generates a ParseTree and a SymbolTable that can be used by
SourceLevelDebuggers and SyntaxEditors.
Model/View/Controller
• MVC is an architectural pattern that separates an application into
three interconnected components:

• Model (data and business logic),

• View (user interface), and
• Controller (handles user input and updates the model and view accordingly).

• Example: Graphical user interface (GUI) applications where user

interactions are separated from the underlying data and logic.
 Model/View/Controller
• In the Model/View/Controller (MVC)
architectural style (Figure 6-15),
subsystems are classified into three
different types:
• model subsystems maintain domain
knowledge,
• view subsystems display it to the user,
• and controller subsystems manage the
sequence of interactions with the user.
Client/server
• In the client/server architectural style (Figure 6-18), a subsystem, the server,
provides services to instances of other subsystems called the clients, which are
responsible for interacting with the user.
• The request for a service is usually done via a remote procedure call
mechanism or a common object broker (e.g., CORBA, Java RMI, or HTTP).
Control flow in the clients and the servers is independent except for
synchronization to manage requests or to receive results.
An information system with a central database is an example of a client/server
architectural style.
The clients are responsible for receiving inputs from the user, performing range checks,
and initiating database transactions when all necessary data are collected.
The server is then responsible for performing the transaction and guaranteeing the
integrity of the data. In this case, a client/server architectural style is a special case of
the repository architectural style in which the central data structure is managed by a
process.
Client/server systems, however, are not restricted to a single server. On the World Wide
Web, a single client can easily access data from thousands of different servers (Figure 6-
19).
Peer-to-peer
• A peer-to-peer architectural style (see Figure 6-20) is a generalization of the
client/ server architectural style in which subsystems can act both as client or
as servers, in the sense that each subsystem can request and provide services.
• The control flow within each subsystem is independent from the others except for
synchronizations on requests.
• An example of a peer-to-peer architectural style is a database that both accepts
requests from the application and notifies to the application whenever certain data
are changed (Figure 6-21).
• Peer-to-peer systems are more difficult to design than client/server systems
because they introduce the possibility of deadlocks and complicate the control
flow.
Three-tier
The three-tier architectural style organizes subsystems into three layers (Figure 6-
22):
• The interface layer includes all boundary objects that deal with the user,
including windows, forms, web pages, and so on.
• The application logic layer includes all control and entity objects, realizing the
processing, rule checking, and notification required by the application.
• The storage layer realizes the storage, retrieval, and query of persistent objects.
The three-tier architectural style was initially described in the 1970s for information
systems. The storage layer, an analog to the Repository subsystem in the repository
architectural style, can be shared by several different applications operating on the same
data. In turn, the separation between the interface layer and the application logic layer
enables the development or modification of different user interfaces for the same application
logic.
Four-tier:
• The four-tier architectural style is a three-tier architecture in which the
Interface layer is decomposed into a Presentation Client layer and a
Presentation Server layer (Figure 6-23).
• The Presentation Client layer is located on the user machines, whereas the
Presentation Server layer can be located on one or more servers.
• The four-tier architecture enables a wide range of different presentation clients in
the application, while reusing some of the presentation objects across clients.
• For example, a banking information system can include a host of different clients,
such as a Web browser interface for home users, an Automated Teller Machine,
and an application client for bank employees.
• Forms shared by all three clients can then be defined and processed in the
Presentation Server layer, thus removing redundancy across clients.
 Pipe and filter
• Filter: A filter is a component that performs a specific processing task. Filters
are designed to be independent and reusable.
• Pipe: A pipe represents the communication channel between filters. It is
responsible for transporting data from the output of one filter to the input of
another.
Example in OOAD:
• Consider a document processing system where different filters handle tasks
such as text extraction, spell checking, and document formatting.
Filters: TextExtractorFilter, SpellCheckFilter, FormatFilter.
• Pipes connect the output of TextExtractorFilter to the input of SpellCheckFilter
and the output of SpellCheckFilter to the input of FormatFilter.
• Each filter operates independently, and the overall document processing is
achieved by connecting these filters in a specific sequence.
Pipe and filter
• In the pipe and filter architectural style (Figure 6-24), subsystems process data
received from a set of inputs and send results to other subsystems via a set of
outputs.

Figure 6-24 Pipe and filter architectural style (UML class diagram). A Filter can have many inputs and outputs. A
Pipe connects one of the outputs of a Filter to one of the inputs of another Filter.
Starting Point: Analysis Model for a Route
Planning System
• Using MyTrip, a driver can plan a trip from a home computer by contacting a trip-
planning service on the Web (PlanTrip in Figure 6-26). The trip is saved for later
retrieval on the server. The trip-planning service must support more than one
driver.
• The driver then goes to the car and starts the trip, while the onboard computer gives
directions based on trip information from the planning service and her current
position indicated by an onboard GPS system (ExecuteTrip in Figure 6-27).
• We perform the analysis for the MyTrip system and obtain the model in Figure 6-28.
• In addition, during requirements elicitation, our client specified the following
nonfunctional requirements for MyTrip:
Static Modelling: Package Diagrams
• A package is used as a container to organize the elements present in the system into a
more manageable unit.
• Package: This basic building block of the Package Diagram is a Package.
• It is a container for organizing different diagram elements such as classes, interfaces, etc.
• It is represented in the Diagram in a folder-like icon with its name.

• NameSpace: It represents the package’s name in the diagram.

It generally appears on top of the package symbol which helps to uniquely identify
the package in the diagram.

• Package Merge: It is a relationship that signifies how a package can be merged or

combined.
It is represented as a direct arrow between two packages. Signifying that
the contents of one package can be merged with the contents of the other.
• Package Import: It is another relationship that shows one package’s access to
the contents of a different package. It is represented as a Dashed Arrow.

• Dependency: Dependencies are used to show that there might be some element
or package that can be dependent upon any other element or package, meaning
that changing anything of that package will result in alteration of the contents
of the other package which is dependent upon the first one.

• Element: An element can be a single unit inside of a package, it can be a class,

an interface or subsystems. This packages are connected and reside inside of
packages that hold them.

• Constraint: It is like a condition or requirement set related to a package. It is

represented by curly braces.
The above is the notation of a simple Package.
• Subsystem

The above notation is used to represent subsystem.

• Dependency

The above dashed arrow sign is used to show the dependency among two elements or two packages.

• Import
The above notation is of the Import, here it also uses a dashed
arrow line but the difference is, the word <<import>> is being
written to represent the below package or function or element
has been imported from the above package.
• Merge

This notation above denotes that the Package 1

can be merged with Package 2

• Package Relationships
Package Merge Relationship
This relationship is used to represent that the contents of a package can be merged
with the contents of another package. This implies that the source and the target
package has some elements common in them, so that they can be merged
together.
• Package Dependency Relationship
• A package can be dependant on other different packages, signifying that the
source package is somehow dependent on the target package.

• Package Import Relationship

• This relationship is used to represent that a package is importing another package
to use. It signifies that the importing package can access the public contents of
the imported package.
Package Access Relationship:
• This type of relationship signifies that there is a access relationship between two
or more packages, meaning that one package can access the contents of another
package without importing it.

The above diagram depicts the Access relationship between the

Front End and Back End services. It is much needed that a front
end service can easily access the important Back End services
to carry out any operation.
Composite Structures diagram

• A composite structure diagram is a UML structural diagram that

provides a logical overview of all or part of a software system.

• It acts as a look inside a given structured classifier, defining its

configuration classes, interfaces, packages, and the relationships
between them at a micro-level.
Basic components of a composite structure diagram
Component Diagrams
• Component diagrams range from simple and high level to detailed and complex.
Either way, you'll want to familiarize yourself with the appropriate UML symbols.
The following are shape types that you will commonly encounter when reading
and building component diagrams:
Example:
Deployment Diagrams
• UML deployment diagrams are used to depict the relationship among run-time
components and nodes.
• Components are self-contained entities that provide services to other components
or actors.
• A Web server, for example, is a component that provides services to Web
browsers. A Web browser such as Safari is a component that provides services to a
user.
• A node is a physical device or an execution environment in which components are
executed.
• A system is composed of interacting run-time components that can be distributed
among several nodes.
• Furthermore a node can contain another node, for example, a device can contain
an execution environment.
• In UML deployment diagrams, nodes are represented by boxes containing
component icons.
• Nodes can be stereotyped to denote physical devices or execution environments.
• Communication paths between nodes are represented by solid lines.
• The protocol used by two nodes to communicate can be indicated with a
stereotype on the communication path. Figure 7-2 depicts an example of a
deployment diagram with two Web browsers accessing a Web server. The Web
server in turns accesses a database server. We can see from the diagram that the
Web browsers do not directly access the database at any time.
Figure 7-2 A UML deployment diagram representing the allocation of components
to different nodes. Web browsers on PCs and Macs can access a WebServer that
provides information from a Database.
System Design Activities: Addressing
Design Goals
We describe the activities needed to ensure that subsystem decomposition addresses
all the nonfunctional requirements and can account for any constraints during the
implementation phase.
• Mapping Subsystems to Processors and Components
• Identifying and Storing Persistent Data
• Providing Access Control
• Designing the Global Control Flow
• Identifying Services
• Identifying Boundary Conditions
• Reviewing the System Design Model
Mapping Subsystems to Processors and
Components

• Subsystems: In our online bookstore system, we may have

subsystems such as inventory management, user management, order
processing, and payment processing.

• Processors and Components: Each subsystem may be mapped to

different processors or servers. For example, the inventory
management subsystem may run on one server while the user
management subsystem runs on another server.
2. Identifying and Storing Persistent Data:
• Persistent Data: Data such as user profiles, book details, order history, and
inventory quantities need to be stored persistently.
• Database Design: We'll need a database to store this data. For instance, we might
use tables like Users, Books, Orders, and Inventory in a relational database
management system (e.g., MySQL).

3. Providing Access Control:

• Access Control: Different user roles (e.g., customer, admin) should have
different levels of access to the system.
• Authentication and Authorization: Implement authentication mechanisms like
username/password .
• Define access control lists (ACLs) to manage permissions for different resources.
4. Designing the Global Control Flow:

• Global Control Flow: This involves designing the flow of control between
different subsystems and components.
• Example: When a user places an order, the system first checks the
inventory, then processes payment, updates order status, and sends a
confirmation email.

5. Identifying Services:

• Services: These are functionalities provided by the system that can be

accessed by users or other systems.
• Example Services: Search for books, add items to the cart, place an
order, update user profile, etc.
6. Identifying Boundary Conditions:
Boundary Conditions: These define the conditions under which the system operates,
including external interfaces and constraints.

Example: The system should integrate with external payment gateways for processing
payments. It should also handle peak loads during promotions or sales events.

7. Reviewing System Design:

Review Process: Conducting design reviews helps identify potential issues or

improvements in the system design before implementation.

Peer Review: Engage other team members or stakeholders to review the design
documentation, diagrams, and plans.
Real-Time Example: Online Bookstore System:
Let's consider a scenario where a user wants to purchase a book from the
online bookstore:
1.User Interaction: The user interacts with the website's frontend to search
for a book and add it to the cart.
2.Subsystem Interaction: The search request is handled by the search
subsystem, which retrieves book details from the database.
3.Access Control: The system authenticates the user and authorizes the
actions (e.g., adding items to the cart).
4.Order Processing: Once the user confirms the order, the order processing
subsystem interacts with the payment processing subsystem to complete the
transaction.
5.Persistent Data: User profiles, book details, and order history are
stored in the database.
6.Boundary Conditions: The system integrates with external payment
gateways for processing payments and handles peak loads during
promotions.
7.Review: Design documents and diagrams are reviewed by the
development team and stakeholders to ensure the system meets
requirements and addresses design goals.

By following these system design activities, we ensure that the online

bookstore system is well-structured, efficient, and meets its
functional and non-functional requirements.