Many learners can repeat terms such as abstraction, cohesion and coupling, but cannot turn a requirement into modules or predict what should change when a rule changes. The vocabulary only starts paying off when it is attached to a real architecture, real interfaces and a scorer you can trace input by input. The central test is simple: if one marking rule changes, how many modules must change, and how easily can you verify the new result?
Software design in Software Engineering: what is being designed
Software design bridges requirements and implementation. Architectural design selects parts and relationships; data design defines representations and ownership; interface design defines inputs, outputs and failures; component design specifies logic; user-interface design specifies human interaction. UML is one representation, not the whole activity.
The ideas build on one another:
Abstraction hides detail behind
score(request).Stepwise refinement expands it into validation, lookup, calculation and storage.
Decomposition separates validation and scoring.
Modularity makes a scoring policy replaceable.
Information hiding keeps database choices behind interfaces.
Separation of concerns keeps scoring policy out of presentation and persistence.
The CS Fundamentals for Exams and Placements catalogue works through these basics alongside the other core CS subjects.
Cohesion and coupling: judge two different qualities
Cohesion asks whether a module serves one purpose. Its diagnostic weak-to-strong progression is coincidental, logical, temporal, procedural, communicational, sequential and functional. ResultUtilities, which validates, reads data, scores and sends messages, has weak mixed cohesion. A pure ScoreCalculator has strong functional cohesion.
Coupling asks how much modules know about one another. The common tight-to-loose progression is content, common, control, stamp and data coupling; message or interface-based interaction is looser still. A full CandidateRecord when only an ID is needed creates stamp coupling. candidateId = "C-104" is narrow data coupling. mode = 3 controlling another module's branch is control coupling.
A good boundary keeps related change together and unrelated change apart. A giant file is not automatically cohesive; zero coupling is impractical.
Software architecture, components and interfaces
Architecture style should fit the change. Layered design controls dependency direction; client-server separates requesters and providers; pipe-and-filter suits transformations; event-driven design separates producers and reactions but is harder to trace. Repository-based design suits a shared central data model. None wins universally.
Architecture identifies parts and communication. Component design defines what one part exposes, owns and does. A contract states preconditions, returned data, side effects and named failures. score(request) returns itemised marks plus a total or a validation error, never a partial result.
ScoreService depends on AnswerKeyPort, ScoringPolicyPort and ResultPort. Adapters keep the calculation unchanged whether data comes from PostgreSQL, a file or a test double.
Worked software design: a five-item assessment scorer
The example assessment SE-05 has five items and a maximum of 8 marks. Its key is Q1=A, Q2=C, Q3=B, Q4=D, Q5=6. Policy v1 gives correct marks [2, 2, 1, 2, 1] and wrong deductions [2/3, 2/3, 1/3, 0, 0].
Candidate C-104 submits [A, B, B, D, 6]. Q1 matches for +2; Q2 is B instead of C for -2/3; Q3 matches for +1; Q4 matches for +2; Q5 matches for +1.
The exact total is 2 - 2/3 + 1 + 2 + 1 = 6 - 2/3 = 18/3 - 2/3 = 16/3. Only the presenter rounds this to 5.33/8.00.
SubmissionController validates candidateId, assessmentId and answers; ScoreService coordinates; the key and policy ports supply data; pure ScoreCalculator produces five line items and 16/3. ResultPort stores (candidateId="C-104", assessmentId="SE-05", exactScore=16/3, policyVersion="v1"). ResultPresenter formats without altering the exact score.
Software design change test: contain a new scoring rule
Policy v2 changes only Q2's wrong deduction from 2/3 to 1/2; key and correct marks stay fixed. The total is 2 - 1/2 + 1 + 2 + 1 = 6 - 1/2 = 12/2 - 1/2 = 11/2 = 5.50. Only the policy value or strategy changes, not controller, repository or presenter.
Three acceptance tests make that boundary observable:
Test A: full response under
v1gives five lines,16/3and5.33/8.00.Test B: the same response under
v2gives11/2and5.50/8.00.Test C:
[A,B,B,D]givesANSWER_COUNT_MISMATCH, zero calculator calls and no stored result.
These tests expose mixed responsibilities. Strategy swaps policies, Repository or Port isolates persistence, and Dependency Injection supplies implementations. Use patterns only to localise change or improve testing.
UML and software design representations
Representation | Question answered |
|
|---|---|---|
Component diagram | Which parts depend on which interfaces? | Service, ports and adapters |
Class diagram | Which types and relationships exist? |
|
Sequence diagram | What happens over time? | Calls for |
Activity diagram | How do decisions and parallel steps flow? | Validation and failure |
Data-flow diagram | How does data move? | Answers, key, policy, result |
Structure chart | Which functions call one another? | Scoring subfunctions |
A class diagram does not show runtime order; a sequence diagram does not replace ownership. All views must agree on 16/3, 5.33/8.00 and v1. Function-oriented design starts from transformations; object-oriented design assigns state and behaviour to types. Both need boundaries.
Software design traps, interview prompts and the GATE boundary
Trap | What goes wrong | Better move |
|---|---|---|
God module | Every concern changes together | Keep the taught boundaries |
Global policy | Hidden common coupling | Inject a versioned policy |
Full record | Private fields leak | Pass only |
Circular dependencies | Change and tests suffer | Depend towards contracts |
Pattern-first design | Needless indirection | Require a real pressure |
Stale diagram | Values contradict behaviour | Check against tests |
Early rounding | Exact | Round in the presenter |
Catch-all failure | Bad input is unclear | Name |
Prompts may ask you to rank cohesion, identify stamp versus data coupling, choose a runtime-order diagram, explain why v2 leaves persistence unchanged, or calculate 11/2. Work through the Software Design practice set in our question bank and each of those prompts will come up more than once.
IIT Guwahati's completed-cycle GATE 2026 CS syllabus names ten sections, and Software Engineering is not among them. Treat this material as interview and university-exam ground rather than GATE revision time. GATE CS Subject Weightage: Where Hours Pay Off offers a prioritisation method; Operating Systems for GATE: Deadlocks, Scheduling, Memory covers a named subject. Check the organising institute's syllabus for your attempt.
Software design short version and the next practice step
Ask: What changes? Which module owns it? What crosses the boundary? Is the interface narrow? Can the domain rule run without a database? Which test proves the result? In SE-05, policy owns the Q2 change, the pure calculator receives key plus policy, ports hide storage, and Test B proves 11/2 = 5.50.
For v3, change only Q5's correct award from 1 to 2. Lines become [+2,-2/3,+1,+2,+2], so 2 - 2/3 + 1 + 2 + 2 = 7 - 2/3 = 21/3 - 2/3 = 19/3, displayed as 6.33/9.00. Only policy data and maximum-mark metadata change.
For placement-oriented Software Engineering basics, use CS Fundamentals for Placements by Sanchit Sir. For planning a GATE attempt around the sections that are on the syllabus, use GATE Guidance by Sanchit Sir.
