การวิเคราะห์และออกแบบระบบเชิงวัตถุ

Object-Oriented Analysis and Design Concepts

Fundamental OO Analysis and Design Concepts

• Identify the problems we want to solve
  (ระบุปัญหาที่เราต้องการแก้ไข)

• Clarify the functionality required to solve the problems
  (หาข้อสรุป เครื่องมือ/กระบวนการ ที่จำเป็นในการแก้ปัญหา)

• Document important decisions
  (จัดทำเอกสารสำคัญสำหรับสัญญาการว่าจ้างทำระบบ)

Step 1: Collect requirements (เก็บรวบรวมความต้องการของระบบ/โปรแกรม)

Fundamental OO Analysis and Design Concepts

• Describe the system from the user's point of view
  (บรรยาย/พรรณนา ถึงระบบจากมุมมองของผู้ใช้งาน)

• Create wireframes and prototypes if needed
  (จัดทำร่างไวร์เฟรมและพิมพ์เขียวของระบบ)

Step 2: Describe the system (ทำความเข้าใจระบบ)

Wireframes
& non-functional prototypes

Fundamental OO Analysis and Design Concepts

• ยกตัวอย่างเช่น การพัฒนาระบบ E-commerce ควรจะมี class เพื่อบริหารจัดการสินค้าที่ต้องการขาย 

Step 3: Identify the class (ระบุถึงสิ่งที่ต้องพัฒนาในระบบ)

Fundamental OO Analysis and Design Concepts

• class ที่ทำงานรับผิดชอบเกี่ยวกับความปลอดภัยของการส่งผ่านข้อมูลภายในระบบ

• class อื่น ๆ ที่จำเป็นต้องใช้งานในระบบ

Step 3: Identify the class (ระบุถึงสิ่งที่ต้องพัฒนาในระบบ)

Fundamental OO Analysis and Design Concepts

• Describe the behavior of our system in a formal way (เขียนไดอะแกรมพิมพ์ของระบบ รวมไปถึงการดำเนินงานในส่วนต่าง ๆ  ของระบบ)

• Visual representation (แผนภาพ)
  -> classes and their attributes & behavior.

• ยกตัวอย่าง เช่น Class diagram, Sequece diagram, และ ฯลฯ -> UML

Step 4: Create diagrams (เขียนแผนภาพไดอะแกรม)

Example of Classes diagrams

Unified Modeling Language - UML

Graphical notation used to describe object-oriented systems

Collecting Requirements (เก็บรวบรวมขอมูล)

• The ​​initial step of building a software system is crucial (ขั้นตอนแรกเริ่มสำคัญที่สุดเสมอ)

• Requirement Analysis (วิเคราะห์ความต้องการของระบบ)

• ขั้นตอนนี้เปรียบเสมือนกับการปูทางสำหรับขั้นตอนต่อไป

• What is Needed ? / Wanted?

Collecting Requirements (เก็บรวบรวมขอมูล)

ตัวอย่าง ต้องการสร้างแอพสำหรับออกกำลังกาย

Collecting Requirements (เก็บรวบรวมขอมูล)

Non-functional

Requirements

Collecting Requirements (เก็บรวบรวมขอมูล)

Non-functional Requirements

Ways to collect requirements (วิธีรวบรวมข้อมูล)

จดบันทึก ยกตัวอย่าง functional req. เช่น

• แอพสามารถเก็บบันทึกข้อมูลค่าใช้จ่ายท่องเที่ยวแยกเป็นแต่ละทริปการเดินทางได้

• แต่ละทริปการเดินทาง ผู้ใช้งานระบุสกุลเงินพื้นฐานได้

• สกุลเงินเริ่มต้น ให้ดึงข้อมูลจากระบบสมาร์ทโฟนของผู้ใช้งาน

• ผู้ใช้งาน สามารถกำหนดสกุลเงินพื้นฐานได้เอง

