1- ucd domain model

7/23/2019 1- UCD Domain Model

http://slidepdf.com/reader/full/1-ucd-domain-model 1/21

UCDs & DMsUse Case Diagrams &

Domain ModelsAre artifacts of requirementsspecication



UCD

UCDs are used to represent thefunctionality of the system and theuser classes entitled to perform thatfunctionality.

They associate user classes with thesystem functionalities/features theymay use.



UCD

A UCD is composed ofA system !oundary. A rectangle enclosing the

system features/functionalities.A num!er of functionalities drawn as o"als

inside the system !oundary and named forthe use cases they represent.

Actors. Actors represent the user classes thatmay operate the system. They may !e

classes of people or other systems whichaccess the system you are !uilding.Connectors. #ines drawn !etween Actors and

the system functionalities that Actor can use.



UCDsourcehttp//en.wi$ipedia.org/wi$i/Use%case%diagram

UCD



Use Case Relationshipsfrom http//en.wi$ipedia.org/wi$i/Use%case%diagram



Use Case Relationshipsour relationships among use cases are used often

in practice.Include

• 'n one form of interaction( a gi"en use case may include another.)'nclude is a Directed *elationship !etween two use cases(implying that the !eha"ior of the included use case is insertedinto the !eha"ior of the including use case).

• The frst use case oten depends on the outcome o the includeduse case. This is useful for e+tracting truly common !eha"iorsfrom multiple use cases into a single description. The notation isa dashed arrow from the including to the included use case( withthe la!el ),include-). This usage resem!les a macro e+pansion

where the included use case !eha"ior is placed inline in the !aseuse case !eha"ior. There are no parameters or return "alues. Tospecify the location in a ow of e"ents in which the !ase usecase includes the !eha"ior of another( you simply write include followed !y the name of use case you want to include.

rom http//en.wi$ipedia.org/wi$i/Use%case%diagram




in practice.

Extend• 'n another form of interaction( a gi"en use case the e+tension0

may extend another. The relationship indicates that the !eha"ior ofthe e+tension use case may !e inserted in the e+tended use caseunder some conditions. The notation is a dashed arrow from the

e+tension to the e+tended use case( with the la!el ),e+tend-). Thenotes or constraints may !e associated with this relationship toillustrate the conditions under which this !eha"ior will !e e+ecuted.

• Modelers use the ,e+tend- relationship to indicate use cases thatare )optional) to the !ase use case. Depending on the modeler1sapproach )optional) may mean )potentially not e+ecuted with the!ase use case) or it may mean )not required to achie"e the !aseuse case goal).





in practice.

Generalization

• 'n the third form of relationship among use cases( ageneralization/specialization relationship e+ists. Agi"en use case may ha"e common !eha"iors(

