LABORATORY

FILEON

SOFTWARE ENGINEERING LAB

KCS651SUBMITTED FOR

B.TECHINCOMPUTERSCIENCEANDENGINEERINGAT

AMBALIKA INSTITUTE OF MANAGEMET AND

TECHNOLOGY,LUCKNOWDR.A.P.JKALAMTECHNICAL
UNIVERSITYLUCKNOW

SESSION-2023-24

SUBMITTEDTO: SUBMITTEDBY:
MR.SUSHEELKUMAR CSE-3RDYEAR(6THSEM)
ASST.PROFESSOR ROLLNO:

2
 INDEX

SL NAMEOFEXPERIMENT DATE SIGN REMARK

10

11

3
 1
IntroductionandProjectDefinition

Use-Case Class State addfile

addfile[numberOffile==M AX] Writing

/flagOF F

Openning

clos efile

clos efile Clos ing

Reading

Deployment
Clas Diagram

Package
Diagram

ComponentForwardEngineering(Code
Collaboration Diagram
Genera
tion)and

SourceCodeedit,compile,debug,

Sequence

Executable

4
 Lab1:IntroductionandProjectDefinition
Objectives
● Introducethelabenvironmentandtoolsusedinthesoftwareengineeringlab:WebCTand
SynchEye.
● Discussthe Project&learnhowtowriteprojectdefinition.

1. Outline
● GettingfamiliarwithWebCT.
● GettingfamiliarwithSyncronEye.
● Introductiontothelab planand objectives.
● Projectdefinition.

2. Background
Thesoftwareengineerisakeypersonanalyzingthebusiness,identifyingopportunitiesforimprovement,
and designing information systems to implement these ideas. It is important tounderstand and
develop through practice the skills needed to successfully design and
implementnewsoftwaresystems.

2.1 Introduction
● In this lab you will practice the software development life cycle (project
management,requirements engineering, systems modeling, software design, prototyping,
and testing)usingCASE tools withinateamwork environment.
● UMLnotationis coveredinthis labasthemodelinglanguageforanalysisanddesign.

2.2 Tools UsedintheLab

● SWElabisoneofthemostchallengingofalllabs.Developingacompletesoftwareapplicationreq
uiresfromeach ofyouagoodlevelof know-howof various tools.
● Therearesometoolswhichwillbetaught,buttherearesomewhichareassumedyoualreadyknow,
ifyoudon’t, then youlearnshoulditindividually.
o MSSourceSafe:forconfigurationmanagement
o MSProject:forprojectplanning/management
o RationalRose:forUMLdiagrams(objectorientedanalysisanddesign)
o RationalRequisitePro:forsoftwarerequirementspecification(SRS)documentation.
o JUnit:for testingsoftware

2.3 Software EngineeringLabObjectives

● Learn
thesoftwarelifecyclephases(projectmanagement,requirementsengineering,softwaredesign,
prototypingandtesting).
● Practicethesoftwarephasesusingaproject.
● Learna numberofCASEtoolsandusethemina projectwithina teamworkenvironment.
● GetfamiliarwithUML(modelinglanguageforanalysisanddesign).

5
2.4 LabPlan
Week # LabContent Deliverables Tool

Week 1 Nolab
Week 2 Introduction and project
definition
Week 3 Softwareprocessoverview Configuration management
tool(Sourcesafe)
Week 4 Projectplanning Management tool (MS
project)
Week 5 Software requirements and Plan doc Requirement documentation
RequisitePro tool(RequisitePro)
Week 6 IntroductiontoUMLanduse Requirementanddesigntool
case diagrams (RationalRose)
Week 7 Systemmodeling(DFDandER) MicrosoftWord

Week 8 Flowofeventsandactivity SRS doc RationalRose

diagram
Week 9 OO analysis: discovering RationalRose
classes
Week 10 Interactiondiagrams:sequence RationalRose
andcollaborationdiagrams
Week 11 Software Design: Designdoc(ver.1) RationalRose
softwarearchitectur
e and object-
orienteddesign
Week 12 StateTransitionDiagram RationalRose
Week 13 Componentand deployment Designdoc(Final RationalRose
diagrams ver.)
Week 14 Softwaretesting Testingtool(JUnit)
Week 15 Presentations Testing doc and
user manual

3. CASETools
Notoolsareusedfor thislab.

4. In-ClassExample
Someexamplesofproblemdefinitionwillbe presentedinthe class.

5. Exercises
● Formgroupsof3 students(withoneofthemas a leader).
● Brainstormandlist5suitableprojecttitles.
● Presentthesetotheclass.
● Chooseoneofthe projectsfromyourlist.
● Trytowrite(ahypothetical)projectdefinitionforit.
● Presentittotheinstructor/class.

6. Deliverables
● Formteamsof4studentsforthetermproject.
● Submittheir IDs,names,sectionbyemailwithinthisweek.
● Suggest/researcha projectandwritea projectdefinition/problemstatement.

6
 2
Software Processes
andVisualSourceSaf
e

7
 Lab2:SoftwareProcessesandVisual SourceSafe
Objectives
● Obtaina deeperunderstandingofsoftwareprocessmodelsandsoftwareprocesses.
● Becomefamiliarwithaconfigurationmanagementcasetool(MicrosoftVisualSourceSa
fe).

1. Outline
● Reviewofthebasicsoftware processmodelsandsoftware processes.
● VisualSourceSafetutorial.

2. Background
IEEE defined a software process as: “a set of activities, practices and transformations that
peopleuse to develop and maintain software and the associated products, e.g., project plans,
designdocuments,code, testcases andusermanual”.

Followingthesoftwareprocesswillstabilizethedevelopmentlifecycleandmakethesoftwaremoremanag
eable and predictable. It will also reduce software development risk and help to organize thework
products that need to be produced during a software development project. A well-managedprocess
will produce high quality products on time and under budget. So following a
maturesoftwareprocessis a key determinanttothesuccessofasoftwareproject.

A number of software processes are available. However, no single software process works well
foreveryproject. Each processworks bestincertainenvironments
Examplesoftheavailablesoftwareprocessmodelsinclude:theWaterfallmodel(theLinearmodel),the
evolutionary development, the formal systems development, and reuse-based (component-based)
development. Other process models support iteration; these include: the Incremental
model,theSpiralmodel, andExtremeProgramming.

3. CASETools
VisualSource Safe (VSS)isMicrosoft'sversion of asource controlprogram
(configurationmanagement) thatenables youtokeeptrackofmultipleversionsofdocuments.

Software Configuration Management is a set of activities that have been developed to

managechangethroughoutthelifeofcomputersoftware.Theseactivitiesaredesignedtocontrolchangeby
identifying the work products that are likely to change, establishing relationships among
them,defining mechanisms for managing different versions of these work products, controlling
thechangesimposedandauditing thereporting onthechangesmade.

With VSS you can go back to an earlier bug-free version of the source code to try to track
downwherethebugwasintroduced,compareversionsofadocumentandrecoveracopyofthedocumenttha
tyousavedweeksormonths ago.