• ข้อมูลรายจ่ายสามารถรับค่าในรูปแบบสกุลเงินอื่นได้

• แอพสามารถแปลงค่าสกุลเงินต่าง ๆ ไปเป็นสกุลเงินพื้นฐาน

Ways to collect requirements (วิธีรวบรวมข้อมูล)

จดบันทึก ยกตัวอย่าง non-functional req. เช่น

• แอพจะต้องใช้งานได้บน ios เวอร์ชั่น 9.0 หรือใหม่กว่า

• แอพไม่ควรโหลดข้อมูลที่ไม่จำเป็นสำหรับทริปการเดินทางแต่ละครั้ง เพื่อลดปริมาณการโหลดข้อมูล และประหยัดค่าโรมมิ่งข้อมูล รวมไปถึงการใช้งานแบตเตอรี่เท่าที่จำเป็น

• แอพควรจะต้องมีช่องทางการติดต่อได้แก่ อีเมล์และลิ้งค์เชื่อมโยงไปยังเว็บไซต์ของกิจการ

<The app / system> must <do something>

<แอพพลิเคชั่น / ระบบ> ต้องทำ <อะไรได้>

Ways to collect requirements (วิธีรวบรวมข้อมูล)

ใช้เครื่องมือ / ซอฟ์ทแวร์

• มีหลายระบบที่รองรับการจัดทำกิจกรรมวิเคราะห์ความต้องการของระบบ

• ระบบทางตรง / ระบบสนับสนุน

• ฟรี / ไม่ฟรี

• สำหรับคอร์สเรียนนี้ ไม่ได้มุ่งเน้นการใช้เครื่องมือในการเก็บรวบรวมข้อมูล ท่านสามารถศึกษาเพิ่มเติมได้จากอินเตอร์เน็ท

Requirements Collection

Define what the system needs to do. Identify constraints and boundaries

Waterfall Model (โมเดลน้ำตก)

Agile Software Development (เอ[ะ]ไกล์)

Sprint

Mapping Requirements to Technical Descriptions

เชื่อมโยงความต้องการของระบบไปยังพิมพ์เขียวระบบ

• หลังจากรวบรวมข้อมูลและระบุความต้องการของระบบที่จะพัฒนาได้แล้ว กระบวนการต่อไปคือการการออกแบบโครงร่างระบบ เปรียบเสมือนกับพิมพ์เขียวของ บ้าน-อาคาร นั่นเอง

• เป็นการ สรุป-รวบยอด ข้อมูลจากขั้นตอนที่แล้ว เพื่อเตรียมพิมพ์เขียวระบบ และเริ่มทำการพัฒนาระบบในขั้นตอนต่อไป

• เราเริ่มต้นที่ Use Case

Use case

Use case

• Title - หัวข้อ ยกตัวอย่างเช่น

  • "Create a new trip"

  • "Add expense" หรือ "Convert currencies"

• Actor - ผู้คน/ระบบ มีบทบาทในระบบ

  • ผู้ใช้งาน ที่มีบทบาทในระบบ

  • สามารถเป็นระบบอื่น หรือโมดูลอื่น ที่มีส่วนร่วมในระบบก็ได้

Use case

Title

Short, descriptive use case title

Actor

User

ตัวอย่าง Scenarios

• The user can initiate the creation of a new trip from the main screen.

• The title is mandatory. All the other settings are optional.

• Optionally, the user can write a short description and set a start and end date for the trip.

• The app assigns a default home currency based on the phone's settings, users can override the default home currency with any of the supported currencies.

• The app allows setting a budget for the trip. The setting is optional.

• Also, the user can assign a custom thumbnail to a trip.

• The user can save the trip or cancel the trip creation process.

Create new trip

Actor: Mobile User

• ผู้ใช้สามารถสร้างแผนการเดินทางใหม่ได้จากหน้าจอหลัก

