1.

IntroductiontoObjectOrientedSoftwareDevelopment
a) Object:Asetofdatatogetherwithsomeoperationsthatcanbeperformedonthatdata. Eg.BankAccount.Datacanbeaccountnumber,nameofaccountholderetc.OperationscanbeWithdrawal, depositetc. b) Model:Simplifiedanalogyofarealentity.Papermodelofabuildingshowsitssizerelatedtootherbuildings. c) ObjectOrientedSystem:Collectionofobjectssendingandreceivingmessagesfromoneanother. d) PredictiveApproaches i. WaterfallSDLC(SystemDevelopmentLifeCycle):Atoolformanaging complexprocessesbybreakingthemdownintoaseriesofphasesand activities.ItoutlinesstepbystepactivitiesforeachphaseofSDLC,the rolethatstakeholdersplayineachactivityandthedeliverables expectedfromeachactivity.InwaterfallSDLC,eachstepiscompletedbeforemovingontothenext. ii. MainLimitationstothepredictiveapproach:Itfailstotakeaccountofinevitablechangesinthelifetimeof thedevelopmentprocess.Thesemodelsseparatedataandtheoperationsperformed,andallthedataand processingrelatedtoasingleentitycanbespreadthroughoutthesystem,sochangesrequirealotofwork. e) AdaptiveApproach i. IterativeSDLC(SystemDevelopmentLifeCycle):WithaniterativeSDLCwebuildasmallsectionofthe systemandthentryitout.Fromtheresultsofthesetests,wemayneedtomakechanges.Oncesatisfied thateverythingisworkingwell,weaddonemorefunctionality,andrepeatthewholeprocess.Eachiteration improvesoraddssomefunctionality.Earlyiterationsemphasizerequirementsaswellasanalysisanddesign; lateriterationsemphasizeimplementationandtesting. ii. IterativePlan:Describeswhattodointhefirstelaborationiteration.Includeshowlongtheiterationwillbe, whowillparticipate,andwhattheywillproduce. iii. ObjectOrientedSystemsDesign:Anexampleofadaptiveapproach 1. Class:Blueprintthatdefinethevariables(orattributes)andthemethodscommontoallobjectsofthe samekind.Eg.YourcarisaninstanceoftheclassCars. 2. Object:Aninstanceofaclass.HaveState,BehaviourandIdentity.MostimportantthinginObject OrientedConcept. 3. Method:Referstoapieceofcodethatisexclusivelyassociatedeitherwithaclass(classmethodsand staticmethods)orwithanobject(instancemethods).Amethodusuallyhasasetofinputparameters, andpossiblyanoutputreturnvalue. 4. Encapsulation:Processofhidingallthedetailsofanobjectthatdonotcontributetoitsessential characteristics.Onlytheinterfaceoftheobjectisexternallyvisible. 5. Inheritance:Capabilityofaclasstousethepropertiesandmethodsofanotherclasswhileaddingtis ownfunctionality.Eg.Ingeneralisation,subclassesinheritpropertiesandmethodsofthesuperclass. Inheritanceenhanceabilitytoreusecode,andmakesdesigningamuchsimplerandcleanerprocess 6. Polymorphism:Capabilityofanactionormethodtododifferentthingsbasedontheobjectthatits actingupon.Overloading,overridingandDynamicmethodBindingaretypesofpolymorphism. f) UnifiedProcess(UP):Theprocessisapublishedindustrystandardforsoftwaredevelopmentprocessespecially forobjectorientedsystems.Ithas4phases,yetallthephasesaresubdividedintoiterations. i. Inception:Establishthecasefortheviabilityoftheproposedsystem ii. Elaboration:Projectstartstotakeshapehere,problemdomainanalysisismade,projectgetsitsbasicform. iii. Construction:Focusgoestothedevelopmentofcomponentsandotherfeaturesofthesystembeing designed.Herethebulkofthecodingtakesplace. iv. Transition:Theproductmovesfromthedevelopmenttoenduser.Heretrainingtakesplaceforendusers andmaintainers,andbetatestingofthesystemtovalidateagainstenduserexpectations.
www.oumstudents.tk

