CSS Prepare

optional · CSS study notes

🗄️ OLD — Design Concepts and Architecture (consolidated)

CSS Computer Science (Optional) — Paper-I, Section-B, Topic V. Covers three distinct syllabus items: Design Concepts, Architectural Design, and Design & Implementation — the third of these was previously a single throwaway line here and has been built out below.

Design Concepts

  • Abstraction: expose only the essential detail, hide the rest.
  • Modularity: decompose a system into independent, well-defined units.
  • Coupling: the degree of interdependence between modules — lower coupling is better (a change in one module shouldn't ripple into others).
  • Cohesion: how closely related the responsibilities within a single module are — higher cohesion is better (a module should do one thing well).
  • Information hiding (Parnas's principle): a module reveals only the interface others need, and hides its internal implementation details — the design-level ancestor of what OOP calls encapsulation.
  • Refactoring: restructuring existing code to improve its internal design (readability, cohesion, reduced coupling) without changing its external behavior. Tested directly as a standalone MCQ in 2025 — don't file this under "just an Agile/XP practice" and skip it.

Architectural Design

The high-level structural styles an exam answer should be able to name and briefly justify:

  • Layered architecture: organizes the system into layers, each only using the services of the layer directly below it (e.g. OS layers, network protocol stacks).
  • Client-server: services are provided by servers and consumed by distributed clients.
  • Pipe-and-filter: data flows through a series of independent processing components ("filters") connected by "pipes."
  • Repository style: components interact by reading/writing to a shared central data store.
  • MVC (Model-View-Controller): separates data (Model), presentation (View), and control logic (Controller) — common in interactive and web systems.

3-Tier Web Application Architecture

FPSC's single favourite instance of this topic — asked with near-identical wording across multiple sittings:

  • Presentation tier: the browser/UI — what the user directly sees and interacts with.
  • Application (logic) tier: business rules and server-side processing — sits between the UI and the data.
  • Data tier: the database and its data-access logic.

Know why this separation is valuable, not just the three names: each tier can be developed, scaled, and replaced independently (e.g. swapping the database engine without touching the UI).

🔥

Repeated in past papers — verbatim: "Explain 3-tier web application architecture" was asked in 2022 Q7(a) for 8 marks, and again in 2025 Q8(c) for 8 marks — the same question, same mark weight, three exam sittings apart. This is one of the highest-confidence "will be asked again" items on the entire syllabus. See 🔥 Most Repeated — Software Engineering.

Design & Implementation

The handoff from blueprint to working code — don't skip this just because it sounds like "just programming":

  • Translating design notation (structure charts, class diagrams, pseudocode) into actual source code in a chosen language/platform.
  • Code reuse strategies: libraries, frameworks, pre-built components, and code generators — reusing well-tested components reduces both effort and defect rates versus writing everything from scratch.
  • Implementation choices feed back into design: a chosen language, platform, or third-party component can constrain or reshape the architecture that was planned on paper (e.g. a chosen database engine ruling out a particular data-tier design).
  • Structured programming discipline: single entry/exit points, avoiding uncontrolled jumps (no goto-style logic), preferring sequence/selection/iteration constructs — the implementation-level counterpart of "modularity" above.

Software Design Strategies

How a designer chooses to decompose the system — a distinct question from which architectural style (above) the result ends up following.

  • Top-down design: start from the overall system and decompose it into progressively smaller sub-modules/functions, refining each in turn ("stepwise refinement"), until every unit is simple enough to implement directly.
  • Bottom-up design: start by building the smallest, most basic reusable components first, then combine them upward into larger subsystems and finally the complete system.
  • Function-Oriented (structured) design: decomposes the system around the functions/processes it performs — typically driven by Data Flow Diagrams, with functions calling other functions in a hierarchy. Data and the functions that operate on it are kept separate.
  • Object-Oriented design: decomposes the system around the objects/entities it manipulates — data and the operations on that data are bundled together in classes/objects. This is the direct opposite of function-oriented design on the data/function-separation question, and it's the design strategy behind the class diagrams covered under Analysis Modeling.
  • Modularization: designing so each module can be developed, tested, and maintained independently — directly guided by the coupling/cohesion principles above (low coupling between modules, high cohesion within each).

MCQ Trap

  • "Which design strategy keeps data separate from the functions that operate on it?" → function-oriented/structured design — object-oriented design is defined by doing the opposite (bundling them together).
  • A question naming "presentation / logic / data" tiers is asking about architectural design, not implementation — don't confuse the structural blueprint with the code that fills it in.