Software Engineering Unit 3: Architectural Design

Architectural Design
 Software Architectural design is concerned with understanding how a system should be
organized and designing the overall structure of that system.
 Architectural design organizes a system and defines its structure.
 Architectural design is the first stage in the software design process.
 This stage connects design with requirements.
 It identifies the main parts of the system and their relationships.
 The outcome is a model showing how the system's components communicate.

You can design software architectures at two levels of abstraction:

1. Architecture in the small is concerned with the architecture of individual programs. At this
level, we are concerned with the way that an individual program is decomposed into
components.
2. Architecture in the large is concerned with the architecture of complex enterprise systems
that include other systems, programs, and program components. These enterprise systems
are distributed over different computers, which may be owned and managed by different
companies.

 To help you understand what I mean by system architecture, consider Figure 6.1. This shows
an abstract model of the architecture for a packing robot system that shows the
components that have to be developed.
 This robotic system can pack different kinds of object.
 It uses a vision component to pick out objects on a conveyor, identify the type of object, and
select the right kind of packaging.
 The system then moves objects from the delivery conveyor to be packaged.
 It places packaged objects on another conveyor.
 The architectural model shows these components and the links between them

KLES JT BCA COLLEGE, GADAG 1|Page

Software Engineering Unit 3: Architectural Design

Architectural Design Decisions

 Architectural design is a creative process where you design a system organization that will
satisfy the functional and non-functional requirements of a system.
 During the architectural design process, system architects have to make a number of
structural decisions that profoundly affect the system and its development process.
 Based on their knowledge and experience, they have to consider the following fundamental
questions about the system:
1. Is there a generic application architecture that can act as a template for the system that
is being designed?
2. How will the system be distributed across a number of cores or processors?
3. What architectural patterns or styles might be used?
4. What will be the fundamental approach used to structure the system?
5. How will the structural components in the system be decomposed into subcomponents?
6. What strategy will be used to control the operation of the components in the system?
7. What architectural organization is best for delivering the non-functional requirements of
the system?
8. How will the architectural design be evaluated?
9. How should the architecture of the system be documented?

Relationship with Non-functional Requirements:

Software architecture, closely linked with non-functional requirements, should align with these
requirements, influencing the chosen architectural style and structure for a system.

1. Performance: If performance is a priority, design the architecture with fewer, larger

components running on the same machine to minimize communication delays. You
can also consider replication across processors for better performance.
2. Security: For security, use a layered architecture where the most sensitive data is
placed in the innermost layers. These layers should have strong security checks to
protect critical assets.
3. Safety: When safety is key, group safety-critical operations in one or a few
components. This makes it easier to validate and ensures you can quickly shut down
the system if something goes wrong.
4. Availability: To ensure high availability, include redundant components so that if
one fails, others can take over without interrupting the system. This helps keep the
system running smoothly.
5. Maintainability: For maintainability, use small, independent components that are
easy to modify. Avoid shared data structures and ensure producers and consumers
of data are separate, making updates simpler.

KLES JT BCA COLLEGE, GADAG 2|Page

Software Engineering Unit 3: Architectural Design

Architectural Views
 Architectural models of a software system can be used to focus discussion about the
software requirements or design.
 They may be used to document a design so that it can be used as a basis for more detailed
design and implementation, and for the future evolution of the system.
 In this section, Two issues that are relevant to both of these:
1. What views or perspectives are useful when designing and documenting a system’s
architecture?
2. What notations should be used for describing architectural models?

 It is impossible to represent all relevant information about a system’s architecture in a single

architectural model, as each model only shows one view or perspective of the system.
 4+1 view model, proposing four fundamental architectural views related through use cases
or scenarios.

1. Logical view: This view focuses on the main objects or classes in the system. It helps
to connect system requirements with the key components of the system.

2. Process view: This view shows how the system runs in real-time, with processes
interacting. It helps assess performance and availability by looking at system behavior
during execution.

3. Development view: This view shows how the software is divided for development,
detailing the components worked on by individual developers or teams. It’s helpful for
software managers and developers.

4. Physical view: This view shows the hardware and how software components are
distributed across different machines. It’s important for planning how the system will be
deployed in real-world environments.

5. +1: Scenarios: Use cases or scenarios that show how the system behaves in real-life
situations (like how users interact with it).

Why it’s useful: Ties all the views together by showing how the system works in
practice, ensuring that each view meets user needs.

