Decoding Object Class Design: Assumptions and Relationships in Requirements Handling

1. What’s Behind The Objects? COMS 103 section 4 25 January, 1999

2. What’s behind the objects? • An object class may not show all the designer was thinking • Assumed behaviors may be present, e.g.: • either attribute A or attribute B will have a value, but never both. • If attribute A is non-zero, then attribute B will point to a C object, otherwise a D object.

3. What’s behind the objects? • Out “Requirement” object class has lots of assumptions about how it is to be used. • course and requirementList objects are mutually exclusive. That is, exactly one of them will have meaningful information within any one Requirement instance. • There is a “recursive” definition in the requirementList

4. Design Quality • Compact • Minimum “assumptions” • Minimum attr. relationships/dependencies • Minimum “outside” knowledge needed • Naturally supports typical application operations.

5. Requirement course requirementList minimumNumber minimumGPA Mutually Exclusive Attributes • Any instance of Requirement will have either a courseor a requirementList Mutually Exclusive

6. Requirement #1 course == COMS102 requirementList == NULL minimumNumber == 1 minimumGPA = 2.0 Simple Requirement • Capture COMS 102 as a pre-requisite to COMS 103 • Note that “instances” are not UML COMS 103 pre-requisite COMS 102

7. Requirement #3 course == MATH 180 requirementList == NULL minimumNumber == 1 minimumGPA = 1.0 Requirement #2 course == MATH 121 requirementList == NULL minimumNumber == 1 minimumGPA = 1.0 More Complex Example • Capture major entrance requirements • This has an or relationship (Math 180 or Math 121) Requirement #1 course == NULL requirementList: Req #2, Reg #3 minimumNumber == 1 minimumGPA == 1.0

8. More Complex Example (cont) Requirement #2 requirementList: Req #4, Req #5 minimumNumber == 2 minimumGPA == 2.5 Requirement #3 requirementList: Req #6, Req #7 minimumNumber == 1 minimumGPA == 1.0 Req. #6 course = MATH121 Req. #7 course = MATH180 Req. #4 course = COMS102 minGPA == 2.0 Req. #5 course = COMS103 minGPA == 2.0 • We will Abbreviate instances: minNum is one, minGPA is 1.0, unless otherwise given Requirement #1 requirementList: Req #2, Req #3 minimumNumber == 2

9. Req. #11 COMS462 Req. #13 COMS350 Req. #15 COMS340 Req. #7 COMS371 Req. #9 COMS230 Req. #14 COMS450 Req. #16 COMS440 Req. #12 COMS463 Req. #10 COMS430 Req. #8 COMS481 A Very Complex Example Requirement #1 requirementList: Req #2, Req #3, Req #4, Req #5, Req #6 minimumNumber == 2 • This example captures “2 of the following sequences” Req. #2 RL == R#7, R#8 Req. #3 RL == R#9, R#10 Req. #4 RL == R#11, R#12 Req. #5 RL == R#13, R#14 Req. #6 RL == R#15, R#16

10. Code Implications of UML • Each relationship type affects the Java code in its own way. • We’ll look at the four relationship types on two object classes A and B • The cardinality also affects the code.

11. Code For Associations • Affects both classes A and B • Cardinality determines whether the variable is scalar (non-array) or an array. class B { // methods private A aPointer; } class A { // methods private B bPointer; } class A { // methods private B[] bCollection = new B[100]; }

12. Code For Dependency • Assume A B • Note that A will have at least one method that invokes at least one method in B class A { // methods private B bPointer; } class B { // methods public void method(); }

13. A B Code For Aggregate • There may be code in both objects • Suppose: 1 n class A { // methods private B[] bSet = new B[25]; } class B { // methods private A aPointer; } (Optional)

14. Code For Inheritance A B • Suppose: class B extends A{ // specializations } class A { // methods void aMethod(); // attributes } B bValue = new B; bValue.aMethod();