tag:blogger.com,1999:blog-7879107.post113526652465529338..comments2023-12-08T01:42:31.590-06:00Comments on Cauvin: Alternative to CRUDRoger L. Cauvinhttp://www.blogger.com/profile/08969779835314260680noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-7879107.post-1135730301009916972005-12-27T18:38:00.000-06:002005-12-27T18:38:00.000-06:00Scott, I think your idea about "composition" is pa...Scott, I think your idea about "composition" is part of the solution.<BR/><BR/>As my post suggests, I would express the larger functional requirement as an on-going, end-to-end use case. (I would just give the name of the use case, the actor, and any needed explanation. A use case diagram with notes often suffices) Then I would attach constraints to that functional requirement.<BR/><BR/>If I considered it important to convey the fact that CRUD-style administration would likely be part of the design, I would depict some use case "composition". For example, I might show that the Pay Employees use case includes a Manage Payroll use case, which in turn includes CRUD use cases. But I would explicitly label these lower-level use cases - and the <<include>> relationships - as a design example or suggestion.<BR/><BR/>Ideally, a product designer or architect documents these use cases instead.Roger L. Cauvinhttps://www.blogger.com/profile/08969779835314260680noreply@blogger.com