8
3.1 HowDoesItWork?
In order for Visual Source Safe to manage your documents, you must first check them in to
VSS.WhenyoufirstcheckafileintoVSS,theprogramrecordsthecontents ofthis
originalversion.Thedocument then becomes read-only to prevent you from making changes that
VSS cannot track.When you want to edit a document that is under source control, you must check
the document outof VSStogetawritablecopy.
When you are finished editing the document, you save the document and then check it back in
toVSS.VSSwillthencontaintwo"versions"ofthedocument:theoriginalandthenewedit.Inreality,VSS
does not keep two full copies. It keeps the original document, and a small file describing
thedifferencesbetweentheoriginalandtheeditedversion.Ifyoueditthedocument100times
overthecourse of a year, you will have access to all 100 versions in VSS, without having to use all
of thediskspacethat100 copiesofthedocumentwould occupy.

3.2 WhyIsItUseful?
VSS lets you view any version of your document, or check out any version for further editing.
Italso lets you pick any two versions-- say, draft 6 and draft 31-- and compare them with the
Diffutility.Thiscomparisonshowsthetwodocumentssidebyside,withthedifferenceshighlightedandcol
or-coded. VSS also enables you to attach comments to each revision; these comments may ormay
not appear in the document itself, depending on how you configure the program. But
thecommentscanbeviewedindependentlyofthedocumentsthemselves.

Another very useful feature of VSS is labeling. Labeling provides a simple way of knowing
whichversions of which documents belong together in a group. VSS was designed for
environments
inwhichmultipleusersareeditingthesamedocuments.Itpermitsonlyoneuseratatimetoediteachdocume
nt, thereby guaranteeing that only one authoritative "latest version" of a document exists
atanygiventime.

4. In-ClassDemo
AdemonstrationwillbegivenshowthebasicfunctionsofVSSinordertomanageyourfiles.Thesefeaturesi
nclude:
a. Creatinganewproject.
b. Checkingfilesinandout.
c. Labelingfiles.
d. Viewingrevisionhistory.
e. UsingDifftoshowdifferences.
f. UsingSearchtofinddocuments.
FormoreinformationonsoftwareprocessesandVSStutorialpleaserefertoLab2slideswhichcontainan
overviewofsoftwareprocesses and VSStutorialslides.

5. Exercises
● Createaprojectandaddsomejavafiles toit(atleast3files).
● Labeltheexistingfiles.
● Checkoutallthefilesandmodifyoneofthem.
● Checktheeditedfilebackin.
● Viewtherevisionhistoryoftheeditedfileandshowthedifferencesbetweentheoldandthenewver
sions.
● Searchfor anyuncheckedinfiles.
After you perform all of the previous tasks, create a new project for your term project. If any
filesofyourtermprojectareready,youneedtocheckthemin.Youneedtomanageallyourtermprojectfilesu
singSourceSafe.

6. Deliverables
Youshouldsuccessfullydemonstrate that allthe exercisetaskswere
implemented.AlsoyourVSSprojectforyourtermprojectshouldbecreatedandanyavailablefiles

9
shouldbecheckedin.

1
0
 3
Project Planning
andManagement

1
1
SoftwareEngineering LabManual(ICS413)

Lab3:ProjectPlanningandManagement
Objectives
● Gainunderstandingofproject management.
● Learnhowtoprepareprojectplans.
● Learnaboutprojectrisks.
● LearnMSProjectcasetool.

1. Outline
● Projectworkplanning.
● Riskmanagement.
● MSproject.
● Examples.

2. Background
Project management is the process of planning and controlling the development of a system
withinaspecifiedtimeframeataminimumcostwiththerightfunctionality.

2.1 ProjectWorkPlan
Preparealistofalltasksinthe workbreakdownstructure,plus:
● Durationoftask.
● Currenttaskstatus.
● Taskdependencies.
● Keymilestonedates.

2.2 Tracking Progress

● GanttChart:
o Barchartformat.
o Usefultomonitor projectstatusatanypointintime.
● PERTChart:
o Flowchartformat.
o Illustratetaskdependenciesandcriticalpath.
2.3 RiskManagement
● Riskmanagementisconcernedwithidentifyingrisksanddrawingupplanstominimizetheir
effectonaproject.
● Ariskisa probabilitythatsomeadversecircumstance willoccur.
● Projectriskswhichaffectscheduleor resources.
● Productriskswhichaffectthequalityor performanceofthesoftwarebeingdeveloped.
● Businessriskswhichaffectthe organizationdevelopingthesoftware.

2.4 RiskManagementProcess
● Riskidentification:identifyproject,productandbusinessrisks.
● Riskanalysis:assessthelikelihoodandconsequencesoftheserisks.
● Riskplanning:drawupplanstoavoidorminimizetheeffectsoftherisk.
● Riskmonitoring: monitortherisksthroughouttheproject.
3. CASETools
● MicrosoftProjectistheclearmarketleaderamongdesktopprojectmanagementapplications.
● PrimaveraProjectPlanner:multi-project,multi-
userproject,andresourceplanningandscheduling.
● SureTrakProjectManager:resourceplanningandcontrolforsmall-to-mediumsizedprojects.
● AccordingtotheGartnerGroup,itaccountsforabouttwo-
thirdsofallprojectmanagementsoftwaresales.

12
SoftwareEngineering LabManual(ICS413)

MSProjectJumpStart LiveDemo

4. In-ClassDemo
Now you will learn how to apply the above mentioned methods to draw a Gantt chart or
Activitychart for the project. Please refer to Lab 3 slides which explain the process in detail with
someexamples.

5. Exercises
UseMSProject2002tocreatea seriesoftasksleadingtocompletionofa
projectofyourchoice.Foryourproject,youneedto:
● Setstartorendingdates.
● Developalistoftasks thatneedtobecompleted.
● Establishanysub tasks andcreatelinks.
● Createanylinksbetweenmajortasks.
● Assigna specificamounttimeforeachtask.
● Assignresourcesforeachtask.
● Createtaskinformationforeachitemyou putintothelist.

6. Deliverables
Youshouldsubmitthesolutionsfor thepreviousexercises.
YoushoulduseMSProjecttocreateaplanandtimeschedulefor your termproject.

13
SoftwareEngineering LabManual(ICS413)

4
Software
RequirementSpecific
ation(SRS)

14
SoftwareEngineering LabManual(ICS413)

Lab4:SoftwareRequirementSpecification(SRS)
Objectives
● Gainadeeperunderstandingof the Software RequirementSpecificationphase
andtheSoftwareRequirementSpecification(SRS).
● Learnhowtowriterequirementsandspecifications.
● GainexposuretorequirementsmanagementusingRequisitePro.

1. Outline
● Reviewoftherequirementsengineeringprocess.
● Writerequirementsandspecifications.
● RequisiteProtutorial.
● SoftwareRequirementSpecification(SRS).

2. Background
A requirement is a statement of a behavior or attribute that a system must possess for the system
tobeacceptabletoastakeholder.

SoftwareRequirementSpecification(SRS)isadocumentthatdescribestherequirementsofacomputer
systemfromtheuser'spointofview. AnSRSdocumentspecifies:
● Therequiredbehaviorofasystemintermsof:inputdata,requiredprocessing,outputdata,operatio
nalscenarios andinterfaces.
● Theattributesofasystemincluding:performance,security,maintainability,reliability,availabil
ity,safetyrequirements anddesignconstraints.

Requirements management is a systematic approach to eliciting, organizing and documenting

