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