Unit-II(STATIC UML DIAGRAMS).ppt

Static UML diagrams

1. Unit II-STATIC UML DIAGRAMS

2. Unified Modeling Language
•UMLisastandardlanguageforspecifying,
visualizing,constructing,anddocumentingthe
artifactsofsoftwaresystems.
•UMLwascreatedbyObjectManagementGroup
andUML1.0specificationdraftwasproposed
totheOMGinJanuary1997.
•Thistutorialgivesacompleteunderstandingon
UML.

3. Unified Modeling Language (Contd.)
•Amodelissimplifiedbecauserealityistoocomplexor
largeandmuchofthecomplexityactuallyisirrelevant
totheproblemwearetryingtodescribeorsolve
•AModelprovidesameansforconceptualizationand
communicationofideasinapreciseandunambiguous
form.
•Thecharacteristicsofsimplificationandrepresentation
aredifficulttoachieveintherealworld
•Mostmodelingtechniqueusedduringmanyofthe
phasesoftheSLC(servicelifecycle)suchasanalysis,
designandimplementation

4. Unified Modeling Language (Contd.)
•For example, objectory is build around several different models:
–Use-case model
defines the outside(actor) and inside (use-case) of the system’s
behavior
–Domain object model
Objects of real world are mapped into the domain object model
–Analysis object model
The analysis object model presents how the source code should
be carried out and written
–Implementation Model
The implementation model represents the implementation of the
system
–Test model
The test model constitutes the test plans, specifications, and
reports

5. Static and Dynamic Models
•Modelscanrepresentstaticanddynamic
•Eachrepresentationhasdifferentimplicationsforhowthe
knowledgeaboutthemodelmightbeorganizedandrepresented
•StaticModel
–Astaticmodelcanbeviewedasasnapshotofasystem’sparametersat
restoraspecificpointintime.
–Staticmodelsareneededtorepresentthestructuralstaticaspectofa
system
–Forexampleacustomercouldhavemorethanoneaccountoranorder
couldbeaggregatedfromoneormorelineitems.
–Staticmodelsassumestabilityandanabsenceofchangeindataovertime
.
–Theunifiedmodelinglanguageclassdiagramisanexampleofastatic
model

6. Static and Dynamic Models (Contd.)
•Dynamicmodel
–Incontrasttoastaticmodel,canbeviewedasa
collectionofproceduresorbehaviorsthat,taken
together,reflectthebehaviorofasystemovertime.
–Dynamicrelationshipsshowhowthebusiness
objectsinteractstoperformtasks.
–Forexample,anorderinteractswithinventoryto
determineproductavailability.
–TheUMLinteractiondiagramandactivitymodels
areexamplesofUMLdynamicmodels

7. Why Modeling?
•Buildingamodelforasoftwaresystempriortoits
constructionisasessentialashavingablueprint
forbuildingalargebuilding.
•Goodmodelsareessentialforcommunication
amongprojectteams.
•Amodelinglanguagemustinclude
–Modelelements–fundamentalmodelingconcepts
andsemantics
–Notation–visualrenderingofmodelelements
–Guidelines–expressionofusagewithinthetrade

8. Modeling (Contd.)
•Theuseofvisualnotationtorepresentormodelaproblem
canprovideusseveralbenefitsrelatingto
–Clarity:wearemuchbetteratpickingouterrorsandomissions
fromagraphicalorvisualrepresentationthanfromlistingof
codeortablesofnumbers.
–Familiarity:Therepresentationformforthemodelmayturn
outtobesimilartothewayinwhichtheinformationactuallyis
representedandusedbytheemployeecurrentlyworkinginthe
problemdomain.
–Maintenance:visualnotationcanimprovethemaintainability
ofasystem.
–Simplification:Useofahigherlevelrepresentationgenerally
resultsintheuseoffewerbutmoregeneralconstructs,
contributingtosimplicityandconceptualunderstanding

9. Advantages of Modeling
•Modelsmakeiteasiertoexpresscomplex
ideas
•Reductionofcomplexity
•Enhanceandreinforcelearningandtraining
•Costislow
•Manipulationismucheasier