therequirements of a system. It is a process that establishes and maintains agreement between
thecustomer and theprojectteamonthechangingrequirementsofasystem.

Requirements management is important because, by organizing and tracking the requirements

andmanagingtherequirementchanges,youimprovethechancesofcompletingtheprojectontimeandund
er budget.Poor changemanagementisakeycause ofprojectfailure.

2.1 RequirementsEngineeringProcess
Requirementsengineeringprocessconsists offourphases:
● Requirementselicitation:gettingthecustomerstostateexactlywhattherequirementsare.
● Requirements analysis: making qualitative judgments and checking for consistency
andfeasibilityofrequirements.
● Requirements validation: demonstrating that the requirements define the system that
thecustomer reallywants.
● Requirements management: the process of managing changing requirements during
therequirements engineering process and system development, and identifying missing
andextrarequirements.

15
SoftwareEngineering LabManual(ICS413)

2.2 WritingRequirements
Requirementsalwaysneedtobecorrect,unambiguous,complete,consistent,andtestable.

2.2.1 RecommendationsWhenWritingRequirements
● Never assume:othersdonowknowwhatyouhaveinmind.
● Usemeaningful words;avoidwordslike:process,manage,perform,handle,andsupport.
● Staterequirements notfeatures:
o Feature:general,testedonlyforexistence.
o Requirement:specific,testable,measurable.
● Avoid:
o Conjunctions:askyourselfwhethertherequirementshoulditbesplitintotworequireme
nts.
o Conditionals:if,else,but,except,although.
o Possibilities:may,might,probably,usually.

2.3 WritingSpecifications
Specification is a description of operations and attributes of a system. It can be a document, set
ofdocuments, a database of design information, a prototype, diagrams or any combination of
thesethings.

Specifications are different from requirements: specifications are sufficiently complete ─ not
onlywhatstakeholderssaytheywant;usually,theyhavenoconflicts;theydescribethesystemasitwillbebu
iltandresolveanyconflictingrequirements.

Creatingspecificationsisimportant.However,youmaynotcreatespecificationsif:
● Youareusingaveryincrementaldevelopmentprocess(smallchanges).
● Youarebuildingresearchorproofofconceptprojects.
● Yourebuildingverysmallprojects.
● Itisnotcheaperor fasterthanbuildingthe product.

2.4 SoftwareRequirementSpecification(SRS)
Rememberthatthereisno“PerfectSRS”.However,SRS shouldbe:
● Correct:eachrequirementrepresentssomethingrequiredbythetargetsystem.
● Unambiguous:everyrequirementinSRShasonlyoneinterpretation
● Complete:everythingthetargetsystemshoulddoisincludedinSRS(nosectionsaremarkedTBD
-tobedetermined).
● Verifiable:thereexistssomefiniteprocesswithwhichaperson/machinecancheckthattheactuala
s-builtsoftwareproductmeets therequirements.
● Consistentinbehaviorandterms.
● Understandablebycustomers.
● Modifiable:changescanbe madeeasily,completelyandconsistently.
● Designindependent: doesn'timplyspecificsoftwarearchitectureoralgorithm.
● Concise:shorterisbetter.
● Organized:requirementsinSRSareeasytolocate;relatedrequirementsaretogether.
● Traceable: each requirement is able to be referenced for later use (by the using
paragraphnumbers,onerequirementineachparagraph,orbyusingconventionforindicationreq
uirements)

16
SoftwareEngineering LabManual(ICS413)

3. CASETools
RequisitePro is a powerful, easy-to-use requirements management tool that helps teams
manageproject requirements comprehensively, promotes communication and collaboration among
teammembers, and reduces project risk. It thereby increases the chances of delivering a product
that theclientwants and does soinatimelymanner.

RequisitePro offers the power of a database and Microsoft Word and is integrated with
otherRationalSuiteproducts.

4. In-ClassDemo
AnoverviewofthebasicfeaturesofRequisiteProwillbepresented.Intheexercisesectionyouwillpractice
andapplywhatyouhavelearnedinthetutorial.Pleaserefertolab4slides whichcontainatutorial on
RequisitePro and an overview of the requirements engineering process, and
writingrequirementsandspecifications.

5. Exercises
a. Arethefollowingrequirementsvague? Ifyes,why?Canyoufixthem?
o Thefeatureisresponsibleformanagingconnections.
o Thefeatureallowsuserstoperformadministrativefunctions.

b. PerformeachofthefollowingtasksusingRequisitePro:
o Createanewproject.
o Createanewpackage.
o CreateandaddsomerequirementswithinRequisitePro.
o Createarequirementdocument.
o Createanewview.

6. Deliverables
● Youshouldsubmitthesolutionsforexercise5.a.
● Youshouldshowthatyouhavesuccessfullyperformedallthetasks listedinexercise5.b.
● Also during the requirementphase ofyourterm project,you should use RequisitePro
tomanageyourrequirements.

17
SoftwareEngineering LabManual(ICS413)

5
IntroductiontoUMLandUseC
aseDiagram

18
SoftwareEngineering LabManual(ICS413)

Lab5:IntroductiontoUMLandUseCaseDiagram
Objectives
• Studythebenefitsofvisual modeling.
• Learnusecasediagrams: discoveringactorsanddiscoveringusecases.
• PracticeusecasesdiagramsusingRationalRose.

1. Outline
● Visualmodeling.
● IntroductiontoUML.
● IntroductiontovisualmodelingwithUML.
● Usecase diagrams:discoveringactorsandusecases.

2. Background
Visual Modeling is a way of thinking about problems using models organized around real-
worldideas. Models are useful for understanding problems, communicating with everyone
involved withthe project (customers, domain experts, analysts, designers, etc.), modeling
enterprises, preparingdocumentation,and designing programs and databases

2.1 VisualModeling
● Capture thestructureandbehaviorofarchitecturesandcomponents.
● Showhowtheelementsofthesystemfittogether.
● Hideorexposedetailsappropriateforthetask.
● Maintainconsistencybetweenadesignanditsimplementation.
● Promoteunambiguouscommunication.

2.2 What isUML?

The UML is the standard language for visualizing, specifying, constructing and documenting
theartifacts of a software-intensive system. UML can be used with all processesthroughout
thedevelopmentlifecycleandacrossdifferentimplementationtechnologies.

2.3 HistoryofUML
The UML is an attempt to standardize the artifacts of analysis and design:
semanticmodels, syntactic notation and diagrams. Thefirst public draft (version 0.8)
wasintroduced in October 1995. Feedback from the public and Ivar Jacobson's input
wereincludedinthenexttwoversions(0.9inJuly1996and0.91inOctober1996).Version
1.0waspresentedtotheObjectManagementGroup(OMG)forstandardizationinJuly1997.
Additionalenhancementswereincorporatedintothe1.1versionofUML,whichwas
presented to the OMG in September 1997. In November 1997, the UML
wasadoptedasthe standardmodelinglanguagebytheOMG.

2.4 PuttingUMLintoWork:Use CaseDiagram

The behavior of the system under development (i.e. what functionality must be provided by
thesystem) is documented in a use case model that illustrates the system's intended functions
(usecases), its surroundings (actors), and relationships between the use cases and actors (use
casediagrams).

