1 / 14

What’s Behind The Objects?

What’s Behind The Objects?. COMS 103 section 4 25 January, 1999. 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.

tivona
Télécharger la présentation

What’s Behind The Objects?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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();

More Related