การแม็พระหว่างโมเดลมุมมองสถาปัตยกรรม 4 + 1 และ UML


15

ฉันสับสนเล็กน้อยเกี่ยวกับรูปแบบสถาปัตยกรรมมุมมอง 4 + 1 จับคู่กับ UML

Wikipediaให้การแมปต่อไปนี้:

  • มุมมองเชิงตรรกะ:แผนภาพคลาส, แผนภาพการสื่อสาร, แผนภาพลำดับ
  • มุมมองการพัฒนา:แผนภาพส่วนประกอบ, แผนภาพแพคเกจ
  • มุมมองกระบวนการ:แผนภาพกิจกรรม
  • มุมมองทางกายภาพ:แผนภาพการปรับใช้
  • สถานการณ์จำลอง:แผนภาพการใช้เคส

กระดาษบทบาทของ UML แผนภาพลำดับ Constructs ในวัตถุ Lifecycle แนวคิดจะช่วยให้การทำแผนที่ต่อไปนี้:

  • มุมมองเชิงตรรกะ (แผนภาพคลาส (CD), วัตถุแผนภาพ (OD), แผนภาพลำดับ (SD), แผนภาพความร่วมมือ (COD), แผนภาพสถานะของรัฐ (SCD), แผนภาพกิจกรรม (AD))
  • มุมมองการพัฒนา (แผนภาพแพคเกจแผนภาพส่วนประกอบ)
  • มุมมองกระบวนการ (ใช้แผนภาพกรณี, CD, OD, SD, COD, SCD, AD)
  • มุมมองทางกายภาพ (แผนภาพการปรับใช้) และ
  • ใช้มุมมองกรณี (ใช้แผนภาพกรณี, OD, SD, COD, SCD, AD) ซึ่งรวมสี่มุมมองดังกล่าวข้างต้น

หน้าเว็บUML 4 + 1 ดูเนื้อหานำเสนอการทำแผนที่ต่อไปนี้:

UML 4 + 1 ดูวัสดุ

ในที่สุดกระดาษสีขาวที่ใช้ 4 + 1 View Architecture กับ UML 2จะให้การจับคู่อื่น:

  • ไดอะแกรมคลาสมุมมองเชิงตรรกะไดอะแกรมวัตถุแผนภูมิสถานะและโครงสร้างประกอบ
  • แผนภาพลำดับการดูกระบวนการไดอะแกรมการสื่อสารไดอะแกรมกิจกรรมไดอะแกรมกำหนดเวลาไดอะแกรมภาพรวมการโต้ตอบ
  • การพัฒนาแผนภาพองค์ประกอบมุมมอง
  • แผนภาพการปรับใช้มุมมองทางกายภาพ
  • ใช้มุมมองเคสใช้ไดอะแกรมเคสแผนภาพกิจกรรม

ฉันแน่ใจว่าการค้นหาเพิ่มเติมจะเปิดเผยการแมปอื่นเช่นกัน

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

คุณช่วยอธิบายความสับสนให้ฉันหน่อยได้ไหม?

คำตอบ:


18

แม้ว่าโดยทั่วไปแล้วฉันจะเห็นด้วยกับคำตอบของ Bart van Ingen Schenauแต่ฉันคิดว่าจุดสองสามจุดนั้นต้องมีรายละเอียดเพิ่มเติม

ประโยชน์ที่ได้จากโมเดลการดู 4 + 1 คือการแมปผู้มีส่วนได้ส่วนเสียกับประเภทของข้อมูลที่ต้องการโดยไม่ต้องใช้สัญลักษณ์การสร้างแบบจำลองเฉพาะ โดยเน้นที่การสร้างความมั่นใจว่าทุกกลุ่มมีข้อมูลเพื่อทำความเข้าใจระบบและทำงานต่อไป

รูปแบบสถาปัตยกรรมซอฟต์แวร์ของ 4 + 1 View ได้อธิบายไว้ในพิมพ์เขียวทางสถาปัตยกรรมของ Philippe Kruchten - "4 + 1" View Model of Architeture ของซอฟต์แวร์ที่เผยแพร่ครั้งแรกในซอฟต์แวร์ IEEE (พฤศจิกายน 1995) เอกสารนี้ไม่ได้อ้างอิงเฉพาะ UML ในความเป็นจริงกระดาษใช้สัญกรณ์ Boochสำหรับมุมมองตรรกะส่วนขยายไปยังสัญกรณ์ Booch สำหรับมุมมองกระบวนการและมุมมองการพัฒนาเรียกใช้ "หลายรูปแบบ" ในการพัฒนามุมมองทางกายภาพและสัญกรณ์ใหม่สำหรับสถานการณ์

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

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