2.5 Actors
● AreNOTpartofthesystem–theyrepresentanyoneoranythingthatmustinteractwiththesystem.
● Onlyinputinformationtothesystem.
● Onlyreceiveinformation fromthesystem.
● Bothinput toandreceiveinformationfromthesystem.
● RepresentedinUMLasastickman.

17
SoftwareEngineering LabManual(ICS413)

2.6 UseCase
● Asequenceoftransactionsperformedbyasystemthatyieldsameas
urableresultofvaluesfor aparticular actor
● A use case typically represents a major piece of
functionalitythat is complete from beginning to end.A use
case mustdeliversomethingofvaluetoanactor.

2.7 UseCaseRelationships
● Betweenactor andusecase.
● Association/Communication.
● Arrow can be in either or both directions; arrow indicates who
initiatescommunication.
● Betweenusecases(generalization):
– Uses
• Wheremultipleusecasessharepiecesofsamefunctionality.
– Extends
• Optionalbehavior.
• Behavioronlyrunsundercertainconditions(suchasalarm).
• Severaldifferentflowsrunbasedontheuser’sselection.

3. CASETools
TheRationalRoseproductfamilyisdesignedtoprovidethesoftwaredeveloperwithacomple
te set of visual modeling tools for development of robust, efficient solutions toreal
business needs in the client/server, distributed enterprise and real-time
systemsenvironments. Rational Rose products share a common universal standard,
makingmodeling accessible to nonprogrammers wanting to model business processes
as wellastoprogrammersmodelingapplicationslogic.

4. In-ClassExample
Nowyouwilllearnhowtoapplytheabove-mentionedmethodstodrawusecasediagramsfromtheproblem
statement. Please refer to Lab 5 slides which explain the process in detail with someexamples.

18
SoftwareEngineering LabManual(ICS413)

5. Exercises
Readcarefullythefollowingproblemstatement
Weareafterasystemthatcontrolsarecyclingmachineforreturnablebottlesandcans.Themachinewillallo
wacustomertoreturnbottlesor cansonthesameoccasion.

Whenthecustomerreturnsanitem,thesystemwillcheckwhattypehasbeenreturned.Thesystemwill
register how many items each customer returns and, when the customer asks for a receipt,
thesystemwillprintoutwhathedeposited,thevalueofthereturneditemsandthetotalreturnsumthatwillbe
paidto thecustomer.

The system is also be used by an operator. The operator wants to know how many items of
eachtypehavebeenreturnedduringtheday.Attheendoftheday,theoperatorasksforaprintoutofthetotal
number of items that have been deposited in the machine on that particular day. The
operatorshould also be able to change information in the system, such as the deposit values of the
items.
Ifsomethingisamiss,forexampleifacangetsstuckorifthereceiptrollisfinished,theoperatorwillbecalled
byaspecialalarmsignal.

Afterreadingtheaboveproblemstatement,find:
1. Actors
2. Usecaseswitheachactor
3. Findextendedorusesusecases(ifapplicable)
4. Finally:drawthemainusecase diagram:

6. Deliverables
Youshouldsubmitthesolutionsforthepreviousexercises.
YoushouldusethesetechniquestodrawusecasediagramsforyourtermprojectusingRationalRose.

19
SoftwareEngineering LabManual(ICS413)

6
SystemModeling

20
SoftwareEngineering LabManual(ICS413)

Lab 6:SystemModeling
Objective:
DeeperunderstandingofSystemmodeling:
● Datamodel:entity-relationshipdiagram(ERD).
● Functionalmodel:dataflowdiagram(DFD).

1. Outline
Systemanalysismodelelements:
● Datamodel:entity-relationshipdiagram(ERD)
● Functionalmodel:dataflowdiagram(DFD)

2. Background
Modeling consists of building an abstraction of reality. These abstractions are
simplificationsbecause they ignore irrelevant details and they only represent the relevant details
(what is relevantor irrelevantdependsonthepurposeofthemodel).

2.1 WhyModelSoftware?
Softwareisgettinglarger,notsmaller;forexample,WindowsXPhasmorethan40millionlinesofcode. A
single programmer cannot manage this amount of code in its entirety. Code is often notdirectly
understandable by developers who did not participate in the development; thus, we
needsimplerrepresentationsforcomplexsystems(modelingisa meanfordealingwithcomplexity).

A wide variety of models have been in use within various engineering disciplines for a long
time.Insoftwareengineeringanumberofmodelingmethods arealsoavailable.

2.2 AnalysisModelObjectives
● Todescribe whatthecustomerrequires.
● Toestablishabasisfor thecreationofasoftware design.
● Todefinea setofrequirementsthatcanbe validatedoncethesoftwareisbuilt.

2.3 The Elementsofthe AnalysisModel

Thegenericanalysismodelconsistsof:
● Anentity-relationshipdiagram(datamodel).
● Adata flow diagram(functionalmodel).
● Astatetransitiondiagram(behavioralmodel).
NOTE:statetransition diagramwillbecoveredinlab11.

21
SoftwareEngineering LabManual(ICS413)

2.3.1 EntityRelationshipDiagram
Anentityrelationshipdiagram(ERD)isonemeansofrepresentingtheobjectsandtheirrelationshipsinthed
atamodelforasoftwareproduct.

EntityRelationshipdiagramnotation:
Entity

Relationship

To createanERD you need to:

● Define “objects” by underlining all nouns in the written statement of
scope:producers/consumers of data, places where data are stored, and
“composite”data items.
● Define “operations” by double underlining all active verbs: processes
relevanttotheapplicationanddatatransformations.
● Considerother“services”thatwillberequiredbytheobjects.
● Then you need to define the relationship which indicates “connectedness”:
a"fact" that mustbe "remembered" by the system andcannotbe oris
notcomputedorderivedmechanically.

2.3.2 DataFlowDiagram
A data flow data diagram is one means of representing the functional model of a software
product.DFDsdo notrepresentprogramlogiclikeflowcharts do.

Dataflowdiagramnotation:

Externalentity

Process

Data

flowControlflow

Datastore

22
SoftwareEngineering LabManual(ICS413)

TocreateaDFDyouneedto:
● ReviewERDtoisolatedataobjectsandgrammaticalparsetodetermineoperations.
● Determineexternalentities(producersandconsumersofdata).
● Createalevel0DFD“ContextDiagram”(onesingleprocess).
● Balancethe flowtomaintaindataflowcontinuity.
● Developalevel1 DFD;usea1:5 (approx.)expansionratio.

Data FlowDiagramGuidelines:
● Alliconsmustbe labeledwith meaningfulnames.
● Always showexternalentitiesatlevel0.
● Always labeldataflowarrows.
● Do notrepresentprocedurallogic.
● Eachbubbleisrefineduntilitdoesjustonething.

3. CASETools
YoucanuseMSword tocreateyourERDandDFDsincewedo nothavealicenseforacase toolthatsupports
thesediagrams.

4. In-ClassExample
NowyouwilllearnhowtocreateERDandDFD.PleaserefertoLab6slideswhichexplaintheprocessofcreat
ingERDandDFD withsomeexamples.

5. Exercises
a. CreateanERD for anairlinereservationsystem.

b. Createa DFDfor:
i. StudentRegistrationSystem.
ii. (a+b)*(c+ a*d)