g) UnifiedModellingLanguage(UML):definesstandardised modelsandnotationsforexpressingdifferentaspectsof anOOdesign. i. Usecases:Describeseventsequencesforanactorto usethesystem.Anarrativedescriptionoftheprocess. ii. DomainModel:Visualizationofconceptsinthereal worlddomain,notadescriptionofsoftwareobjects. iii. InteractionDiagram:Flowofmessagesbetween softwareobjectsandalsotheinvocationofmethod. iv. DesignClassDiagram:Showssoftwareclasses,not realworldconcepts.Ithasmethodsandattributesof classes. h) Analysis&Design:Analysisiswhatneedstobeprovidedanddesignishowitwillbeprovided. i) ObjectOrientedAnalysis(OOA):Processofdefiningtheproblemintermsofobjects:realworldobjectswith whichthesystemmustinteract,andcandidatesoftwareobjectsusedtoexplorevarioussolutionalternatives. j) ObjectOrientedDesign(OOD):Processofdefiningthecomponents,interfaces,objects,classes,attributes,and operationsthatwillsatisfytherequirements.Youtypicallystartwiththecandidateobjectsdefinedduring analysis,butaddmuchmorerigortotheirdefinitions.Thenyouaddorchangeobjectsasneededtorefinea solution.Inlargesystems,designusuallyoccursattwoscales: i. Architecturaldesign:Definingthecomponentsfromwhichthesystemiscomposed;and ii. Componentdesign:Definingtheclassesandinterfaceswithinacomponent. k) ImportanceofDesign:Badlydesignedtoolsoruserinterfacesrequireefforttouseandconsequentlyone frequentlymakesmistakesorfeelsfrustrated.Theexternalaspectistheuserinterface.Theinternalsare concernedwithreliability,abilitytochange,resiliencetonewtechnology. Alwaysrememberthatusersofa systemarepeople.AGoodDesign: i. Requiresanunderstandingoftheunderlyingbasicprinciplesandtradeoffs. ii. Requiresexperience. iii. Isnotaboutrightorwrong,butaboutbeingbetterincertaincircumstancesthanothers. l) InceptionPhase:WhereaprojectbeginsinUP.Primarygoalistocheckviabilityoftheproposedsystem.Starts withanideabysomeone.Thenotherswithauthority,finance,knowledgeorskillsneedtobeincorporatedto formavisionoftheproject.Sincethisisiterativeprocess,weexpectmanyversionsofthesamethings.Vital partofthevisionistheScope.Scopehastobesmallestpossibleyetstillhavingthecoreneedsasbiggerscopes tendtofailmoreoften. Asfarastheinceptionphaseoftheprojectisconcerned,whatwewantisaninitiallist ofthenamesoftheusecases. i. ParetosPrinciple(80/20Rule):Thisrulestatesthat80%ofthevalueofagroupofitemsisgenerally concentratedin20%oftheitems. ii. ScopeofaSystem:Thesumofitsparts. iii. FunctionalRequirements:Partsofthesystemthatprovidefunctionality,likingacceptingacustomerorder, theyarebestdescribedwithUseCases.(Othersarewhatwecallnonfunctionalrequirements). iv. UseCase:Descriptionoftheinteractionbetweentheuserandthesystem,doesnttellusanythingabout howthesystemworks,writteninsimpleeverydaylanguage,canbeasimple,casualnarrativedescribing howausersgoalissatisfied. Borrowavideousecasesimplestory Thecustomertakesthevideostheyhaveselectedandgoestothecheckoutcounter.Theretheclerk confirmstheirmembershipandchecksforanyoverduevideos.Thetotalcostiscalculated;thecustomer pays,andleaveswiththeirvideos.

www.oumstudents.tk

m) InceptionPhaseArtifacts:Variousmodels,designs,documents,reports,spreadsheets,manualsand programmingcodethatareproducedduringthedevelopmentofasystem.Amethodologyusuallygives guidelinesonwhichartifactsneedtobeproduced,whentheyareproducedinthedevelopmentlifecycle,the format(drawing,document,spreadsheet,etc.),andpossiblywhointheteamshouldproducethem. i. InceptionPhaseArtifacts:Vision&BusinessCase,UseCaseModel,SupplementarySpecification,Glossary, RiskList&RiskManagementPlan,Prototypes&ProofofConcepts,IterationPlan,PhasePlan&Software DevelopmentPlan,DevelopmentCase.