Summary:
In simple terms, the 4+1 View Model suggests that we need different "views" to understand
different aspects of a system:

 Logical View: What are the core objects or classes in the system?
 Process View: How does the system work when it’s running?
 Development View: How is the system broken down for development?
 Physical View: How is the system deployed across hardware?
 Scenarios: How does the system behave in real-life situations?

Each view shows a different side of the system, and together, they give a full understanding of how
the system works, is built, and will be deployed.

KLES JT BCA COLLEGE, GADAG 3|Page

Software Engineering Unit 3: Architectural Design

Architectural Patterns
 Software architecture is like the blueprint for building software, showing how different
parts fit together and interact.
 It helps the development team understand how to build the software according to
customer requirements. There are many ways to organize these parts.
 These patterns have been tested and proven to solve different problems by arranging
components in specific ways.
 Each pattern also highlights its advantages (what it does well) and its limitations (where it
might not be the best choice).
 For example, Figure 6.2 describes the well-known Model-View-Controller pattern, this
pattern is the basis of interaction management in many web-based systems.

MVC (Model-View-Controller)
 The MVC design pattern is a software architecture pattern that separates an application
into three main components: Model (which handles data), the View (which is what users
see), and the Controller (which connects the two) making it easier to manage and maintain
the codebase.
 It also allows for the reusability of components and promotes a more modular approach to
software development.
 This makes it easier to work on each part separately, so you can update or fix things
without messing up the whole app.
 It helps developers add new features smoothly, makes testing simpler, and allows for
better user I nterfaces.
 Overall, MVC helps keep everything organized and improves the quality of the software.

 The Model component manages the system data and associated operations on that data.
 The View component defines and manages how the data is presented to the user
 The Controller component manages user interaction (e.g., key presses, mouse clicks, etc.)
and passes these interactions to the View and the Model.

KLES JT BCA COLLEGE, GADAG 4|Page

Software Engineering Unit 3: Architectural Design

Figure 6.2 The model view-controller (MVC) pattern

KLES JT BCA COLLEGE, GADAG 5|Page

Software Engineering Unit 3: Architectural Design

Layered Architecture

 Layered Architecture is a design pattern used to structure software systems by dividing

them into layers, where each layer only depends on the layer directly below it and each
layer focuses on a specific function.
 If one layer changes (e.g., replacing a database system), only the layer directly above it is
impacted.
 The system is organized into multiple layers, each with a distinct function:
 Layer 1: System Infrastructure (Databases, Operating System Services): This layer
manages system resources, including databases and operating systems. It handles
data storage and hardware interaction.
 Layer 2: Application Logic (Business Rules and Processes): This layer processes the
core business logic and rules. It controls how data is handled and how operations
are performed.
 Layer 3: User Interface and User Interaction Management: This layer manages user
input and interaction with the application. It handles authentication and session
management.
 Layer 4: Presentation Layer (UI the User Sees): This top layer provides the visual
interface that users interact with. It displays data and handles user commands like
clicks and inputs.
 Communication Between Layers: Each layer interacts only with the layer directly below it,
ensuring that changes in one layer don’t disrupt others.
 For example, the top layer (user interface) may call functions from the layer below it
(application layer), but it doesn’t directly interact with the bottom layer (system support).

Example of a Layered System (LIBSYS Library System):

 Layer 1: Each university's database.

 Layer 2: Application logic, such as managing which materials are available.
 Layer 3: User management (e.g., user authentication, permissions).
 Layer 4: User interface, where users can search for and access materials.

KLES JT BCA COLLEGE, GADAG 6|Page

Software Engineering Unit 3: Architectural Design

In this system, you can replace the database or modify user interface components without affecting
other parts of the system.

KLES JT BCA COLLEGE, GADAG 7|Page

Software Engineering Unit 3: Architectural Design

Repository Architecture
 The Repository Pattern is used in systems where multiple components share a common
database or data repository.
 Data is stored in a central repository (e.g., a database or version-controlled system).
 It allows different parts of the system to access and update data without needing to
communicate directly with each other.
 In systems using the repository pattern, the repository acts as a centralized data storage.
Components (e.g., different tools) don’t need to pass data between each other directly.
Instead, they all interact with the repository to access or update data.
 Example: In an Integrated Development Environment (IDE), the repository could store and
track the version history of code.
 Components share data by reading from and writing to the repository, without explicitly
sending data to each other.
 This method is more efficient for systems that handle large amounts of data, as it avoids the
need for continuous data transfer.