6. Deliverables
Youshouldsubmitthesolutionsforthepreviousexercises.
YoushouldcreateERDandDFDforyourtermprojectifneeded.YoualsoneedtocheckthemintoSourceSaf
e.

23
SoftwareEngineering LabManual(ICS413)

7
Documenting Use Cases
andActivityDiagrams

24
SoftwareEngineering LabManual(ICS413)

Lab7:DocumentingUseCasesandActivityDiagrams
Objectives
● Studyhowtodocumentusecasesindetail.
● Knowaboutscenarios(flow ofevents) anditsimportance.
● DeeperunderstandingofUMLactivitydiagrams.
● PracticingflowofeventsandactivitydiagramsusingRationalRose.

1. Outline
● Writingflowofevents.
● Flowofeventstemplateandexample.
● Activitydiagrams.
● Examples.

2. Background
Eachusecaseisdocumentedwithaflowofevents.Theflowofeventsforausecaseisadescriptionof the
events needed to accomplish the required behavior of the use case. Activity diagrams mayalso be
created at this stage in the life cycle. These diagrams represent the dynamics of the system.They
are flow charts that are used to show the workflow of a system; that is, they show the flow
ofcontrolfromoneactivitytoanotherinthesystem,

2.1 FlowofEvents
Adescriptionofeventsrequiredtoaccomplishthebehavioroftheusecase,that:
● ShowWHATthesystemshould do,notHOWthesystemdoesit.
● Writteninthelanguageofthedomain,notintermsofimplementation.
● Writtenfromanactor pointofview.
Aflowofevents documentiscreatedfor eachusecase:
● Actorsareexaminedtodeterminehowtheyinteractwiththesystem.
● Breakdownintothemostatomicactionspossible.

2.2 Contentsof FlowofEvents

● Whenandhowtheusecasestarts andends.
● Whatinteractiontheuse casehaswiththeactors.
● Whatdataisneededbytheusecase.
● Thenormalsequenceofeventsfortheusecase.
● Thedescriptionofanyalternate orexceptionalflows.

2.3 Template for the flowofeventsdocument

Eachprojectshoulduseastandardtemplateforthecreationoftheflowofeventsdocument.Thefollowingte
mplateseemstobeuseful.
X Flowofeventsforthe<name>usecase
X.1 Preconditions
X.2 Mainflow
X.3 Sub-flows(ifapplicable)
X.4 Alternativeflows
whereXisanumberfrom1tothenumber ofusecases.

AsamplecompletedflowofeventsdocumentfortheSelectCoursestoTeachusecasefollows.

1. FlowofEventsfortheSelect CoursestoTeachUseCase

1.1 Preconditions

25
SoftwareEngineering LabManual(ICS413)

Create course offerings sub-flow of the maintain course information use case
mustexecute beforethis use casebegins.

1.2 MainFlow
This use case begins when the professor logs onto the registration system and
entershis/her password. The system verifies that the password is valid (E-1) and
prompts theprofessortoselectthecurrentsemesterorafuturesemester(E-
2).Theprofessorentersthe desired semester. The system prompts the Professor to select
the desired activity:ADD,DELETE,REVIEW,PRINT,orQUIT.

Iftheactivityselected isADD,theS-1: add acourseoffering sub-flowisperformed.

Iftheactivity selectedisDELETE,theS-2:deleteacourse offeringsub-flowisperformed.

If the activity selected is REVIEW, the S-3: review schedule sub-flow is

performed.IftheactivityselectedisPRINT,theS-4: printaschedulesub-

flowisperformed.

Iftheactivityselected isQUIT,theusecase ends.

1.3 Sub-flows
S-1:AddaCourseOffering:
Thesystemdisplaysthecoursescreencontainingafieldforacoursenameandnumber.The
professor enters the name and number of a course (E-3). The system displays
thecourse offerings for the entered course (E-4). The professor selects a course
offering.The system links the professor to the selected course offering (E-5). The use
case thenbeginsagain.

S-2:DeleteaCourseOffering:
The system displays the course offering screen containing a field for a course
offeringname and number. The professor enters the name and number of a course
offering (E-6).Thesystemremovesthe linktotheprofessor(E-
7).Theusecasethenbeginsagain.

S-3:ReviewaSchedule:
The system retrieves (E-8) and displays thefollowinginformation forall
courseofferings for which the professor is assigned: course name, course number,
courseoffering number, days of the week, time, and location. When the professor
indicatesthathe orsheisthroughreviewing,theuse case begins again.

S-4:PrintaSchedule
Thesystemprintstheprofessor schedule(E-9).Theusecasebeginsagain.

26
SoftwareEngineering LabManual(ICS413)

1.4 AlternativeFlows
E-1: An invalid professor ID number is entered. The user can re-enter a professor
IDnumberorterminatetheusecase.

E-2:Aninvalidsemesterisentered.Theusercanre-enterthesemesterorterminatetheuse
case.

E-3:Aninvalidcoursename/numberisentered.Theusercanre-
enteravalidname/numbercombinationorterminatetheusecase.

E-4: Course offerings cannot be displayed. The user is informed that this option is
notavailable atthe currenttime.The use casebegins again.

E-5: A link between the professor and the course offering cannot be created.
Theinformation is saved and the system will create the link at a later time. The use
casecontinues.

E-6: An invalid course offering name/number is entered. The user can re-enter a
validcourseofferingname/numbercombinationorterminate theuse case.

E-7: A link between the professor and the course offering cannot be removed.
Theinformation is saved and the system will remove the link at a later time. The use
casecontinues.

E-8:Thesystemcannotretrievescheduleinformation. Theusecasethenbeginsagain.

E-9: The schedule cannot be printed. The user is informed that this option is
notavailable atthe currenttime.The use casebegins again.
Use case flow of events documents are entered and maintained in documents
externaltoRationalRose.Thedocumentsare linkedtotheusecase.

2.4 ActivityDiagrams
Activitydiagramsareflowcharts thatareusedtoshowtheworkflowofasystem.Theyalso:
● Representthedynamicsofthesystem.
● Showtheflowofcontrolfromactivity toactivityin thesystem.
● Show what activities can be done in parallel, and any alternate paths through the
flow.Activitydiagramsmaybecreatedtorepresenttheflow
acrossusecasesortheymaybecreatedtorepresenttheflowwithinaparticularusecase.Laterinthelifecycle,
activitydiagramsmaybecreatedtoshowtheworkflowforan operation.

2.5 ActivityDiagramNotation
● Activities-performance ofsomebehaviorinthe workflow.
● Transition-passingtheflow ofcontrolfromactivitytoactivity.
● Decision-showwheretheflow ofcontrolbranchesbasedona decisionpoint:
oGuardconditionis usedtodeterminewhichpathfromthedecisionpointistaken.
● Synchronization-
whatactivitiesaredoneconcurrently?Whatactivitiesmustbecompletedbeforeprocessing
maycontinue(join).

3. CASETools
RationalRose(introducedinlab 5).

4. In-ClassExample
27
SoftwareEngineering LabManual(ICS413)

Nowyouwilllearnhowtoapplytheabovementionedmethodstowriteflowofeventsanddrawingactivitydi
agramsfromtheusecase(s)flow ofevents.PleaserefertoLab7slideswhichexplaintheprocessin
detailwithsomeexamples.