2. Requirement&UseCases
a) Requirements:Tellswhatthesystemwilldo,ratherthanhowitwilldoit. b) RequirementAnalysis:beforewedoanythingatall,wehavetoaskourselveswhatwewantthesystemtodo. Toanswerthisquestion,itisnecessarytoconsider: i. businessneeds ii. availableresources iii. possibletechnologies iv. socialandlegalimplications c) Writingtherequirementsinvolves: i. Definingthepurposeofthesystem,prioritizingitsfunctionality,andspecifyingitscontext(i.e.whoareits usersandwhatsystemsdoesitinteractwith?). ii. Identifyingexternalinterfaces,bothhumanandsystemtosystem.Thetechnologyofanexistingsystem withwhichthesystemmustinterfacecanconstraintherequirementsanddesign. iii. Identifyingmajorfunctionalitythatmustbeprovidedbythesystemanddescribingit. iv. Documentingassumptionsuponwhichtherequirementsarebased.Iftheassumptionschange,thenso mighttherequirements. v. Communicatingwithusers,clients,businessanalystsanddeveloperssothatthesystemthatisdeveloped meetstheclientsexpectations. d) Somereasonsanorganizationmightstartanewsystemdevelopmentproject: i. newbusinessrequirements, ii. replacinganoldsystem, iii. themergingoftwoexistingsystemsduetoacquisitionandmerger,etc. e) LevelsandTypesofRequirements: i. Businessrequirementsthesedefinethehighlevelprocessesthatoccurinanorganization.Forexample,for aBankingsystem,whatisthepurposeofdevelopingthenewbankingsystem?Isitgoingtoreplaceanold systemorisitgoingtobeusedinanewlineofbusiness,etc.? ii. Systemrequirementswhatthecomputersystemmustdoforitsusers.Thesearethefunctional requirementsofthesystem. iii. Internalrequirementsrelatingtotechnology,personnel,hardwareplatformrequirements,etc.Theseare thenonfunctionalrequirements. f) ChallengesofWritingRequirements: i. ProblemDomainComplexity:Thebiggestchallengeisfindingoutabouttheproblemdomain(the environmentinwhichthesystemwilloperate,e.g.ourvideoshop). ii. PersontoPersonCommunication:Forsuccessfulrequirementsanalysis,groupsinvolvedneedtoconvey informationtooneanothereffectively. iii. ConstantChange:Changingrequirementsareaninevitableaspectofthesoftwaredevelopmentlifecycle. iv. WritingRequirementsinUP:Keyrequirementartifacts;UsecaseModelandSupplementarySpecifications.
www.oumstudents.tk

g) Actors:Actorsareentitiesoutsideofthesystemthatwillinteractwiththesystem.ThetermforUsersinUML. ThreekindsofRolesforActors: i. Primary:Apersoninthisroledirectlyusesthesystemtoenter,viewprocessorextractinformation. ii. Secondary:Apersoninthisroledoesnotdirectlyusethesystem,butusesorgeneratesdataforthesystem. iii. External: Anysystemthatreceivesorgeneratesdataforthesystem. h) WritingUseCases: i. FourStepProceduretodefineusecases: 1. Definetherightsystemboundary 2. Identifytheprimaryactors 3. Identifytheactorsgoals 4. Defineandnametheusecases. ii. Threetypesofformatforwritingusecases. 1. Briefusecaseithasoneparagraphsummaryandnormallyusedformainsuccessscenario. 2. Casualusecaseitisaninformalparagraphwhichhasmultipleparagraphsthatcovervarious scenarios. 3. Fullydressedthemostcomprehensivethatshowsallthestepsandvariations.Ithassupporting sections,suchaspreconditionsandsuccessguarantees.However,detaildiscussionaboutfullydressed usecaseisbeyondthesyllabus. i) UseCaseDiagrams:Itprovidesastaticviewofasystemtoallowustohavean overviewofthesystemandtherelationshipbetweentheusecasesaswellas theactorsofthesystem. j) ActivityDiagram:ActivitydiagramsareverysimilartoFlowChartdiagrams andtheydescribehowthingsflowandconnecttonextactions. k) PotentialProblemswithuseCases: i. Thesystemboundaryisundefinedorinconstant. ii. Theusecasesarewrittenfromthesystemspointofview. iii. Theactornamesareinconsistent. iv. Therearetoomanyusecases. v. Theactortousecaserelationshipsresembleaspidersweb. vi. Theusecasespecificationsaretoolong. ActivityDiagram vii. Theusecasespecificationsareconfusing. viii. Theusecasedoesntcorrectlydescribefunctionalentitlement. ix. Thecustomerdoesntunderstandtheusecases. x. Theusecasesareneverfinished. l) HowtoAvoidPotentialProblems: i. Explicitlydefinethesystemsboundary.Thismakesclearwhatisinsidethesystemandwhatisoutsidethe system. ii. Makeuseofastandardizedtemplatefordocumentingyourusecasespecifications. iii. Whenwritingusecases,focusonthegoalsoftheactors. iv. Dontmakeusecasespecificationsynonymouswithuserinterfacedesign. m) PossibilitiesofPackagingtheUseCase: i. Byfunctionalareas.Forexample,puteverythingtodowithmoneyinonepackageetc ii. Byactor.Forexample,putallthecashiersusecasesinonepackage. iii. Bystyleofusecase.Forexample,putallthesimplesetup/maintenancestyleusecasesinonepackage. iv. Byimportanceoriteration.Forexample,alltheusecasesthataregoingtobebuiltfirstinonepackage. v. Byphysicalimplementation.Forexample,alltheusecasesthataredeliveredviatheWeb

