CS504 Final Term Past Papers 2025
Architectural Perspectives in Software Systems
In the field of software engineering, architecture refers to
the structured arrangement of various elements within a system to meet both its
functional and non-functional demands. Perry and Wolfe provided a clear
framework for understanding software architecture through this formula:
Software Architecture = {Elements, Forms, Rationale}
This formula highlights that architecture consists of key elements that follow specific forms, all driven by a clear purpose. These components are divided into three fundamental classes for better understanding.
· Data Elements – They store
and manage information that is manipulated throughout the system.
·
Processing Elements – They
define the logic and operations performed on data.
·
Connecting Elements – They
enable communication and data exchange between different parts of the system.
Development View
The Development View focuses on the organizational layout of
system files and directories. It is primarily used by developers, configuration
managers, and project leaders to manage code maintenance, conduct testing, and
perform version control. This perspective ensures that the development team can
efficiently handle the system’s evolution and updates.
Physical View
The Physical View describes the actual physical arrangement
and deployment of the system in a real-world setting. It outlines details about
processors, sensors, and storage devices, as well as the configuration of
networks and communication tools. This view is essential for hardware and
system engineers who work on installing and integrating the system components.
It also helps them address key concerns like system performance, scalability,
reliability, and security.
Architectural Styles
Software architecture can align with common architectural styles, which offer standard templates to address design challenges. While these styles simplify architectural planning, many large-scale systems combine multiple styles to accommodate their complex requirements.
Architectural Models
Various architectural models emerge during the design phase,
each providing a unique lens on the system:
·
Static Structural Models
display the key building blocks of the system and the connections between them.
·
Dynamic Process Models –
Depict the workflows and interactions within the system.
·
Interface Models – Specify
how different sub-systems interact.
Client-Server Model
The Client-Server Model signifies a significant move away
from the old mainframe approach. In older systems, both data processing and
management occurred in a single large computer, while users interacted through
basic terminals. Modern client-server systems distribute data and processing
between powerful yet affordable machines, enhancing scalability and
performance.
Components of Client-Server Systems
A typical client-server system includes several components:
User Interaction / Presentation Layer – Manages how users
interact with the system. Application Subsystem – Implements the business logic
and application-specific processes.
Database Management Subsystem – Manages and maintains
data in a structured and efficient manner.
Middleware – Connects clients and servers by offering
communication protocols and services.
In this model, application components can exist on
either the client or server, depending on system design.
Advantages of Client-Server Architecture
The client-server setup offers many benefits:
Cost Efficiency – Cheaper hardware can be used,
reducing costs while achieving high performance.
callability – Servers can be upgraded or expanded to
meet growing demand.
Simplified Data Distribution – It becomes easier to
distribute data across different clients.
Disadvantages of Client-Server Architecture
However, some challenges exist:
Inconsistent Data Sharing – Different sub-systems may
not have compatible data structures, leading to inefficient data sharing.
Redundant Management – Each server requires its own
management, increasing overhead.
No Central Directory – Without a unified registry of
available services, locating servers can be difficult.
Thin Client Model
The Thin Client Model is often employed to modernize older
systems by integrating them into a client-server setup. In this approach, the
legacy system acts as the server, while the new graphical interface runs on the
client. While it simplifies the migration process, this approach can put
significant strain on the server and network, possibly leading to performance
bottlenecks.
Inadequate Requirement Process
As discussed earlier, having well-defined requirements is
crucial in software development. The quality of these requirements directly
affects whether a system will succeed or fail. Poorly managed requirements can
create a number of problems:
Firstly, when users aren’t sufficiently involved, the
resulting product is likely to fall short of expectations. If the needs of
different user groups (stakeholders) aren’t properly considered, some key
features might be missing, which leads to dissatisfaction.
Another common risk is the addition of new user requirements
at later stages of development, known as “requirement creep.” This causes
project timelines and budgets to exceed expectations and can lower the overall
quality of the software. The expense of including additional requirements
becomes higher the later they are added in the development process.
Business Requirements
These describe the broader goals of the organization or
customer that wants the system. They outline the key features and overall
purpose of the system without going into technical details. Usually, business
requirements are recorded in a document that sets out the project’s vision and
scope.
User Requirements
User requirements take business requirements a step further
by focusing on what the user needs to do. They’re written from the perspective
of the user, explaining the tasks the user should be able to perform. These are
detailed in a requirement definition document.
Non-Functional Requirements
Earlier, we defined software requirements as describing what
the system does and how it should work. Non-functional requirements are part of
this—they cover everything that isn’t about the system’s direct functions.
These include external interfaces, design limitations, and performance
standards the system must meet. They also cover any laws, regulations, or
standards the system needs to follow.
In summary, gathering proper requirements from the start is
essential to a project’s success and helps avoid costly changes and
dissatisfied users later on.
Conclusion
In summary, software architecture is a foundational concept
that defines how various system components interconnect and collaborate to meet
functional and operational requirements. From structured views like the
development and physical perspectives to architectural styles and models, each
aspect contributes to a comprehensive understanding of software systems. The
client-server architecture, with its distributed computing model, has
revolutionized modern software design. Despite some drawbacks, it offers a
balanced approach to performance, scalability, and cost efficiency. By
mastering these concepts, developers and engineers can create robust and
maintainable software solutions.
CS504 Final Term Past Papers 2025, cs504 final term short notes, cs504 final term preparation
0 Comments