มุมมองกระบวนการถูกออกแบบมาสำหรับผู้ออกแบบระบบทั้งหมดและรวมระบบย่อยหรือระบบเข้ากับระบบของระบบ มุมมองนี้แสดงงานและกระบวนการที่ระบบมีส่วนต่อประสานกับโลกภายนอกและ / หรือระหว่างส่วนประกอบภายในระบบข้อความที่ส่งและรับและวิธีการปฏิบัติงานความพร้อมใช้งานความพร้อมรับข้อผิดพลาดและความสมบูรณ์

มุมมองการพัฒนานั้นใช้สำหรับนักพัฒนาที่จะสร้างโมดูลและระบบย่อย ควรแสดงการพึ่งพาและความสัมพันธ์ระหว่างโมดูลวิธีการจัดระเบียบโมดูลการใช้ซ้ำและการพกพา

มุมมองทางกายภาพนั้นมีไว้สำหรับผู้ออกแบบระบบและผู้ดูแลระบบที่ต้องเข้าใจตำแหน่งทางกายภาพของซอฟต์แวร์การเชื่อมต่อทางกายภาพระหว่างโหนดการปรับใช้และการติดตั้งและความสามารถในการปรับขยาย

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

เมื่อคุณเข้าใจว่าแต่ละมุมมองควรให้อะไรคุณสามารถเลือกสัญลักษณ์การสร้างแบบจำลองที่จะใช้และระดับรายละเอียดที่จำเป็น ย่อหน้าสุดท้ายของ Bart นั้นเป็นเรื่องจริงโดยเฉพาะ - คุณสามารถแสดงรายละเอียดในระดับต่างๆในโมเดล UML ของคุณโดยเน้นไปที่องค์ประกอบการออกแบบเฉพาะหรือการรวมไดอะแกรมชนิดต่าง ๆ ไว้ในชุด นอกจากนี้คุณอาจต้องการที่จะต้องพิจารณาไปเกินกว่า UML ในการสร้างแบบจำลองสัญลักษณ์อื่น ๆ ที่ดีกว่าการอธิบายสถาปัตยกรรมระบบของคุณ - SysML , การสร้างแบบจำลอง Entity-ความสัมพันธ์หรือIDEF


The logical view is designed to address the end user's concerns about ensuring that all of their desired functionality is captured by the system. In an object-oriented system, this is often at the class level. คุณไม่พบหรือว่าถ้าเราต้องการทำบางสิ่งบางอย่างสำหรับผู้ใช้อย่างน้อยที่สุดเราต้องสื่อสารกับพวกเขาและพูดภาษาเดียว ลองแสดงแผนภาพคลาสของคุณต่อผู้ใช้ของคุณและมาดูกันว่าพวกเขาจะพูดอะไร
พาเวล

1
@ JimJim2000 ฉันไม่ได้บอกว่ามันเป็นสำหรับผู้ใช้ปลายทาง หากคุณมีชุดของข้อกำหนดและคุณจับคู่กับองค์ประกอบในมุมมองแบบลอจิคัลคุณสามารถมั่นใจได้ว่ามีส่วนประกอบ (แพ็คเกจคลาสฟังก์ชั่น) ที่ได้รับการออกแบบมาเพื่อตอบสนองความต้องการแต่ละข้อ ฉันไม่สามารถนึกถึงโมเดลจำนวนมากจากภาษาการสร้างแบบจำลองใด ๆ ที่ฉันจะแสดงต่อผู้ใช้ปลายทางและคาดหวังให้พวกเขาได้รับ อาจเป็นแผนภาพกิจกรรมจาก UML
โธมัสโอเวนส์

9

เหตุผลที่คุณไม่สามารถค้นหาการทำแผนที่แบบหนึ่งต่อหนึ่งระหว่างมุมมองของแบบจำลองสถาปัตยกรรม 4 + 1 และไดอะแกรม UML ต่างๆได้เนื่องจากการทำแผนที่ดังกล่าวไม่มีอยู่

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