Figure 6.8 The repository pattern

KLES JT BCA COLLEGE, GADAG 8|Page

Software Engineering Unit 3: Architectural Design

In practice, consider a version-controlled repository (like GitHub) used in a development team:

 The repository holds all the source code files.

 A Code Editor (e.g., Visual Studio Code) accesses this repository to load the current code.
 The Compiler uses the same repository to compile the code.
 The Version Control System (like Git) stores the history of code changes in the repository,
enabling developers to revert to an older version if needed.

Client–Server Architecture
 The Client–Server architecture is a way of organizing systems where services are provided
by servers and used by clients.
 A client is a program or device that requests services.
 A server is a program or system that provides services to clients.
 The major components of this model are:
1. Server: A set of servers that offer services to other components
Examples:
Print servers that offer printing services,
File servers that offer file management services,
Compile server offers programming language compilation services.
2. Clients: Programs that request services from servers
Clients run on different computers and often work simultaneously
3. Network: Connects clients and servers, allowing clients to access services

Figure 6.10 The client–server pattern

KLES JT BCA COLLEGE, GADAG 9|Page

Software Engineering Unit 3: Architectural Design

 Figure 6.11 is an example of a system that is based on the client–server model. This is a
multi-user, web-based system for providing a film and photograph library.

Real-Time Example: Streaming a Video

Let’s use a video streaming service as an example to explain client-server architecture in

action.Imagine you are using a streaming app like YouTube or Netflix. Here's how the client-server
model works:

1. Client (You) Makes a Request:

o You open the app on your device (smartphone, tablet, computer).
o You search for a video or movie you want to watch and click play.
o Your device (the client) sends a request to the video server for the specific video you
want to watch.
2. Server Responds:
o The video server receives the request and looks for the video.
o The server compresses the video to make the file smaller, reducing the time it takes
to send over the internet.
o The server then delivers the video data to your device, usually in chunks.
3. Video Streaming:
o Your device begins to receive and play the video, usually by downloading small
portions at a time.
o The server makes sure the video plays without interruption, even if your internet
speed is low, by adjusting the video quality (e.g., lower quality for slower internet
speeds).

In this example:

 You (your device) are the client.

 The video server (where the video files are stored and processed) is the server
 The internet or Wi-Fi network connects your device to the server

KLES JT BCA COLLEGE, GADAG 10 | P a g e

Software Engineering Unit 3: Architectural Design

Pipe and Filter Architecture

o Pipe and Filter is a model used to organize systems where data flows through different steps
(called filters), and each step transforms the data.
o Pipe: The pathway that the data travels through.
o Filter: Each step in the process where the data is transformed or processed.
o How it works: Data flows from one filter to the next, getting processed along the way
o Each filter performs a specific transformation on the data (e.g., changing its format or
filtering out unwanted parts).
o The filters can work sequentially (one after the other) or in parallel (at the same time).
o Data can be processed item by item or in batches (all at once).
o The name "Pipe and Filter" comes from Unix systems
o In Unix, pipes allow one process to send a stream of data to another process.
o The term filter is used because each transformation filters the data, keeping only the parts it
needs.

What is Pipe and Filter Architecture?

Think of a pipe and filter as a system where data flows from one step to another, just like water
flowing through pipes in your house. In this case, the pipe is the pathway through which the data
travels, and the filters are the steps where the data gets processed or changed.

 Pipe: A pathway where data moves from one point to the next.
 Filter: A step where the data is processed, changed, or transformed.

Figure 6.12 The pipe and filter pattern

KLES JT BCA COLLEGE, GADAG 11 | P a g e

Software Engineering Unit 3: Architectural Design

Figure 6.13 An example of the pipe and filter architecture

Imagine a billing system:

1. First, invoices are generated (this is one filter).

2. Then, payments made by customers are checked against those invoices (second filter).
3. If payments match, a receipt is sent (third filter)
4. If payments don't match within the allowed time, a reminder is sent (fourth filter)

This model is often used in batch systems where data is processed in batches. An example is
a billing system, where payments are processed in steps
In a billing system, invoices are issued, payments are reconciled, and receipts or reminders
are sent. Each of these steps can be seen as a "filter" processing the data
Example: An organization has issued invoices to customers.
Once a week, payments that have been made are reconciled with the invoices
For those invoices that have been paid, a receipt is issued.
For those invoices that have not been paid within the allowed payment time, a reminder is
issued