5. Exercises
1. Taketwooftheusecasesfromrecyclingmachineproblem(Lab5)andwriteflowofeventsfor
those. Youshould workin groupsofthreetosolvethisproblem.
2. Practiceactivity diagramfromtheexampleinPPT(Lab 7) forcoursecatalogcreation.

6. Deliverables
Youshouldsubmitthesolutionsforthepreviousexercises.
Youshoulduse thesetechniquestowriteflowofeventsanddraw activitydiagramsforyourtermproject.

28
SoftwareEngineering LabManual(ICS413)

8
Object Oriented
Analysis:Discovering
Classes

29
SoftwareEngineering LabManual(ICS413)

Lab8:Object-OrientedAnalysis:DiscoveringClasses
Objective
● Learntheobject-
orientedanalysisphasebyunderstandingthemethodsofclasselicitationand
findingtheclasses inan object-orientedsystem.

1. Outline
● Object-Orientedconcepts
● Discoveringclasses’approaches:nounphraseapproach,commonclasspatterns,usecasedriven
method,CRC(Class-Responsibility-Collaboration)andmixedapproach.
● Examples.

2. Background
Classes:adescriptionofagroupofobjectswithcommon
properties(attributes),commonbehavior(operations),commonrelationships toother objects
andcommon semantics.

2.1 Object-OrientedConcepts
● Attribute:thebasicdata oftheclass.
● Method(operation):anexecutableprocedurethatisencapsulatedinaclassandisdesignedtooper
ateon oneormoredataattributes thataredefinedaspartoftheclass.
● Object:whenspecificvaluesareassignedtoalltheresourcesdefinedinaclass,the
resultisaninstanceofthatclass.Anyinstanceofany classiscalledan object.

2.2 DiscoveringClasses
Discovering and defining classes to describe the structure of a computerized system is not an
easytask. When the problem domain is new or unfamiliar to the software developers it can be
difficulttodiscoverclasses;acookbookfor findingclassesdoesnotexist.

2.3 ClassesCategories
Classesaredividedintothreecategories:
● Entity: models information and associated behavior that is long-lived,
independentofthesurrounding,applicationindependent,andaccomplishessomerespo
nsibility
● Boundary: handles the communication between the system surroundings and
theinside of the system, provides interface, and facilitates communication with
othersystems
● Control: model sequencing behavior specific to one or more use cases.
Controlclasses coordinate the events needed to realize the behavior specified in
the usecase,andtheyareresponsibleforthe flow ofeventsinthe use case.

30
SoftwareEngineering LabManual(ICS413)

2.4 DiscoveringClassesApproaches
Methodsofdiscoveringclasses:

2.4.1 Noun PhraseApproach:Examinethe

requirementsandunderlineeachnoun.Eachnounisacandidateclass;dividethelistofcandidatecl
asses into:
● Relevantclasses:partoftheapplicationdomain;occurfrequentlyinrequirement
s.
● Irrelevantclasses:outsideofapplicationdomain
● Fuzzy
classes:unabletobedeclaredrelevantwithconfidence;requireadditionalanalys
is

2.4.2 CommonClassPatterns:Derivescandidateclassesfromtheclassificationtheoryofobjects;ca
ndidateclassesand objectscomefromoneofthefollowingsources:
● Tangiblethings:e.g.buildings,cars.
● Roles:e.g.teachers, students.
● Events:thingsthathappenatagivendateandtime,orasstepsinanorderedsequenc
e:e.g.landing,request,interrupt.
● Interactions:e.g.meeting,discussion.
● Sources,facilities:e.g.departments.
● Othersystems:externalsystemswithwhichtheapplicationinteracts.
● Conceptclass:anotionsharedbyalargecommunity.
● Organizationclass:acollectionorgroupwithinthedomain.
● Peopleclass:rolespeoplecanplay.
● Placesclass:aphysicallocationrelevanttothesystem.

2.4.3 Use Case Driven Method:The scenarios - use cases that are fundamental to the
systemoperation are enumerated. Going over each scenario leads to the identification of
theobjects, the responsibilities of each object, and how these objects collaborate with
otherobjects.

2.4.4 CRC (Class-Responsibility-Collaboration): Used primarily as a brainstorming tool

foranalysisand design.CRC identifiesclassesby analyzing how objectscollaborate
toperformbusinessfunctions (usecases).
A CRC card contains: name of the class, responsibilities of the class and collaborators
ofthe class. Record name of class at the top; record responsibilities down the left-hand
side;recordotherclasses(collaborators)thatmayberequiredtofulfilleachresponsibilityontheri
ght-handside.
CRCcardsareeffectiveatanalyzingscenarios;theyforceyoutobeconciseandclear;theyarechea
p,portableandreadilyavailable.

2.4.5 MixedApproach:Amixoftheseapproachescanbe used,one possiblescenariois:

● UseCRCforbrainstorming.
● Identifytheinitialclasses bydomainknowledge.
● Usecommonclasspatternsapproachtoguidetheidentificationoftheclasses.
● Usenounphraseapproachtoaddmoreclasses.
● Usetheusecaseapproachtoverifytheidentifiedclasses.

2.5 ClassElicitationGuidelines
● Aclassshouldhaveasinglemajorrole.
● Aclassshouldhavedefinedresponsibilities(useCRCcardsifneeded).
● Classesshouldbeofamanageablesize:ifaclasshastoomanyattributesoroperati
ons,considersplittingit.
31
SoftwareEngineering LabManual(ICS413)

● A class should have a well-defined behavior, preferably by implementing

agivenrequirementoraninterface.

3. CASETools
RationalRose(introducedinlab 7).

4. In-ClassExample
Nowyouwilllearnhowtoapplytheabovementionedmethodsoffindingclassesfromtheproblemstatemen
t. Please refer to Lab 8 slides which explain the process of finding classes with someexamples.

5. Exercises
Consider the following requirements for the Video Store system. Identify the candidate
classes:Thevideostore
keepsinstockanextensivelibraryofcurrentandpopularmovietitles.Aparticularmoviemaybeheld on
videotapeordisk.
Videotapesareineither"Beta"or"VHS"format.VideodisksareinDVDformat.Eachmoviehasa
particular rental period (expressed in days), with a rental charge to that period. The video
storemustbeabletoimmediatelyanswer anyinquiriesaboutamovie'sstockavailabilityandhow
manytapes and/or disks are available for rental. The current condition of each tape and disk must
beknownandrecorded.
The rental charge differs depending on video medium: tape or disk (but it is the same for the
twocategoriesoftapes:BetaandVHS).
Thesystemshouldaccommodatefuture videostorageformatsinadditiontoVHStapes,Betatapesand
DVD disks. The employees frequently use a movie code, instead of movie title, to identify
themovie.Thesamemovietitlemayhavemorethanonereleasebydifferentdirectors.

Youmayuseany(ormix) oftheclasselicitationmethodstofindthecandidateclasses.

6. Deliverables
● Youshouldsubmitthesolutionsforthepreviousexercises.
● Alsoyoushoulduse theseclasselicitationtechniquestoidentifytheclassesforyourtermproject.

32
SoftwareEngineering LabManual(ICS413)

9
Interaction Diagrams:
Sequence&CollaborationDia
grams