www.oumstudents.tk

3. ObjectOrientedModelling
a) OutcomeoftheInceptionPhaseshouldinclude: i. Visiondocument:ageneralvisionoftheprojectsrequirements,keyfeatures,andmainconstraints ii. Initialusecasemodel(1020%complete) iii. initialprojectglossary iv. Initialbusinesscase,whichincludesbusinesscontext,successcriteria(revenueprojection,market recognition,andsoon),andfinancialforecast v. Initialriskassessment vi. Projectplanshowingphasesanditerations vii. Businessmodel,ifnecessary viii. Oneorseveralsimpleprototypes. b) EvaluationCriteriafortheInceptionPhase: i. Stakeholdersagreeonscopedefinitionandcost/scheduleestimates ii. Requirementsunderstandingaspresentedintheprimaryusecases iii. Credibilityofthecost/scheduleestimates,priorities,risksanddevelopmentprocess iv. Depthandbreadthofanyarchitecturalprototypethatwasdeveloped v. Actualexpendituresversusplannedexpenditures. c) ElaborationPhase:Intheelaborationphase,anexecutablearchitectureprototypeisbuiltinoneormore iterations,dependingonthescope,size,riskandnoveltyoftheproject.MostCriticalofthefourphases. i. OutcomeoftheElaborationPhase: 1. Usecasemodel(atleast80%complete):allusecasesandactorshavebeenidentified,andmostuse casedescriptionshavebeendeveloped 2. Supplementaryrequirements:thesecapturethenonfunctionalrequirementsandanyrequirements thatarenotassociatedwithaspecificusecase 3. SystemSequenceDiagramsthatdescribetheeventsandtheirorder:thesearegeneratedbytheactors andthesystemorintersystemevents 4. Domainmodel:avisualizationofthingsinthedomainofinterest 5. Designmodel(partiallycomplete):asetofdiagramsthatdescribesthelogicaldesignofthesystem 6. Softwarearchitecturedocument:thissummarizesthekeyarchitecturalissuesandtheirresolutionin thedesign 7. Datamodel(partiallycomplete):thisincludesthedatabaseschemaandthemappingstrategies betweenobjectandnonobjectrepresentations 8. Testmodel(partiallycomplete):thisdescribeswhatwillbetested 9. Executablearchitecturalprototype 10. Revisedrisklistandarevisedbusinesscase 11. Developmentplanfortheoverallproject,includingthecoarsegrainedprojectplan,showingiterations andevaluationcriteriaforeachiteration 12. Updateddevelopmentcasespecifyingtheprocesstobeused 13. Preliminaryusermanual(optional). d) HierarchyofModelsinUP: i. ConceptualModelEnduserpointofviewofhowthingswouldworknothingofhowtheprocessing happens ii. LogicalModelHowthesystemshouldbedoneLogicallyhowthingswouldhappenIndependent iii. PhysicalModelCannotbechangedfromonemachinetoanother.Thefinaldesignmodel,showinghow thingswillbedoneorbuiltanddepictingallplatformdetails,datastorageandotherimplementationdetails.

www.oumstudents.tk

