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