requirements( constraints( and assumptions with amore general use case. 'n this case( descri!e themonce( and deal with it in the same way( descri!ingany di2erences in the speciali3ed cases. The

notation is a solid line ending in a hollow triangledrawn from the speciali3ed to the more general usecase following the standard generali3ation notation0





in practice.

Associations

• Associations !etween actors and use cases areindicated in use case diagrams !y solid lines. Anassociation e+ists whene"er an actor is in"ol"ed with

an interaction descri!ed !y a use case. Associationsare modeled as lines connecting use cases andactors to one another( with an optional arrowhead onone end of the line. The arrowhead is often used to

indicate the direction of the initial in"ocation of therelationship or to indicate the primary actor withinthe use case. The arrowheads imply control ow andshould not !e confused with data ow.




DM 4"er"iew•

Thedomain model

is created in order to represent the "oca!ularyand $ey concepts of the pro!lem domain. The domain model alsoidenties the relationships among all the entities within the scopeof the pro!lem domain( and commonly identies their attri!utes. Adomain model that encapsulates methods within the entities ismore properly associated with o!5ect oriented models. The domain

model pro"ides a static( structural "iew of the domain that can !ecomplemented !y other dynamic "iews( such as Use Case models.

• An important ad"antage of a domain model is that it descri!es andconstrains the scope of the pro!lem domain. The domain modelcan !e e2ecti"ely used to "erify and "alidate the understanding ofthe pro!lem domain among "arious sta$eholders. 't is especially

helpful as a communication tool and a focusing point !oth amongstthe di2erent mem!ers of the !usiness team as well as !etween thetechnical and !usiness teams.

rom http//en.wi$ipedia.org/wi$i/Domain%model



DMs

Domain Models represent our initialunderstanding of what conceptualclasses are li$ely to !e necessary to!uild the system.

They show these Domain #e"el 4!5ectsD#4s0 along with the associations!etween them.



D#4s

Domain #e"el 4!5ects D#4s0 aredepicted as Two !o+ containers withthe top !o+ lled with the name ofthe D#4 and the !ottom !o+ lledwith the untyped0 attri!utes wethin$ that D#4 might need to

perform the functions we !elie"e itwill need to perform.



Associations

Associations connect D#4s. They arecomposed of 6 main components.

A connector !etween two D#4s. 'f( and only

if( this connection does not go left7to7rightor top7to7!ottom a directionality openarrowhead0 should !e shown.

A name an acti"e "er! descri!ing the

relationship !etween the connected D#4s.Cardinalities The multiplicity of theassociation should !e depicted at !oth endsof the connector.



Domain Model Syntaxromhttp//www.comptechdoc.org/independent/uml/!egin/umldomainmodel.html



Domain Model 8lements There can !e multiple relationships !etween o!5ects

in the domain model. or instance an o!5ect mayhandle a single transaction( then ma$e a record of alltransactions it handles. 'n the domain model thefollowing are shown

•Concepts 4!5ects0

•Attri!utes of 4!5ects 7 Attributes must be simpleattributes such as numbers. They cannot !eo!5ects( dimensioned num!ers( or $eys to part of adata!ase.

•Association !etween o!5ects

•Multiplicity

•4ptional direction of relationship arrow

•4ptional role of o!5ectromhttp//www.comptechdoc.org/independent/uml/!egin/umldomainmodel.html



D#4s

• 'dentify with noun analysis ofrequirements and use cases.

• Domain Model Candidates

9our Corporation has

:.multiple plants has

;.multiple departments has6.multiple machines

rom http//www.comptechdoc.org/independent/uml/!egin/umldomainmodel.html



Associations

• Associations descri!e important relationships !etween concepts and may !e!idirectional. Use an association to relate classes( not attri!utes. <omeassociations may !e

• A is a part of =

• line item of

• Contained inside

• 's a mem!er of

• 's a policy of

• 's ne+t to

• Uses

• Communicates with

• A relates to = due to a transaction

• >hen creating associations( as$ yourself( )Does one need to $now a!out theother?). 'f the answer is yes( there should pro!a!ly !e an association. There may!e more than one association !etween two o!5ects.




Multiplicity

• Descri!es how many instances of one conceptcan !e associated with one instance of therelated concept.

• @ Bero or more

• ..6 Bero to three

• ;((E Two( four( or si+

• : 8+actly :

•

:..@ 4ne or more• ..@ Bero or more




Some Guidelines

• Fut items up in this order

– Concepts

– #a!el associations

– Types on attri!utes• 'f concepts ha"e !oth data attri!utes0 and

!eha"ior methods0 they more li$ely t in thedomain model though the methods are not

shown in the DM0.• Analy3e items that may ha"e additional types.




Domain Modelssource http//nu!yonrails.les.wordpress.com/;G/G/domain7model.5pg



DMs

Hote that in the last slide some of theassociations are unnamed. This isincorrect.

All associations should !e named unless theyare inheritance( composition oraggregation.

The a!o"e need not !e named as they ha"especially drawn connectors which containwithin their "ery denition the nature oftheir association.

1- ucd domain model

Documents