e) SystemSequenceDiagrams(SSD):illustrateeventsandoperationssequentially,starting withtheexternalactorsinputtothesystem. f) DomainModel:Arepresentationofthingsintherealworld,simplifiedversionofBusiness Model.Inadomainmodel,wehavethreetypesofinformation: i. Domainobject(orconceptualclass)whichidentifiesabusinessentityor concept,e.g.shop,videoCD,member,etc. ii. Associationsbetweendomainobjectswhichdefinerelevant relationships,thosethatcapturebusinessinformationthatneedstobe preserved,andtheirmultiplicity,e.g.ashophasmanyvideoCDs,a memberborrowsmanyvideoCDs. iii. Domainobjectattributeswhicharelogicaldatavaluesofanobject,e.g. eachmembermayhaveamembersnumberwhichisanattributeofthe objectmember. g) ConceptualClasses:Representssomethingphysicalorconceptualinabusiness.Threekindsare: i. Concreteobjects:aretangible,i.e.hasaphysicalpresence.EgVideoCD,Bananaetc ii. Conceptualobjects:areintangibleandoftenfarmoredifficulttounderstand.Eg.School,VideoTitleetc. iii. Eventandstateobjectsarehighlyabstractinnature.Theyarerelatedinthattypicallywhenaneventofany significanceoccurs,someormoreobjectswillswitchtoadifferentstate.Anexampleofaneventandstate objectinthevideoshopisborrowvideo.Wecanseethatborrowvideoeventswilltypicallychangethe status(e.g.borrowvideolist)oftheobject. h) SpecificationConceptualClasses:Whenitsappropriatetouse: i. Thereisaneedtodescribeaboutanitemorservice,independentofthecurrentexistenceoftheseitemsor services ii. Deletinginstancesofthingsthattheydescribe(forExample:Item)resultsinalossofinformationthatneed tobemaintained iii. Itreducesduplicatedinformation i) Associations:Anobjectorientedtermforrelationship.InUML,an associationisarelationshipexpressingtheinteractionbetweeninstancesoftwoconceptualclasses, representedbytheverbthatdescribeswhattheydotoeachother,and/orbythenounsfortherolesthateach playsinthelifeoftheother. i. Multiplicity:Thenumberofinstancesofeachclassthatcan participateinanoccurrenceoftheassociation. j) Attributes:arethepiecesofdataweusetoidentifyordescribe things.Eg.apersonhasaname,dateofbirthandeyecolour. i. Criteriatoeliminateunnecessaryandincorrectattributes: 1. Iftheindependentexistenceofanentityisimportant,ratherthanjustitsvalue,thenitisaseparate class. 2. Anentitythathasfeaturesofitsownwithinthegivenapplicationisaseparateclass. 3. Ifthevalueofanattributedependsonaparticularcontextthenconsiderrestatingtheattributeasa qualifier. 4. Anameisaclassattributewhenitdoesnotdependoncontext,especiallywhenitneednotbeunique. 5. Donotlistobjectidentifiersthatareusedpurelyforunambiguouslyreferencinganobject. 6. Ifanattributedescribestheinternalstateofaclassthatisinvisibleoutsidetheclasstheneliminateit fromtheanalysis. 7. Omitminorattributesthatareunlikelytoaffectmostoperations.
www.oumstudents.tk

4. MoreUseCases
a) ThreeKindsofRelationshipsBetweenUseCases: i. Include:Typicallywhereasetofusecaseseachincludessome commonfunctionalitythatisexpressedinone sharedsubusecase. ii. Extend:Wherethefunctionalityofausecaseisextendedbyreferencingotherusecases;and iii. Generalize:Whereseveralusecasessharesomethingsimilar. b) StateDiagram:Astatediagramshowsthelifecycleofanobject: whateventsitexperiences,itstransitions,andthestatesitisin betweentheseevents.Onthesediagramswethenwritetheusecase names,whichindoingso,weoftendiscovermissingusecases. c) CRUD(Create+Read+Update+Delete):Secondtechniquethat helpsustofindmissingusecases.Weneedtoexamineeveryclassin theconceptualclassdiagramtoensurethateitherwehaveallof StateDiagramshowingSuperState theseoperations,orwecandecidenottoincludethem. d) BusinessRules:Probablythemostbasicpartofrequirementsanalysisandshouldbedoneconcurrentlywith theusecasemodeling.Besidestheirroleintheusecases, businessrulesarealsolinkedtootherartifactsinthe softwaredevelopmentprocess. e) RobustnessDiagram: i. Robustnessanalysis(UseCaseAnalysis):Involves analyzingthenarrativetextofusecasesandidentifyinga firstguesssetofobjectsthatwillparticipateineachusecase. Thistechniquecanhelpustoproduceapreliminarydesign. Robustnessdiagramshelpuscrossthedividefromanalysisto design.Theobjectsonrobustnessdiagramscanbeclassified intothreetypes,namely: 1. BoundaryObjects: Representall connectionsbetween theinternalobjectsof thesystemandtheoutsideworld.Eg.UserInterfacelike WindoworDialoguebox,BarcodeReadersetc 2. EntityObjects:Objectsthatrepresentdatathathavetobe rememberedbythesystem,eitheronamorepermanent basisbeyondtheexecutionoftheusecase(suchdata mightbestoredinadatabasetable),orfortheexecution ofausecase. 3. ControllerObjects:Representanythingelseyoufindyou needtomakethewholediagrammakesense.Eg.business rulesorprocessesthatarecapturedbyausecase

