Tôi được dạy vẽ sơ đồ trong UML để xem các tương tác giữa các lớp, đối tượng và người tham gia/hệ thống, v.v. Tuy nhiên, tôi đã nhìn thấy một số câu trả lời ở đây nói rằng UML là một công cụ tài liệu chứ không phải là một công cụ thiết kế.Nếu bạn không thiết kế trong UML, thì bạn thiết kế gì?
Bạn mô tả thiết kế đồ họa như thế nào nếu bạn không sử dụng UML?
Scott Ambler có great table on his website liệt kê tất cả các sơ đồ thường được sử dụng trên các dự án phần mềm, với các liên kết đến các ví dụ.
Tôi tìm thấy sơ đồ UML hữu ích nhưng liên tục bị làm phiền bởi tâm lý 'mỗi thứ một hộp'.
EDIT: Tôi có xu hướng tránh xa các công cụ tạo mô hình UML càng nhiều càng tốt, vì hành động tạo biểu đồ chính xác chắc chắn tạo áp lực để 'đánh bóng' nó cho đến khi nó trông giống như một sản phẩm chất lượng (bất kể giá trị là bao nhiêu trong sơ đồ).
Nó không giúp điều đó cho đến gần đây hầu hết các trình chỉnh sửa UML đã cung cấp rất ít trợ giúp trong các sơ đồ làm sạch, ví dụ: vẽ một đường thẳng giữa hai hộp và một 'kink' xuất hiện ở giữa bởi vì các phần tử không hoàn toàn nằm ngang. Tôi đã nhìn thấy các nhà phát triển giờ lãng phí chỉ cố gắng để có được tất cả các dòng ngang hoặc ở 45 độ. Trình chỉnh sửa yêu thích cá nhân của tôi là MagicDraw, nhưng Enterprise Architect dường như rất phổ biến nên tôi cũng sử dụng nó rất nhiều.
Khi tôi làm người mẫu bên trong nhóm, tôi sử dụng bản phác thảo giao diện người dùng UML + DFD + cho đến khi mọi người hài lòng, sau đó chụp ảnh kỹ thuật số và đăng lên trang web dự án. Nếu nó chứng minh rất hữu ích, nó có thể kéo dài đủ lâu để được 'chính thức hóa' - nhưng hầu hết thì không.
Tôi muốn mọi người (có thể bạn) mở rộng về vấn đề này. Những công cụ nào có sẵn để nắm bắt các sơ đồ này? Tôi hiện đang sử dụng StarUML, vì vậy tôi đang xem xét điều đó để xem liệu nó có thể nắm bắt các loại tài liệu khác không, nhưng tôi sẽ quan tâm để biết cách bạn hoặc những người khác nắm bắt các biểu đồ không phải là UML. –
Bảng bao gồm phần mềm nào được sử dụng. Tuy nhiên, tôi thấy rất ít trong danh sách cạnh tranh trực tiếp với UML; hầu hết các định dạng dường như là một phần của UML hoặc có tương tự trực tiếp trong UML. –
Tôi ghét sử dụng các công cụ UML cho đến khi tôi tìm thấy http://yuml.me/, nó cung cấp một số loại DSL để mô tả sơ đồ UML. Không có chuột-fiddleling nữa :-). – helpermethod
Tôi sử dụng các bản phác thảo UML nhanh như một công cụ thiết kế và sau đó biểu đồ UML đầy đủ được tạo từ mã dưới dạng tài liệu. Một sơ đồ UML đầy đủ, chính xác như thiết kế không thực sự khả thi (ít nhất là không đến UML là một ngôn ngữ lập trình đồ họa đầy đủ) vì vậy đây có vẻ là phương pháp tốt nhất cho tôi.
Vì vậy, bạn có một số loại sơ đồ UML (mặc dù có thể không đầy đủ) khi bạn bắt đầu hiển thị các lớp/diễn viên/hệ thống chính/Các hệ thống con và như vậy? –
Tôi có xu hướng sử dụng Bút (cil) và Giấy. Hoặc có thể Sticky Notes và Whiteboard, tùy thuộc vào độ phức tạp.
Bạn đặt gì trên các phương tiện này? Tôi đoán nó có phần UML như (mặc dù nó có thể không tuân theo mọi quy tắc trong sách UML của luật pháp) –
Hy vọng trợ giúp giải thích rõ ràng –
Có, nó có. –
Hộp và mũi tên trên giấy hoặc bảng trắng. Tất cả các lực lượng UML hành lý trên bạn là quá mức cần thiết trong nhiều tình huống, đặc biệt là ở giai đoạn đầu của thiết kế.
Tất nhiên có cấp độ, sau một vài lần lặp lại, khi nó bắt đầu hữu ích (và thậm chí cần thiết) thành tài liệu các quyết định trước đó chi tiết với định dạng chuẩn.
UML là công cụ tài liệu chứ không phải công cụ thiết kế.
Tôi sẽ gọi crap trên tuyên bố đó. UML là một ký hiệu thiết kế đã được chứng minh, cung cấp một lượng lớn độ sâu trên các biểu đồ khác nhau của nó và được chuẩn hóa. Thật tuyệt vời nếu bạn có một đội ngũ lớn và cần đảm bảo mọi người ở cùng một trang liên quan đến các quyết định kiến trúc.
Tôi đoán bất kỳ ai đưa ra tuyên bố đó đơn giản là mệt mỏi với UML, không hiểu cách sử dụng nó, hoặc cả hai.
Đối với bất cứ ai đang cung cấp phiếu chống tiêu cực cho phản hồi của tôi, hãy tự bảo vệ mình bằng cách thêm một bình luận – Huuuze
Tôi đã không downvoted bạn, nhưng tôi muốn biết theo cách nào UML là một "phương pháp thiết kế"? –
Bạn nói đúng, sự nhiệt thành của tôi để đăng dẫn tôi đến sử dụng sai cụm từ – Huuuze
UML là ngôn ngữ giao tiếp. Khi mọi người nói rằng họ sử dụng hộp và mũi tên trên giấy, họ đang sử dụng UML hoặc họ đang sử dụng một cái gì đó họ phải giải thích cho bất cứ ai họ đang nói chuyện với.
Nếu họ chỉ nói chuyện với bản thân, thì có lẽ họ không nên làm thiết kế - thiết kế cần đa dạng di truyền nếu nó không bị hỏng não, tôi không quan tâm đến kiến trúc sư giỏi như thế nào .
tôi sử dụng thẻ CRC: http://en.wikipedia.org/wiki/Class-Responsibility-Collaboration_card
Một số từ tuyệt vời về công nghệ phần mềm, bởi Richard Feynman, có thể được tìm thấy here. Thực sự là một bài học để lấy bằng trái tim ...
EDIT: di chuyển ramblings của tôi dưới đây ... tốt hơn để lắng nghe Feynman! :)
IMHO có nhiều lựa chọn thiết kế không được UML phân phối.
UML là tốt khi không phải là quá mức cần thiết! Có thể một số phác thảo nhanh là bước đầu tiên, được tinh chỉnh sau để trở thành UML hoàn chỉnh.
Vui lòng không giải thích phương pháp từ trên xuống mà UML (có xu hướng) khuyến khích quá nhiều (IMHO một lần nữa).
Tôi bắt đầu với bảng trắng, sau đó tôi di chuyển đến GraphViz khi thiết kế đã ổn định. Thật dễ dàng để chia sẻ nguồn với những người khác để kiểm tra ý tưởng thay thế hoặc làm rõ vai trò.
Sau đó, bạn có thể giữ một bản sao của nguồn graphviz mở trong trình soạn thảo của bạn và tinh chỉnh sơ đồ khi bạn đi để giữ các chi tiết hiện tại bằng mã của bạn.
Tôi thấy hữu ích khi nghĩ về các kiểu kiến trúc được mô tả trong sách như this khi tôi thiết kế dự án.
Tôi nghĩ hầu hết mọi người bắt đầu bằng cách vẽ biểu đồ dạng tự do về cơ bản là UML, nhưng không phải là cứng nhắc hoặc được xác định rõ.
Nếu sơ đồ cần tiến triển ngoài giai đoạn này, thì chúng có thể được chuyển thành biểu đồ UML phù hợp tuân thủ tất cả các quy tắc.
Tôi đã thấy rất ít lựa chọn thay thế cho sơ đồ UML. Hầu hết trong số họ có vẻ là các định dạng cũ hơn, có định dạng kế thừa trực tiếp trong UML.
(BTW Tôi hoàn toàn từ chối luôn viết "UML" theo những cách câu mangling!)
Tôi sẽ gọi các sơ đồ tư duy của biểu đồ dạng tự do '. – slashmais
Một giấy và một cây bút chì
Tôi thường cố gắng để bắt đầu với một phác thảo đơn giản trên một mảnh giấy bởi vì khi tôi xây dựng thiết kế, tôi thấy rằng mọi thứ thường được trang bị tốt hơn ở nơi khác và viết nó xuống sẽ giúp tôi nhớ nó tốt hơn sau này.
Tôi không luôn điền các loại ngay từ đầu vì tôi không phải lúc nào cũng biết những gì tôi cần (ví dụ: boolean cho hộp kiểm hoặc enum cho hộp kiểm tri-state).
Sau khi thiết kế cơ sở của tôi, tôi có xu hướng thực hiện các lớp học và các kết nối sau đó xác thịt ra chi tiết về một lớp thẻ chỉ mục bằng lớp trước khi làm bất kỳ việc thực hiện thực
Điều bạn mô tả là giai đoạn thiết kế và phân tích thô. Tôi đang tìm kiếm các công cụ sẽ hỗ trợ chính xác điều đó - xem câu hỏi của tôi và có thể một số guru sẽ xuất hiện và chỉ cho chúng tôi các công cụ. – slashmais
Tôi đọc ở đâu đó rằng mọi người sẽ phác thảo với sau đó ghi chú, nhưng không được phép thực sự viết bất cứ thứ gì lên chúng, và khi thiết kế trở nên phức tạp đến nỗi bạn không thể nhớ nó không phải là lớp/mô-đun/kiến trúc nào thì nó sẽ cần được đơn giản hóa.
Tôi nghĩ rằng gọn gàng. Cá nhân tôi sử dụng biểu đồ trình tự và lớp UML-esque. Real UML chỉ là quá nhiều công việc, theo ý kiến của tôi.
Trong kinh nghiệm cá nhân của tôi, mã với vài lớp là mã được đóng gói không đúng. –
Nghe có vẻ điên rồ! Tôi nghĩ rằng tôi sẽ bị mắc kẹt với một hệ thống chỉ có 5 lớp nếu tôi sử dụng nó;) – UpTheCreek
Vấn đề là đóng gói chức năng trong một trong những "mô-đun" sau đó. Họ không lập bản đồ 1-to-1 với các lớp, chúng chỉ là các gói đóng gói logic. Nguyên tắc thiết kế cơ bản là phân chia hệ thống thành 3-5 phần và mô hình hóa tương tác của chúng, sau đó đi sâu vào từng phần và tương tự. Bạn đệ quy làm điều này cho đến khi bạn hoàn thành. Đây cũng là thực hành tiêu chuẩn của UML (sơ đồ gói và những gì không). Thật ngớ ngẩn khi nghĩ rằng toàn bộ hệ thống có thể phù hợp với một sơ đồ lớp đơn, ngay cả với tên/nhãn! –
Ký hiệu quirky tùy chỉnh của riêng tôi. hộp cho các khối dữ liệu cho dù mảng, tệp vv Các ý tưởng sơ sài cho các lớp chỉ là tên lớp với các thành viên và các phương thức được viết bên dưới. Tôi xử lý phần cứng thường xuyên, vì vậy hệ thống thu thập dữ liệu ngồi trong một chiếc xe trải qua một thử nghiệm chỉ là một bản vẽ nhỏ dễ thương của một chiếc xe hơi. Duh, đơn giản!
Có một thứ trông chừng nĩa - một sản phẩm bò - chỉ ra khi một thứ kích động hành động khác hoặc điều khiển hoạt động của nó. Các mũi tên cho luồng dữ liệu, đôi khi đi qua hoops chỉ ra quy định, hướng dẫn, chuyển hướng dữ liệu đó.
Tôi sử dụng các mũi tên thuộc loại được sử dụng trong UML để biểu thị thừa kế lớp. Đó là điều duy nhất tôi lấy trộm từ UML. (Dù tôi đã sử dụng gì trước khi tôi gặp UML?) Nền của tôi là thiết bị điện tử, vì vậy ký hiệu cá nhân của tôi có thể dựa trên việc xem sơ đồ khối của radio và TV như một đứa trẻ.
Tôi may mắn rằng khoảng 90% công việc của tôi là solo, mã nguồn hoàn toàn theo lệnh của tôi, chỉ cho các phiên bản hoàn chỉnh hoặc thử nghiệm của các tệp thi hành cho người khác. Nếu tôi ở trong một tập đoàn lớn, tôi sẽ nhận được rất nhiều ngoại hình kỳ lạ, giống như một con quái vật xiếc!
Trước đó, tôi đã sử dụng Excel đơn giản để làm sơ đồ và quy trình xử lý của mình. Rất dễ dàng và vô nghĩa. Bây giờ, tôi thường sử dụng các công cụ đáng tin cậy hơn như Visio, StarUML, Creately và Lucidchart để làm sơ đồ của tôi.
Tại sao không làm như hầu hết mọi người, mã đầu tiên, thiết kế sau? : P – davr
Vì tôi là kỹ sư phần mềm và thích làm theo một số quy trình kỹ thuật. Mặc dù tôi thích các phương pháp nhanh nhẹn với thiết kế tối thiểu ở phía trước. Tôi không phải là fan của BDUF. Nó thường kết thúc lên trên khuôn mặt của bạn. –
Bah, bạn đã không nghe nói về 'một tuần giá trị của mã hóa sẽ giúp bạn tiết kiệm một giờ thiết kế' như justsification cho 'mã đầu tiên, thiết kế sau'? :) – workmad3