Relatedinformation

CourseRegistrationSystem
SoftwareArchitectureDocument
Version1.0

RevisionHistory
Date

Version

Description

Author

21/March/1999

1.0

SoftwareArchitectureDocumentgeneratedusingRational
SoDAtemplateandRationalRosemodel.

S.Johnson

TableofContents
1.Introduction
1.1Purpose
1.2Scope
1.3Definitions,AcronymsandAbbreviations
1.4References
2.ArchitecturalRepresentation
3.ArchitecturalGoalsandConstraints
4.UseCaseView
4.1ArchitecturallySignificantUseCases
5.LogicalView
5.1ArchitectureOverviewPackageandSubsystemLayering
6.ProcessView
6.1Processes
6.2ProcesstoDesignElements
6.3ProcessModeltoDesignModelDependencies
6.4ProcessestotheImplementation
7.DeploymentView
7.1ExternalDesktopPC
7.2DesktopPC
7.3RegistrationServer
7.4CourseCatalog
7.5BillingSystem

8.SizeandPerformance
9.Quality

SoftwareArchitectureDocument
1.Introduction
1.1Purpose
Thisdocumentprovidesacomprehensivearchitecturaloverviewofthesystem,usinganumberofdifferentarchitectural
viewstodepictdifferentaspectsofthesystem.Itisintendedtocaptureandconveythesignificantarchitecturaldecisions
whichhavebeenmadeonthesystem.
1.2Scope
ThisSoftwareArchitectureDocumentprovidesanarchitecturaloverviewoftheCRegistrationSystem.TheC
RegistrationSystemisbeingdevelopedbyWylieCollegetosupportonlinecourseregistration.
ThisDocumenthasbeengenerateddirectlyfromtheCRegistrationAnalysis&DesignModelimplementedinRose.The
majorityofthesectionshavebeenextractedfromtheRoseModelusingSoDAandtheSoftwareArchitectureDocument
template.
1.3Definitions,AcronymsandAbbreviations
SeetheGlossary[4].
1.4References
Applicablereferencesare:
1. CourseBillingInterfaceSpecification,WC93332,1985,WylieCollegePress.
2. CourseCatalogDatabaseSpecification,WC93422,1985,WylieCollegePress.
3. VisionDocumentoftheCRegistrationSystem,WyIT387,V1.0,1998,WylieCollegeIT.
4. GlossaryfortheCRegistrationSystem,WyIT406,V2.0,1999,WylieCollegeIT.
5. UseCaseSpecCloseRegistration,WyIT403,V2.0,1999,WylieCollegeIT.
6. UseCaseSpecLogin,WyIT401,V2.0,1999,WylieCollegeIT.
7. UseCaseSpecMaintainProfessorInfo,WyIT407,Version2.0,1999,WylieCollegeIT.
8. UseCaseSpecRegisterforCourses,WyIT402,Version2.0,1999,WylieCollegeIT.
9. UseCaseSpecSelectCoursestoTeach,WyIT405,Version2.0,1999,WylieCollegeIT.
10. UseCaseSpecMaintainStudentInfo,WyIT408,Version2.0,1999,WylieCollegeIT.
11. UseCaseSpecSubmitGrades,WyIT409,Version2.0,1999,WylieCollegeIT.
12. UseCaseSpecViewReportCard,WyIT410,Version2.0,1999,WylieCollegeIT.
13. SoftwareDevelopmentPlanfortheCRegistrationSystem,WyIT418,V1.0,1999,WylieCollege
IT.
14. E1IterationPlan,WyIT420,V1.0,1999,WylieCollegeIT.
15. SupplementarySpecification,WyIT400,V1.0,1999,WylieCollege,IT.

2.ArchitecturalRepresentation
Thisdocumentpresentsthearchitectureasaseriesofviewsusecaseview,logicalview,processviewanddeployment
view.Thereisnoseparateimplementationviewdescribedinthisdocument.TheseareviewsonanunderlyingUnified
ModelingLanguage(UML)modeldevelopedusingRationalRose.