www.oumstudents.tk

5. DynamicModelling
a) DesignModel:InthedesignModel,wewillproducetwodiagrams: i. Designclassdiagram:Definingclassesandtherelationshipsbetweenthem.Itrepresentsthestaticaspectof thedesignmodel. ii. Interactiondiagrams:whichdefineclass/objectinteractions.Theyrepresentthedynamicaspectofthe designmodel.Therearetwotypesofinteractiondiagrams,namelythesequencediagramsandthe collaborationdiagrams. b) Class:Acollectionofobjectswithcommonstructures,behaviors,relationshipsandcommonsemantics. i. IdentifyingClasses: 1. Usetherequirementsmodel/usecases/domainmodel,andfindthenouns.Thesewillmostlikelybe classes. 2. Usethetechniqueofrobustnessanalysisto identifyadditionalclasses. 3. Suggestresponsibilities. 4. Identifyattributes. 5. Identifyoperations. ii. InUML,aclassisdrawnasarectanglewiththree compartments:onefortheclassnameandany modifiers,oneforattributesandoneforoperations. iii. Attribute:Thestructureofaclassisrepresentedby itsattributes.Hasanameandtypeseparatedbya colon: iv. Operations:Behaviorofaclass/objectthatactsupontheattributesintheclass/object.Canhaveinput(in), output(out)andinput/output(inout)arguments.Allargumentshaveanameandtype(separatedbya colon)andareprefixedbythetermdescribingwhattypeofargumenttheyare. v. ThreetypesofoperationsexistinginaClassDiagram: 1. Constructoroperationisusedtocreatenewobjects foraclassbygivinginitialvaluesfortheattributes. Thenameoftheconstructoroperationissamewith thenameoftheclass. 2. Queryoperationisusedtoaccessonlytheobjects stateandthisoperationdoesnotchangethestateof aobject(e.g.getName,getPay,RetrieveID,checkPassword,etc). 3. Updateoperationisusedtoupdateorchangethevalueofattribute(s)ofaobject.Thisupdate operationwillchangethestateoftheobject(e.g.setName,updateAge,etc). vi. Tospecifyanobject,wealsousearectangle,butthenameis underlined. c) InteractionDiagram:Usedtodefinetheclass/objectinteractionswithinthesystem.Theyshowthedynamic aspectofthesystem,e.g.theflowofmessages.Twotypesare: i. Collaborationdiagrams:Depictaninteractionamongelementsofasystemandtheirrelationshipsorganized intimeandspace.Itselementsare: 1. Classes,denotedasclassrectangles,torepresent theobjectsinvolvedintheinteraction. 2. Associationroles,whichrepresentrolesthat linksmayplaywithintheinteraction. 3. Messages,denotedaslabeledarrows,to representmessagessentbetweenobjects.The
www.oumstudents.tk

