From sre@jrcase.mq.edu.au Sun Feb 13 19:02:12 2000 Originator: sre@jrcase.mq.edu.au Sender: sre@jrcase.mq.edu.au From: Patricia Ferdinandi To: Multiple recipients of list Subject: [SRE:2164] RE: How to Do OOA? RJLRef: ~/how2doOOA.2k0214 I agree with this approach. In fact, I have been known to draw diagrams during facilitation sessions. Every time I've done this approach, the users start drawing the diagrams for me on the white board! At 10:45 PM 2/13/00 +1100, you wrote: > > From: "Manhaeve Hendrik 557052008"@dishwasher1.mpce.mq.edu.au >.. > > Data are indeed very important in requirements and systems design, but in > > my opinion there is more: > > > > functions are requested by the user(describing tasks they want to > perform)and > > these functions are implemented by the functionality of the system. > > > > Users don't think like we do (and we are both right, but using a different > > perspective). The data and the relationships needed for the system are > not the > > same as those of the user. E.g. we could state a product is associated > to an > > order (by the orderlines), the user however will not percieve this as an > > association but the product becomes a part of the order (the difference is > > mainly induced by the abstraction we use and which the users do not > use). For > > the user data has always a context to have value, for us data havetheir > merits > > on their own. > >I doubt that users won't understand that a line item is-part-of an order, >and that line items contain product id numbers (references) and quantity- >ordered, not concrete parts. The fault may lie in the analyst's use of the >OODB 'set-of' abstraction or the ERD abstraction called association or >associative entity to describe the line item content, instead of explicitly >modeling line items as instances of a separate concrete but old-fashioned >relational table or entity class in a normalized data model. Or perhaps >it lies with UML's T-shaped non-digraph-model for an attributed association >'edge' when they could have simplfied all such conglomerations as associative >entities and done away altogether with many:many relations, attributed or not. > >Tom Demarco's circa 1982 Structured Analysis and Design said it this way: >let the users see that you refer to ERD's and DFD's (now replaced by >class diagrams, Use Cases, Sequence Diagrams and State Charts in UML) >without trying to explain them. Gradually entice the onlookers' >curiosity until they become converts to understanding that there is >a static information model basis that underpins the dynamic transaction >analysis that you both need to come up with from use cases and more. > > > So at this point use case are of great value because they make clear > how the > > user will use the system and what actions(transactions) will change or > request > > data. The user cases are providing the users context. Users do not work > with > > 'normalized' data but with clusters and the only relationships they > know are > > inheritance and part of. > >But why should they need to know about inheritance? And how can they >avoid discussing other binary associations besides containment? >(Or are these 'clusters'? >Part-of decomposition and non-aggregated associations would get my vote >as the two key relationships to verify with the users during analysis, >with inheritance as a deferred (but shared) design-time responsibility. > > > > > In my opinion this difference is a major factor in the mis-communication > > between systems people and real users and during requirements we should > take > > their side and not the systems side (after all we are developing > systems for > > them, aren't we). > > > >Mea culpa - I admit to having spoken like a systems person - >most of my 'users' are [student] SW engineers :-( > >Bob Lechner >CS Dept, UMass-Lowell >lechner@cs.uml.edu