DOC PREVIEW
UT Dallas CS 6359 - S8_Chapters9-31_2

This preview shows page 1-2-3-18-19-36-37-38 out of 38 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 38 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 38 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 38 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 38 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 38 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 38 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 38 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 38 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 38 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Slide 1What will we learn?Refining Domain Models: Super and Sub ClassesSuper- and Sub-ClassesSuper and Sub ClassesRefining Domain Models: Super and Sub ClassesSub-Classes: When to DefineSuper- and Sub-Classes: When to CreateSuper-Classes: When to DefineExample: Payment Sub-ClassesSlide 11Domain Models: Levels of GranularitySlide 13Slide 14Abstract Conceptual ClassesModeling State ChangesExample: Modeling State ChangesAssociation ClassesExample: An Association ClassAssociation Classes – When to AddAggregation and CompositionExamples: Aggregation and CompositionAggregation and CompositionExamples: Composition in NextGen POSAssociation Role NamesQualified AssociationsPackagesPackagesPackagesPartitioning the Domain ModelNextGen POS – Domain ModelNextGen POS: Core/Misc PackageSlide 33Slide 34Slide 35Slide 36Takeaways from Chapters 9 and 31Next …Object-Oriented Analysis and DesignCHAPTERS 9, 31: DOMAIN MODELS1What will we learn?Refining the Domain Model2Refining Domain Models: Super and Sub ClassesRecall that once the initial Domain Model has been created, it may be enhanced in future iterations as more details are added to use cases, or our understanding of the system under development increasesEarly iterations tend to be high level, but more details are added in laterWe saw that as use case scenarios are extended, it may make sense to collect several conceptual classes together to form a super-class, with individual sub-classesA conceptual super-class definition is more general or encompassing than a subclass definitionAll members of a conceptual subclass set are members of their superclass set3Super- and Sub-Classes4CashPaymentCreditPaymentCheckPaymentPaymentamount : MoneyPaymentCashPayment CreditPayment CheckPaymentSuper and Sub ClassesAll statements about the super-class apply to any sub-classes; in other words, 100% of the super-class definition applies to the sub-classThe sub-class must conform to the attributes and associations of the super-classA Credit Payment pays-for a Sale. A Check Payment has an amount5CashPaymentCreditPaymentCheckPaymentPaymentamount : MoneySalePays-for11Refining Domain Models: Super and Sub ClassesCan think of the “sub-class as being a kind of super-class”A Credit Payment is a kind of PaymentOften shortened to: A Credit Payment is a PaymentWe can identify sub-classes by these two rulesThe 100% - all the super-class definition applies to the sub-classThe “is a” rule – the sub-class is a kind of super-class Any sub-class of a super-class must obey these rules6Sub-Classes: When to DefineOccasionally a super-class is created to capture similar sub-classes, but usually the process works the other way: A more general super-class has been defined, and as the iterations proceed, sub-classes are created to handle more detailed scenariosGuidelines: Create a sub-class when …The class under consideration “is a” kind of an existing super-classThe class under consideration has additional attributes of interestThe class under consideration has additional associations of interestThe class under consideration is operated on, handled, reacted to, or manipulated differently than the super-class (or other subclasses)The class under consideration represents an actor that behaves differently than the super-class or other sub-classes7Super- and Sub-Classes: When to Create8 Bad example: When would this make sense? Market research model, where there are behaviors of male and female shoppers that are different Medical research, since men and women are different biologicallyMaleCustomerFemaleCustomerCustomerCorrect subclasses.But useful?Super-Classes: When to DefineThis may occur when common traits are identified among various conceptual classes in the Domain ModelCreate a super-class when:The potential sub-classes appear to be variations of the same conceptAll the potential sub-classes will conform to the “is a” rule for the new super-classA set of common attributes that belong to all the potential sub-classes is identified and can be factored outA set of common associations that all potential sub-classes have has been identified and can be factored out9Example: Payment Sub-Classes10CashPaymentCreditPaymentCheckPaymentPaymentamount : MoneyCheckIdentifies-credit-with Paid-with*each payment subclass is handled differentlyadditional associationssuperclass justified by common attributes and associationsSalePays-forCreditCard111 111CreditAuthorizationServiceCheckAuthorizationServiceCheckPaymentAuthorizationServiceaddressnamephoneNumberadditional associationssuperclass justified by common attributes and associationsStoreAuthorizes-payments-of*AuthorizesCreditPaymentAuthorizes***1 1Domain Models: Levels of GranularityAs the Domain Model evolves, the question will arise: What level of detail to go to? How many sub-classes?Depends on the system being modeled – remember, the Domain Model is a tool to help understand the systemNote that system transactions (request – reply) are usually modeled, because other activities and processes depend upon themBut it is not always necessary to define sub-classes for every transactionGeneral rule: don’t add complexity unless needed!1213CreditPaymentApprovalReplyCheckPaymentApprovalReplyCreditPaymentApprovalRequestCheckPaymentApprovalRequestCreditPaymentDenialReplyCheckPaymentDenialReplyCheckPaymentAuthorizationReplyCreditPaymentAuthorizationReplyPaymentAuthorizationReplyPaymentAuthorizationRequestPaymentAuthorizationTransactiondatetimeConcepts too fine grained?Useful to show this degree of partitioning?Each transaction is handled differently, so it is useful to partition them into discrete classes.14CreditPaymentApprovalRequestCheckPaymentApprovalRequestPaymentAuthorizationReplyPaymentAuthorizationRequestPaymentAuthorizationTransactiondatetimeCreditPaymentApprovalReplyCheckPaymentApprovalReplyCreditPaymentDenialReplyCheckPaymentDenialReplyAbstract Conceptual ClassesRecall that when we were developing use cases, we saw that it may be useful to collect a series of steps that occurs in several use cases and define an abstract use case that the other use cases could refer toWe can do something similar for conceptual classes: If every member of a class C is a sub-class of C, then C is called an abstract class. But if there is an instance of C that is not a member of a sub-class, then C is not an abstract class.The Payment conceptual class we have been discussing is an abstract class, because all payments fall into one


View Full Document

UT Dallas CS 6359 - S8_Chapters9-31_2

Documents in this Course
Lecture2

Lecture2

63 pages

Lecture3

Lecture3

49 pages

Lecture4

Lecture4

48 pages

Lecture5

Lecture5

47 pages

Lecture6

Lecture6

45 pages

Lecture7

Lecture7

63 pages

Lecture8

Lecture8

77 pages

Lecture9

Lecture9

48 pages

Lecture10

Lecture10

84 pages

Lecture11

Lecture11

45 pages

Lecture12

Lecture12

134 pages

Lecture13

Lecture13

62 pages

Lecture14

Lecture14

76 pages

Project

Project

2 pages

Chapter_1

Chapter_1

25 pages

Load more
Download S8_Chapters9-31_2
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view S8_Chapters9-31_2 and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view S8_Chapters9-31_2 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?