3.ArchitecturalGoalsandConstraints
Therearesomekeyrequirementsandsystemconstraintsthathaveasignificantbearingonthearchitecture.Theyare:
1. TheexistinglegacyCourseCatalogSystematWylieCollegemustbeaccessedtoretrieveallcourse
informationforthecurrentsemester.TheCRegistrationSystemmustsupportthedataformatsandDBMSof

thelegacyCourseCatalogSystem[2].
2. TheexistinglegacyBillingSystematWylieCollegemustbeinterfacedwithtosupportbillingofstudents.
ThisinterfaceisdefinedintheCourseBillingInterfaceSpecification[1].
3. Allstudent,professor,andRegistrarfunctionalitymustbeavailablefrombothlocalcampusPCsandremote
PCswithinternetdialupconnections.
4. TheCRegistrationSystemmustensurecompleteprotectionofdatafromunauthorizedaccess.Allremote
accessesaresubjecttouseridentificationandpasswordcontrol.
5. TheCRegistrationSystemwillbeimplementedasaclientserversystem.TheclientportionresidesonPCs
andtheserverportionmustoperateontheWylieCollegeUNIXServer.[3]
6. Allperformanceandloadingrequirements,asstipulatedintheVisionDocument[3]andtheSupplementary
Specification[15],mustbetakenintoconsiderationasthearchitectureisbeingdeveloped.

4.UseCaseView
Adescriptionoftheusecaseviewofthesoftwarearchitecture.TheUseCaseViewisimportantinputtotheselectionofthe
setofscenariosand/orusecasesthatarethefocusofaniteration.Itdescribesthesetofscenariosand/orusecasesthat
representsomesignificant,centralfunctionality.Italsodescribesthesetofscenariosand/orusecasesthathavea
substantialarchitecturalcoverage(thatexercisemanyarchitecturalelements)orthatstressorillustrateaspecific,delicate
pointofthearchitecture.
TheCRegistrationusecasesare:
Login
RegisterforCourses
MaintainStudentInformation
MaintainProfessorInformation
SelectCoursestoTeach
SubmitGrades
ViewReportCard
CloseRegistration.
Theseusecasesareinitiatedbythestudent,professor,ortheregistraractors.Inaddition,interactionwithexternalactors
CourseCatalogandBillingSystemoccur.
4.1ArchitecturallySignificantUseCases

DiagramName:ArchitecturallySignificantUseCases

4.1.1CloseRegistration
BriefDescription:ThisusecaseallowsaRegistrartoclosetheregistrationprocess.Courseofferings
thatdonothaveenoughstudentsarecancelled.Courseofferingsmusthaveaminimumofthree
studentsinthem.Thebillingsystemisnotifiedforeachstudentineachcourseofferingthatisnot
cancelled,sothestudentcanbebilledforthecourseoffering.Themainactorofthisusecaseisthe
Registrar.TheBillingSystemisanactorinvolvedwithinthisusecase.
4.1.2Login
BriefDescription:ThisusecasedescribeshowauserlogsintotheCourseRegistrationSystem.The
actorsstartingthisusecaseareStudent,Professor,andRegistrar.
4.1.3MaintainProfessorInformation
BriefDescription:Thisusecaseallowstheregistrartomaintainprofessorinformationinthe
registrationsystem.Thisincludesadding,modifying,anddeletingprofessorsfromthesystem.The
actorofthisusecaseistheRegistrar.