นอกจากนี้ไดอะแกรม UML บางตัวสามารถใช้ในรูปแบบที่แตกต่างกันโดยเน้นองค์ประกอบต่าง ๆ ในแผนภาพซึ่งทำให้มีประโยชน์สำหรับหลายมุมมอง แต่แม้ว่าจะสามารถใช้ชนิดแผนภาพ UML ได้หลายมุมมอง แต่คุณสามารถวาดไดอะแกรมต่าง ๆ (หรือชุดไดอะแกรม) สำหรับแต่ละมุมมองได้


2

แม้ว่าฉันจะเห็นด้วยกับThomas Owens คำตอบสำหรับวิธีการตอบสนองความต้องการของผู้ใช้ของคุณสิ่งหนึ่งที่ล้มเหลวที่จะกล่าวถึงคือเหตุผลที่นิยามเดิมของ"4 + 1 ดูแบบจำลองสถาปัตยกรรม" โดย Kruchtenไม่ได้ทำ การอ้างอิงที่เฉพาะเจาะจงเพื่อ UML เป็นเพราะบทความที่เขียนขึ้นในปี 1995 (เป็นคำตอบของรัฐ) แต่ UML ไม่ได้ถูกนำมาใช้จริงๆเป็นมาตรฐาน1997 จนกระทั่ง

การใช้ Booch Notation อย่างต่อเนื่องในบทความแสดงให้เห็นว่าการเชื่อมโยงแต่ละมุมมองของแบบจำลองกับแผนภาพ UML นั้นมีความเหมาะสมเนื่องจาก Grady Booch เป็นหนึ่งในผู้ที่เกี่ยวข้องในการพัฒนา UML

เป็นเพราะเหตุนี้ผู้เขียนหลายคนจึงคิดว่าไดอะแกรม UML ที่แตกต่างกันสามารถนำไปใช้กับแต่ละมุมมองได้เนื่องจากไดอะแกรม UML หลายรายการอาจถูกพิจารณาในจำนวน "abstractions" ของสัญกรณ์ Booch ที่นิยามดั้งเดิมของโมเดล 4 + 1 อาศัย เพื่อเป็นตัวแทนของแต่ละมุมมอง

หวังว่านี่จะเป็นการล้างสิ่งต่าง ๆ อีกเล็กน้อยสำหรับคนอื่น ๆ ที่กำลังมองหาสิ่งนี้


1

คุณยังใช้ VCR ที่คุณซื้อคืนในปี 1995 หรือไม่? 4 + 1 สามารถใช้งานได้เมื่อซอฟต์แวร์อยู่ในช่วงเริ่มต้น แต่ถึงอย่างนั้นก็ไม่มีใครเคยใช้มุมมองมากกว่า 2 หรือ 3 ครั้ง ในช่วง 20 ปีที่ผ่านมาวิศวกรรมซอฟต์แวร์เปลี่ยนแปลงไป ทุกวันนี้ขอบเขต / บริบทและแนวคิดและตรรกะและกายภาพและ ... ล้วนแตกต่างกัน โซลูชัน COTS จำนวนมากต้องถูกรวมเข้าด้วยกันและอื่น ๆ วันนี้เรากำลังพูดถึงแผนที่ภูมิประเทศการให้บริการและมุมมองและมุมมองอื่น ๆ อีกมากมาย วิธีที่ดีที่สุดในการมองผ่านกรอบภาษีแบบง่าย ๆ เช่น Zachman: 6 views และ 6 viewpoint ปล่อยให้เป็นจุดเริ่มต้นของคุณ มุมมอง 6 มุมมองคือ: แนวคิดเชิงบริบทหรือเชิงตรรกะทางธุรกิจหรือการจัดส่งทางกายภาพหรือเทคโนโลยี

6 มุมมองคือ: ข้อมูลหรือฟังก์ชั่นอะไรหรืออย่างไรเครือข่ายหรือที่ไหนผู้คนหรือใครเวลาหรือเมื่อแรงจูงใจหรือทำไม