10. Key Ideas of Modeling
•Amodelisrarelycorrectonthefirsttry
•Alwaysseektheadviceandcriticismofothers.
Youcanimproveamodelbyreconciling
differentperspective
•Avoidexcessmodelrevision,astheycan
distorttheessenceofyourmodel.

11. Introduction to the UML
•TheUMLisalanguagueforspecifying,constructing,
visualizinganddocumentingthesoftwaresystemandits
components.
•TheUMLisagraphicallanguagewithsetsofrulesand
semantic
•Therulesandsemanticsofamodelareexpressedin
english,inaformknownasobjectconstraint
language(OCL).
•OCLisaspecificationlanguagethatusessimplelogicfor
specifyingthepropertiesofasystem.
•TheUMLisnotintendedtobeavisualprogramming
languageinthesenseofhavingallthenecessaryvisualand
semanticsupporttoreplaceprogramminglanguages.

12. Introduction to the UML (Contd.)
•TheprimarygoalinthedesignoftheUMLwere
–Provideusersaready–to-use,expressivevisualmodeling
languagedevelopandexchangemeaningfulmodels
–Provideextensibilityandspecializationmechanismsto
extendthecoreconcepts
–Beindependentofparticularprogramminglanguagesand
developmentprocesses
–Provideaformalbasisforunderstandingthemodeling
language
–EncouragethegrowthoftheOOtoolsmarket
–Supporthigher-leveldevelopmentconcepts
–Integratebestpracticesandmethodologies

13. UML Diagrams
•Everycomplexsystemisbestapproachedthroughasmallsetofnearly
independentviewsofamodel;nosingleviewissufficient.
•TheUMLdefinesninegraphicaldiagrams
–Classdiagram(static)
–Use-casediagram
–Behaviordiagram(Dynamic)
•Interactiondiagram
–Sequencediagram
–Collaborationdiagram
•Statechartdiagram
•Activitydiagram
–Implementationdiagram
•Componentdiagram
•Deploymentdiagram

14. Use Case Diagram
•Used for describing a set of user scenarios
•Mainly used for capturing user requirements
•Work like a contractbetween end user and
software developers

15. Use Case Diagram (core components)
Actors:A role that a user plays with respect to the system,including
human users and other systems. e.g.,inanimate physical objects (e.g. robot);
an external system that needs some information from the current system.
Use case:A set of scenarios that describing an interaction between a user
and a system, including alternatives.
System boundary: rectangle diagram representing the boundary between
the actors and the system.

16. Use Case Diagram(core relationship)
Association:communication between an actor and
a use case; Represented by a solid line.
Generalization: relationship between one general
use case and a special use case (used for defining
special alternatives)
Represented by a line with a triangular arrow head
toward the parent use case.

17. Use Case Diagram(core relationship)
Extend: a dotted line labeled <<extend>> with an arrow
toward the base case.The extending use case may add behavior to
the base use case. The base class declares “extension points”.
<<extend>>
Include: a dotted line labeled <<include>> beginning at base
use case and ending with an arrows pointing to the include use
case. The include relationship occurs when a chunk of
behavior is similar across more than one use case. Use
“include” in stead of copying the description of that behavior.
<<include>>

18. Use Case Diagrams
Library System
Borrow
Order Title
Fine Remittance
Client
Employee
Supervisor
•A generalized description of how a system will be used.
•Provides an overview of the intended functionality of the system
Boundary
Actor
Use Case

19. Use Case Diagrams(cont.)
(TogetherSoft, Inc)

20. Use Case Diagrams(cont.)

21. Procedure for creating Actor
•InordertocreateActor,click[Toolbox]->[UseCase]->[Actor]
buttonandclickthepositionwheretoplaceActor.Actoris
shownintheformofstickmanorrectanglewithicon,thatis
decorationview.Todisplayactorindecorationview,select
[Format]->[StereotypeDisplay]->[Decoration]menuitemor
select[Decoration]itemincombobuttonontoolbar.

22. Procedure for creating UseCase
•InordertocreateUseCase,click[Toolbox]->[UseCase]button
andclickthepositionwheretoplaceUseCaseonthe[main
window].
•UseCaseisexpressedintheformsoftextual,decoration,
iconic.TochangeUseCase'sviewstyle,selectmenuitem
under[Format]->[StereotypeDisplay]orselectbutton's
comboitem.