Disadvantages:
 Interactive Systems (like those with graphical user interfaces or real-time user
input, such as mouse clicks or menu selections) are difficult to create using the pipe
and filter mode
 Reason: These systems need to react to events and handle complex data formats,
which doesn't fit well into the streaming data flow of the pipe and filter model

KLES JT BCA COLLEGE, GADAG 12 | P a g e

Software Engineering Unit 3: Architectural Design

Don’t Write this in Exam(Only for Understanding purpose)

Each transformation must parse its input and unparse its output to the agreed form.

___________________________________________________________________________

KLES JT BCA COLLEGE, GADAG 13 | P a g e

Software Engineering Unit 3: Architectural Design

Design and Implementation

Object-oriented design using the UML
 Object-oriented design (OOD) is a way of creating software systems by focusing on objects
that interact with each other.
 These objects have two main components: data (or state) and operations (or methods) to
manipulate that data.
 Each object keeps its own data private, so it can't be directly accessed from outside.
 Object-oriented design processes involve designing object classes and the relationships
between these classes.
 These classes define the objects in the system and their interactions.
 When the design is realized as an executing program, the objects are created dynamically
from these class definitions
 Steps/Stages to Develop Object-Oriented Design:
1. Understand the System Context: Before you start designing, you need to
understand what the system is supposed to do and how it will interact with the
outside world (other systems, users, or devices).
2. Design the System Architecture: This means deciding how the overall system will be
structured, including how different objects will communicate with each other.
3. Identify the Principal Objects: Identify the key objects in the system, based on the
system’s requirements. For example, in the weather station example, the objects
might include: Weather Station: Collects data from the environment, Weather Data:
Stores the collected data, Satellite Link: Sends the data to a central system.
4. Develop Design Models: These are visual representations (like diagrams) that show
how the objects in the system will work together.
5. Specify Interfaces: This means defining what operations (or methods) each object
will provide for other objects to interact with it. For example, a "Weather Station"
object might have a method to get the current temperature.

Example: Wilderness Weather Station

Imagine designing a weather station in a remote area that collects weather data and sends it to a
central system via satellite. Here, objects could represent components like the "Weather Station"
(which collects data) or the "Satellite Link" (which sends data). These objects would work together,
each focusing on a specific part of the process. By using object-oriented design, you can ensure that
changes to one part of the system (like upgrading the satellite communication) don’t affect the rest
of the system.

In short, object-oriented design helps break down complex systems into manageable, independent
parts, making them easier to understand, modify, and maintain.

KLES JT BCA COLLEGE, GADAG 14 | P a g e

Software Engineering Unit 3: Architectural Design

System context and interactions

System context models and interaction models present complementary views of the
relationships between a system and its environment
A system context model is a structural model that demonstrates the other systems in the
environment of the system being developed.
An interaction model is a dynamic model that shows how the system interacts with its
environment as it is used.
The context model of a system may be represented using associations. Associations simply
show that there are some relationships between the entities involved in the association.

Figure 7.1, which shows a weather station interacting with three systems in its environment:
a weather information system, an on board satellite system, and a control system.
The control system is linked to multiple weather stations, while there is one satellite system
and one weather information system connected to each weather station.

A use case model is used to represent the interactions between the weather station and
these external systems in a simple, abstract way.

KLES JT BCA COLLEGE, GADAG 15 | P a g e

Software Engineering Unit 3: Architectural Design

Figure 7.2 shows The use case model for the weather station shows how it interacts with
different systems.
The weather station interacts with the weather information system to report weather data
and its hardware status.
The weather station also interacts with the control system, which can send control
commands to the station.
A stick figure is used in the UML diagram to represent both external systems (like the
weather information system or control system) and human users.
Each use case should be described in natural language to clarify how the system works and
what each interaction involves.
A standard format is used for describing these use cases, detailing what information is
exchanged, how interactions are triggered, and the sequence of actions involved.

Architectural design
 The software system's architecture is designed based on the interactions between the
system and its environment
 Major components of the system are identified, along with how they interact.

 The weather station is made up of independent subsystems that communicate through a

common infrastructure called the communication link.
 Each subsystem listens for messages on this shared infrastructure and picks up the messages
meant for them.
 This approach is a common architectural style, alongside other models like client-server.
 For example, if the communications subsystem receives a control command, such as a
shutdown command, all the subsystems receive the message and shut down correctly.
 A key benefit of this architecture is flexibility—subsystems can be easily reconfigured