4.1.4SelectCoursestoTeach
BriefDescription:Thisusecaseallowsaprofessortoselectthecourseofferings(dateandtime
specificcourseswillbegiven)fromthecoursecatalogforthecoursesthathe/sheiseligibleforand
wishestoteachintheupcomingsemester.TheactorstartingthisusecaseistheProfessor.The
CourseCatalogSystemisanactorwithintheusecase.
4.1.5RegisterforCourses
BriefDescription:Thisusecaseallowsastudenttoregisterforcoursesinthecurrentsemester.The
studentcanalsomodifyordeletecourseselectionsifchangesaremadewithintheadd/dropperiod
atthebeginningofthesemester.TheBillingSystemisnotifiedofallregistrationupdates.The
CourseCatalogprovidesalistofallthecourseofferingsforthecurrentsemester.Themainactorof
thisusecaseisthestudent.TheCourseCatalogSystemisanactorwithintheusecase.
4.1.6ViewReportCard
BriefDescription:Thisusecaseallowsastudenttoviewhis/herreportcardforthepreviously
completedsemester.Thestudentistheactorofthisusecase.
4.1.7SubmitGrades
BriefDescription:Thisusecaseallowsaprofessortosubmitstudentgradesforoneormoreclasses
completedintheprevioussemester.TheactorinthisusecaseistheProfessor.
4.1.8MaintainStudentInformation
BriefDescription:Thisusecaseallowstheregistrartomaintainstudentinformationintheregistration
system.Thisincludesadding,modifying,anddeletingstudentsfromthesystem.Theactorforthisusecase
istheRegistrar.

5.LogicalView
Adescriptionofthelogicalviewofthearchitecture.Describesthemostimportantclasses,theirorganizationinservice
packagesandsubsystems,andtheorganizationofthesesubsystemsintolayers.Alsodescribesthemostimportantusecase
realizations,forexample,thedynamicaspectsofthearchitecture.Classdiagramsmaybeincludedtoillustratethe
relationshipsbetweenarchitecturallysignificantclasses,subsystems,packagesandlayers.
Thelogicalviewofthecourseregistrationsystemiscomprisedofthe3mainpackages:UserInterface,BusinessServices,
andBusinessObjects.
TheUserInterfacePackagecontainsclassesforeachoftheformsthattheactorsusetocommunicatewiththeSystem.
Boundaryclassesexisttosupportlogin,maintainingofschedules,maintainingofprofessorinfo,selectingcourses,
submittinggrades,maintainingstudentinfo,closingregistration,andviewingreportcards.
TheBusinessServicesPackagecontainscontrolclassesforinterfacingwiththebillingsystem,controllingstudent
registration,andmanagingthestudentevaluation.
TheBusinessObjectsPackageincludesentityclassesfortheuniversityartifacts(i.e.courseoffering,schedule)and
boundaryclassesfortheinterfacewiththeCourseCatalogSystem.

5.1ArchitectureOverviewPackageandSubsystemLayering


5.1.1Application
layer
Thisapplicationlayerhasalltheboundaryclassesthatrepresenttheapplicationscreensthatthe
usersees.ThislayerdependsupontheProcessObjectslayerthatstraddlestheseparationofthe
clientfrommidtier.
5.1.2BusinessServices
layer
TheBusinessServicesprocesslayerhasallthecontrollerclassesthatrepresenttheusecase
managersthatdrivetheapplicationbehavior.Thislayerrepresentstheclienttomidtierborder.
TheBusinessServiceslayerdependsupontheProcessObjectslayerthatstraddlestheseparation
oftheclientfrommidtier.
5.1.3Middleware
layer
TheMiddlewarelayersupportsaccesstoRelationalDBMSandOODBMS.
5.1.4BaseReuse
TheBaseReusepackageincludesclassestosupportlistfunctionsandpatterns.

6.ProcessView
Adescriptionoftheprocessviewofthearchitecture.Describesthetasks(processesandthreads)involvedinthesystem's
execution,theirinteractionsandconfigurations.Alsodescribestheallocationofobjectsandclassestotasks.
TheProcessModelillustratesthecourseregistrationclassesorganizedasexecutableprocesses.Processesexisttosupport

studentregistration,professorfunctions,registrationclosing,andaccesstotheexternalBillingSystemandCourse
CatalogSystem.
6.1Processes

DiagramName:Processes
6.1.1CourseCatalogSystemAccess
ThisprocessmanagesaccesstothelegacyCourseCatalogSystem.Itcanbesharedbymultiple
usersregisteringforcourses.Thisallowsforacacheofrecentlyretrievedcoursesandofferingsto
improveperformance.
TheseparatethreadswithintheCourseCatalogprocess,CourseCacheandOfferingCacheareused
toasynchronouslyretrieveitemsfromthelegacysystem.
AnalysisMechanisms:
LegacyInterface
RequirementsTraceability:
DesignConstraints:Thesystemshallintegratewithexistinglegacysystem(coursecatalog
database).