23. Procedure for creating Actor from
UseCase
•InordertocreatemultipleActorsrelatedtoUseCaseatonce,
useshortcutcreationsyntax.
1.Double-clickUseCase,orselectUseCaseandpress[Enter]
key.Atquickdialog,enterActor'snameafter"()-"stringand
separateActornamesby","character.
2.Andpress[Enter]key.SeveralActorsassociatedwiththe
UseCasearecreatedandarrangedvertically.

24. Procedure for creating association
•Inordertocreateassociation,click[Toolbox]->
[UseCase]->[Association]button,dragfromfirst
element,anddroptosecondelementinthe[main
window].

25. Procedure for creating directed
association
•Theprocedureisequaltotheassociation's,draganddropin
thearrowdirection.
•Orcreateassociation,clicktheactor-sideassociationend.At
thequickdialog,unchecknavigableandassociationbecomes
directed.

26. Procedure for creating element related to
association/directed assocition
•Inordertocreateelementassociatedwithcurrentelement,
useshortcutcreationsyntax.
1.Double-clickelementandenterelement'snames
associatedafter"--"or"->"stringatthequickdialog.Separate
elementnameswith","charactertorelatemultipleelements.
2.Press[Enter]keyandseveralelementsassociatedwith
selectedelementarecreatedandarrangedautomatically.

27. Procedure for creating generalization
•Inordertomakegeneralization,click[Toolbox]->
[UseCase]->[Generalization]button,dragfromchild
elementanddroptoparentelementinthe[main
window].

28. Procedure for creating multiple child
actors inherited from actor
•Tocreatemultipleelementsinheritedfromsomeelement,
1.Enterwith"<="stringasfollowingatthequickdialog,and
severalelementsinheritedfromselectedelementarecreated
atonce.
2.Childelementsaregeneratedbelowselectedelementand
arrangedautomatically.

29. Procedure for creating dependency
•Inordertocreatedependency,click[Toolbox]->
[UseCase]->[Dependency]button,dragelementand
droptootherelementdepended

30. Procedure for creating other usecase
depended by current usecase
•Enterwith"-->"stringatthequickdialogas
following.
•Sodependencyrelationshipiscreatedbetweentwo
elements.

31. Procedure for creating include
•Inordertocreateincluderelationship,click[Toolbox]
->[UseCase]->[Include]button,dragfromelement
includinganddroptoelementincludedinthe[main
window].

32. Procedure for creating other usecase
included by current usecase
•Enterwith"-i>"stringatthequickdialogasfollowing
•Soincluderelationshipiscreatedbetweentwo
elements.

33. Procedure for creating extend
•Inordertocreateextend,click[Toolbox]->[UseCase]
->[Extend]button,dragfromelementextendingand
droptoelementextendedinthe[mainwindow].

34. Procedure for creating other usecase
extending current usecase
•Enterwith"<e-"stringatthequickdialogas
following.
•Soextendrelationshipiscreatedbetweentwo
elements

35. Procedure for creating system
boundary
•Inordertocreatesystemboundary,click[Toolbox]->
[UseCase]->[SystemBoundary]button,dragfrom
thestartingpointofsystemboundaryanddragto
right-bottompointofsystemboundary.

36. Procedure for creating package
•Inordertocreatepackage,click[Toolbox]->
[UseCase]->[Package]buttonandclickatthe
locationwherepackagewillbeplacedinthe[main
window].

37. Class Diagram
•Itisalsoreferredtoasobjectmodeling,isthemain
staticanalysisdiagram.
•Aclassdiagramisacollectionofstaticmodeling
elements,suchasclassesandtheirrelationships,
connectedasagraphtoeachotherandtotheir
contents.
•Forexamplethethingsthatexist,theirinternal
structures,andtheirrelationshipstootherclasses.
•Classdiagramsdonotshowtemporalinformation,
whichisrequiredindynamicmodeling.

38. Class Diagram
•Objectmodelingistheprocessbywhichthelogical
objectsintherealworldarerepresentedbythe
actualobjectsintheprogram.
•Thisvisualrepresentationoftheobjects,their
relationships,andtheirstructuresisforeaseof
understanding.
•Toeffectivelydevelopamodeloftherealworld
andtodeterminetheobjectsrequiredinthe
system,youfirstmustaskwhatobjectsareneeded
tomodelthesystem.

