Class Diagrams CSC 440/540: Software Engineering Slide #
Topics. Design class diagrams (DCDs) 2. DCD development process 3. Associations and Attributes 4. Dependencies 5. Composition and Constraints 6. Object modeling advice CSC 440/540: Software Engineering Slide #2
Design Class Diagrams DCDs are class diagrams for static object modeling. Domain models use a subset of class diagram notation for business modeling. Builds on previous artifacts Domain Model (conceptual classes) Interaction Diagrams (software classes + methods) Feedback loop with interaction diagrams Typically develop in parallel CSC 440/540: Software Engineering Slide #3
DCDs illustrate Classes Associations between classes Attributes of objects with types Interfaces Methods Dependencies Navigability CSC 440/540: Software Engineering Slide #4
Class Diagram UML Notation 3 c o m m o n c o m p a rtm e n ts. c la s s ifie r n a m e 2. a ttrib u te s 3. o p e ra tio n s a n in te rfa c e s h o w n w ith a k e y w o rd «in te rfa c e» R u n n a b le ru n () S u p e rc la s s F o o or S u p e rc la s s F o o { a b s tra c t } - c la s s O rs ta tic A ttrib u te : In t + p u b lic A ttrib u te : S trin g - p riv a te A ttrib u te a s s u m e d P riv a te A ttrib u te is In itia liz e d A ttrib u te : B o o l = tru e a C o lle c tio n : V e g g ie B u rg e r [ * ] a ttrib u te M a y L e g a lly B e N u ll : S trin g [0.. ] fin a lc o n s ta n ta ttrib u te : In t = 5 { re a d O n ly } /d e riv e d A ttrib u te + c la s s O rs ta tic M e th o d () + p u b lic M e th o d () a s s u m e d P u b lic M e th o d () - p riv a te M e th o d () # p ro te c te d M e th o d () ~ p a c k a g e V is ib le M e th o d () «c o n s tru c to r» S u p e rc la s s F o o ( Long ) m e th o d W ith P a rm s (p a rm : S trin g, p a rm 2 : F lo a t) m e th o d R e tu rn s S o m e th in g () : V e g g ie B u rg e r m e th o d T h ro w s E x c e p tio n () {e x c e p tio n IO E x c e p tio n } a b s tra c tm e th o d () a b s tra c tm e th o d 2 () { a b s tra c t } // a lte rn a te fin a lm e th o d () { le a f } // n o o v e rrid e in s u b c la s s s y n c h ro n iz e d M e th o d () { g u a rd e d } o ffic ia lly in U M L, th e to p fo rm a t is u s e d to d is tin g u is h th e p a c k a g e n a m e fro m th e c la s s n a m e u n o ffic ia lly, th e s e c o n d a lte rn a tiv e is c o m m o n ja v a.a w t::f o n t or ja v a.a w t.f o n t p la in : In t = 0 { re a d O n ly } b o ld : In t = { re a d O n ly } n a m e : S trin g s ty le : In t = 0 g e tf o n t(n a m e : S trin g ) : F o n t g e tn a m e () : S trin g F ru it dependency in te rfa c e im p le m e n ta tio n and s u b c la s s in g S u b c la s s F o o ru n () - e llip s is m e a n s th e re m a y b e e le m e n ts, b u t n o t s h o w n - a b la n k c o m p a rtm e n t o ffic ia lly m e a n s u n k n o w n b u t a s a c o n v e n tio n w ill b e u s e d to m e a n n o m e m b e rs o rd e r a s s o c ia tio n w ith m u ltip lic itie s P u rc h a s e O rd e r
DCD development process. Identify all classes involved in software by analyzing interaction diagrams. 2. Draw classes in a class diagram. 3. Copy attributes from the related concepts in the domain model. 4. Add method names based on messages exchanged between classes in interaction diagrams. 5. Add type information. 6. Add associations necessary for attribute visibility. 7. Add navigability arrows to associates to indicate direction of visibility. 8. Add dependency relationship lines to indicate nonattribute visibility. CSC 440/540: Software Engineering Slide #6
From Domain to Design Model D o m a in M o d e l c o n c e p tu a l p e rs p e c tiv e R e g is te r C a p tu re s S a le tim e is C o m p le te : B o o le a n /to ta l R e g is te r S a le D e s ig n M o d e l DCD; s o ftw a re p e rs p e c tiv e e n d S a le () e n te rite m () m a k e P a y m e n t() c u rre n ts a le tim e is C o m p le te : B o o le a n /to ta l m a k e L in e Ite m ()
Prefer associations to attributes u s in g th e a ttrib u te te x t n o ta tio n to in d ic a te R e g is te r h a s a re fe re n c e to o n e S a le in s ta n c e R e g is te r c u rre n ts a le : S a le S a le O B S E R V E : th is s ty le v is u a lly e m p h a s iz e s th e c o n n e c tio n b e tw e e n th e s e c la s s e s R e g is te r c u rre n ts a le S a le u s in g th e a s s o c ia tio n n o ta tio n to in d ic a te R e g is te r h a s a re fe re n c e to o n e S a le in s ta n c e th o ro u g h a n d u n a m b ig u o u s, b u t s o m e p e o p le d is lik e th e p o s s ib le re d u n d a n c y R e g is te r c u rre n ts a le : S a le c u rre n ts a le S a le
Association vs Attribute Decisions a p p ly in g th e g u id e lin e to s h o w a ttrib u te s a s a ttrib u te te x t v e rs u s a s a s s o c ia tio n lin e s id: In t R e g is te r c u rre n ts a le S a le tim e : D a te T im e R e g is te r h a s T H R E E a ttrib u te s :. id 2. c u rre n ts a le 3. lo c a tio n lo c a tio n S to re a d d re s s : A d d re s s phone: P h o n e N u m b e r
Representing Collections S a le S a le s L in e Ite m tim e : D a te T im e lin e Ite m s : S a le s L in e Ite m [..* ] or lin e Ite m s : S a le s L in e Ite m [..* ] {o rd e re d } T w o w a y s to s h o w a c o lle c tio n a ttrib u te S a le S a le s L in e Ite m tim e : D a te T im e..* lin e Ite m s {o rd e re d, L is t} n o tic e th a t a n a s s o c ia tio n e n d c a n o p tio n a lly a ls o h a v e a p ro p e rty s trin g s u c h a s {o rd e re d, L is t}
Generalization CSC 440/540: Software Engineering Slide #
Dependencies Common dependencies include Target is an attribute of the source. Source sends a message to the target. Source receives a parameter of target type. Target is a superclass or interface. Indicating dependencies helps you Know which classes to implement or mock first. Know which classes will be impacted by a change. CSC 440/540: Software Engineering Slide #2
Dependencies and Attributes th e S a le h a s p a ra m e te r v is ib ility to a P ro d u c td e s c rip tio n, a n d th u s s o m e k in d o f dependency P ro d u c td e s c rip tio n S a le u p d a te P ric e F o r( P ro d u c td e s c rip tio n ) S a le s L in e Ite m..* lin e Ite m s
Interfaces and Implementations a c tiv e c la s s «in te rfa c e» ru n () R u n n a b le ru n () C lo c k
DCD Keywords Keyword Meaning Example «interface» Class is an interface «interface»listener «create» «call» {abstract} {ordered} Source creates instances of target of dependency. Source calls an operation in target of dependency. Abstract classes cannot be instantiated. Collection of objects has a defined order. Class {abstract} list: class{ordered} CSC 440/540: Software Engineering Slide #5
Dependency Example th e d o X m e th o d in v o k e s th e ru n F in a liz a tio n s ta tic m e th o d, a n d th u s h a s a d e p e n d e n c y o n th e S y s te m c la s s S y s te m F o o ru n F in a liz a tio n () dox() Static method
More dependency examples W in d o w «c a ll» C lo c k g e tt im e () A «c re a te» B a d e p e n d e n c y o n c a llin g o n o p e ra tio n s o f th e o p e ra tio n s o f a C lo c k a d e p e n d e n c y th a t A o b je c ts c re a te B o b je c ts
Object Composition H a n d 0..7 F in g e r c o m p o s itio n m e a n s -a p a rt in s ta n c e (S q u a re ) c a n o n ly b e p a rt o f o n e c o m p o s ite (B o a rd ) a t a tim e c o m p o s itio n -th e c o m p o s ite h a s s o le re s p o n s ib ility fo r m a n a g e m e n t o f its p a rts, e s p e c ia lly c re a tio n a n d d e le tio n B o a rd 40 S q u a re S a le..* S a le s L in e Ite m
UML Constraints th re e w a y s to s h o w U M L c o n s tra in ts S ta c k s iz e : In te g e r { s iz e > = 0 } p u s h ( e le m e n t ) pop() : O b je c t { p o s t c o n d itio n : n e w s iz e = o ld s iz e + } { p o s t c o n d itio n : n e w s iz e = o ld s iz e }
Object Modeling Advice Model dynamic and static behavior concurrently One whiteboard for interaction diagrams (dynamic) Adjacent whiteboard for class diagrams (static) When dynamic modeling Use communication diagrams for sketching. Document with sequence diagrams. CSC 440/540: Software Engineering Slide #20