6.1.2CourseCatalog

Theunabbridgedcatalogofallcoursesandcourseofferingsofferedbytheuniversityincluding
thosefromprevioussemesters.
Thisclassactsasanadapter(seetheGammapattern).Itworkstomakessurethe
CourseCatalogSystemcanbeaccessedthroughtheICourseCataloginterfacetothesubsystem.

6.1.3CourseRegistrationProcess
Thereisoneinstanceofthisprocessforeachstudentthatiscurrentlyregisteringforcourses.

6.1.4RegistrationController
Thissupportstheusecaseallowingastudenttoregisterforcoursesinthecurrentsemester.The
studentcanalsomodifyordeletecourseselectionsifchangesaremadewithintheadd/dropperiod
atthebeginningofthesemester.
AnalysisMechanisms:
Distribution

6.1.5StudentApplication
Managesthestudentfunctionality,includinguserinterfaceprocessingandcoordinationwiththe
businessprocesses.
Thereisoneinstanceofthisprocessforeachstudentthatiscurrentlyregisteringforcourses.

6.1.6MainStudentForm
ControlstheinterfaceoftheStudentapplication.ControlsthefamilyofformsthattheStudent
uses.

6.1.7BillingSystemAccess
ThisprocesscommunicateswiththeexternalBillingSystemtoinitiatestudentbilling.

6.1.8CloseRegistrationProcess
TheCloseRegistrationprocessisinitiatedattheendoftheregistrationtimeperiod.Thisprocess
communicateswiththeprocesscontrollingaccesstotheBillingSystem.

6.1.9BillingSystem
TheBillingSystemsupportsthesubmittingofstudentbillsforthecoursesregisteredforbythe
studentforthecurrentsemester.
AnalysisMechanisms:
LegacyInterface

6.1.10CloseRegistrationController
TheCloseRegistrationControllercontrolsaccesstotheBillingSystem.
AnalysisMechanisms:

Distribution

6.2ProcesstoDesignElements

DiagramName:ProcesstoDesignElements
6.2.1CourseCache
TheCourseCachethreadisusedtoasynchronouslyretrieveitemsfromthelegacyCourseCatalogSystem.
6.2.2OfferingCache
TheOfferingCashethreadisusedtoasynchronouslyretrieveitemsfromthelegacyCourseCatalogSystem.

6.2.3Course
Aclassofferedbytheuniversity.
AnalysisMechanisms:
Persistency
LegacyInterface

6.2.4CourseOffering

Aspecificofferingforacourse,includingdaysoftheweekandtimes.
AnalysisMechanisms:
Persistency
LegacyInterface

6.3ProcessModeltoDesignModelDependencies

DiagramName:ProcessModeltoDesignModelDependencies

6.4ProcessestotheImplementation

DiagramName:ProcessestotheImplementation
6.4.1Remote
*TheRemoteinterfaceservestoidentifyallremoteobjects.Anyobjectthatisaremoteobject
mustdirectlyorindirectlyimplementthisinterface.Onlythosemethodsspecifiedinaremote
interfaceareavailableremotely.
*Implementationclassescanimplementanynumberofremoteinterfacesandcanextendother
remoteimplementationclasses.
6.4.2Runnable
*TheRunnableinterfaceshouldbeimplementedbyanyclasswhoseinstancesareintendedtobe
executedbyathread.Theclassmustdefineamethodofnoargumentscalledrun.
*Thisinterfaceisdesignedtoprovideacommonprotocolforobjectsthatwishtoexecutecode
whiletheyareactive.Forexample,RunnableisimplementedbyclassThread.
*Beingactivesimplymeansthatathreadhasbeenstartedandhasnotyetbeenstopped.
6.4.3Thread
*Athreadisathreadofexecutioninaprogram.TheJavaVirtualMachineallowsanapplication
tohavemultiplethreadsofexecutionrunningconcurrently.
*Everythreadhasapriority.Threadswithhigherpriorityareexecutedinpreferencetothreads
withlowerpriority.Eachthreadmayormaynotalsobemarkedasadaemon.Whencoderunning
insomethreadcreatesanewThreadobject,thenewthreadhasitspriorityinitiallysetequaltothe
priorityofthecreatingthread,andisadaemonthreadifandonlyifthecreatingthreadisa
daemon.