39. Class Diagram
•Answeringthefollowingquestionswillhelpyoutostay
focusedontheproblemathandanddeterminewhatisinside
theproblemdomainandwhatisoutsideit:
–Whatarethegoalsofthesystem?
–Whatmustthesystemaccomplish?
•Youneedtoknowwhatobjectswillformthesystembecause,
intheobjectorientedviewpoint,objectsaretheprimary
abstraction,.
•Themaintaskofobjectmodelingistographicallyshowwhat
eachwilldointheproblemdomain,describesthestructure
andtherelationshipsamongobjectsbyvisualnotations,and
determinewhatbehaviorsfallwithinandoutsidetheproblem
domain.

40. Class Notation: Static Structure
•Aclassisdrawnasarectanglewiththreecomponentsseparatedby
horizontallines.
•Thetopnamecompartmentholdstheclassname,othergeneral
propertiesoftheclass,suchasattributes,areinthemiddle
compartment,andthebottomcompartmentholdsalistof
operations.
•Eitherorboththeattributeandoperationcompartmentsmaybe
suppressed.
•Aseparatorlineisnotdrawnforamissingcompartmentifa
compartmentissuppressed;noinferencecanbedrawnaboutthe
presenceorabsenceofelementsinit.
•Theclassnameandotherpropertiesshouldbedisplayedinupto
threesections.
•AstylisticconventionofUMListouseanitalicfontforabstract
classesandanormal(roman)fontforconcreteclasses.

41. Class Diagram

42. Object Diagram
•Astaticobjectdiagramisaninstanceofaclass
diagram.
•Itshowsasnapshotofthedetailedstateofthe
systematapointintime.
•Notationisthesameforanobjectdiagramand
aclassdiagram.
•Classdiagramcancontainobjects,soaclass
diagramwithobjectsandnoclassesisanobject
diagram.

43. Class Interface notation
•Classinterfacenotationisusedtodescribetheexternallyvisible
behaviorofaclass;forexample,anoperationwithpublicvisibility.
•IdentifyingclassinterfacesisadesignactivityofOOSD.
•TheUMLnotationforaninterfaceisasmallcirclewiththenameof
theconnectedtotheclass.
•Aclassthatrequirestheoperationsintheinterfacemaybe
attachedtothecirclebyadashedarrow.
•Thedependentclassisnotrequiredtoactuallyuseallofthe
operations.
•Forexample,apersonobjectmayneedtointeractwiththe
BankAccountobjecttogetthebalance;thisrelationshipisdepicted
withUMLclassinterfacenotation.

44. Binary association notation
•Abinaryassociationisdrawnasasolidpathconnectingtwo
classes,orbothendsmaybeconnectedtothesameclass.
•Anassociationmayhaveanassociationname.
•Theassociationnamemayhaveanoptionalblacktrianglein
it,thepointofthetriangleindicatingthedirectioninwhichto
readthename.
•Theendofanassociation,whereitconnectstoaclass,is
calledtheassociationrole.
marriedTo

45. Association Role
•Asimpleassociation–thetechnicaltermforitisbinaryassociation
–isdrawnasasolidlineconnectingtwoclasssymbols.
•Theendofanassociation,whereitconnectstoaclass,showsthe
associationrole.
•Theroleispartoftheassociation,notpartoftheclass.
•Eachassociationhastwoormorerolestowhichitisconnected.
•TheUMLusesthetermassociationnavigationornavigabilityto
specifyaroleaffiliatedwitheachendofanassociationrelationship.
•Anarrowmaybeattachedtotheendofthepathtoindicatethat
navigationissupportedinthedirectionofclasspointedto.
•Anarrowmaybeattachedtoneither,one,orbothendsofthepath.

46. Qualifier
•Aqualifierisanassociationattribute.
•Forexample,apersonobjectmaybeassociatedtoabankobject.
•Anattributeofthisassociationistheaccount#.
•Theaccount#isthequalifierofthisassociation.
•Aqualifierisshownasasmallrectangleattachedtotheendofan
associationpath,betweenthefinalpathsegmentandthesymbol
oftheclasstowhichitconnects.
•Thequalifierrectangleispartoftheassociationpath,notpartof
theclass.
•Thequalifierrectangleusuallyissmallerthantheattachedclass
rectangle.
account#
*
0…1