33
SoftwareEngineering LabManual(ICS413)

Lab9:InteractionDiagrams:Sequence&CollaborationDiagra
ms
Objectives
● Betterunderstandingoftheinteractiondiagrams.
● Getfamiliarwithsequence&collaborationdiagrams.
● PracticedrawingtheinteractiondiagramsusingRationalRose.

1. Outline
● Interactiondiagrams:
o Sequencediagrams
o Collaborationdiagrams

2. Background
Interactiondiagramsdescribehowgroupsofobjectscollaborateinsomebehavior.Aninteractiondiagramt
ypically captures thebehaviorofasingleusecase.
Interactiondiagramsdonot capturethecompletebehavior,onlytypicalscenarios.

2.1 AnalyzingaSystem’sBehavior
UMLofferstwodiagramstomodelthedynamicsofthesystem:sequenceandcollaborationdiagrams.Thes
ediagramsshowtheinteractionsbetween objects.

2.2 Sequence Diagrams

Sequencediagramsareagraphicalwaytoillustrateascenario:
● They are called sequence diagrams because they show the sequence of message
passingbetweenobjects.
● Anotherbigadvantageofthesediagramsisthattheyshowwhentheobjectsarecreatedandwhenth
eyaredestructed.Theyalsoshowwhethermessagesaresynchronousorasynchronous

2.3 CreatingSequenceDiagrams
● Youmustknow thescenarioyou wanttomodelbefore diagrammingsequence diagrams.
● Afterthatspecifytheclassesinvolvedinthatscenario.
● Listtheinvolvedobjects inthescenario horizontallyonthetopofthepage.
● Dropadottedlinebeneathevery object.Theyarecalledlifelines.
● Thescenarioshouldstartbyamessagepassfromthefirstobject.
● Youmustknow howtoplacetheobjectssothatthesequenceisclear.
● Youmaystart thescenariobyanactor.
● Timingisrepresentedverticallydownward.
● Arrowsbetweenlifelinesrepresents messagepassing.
● Horizontalarrowsmaypassthroughthelifelineofanotherobject,butmuststopatsomeotherobjec
t.
● Youmayaddconstraintstothesehorizontalarrows.
● Objectsmaysendmessagestothemselves.
● Long,narrowrectanglescanbeplacedoverthelifelineofobjectstoshowwhenthe objectisactive.
Theserectangles arecalledactivationlines.

34
SoftwareEngineering LabManual(ICS413)

2.4 CollaborationDiagrams
Theyarethesameassequencediagramsbutwithoutatimeaxis:
● Theirmessagearrowsarenumberedtoshowthesequenceofmessagesending.
● Theyarelesscomplexandlessdescriptivethansequence diagrams.
● Thesediagramsareveryusefulduringdesignbecauseyoucanfigureouthowobjectscommunicat
ewith each other.

2.5 Notes
● Alwayskeepyourdiagramssimple.
● For “IF... then...” else scenarios, you may draw separate sequence diagrams for
thedifferent branches of the “if statement”. You may even hide them, (at least during
theanalysis phase) and document them by the text description accompanying the
sequencediagrams.

3. CASETools
RationalRose(introducedinlab 5).

4. In-ClassExample
Nowyouwilllearnhowtoapplytheabovementionedmethodsofdrawingsequenceandcollaboration
diagrams from the problem statement. Please refer to Lab 9 slides which explain
theprocessoffindingclasseswithsomeexamples.

5. Exercises
Weallhaveusedanelevator.Thefollowingstepsdescribethescenarioofwhathappensattheelevatordoorfr
omoutside.
1. Thepassengerpressesthebuttonofeitherupordowndependingonwherehewantstogo.
2. Thenhewillseethatthebuttonhepressedisilluminated.
3. Theelevatorisnowmovingtohisfloor.
4. Whentheelevator reachedhisfloor itstops.
5. Nowthebuttonwhichwasilluminatednowoff.
6. The door opensandthepassenger enters.
7. Thedoorcloses.
Theobjects:
3. Passenger(heistheactor).
4. Floorbutton(thisistheinterfaceclass,theactorinteractswiththisobject).
5. Elevatorcontroller(thisthecontrolclass,whichcoordinatestheactivitiesofthescenario).
6. Elevator(theentityclass,whichrepresentsthemachineitselfwhichmovesupanddown).
7. Door(anotherentityclass,whichrepresentsthe doorwhichopensandcloses).

Drawasequence diagramfortheabovescenario.

6. Deliverables
Youshouldsubmitthesolutionsforthepreviousexercises.
Youshouldusethesetechniquestocreatesequenceandcollaborationdiagramsforyourtermproject.

35
SoftwareEngineering LabManual(ICS413)

10
SoftwareDesign:
Software Architecture and Object-
OrientedDesign

36
SoftwareEngineering LabManual(ICS413)

Lab 10: Software Design: Software Architecture and Object-

OrientedDesign
Objectives
● Deeperunderstandingofsoftwaredesignandthesoftwaredesigndocument (SDD).
● Learnhowto findtherelationshipsbetweenclassestocreateUMLclassdiagram.

1. Outline
● Softwaredesignconceptsandprincipals.
● Softwarearchitecture.
● Specifyingtheattributesandtheoperationsandfindingtherelationshipsbetweenclasses.
● CreatingUMLclassdiagram.
● Softwaredesigndocument.

2. Background
The purpose of software design is “to produce a workable (implementable) solution to a
givenproblem.”DavidBudgeninSoftwareDesign:AnIntroduction.

2.1 TheDesignProcess
Software design is an iterative process that is traceable to the software requirements
analysisprocess. Many software projects iterate through the analysis and design phases several
times. Pureseparationofanalysis and designmay notalways be possible.

2.2 Design Concepts

● Thedesignshouldbebasedonrequirementsspecification.
● Thedesignshouldbedocumented(sothatitsupportsimplementation,verification,andmaintena
nce).
● Thedesignshould useabstraction(toreducecomplexityandto hideunnecessarydetail).
● Thedesignshouldbemodular(tosupportabstraction,verification,maintenance,anddivisionofl
abor).
● The designshouldbeassessedfor qualityasitisbeingcreated,notafterthefact.
● Designshouldproducemodulesthatexhibit independent functionalcharacteristics.
● Designshouldsupportverificationandmaintenance.

2.3 SoftwareArchitecture
Software architecture is a description of the subsystems and components of a
softwaresystemandtherelationshipsbetweenthem.
Youneedtodevelopanarchitecturalmodeltoenableeveryonetobetterunderstandthesystem
,
toallowpeopletoworkonindividualpiecesofthesysteminisolation,toprepareforext
ensionofthesystemand tofacilitatereuseand reusability.
2.4 DescribinganArchitectureUsingUML
All UML diagrams can be useful to describe aspects of the architectural model.
FourUMLdiagramsare particularlysuitableforarchitecturemodeling:
● Packagediagrams
● Subsystemdiagrams
● Componentdiagrams
● Deploymentdiagrams

2.5 SpecifyingClasses
Eachclassis givenaname, andthen you needtospecify:
● Attributes:initiallythosethatcaptureinterestingobject

37
SoftwareEngineering LabManual(ICS413)
states.Attributescanbepublic,protected,privateorfriendly/package.