7.DeploymentView
AdescriptionofthedeploymentviewofthearchitectureDescribesthevariousphysicalnodesforthemosttypical
platformconfigurations.Alsodescribestheallocationoftasks(fromtheProcessView)tothephysicalnodes.
Thissectionisorganizedbyphysicalnetworkconfigurationeachsuchconfigurationisillustratedbyadeployment
diagram,followedbyamappingofprocessestoeachprocessor.

DiagramName:DeploymentView
7.1ExternalDesktopPC
StudentsregisterforcoursesusingexternaldesktopPCswhichareconnectedtotheCollegeServerviainternet
dialup.
7.2DesktopPC
StudentsregisterforcoursesvialocalDesktopPCsthatareconnecteddirectlytotheCollegeServerviaLAN.
TheselocalPCsarealsousedbyprofessorstoselectcourseandsubmitstudentgrades.TheRegistrarusesthese
localPCstomaintainstudentandprofessorinformation.
7.3RegistrationServer
TheRegistrationServeristhemaincampusUNIXServer.AllfacultyandstudentshaveaccesstotheServer
throughthecampusLAN.
7.4CourseCatalog
TheCourseCatalogSystemisalegacysystemthatcontainsthecompletecoursecatalog.Accesstoitis
availableviatheCollegeServerandLAN.
7.5BillingSystem
TheBillingSystem(alsocalledtheFinanceSystem)isalegacysystemthatgeneratesthestudentbillseachsemester.

8.SizeandPerformance
Thechosensoftwarearchitecturesupportsthekeysizingandtimingrequirements,asstipulatedinthe
SupplementarySpecification[15]:
1. Thesystemshallsupportupto2000simultaneoususersagainstthecentraldatabaseatanygiven
time,andupto500simultaneoususersagainstthelocalserversatanyonetime.
2. Thesystemshallprovideaccesstothelegacycoursecatalogdatabasewithnomorethana10
secondlatency.
3. Thesystemmustbeabletocomplete80%ofalltransactionswithin2minutes.
4. Theclientportionshallrequirelessthan20MBdiskspaceand32MBRAM.
Theselectedarchitecturesupportsthesizingandtimingrequirementsthroughthe
implementationofaclientserverarchitecture.Theclientportionisimplementedonlocal
campusPCsorremotedialupPCs.Thecomponentshavebeendesignedtoensurethat
minimaldiskandmemoryrequirementsareneededonthePCclientportion.

9.Quality
Thesoftwarearchitecturesupportsthequalityrequirements,asstipulatedintheSupplementary
Specification[15]:
1. ThedesktopuserinterfaceshallbeWindows95/98compliant.
2. TheuserinterfaceoftheCRegistrationSystemshallbedesignedforeaseofuseandshallbe
appropriateforacomputerliterateusercommunitywithnoadditionaltrainingontheSystem.
3. EachfeatureoftheCRegistrationSystemshallhavebuiltinonlinehelpfortheuser.OnlineHelp
shallincludestepbystepinstructionsonusingtheSystem.OnlineHelpshallincludedefinitions
fortermsandacronymns.
4. TheCRegistrationSystemshallbeavailable24hoursaday,7daysaweek.Thereshallbeno
morethan4%downtime.
5. MeanTimeBetweenFailuresshallexceed300hours.
6. UpgradestothePCclientportionofCRegistrationshallbedownloadablefromtheUNIXServer
overtheinternet.Thisfeatureenablesstudentstohaveeasyaccesstosystemupgrades.

Copyright19872001RationalSoftwareCorporation

CourseRegistrationProjectWebExample
Version2001.02