• ข้อมูล title เป็นข้อมูลสำคัญต้องกรอก ส่วนข้อมูลอื่นไม่บังคับกรอก

• ไม่บังคับ, ผู้ใช้สามารถใส่ข้อมูลบรรยายรายละเอียดการเดินทาง พร้อมระบุวันเริ่มต้นและวันสิ้นสุด ของแผนการเดินทางได้

• แอพจะเลือกสกุลเงินพื้นฐานเริ่มต้นโดยดึงข้อมูลจากสมาร์ทโฟนของผู้ใช้ อย่างไรก็ตาม ผู้ใช้สามารถเปลี่ยนค่าสกุลเงินพื้นฐานได้ตามต้องการ

• แอพอนุญาตให้ผู้ใช้งานระบุงบประเมินสำหรับแผนการเดินทาง (ไม่บังคับกรอก)

• ผู้ใช้สามารถเลือกรูปภาพประกอบแผนการเดินทางได้ (ไม่บังคับกรอก)

• ผู้ใช้สามารถบันทึกแผนการเดินทาง หรือยกเลิกการสร้างแผนการเดินทางได้

Use case

• สามารถเขียนในรูปแบบของกลุ่มข้อความ หรือรายการ

• พยายามหลีกเลี่ยงการใช้คำศัพท์เทคนิค

• เอกสาร Use Case ควรอ่านเข้าใจง่าย และเป็นมิตรกับผู้อ่าน แม้กระทั่งผู้ว่าจ้าง หรือบุคคลภายนอก

• ระบบทำอะไรได้ ? และใครคือผู้ทำ ? ทำอย่างไร ?

• Use case Diagram จะถูกพูดถึงอีกครั้งในหัวข้อถัดไป

User Stories

• Very brief description of a feature
  (ข้อมูลอธิบายฟีเจอร์ของระบบแบบกระชับ)

• อธิบายถึงฟีเจอร์หลักของระบบ

• User Stories มักสั้นกว่า Use Case โดยปกติ 1-2 ประโยค

• มักเขียนในรูปแบบประโยคดังนี้

User Stories

As a <type of user>, I want <some goal> so that <some reason>.

User Stories -- ตัวอย่าง

As a user, I want add notes to my expenses so that I can identify them later on.

User Stories -- ตัวอย่าง

As a power user, I want to retrieve the app's database file so that I can inspect it on any computer.

Epic

• Describe a bigger chunk of functionality. Should be split into smaller user stories.

• กรณีฟีเจอร์หลักของระบบมีข้อมูลกว้าง (เยอะ) เกินไป สามารถที่จะเขียนแบ่งเป็น User Stories มากกว่าหนึ่งได้

• ยกตัวอย่าง เช่น

"As a traveler, I want to track my expenses while abroad so that I don't exceed my budget."

Epic

As a traveler, I want to track my expenses while abroad so that I don't exceed my budget.

Epic

สำหรับนักท่องเที่ยว, ฉันต้องการดูรายละเอียดค่าใช้จ่ายขณะท่องเที่ยว เพื่อที่จะ ไม่ใช้จ่ายเกินงบประมาณ.

User Stories มักถูกใช้บ่อย ๆ สำหรับกิจกรรมระดมความคิดแบบ Stick Notes หรือ Index Cards ซึ่งสามารถพบเห็นได้จากบอร์ดระดมความคิดเห็น

ทำนองเดียวกันกับคำอธิบาย Use Case, User Stories ไม่สามารถหาได้จากคำอธิบายฟีเจอร์ของระบบ แต่มักใช้เพื่อก่อให้เกิดการ โต้เถียง/ระดม ความคิดของทีมพัฒนา (+ผู้ว่าจ้าง)

Why Do We Need a Common Descriptive Language ?

ทำไมเราจึงมีความจำเป็นต้องใช้ภาษาการออกแบบที่เป็นมาตรฐาน ?