47. Multiplicity
•Multiplicityspecifiestherangeofallowableassociated
classes.
•Itisgivenforroleswithinassociation,partswithin
compositions,repetitions,andotherpurposes.
•Amultiplicityspecificationisshownasatextstring
comprisingaperiodseparatedsequenceofinteger
intervals,whereanintervalrepresentsarangeof
integersinthisformat
lowerbound..Upperbound
0..1
0..*
1..3,7..10,15,19..*
account#
*
0…1

48. OR Association
•AnOrassociationindicatesasituationinwhichonlyoneofseveral
potentialassociationmayinstantiatedatonetimeforanysingle
object.
•Thisisshownasadashedlineconnectingtwoormoreassociation,
allofwhichmusthaveaclassincommon,withtheconstraint
string{0r}labelingthedashedline.
•Inotherwords,anyinstanceoftheclassmayparticipatein,atmost,
oneoftheassociationatonetime.
Car
Person
Company
{or}

49. Association Class
•Anassociationclassisanassociationthatalsohasclassproperties.
•Anassociationclassinshownasaclasssymbolattachedbya
dashedlinetoanassociationpath.
•Thenameintheclasssymbolandthenamestringattachedtothe
associationpatharethesame.
•Thenamecanbeshownonthepathorclasssymbolorboth.
•Ifanassociationclasshasattributesbutnooperationsorother
association,thenthenamebedisplayedontheassociationpath
andomittedfromtheassociationclasstoemphasizeits“
associationnature”.
•Ifithasoperationsandattributes,thenthenamemaybeomitted
fromthepathandplacedintheclassrectangletoemphasizeits
“classnature”.

50. Association Class

51. N-ary Association
•Ann-aryassociationisanassociationamongmorethan
twoclasses.
•Ann-aryassociationisshownasalargediamondwitha
pathfromthediamondtoeachparticipantclass.
•Thenameoftheassociationisshownnearthediamond.
•Theroleattachmentmayappearoneachpathaswitha
binaryassociation.
•Multiplicitymaybeindicated;however,qualifiersand
aggregationarenotpermitted.
•Anassociationclasssymbolmaybeattachedtothe
diamondbyadashedline,Indicatingann-aryassociation
thathasattributes,operation,orassociations.

52. N-ary Association

53. Aggregation
•Aggregationisaformofassociation.
•Ahollowdiamondisattachedtotheendofthepath
toindicateaggregation.
•Thediamondmaynotbeattachedtobothendsofa
line,anditneednotbepresentedatall.

54. Composition
•Italsoknowasthea-part-of,isaformofaggregationwith
strongownershiptorepresentthecomponentofacomplex
object.
•Compositionalsoisreferredtoasapart-wholerelationship.
•TheUMLnotationforcompositionisasoliddiamondatthe
endofapath.
•Alternatively,theUMLprovidesagraphicallynestedform
that,inmanycases,ismoreconvenientforshowing
composition.
•Partswithmultiplicitygreaterthanonemaybecreatedafter
theaggregateitselfbut,oncecreated,theyliveanddiewith
it.
•Suchpartscanalsoexplicitlyremovedbeforethedeathofthe
aggregate.

56. Generalization
•Generalizationistherelationshipbetweenamoregeneralclassand
amorespecificclass.
•Generalizationisdisplayedasadirectedlinewithaclosed,hollow
arrowheadatthesuperclassend.
•TheUMLallowsadiscriminatorlabeltobeattachedtoa
generalizationofthesuperclass.
•Ellipse(….)indicatethatthegeneralizationisincompleteandmore
subclassesexitthatarenotshown.
•Theconstructorcompleteindicatesthatthegeneralizationis
completeandnomoresubclassesareneeded.
•Ifatextlabelisplacedonthehollowtrianglesharedbyseveral
generalizationpathstosubclasses,thelabelappliestoallofthe
paths.
•Inotherwords,allsubclassessharethegivenproperties.

57. Generalization Example

58. Generalization Example

59. Visual Paradigm for UML