ลองดูตัวอย่าง หากเราสนใจเฉพาะข้อมูลเราจะเริ่มต้นด้วยมุมมองขอบเขตและพูดว่า "ขอบเขตของเราคือ CRM" ในมุมมองแนวคิดสำหรับมุมมองข้อมูลเราจะสร้างโมเดลความหมายสำหรับ CRM รูปแบบจะเป็นแนวคิดแนวคิดข้อมูลธุรกิจมากกว่าวัตถุข้อมูล ต่อไปในมุมมองเชิงตรรกะเราจะสร้างแบบจำลองข้อมูลเชิงตรรกะจากแบบจำลองแนวคิดของ CRM เราอาจใช้วิธีการ ER เพื่อสร้างแบบจำลองข้อมูลเชิงตรรกะ จากนั้นในมุมมองทางกายภาพเราจะสร้างแบบจำลองข้อมูลทางกายภาพ ที่นี่เราจะกำหนดชนิดข้อมูลที่เป็นรูปธรรมสำหรับแพลตฟอร์ม db ที่เราเลือกดัชนีและอื่น ๆ สุดท้ายในมุมมองการนำส่งเราจะมีสคริปต์ DDL ของเราในมุมมองขององค์กรที่ใช้งานได้เราจะมีไฟล์ไบนารีติดตั้งในเซิร์ฟเวอร์ฐานข้อมูลบางตัว และแมปเข้ากับโครงสร้างข้อมูลภายในของผู้ขาย DBMs เราทำสิ่งนี้ซ้ำสำหรับทุกมุมมองหรือคอลัมน์ นอกจากนี้หากมีผู้มีส่วนได้ส่วนเสียมากกว่าหนึ่งคนเราจะสร้างแบบจำลองมากกว่าหนึ่งแบบสำหรับแต่ละมุมมอง / ชุดค่าผสมการดู ตอนนี้คุณมี taxonomy นี้แล้วคุณสามารถกำหนดมุมมองและมุมมองของคุณเองและจัดแนวเหล่านี้เป็น taxonomy นี้ ตัวอย่างเช่นสำหรับการริเริ่มระดับองค์กรมุมมองต่อไปนี้เป็นสิ่งสำคัญ: นักแสดงพฤติกรรมการทำงานร่วมกันของแอปพลิเคชันแอพลิเคชันความร่วมมือแอพลิเคชันโครงสร้างการใช้งานฟังก์ชั่นทางธุรกิจกระบวนการทางธุรกิจ ตอนนี้คุณมี taxonomy นี้แล้วคุณสามารถกำหนดมุมมองและมุมมองของคุณเองและจัดแนวเหล่านี้เป็น taxonomy นี้ ตัวอย่างเช่นสำหรับการริเริ่มระดับองค์กรมุมมองต่อไปนี้เป็นสิ่งสำคัญ: นักแสดงพฤติกรรมการทำงานร่วมกันของแอปพลิเคชันแอพลิเคชันความร่วมมือแอพลิเคชันโครงสร้างการใช้งานฟังก์ชั่นทางธุรกิจกระบวนการทางธุรกิจ ตอนนี้คุณมี taxonomy นี้แล้วคุณสามารถกำหนดมุมมองและมุมมองของคุณเองและจัดแนวเหล่านี้เป็น taxonomy นี้ ตัวอย่างเช่นสำหรับการริเริ่มระดับองค์กรมุมมองต่อไปนี้เป็นสิ่งสำคัญ: นักแสดงพฤติกรรมการทำงานร่วมกันของแอปพลิเคชันแอพลิเคชันความร่วมมือแอพลิเคชันโครงสร้างการใช้งานฟังก์ชั่นทางธุรกิจกระบวนการทางธุรกิจ

Krutchen 4 + 1 ไม่สามารถตอบสนองความต้องการเหล่านี้ทั้งหมดได้


3
คำตอบนี้มีอคติมากและฉันไม่เห็นด้วยกับเหตุผลของคุณว่าเพราะเหตุใด Kruchten 4 + 1 จึงเก่าเกินไป 20 ปีก่อนคือปี 1999 ซอฟต์แวร์ไม่ได้อยู่ในช่วงเริ่มต้น Kruchten ยังพูดถึงความเกี่ยวข้องของ 4 + 1 โดยเฉพาะในสภาพแวดล้อมที่คล่องตัว มีเหตุผลมุมมองและมุมมองที่มีอยู่ในมาตรฐาน IEEE เกี่ยวกับคำอธิบายสถาปัตยกรรม
Zimano
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.