arrowpointsfromtheobjectthatsendsthemessagetothereceivingobject.Optionally,parametersare passedaspartofthemessage;andalsooptionally,someinformation,oranotherobjectispassedback. ii. Sequencediagrams:Sequencediagramsdepictaninteractionamongelementsofasystemorganizedin timesequence.Itselementsare: 1. Classroles,denotedasclassrectangles, representrolesthatobjectsmayplaywithinthe interaction. 2. Lifelines,denotedasdashedlines,represent theexistenceofanobjectoveraperiodoftime. 3. Activations,denotedasthinrectangles, representthetimeduringwhichanobjectis performinganoperation. 4. Messages,denotedaslabeledhorizontalarrowsbetweenlifelines,representcommunicationbetween objects. d) DesignClassDiagram:Describesclassesthatwillexistinsoftware. i. Visibility:Thevisibilityofanattributeormethodwithinaclassdetermineswhatotherobjectscanaccessit. Itisadesirabledesignpracticetokeepattributesofyourclassprivate,providingaccesstothemthrough accessormethods.Theoptionsare: 1. Publicvisibilitydenotedby+inUML(orbyaniconinthetool)meansthatobjectsofanyclasscan usetheattributeoroperation. 2. Protectedvisibilitydenotedby#inUML(orbyaniconinthetool)meansthatonlyobjectsofthat classoritssubclassescanusetheattributeoroperation. 3. PrivatevisibilitydenotedbyinUML(orbyaniconinthetool)meansthatobjectsofonlythatclass canusetheattributeoroperation. ii. Association:Anassociationisaconnectionbetweenclassesandisshownasalineconnectingtherelated classes.Iftherearenoarrowsontheline,itisassumedtobebidirectional. iii. Composition(UsesaRelationship):(a.k.a.compositeaggregation)isastronger formofaggregationwherethepartiscreatedanddestroyedwiththewhole.Eg.A rectangleismadeupofseveralpoints.Iftherectangleisdestroyed,soarethepoints.(FilledDiamond) iv. Aggregation(HasaRelationship):Inanaggregationrelationship,thepartmaybe independentofthewholebutthewholerequiresthepart.Eg.Anorderismadeupof severalproducts,butaproductcontinuestoexisteveniftheorderisdestroyed.(UnfilledDiamond) v. DifferencesbetweenConceptualandDesignClassDiagrams Concept Conceptual Design Classes YesRepresentsRealWorldEntities YesRepresentsSoftwareClasses AddsdirectiontotheHasarelationships. PassMessagestoClasses Inheritcode Yes AddmoreAttributes AddTypes Addmanymore, withfullparameters

Hasa Relationships Navigationisirrelevant Inheritance Cardinalities IsaRelationship Yes

Showkeyones Attributes Typesareoptional Methods

www.oumstudents.tk

Usuallyveryfew

e) Inheritance(IsaRelationship):Capabilityofaclasstousethe propertiesandmethodsofanotherclasswhileaddingitsown functionality.(FilledArrow) i. Polymorphism:Capabilityofanactionormethodtododifferent thingsbasedontheobjectthatitisactingupon.Eg.Whilegivingthecommandtoprintafile,theowner objectdoesnotneedtoknowwhattypeofdocumentitisbeforegivingthecommand.Itmeansthatthe exactcodeofthemethodwillchangeaccordingtotheclass oftheobjectthatreceivesthemessage. ii. Concrete&AbstractClasses:AreSpecified ineitherItalicsorthewordconcreteor abstractareaddedwithincurlybrackets. 1. AbstractClass:Aclassthatneverhas anyobjects(thatwecanphysicallytouch).Eg.GroupingslikeFruitsetc.Abstractclassesshouldnot inheritfromconcreteclasses 2. ConcreteClass:Aclassthathasobjects(thatwecanphysicallytouch).Eg.Apple.Concreteclasses shouldalwaysbetheleaves f) DesignPrinciples: i. Coupling:Strengthofassociationbetweentwoclasses.Strongcouplingisbad.Fourbasicformsofcoupling: 1. Identitycoupling:measuresthelevelofconnectivityofadesign.Thisisshownasanassociationona classdiagram.Aonewayassociationislesscoupledthanatwowayassociation. 2. Representationalcoupling:Measureofhowoneobjectaccessesthedataofanotherobject. 3. Subclasscoupling:Whenaclientclassdirectlyreferencesasubclassratherthanitssuperclass.Thisisto beavoidedwhereverpossible. 4. Inheritancecoupling:Asubclassisrelatedtoitssuperclassbyinheritancecoupling. ii. Cohesion:Measureofhowfocusedthefunctionalityofaclassis.Highcohesionifclassrepresentsonlyone idea.Eg.TheclassVideoSpecificationdefinesaparticulartitleofamovie.Ittellsussomethingaboutthat movie(itsname,theactors,yearitwasmade,ratings,andsoon).TheclassVideoisallaboutoneparticular tapeofavideospecification.ThusVideoandVideoSpecificationareseparateclasses.Iftheyweremerged intoone,theresultingclasswouldnothavehighcohesion.

www.oumstudents.tk