OOAD Exam module 1 (With Answers)
OOAD Exam module 1
Table of Contents
- 📝 SET A (Questions 1–60)
- OOAD & Fundamentals (1–15)
- Requirements & Inception (16–30)
- Use Cases (31–45)
- Domain Model & Responsibility (46–60)
- 📝 SET B (Questions 61-120)
- Requirements & FR / NFR (61–80)
- Use Case & Boundary (81–100)
- Domain Model & Responsibility (101–120)
- 📝 SET C (Questions 121-180)
- Scenario-based / วิเคราะห์จริง
📝 SET A (Questions 1–60)
OOAD & Fundamentals (1–15)
- What is the main goal of OOAD?
- A) Writing code faster
- B) Designing UI screens
- C) Bridging requirements to code design
- D) Database optimization
Show Answer
Answer: C – OOAD คือการเชื่อม requirement → design → code
- OOAD focuses mainly on:
- A) Algorithms
- B) Objects, responsibilities, and interactions
- C) Network protocols
- D) UI color schemes
Show Answer
Answer: B – โฟกัสที่ object, responsibility, interaction
- Which statement best describes an object?
- A) A database table
- B) A function
- C) An entity with identity, state, and behavior
- D) A UML diagram
Show Answer
Answer: C – Object = identity + state + behavior
- Which is state of an object?
- A) drive()
- B) deposit()
- C) balance
- D) approve()
Show Answer
Answer: C – balance = state (ข้อมูล)
- Which is behavior?
- A) roomNumber
- B) status
- C) createdAt
- D) cancel()
Show Answer
Answer: D – cancel() = behavior (การกระทำ)
- Class vs Object: which is correct?
- A) Object is a blueprint
- B) Class is a runtime entity
- C) Class defines, Object is an instance
- D) They are identical
Show Answer
Answer: C – Class = blueprint, Object = instance
- Which paradigm best matches real-world domains?
- A) Procedural
- B) Functional
- C) Object-Oriented
- D) Assembly
Show Answer
Answer: C – OOP สะท้อนโลกจริงดีที่สุด
- OOAD happens mainly in which phase?
- A) Deployment
- B) Testing
- C) Analysis & Design
- D) Maintenance
Show Answer
Answer: C – OOAD อยู่ใน Analysis & Design
- Which is an example of overengineering?
- A) No design at all
- B) One class does everything
- C) Too many patterns for simple needs
- D) No documentation
Show Answer
Answer: C – ใช้ pattern เยอะเกินจำเป็น = overengineering
- เป้าหมายของ OOAD คืออะไร?
- A) โค้ดสั้นที่สุด
- B) ออกแบบให้เปลี่ยนแปลงง่าย
- C) ใช้ framework เยอะ
- D) ทำ UI สวย
Show Answer
Answer: B – เป้าหมายคือ design ที่เปลี่ยนง่าย
- Which is NOT a benefit of OOAD?
- A) Maintainability
- B) Flexibility
- C) Faster CPU execution
- D) Clear responsibilities
Show Answer
Answer: C – OOAD ไม่ได้ทำให้ CPU เร็วขึ้นโดยตรง
- OOAD helps reduce:
- A) RAM usage
- B) Rework
- C) Internet latency
- D) Compilation errors
Show Answer
Answer: B – Design ดี → ลด rework
- Which artifact comes first?
- A) Code
- B) Test cases
- C) Requirements
- D) Deployment scripts
Show Answer
Answer: C – Requirements มาก่อนเสมอ
- OOAD is different from OOP because:
- A) OOAD is coding
- B) OOP is planning
- C) OOAD is design thinking
- D) OOP ignores objects
Show Answer
Answer: C – OOAD คือ design thinking ไม่ใช่ coding
- Which best describes identity?
- A) Attribute value
- B) Unique existence of an object
- C) Method name
- D) Data type
Requirements & Inception (16–30)
Show Answer
Answer: B – Identity = ความเป็นเอกลักษณ์ของ object
- Requirements inception means:
- A) Writing code
- B) Testing system
- C) Clarifying problem & scope
- D) Deploying MVP
Show Answer
Answer: C – Inception = เข้าใจ problem & scope
- What is a stakeholder?
- A) Database admin
- B) Anyone affected by the system
- C) Only developers
- D) Only users
Show Answer
Answer: B – Stakeholder = ทุกคนที่ได้รับผลกระทบ
- Functional Requirement (FR) describes:
- A) Performance
- B) Security
- C) System behavior
- D) Constraints
Show Answer
Answer: C – FR = พฤติกรรมระบบ
- Non-Functional Requirement (NFR) describes:
- A) Business logic
- B) Quality attributes
- C) UI layout
- D) Use case steps
Show Answer
Answer: B – NFR = คุณภาพ เช่น performance, usability
- Which is an FR?
- A) System responds in 2 seconds
- B) Only staff can approve
- C) User can cancel booking
- D) Data encrypted at rest
Show Answer
Answer: C – “User can cancel booking” = behavior
- Which is an NFR?
- A) Create booking
- B) Approve request
- C) Cancel request
- D) Response time ≤ 2 seconds
Show Answer
Answer: D – Response time ≤ 2s = performance (NFR)
- “The system should be fast” is:
- A) Good requirement
- B) Testable
- C) Vague
- D) Functional
Show Answer
Answer: C – “Fast” = vague
- Acceptance criteria are used to:
- A) Design UI
- B) Define “done”
- C) Write code
- D) Create DB schema
Show Answer
Answer: B – Acceptance criteria กำหนดว่า done คืออะไร
- Which word should be avoided in requirements?
- A) Shall
- B) Must
- C) Easy
- D) Allow
Show Answer
Answer: C – “Easy” วัดไม่ได้
- ข้อใดคือ requirement ที่ดี?
- A) ระบบต้องใช้ง่าย
- B) ระบบต้องเร็ว
- C) ผู้ใช้ใหม่จองห้องได้ภายใน 2 นาที
- D) ระบบต้องดี
Show Answer
Answer: C – วัดได้และเฉพาะเจาะจง
- Which requirement level answers “Why”?
- A) System
- B) User
- C) Business
- D) Technical
Show Answer
Answer: C – Business requirement ตอบ Why
- Traceability links:
- A) Code → UI
- B) Requirement → Test
- C) DB → Server
- D) Class → Table
Show Answer
Answer: B – Traceability: requirement → test
- Which is NOT a requirement smell?
- A) Ambiguous
- B) Testable
- C) Bundled
- D) Contradictory
Show Answer
Answer: B – Testable ไม่ใช่ smell
- MoSCoW “Must” means:
- A) Optional
- B) Nice-to-have
- C) Critical
- D) Postponed
Show Answer
Answer: C – Must = critical
- In inception, system boundary defines:
- A) UI layout
- B) Scope (inside/outside)
- C) Database schema
- D) Coding style
Use Cases (31–45)
Show Answer
Answer: B – Boundary = กำหนด scope
- A use case focuses on:
- A) UI clicks
- B) Actor goals
- C) Code structure
- D) Database
Show Answer
Answer: B – Use case เน้น actor goal
- Actor can be:
- A) Only humans
- B) Only admins
- C) External systems
- D) Only users
Show Answer
Answer: C – Actor อาจเป็น external system
- Which is a good use case name?
- A) Booking page UI
- B) Manage system
- C) Submit Booking Request
- D) Database insert
Show Answer
Answer: C – ต้องเป็น verb + goal
- Primary actor is:
- A) The system
- B) External service
- C) Main goal achiever
- D) Database
Show Answer
Answer: C – Primary actor = คนได้ goal
- Use case level we focus most on:
- A) Summary
- B) User-goal
- C) Sub-function
- D) Technical
Show Answer
Answer: B – Focus user-goal level
- Preconditions describe:
- A) UI steps
- B) System state before start
- C) Error handling
- D) Code logic
Show Answer
Answer: B – Preconditions = สภาพก่อนเริ่ม
- Alternative flows capture:
- A) Happy path
- B) UI design
- C) Exceptions & edge cases
- D) Database errors only
Show Answer
Answer: C – Alternative flow = exception
- Which should be avoided in use cases?
- A) Clear steps
- B) Consistent terms
- C) UI button color
- D) Actor goals
Show Answer
Answer: C – หลีกเลี่ยง UI detail
- System boundary helps prevent:
- A) Bugs
- B) Scope creep
- C) Refactoring
- D) Testing
Show Answer
Answer: B – Boundary กัน scope creep
- “Click green button” is:
- A) Good use case step
- B) UI-driven detail
- C) Actor goal
- D) Business rule
Show Answer
Answer: B – “Click green button” = UI detail
- Which is a sub-function use case?
- A) Submit Booking
- B) Approve Booking
- C) Validate Time Slot
- D) Cancel Booking
Show Answer
Answer: C – Validate Time Slot = sub-function
- Use case diagram mainly shows:
- A) Detailed logic
- B) Scope & actors
- C) Database design
- D) Algorithms
Show Answer
Answer: B – Diagram แสดง scope + actor
- Use cases help discover:
- A) UI color
- B) Missing rules
- C) Server specs
- D) IDE settings
Show Answer
Answer: B – ช่วยเจอ missing rule
- Actor roles should be:
- A) Person names
- B) Job titles
- C) Roles (Student, Staff)
- D) Emails
Show Answer
Answer: C – ตั้งชื่อเป็น role
- Use case narratives include all EXCEPT:
- A) Preconditions
- B) Postconditions
- C) Class attributes
- D) Main flow
Domain Model & Responsibility (46–60)
Show Answer
Answer: C – Class attribute ไม่อยู่ใน use case
- Domain model represents:
- A) Code classes
- B) DB tables
- C) Problem domain concepts
- D) UI components
Show Answer
Answer: C – Conceptual model ของ problem
- Which should NOT appear in domain model?
- A) Room
- B) BookingRequest
- C) Controller
- D) TimeSlot
Show Answer
Answer: C – Controller ไม่ใช่ domain concept
- Domain model is:
- A) Technology dependent
- B) Conceptual
- C) Physical schema
- D) Implementation
Show Answer
Answer: B – Technology independent
- Multiplicity 0..* means:
- A) Exactly one
- B) Optional one
- C) Many or none
- D) One or more
Show Answer
Answer: C – 0.. = none or many*
- Inheritance should be used when:
- A) Convenient
- B) True “is-a” relationship
- C) Many attributes
- D) Performance needed
Show Answer
Answer: B – Inheritance ต้อง is-a
- Glossary is used to:
- A) Store code
- B) Share vocabulary
- C) Design UI
- D) Optimize DB
Show Answer
Answer: B – Glossary สร้าง shared vocabulary
- Responsibility refers to:
- A) Only data
- B) Only behavior
- C) What object knows & does
- D) UI logic
Show Answer
Answer: C – Responsibility = what object knows & does
- GRASP stands for:
- A) Design patterns
- B) Responsibility assignment principles
- C) UML notation
- D) Testing strategy
Show Answer
Answer: B – GRASP = responsibility principles
- Information Expert principle assigns responsibility to:
- A) UI
- B) Controller
- C) Class with needed data
- D) Database
Show Answer
Answer: C – Assign to class with data
- Creator principle suggests creation responsibility goes to:
- A) Random class
- B) UI
- C) Aggregating class
- D) External system
Show Answer
Answer: C – Aggregator ควรสร้าง object
- Low coupling means:
- A) Many dependencies
- B) Few dependencies
- C) Big classes
- D) Shared state
Show Answer
Answer: B – Low coupling = dependency น้อย
- High cohesion means:
- A) Many unrelated tasks
- B) Clear focused responsibility
- C) Many methods
- D) Large file
Show Answer
Answer: B – High cohesion = focused
- “God class” is a sign of:
- A) High cohesion
- B) Good design
- C) Low cohesion
- D) Polymorphism
Show Answer
Answer: C – God class = low cohesion
- Which improves maintainability?
- A) Tight coupling
- B) High cohesion
- C) UI logic in domain
- D) Mixed responsibilities
Show Answer
Answer: B – Cohesion สูงช่วย maintain
- ความรับผิดชอบ (Responsibility) ที่ดีควร:
- A) ทำทุกอย่าง
- B) กระจายไปทั่ว
- C) ชัดเจนและเฉพาะเจาะจง
- D) ผูกกับ UI
Show Answer
Answer: C – Responsibility ต้องชัด
📝 SET B (Questions 61-120)
Requirements & FR / NFR (61–80)
- ข้อใดเป็น Functional Requirement (FR)?
- A) ระบบต้องรองรับผู้ใช้ 200 คน
- B) ระบบตอบสนองภายใน 2 วินาที
- C) ผู้ใช้สามารถยกเลิกคำขอได้ก่อนอนุมัติ
- D) ข้อมูลต้องถูกเข้ารหัส
Show Answer
Answer: C – behavior
- “Only staff can approve requests” จัดเป็น:
- A) FR
- B) NFR ด้าน security
- C) Business requirement
- D) UI rule
Show Answer
Answer: B – security constraint
- ข้อใดคือ NFR ด้าน usability?
- A) ผู้ใช้สร้าง booking ได้
- B) ผู้ใช้ใหม่ทำรายการได้ภายใน 2 นาที
- C) ระบบบันทึก booking
- D) ระบบส่ง notification
Show Answer
Answer: B – usability วัดจากเวลา
- คำว่า “shall” ใน requirement หมายถึง:
- A) ตัวเลือก
- B) คำแนะนำ
- C) ข้อบังคับ
- D) สมมติฐาน
Show Answer
Answer: C – shall = mandatory
- ข้อใดเป็น requirement smell?
- A) Testable
- B) Measurable
- C) Ambiguous
- D) Consistent
Show Answer
Answer: C – ambiguous = smell
- “The system shall generate reports and send notifications” เป็นปัญหาเพราะ:
- A) เขียนดีเกินไป
- B) Bundled requirement
- C) เป็น NFR
- D) ไม่ใช่ระบบ
Show Answer
Answer: B – รวม 2 requirement
- Acceptance criteria ควร:
- A) กำกวม
- B) วัดผลไม่ได้
- C) ตรวจสอบ pass/fail ได้
- D) เขียนหลัง coding
Show Answer
Answer: C – ต้อง pass/fail ได้
- Requirement ใดตอบคำถาม “What users need”?
- A) Business
- B) User
- C) System
- D) Technical
Show Answer
Answer: B – User requirement
- Traceability สำคัญเพราะ:
- A) ลดโค้ด
- B) พิสูจน์ว่าระบบตรง requirement
- C) ออกแบบ UI
- D) เพิ่ม performance
Show Answer
Answer: B – prove compliance
- ข้อใดไม่ควรเขียนเป็น requirement?
- A) สิ่งที่ต้องทำ
- B) ข้อจำกัด
- C) เทคโนโลยีที่ต้องใช้
- D) คุณภาพระบบ
Show Answer
Answer: C – Technology choice = design
- “Must use microservices” ถือเป็น:
- A) FR
- B) NFR
- C) Design decision
- D) Acceptance criteria
Show Answer
Answer: C – microservices = design decision
- NFR มักเกี่ยวข้องกับ:
- A) Verb
- B) Scenario
- C) Quality attribute
- D) Actor
Show Answer
Answer: C – NFR = quality
- ข้อใดเป็น NFR ด้าน reliability?
- A) ระบบไม่ล่มเมื่อ restart
- B) ผู้ใช้สร้าง booking
- C) Staff อนุมัติ request
- D) ระบบแจ้งเตือน
Show Answer
Answer: A – reliability
- MoSCoW – “Could” หมายถึง:
- A) ต้องมี
- B) ควรมี
- C) ถ้ามีก็ดี
- D) ห้ามมี
Show Answer
Answer: C – Could = nice-to-have
- Requirement ที่ดีต้อง:
- A) กว้าง
- B) กำกวม
- C) ตรวจสอบได้
- D) ยาว
Show Answer
Answer: C – ต้อง testable
- ข้อใดคือ FR?
- A) ระบบเข้ารหัสข้อมูล
- B) ระบบเก็บข้อมูล 2 ปี
- C) ผู้ใช้ดูสถานะ booking
- D) ระบบตอบสนองเร็ว
Show Answer
Answer: C – ดูสถานะ = behavior
- “Fast” ควรถูกแทนด้วย:
- A) คำอื่น
- B) ตัวเลขที่วัดได้
- C) UI
- D) Code
Show Answer
Answer: B – ต้อง measurable
- Acceptance criteria ควรเขียน:
- A) หลัง deploy
- B) พร้อม requirement
- C) หลังสอบ
- D) หลัง debug
Show Answer
Answer: B – เขียนพร้อม requirement
- Requirement level ที่ละเอียดที่สุดคือ:
- A) Business
- B) User
- C) System
- D) Vision
Show Answer
Answer: C – System level ละเอียดสุด
- Inception สิ้นสุดเมื่อ:
- A) เขียนโค้ดเสร็จ
- B) เข้าใจ scope และ requirement
- C) Deploy ระบบ
- D) สอบผ่าน
Use Case & Boundary (81–100)
Show Answer
Answer: B – จบเมื่อเข้าใจ scope
- Use case เน้น:
- A) UI
- B) Actor goal
- C) Database
- D) Algorithm
Show Answer
Answer: B – goal-driven
- Actor ต้อง:
- A) อยู่ในระบบ
- B) เป็นคนเท่านั้น
- C) อยู่นอก system boundary
- D) เป็น admin
Show Answer
Answer: C – outside boundary
- “Approve Booking Request” เป็น use case ระดับ:
- A) Summary
- B) User-goal
- C) Sub-function
- D) Technical
Show Answer
Answer: B – user-goal
- Preconditions คือ:
- A) สิ่งที่เกิดหลังจบ
- B) เงื่อนไขก่อนเริ่ม
- C) Error
- D) UI state
Show Answer
Answer: B – before start
- Trigger คือ:
- A) กฎ
- B) เหตุการณ์เริ่ม use case
- C) Postcondition
- D) Test
Show Answer
Answer: B – trigger = event
- ข้อใดไม่ควรอยู่ใน use case?
- A) Actor action
- B) System response
- C) SQL query
- D) Business rule
Show Answer
Answer: C – SQL = implementation
- Alternative flow ใช้สำหรับ:
- A) Happy path
- B) UI
- C) Exception
- D) Class design
Show Answer
Answer: C – exception
- Use case diagram แสดง:
- A) Logic ลึก
- B) Scope และ actor
- C) Database
- D) Code
Show Answer
Answer: B – scope & actor
- Actor ควรตั้งชื่อเป็น:
- A) ชื่อคน
- B) Email
- C) Role
- D) Function
Show Answer
Answer: C – role
- System boundary ใช้เพื่อ:
- A) ปรับ UI
- B) กัน scope creep
- C) Optimize DB
- D) Test code
Show Answer
Answer: B – prevent creep
- “Click submit button” เป็น:
- A) Goal
- B) Implementation detail
- C) UI detail
- D) Business rule
Show Answer
Answer: C – UI detail
- Use case ระดับ summary:
- A) รายละเอียดมาก
- B) ภาพรวมกระบวนการ
- C) Reusable
- D) Technical
Show Answer
Answer: B – overview
- Sub-function use case คือ:
- A) Submit request
- B) Cancel booking
- C) Validate permission
- D) View status
Show Answer
Answer: C – reusable logic
- Use case ที่ดีควรมี:
- A) อย่างน้อย 1 alternative flow
- B) UI mockup
- C) Code snippet
- D) DB schema
Show Answer
Answer: A – ควรมี alternative
- Postcondition บอก:
- A) ก่อนเริ่ม
- B) หลังจบ
- C) ระหว่าง
- D) ก่อน test
Show Answer
Answer: B – after finish
- Use case narrative ไม่ควร:
- A) สอดคล้อง glossary
- B) ใช้คำสม่ำเสมอ
- C) อิง UI
- D) แสดง intent
Show Answer
Answer: C – ไม่อิง UI
- Actor สามารถเป็น:
- A) Scheduler
- B) External system
- C) ทั้ง A และ B
- D) ไม่มีข้อใด
Show Answer
Answer: C – both
- Use case ช่วยหา:
- A) Missing rule
- B) สีปุ่ม
- C) Framework
- D) IDE
Show Answer
Answer: A – missing rule
- Boundary ผิดพลาดจะทำให้:
- A) Code ช้า
- B) Scope ใหญ่เกิน
- C) Bug
- D) Test fail
Show Answer
Answer: B – boundary ผิด = scope บวม
- Use case “Manage system” เป็นตัวอย่างของ:
- A) ดี
- B) ชัดเจน
- C) กว้างเกินไป
- D) Sub-function
Domain Model & Responsibility (101–120)
Show Answer
Answer: C – กว้างเกิน
- Domain model คือ:
- A) UML code diagram
- B) Conceptual model
- C) DB schema
- D) API design
Show Answer
Answer: B – conceptual
- ข้อใดไม่ใช่ domain concept?
- A) Room
- B) BookingRequest
- C) Controller
- D) User
Show Answer
Answer: C – Controller = design artifact
- Domain model ควร:
- A) อิง framework
- B) Technology-independent
- C) มี service
- D) มี UI
Show Answer
Answer: B – tech-independent
- Multiplicity 1..* หมายถึง:
- A) 0 หรือ 1
- B) อย่างน้อย 1
- C) เท่ากับ 1
- D) มากสุด 1
Show Answer
Answer: B – ≥1
- Inheritance ใช้เมื่อ:
- A) สะดวก
- B) Is-a relationship
- C) Has-a
- D) Performance
Show Answer
Answer: B – is-a
- Glossary มีไว้เพื่อ:
- A) เก็บโค้ด
- B) ป้องกันความหมายสับสน
- C) ออกแบบ UI
- D) Test
Show Answer
Answer: B – shared meaning
- Responsibility คือ:
- A) Attribute
- B) Method
- C) สิ่งที่ object ต้องทำ/รู้
- D) UI action
Show Answer
Answer: C – do/know
- GRASP ใช้เพื่อ:
- A) เขียน code
- B) Assign responsibility
- C) วาด UML
- D) Test
Show Answer
Answer: B – assign responsibility
- Information Expert ควร:
- A) รับทุกอย่าง
- B) อยู่ที่ UI
- C) อยู่ที่ class ที่มีข้อมูล
- D) อยู่ที่ controller เสมอ
Show Answer
Answer: C – class with data
- Creator principle:
- A) UI สร้าง object
- B) Class ใกล้ชิดสร้าง object
- C) DB สร้าง
- D) Actor สร้าง
Show Answer
Answer: B – closest class
- Low coupling หมายถึง:
- A) พึ่งพากันมาก
- B) แยกอิสระ
- C) Class ใหญ่
- D) Code ยาว
Show Answer
Answer: B – independent
- High cohesion หมายถึง:
- A) หลายหน้าที่
- B) หน้าที่ชัด
- C) มีหลาย dependency
- D) ทำทุกอย่าง
Show Answer
Answer: B – focused
- God class เป็น:
- A) Best practice
- B) Anti-pattern
- C) GRASP
- D) Requirement
Show Answer
Answer: B – anti-pattern
- Domain model ไม่ควรมี:
- A) Status
- B) Attribute
- C) Database key
- D) Relationship
Show Answer
Answer: C – no DB key
- Business rule ควรถูก:
- A) ฝังใน UI
- B) เขียนเป็น note
- C) ไม่สนใจ
- D) ใส่ DB เท่านั้น
Show Answer
Answer: (ควรเป็น Domain logic) – ไม่ใช่ UI
- Concept hunting เริ่มจาก:
- A) Verb
- B) Noun
- C) Code
- D) DB
Show Answer
Answer: B – noun hunting
- BookingRequest เป็น:
- A) Entity
- B) Event/Transaction
- C) UI
- D) Service
Show Answer
Answer: B – transaction
- Responsibility assignment ที่ดีช่วย:
- A) Code ช้า
- B) Maintainability
- C) Bug เพิ่ม
- D) Coupling สูง
Show Answer
Answer: B – maintainability
- Controller ใน GRASP คือ:
- A) UI
- B) DB
- C) Object รับ system event
- D) Actor
Show Answer
Answer: C – receives system event
- “SystemManager” class มักบ่งบอกถึง:
- A) High cohesion
- B) Good design
- C) God class
- D) Polymorphism
Show Answer
Answer: C – God class smell
📝 SET C (Questions 121-180)
Scenario-based / วิเคราะห์จริง
- นักศึกษาส่งคำขอจองห้อง → ใครควรตรวจสอบเวลาซ้อน?
- A) UI
- B) BookingRequest
- C) Room / Schedule
- D) User
Show Answer
Answer: C – Room/Schedule มีข้อมูลเวลา
- การ “approve request” เปลี่ยน:
- A) UI
- B) Status
- C) Actor
- D) Boundary
Show Answer
Answer: B – เปลี่ยน status
- ถ้าระบบอนุญาตเฉพาะ Staff อนุมัติ → เป็น:
- A) FR
- B) NFR
- C) Business rule
- D) ทั้ง B และ C
Show Answer
Answer: C – เป็น security business rule ไม่ใช่ NFR เพราะมักจะเกี่ยวกับ Security ของระบบมากกว่า Security ของ business
- “Cancel after approved” ควร:
- A) อนุญาต
- B) ป้องกันด้วย rule
- C) เป็น UI choice
- D) Ignore
Show Answer
Answer: B – enforce rule
- Object ที่เหมาะเป็น Creator ของ BookingRequest คือ:
- A) UI
- B) User หรือ BookingService
- C) Database
- D) Actor
Show Answer
Answer: B – Creator principle
- ถ้า requirement เขียนว่า “ระบบดีและใช้ง่าย” ปัญหาคือ:
- A) สั้น
- B) Vague
- C) FR
- D) NFR
Show Answer
Answer: B – vague
- Use case ที่รวมหลาย goal เป็น:
- A) ดี
- B) Bundled
- C) Summary
- D) Sub-function
Show Answer
Answer: B – bundled
- Domain model มี “Manager” หลายตัว แสดงว่า:
- A) ดี
- B) High cohesion
- C) Design smell
- D) Correct
Show Answer
Answer: C – Manager เยอะ = smell
- Polymorphism ช่วยลด:
- A) Performance
- B) If-else
- C) Memory
- D) Storage
Show Answer
Answer: B – ลด if-else
- “PaymentMethod.pay()” เป็นตัวอย่างของ:
- A) Inheritance
- B) Encapsulation
- C) Polymorphism
- D) Coupling
Show Answer
Answer: C – polymorphism
- ถ้า UI เรียก DB ตรง → เป็น:
- A) Loose coupling
- B) Tight coupling
- C) GRASP
- D) MVC
Show Answer
Answer: B – tight coupling
- Acceptance criteria แบบ Given–When–Then ช่วย:
- A) เขียน code
- B) Test scenario
- C) Design UI
- D) DB
Show Answer
Answer: B – test scenario
- Use case ที่ดีควร:
- A) ยาว
- B) ครอบคลุมทุก feature
- C) ชัดเจนทีละ goal
- D) อิง framework
Show Answer
Answer: C – หนึ่ง goal ต่อ use case
- Status เช่น REQUESTED, APPROVED ควรอยู่ใน:
- A) UI
- B) Domain model
- C) DB เท่านั้น
- D) Test
Show Answer
Answer: B – status ใน domain
- “Validate permission” เหมาะเป็น:
- A) User-goal
- B) Sub-function
- C) Summary
- D) Actor
Show Answer
Answer: B – sub-function
- Business rule “ห้ามจองเวลาซ้อน” ควร:
- A) อยู่ใน UI
- B) อยู่ใน Domain logic
- C) อยู่ใน DB อย่างเดียว
- D) Ignore
Show Answer
Answer: B – domain logic
- ถ้า class ทำ login + booking + report:
- A) High cohesion
- B) Low coupling
- C) God class
- D) GRASP
Show Answer
Answer: C – god class
- การใช้ inheritance ผิดจะทำให้:
- A) Cohesion สูง
- B) Coupling สูง
- C) Simpler
- D) Faster
Show Answer
Answer: B – coupling สูง
- OOAD เน้น “ก่อนเขียนโค้ด” เพื่อ:
- A) ช้า
- B) ลด rework
- C) ใช้ AI
- D) เขียน UML
Show Answer
Answer: B – ลด rework
- Domain model v1 ควรมีประมาณ:
- A) 1–3 class
- B) 50 class
- C) 10–15 class
- D) ไม่จำกัด
Show Answer
Answer: C – 10–15 พอเหมาะ v1
- Glossary ช่วยให้:
- A) Code เร็ว
- B) ทีมเข้าใจตรงกัน
- C) DB เล็ก
- D) UI สวย
Show Answer
Answer: B – shared understanding
- Actor “Scheduler” จัดเป็น:
- A) Human
- B) External system
- C) Role
- D) UI
Show Answer
Answer: C – role
- Use case เขียน “Call API” เป็น:
- A) ดี
- B) Implementation detail
- C) Goal
- D) Rule
Show Answer
Answer: B – implementation detail
- Responsibility ที่ดีควร:
- A) กระจาย
- B) ซ้ำ
- C) ชัดเจน
- D) อยู่ที่ UI
Show Answer
Answer: C – clear
- FR ต้อง:
- A) วัดผลไม่ได้
- B) Test ได้
- C) เป็น design
- D) เป็น code
Show Answer
Answer: B – testable
- NFR ที่ดีต้อง:
- A) กำกวม
- B) วัดได้
- C) เป็น UI
- D) เป็น DB
Show Answer
Answer: B – measurable
- Requirement ที่ขัดกันจะทำให้:
- A) Code เร็ว
- B) Design unstable
- C) Bug น้อย
- D) Test ง่าย
Show Answer
Answer: B – unstable design
- “Support all users” เป็น:
- A) Specific
- B) Scope-free
- C) Measurable
- D) Good
Show Answer
Answer: B – vague
- Domain model ไม่ควรรีบ:
- A) เขียน
- B) Collapse เป็น DB
- C) Review
- D) ใช้
Show Answer
Answer: B – อย่า collapse เป็น DB เร็วเกิน
- GRASP ช่วย:
- A) วาด UI
- B) ตัดสินใจ design
- C) เขียน SQL
- D) Deploy
Show Answer
Answer: B – design decision
- ถ้าเปลี่ยน DB แล้ว UI พัง แสดงว่า:
- A) Loose coupling
- B) Tight coupling
- C) High cohesion
- D) Polymorphism
Show Answer
Answer: B – tight coupling
- “ApproveBookingController” ทำหน้าที่:
- A) Domain entity
- B) Controller
- C) Actor
- D) Repository
Show Answer
Answer: B – controller
- Responsibility mapping มาจาก:
- A) Code
- B) Use case steps
- C) DB
- D) UI
Show Answer
Answer: B – derive from use case
- Actor vs User ต่างกันตรง:
- A) Actor เป็น role
- B) User เป็น class เสมอ
- C) Actor อยู่ในระบบ
- D) User เป็น external
Show Answer
Answer: A – actor = role
- Use case ที่ดีต้อง:
- A) ยึด UI
- B) ยึด intent
- C) ยึด code
- D) ยึด DB
Show Answer
Answer: B – intent-based
- Domain model attribute ควร:
- A) ทุก field
- B) มีความหมายทางธุรกิจ
- C) UI only
- D) Technical
Show Answer
Answer: B – business meaning
- “Only staff can approve” ควรอยู่ใน:
- A) UI
- B) Business rule
- C) Database
- D) CSS
Show Answer
Answer: B – business rule
- OOAD + Agile หมายถึง:
- A) Design ครั้งเดียว
- B) Iterative
- C) No design
- D) Big upfront
Show Answer
Answer: B – iterative
- Vertical slice คือ:
- A) UI only
- B) DB only
- C) End-to-end feature
- D) Diagram
Show Answer
Answer: C – end-to-end
- If requirement unclear ผลคือ:
- A) Code stable
- B) Design drift
- C) Test ง่าย
- D) Performance ดี
Show Answer
Answer: B – design drift
- “BookingService” ที่ทำทุกอย่างคือ:
- A) High cohesion
- B) God class
- C) GRASP
- D) MVC
Show Answer
Answer: B – god class
- Sub-function use case มัก:
- A) เริ่มก่อน
- B) เขียนหลัง
- C) reuse ได้
- D) เป็น UI
Show Answer
Answer: C – reuse
- Domain model ควร sync กับ:
- A) Code เสมอ
- B) Use case & glossary
- C) DB only
- D) Framework
Show Answer
Answer: B – sync กับ use case + glossary
- Acceptance criteria ใช้ใน:
- A) Test
- B) Demo
- C) Grading
- D) ทั้งหมด
Show Answer
Answer: D – test/demo/grading
- Object responsibility ที่ดีช่วย:
- A) Debug ยาก
- B) Change ง่าย
- C) Code ยาว
- D) Dependency เยอะ
Show Answer
Answer: B – change ง่าย
- OOAD artifact ใดมาก่อน?
- A) Sequence diagram
- B) Domain model
- C) Requirements
- D) Code
Show Answer
Answer: C – requirements first
- Use case ที่ไม่มี exception:
- A) สมบูรณ์
- B) ผิด
- C) เสี่ยง bug
- D) ถูก
Show Answer
Answer: C – เสี่ยง bug
- “User logs in” เป็น:
- A) Use case goal
- B) Sub-function
- C) Business rule
- D) UI
Show Answer
Answer: A – goal
- Domain model ไม่ควร:
- A) เปลี่ยน
- B) Iterative
- C) Fix ตายตัว
- D) Review
Show Answer
Answer: C – ไม่ fix ตายตัว
- Business rule ควร:
- A) Test ได้
- B) กำกวม
- C) ซ่อน
- D) Ignore
Show Answer
Answer: A – testable
- “Check permission” เหมาะกับ:
- A) Controller
- B) Domain logic
- C) UI
- D) Actor
Show Answer
Answer: B – domain logic
- If-else เยอะ แสดงว่า:
- A) Polymorphism ดี
- B) ออกแบบไม่ดี
- C) High cohesion
- D) Loose coupling
Show Answer
Answer: B – design issue
- OOAD ช่วยให้:
- A) Code เร็วเสมอ
- B) เปลี่ยน requirement ง่าย
- C) No refactor
- D) Bug หาย
Show Answer
Answer: B – easier change
- Status transition ควรอยู่:
- A) UI
- B) Domain object
- C) DB trigger
- D) Actor
Show Answer
Answer: B – state machine ใน domain
- Use case กับ Domain model เชื่อมกันผ่าน:
- A) UI
- B) Glossary
- C) Framework
- D) IDE
Show Answer
Answer: B – glossary เชื่อม concept
- Actor ไม่ควรเป็น:
- A) Role
- B) External system
- C) Class ภายใน
- D) Scheduler
Show Answer
Answer: C – class ภายในไม่ใช่ actor
- Acceptance criteria ที่ดีต้อง:
- A) เขียนคลุมเครือ
- B) วัดไม่ได้
- C) ชัดเจน
- D) เป็น code
Show Answer
Answer: C – clear
- Domain model ที่ดี:
- A) ใหญ่
- B) เล็กแต่ชัด
- C) มี service
- D) มี UI
Show Answer
Answer: B – small but clear
- OOAD เป้าหมายสูงสุดคือ:
- A) UML สวย
- B) Design ที่เปลี่ยนได้
- C) Code น้อย
- D) AI
Show Answer
Answer: B – change-friendly design
- “ความรับผิดชอบของ object” ที่ดีควร:
- A) ซ้อนกัน
- B) ชัดและไม่ทับกัน
- C) อยู่ใน UI
- D) รวมทุกอย่าง
Show Answer
Answer: B – responsibility ไม่ทับซ้อน