because the sender doesn't need to target a specific subsystem when sending a message

KLES JT BCA COLLEGE, GADAG 16 | P a g e

Software Engineering Unit 3: Architectural Design

Object Class Identification

 There are several approaches to identifying object classes in an object-oriented system
1. Grammatical analysis: Look at the natural language description of the system.
Nouns represent objects or attributes, while verbs represent operations or actions.
2. Tangible entities: Identify real-world entities, such as things (e.g., weather
instruments), roles (e.g., manager), events (e.g., requests), or locations (e.g., offices).
3. Scenario-based analysis: Break down system use into various scenarios and analyze
them. As you do this, identify the objects, attributes, and operations needed for
each scenario.

Figure 7.6 Weather station objects

 Five object classes are shown in the diagram In Figure 7.6

 Ground Thermometer, Anemometer, and Barometer: These are application domain
objects representing physical instruments used in the weather station.
 WeatherStation and WeatherData: These objects are identified based on the system and
use case descriptions.
1. WeatherStation: Acts as the main interface between the weather station and its
environment and Manages overall interactions with external systems.
2. WeatherData: Handles the "report weather" command and Collects and
summarizes data from the instruments and sends it to the weather information
system.
3. Ground Thermometer, Anemometer, and Barometer: Represent the actual
hardware instruments in the system. These objects control the physical devices and
operate autonomously. They collect data at specified times and store it locally.
When requested, they send their data to the WeatherData object for processing.

KLES JT BCA COLLEGE, GADAG 17 | P a g e

Software Engineering Unit 3: Architectural Design

Design Models
o Design models show the objects or object classes in a system and their relationships.
o These models act as a bridge between the system requirements and the system
implementation
o Typically, two main types of design models are developed:
1. Structural models: Show the static structure of the system, including object classes
and their relationships (e.g., inheritance, uses/used-by, and composition
relationships).
2. Dynamic models: Show the dynamic interactions between system objects, such as
the sequence of service requests and the state changes triggered by these
interactions.
Figure 7.7 Sequence diagram describing data collection

o Sequence diagram (Figure 7.7) shows the sequence of interactions when an external system
requests the summarized weather data from the weather station.
o The diagram is read top to bottom, showing the flow of messages between objects.
1. SatComms object: Receives a request from the weather information system to
collect a weather report. It acknowledges the request. The stick arrowhead on the
message indicates that SatComms doesn’t wait for a response and continues with
other tasks.
2. SatComms to WeatherStation: SatComms sends a message to the WeatherStation
to create a summary of the weather data, via a satellite link. Again, the stick
arrowhead indicates SatComms doesn’t wait for a response.
3. WeatherStation to Commslink: WeatherStation sends a message to the Commslink
object to summarize the weather data. The squared arrowhead indicates that
WeatherStation waits for a reply from Commslink.

KLES JT BCA COLLEGE, GADAG 18 | P a g e

Software Engineering Unit 3: Architectural Design

4. Commslink to WeatherData: Commslink calls the summarize method in the

WeatherData object and waits for a reply.
5. WeatherData Summary: The summary of the weather data is computed and sent
back to WeatherStation through Commslink.
6. WeatherStation to SatComms: WeatherStation sends the summarized data to
SatComms to transmit it back to the weather information system via the satellite
communications system.
Concurrency:

 Both SatComms and WeatherStation may be implemented as concurrent processes,

meaning they can be suspended and resumed.
 SatComms listens for messages, decodes them, and triggers weather station operations.

KLES JT BCA COLLEGE, GADAG 19 | P a g e

Software Engineering Unit 3: Architectural Design

Interface Specification
Interface specification defines how different parts of a system communicate but doesn’t
show how things work internally.
It allows parallel design. Multiple components or subsystems can be developed at the same
time as long as they follow the same interface specification.
Once an interface is defined, developers can assume that the interface will be implemented
according to the specification, allowing for smooth integration.
In UML (Unified Modeling Language), interfaces are represented similarly to class diagrams,
but with a few differences:
1. There is no attribute section for interfaces.
2. The <<interface>> stereotype is included in the name part to indicate that it is an
interface.
Attributes (data representation) are not defined in an interface. Interfaces do not specify
how data is stored.
However, interfaces define operations (or methods) that allow objects to access or update
data.
There is not a simple 1:1 relationship between objects and interfaces.
An object can have multiple interfaces. Each interface might provide a different viewpoint
of the object's capabilities.

