Requirements aur UI ban gaye — ab coding se pehle system ka design banana hai. Ye notes lectures (Prof. Sridhar Iyer + Prof. Prajish Prasad), slides, aur transcripts sab combine karke bane hain — saath mein 15 assignment questions answers & explanation ke saath.
Ab tak humne kya kiya tha? Requirements collect kiye, SRS banaya, user stories likhi, aur unke liye UI design kiya. Ab development shuru karne se pehle ek step aata hai — Design.
Definition (yaad rakho, exam mein aata hai): Design is a way of organising the code you will implement and providing a structure to the software system. Matlab — code likhne se pehle ye decide karna ki code kaise organise hoga, kaun se parts honge, aur wo parts aapas mein kaise baat karenge.
Design process ka output directly code nahi hota — ek intermediate representation hota hai, jiske broadly 4 outcomes hain:
Solution ke modules — functions ka collection + un functions ka shared data. Har module ek well-defined task accomplish karta hai, aur sab milke pura system chalate hain. E.g. Amazon Seller Portal mein: catalogue management, inventory management, payment tracking.
Modules aapas mein kaise communicate karte hain — data exchange ka tarika. Sender aur receiver dono ko pata hona chahiye ki exchanged data ko kaise interpret karna hai.
Har component ke andar data kaise store hoga — arrays, lists, trees, hash tables etc. E.g. fast search + insert ke liye hash table choose karna = data structure decision.
Data pe kaun sa logic chalega jisse desired result mile. Data structure pe run hone wala procedure.
Seller Portal example ka flow: User stories (view inventory, track customer feedback…) → common functionalities identify karo → group karke tasks banao (project management week wala concept) → yehi tasks system ke components ban jaate hain.
Maan lo tumne components aur interfaces bana liye — ab kaise pata ye design achha hai? Lecture mein 4 characteristics diye gaye:
| Characteristic | Matlab kya? | Kaise ensure / example |
|---|---|---|
| Correctness | Kya design system ki functionality sahi implement karta hai? | Requirements sahi capture karo — unambiguous, non-conflicting, complete. Tabhi saari functionality design mein aayegi. |
| Efficiency | Resources (time, space/memory, cost) well-managed hain? | Framework selection application ke hisaab se — e.g. embedded system ko limited memory mein chalna hota hai; mission-critical vs client-server ka choice. |
| Maintainability | Code ko change karna easy hai? (bina scratch se redesign kiye) | Requirements change hote rehte hain — release ke baad bhi. New requests, upgrades — existing design/code mein without too much effort changes ho paayein. |
| Understandability | Puri team design ko follow kar paaye? | Agar team samajh na paaye → bugs + higher development & maintenance cost. Is week ke concepts (modularity, UML) understandability ke liye hi hain. |
Modular design = problem ko modules mein decompose karna jisme modules ka aapas mein limited interaction ho. Fayda? Har module independently samjha ja sakta hai — understandability ↑, maintainability ↑.
Measure of how functions in a module cooperate together to perform a single objective.
High cohesion = module ke saare functions ek hi objective ke liye milke kaam karte hain. Low cohesion = functions alag-alag unrelated cheezein karte hain.
Measure of the degree of interaction between two modules.
High coupling = function calls mein large chunks of shared data pass hota hai — not desirable. Low coupling = minimal, clean interaction.
Coupling ke types depend karte hain ki modules ke beech kis type ki information share ho rahi hai. Course mein 4 types: Data → Control → Common → Content (best → worst).
Do modules data-coupled hain agar wo primitive data type (integer, float, character, string) parameter ke through communicate karte hain.
Example: Seller module inventory module ko query karta hai view_inventory(seller_id) — seller_id ek integer/string hai. Simple, clean.
Jab pass kiya gaya data doosre module ke internal logic ko influence karta hai — typically flags aur switches.
Example: Seller module calls perform_actions(OPERATION_FLAG). Flag = 0 → view inventory, 1 → add product, 2 → delete product. Inventory module ka behaviour flag ki value pe depend karta hai.
Do modules commonly coupled hain agar wo global data items share karte hain. E.g. OPERATION_FLAG ko global variable bana do — ab doosre modules bhi usse access kar sakte hain, multiple concurrent changes ho sakte hain → unstable system. Not recommended.
Jab ek module doosre module ke internals ko directly refer kare — e.g. ek module doosre mein branch kar jaaye ya uske internal changes pe depend kare. Python/Java jaise OO languages mein rarely hota hai kyunki data + functions encapsulated hote hain.
| Type | Kya share hota hai | Trigger keyword (MCQ ke liye) | Rank |
|---|---|---|---|
| Data | Primitive type parameter (int, float, char) | "passing amount / id / value" | Best ✓ |
| Control | Flag/switch jo logic control kare | "flag ke basis pe different logic" | Okay-ish |
| Common | Global variables | "global data / shared variable" | Bad |
| Content | Doosre module ke internals | "refers to internals / branches into" | Worst ✗ |
Cohesion ke types batate hain ki module ke functions kis basis pe saath rakhe gaye hain. Course order (best → worst): Functional → Sequential → Communicational → Procedural → Coincidental.
Module ke different functions ek single specific task complete karne ke liye cooperate karte hain.
Example — Inventory module: view_inventory(), add_item_to_inventory(), delete_item_inventory() — sab inventory management se related. Perfect.
Functions sequence mein execute hote hain — ek function ka output agle ka input banta hai.
Example — Order Processing: create_order() → check_availability() → place_order(). Note: check_availability() actually product/inventory ko dekhta hai, toh strictly order module ka nahi hai — bas sequence maintain karne ke liye yahan rakha gaya.
Module ke saare functions same data structure ko refer ya update karte hain.
Example: Inventory + catalogue alag rakhne ke bajaye ek hi Product module jisme products ki list hai — add, edit, delete of catalogue AND inventory sab isi mein, same list pe operate karte hue.
Activities sequence se related hain, lekin wo entirely different purposes ke liye kaam karti hain.
Example — ek hi "Seller Portal" module: login → add product to catalogue → add item to inventory → place order → update inventory → logout. Login/logout ka product-add se koi lena dena nahi — ideally alag modules mein hone chahiye the.
Module mein functions ka aapas mein meaningless relationship hai — bas random cheezein ek jagah daal di. Good designs mein rarely dikhta hai.
Ab modules ko represent kaise karein? Course object-oriented design (OOD) approach follow karta hai. Core concepts:
Class = template for object creation. Similar attributes aur methods wale saare objects milke ek class banate hain. E.g. electronic items, clothes, food items — sab Product type ke objects hain.
Classes aapas mein 5 tarike se related ho sakti hain. Notation + identification trick dono yaad karo — assignment ke 5 questions (Q7–Q10, Q15) isi pe hain.
| Statement pattern | Relationship |
|---|---|
| "A delegates to B" / "A needs help from B" / A calls B's method | Association |
| "B is a part of A" / "A contains B" / "A is a collection of Bs" | Composition / Aggregation |
| "A is a kind of B" / "A is a specialisation of B" / categorised into | Inheritance |
| "A changes → B must change" / B implements interface A | Dependency |
Software modeling = system ka external explicit representation banana, taaki design team members aur clients ko communicate ho sake. Iske liye most popular notation: UML (Unified Modeling Language). UML system ko multiple views se describe karta hai — user's view, functional view, behavioural view etc. Course focus: 2 views.
Class diagram static diagram hai — system ki structure dikhata hai: classes, unke attributes, operations/methods, aur objects ke beech relationships. Ye time-dependent behaviour describe nahi karta. Har class box ke 3 compartments:
Seller portal example: Product–Catalogue ke beech composition (products milke catalogue), aur Clothing/Book classes Product base class se inherit karti hain (Book = product + author, publisher, pages jaise extra attributes).
Interaction view ka most important type. Ek user story / requirement ka behaviour implement karta hai — objects ke beech message exchanges ki sequence dikhakar.
VeriSIM = Verifying designs by SIMulating scenarios. Ek learning environment jisse tum class + sequence diagrams ka integrated understanding develop karte ho.
Requirements example: user passcode enter karke register karta hai; lock/unlock option choose karta hai. "Unlock option + correct passcode → door unlocks; incorrect passcode → door locked rehta hai." Ye requirements class diagram + kai sequence diagrams se model hote hain.
Given scenario ke liye ek state diagram construct karna. Isme:
Har activity ke baad evaluations aur reflection activities bhi hoti hain.
Har question ke saath: correct answer highlighted + Hinglish explanation + kaunsa concept test ho raha hai. Explanation kholne ke liye "Samjho kyun" pe click karo.
When all the functions in each module of a software system perform a single objective, then the modules ________.
Cohesion ki definition hi yehi hai — module ke functions milke single objective perform karein = high cohesion. Coupling ka yahan zikr hi nahi (wo modules ke beech ki baat hai), toh C/D out. "Single objective" keyword dikhe → seedha high cohesion.
A software design process has ensured that the changes to the software will be easy to implement even after the product has been released. Which characteristic of good software design is ensured?
"Changes easy to implement even after release" — ye word-to-word maintainability ki definition hai (lecture: "new requests can come even after the product is released… design should be maintainable"). Correctness = functionality sahi, Efficiency = resources, Understandability = team samjhe. Change/modify keyword = maintainability.
Figures mein modules (M1–M5) hain, arrows = interactions. Figure 1: tree-jaisa clean structure (kam arrows). Figure 2: same modules, but bahut saare cross arrows. Select reasons that make Figure 1 a better design than Figure 2.
Arrows = module interactions = coupling. Figure 1 mein kam arrows → lower coupling → better. Kam external interaction ka matlab har module apna kaam khud handle kar raha hai → higher cohesion. Good design mantra: high cohesion + low coupling — Figure 1 dono satisfy karta hai.
When function calls between two modules involve passing a large chunk of shared data, then the modules ________.
Lecture ki exact line: "high coupling means function calls between two modules involve passing large chunks of shared data — and this is not desirable." Do modules ke beech ki baat = coupling (cohesion nahi), aur large shared data = high coupling.
Food delivery app: order module payment module ko payable amount (floating point type) pass karke payment initiate karta hai. Identify the type of coupling.
Float = primitive data type, parameter ke through pass ho raha hai → data coupling (best type). Ye flag nahi hai (logic control nahi kar raha → control ✗), global nahi hai (common ✗), internals refer nahi ho rahe (content ✗).
E-commerce app: order module delivery module ko ek flag pass karta hai (regular vs priority customer). Flag value ke depending pe delivery module different internal logic execute karta hai. Identify the coupling type.
Do giveaways: (1) "flag" word, (2) "depending on flag value, different internal logic" — passed data receiver ke internal logic ko influence kar raha hai = control coupling ki textbook definition (OPERATION_FLAG example jaisa). Note: flag technically primitive hota hai, but jab wo logic control kare toh data coupling nahi, control coupling hai.
Library Management System: objects of Novel class are categorised into two classes — Fiction and Nonfiction. Identify the relationship between Novel and, Fiction & Nonfiction classes.
"Categorised into" = Fiction is a kind of Novel, Nonfiction is a kind of Novel — specialisation → inheritance. Novel = base class; Fiction/Nonfiction = derived classes (jaise Product → Books/Clothing wala example). Part-whole nahi hai (composition ✗), sirf method-call help nahi hai (association ✗).
Online food delivery: diagram mein Customer ─ add_product(prod_id, quantity) ─→ Order. Identify the class relationship type.
Customer object, Order class ka method invoke kar raha hai (add_product) — "A needs help from B / A delegates to B" pattern → association. Notation bhi simple arrow hai (na diamond, na triangle, na dashed). Seller→Inventory view_inventory(seller_id) wale example ka mirror hai.
Class diagram: User ──→ TaskList (plain arrow); TaskList ◆── Task (diamond); TimeBoundTask ──▷ Task (hollow triangle). Which statements are true?
Notation decode karo: User→TaskList plain arrow = association (User register karke tasklist use karta hai). TaskList ke side diamond + tasks: List<Task> attribute = TaskList is a collection of Tasks → composition (whole-part). Aur TimeBoundTask → Task pe hollow triangle = inheritance wahan hai (Task–TaskList ke beech nahi). Diamond dikha toh composition/aggregation, triangle dikha toh inheritance — bas symbols padhne ka game hai.
Pen seller app: Catalogue comprises one or more objects of Pen class; Pen objects further classified as FountainPen, BallPen, GelPen. Correct class diagram?
Do relationships identify karo: (1) "Catalogue comprises Pen objects" = whole-part → diamond Catalogue (whole) ki side pe, Pen ki taraf line. (2) "Pen objects further classified as FountainPen/BallPen/GelPen" = inheritance → triangle Pen (base class) ki taraf, teeno derived classes usse point karti hain. Option B mein dono sahi direction mein hain. C mein containment ulta hai (Pen contains Catalogue — galat).
Food delivery app — "add a restaurant" user story ka sequence diagram (User → AddRestaurant UI → Controller → Restaurant, with addRestaurant(id, name, address) messages). Correct statements?
Terminology swap trap hai ye! Sahi mapping: top boxes = classes/objects ✓ (A sahi). Vertical dashed lines = LIFELINES (messages nahi → B galat). Horizontal arrows = MESSAGES (lifelines nahi → C galat). D sahi kyunki addRestaurant message UI→Controller pe bhi call hota hai aur Controller→Restaurant pe bhi — jis object ki lifeline pe arrow land karta hai, wo method us class mein defined hona chahiye — matlab dono classes mein.
In which of the following diagram models is the flow of control among computational activities?
Slide definition word-to-word: Activity view — models flow of control among computational activities. Compare: State machine = object ke states; Interaction = message exchanges; Class diagram = static structure. Teeno behavioural views ki one-liners ratta maarna zaroori hai (fig 7 dekho).
You need to store a list of active users with fast search and insertion. You decide to use a hash table. Which design decision are you addressing?
Design ke 4 outcomes yaad karo: components, interfaces, data structures, algorithms. "Data kaise store hoga" (hash table, array, tree…) = data structure decision. Algorithm hota agar data pe chalne wala procedure choose kar rahe hote; component hota agar module define karte; interface hota agar modules ka communication decide karte.
Developer ko authentication password-based se OTP-based change karna hai, lekin current code tightly coupled hai aur modify karna difficult hai. Kaunsi design quality lacking hai?
"Difficult to modify/change" = maintainability ki kami. Notice: tight coupling ↔ poor maintainability — yehi reason hai ki hum low coupling chahte hain. Code galat nahi chal raha (correctness ✗), resources ka issue nahi (efficiency ✗), samajhne ka issue primary nahi (understandability ✗) — issue change karne ka hai.
University system: (i) A Course contains multiple Student objects. (ii) A Course uses a GradingService to assign grades. (iii) A Professor is a kind of Employee. Correctly identified set?
Teen statements, teen patterns:
(i) Course contains Students → whole-part. Students course ke bina bhi exist karte hain (independently) → weak containment = Aggregation (composition hota toh part whole ke saath hi jeeta-marta).
(ii) Course uses GradingService = "A needs help from B" = Association.
(iii) Professor is a kind of Employee = specialisation = Inheritance.
Order match: Aggregation, Association, Inheritance → Option A.
| Concept | One-liner (bas itna yaad rakho) |
|---|---|
| Design | Code ko organise karne + structure dene ka tarika (coding se pehle) |
| 4 outcomes | Components · Interfaces · Data Structures · Algorithms (C-I-D-A) |
| Architecture | Components + Interfaces = high-level design |
| Good design | Correctness · Efficiency · Maintainability · Understandability |
| Cohesion | Module ke ANDAR — functions ek single objective ke liye cooperate karein (high chahiye) |
| Coupling | Modules ke BEECH interaction ka degree (low chahiye) |
| Coupling order | Data < Control < Common < Content (best → worst) |
| Cohesion order | Functional > Sequential > Communicational > Procedural > Coincidental |
| Encapsulation | Data + Methods bundle → data hiding → high cohesion + low coupling free mein |
| Association | "A needs help from B" — plain line/arrow |
| Aggregation | "B part of A" (weak) — HOLLOW ◇ whole ki side |
| Composition | "A collection of Bs" (strong) — FILLED ◆ whole ki side |
| Inheritance | "A is a kind of B" — hollow triangle ▷ base class ki side |
| Dependency | "A badla → B badlo" (interface impl.) — dashed arrow |
| Class diagram | Structural/static: Name | Attributes | Operations (3 compartments) |
| Sequence diagram | Ek user story ka behaviour: boxes = objects, vertical dashed = lifelines, horizontal arrows = messages |
| State machine view | Object ke states model karta hai |
| Activity view | Flow of control among computational activities |
| Interaction view | Message exchanges ki sequence (sequence diagram iska type) |
| VeriSIM | Verifying designs by SIMulating scenarios — design tracing se state diagram banao (states ← class diagram, transitions ← sequence diagram) |