38
SoftwareEngineering LabManual(ICS413)

● Operations:canbedelayedtilllateranalysisstagesoreventilldesign.Operationsalso
can be public,protected,privateorfriendly/package.
● Object-Relationships:
o Associations:denoterelationships betweenclasses.
o Anaggregation:aspecial caseofassociationdenotinga“consistsof”hierarchy.
o Composition:astrongformofaggregationwherecomponentscannotexistwitho
uttheaggregate.
o Generalizationrelationships:denoteinheritance betweenclasses.
Thiswillbuildtheclassdiagram,whichisagraphicalrepresentationoftheclasses(includingtheirattributes
and operations)andtheirrelationshipwith otherclasses.

3. CASETools
RationalRose(introducedinlab 7).

4. In-ClassExample
Now you will learn how to specify classes’ attributes, methods and the relationships between
theclasses. You will use the same classes identified in the examples of lab 8. Please refer to Lab
10slides which explain the process of finding classes’ attributes, methods and the
relationshipsbetweentheclassesas wellas creatingUML classdiagramswithsomeexamples.

5. Exercises
Refer to Lab 8 exercises; assume that the Video Store needs to know if a video tape is a brand
newtape or it was already taped over (this can be captured by an attribute is_taped_over); assume
alsothat the storage capacity of a video disk allows holding multiple versions of the same movie,
eachinadifferentlanguageorwith differentendings.
Use the identified classes from Lab 8 and find their attributes, operations and the
relationshipsbetweentheclasses (buildtheUML diagram).

6. Deliverables
● Youshouldsubmitthesolutionsforthepreviousexercises.
● Alsoyoushouldusespecifyingclassattributes,methodsandtherelationshipwithoth
erclassesyoulearnedinyourtermproject.

39
SoftwareEngineering LabManual(ICS413)

11
StateTransitionDiagram

StateTransitionDiagram

40
SoftwareEngineering LabManual(ICS413)

Lab11:StateTransitionDiagrams
Objectives
● DeeperunderstandingofUMLstatetransitiondiagrams(STD).
● PracticingusingRationalRose.

1. Outline
● UMLstate diagrams.
● UMLstatediagramnotation
● UMLstate details
● Examples

2. Background
Mainly, we use interaction diagrams to study and model the behavior of objects in our
system.Sometimes,weneedtostudythebehaviorofaspecificobjectthatshowscomplexbehaviortobetter
understand its dynamics. For that sake, UML provides state transition diagrams used to model
thebehavior of objects of complex behavior. In this Lab, UML state transition diagrams will
beintroduced.Wewillstudytheirnotationand howcanwemodelthemusing RationalRose.

2.1 UMLStateDiagrams
Statediagramsshowhowonespecificobject changesstateasitreceivesandprocessesmessages:
● Sincetheyareveryspecific,theyareusedforanalyzingveryspecificsituationsifwecomparethem
withotherdiagrams.
● Astatereferstothesetof valuesthatdescribeanobjectataspecificmomentintime.
● Asmessagesarereceived,theoperationsassociatedwiththeobject’sparentclassareinvokedto
dealwiththemessages.
● Thesemessageschangethevaluesoftheseattributes.
● Thereisno needto prepareastatediagramforeveryclassyouhaveinthesystem.

2.2 CreatingState TransitionDiagrams

● Statesare represented by rectangleswith rounded cornerswith an attributename with
avaluesassociated withit.
● Thenameofthestateis placedwithinthebox.
● Eventsareshownbyarrows.
● Aneventoccurswhenataninstantintimewhenavalueis changed.
● Amessageisdata passedfromone objecttoanother.
● Thenameofastate usuallyreferstothenameofthe attribute andthevaluesassociatedtoit.
● Example,astudentobjectmayreceiveamessagetochangeitsname.Thestateofthatobjectchange
s fromthefirstnamestatetothenewstatename.
● Thenameofthestateis placedinthetopcompartment.
● Statevariablesareplacedinthenextcompartment.
● Theoperationsassociatedwiththestatearelistedinthelowestcompartmentofthestatebox.
● Intheoperationspart,weusuallyuseoneofthefollowingreservedwords:
o Entry:aspecificaction performed ontheentrytothestate.
o Do:anongoingaction performed whileinthestate.
o On:a specificactionperformedwhileinthestate.
o Exit: a specificactionperformedonexitingthestate.
● Therearetwospecialstates addedtothestatetransition diagram-startstateandendstate.
● Notationofstartstateisa solidblackcircleandfor theendstateabull’seyeisused.

2.3 StateTransitionDetails
● A statetransitionmayhavean
actionand/orguardconditionassociatedwithitanditmayalsotriggeran event.
● Anactionisthebehavior thatoccurs whenthestatetransition occurs.

41
SoftwareEngineering LabManual(ICS413)

● Aneventisamessagethatissenttoanotherobjectinthe system.
● AguardconditionisaBooleanexpressionofattribute valuesthatallowsastate
transitiononlyiftheconditionis true.
● Both actions and guards are behaviors of the object and typically become operations.
Alsotheyareusually privateoperations(usedbytheobjectitself)
● Actionsthataccompanyallstatetransitionsintoastatemaybeplacedasanentryactionwithinthest
ate.
● Actions that accompany all state transitionsoutof astatemay beplaced as exit
actionswithinthestate
● Abehavior thatoccurswithinthestateiscalledanactivity.
● Anactivitystartswhenthestateisenteredandeithercompletesorisinterruptedbyanoutgoingstate
transition.
● Abehaviormaybeanaction,or itmaybeaneventsenttoanother object.
● Thisbehaviorismappedtooperationsontheobject.

Statetransitiondiagramnotation:

State
[entry:
…]
[do:…]
[exit:…]

Eventcausingtransition
Actionthat occurs

NewState

[entry:…]
[do:…]
[exit:…]

42
SoftwareEngineering LabManual(ICS413)

3. CASETools
RationalRose(introducedin Lab 5).

4. In-ClassExample
Nowyouwilllearnhowtoapplytheabovementionedmethodsofdrawingstatetransitiondiagrams(STD).
Please refer to Lab 11 slides which explain the process of finding dynamic classes
andcreatingSTDwithsomeexamples.

5. Exercises
Hereiswhathappensinamicrowave oven:
1. The ovenisinitiallyinanidlestatewithdooropen,wherethelightisturnedon.
2. Whenthe dooriscloseditisnowinidlewithdoor closed,butthe lightisturnedoff.
3. If abutton is pressed,then itmoves to initial cookingstage, where the timeris set
andlightsareon, and heatingstarts
4. At anymoment
thedoormaybeopened,thecookingisinterrupted,thetimeriscleared,andheatingstops.
5. Alsowhilecooking,anotherbuttoncanbepushedandextendedcookingstatestarts,wheretheti
mer getsmoreminutes.Atanymomentdoor canbeopenedherealso.
6. If the time times out, then cooking is complete, heating stops, lights are off, and it
soundsabeep.
7. Whenthe door isopen,againthe ovenisinidlestatewiththe door
open.Drawastatetransition diagramforthemicrowaveoven.

6. Deliverables
Youshouldsubmitthesolutionsforthepreviousexercises.
Youshouldusethesetechniquestocreatestatetransition diagramsfor your termproject

43
44