Figure 7.9 defines two interfaces for the WeatherStation system:

1. Reporting Interface
 Defines operation names for generating weather and status reports.
 These operations map directly to methods in the WeatherStation object (e.g.,
generateWeatherReport()).
2. Remote Control Interface
 Defines four operations for remote control of the WeatherStation.
 All operations are mapped to a single method: remoteControl()
 remoteControl() uses a command string to specify the action (e.g., "turn on",
"shut down").
 The WeatherStation object decodes the command string and performs the
corresponding action.

KLES JT BCA COLLEGE, GADAG 20 | P a g e

Software Engineering Unit 3: Architectural Design

Design Patterns
 A pattern is a description of a problem and its solution, offering a reusable solution for
common problems in different contexts.
 Describing designs using patterns allows developers to communicate and explain their design
decisions clearly.
 The Gang of Four refers to the authors of a famous book on design patterns (Gamma et al.,
1995), which describes widely-used design patterns.
 Although design patterns are mostly linked to object-oriented design, the idea of capturing
design solutions can apply to any type of software design.
 The Four Essential Elements of Design Patterns (defined by the 'Gang of Four'):
1. Name: It helps to identify and communicate the pattern easily.
2. Problem Description: Helps developers understand the situations or contexts
where the pattern is useful
3. Solution Description: Describes the parts of the design solution, their
relationships, and responsibilities.
4. Consequences: Helps designers understand the impact of applying the pattern in
a specific situation. It shows the benefits and drawbacks, helping decide whether
the pattern is suitable.

 The Observer pattern is used in situations where different presentations of an object’s state
are required.
 This pattern allows for multiple views of the same object’s state without tightly coupling the
state object to the presentation logic.
 Figure 7.11 illustrates two different graphical representations of the same data set,
demonstrating how the Observer pattern works.
 The Observer pattern is typically represented graphically, showing the object classes and
their relationships.
 Separates object display from different forms of presentation
 Utilized when different presentations of an object's state are required.

KLES JT BCA COLLEGE, GADAG 21 | P a g e

Software Engineering Unit 3: Architectural Design

Implementation issues
 Software engineering includes all of the activities involved in software development from the
initial requirements of the system through to maintenance and management of the deployed
system.
 A critical stage of this process is, of course, system implementation, where you create an
executable version of the software.
 Implementation can involve:
 Writing code in high-level or low-level programming languages.
 Adapting off-the-shelf software to fit specific needs of an organization.
 Key Aspects of Implementation:
1. Reuse:
 Most modern software is built by reusing existing components or systems. This
means that instead of writing all the code from scratch, developers use already-built
software components, libraries, or frameworks to save time and effort.
 When developing software, it’s essential to reuse as much existing code as possible
to make the process faster and more efficient.
2. Configuration Management:
 During the development process, there will be multiple versions of the software
components created
 It is about keeping track of all these versions to avoid issues. If you don’t manage
versions properly, you might accidentally use the wrong version of a component,
which can cause errors or unexpected behavior.
3. Host-Target Development:
 Production software does not usually execute on the same computer as the software
development environment.
 Rather, you develop it on one computer (the host system) and execute it on a
separate computer (the target system).
 The host and target systems are sometimes of the same type but, often they are
completely different
Summary:

 Reuse existing software as much as possible to save time.

 Use configuration management to track different versions of components.
 Develop on a host system and run on a target system if needed, especially if the
development environment is different from the production environment.

KLES JT BCA COLLEGE, GADAG 22 | P a g e

Software Engineering Unit 3: Architectural Design

Assignment Questions

2 marks
1. Define Architecture Design.
2. What is Client-Server Architecture? (Feb 2024, Exam)
3. List out the types of patterns.
4. List out the Relationship with Non-functional Requirements.
5. Define MVC
6. Define Design Patterns
7. Define Repository Architecture

5 marks
1. Explain Architecture Design Decisions
2. Explain Architecture Views
3. Explain in detail about Layered Architecture
4. Explain in details about Client-server Architecture
5. Explain in details about MVC architecture
6. Explain in detail about Object oriented design using UML or Explain the steps/stages
to Develop Object-Oriented Design (Feb 2024, Exam)
7. Explain Object Class identification

10 marks
1. Explain in detail about Pipe and Filter Architecture
2. Explain Design Models
3. Explain in detail about Repository Architecture (Feb 2024, Exam)

KLES JT BCA COLLEGE, GADAG 23 | P a g e