DEV475 Mastering Object-Oriented Analysis and Design with UML ...

Rational UniversityDEV475 Mastering Object-Oriented Analysis and Design with UMLStudent ManualVersion 2003.06.00Volume 1February, 2003Copyright © 2002, 2003 Rational Software Corporation. All rights reserved.The contents of this manual and the associated software are the property ofRational Software and/or its licensors, and are protected by United States copyright laws,patent laws, and various international treaties. Any reproduction in whole or in partis strictly prohibited. For additional copies of this manual or software, please contactRational Software.Rational, the Rational logo, ClearQuest, ClearCase, Purify, PureCoverage, Rational UnifiedProcess, ClearDDTS, and Quantify are trademarks or registered trademarks of RationalSoftware Corporation in the United States and in other countries. All names are used foridentification purposes only and are trademarks of their respective companies.Microsoft Visual Basic, Windows NT, Windows 2000, and Visual SourceSafe are trademarksor registered trademarks of Microsoft Corporation.Java and all Java-based marks, among others, are trademarks or registered trademarks of SunMicrosystem’s in the United States and/or other countries. All other names are used foridentification purposes only and are trademarks of their respective companies.Printed in the United States of America.This manual prepared by:Rational SoftwareRational University18880 Homestead RoadCupertino, CA 95014-0721USATel: 408-863-9900Fax: 408-863-4099Register: 888-RATL-444Web: http://www.rational.com…

ContentsModule 0 About This Course 0-1Course Objectives.......................................................................................... 0-3Prerequisites .................................................................................................. 0-6Rational University Curriculum....................................................................... 0-7Module 1 Best Practices of Software Engineering 1-1Practice 1: Develop Iteratively ....................................................................... 1-7Practice 2: Manage Requirements................................................................ 1-11Practice 3: Use Component Architectures .................................................... 1-15Practice 4: Model Visually............................................................................ 1-18Practice 5: Continuously Verify Quality........................................................ 1-22Practice 6: Manage Change ......................................................................... 1-27Module 2 Concepts of Object Orientation 2-1What Is Object Technology? .......................................................................... 2-4Basic Principles of Object Orientation .......................................................... 2-15Representing Classes in the UML.................................................................. 2-24Review ........................................................................................................ 2-51Module 3 Requirements Overview 3-1Introduction .................................................................................................. 3-3Key Concepts ................................................................................................ 3-7Use-Case Model .......................................................................................... 3-10Glossary....................................................................................................... 3-19Supplementary Specifications....................................................................... 3-22Review ........................................................................................................ 3-31Module 4 Analysis and Design Overview 4-1Key Concepts ................................................................................................ 4-5Analysis and Design Workflow ..................................................................... 4-11Module 5 Architectural Analysis 5-1Architectural Analysis Overview ..................................................................... 5-4Key Concepts ................................................................................................ 5-5Define the high-level Organization of Subsystems......................................... 5-10Identify Analysis Mechanisms ....................................................................... 5-19Identify Key Abstractions.............................................................................. 5-28Create Use-Case Realizations ....................................................................... 5-32Review ........................................................................................................ 5-38

AcknowledgmentsThe development of this course was made possible with the help of many individuals, but I wouldparticularly like to thank the following for their exceptional participation:Alex Kutsick of Rational University for his course development standards, instructional designexpertise, attention to detail, and correcting my misuse of the English language. Alex ispersonally responsible for ensuring that there is a high-level of consistency throughout thiscourse.Dan Machado of Rational University for his graphics support.Kelli Houston of Rational University for her incredible work on OOADv4.0 and OOADv4.2;all I had to do was carry on what she had started.The OOAD Steering Committee: Eric Aker, Sinan Alhir, Alex Barclay, Francesco Bonfiglio,Jerome Desquilbet, Fredrik Ferm, Yves Holvoet, Sean Kelley, Pan Wei Ng, Davyd Norris, JimRuehlin, Jean-Pierre Schoch and Mike Tudball.Paul Dreyfus and his team of editors for assisting in reviewing the material.Last but certainly not least, DeAnna Roberts of the Rational University production team for herfulfillment and logistical support.January, 2003Lee AckermanRational University Sr. Product Manager/ OO Curriculumlackerman@rational.com

Works CitedThe following sources were used to develop this courseware. When quoted directly, we cite the sourceafter the quoted passage. For all other uses, we respectfully acknowledge below the authors’contributions in the development of this courseware.The Deadline: A Novel About Project Management, Tom DeMarco, Dorset House Publishing,1997.Dictionary of Object Technology: The Definitive Desk Reference, Donald G. Firesmith and EdwardM. Eykholt, Prentice Hall, 1995.Meta Fax, 09/15/97.news@sei, Vol. 1, No. 2.Object Technology: A Manager’s Guide, David A. Taylor, Addison-Wesley, 1999.Pattern-Oriented Software Architecture: A System of Patterns, Frank Buschman et al., John Wiley &Sons, 1996.The Rational Unified Process, An Introduction, Phillippe Kruchten, Addison-Wesley, 1999.UML Distilled, Martin Fowler and Kendall Scott, Addison-Wesley, 1997.UML Toolkit, Hans-Erik Eriksson and Magnus Penker, John Wiley & Sons, 1997.The Unified Modeling Language User Guide, Grady Booch, James Rumbaugh, Ivar Jacobson,Addison-Wesley, 1999.Visual Modeling with Rational Rose and UML, Terry Quatrani, Addison-Wesley, 1998.

► ► ► Module 0About This CourseMastering Object-Oriented Analysisand Design with UMLModule 0: About This CourseTopicsCourse Objectives ................................................................................................ 0-3Prerequisites......................................................................................................... 0-6Rational University Curriculum ............................................................................. 0-70 - 1

DEV475 Mastering Object-Oriented Analysis and Design with UMLIntroductionsIntroductions• Your organization• Your role• Your background, experience• Object technology experience• Software development experience• Implementation language experience• Your expectations for this courseMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 20 - 2

Module 0 - About This CourseCourse ObjectivesCourse Objectives• Upon completion of the course, participantswill be able to:• Apply an iterative, use case-driven,architecture-centric process to the developmentof a robust design model• Use the Unified Modeling Language (UML) torepresent the design model• Apply Object-Oriented (OO) concepts:abstraction, encapsulation, inheritance,hierarchy, modularity, and polymorphism to thedevelopment of a robust design modelMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 3During this course, you will be introduced to the concepts, process, and notation fordeveloping a design model. You will be using the Rational Unified Process Analysisand Design workflow as your framework. These concepts can also be applied withinany software development process.0 - 3

DEV475 Mastering Object-Oriented Analysis and Design with UMLCourse Objectives (cont.)Course Objectives (cont.)• Upon completion of the course, participantswill be able to:• Describe the different views of softwarearchitecture, key mechanisms that are definedin support of that architecture, and the effect ofthe architecture on the produced design• Define basic design considerations, includingthe use of patternsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 4The concentration will be on those activities that are performed by the objectorienteddesigner. Architectural concepts will be introduced and discussed, as theydrive the design, but this is not an architecture course.0 - 4

Module 0 - About This CourseIntended AudienceIntended Audience• Intended Audience• Practitioners who want a basic explanation ofObject-Oriented Analysis and Design (OOAD)concepts, as well as hands-on practicalexperience in applying the techniques• Analysts, designers, software developersMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 50 - 5

DEV475 Mastering Object-Oriented Analysis and Design with UMLPrerequisitesPrerequisites• Some experience applying the followingtechniques in a software developmentenvironment• An exposure to object technology including, how to:• Read a use-case model• Add classes, objects, associations and how to create simpleinteraction and class diagrams• Find classes and distribute class behavior• Distinguish between the UML Analysis class stereotypes:boundary, control, and entity• Prerequisites can be achieved through attendance in“Essentials of Visual Modeling with UML” orequivalent experienceMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 60 - 6

Module 0 - About This CourseRational University CurriculumRational University CurriculumCurriculum Flow:DesignerPath 1Instructor-ledWeb-basedOptionalDEV110Principles ofModelingDEV111Principles ofUC Modelingwith UMLDEV112Principles ofAnalysis IDEV113Principles ofAnalysis IIDEV305Essentials ofRationalRose2 hours2 hours2 hours2 hours5 hoursORPath 2ORDEV275Essentialsof VisualModelingwith UML1 dayDEV475Mastering ObjectOrientedAnalysis &Design with UML4 daysFund. ofRationalRose1 dayMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 7The Rational University curriculum offers the courses shown here and on the nexttwo slides. As you can see, for each major software development team role, RationalUniversity offers a professional development course.The Requirements Management with Use Cases may be particularly interesting to you,as it is where you will learn to develop use cases, the artifacts that drive much of whatyou do in Analysis and Design.0 - 7

DEV475 Mastering Object-Oriented Analysis and Design with UMLRational University CurriculumRational University CurriculumCurriculum Flow:Enterprise ArchitectPath 1Instructor-ledWeb-basedOptionalPRJ110Principles ofRationalUnifiedProcess3 hoursDEV275Essentialsof VisualModelingwith UML1 dayORDEV111Principles ofUC Modelingwith UMLPath 22 hoursDEV112Principles ofAnalysis I2 hoursDEV113Principles ofAnalysis II2 hoursPrinciples ofArchitectingSoftwareSystems3 daysDEV110Principles ofModeling2 hoursDEV475Mastering ObjectOrientedAnalysis &Design with UML4 daysMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 80 - 8

Module 0 - About This CourseRational University CurriculumRational University CurriculumCurriculum Flow:AnalystInstructor-ledWeb-basedOptionalREQ310Essentials ofRationalRequisiteProDEV110Principles ofModelingDEV305Essentials ofRationalRose5 hours2 hours2 hoursReq.Managementwith UseCases3 daysORFund. OfRationalRequisiteProORDEV275Essentialsof VisualModelingwith UMLORFund. ofRationalRose1 day1 day1 dayMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 90 - 9

DEV475 Mastering Object-Oriented Analysis and Design with UMLCourse MaterialsCourse Materials• Student Manual, Books 1, 2, and 3• Additional Information Appendix• Course Registration RequirementsDocument• Payroll Requirements Document• Payroll Architecture Handbook• Payroll Solution Appendix• Course Registration Models and PayrollSolutions Models CD• UML User’s Guide by Grady BoochMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 10The Student Manual contains copies of the slides, as well as detailed Student Notes.The Student Manual is comprised of two books.The Additional Information Appendix contains a collection of additional topics thatare not general enough to be included in the base course, or may be considered tooadvanced for the introductory audience. These topics may or may not be covered bythe instructor. This appendix contains the UML-To-Language Maps that show themap from the UML to implementation language constructs for the followinglanguages: C++, Java, PowerBuilder, and Visual Basic. It also contains informationon several additional Architectural Mechanisms.The requirements that drive the development of the example and exercise designmodels are documented in the Course Registration Requirements Document andthe Payroll Requirements Document, respectively.The architectural “givens” that guide the students in the development of the exercisedesign model are documented in the Payroll Architecture Handbook.The Payroll Solution Appendix contains the hard-copy of the course exercisesolutions. The Rose models for the course example and course solutions are providedon the Course Registration Models and Payroll Solutions Models CD.0 - 10

DEV475 Mastering Object-Oriented Analysis and Design with UMLLogisticsLogisticsMorning2-Fifteen-minute breaksLunch1 HourAfternoon2-Fifteen-minute breaksMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 120 - 12

► ► ► Module 1Best Practices of Software EngineeringMastering Object-Oriented Analysisand Design with UMLModule 1: Best Practices of SoftwareEngineeringTopicsPractice 1: Develop Iteratively.............................................................................. 1-7Practice 2: Manage Requirements ...................................................................... 1-11Practice 3: Use Component Architectures........................................................... 1-15Practice 4: Model Visually (UML)........................................................................ 1-18Practice 5: Continuously Verify Quality............................................................... 1-22Practice 6: Manage Change................................................................................ 1-271 - 1

DEV475 Mastering Object-Oriented Analysis and Design with UMLObjectivesObjectives• Identify activities for understanding andsolving software engineering problems.• Explain the Six Best Practices.• Present the Rational Unified Process (RUP)within the context of the Six Best Practices.Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved2In this module, you learn about recommended software development Best Practicesand the reasons for these recommendations. Then you see how the Rational UnifiedProcess (RUP) is designed to help you implement the Six Best Practices.1 - 2

Module 1 - Best Practices of Software EngineeringModule 1 Content OutlineModule 1 Content Outline• Software development problems• The Six Best Practices• RUP within the context of the Six BestPracticesMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved31 - 3

DEV475 Mastering Object-Oriented Analysis and Design with UMLSymptoms of Software Development ProblemsSymptoms of Software Development ProblemsUser or business needs not metRequirements not addressedModules not integratingDifficulties with maintenanceLate discovery of flawsPoor quality of end-user experiencePoor performance under loadNo coordinated team effortBuild-and-release issuesMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved41 - 4

Module 1 - Best Practices of Software EngineeringTrace Symptoms to Root CausesTrace Symptoms to Root CausesSymptoms Root Causes Best PracticesNeeds not metRequirements churnModules don’t not fit fitHard to maintainLate discoveryPoor qualityPoor performanceColliding developersBuild-and-releaseInsufficient requirementsAmbiguous communicationsBrittle architecturesOverwhelming complexityUndetected inconsistenciesPoor testingSubjective assessmentWaterfall developmentUncontrolled changeInsufficient automationDevelop IterativelyManage RequirementsUse Component ArchitecturesModel Visually (UML)Continuously Verify QualityManage ChangeMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved5Treat these root causes, and you will eliminate the symptoms. Eliminate thesymptoms, and you’ll be in a much better position to develop quality software in arepeatable and predictable fashion.Best practices are a set of commercially proven approaches to software development,which, when used in combination, strike at the root causes of software developmentproblems. These are called “Best Practices,” not because we can precisely quantifytheir value, but because they are observed to be commonly used in the industry bysuccessful organizations. The Best Practices are harvested from thousands ofcustomers on thousands of projects and from industry experts.1 - 5

DEV475 Mastering Object-Oriented Analysis and Design with UMLModule 1 Content OutlineModule 1 Content Outline• Software development problems• The Six Best Practices• RUP within the context of the Six BestPracticesMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved61 - 6

Module 1 - Best Practices of Software EngineeringPractice 1: Develop IterativelyPractice 1: Develop IterativelyBest PracticesProcess Made PracticalDevelop IterativelyManage RequirementsUse ComponentArchitecturesModel Visually (UML)Continuously Verify QualityManage ChangeMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved7Developing iteratively is a technique that is used to deliver the functionality of asystem in a successive series of releases of increasing completeness. Each release isdeveloped in a specific, fixed time period called an iteration.Each iteration is focused on defining, analyzing, designing, building, and testing a setof requirements.1 - 7

DEV475 Mastering Object-Oriented Analysis and Design with UMLWaterfall Development CharacteristicsWaterfall Development CharacteristicsWaterfall ProcessRequirementsanalysisDesignCode and unit testSubsystem integrationSystem test• Delays confirmation ofcritical risk resolution• Measures progress byassessing workproducts that are poorpredictors of time-tocompletion• Delays and aggregatesintegration and testing• Precludes earlydeployment• Frequently results inmajor unplannediterationsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved8Waterfall development is conceptually straightforward because it produces a singledeliverable. The fundamental problem of this approach is that it pushes risk forwardin time, when it is costly to undo mistakes from earlier phases. An initial design maybe flawed with respect to its key requirements, and late discovery of design defectsmay result in costly overruns and/or project cancellation. The waterfall approachtends to mask the real risks to a project until it is too late to do anything meaningfulabout them.1 - 8

Module 1 - Best Practices of Software EngineeringIterative Development Produces an ExecutableIterative Development Produces an ExecutableRequirementsAnalysis & DesignInitialPlanningPlanningManagementEnvironmentImplementationTestEvaluationEach iterationresults in anexecutable releaseDeploymentMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved9The earliest iterations address the greatest risks. Each iteration includes integrationand testing and produces an executable release. Iterations help:• Resolve major risks before making large investments.• Enable early user feedback.• Make testing and integration continuous.• Focus project short-term objective milestones.• Make possible deployment of partial implementations.Iterative processes were developed in response to these waterfall characteristics. Withan iterative process, the waterfall steps are applied iteratively. Instead of developingthe whole system in lock step, an increment (for example, a subset of systemfunctionality) is selected and developed, then another increment, and so on. Theselection of the first increment to be developed is based on risk, with the highestpriority risks first. To address the selected risk(s), choose a subset of use cases.Develop the minimal set of use cases that will allow objective verification (that is,through a set of executable tests) of the risks that you have chosen. Then select thenext increment to address the next-highest risk, and so on. Thus you apply thewaterfall approach within each iteration, and the system evolves incrementally.1 - 9

DEV475 Mastering Object-Oriented Analysis and Design with UMLRisk ProfilesRisk ProfilesWaterfall RiskRiskRisk ReductionIterative RiskTimeMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved10Iterative development produces the architecture first, allowing integration to occur asthe “verification activity” of the design phase, and allowing design flaws to bedetected and resolved earlier in the lifecycle. Continuous integration throughout theproject replaces the “big bang” integration at the end of a project. Iterativedevelopment also provides much better insight into quality, because systemcharacteristics that are largely inherent in the architecture (for example, performance,fault tolerance, and maintainability) are tangible earlier in the process. Thus, issuesare still correctable without jeopardizing target costs and schedules.1 - 10

Module 1 - Best Practices of Software EngineeringPractice 2: Manage RequirementsPractice 2: Manage RequirementsBest PracticesProcess Made PracticalDevelop IterativelyManage RequirementsUse ComponentArchitecturesModel Visually (UML)Continuously Verify QualityManage ChangeMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved11A report from the Standish Group confirms that a distinct minority of softwaredevelopment projects is completed on-time and on-budget. In their report, thesuccess rate was only 16.2%, while challenged projects (operational, but late andover-budget) accounted for 52.7%. Impaired (canceled) projects accounted for31.1%. These failures are attributed to incorrect requirements definition from the startof the project to poor requirements management throughout the developmentlifecycle. (Source: Chaos Report, http://www.standishgroup.com)1 - 11

DEV475 Mastering Object-Oriented Analysis and Design with UMLRequirements ManagementRequirements ManagementMaking sure you• solve the right problem• build the right systemby taking a systematic approach to• eliciting• organizing• documenting• managingthe changing requirements of asoftware application.Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved121 - 12

Module 1 - Best Practices of Software EngineeringAspects of Requirements ManagementAspects of Requirements Management• Analyze the Problem• Understand User Needs• Define the System• Manage Scope• Refine the System Definition• Manage Changing RequirementsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved131 - 13

DEV475 Mastering Object-Oriented Analysis and Design with UMLMap of the TerritoryMap of the TerritoryNeedsProblemProblemSpaceFeaturesSoftwareRequirementsTraceabilitySolutionSpaceTheProductto BeBuiltTest ScriptsDesignUserDocsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved14Managing requirements involves the translation of stakeholder requests into a set ofkey stakeholder needs and system features. These in turn are detailed intospecifications for functional and nonfunctional requirements. Detailed specificationsare translated into test procedures, design, and user documentation.Traceability allows us to:• Assess the project impact of a change in a requirement.• Assess the impact of a failure of a test on requirements (that is, if the test fails, therequirement may not be satisfied).• Manage the scope of the project.• Verify that all requirements of the system are fulfilled by the implementation.• Verify that the application does only what it is intended to do.• Manage change.1 - 14

Module 1 - Best Practices of Software EngineeringPractice 3: Use Component ArchitecturesPractice 3: Use Component ArchitecturesBest PracticesProcess Made PracticalDevelop IterativelyManage RequirementsUse ComponentArchitecturesModel Visually (UML)Continuously Verify QualityManage ChangeMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved15Software architecture is the development product that gives the highest return oninvestment with respect to quality, schedule, and cost, according to the authors ofSoftware Architecture in Practice (Len Bass, Paul Clements and Rick Kazman [1998]Addison-Wesley). The Software Engineering Institute (SEI) has an effort underwaycalled the Architecture Tradeoff Analysis (ATA) Initiative that focuses on softwarearchitecture, a discipline much misunderstood in the software industry. The SEI hasbeen evaluating software architectures for some time and would like to seearchitecture evaluation in wider use. As a result of performing architectureevaluations, AT&T reported a 10 percent productivity increase (from news@sei, Vol.1, No. 2).1 - 15

DEV475 Mastering Object-Oriented Analysis and Design with UMLResilient Component-Based ArchitecturesResilient Component-Based Architectures• Resilient• Meets current and future requirements• Improves extensibility• Enables reuse• Encapsulates system dependencies• Component-based• Reuse or customize components• Select from commercially available components• Evolve existing software incrementallyMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved16Architecture is a part of Design. It is about making decisions on how the system willbe built. But it is not all of the design. It stops at the major abstractions, or, in otherwords, the elements that have some pervasive and long-lasting effect on systemperformance and ability to evolve.A software system’s architecture is perhaps the most important aspect that can beused to control the iterative and incremental development of a system throughout itslifecycle.The most important property of an architecture is resilience –flexibility in the face ofchange. To achieve it, architects must anticipate evolution in both the problemdomain and the implementation technologies to produce a design that can gracefullyaccommodate such changes. Key techniques are abstraction, encapsulation, andobject-oriented Analysis and Design. The result is that applications are fundamentallymore maintainable and extensible.1 - 16

Module 1 - Best Practices of Software EngineeringPurpose of a Component-Based ArchitecturePurpose of a Component-Based Architecture• Basis for reuse• Component reuse• Architecture reuse• Basis for project management• Planning• Staffing• Delivery• Intellectual control• Manage complexity• Maintain integrityComponent-basedarchitecture withlayersBusinessspecificApplicationspecificSystemsoftwareMiddlewareMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved17Definition of a (software) component:RUP Definition: A nontrivial, nearly independent, and replaceable part of a systemthat performs a clear function in the context of a well-defined architecture. Acomponent conforms to and provides the physical realization of a set of interfaces.UML Definition: A physical, replaceable part of a system that packagesimplementation, and that conforms to and provides the realization of a set ofinterfaces. A component represents a physical piece of the implementation of asystem, including software code (source, binary, or executable) or equivalents such asscripts or command files.1 - 17

DEV475 Mastering Object-Oriented Analysis and Design with UMLPractice 4: Model VisuallyPractice 4: Model Visually (UML)Best PracticesProcess Made PracticalDevelop IterativelyManage RequirementsUse ComponentArchitecturesModel Visually (UML)Continuously Verify QualityManage ChangeMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved18A model is a simplification of reality that provides a complete description of a systemfrom a particular perspective. We build models so that we can better understand thesystem we are building. We build models of complex systems because we cannotcomprehend any such system in its entirety.1 - 18

Module 1 - Best Practices of Software EngineeringWhy Model Visually?Why Model Visually?• Captures structure and behavior• Shows how system elements fit together• Keeps design and implementationconsistent• Hides or exposes details as appropriate• Promotes unambiguous communication• The UML provides one language for allpractitionersMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved19Modeling is important because it helps the development team visualize, specify,construct, and document the structure and behavior of system architecture. Using astandard modeling language such as the UML (the Unified Modeling Language),different members of the development team can communicate their decisionsunambiguously to one another.Using visual modeling tools facilitates the management of these models, letting youhide or expose details as necessary. Visual modeling also helps you maintainconsistency among system artifacts - its requirements, designs, and implementations.In short, visual modeling helps improve a team’s ability to manage softwarecomplexity.1 - 19

DEV475 Mastering Object-Oriented Analysis and Design with UMLVisual Modeling With the Unified Modeling LanguageVisual Modeling With the Unified Modeling Language• Multiple views• Precise syntax andsemanticsSequenceDiagramsUse-CaseDiagramsClassDiagramsStaticDiagramsObjectDiagramsCollaborationDiagramsModelsComponentDiagramsDynamicDiagramsStatechartDiagramsActivityDiagramsDeploymentDiagramsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved20In building a visual model of a system, many different diagrams are needed torepresent different views of the system. The UML provides a rich notation forvisualizing models. This includes the following key diagrams:• Use-Case diagrams to illustrate user interactions with the system• Class diagrams to illustrate logical structure• Object diagrams to illustrate objects and links• Component diagrams to illustrate physical structure of the software• Deployment diagrams to show the mapping of software to hardwareconfigurations• Activity diagrams to illustrate flows of events• Statechart diagrams to illustrate behavior• Interaction diagrams (that is, collaboration and sequence diagrams) to illustratebehavior1 - 20

ƯÁ¤¹®¼- ¿¡ ´ëÇ Ñ º ¸±â¸¦»ç¿ëÀÚ°¡ ¿äûÇÑ´Ù.È-ÀÏ°ü¸®ÀÚ´Â Àоî¿Â¹®¼ -ÀÇ Á ¤º¸¸¦ ÇØ ´ç ¹® ¼-°´Ã¼¿¡ ¼³Á¤À» ¿äûÇÑ´Ù.È-¸é °´Ã¼´Â ÀоîµéÀΰ ´Ã¼µé¿ ¡ ´ëÇØ À̸§ º° ·ÎÁ ¤·ÄÀ» ½ÃÄÑ È-¸é¿¡º¸ ¿©ÁØ´Ù.Forwarduser : Clerkuser1: Doc vi ew request ( )mainWnd : MainWndfileMgr : FileMgrrepository : Repository1: Doc v iew request ( )L9: sortByN ame ( )2: fetc hDoc( )7: readFile ( )5: readDoc ( )mainWnd fileMgr :FileMgr9: sortByName ( )2: fetchDoc( )3: create ( )6: fill Document ( )4: create ( )8: fillFile ( )document :Document4: c reate ( )8: fillFile ( )3: create ( )6: fillDocument ( )5: readDoc ( )7: readFile ( )gFile : GrpFiledocument : DocumentgFilerepositoryrepRepositoryname : char * = 0readD oc( )readFile( )FileMgrfetchD oc( )sortByName( )(from Persistence)FileListadd( )del ete( )read( )FileDocumentListad d( )del ete( )fList1GrpFileread( )op en( )create( )fillFile( )Documentname : i ntdoci d : intnumField : intget( )open( )close( )read( )sortFileList( )create( )fillDocument( )read() fill thecode..OpenningReadingadd file [ numberOffile==MAX ] /flag OFFclose fileClosingclose fileadd fileWritingWindow95¹®¼ -° ü¸®Å¬óÀ̾ðÆ®.EXEWindowsNTW indow sNT¹®¼-°ü¸® ¿£Áø.EXEWindows95IBMMainfra meµ¥ÀÌŸº£À̽º¼-¹öSolarisÀÀ¿ë¼-¹ö.EXEW indow s95¹®¼-°ü¸® ¾ÖÇø´AlphaUNIXModule 1 - Best Practices of Software EngineeringVisual Modeling Using UML DiagramsVisual Modeling Using UML DiagramsUse-CaseDiagramClass DiagramStatechartDiagramUse Case 1Actor AActor BUse Case 2Use Case 3CollaborationDiagramFileManagerRepositoryDocumentListDeploymentDiagramDocumentGraphicFileFileFileListSequenceDiagramMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reservedComponentDiagram21andReverseEngineeringTargetSystemVisual modeling with the UML makes application architecture tangible, permitting usto assess it in multiple dimensions. How portable is it? Can it exploit expectedadvances in parallel processing? How can you modify it to support a family ofapplications?We have discussed the importance of architectural resilience and quality. The UMLenables us to evaluate these key characteristics during early iterations — at a pointwhen design defects can be corrected before threatening project success.Advances in forward and reverse engineering techniques permit changes to anapplication’s model to be reflected automatically in its source code, and changes toits source code to be automatically reflected in its model. This is critical when usingan iterative process, in which we expect such changes with each iteration.1 - 21

DEV475 Mastering Object-Oriented Analysis and Design with UMLPractice 5: Continuously Verify QualityPractice 5: Continuously Verify QualityBest PracticesProcess Made PracticalDevelop IterativelyManage RequirementsUse ComponentArchitecturesModel Visually (UML)ContinuouslyVerify QualityManage ChangeMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved22Quality, as used within RUP, is defined as "The characteristic of having demonstratedthe achievement of producing a product which meets or exceeds agreed-uponrequirements, as measured by agreed-upon measures and criteria, and is producedby an agreed-upon process." Given this definition, achieving quality is not simply"meeting requirements" or producing a product that meets user needs andexpectations. Quality also includes identifying the measures and criteria (todemonstrate the achievement of quality), and the implementation of a process toensure that the resulting product has achieved the desired degree of quality (and canbe repeated and managed).In many organizations, software testing accounts for 30% to 50% of softwaredevelopment costs. Yet most people believe that software is not well-tested before itis delivered. This contradiction is rooted in two clear facts. First, testing software isenormously difficult. The different ways a particular program can behave are almostinfinite. Second, testing is typically done without a clear methodology and withoutthe required automation or tool support. While the complexity of software makescomplete testing an impossible goal, a well-conceived methodology and use of stateof-the-arttools can greatly improve the productivity and effectiveness of the softwaretesting.1 - 22

Module 1 - Best Practices of Software EngineeringContinuously Verify Your Software’s QualityContinuously Verify Your Software’s QualitySoftware problems are100 to 1000 times more costlyto find and repair after deployment• Cost to Repair Software• Cost of Lost OpportunitiesCost• Cost of Lost CustomersInceptionElaborationConstructionTransitionMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved23This principle is driven by a fundamental and well-known property of softwaredevelopment: It is a lot less expensive to correct defects during development than tocorrect them after deployment.• Tests for key scenarios ensure that all requirements are properly implemented.• Poor application performance hurts as much as poor reliability.• Verify software reliability — memory leaks, bottlenecks.• Test every iteration — automate test.1 - 23

DEV475 Mastering Object-Oriented Analysis and Design with UMLTesting Dimensions of QualityTesting Dimensions of QualityUsability• Test applicationfrom the perspectiveof convenience toend user.Functionality• Test the accurateworkings of eachusage scenario.Reliability• Test that the applicationbehaves consistentlyand predictably.Supportability• Test the ability tomaintain and supportapplication underproduction use.Performance• Test the online responseunder average andpeak loading.Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved24Functional testing verifies that a system executes the required use-case scenarios asintended. Functional tests may include the testing of features, usage scenarios, andsecurity.Usability testing evaluates the application from the user’s perspective. Usability testsfocus on human factors, aesthetics, consistency in the user interface, online andcontext-sensitive Help, wizards and agents, user documentation, and trainingmaterials.Reliability testing verifies that the application performs reliably and is not prone tofailures during execution (crashes, hangs, and memory leaks). Effective reliabilitytesting requires specialized tools. Reliability tests include tests of integrity, structure,stress, contention, and volume.Performance testing checks that the target system works functionally and reliablyunder production load. Performance tests include benchmark tests, load tests, andperformance profile tests.Supportability testing verifies that the application can be deployed as intended.Supportability tests include installation and configuration tests.1 - 24

Module 1 - Best Practices of Software EngineeringTest Each IterationTest Each IterationIteration 1Iteration 2Iteration 3Iteration 4UML ModelandImplementationTest Suite 1Test Suite 2Test Suite 3Test Suite 4TestsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved25In each iteration, automated tests are created that test the requirements addressed inthat iteration. As new requirements are added in subsequent iterations, new tests aregenerated and run. At times, a requirement may be changed in a later iteration. Inthat case, the tests associated with the changed requirement may be modified orsimply regenerated by an automated tool.1 - 25

DEV475 Mastering Object-Oriented Analysis and Design with UMLTest Within the Product Development LifecycleTest Within the Product Development LifecycleIterationXIterationX + 1IterationX + 2Requirements CaptureProjectPlanningAnalysis and DesignBuildImplementationDefineValidateTest andAchieveImproveMissionBuildEvaluateMissionAssetsVerify ApproachTimeMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved26The testing lifecycle is a part of the software lifecycle; both should start in anequivalent time frame. The design and development process for tests can be ascomplex and arduous as the process for developing the software product itself. If testsdo not start in line with the first executable software releases, the test effort will backload the discovery of potentially important problems until late in the developmentcycle.1 - 26

Module 1 - Best Practices of Software EngineeringPractice 6: Manage ChangePractice 6: Manage ChangeBest PracticesProcess Made PracticalDevelop IterativelyManage RequirementsUse ComponentArchitecturesModel Visually (UML)Continuously Verify QualityManage ChangeMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved27You cannot stop change from being introduced into a project. However, you mustcontrol how and when changes are introduced into project artifacts, and whointroduces those changes.You must also synchronize changes across development teams and locations.Unified Change Management (UCM) is the Rational Software approach to managingchange in software system development, from requirements to release.1 - 27

DEV475 Mastering Object-Oriented Analysis and Design with UMLWhat Do You Want to Control?What Do You Want to Control?• Secure workspaces for each developer• Automated integration/build management• Parallel developmentWorkspaceManagementParallelDevelopmentConfigurationManagement ismore than justcheck-in andcheck-outProcessIntegrationREPORTALERTBuildManagementMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved28Establishing a secure workspace for each developer provides isolation from changesmade in other workspaces and control of all software artifacts — models, code,documents and so forth.A key challenge to developing software-intensive systems is the need to cope withmultiple developers, organized into different teams, possibly at different sites, allworking together on multiple iterations, releases, products, and platforms. In theabsence of disciplined control, the development process rapidly degrades into chaos.Progress can come to a stop.Three common problems that result are:• Simultaneous update: When two or more roles separately modify the sameartifact, the last one to make changes destroys the work of the former.• Limited notification: When a problem is fixed in shared artifacts, some of theusers are not notified of the change.• Multiple versions: With iterative development, it would not be unusual to havemultiple versions of an artifact in different stages of development at the sametime. For example, one release is in customer use, one is in test, and one is still indevelopment. If a problem is identified in any one of the versions, the fix must bepropagated among all of them.1 - 28

Module 1 - Best Practices of Software EngineeringAspects of a CM SystemAspects of a CM System• Change Request Management (CRM)• Configuration Status Reporting• Configuration Management (CM)• Change Tracking• Version Selection• Software ManufactureMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved29Change Request Management (CRM) addresses the organizational infrastructurerequired to assess the cost and schedule impacts of a requested change to the existingproduct. CRM addresses the workings of a Change Review Team or Change ControlBoard.Configuration Status Reporting (Measurement) is used to describe the “state” ofthe product based on the type, number, rate and severity of defects found and fixedduring the course of product development. Metrics derived under this aspect,through either audits or raw data, are useful in determining the overall completenessof the project.Configuration Management (CM) describes the product structure and identifies itsconstituent configuration items, which are treated as single versionable entities in theconfiguration management process. CM deals with defining configurations, buildingand labeling, and collecting versioned artifacts into constituent sets, as well as withmaintaining traceability among these versions.Change Tracking describes what is done to components for what reason and at whattime. It serves as the history of and rationale for changes. It is quite separate fromassessing the impact of proposed changes as described under Change RequestManagement.Version Selection ensures that the right versions of configuration items are selectedfor change or implementation. Version selection relies on a solid foundation of“configuration identification.”Software Manufacture covers the need to automate the steps to compile, test, andpackage software for distribution.1 - 29

DEV475 Mastering Object-Oriented Analysis and Design with UMLUnified Change Management (UCM)Unified Change Management (UCM)UCM involves:• Management across the lifecycle• System• Project Management• Activity-Based Management• Tasks• Defects• Enhancements• Progress Tracking• Charts• ReportsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved30Unified Change Management (UCM) is Rational Software's approach to managingchange in software system development, from requirements to release. UCM spansthe development lifecycle, defining how to manage change to requirements, designmodels, documentation, components, test cases, and source code.One of the key aspects of the UCM model is that it unifies the activities used to planand track project progress and the artifacts undergoing change.1 - 30

Module 1 - Best Practices of Software EngineeringBest Practices Reinforce Each OtherBest Practices Reinforce Each OtherBest PracticesDevelop IterativelyManage RequirementsUse Component ArchitecturesModel Visually (UML)Ensures users are involvedas requirements evolveValidates architecturaldecisions early onAddresses complexity ofdesign/implementation incrementallyContinuously Verify QualityMeasures quality early and oftenManage ChangeEvolves baselines incrementallyMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved31In the case of our Six Best Practices, the whole is much greater than the sum of theparts. Each of the Best Practices reinforces and, in some cases, enables the others.This slide shows just one example: how iterative development leverages the other fiveBest Practices. However, each of the other five practices also enhances iterativedevelopment. For example, iterative development done without adequaterequirements management can easily fail to converge on a solution. Requirementscan change at will, users cannot agree, and the iterations go on forever.When requirements are managed, this is less likely to happen. Changes torequirements are visible, and the impact on the development process is assessedbefore the changes are accepted. Convergence on a stable set of requirements isensured. Similarly, each pair of Best Practices provides mutual support. Hence,although it is possible to use one Best Practice without the others, it is notrecommended, since the resulting benefits will be significantly decreased.1 - 31

DEV475 Mastering Object-Oriented Analysis and Design with UMLModule 1 Content OutlineModule 1 Content Outline• Software development problems• The Six Best Practices• RUP within the context of the Six BestPracticesMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved321 - 32

Module 1 - Best Practices of Software EngineeringRational Unified Process Implements Best PracticesRational Unified Process Implements Best PracticesBest PracticesProcess Made PracticalDevelop IterativelyManage RequirementsUse Component ArchitecturesModel Visually (UML)Continuously Verify QualityManage ChangeMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved33Why have a process?• Provides guidelines for efficient development of quality software• Reduces risk and increases predictability• Promotes a common vision and culture• Captures and institutionalizes Best PracticesThe Rational Unified Process (RUP) is a generic business process for object-orientedsoftware engineering. It describes a family of related software-engineering processessharing a common structure and a common process architecture. It provides adisciplined approach to assigning tasks and responsibilities within a developmentorganization. Its goal is to ensure the production of high-quality software that meetsthe needs of its end users within a predictable schedule and budget. The RUPcaptures the Best Practices in modern software development in a form that can beadapted for a wide range of projects and organizations.The UML provides a standard for the artifacts of development (semantic models,syntactic notation, and diagrams): the things that must be controlled and exchanged.But the UML is not a standard for the development process. Despite all of the valuethat a common modeling language brings, you cannot achieve successfuldevelopment of today’s complex systems solely by the use of the UML. Successfuldevelopment also requires employing an equally robust development process, whichis where the RUP comes in.1 - 33

DEV475 Mastering Object-Oriented Analysis and Design with UMLAchieving Best PracticesAchieving Best Practices• Iterative approach• Guidance for activitiesand artifacts• Process focus onarchitecture• Use cases that drivedesign andimplementation• Models that abstractthe systemMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved34Examples:• The dynamic structure (phases and iterations) of the Rational Unified Processcreates the basis of iterative development.• The Project Management discipline describes how to set up and execute aproject using phases and iterations.• The Use-Case Model of the Requirements discipline and the risk list determinewhat functionality you implement in an iteration.• The Workflow Details of the Requirements discipline show the activities andartifacts that make requirements management possible.• The iterative approach allows you to progressively identify components, and todecide which one to develop, which one to reuse, and which one to buy.• The Unified Modeling Language (UML) used in the process represents the basisof visual modeling and has become the de facto modeling language standard.• The focus on software architecture allows you to articulate the structure: thecomponents, the ways in which they integrate, and the fundamental mechanismsand patterns by which they interact.1 - 34

Module 1 - Best Practices of Software EngineeringA Team-Based Definition of ProcessA Team-Based Definition of ProcessA process defines Who is doing What,When, and How, in order to reach a certaingoal.New or changedrequirementsSoftware EngineeringProcessNew or changedsystemMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved351 - 35

DEV475 Mastering Object-Oriented Analysis and Design with UMLProcess Structure - Lifecycle PhasesProcess Structure - Lifecycle PhasesInception Elaboration Construction TransitiontimeRational Unified Process has four phases:• Inception - Define the scope of project• Elaboration - Plan project, specify features andbaseline architecture• Construction - Build the product• Transition - Transition the product into end-usercommunityMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved36During Inception, we define the scope of the project: what is included and what isnot. We do this by identifying all the actors and use cases, and by drafting the mostessential use cases (typically 20% of the complete model). A business plan isdeveloped to determine whether resources should be committed to the project.During Elaboration, we focus on two things: getting a good grasp of the requirements(80% complete) and establishing an architectural baseline. If we have a good grasp ofthe requirements and the architecture, we can eliminate a lot of the risks, and we willhave a good idea of how much work remains to be done. We can make detailedcost/resource estimations at the end of Elaboration.During Construction, we build the product in several iterations up to a beta release.During Transition, we move the product to the end user and focus on end-usertraining, installation, and support.The amount of time spent in each phase varies. For a complex project with manytechnical unknowns and unclear requirements, Elaboration may include three-to-fiveiterations. For a simple project, where requirements are known and the architectureis simple, Elaboration may include only a single iteration.1 - 36

Module 1 - Best Practices of Software EngineeringPhase Boundaries Mark Major MilestonesPhase Boundaries Mark Major MilestonesInception Elaboration Construction TransitiontimeLifecycleObjectiveMilestone(LCO)LifecycleArchitectureMilestone(LCA)Initial OperationalCapabilityMilestone(IOC)ProductReleaseMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved37At each of the major milestones, we review the project and decide whether toproceed with it as planned, to cancel the it, or to revise it. The criteria used to makethese decisions vary by phase.LCO: scope is agreed upon and risks are understood and reasonableLCA: high risks are addressed and architecture is stableIOC: product is complete and quality is acceptableThe evaluation criteria for the Inception phase (LCO) include: stakeholderconcurrence on scope definition and cost/schedule estimates; requirementsunderstanding as evidenced by the fidelity of the primary use cases; credibility ofcost/schedule estimates, priorities, risks, and development process; depth andbreadth of any architectural prototype; actual expenditures versus plannedexpenditures.The evaluation criteria for the Elaboration phase (LCA) include: stability of theproduct vision and architecture; resolution of major risk elements; adequate planningand reasonable estimates for project completion; stakeholder acceptance of theproduct vision and project plan; and acceptable expenditure level.The evaluation criteria for the Construction phase (IOC) include: stability andmaturity of the product release (that is, is it ready to be deployed?); readiness of thestakeholders for the transition; and acceptable expenditure level.At the end of the Transition phase, we decide whether to release the product. Webase this primarily on the level of user satisfaction achieved during the Transitionphase. Often this milestone coincides with the initiation of another developmentcycle to improve or enhance the product. In many cases, this new development cyclemay already be underway.1 - 37

DEV475 Mastering Object-Oriented Analysis and Design with UMLIterations and PhasesIterations and PhasesInception Elaboration Construction TransitionPreliminaryIterationArchitect.IterationArchitect.IterationDevel.IterationDevel.IterationDevel.IterationTransition TransitionIteration IterationMinor Milestones: ReleasesAn iteration is a distinct sequence of activities based onan established plan and evaluation criteria, resulting in anexecutable release (internal or external).Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved38Within each phase, there is a series of iterations. The number of iterations per phasewill vary. Each iteration results in an executable release encompassing larger andlarger subsets of the final application.An internal release is kept within the development environment and (optionally)demonstrated to the stakeholder community. We provide stakeholders (usually users)with an external release for installation in their environment. External releases aremuch more expensive because they require user documentation and technicalsupport — because of this, they normally occur only during the Transition phase.The end of an iteration marks a minor milestone. At this point, we assess technicalresults and revise future plans as necessary.1 - 38

Module 1 - Best Practices of Software EngineeringBringing It All Together: The Iterative ApproachBringing It All Together: The Iterative ApproachIn aniteration,you walkthrough alldisciplines.Disciplinesgroupactivitieslogically.Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved39This slide illustrates how phases and iterations (the time dimension) relate to thedevelopment activities (the discipline dimension). The relative size of each color areain the graph indicates how much of the activity is performed in each phase oriteratino.Each iteration involves activities from all disciplines. The relative amount of workrelated to the disciplines changes between iterations. For instance, during lateConstruction, the main work is related to Implementation and Test and very littlework on Requirements is done.Note that requirements are not necessarily complete by the end of Elaboration. It isacceptable to delay the analysis and design of well-understood portions of the systemuntil Construction because they are low in risk.1 - 39

DEV475 Mastering Object-Oriented Analysis and Design with UMLDisciplines Produce ModelsDisciplines Produce ModelsDisciplinesBusinessModelingImplementationRequirementsAnalysis &DesignModelsRealizedByBusiness Use-Case ModelUse-CaseModelRealized ByImplementedByBBBBBusinessObject ModelAutomatedByDesign ModelImplementationModelMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved40The RUP takes a model-driven approach. Several models are needed to fully describethe evolving system. Each major discipline produces one of those models. The modelsare developed incrementally across iterations.• The Business Model is a model of what the business processes are and of thebusiness environment. It can be used to generate requirements of supportinginformation systems.• The Use-Case Model is a model of what the system is supposed to do and of thesystem environment.• The Design Model is an object model describing the realization of use cases. Itserves as an abstraction of the implementation model and its source code.• The Implementation Model is a collection of components and theimplementation subsystems that contain them.Test Suites are derived from many of these models.1 - 40

Module 1 - Best Practices of Software EngineeringDisciplines Guide Iterative DevelopmentDisciplines Guide Iterative DevelopmentBusinessModeling:WorkflowRequirements:WorkflowMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved41Within a discipline, workflows group activities that are done together. Disciplineworkflows will be present in varying degrees, depending on the phase.1 - 41

DEV475 Mastering Object-Oriented Analysis and Design with UMLOverview of Rational Unified Process ConceptsOverview of Rational Unified Process ConceptsDivided into Considers Described byPhase Iteration DisciplineWorkflowDetailParticipates inReferencesRoleActivityResponsible forModifiesDocumentModelModelElementArtifactMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved42Basic Concepts in the RUPA software lifecycle in the RUP is decomposed over time into four sequential phases,each concluded by a major milestone. Each phase is essentially a span of timebetween two major milestones.An iteration is a pass through a sequence of process disciplines. Each iterationconcludes with the release of an executable product.A discipline shows all the activities that you may go through to produce a particularset of artifacts. We describe these disciplines at an overview level — a summary of allroles, activities, and artifacts that are involved.A workflow detail is a grouping of activities that are done "together," presented withinput and resulting artifacts.A role defines the behavior and responsibilities of an individual, or a set of individualsworking together as a team.An activity is the smallest piece of work that is relevant.Artifacts: These are the modeling constructs and documents that activities evolve,maintain, or use as input.• Documents: These record system requirements, including usability, reliability,performance, and supportability requirements.• Model: This is a simplified view of a system. It shows the essentials of the systemfrom a particular perspective and hides the non-essential details.• Model elements: These help the team visualize, construct, and document thestructure and behavior of the system, without getting lost in complexity.1 - 42

Module 1 - Best Practices of Software EngineeringReviewReview• Best Practices guide software engineeringby addressing root causes.• Best Practices reinforce each other.• Process guides a team on who does what,when, and how.• The Rational Unified Process is a means ofachieving Best Practices.Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved431 - 43

DEV475 Mastering Object-Oriented Analysis and Design with UML1 - 44

► ► ► Module 2Concepts of Object OrientationMastering Object-Oriented Analysisand Design with UMLModule 2: Concepts of Object OrientationTopicsWhat Is Object Technology?................................................................................. 2-4Basic Principles of Object Orientation................................................................. 2-15Representing Classes in the UML ........................................................................ 2-24Review............................................................................................................... 2-512 - 1

DEV475 Mastering Object-Oriented Analysis and Design with UMLObjectives: Concepts of Object OrientationObjectives: Concepts of Object Orientation• Explain the basic principles of objectorientation• Define the basic concepts and terms ofobject orientation and the associated UMLnotation• Demonstrate the strengths of objectorientation• Present some basic UML modeling notationMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 22 - 2

Module 2 - Concepts of Object OrientationBest Practices ImplementationBest Practices Implementation• Object technology helps implementthese Best Practices.• Develop Iteratively: tolerates changingrequirements, integrates elementsprogressively, facilitates reuse.• Use Component-Based Architectures:architectural emphasis, componentbaseddevelopment.• Model Visually: easy understanding,easy modification.Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 3• Iterative development allows you to account for technological changes. If atechnology changes, becomes a standard, or new technology appears, the projectcan take advantage of it. This is particularly true for platform changes or lowerlevelinfrastructure changes.• Integration is not one "big bang" at the end. Elements are integrated progressively.Actually, the iterative approach is almost continuous integration. Noniterativeintegration takes up to 40% of the total effort at the end of a project and is hardto plan accurately. What used to be a long, uncertain, and difficult process isbroken down into six-to-nine smaller integrations that start with far fewerelements to integrate.• By clearly articulating the major components and the critical interfaces betweenthem, an architecture allows you to plan for reuse, both internally, (theidentification of common parts) and externally (the incorporation of off-the-shelfcomponents). On a larger scale, it also allows the reuse of the architecture itselfin the context of a line of products that addresses different functionality in acommon domain.• An object-oriented model aims at reflecting the world we experience in reality.Thus, the objects themselves often correspond to phenomena in the real worldthat the system is to handle. For example, an object can be an invoice in abusiness system or an employee in a payroll system.• A model, correctly designed using object technology, is easy to understand andmodify. It clearly corresponds to reality, and changes in a particular phenomenonconcern only the object that represents that phenomenon.2 - 3

DEV475 Mastering Object-Oriented Analysis and Design with UMLWhat Is Object Technology?What Is Object Technology?• Object technology• A set of principles guidingsoftware constructiontogether with languages,databases, and other toolsthat support thoseprinciples. (ObjectTechnology: A Manager’sGuide, Taylor, 1997)Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 4• Object technology is used for creating models that reflect a specific domain usingthe terminology of the domain.• Models created using object technology are easy to create, change, expand,validate, and verify.• Systems built using object technology are flexible to change, have well-definedarchitectures, and allow reusable components to be created and implemented.• Models created using object technology are conveniently implemented insoftware using object-oriented programming languages.• Object technology is not just a theory, but a well-proven technology used in alarge number of projects and for building many types of systems.• Successful implementation of object technology requires a method that integratesa development process and a modeling language with suitable constructiontechniques and tools. (UML Toolkit, Eriksson and Penker, 1997)2 - 4

Module 2 - Concepts of Object OrientationStrengths of Object TechnologyStrengths of Object Technology• Provides a single paradigm• A single language used by users, analysts, designers,and implementers• Facilitates architectural and code reuse• Models more closely reflect the real world• More accurately describes corporate entities• Decomposed based on natural partitioning• Easier to understand and maintain• Provides stability• A small change in requirements does not mean massivechanges in the system under development• Is adaptive to changeMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 5• The UML represents a convergence of Best Practices throughout the objecttechnologyindustry. It provides a consistent language that can be applied to bothsystem and business engineering.• Object technology can help a company change its systems almost as fast as thecompany itself changes.2 - 5

DEV475 Mastering Object-Oriented Analysis and Design with UMLWhat Is a Model?What Is a Model?• A model is a simplification of reality.Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 6According to Grady Booch, a model provides the blueprints of a system. It canencompass detailed plans, as well as more general plans that give a 30,000-foot viewof the system under construction. A good model includes those elements that are notrelevant to the given level of abstraction. Every system can be described fromdifferent aspects using different models, and each model is therefore a semanticallyclosed abstraction of the system. A model can be structural, emphasizing theorganization of the system, or it can be behavioral, emphasizing the dynamics of thesystem.2 - 6

Module 2 - Concepts of Object OrientationWhy Do We Model?Why Do We Model?• We build models to better understand the systemwe are developing.• Modeling achieves four aims. It:• Helps us to visualize a system as we want it to be.• Permits us to specify the structure or behavior of asystem.• Gives us a template that guides us in constructing asystem.• Documents the decisions we have made.• We build models of complex systems because wecannot comprehend such a system in its entirety.Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 7According to The Unified Modeling Language Use Guide (Booch, Rumbaugh, andJacobson, 1998), modeling achieves four aims:• Models help us to visualize a system as we want it to be. A model helps thesoftware team communicate the vision for the system being developed. It is verydifficult for a software team to have a unified vision of a system that is onlydescribed in specification and requirement documents. Models bring aboutunderstanding of the system.• Models permit us to specify the structure or behavior of a system. A modelallows us to document system behavior and structure before coding the system.• Models give us a template that guides us in constructing a system. A model is aninvaluable tool during construction. It serves as a road map for a developer. Haveyou experienced a situation where a developer coded incorrect behaviorbecause there was confusion over the wording in a requirements document?Modeling helps alleviate that situation.• Models document the decisions that have been made. Models are valuable toolsin the long term because they give “hard” information on design decisions. Youdon’t need to rely on someone’s memory.2 - 7

DEV475 Mastering Object-Oriented Analysis and Design with UMLWhat Is an Object?What Is an Object?• Informally, an object represents an entity,either physical, conceptual, or software.• Physical entityTruck• Conceptual entityChemical Process• Software entityLinked ListMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 8• Objects allow the software developer to represent real-world concepts in thesoftware design. These real-world concepts can represent a physical entity suchas a person, truck, or space shuttle.• Objects can be concepts like a chemical process or algorithms.• Objects can even represent software entities like a linked list.2 - 8

Module 2 - Concepts of Object OrientationA More Formal DefinitionA More Formal Definition• An object is an entitywith a well-definedboundary and identitythat encapsulates stateand behavior.• State is represented byattributes andrelationships.• Behavior is representedby operations, methods,and state machines.AttributesOperationsObjectMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 9• An object is an entity that has a well-defined boundary. That is, the purpose ofthe object should be clear.• An object has two key components: attributes and operations.• Attributes represent an object’s state, and operations represent the behavior ofthe object.• Object state and behavior are discussed on the next few slides.2 - 9

DEV475 Mastering Object-Oriented Analysis and Design with UMLAn Object Has StateAn Object Has State• The state of an object is one of the possibleconditions in which the object may exist.• The state of an object normally changes overtime.Name: J ClarkEmployee ID: 567138Date Hired: July 25, 1991Status: TenuredDiscipline: FinanceMaximum Course Load: 3 classesName: J ClarkEmployee ID: 567138HireDate: 07/25/1991Status: TenuredDiscipline: FinanceMaxLoad: 3Professor ClarkMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 10• The state of an object is one of the possible conditions that an object may existin, and it normally changes over time.• The state of an object is usually implemented by a set of properties calledattributes, along with the values of the properties and the links the object mayhave with other objects.• State is not defined by a “state” attribute or set of attributes. Instead, state isdefined by the total of an object’s attributes and links. For example, if ProfessorClark’s status changed from Tenured to Retired, the state of the Professor Clarkobject would change.2 - 10

Module 2 - Concepts of Object OrientationAn Object Has BehaviorAn Object Has Behavior• Behavior determines how an object acts andreacts.• The visible behavior of an object is modeled bythe set of messages it can respond to (operationsthe object can perform).SubmitFinalGrades()AcceptCourseOffering()SetMaxLoad()Professor Clark’s behaviorSubmit Final GradesAccept Course OfferingTake SabbaticalMaximum Course Load: 3 classesTakeSabbatical()Professor ClarkMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 11• The second characteristic of an object is that it has behavior. Objects areintended to mirror the concepts that they are modeled after, including behavior.• Behavior determines how an object acts and reacts to requests from otherobjects.• Object behavior is represented by the operations that the object can perform.For example, Professor Clark can choose to take a sabbatical once every fiveyears. The Professor Clark object represents this behavior through theTakeSabbatical() operation.2 - 11

DEV475 Mastering Object-Oriented Analysis and Design with UMLAn Object Has IdentityAn Object Has Identity• Each object has a unique identity, even ifthe state is identical to that of anotherobject.Professor “J Clark”teaches BiologyProfessor “J Clark”teaches BiologyMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 12In the real world, two people can share the same characteristics: name, birth date,job description. Yet, there is no doubt that they are two individuals with their ownunique identities.The same concept holds true for objects. Although two objects may share the samestate (attributes and relationships), they are separate, independent objects with theirown unique identity.2 - 12

Module 2 - Concepts of Object OrientationRepresenting Objects in the UMLRepresenting Objects in the UML• An object is represented as a rectanglewith an underlined name.J Clark : ProfessorNamed ObjectProfessor J Clark: ProfessorUnnamed ObjectMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 13• An object is represented as a rectangle.• Within the rectangle, underlined, is the name of the class. To name an object,add its name before the colon.• To keep an object unnamed (anonymous), do not include a name.2 - 13

DEV475 Mastering Object-Oriented Analysis and Design with UMLWhat Are Stereotypes?What Are Stereotypes?• Stereotypes define a new model element interms of another model element.• Sometimes you need to introduce new thingsthat speak the language of your domain andlook like primitive building blocks.ClassStereotypeMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 14A stereotype can be defined as:An extension of the basic UML notation that allows you to define a new modelingelement based on an existing modeling element.• The new element may contain additional semantics but still applies in all caseswhere the original element is used. In this way, the number of unique UMLsymbols is reduced, simplifying the overall notation.• The name of a stereotype is shown in guillemets (>).• A unique icon may be defined for the stereotype, and the new element may bemodeled using the defined icon or the original icon with the stereotype namedisplayed, or both.• Stereotypes can be applied to all modeling elements, including classes,relationships, components, and so on.• Each UML element can only have one stereotype.• Stereotype uses include modifying code generation behavior and using adifferent or domain-specific icon or color where an extension is needed orhelpful to make a model more clear or useful.2 - 14

Module 2 - Concepts of Object OrientationBasic Principles of Object OrientationBasic Principles of Object OrientationObject OrientationAbstractionEncapsulationModularityHierarchyMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 15There are four basic principles of object orientation. They are:• Abstraction• Encapsulation• Modularity• Hierarchy2 - 15

DEV475 Mastering Object-Oriented Analysis and Design with UMLWhat Is Abstraction?What Is Abstraction?• The essential characteristicsof an entity that distinguish itfrom all other kinds of entities• Defines a boundary relative tothe perspective of the viewer• Is not a concrete manifestation,denotes the ideal essence ofsomethingMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 16Abstraction can be defined as:Any model that includes the most important, essential, or distinguishing aspects ofsomething while suppressing or ignoring less important, immaterial, or diversionarydetails. It is the result of removing distinctions so as to emphasize commonalties.(Dictionary of Object Technology, Firesmith, Eykholt, 1995)• Abstraction allows us to manage complexity by concentrating on the essentialcharacteristics of an entity that distinguish it from all other kind of entities.• An abstraction is domain - and perspective - dependent. That is, what isimportant in one context, may not be in another.• OO allows us to model our system using abstractions from the problem domain(for example, classes and objects).2 - 16

Module 2 - Concepts of Object OrientationExample: AbstractionExample: AbstractionStudentProfessorCourse Offering (9:00 AM,Monday-Wednesday-Friday)Course (e.g., Algebra)Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 17The following are examples of abstraction.• A student is a person enrolled in classes at the university.• A professor is a person teaching classes at the university.• A course is a class offered by the university.• A course offering is a specific offering for a course, including days of the weekand times.2 - 17

DEV475 Mastering Object-Oriented Analysis and Design with UMLWhat Is Encapsulation?What Is Encapsulation?• Hide implementation from clients.• Clients depend on interface.Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 18Improves ResiliencyEncapsulation can be defined as:The physical localization of features (for example, properties, behaviors) into a singleblackbox abstraction that hides their implementation (and associated designdecisions) behind a public interface. (Dictionary of Object Technology, Firesmith,Eykholt, 1995)• Encapsulation is often referred to as “information hiding,” making it possible forthe clients to operate without knowing how the implementation fulfills theinterface.• Encapsulation eliminates direct dependencies on the implementation (clientsdepend on/use the interface). Thus, it is possible to change the implementationwithout updating the clients as long as the interface is unchanged.• Clients will not be affected by changes in implementation. This reduces the“ripple effect,” which happens when a correction to one operation forces thecorresponding correction in a client operation and so on. As a result ofencapsulation, maintenance is easier and less expensive.• Encapsulation offers two kinds of protection. It protects an object’s internal statefrom being corrupted by its clients and client code from changes in the object’simplementation.2 - 18

Module 2 - Concepts of Object OrientationEncapsulation IllustratedEncapsulation Illustrated• Professor Clarkneeds to be ableto teach fourclasses in thenext semester.SetMaxLoad(4)Professor ClarkSubmitFinalGrades()AcceptCourseOffering()Name: J ClarkEmployee ID: 567138HireDate: 07/25/1991Status: TenuredDiscipline: FinanceMaxLoad:4SetMaxLoad()TakeSabbatical()Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 19• The key to encapsulation is an object’s message interface. The object interfaceensures that all communication with the object takes place through a set ofpredefined operations. Data inside the object is only accessible by the object’soperations. No other object can reach inside of the object and change itsattribute values.• For example, Professor Clark needs to have her maximum course load increasedfrom three classes to four classes per semester. Another object will make arequest to Professor Clark to set the maximum course load to four.The attribute,MaxLoad, is then changed by the SetMaxLoad() operation.• Encapsulation is beneficial in this example because the requesting object doesnot need to know how to change the maximum course load. In the future, thenumber of variables that are used to define the maximum course load may beincreased, but that does not affect the requesting object. The requesting objectdepends on the operation interface for the Professor Clark object.2 - 19

DEV475 Mastering Object-Oriented Analysis and Design with UMLWhat Is Modularity?What Is Modularity?• Modularity is the breakingup of something complex intomanageable pieces.• Modularity helps people tounderstand complex systems.Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 20Modularity can be defined as:The logical and physical decomposition of things (for example, responsibilities andsoftware) into small, simple groupings (for example, requirements and classes,respectively), which increase the achievements of software-engineering goals.(Dictionary of Object Technology, Firesmith, Eykholt, 1995)• Another way to manage complexity is to break something that is large andcomplex into a set of smaller, more manageable pieces. These pieces can thenbe independently developed as long as their interactions are well understood.• Packages (described later in the course) support the definition of modularcomponents.2 - 20

Module 2 - Concepts of Object OrientationExample: ModularityExample: Modularity• For example, breakcomplex systems intosmaller modules.BillingSystemCourseCatalogSystemCourse RegistrationSystemStudentManagementSystemMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 21Often, the system under development is too complex to understand. To furtherunderstanding, the system is broken into smaller blocks that are each maintainedindependently. Breaking down a system in this way is called modularity. It is criticalfor understanding a complex system.For example, the system under development is a Course Registration system. Thesystem itself is too large and abstract to allow an understanding of the details.Therefore, the development team broke this system into three modular systems, eachindependent of the others.• The Billing System• Course Catalog System• Student Management System2 - 21

DEV475 Mastering Object-Oriented Analysis and Design with UMLWhat Is Hierarchy?What Is Hierarchy?IncreasingabstractionAssetBankAccountSecurityRealEstateSavingsCheckingStockBondDecreasingabstractionElements at the same level of the hierarchyshould be at the same level of abstraction.Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 22Hierarchy can be defined as:Any ranking or ordering of abstractions into a tree-like structure. Kinds: Aggregationhierarchy, class hierarchy, containment hierarchy, inheritance hierarchy, partitionhierarchy, specialization hierarchy, type hierarchy. (Dictionary of Object Technology,Firesmith, Eykholt, 1995)• Hierarchy organizes items in a particular order or rank (for example, complexityand responsibility). This organization is dependent on perspective. Using ahierarchy to describe differences or variations of a particular concept provides formore descriptive and cohesive abstractions and a better allocation ofresponsibility.• In any one system, there may be multiple abstraction hierarchies (for example, afinancial application may have different types of customers and accounts).• Hierarchy is not an organizational chart or a functional decomposition.• Hierarchy is a taxonomic organization. The use of hierarchy makes it easy torecognize similarities and differences. For example, botany organizes plants intofamilies. Chemistry organizes elements in a periodic table.2 - 22

Module 2 - Concepts of Object OrientationWhat Is a Class?What Is a Class?• A class is a description of a set of objects thatshare the same attributes, operations,relationships, and semantics.• An object is an instance of a class.• A class is an abstraction in that it• Emphasizes relevant characteristics.• Suppresses other characteristics.Class+ attribute+ operation()Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 23A class can be defined as:A description of a set of objects that share the same attributes, operations,relationships, and semantics. (The Unified Modeling Language User Guide, Booch,1999)• There are many objects identified for any domain.• Recognizing the commonalties among the objects and defining classes helps usdeal with the potential complexity.• The OO principle of abstraction helps us deal with complexity.2 - 23

DEV475 Mastering Object-Oriented Analysis and Design with UMLRepresenting Classes in the UMLRepresenting Classes in the UML• A class is represented using a rectangle withcompartments.Professor-name- employeeID : UniqueID- hireDate-status- discipline- maxLoad+ submitFinalGrade()+ acceptCourseOffering()+ setMaxLoad()+ takeSabbatical()Professor J ClarkMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 24• The UML notation for a class permits you to see an abstraction apart from anyspecific programming language, which lets you emphasize the most importantparts about an abstraction — its name, attributes, and operations.• Graphically, a class is represented by a rectangle.2 - 24

Module 2 - Concepts of Object OrientationThe Relationship Between Classes and ObjectsThe Relationship Between Classes and Objects• A class is an abstract definition of an object.• It defines the structure and behavior of each object inthe class.• It serves as a template for creating objects.• Classes are not collections of objects.Professor TorpieProfessorProfessor MeijerProfessor AllenMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 25• A class is a description of a set of objects that share the same responsibilities,relationships, operations, attributes, and semantics.• An object is defined by a class. A class defines a template for the structure andbehavior of all its objects. The objects created from a class are also called theinstances of the class.• The class is the static description; the object is a run-time instance of that class.• Since we model from real-world objects, software objects are based on the realworldobjects, but they exist only in the context of the system.• Starting with real-world objects, abstract out what you do not care about. Then,take these abstractions and categorize, or classify them, based on what you docare about. Classes in the model are the result of this classification process.• These classes are then used as templates within an executing software system tocreate software objects. These software objects represent the real-world objectswe originally started with.• Some classes/objects may be defined that do not represent real-world objects.They are there to support the design and are "software only.”2 - 25

DEV475 Mastering Object-Oriented Analysis and Design with UMLWhat Is an Attribute?What Is an Attribute?• An attribute is a named property of a class thatdescribes a range of values that instances ofthe property may hold.• A class may have any number of attributes or no attributes at all.AttributesStudent-name- address- studentID- dateOfBirthMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 26An attribute can be defined as:A named property of a class that describes the range of values that instances of theproperty may hold. (The Unified Modeling Language User Guide, Booch, 1999)• A class may have any number of attributes or no attributes at all. At any time, anobject of a class will have specific values for every one of its class’ attributes.• An attribute defined by a class represents a named property of the class or itsobjects. An attribute has a type that defines the type of its instances.• An attribute has a type, which tells us what kind of attribute it is. Typicalattributes are integer, Boolean, real, and enumeration. These are called primitivetypes. Primitive types can be specific for a certain programming language.2 - 26

Module 2 - Concepts of Object OrientationWhat Is an Operation?What Is an Operation?• An operation is the implementation of a servicethat can be requested from any object of theclass to affect behavior.• A class may have any number of operations ornone at all.StudentOperations+ getTuition()+ addSchedule()+ getSchedule()+ deleteSchedule()+ hasPrerequisites()Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 27An operation can be defined as:The implementation of a service that can be requested from any object of the class toaffect behavior. (The Unified Modeling Language User Guide, Booch, 1999)• The operations in a class describe what the class can do.• An operation can be either a command or a question. Only a command canchange the state of the object; a question should never change it.• An operation is described with a return-type, name, and zero or moreparameters. Together, the return-type, name, and parameters are called thesignature of the operation.• The outcome of the operation depends on the current state of the object. Often,but not always, invoking an operation on an object changes the object’s data orstate.2 - 27

DEV475 Mastering Object-Oriented Analysis and Design with UMLWhat Is Polymorphism?What Is Polymorphism?• The ability to hide many differentimplementations behind a single interfaceManufacturer AManufacturer BManufacturer COO Principle:EncapsulationMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 28The Greek term polymorphos means “having many forms.” There may be one ormany implementations of a given interface. Every implementation of an interfacemust fulfill the requirements of that interface. In some cases, the implementation canperform more than the basic interface requirements.For example, the same remote can be used to control any type of television(implementation) that supports the specific interface that the remote was designed tobe used with.2 - 28

Module 2 - Concepts of Object OrientationExample: PolymorphismExample: PolymorphismfinancialInstrument.getCurrentValue()getCurrentValue()getCurrentValue()getCurrentValue()Stock Bond Mutual FundMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 29In this example, a requesting object would like to know the current value of afinancial instrument. However, the current value for each financial instrument iscalculated in a different fashion. The stock needs to determine the current askingprice in the financial market that it is listed under. The bond needs to determine thetime to maturity and interest rates. A mutual fund needs to look up the closing pricefor the day from the fund management company.In a non object-oriented development environment, we would write code that maylook something like this:IF financialInstrument = Stock THENcalcStockValue()IF financialInstrument = Bond THENcalcBondValue()IF financialInstrument = MutualFund THENcalcMutualFundValue()With object technology, each financial instrument can be represented by a class, andeach class will know how to calculate its own value. The requesting object simplyneeds to ask the specific object (for example, Stock) to get its current value. Therequesting object does not need to keep track of three different operation signatures.It only needs to know one. Polymorphism allows the same message to be handled indifferent ways, depending on the object that receives it.2 - 29

DEV475 Mastering Object-Oriented Analysis and Design with UMLWhat Is an Interface?What Is an Interface?• Interfaces formalize polymorphism• Interfaces support “plug-and-play” architecturesTubeShape+ draw()+ move()+ scale()+ rotate()PyramidCubeRealization relationship(stay tuned for realization relationships)Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 30From the UML User’s Guide (Booch, 1999): An interface is “a collection of operationsthat are used to specify a service of a class or a component.”Interfaces formalize polymorphism. They allow us to define polymorphism in adeclarative way, unrelated to implementation. Two elements are polymorphic withrespect to a set of behaviors if they realize the same interfaces. In other words, if twoobjects use the same behaviors to get different, but similar results, they areconsidered to be polymorphic. A cube and a pyramid can both be drawn, moved,scaled, and rotated, but they look very different.You have probably heard that polymorphism is one of the big benefits of objectorientation, but without interfaces there is no way to enforce it, verify it, or evenexpress it except in informal or language-specific ways. Formalization of interfacesstrips away the mystery of polymorphism and gives us a good way to describe, inprecise terms, what polymorphism is all about. Interfaces are testable, verifiable, andprecise.Interfaces are the key to the “plug-and-play” ability of an architecture: Any classifiers(for example, classes, subsystems, components) that realize the same interfaces maybe substituted for one another in the system, thereby supporting the changing ofimplementations without affecting clients.Realization relationships are discussed later in this module.2 - 30

Module 2 - Concepts of Object OrientationHow Do You Represent an Interface?How Do You Represent an Interface?Elided/IconicRepresentation(“lollipop”)TubePyramidShapeCubeCanonical(Class/Stereotype)RepresentationShape+ draw()+ move()+ scale()+ rotate()TubePyramidCubeMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 31The lollipop notation is best used when you only need to denote the existence of aninterface. If you need to see the details of the interface (for example, the operations),then the class/stereotype representation is more appropriate.From The Random House Collegiate Dictionary:• Elide: to pass over; omit; ignore.• Canonical: authorized; recognized; accepted.2 - 31

DEV475 Mastering Object-Oriented Analysis and Design with UMLWhat Is a Package?What Is a Package?• A package is a general-purpose mechanism fororganizing elements into groups.• It is a model element that can contain othermodel elements.UniversityArtifacts• A package can be used:• To organize the model under development.• As a unit of configuration management.Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 32A package can be defined as:A general purpose mechanism for organizing elements into groups. (The UnifiedModeling Language User Guide, Booch, 1999)• Models can contain hundreds and even thousands of model elements. The sheernumber of these elements can quickly become overwhelming. Therefore, it iscritical to group model elements into logical collections to maintain and easilyread the model (application of modularity and hierarchy).• Packages are a general grouping mechanism for grouping elements intosemantically related groups. A package contains classes that are needed by anumber of different packages, but are treated as a “behavioral unit.”• A package is simply a grouping mechanism. No semantics are defined for itsinstances. Thus, packages do not necessarily have a representation inimplementation, except, maybe, to represent a directory.• In the UML, a package is represented as a tabbed folder.2 - 32

Module 2 - Concepts of Object OrientationWhat Is a Subsystem?What Is a Subsystem?• A combination of a package (can contain othermodel elements) and a class (has behavior)• Realizes one or more interfaces which defineits behaviorSubsystemRealizationInterfaceSubsystemNameInterface1OO Principles: Encapsulation and ModularityMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 33(stay tuned for realization relationships)A subsystem is a model element that has the semantics of a package, such that it cancontain other model elements, and a class, such that it has behavior. (The behavior ofthe subsystem is provided by classes or other subsystems it contains.) A subsystemrealizes one or more interfaces, which define the behavior it can perform.From the UML User’s Guide (Booch, 1999): A subsystem is “a grouping of elements ofwhich some constitute a specification of the behavior offered by the other containedelements.”A subsystem may be represented as a stereotyped package.The realization relationship will be discussed later in this module.2 - 33

DEV475 Mastering Object-Oriented Analysis and Design with UMLWhat Is a Component?What Is a Component?• A non-trivial, nearly independent, andreplaceable part of a system that fulfillsa clear function in the context of a welldefinedarchitecture• A component may be• A source code componentSource FileName• A run time component• An executable componentComponentInterfaceExecutableNameComponentNameOO Principle: EncapsulationMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 34From the UML User’s Guide (Booch, 1999): A component is “a physical andreplaceable part of a system that conforms to and provides the realization of a set ofinterfaces.”Software components include:• Source code components (for example, .h, .cpp files, shell scripts, data files),• Binary code components. Examples include: Java Beans, ActiveX controls, COMobjects (DLL's and OCX's from VB), CORBA objects), and• Executable components (.exe’s).Stereotypes (with alternate icons) may be used to define these specific kinds ofcomponents.Component-based development is the creation and deployment of software-intensivesystems assembled from components. Component software development should notbe confused with object-oriented programming (OOP). OOP is a way to buildobject-based software components. Component-based development (CBD) is atechnology that allows you to combine object-based components. OOP is concernedwith creating objects, CBD is concerned with making objects work together.A component conforms to and provides the physical realization of a set of interfaces.Components are implementation things. They are the physical realization of anabstraction in your design. Interfaces were discussed earlier in this module.2 - 34

Module 2 - Concepts of Object OrientationSubsystems and ComponentsSubsystems and Components• Components are the physical realization ofan abstraction in the design• Subsystems can be used to represent thecomponent in the designDesign ModelImplementation ModelComponentInterfaceComponent NameComponentInterfaceComponentNameOO Principles: Encapsulation and ModularityMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 35A component conforms to and provides the physical realization of a set of interfaces.Components are implementation things. They are the physical realization of anabstraction in your design. A subsystem can be used to represent the component inthe design.A subsystem is the design representation of a component. They both encapsulate aset of replaceable behaviors behind one or more interfaces. Subsystems andinterfaces will be discussed later in the course.2 - 35

DEV475 Mastering Object-Oriented Analysis and Design with UMLComponents UML 1.4 and BeyondComponents UML 1.4 and Beyond• UML 1.4 introduces concept of Artifacts:• An Artifact represents a physical piece ofinformation that is used or produced by asoftware development process. Examples ofArtifacts include models, source files, scripts,and binary executable files.• To distinguish between artifacts in general,and the artifacts that make up theimplementation, we introduce a new term:• Implementation Element - the physical parts(UML artifacts) that make up animplementation, including software code files(source, binary or executable), and data files.Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 362 - 36

Module 2 - Concepts of Object OrientationComponents UML 1.4 and Beyond (cont.)Components UML 1.4 and Beyond (cont.)• Component becomes similar to subsystem:• can group classes to define a larger granularityunits of a system• can separate the visible interfaces from internalimplementation• can have instances that execute at run-time• The distinction between "component" and"artifact" is new in UML 1.4.• Many tools, profiles, and examples continue touse "component" to represent implementationelements.Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 372 - 37

DEV475 Mastering Object-Oriented Analysis and Design with UMLWhat Is an Association?What Is an Association?• The semantic relationship between two ormore classifiers that specifies connectionsamong their instances• A structural relationship, specifying that objects of onething are connected to objects of anotherStudentScheduleCourseMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 38An association can be defined as:The semantic relationship between two or more classifiers that specifies connectionsamong their instances. In other words, an association is a structural relationship thatspecifies that objects (instances of classes) are connected to other objects.• The way that we show relationships between classes is through the use ofassociations. Associations are represented on class diagrams by a line connectingthe associating classes. Data may flow in either direction or in both directionsacross a link.• Most associations are simple. That is, they exist between exactly two classes.They are drawn as solid paths connecting pairs of class symbols. Ternaryrelationships are also possible.• Sometimes, a class has an association to itself. This does not always mean that aninstance of that class has an association to itself. More often, it means that oneinstance of the class has associations to other instances of the same class.• This example shows that a student object is related to a schedule object. Thecourse class demonstrates how a course object can be related to another courseobject.2 - 38

Module 2 - Concepts of Object OrientationWhat Is Multiplicity?What Is Multiplicity?• Multiplicity is the number of instances one classrelates to ONE instance of another class.• For each association, there are two multiplicitydecisions to make, one for each end of theassociation.• For each instance of Professor, many CourseOfferings may be taught.• For each instance of Course Offering, there may beeither one or zero Professor as the instructor.Professor+ instructor0..1 0..*CourseOfferingMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 39Multiplicity can be defined as:The number of instances of one class that relate to one instance of another class.• For each role, you can specify the multiplicity of its class and how many objectsof the class can be associated with one object of the other class.• Multiplicity is indicated by a text expression on the role. The expression is acomma-separated list of integer ranges.• It is important to remember that multiplicity is referring to instances of classes(objects) and their relationships. In this example, a Course Offering object canhave either zero or one Professor object related to it. Conversely, a Professorobject can have zero or more Course Offering objects related to it.• Multiplicity must be defined on both ends of the association.2 - 39

DEV475 Mastering Object-Oriented Analysis and Design with UMLMultiplicity IndicatorsMultiplicity IndicatorsUnspecifiedExactly OneZero or MoreZero or MoreOne or MoreZero or One (optional scalar role)Specified RangeMultiple, Disjoint Ranges10..**1..*0..12..42, 4..6Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 40• Multiplicity is indicated by a text expression on the role.• The expression is a comma-separated list of integer ranges.• A range is indicated by an integer (the lower value), two dots, followed byanother integer (the upper value).• A single integer is a valid range, and the symbol “*” indicates "many.” That is, anasterisk “*” indicates an unlimited number of objects.• The symbol “*” by itself is equivalent to “0..*” That is, it represents any number,including none. This is the default value.• An optional scalar role has the multiplicity 0..1.2 - 40

Module 2 - Concepts of Object OrientationWhat Is Aggregation?What Is Aggregation?• An aggregation is a special form of associationthat models a whole-part relationship betweenan aggregate (the whole) and its parts.• An aggregation is an “Is a part-of” relationship.• Multiplicity is represented like otherassociations.WholePart10..1Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 41An aggregation can be defined as:A special form of association that models a whole-part relationship between anaggregate (the whole) and its parts.• Aggregation is used to model relationships between model elements. There aremany examples of aggregation: a library contains books, departments are madeup of employees, a computer is composed of a number of devices. To model anaggregation, the aggregate (department) has an aggregation association to the itsconstituent parts (employee).• A hollow diamond is attached to the end of an association path on the side of theaggregate (the whole) to indicate aggregation.• An aggregation relationship that has a multiplicity greater than one for theaggregate is called shared. Destroying the aggregate does not necessarily destroythe parts. By implication, a shared aggregation forms a graph or a tree with manyroots. Shared aggregations are used where there is a strong relationship betweentwo classes. Therefore, the same instance can participate in two differentaggregations.2 - 41

DEV475 Mastering Object-Oriented Analysis and Design with UMLWhat Is Navigability?What Is Navigability?• Indicates that it is possible to navigate from aassociating class to the target class using theassociationRegistrationControllerScheduleCourseOfferingMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 42• The navigability property on a role indicates that it is possible to navigate from aassociating class to the target class using the association. This may beimplemented in a number of ways: by direct object references, associative arrays,hash-tables, or any other implementation technique that allows one object toreference another.• Navigability is indicated by an open arrow placed on the target end of theassociation line next to the target class (the one being navigated to). The defaultvalue of the navigability property is true (associations are bi-directional bydefault).• In the course registration example, the association between the Schedule and theCourse Offering is navigable in both directions. That is, a Schedule must knowthe Course Offering assigned to the Schedule, and the Course Offering mustknow the Schedules it has been placed in.• When no arrowheads are shown, the association is assumed to be navigable inboth directions.• In the case of the association between Schedule and Registration Controller, theRegistration Controller must know its Schedules, but the Schedules have noknowledge of the Registration Controllers (or other classes). As a result, thenavigability property of the Registration Controller end of the association isturned off.2 - 42

Module 2 - Concepts of Object OrientationRelationships: DependencyRelationships: Dependency• A relationship between two model elementswhere a change in one may cause a change inthe other• Non-structural, “using” relationshipClassComponentClientClientDependencyrelationshipDependencyrelationshipDependencyrelationshipSupplierSupplierPackageClientPackageSupplierPackageMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 43A dependency relationship is a weaker form of relationship showing a relationshipbetween a client and a supplier where the client does not have semantic knowledgeof the supplier.A dependency relationship denotes a semantic relationship between model elements,where a change in the supplier may cause a change in the client.2 - 43

DEV475 Mastering Object-Oriented Analysis and Design with UMLWhat Is Generalization?What Is Generalization?• A relationship among classes where oneclass shares the structure and/or behaviorof one or more classes• Defines a hierarchy of abstractions in whicha subclass inherits from one or moresuperclasses• Single inheritance• Multiple inheritance• Is an “is a kind of” relationshipMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 44Generalization can be defined as:A specialization/generalization relationship in which objects of the specializedelement (the child) are substitutable for objects of the generalized element (theparent). (The Unified Modeling Language User Guide, Booch, 1999)• The subclass may be used where the superclass is used, but not vice versa.• The child inherits from the parent.• Generalization is transitive. You can always test your generalization by applyingthe “is a kind of” rule. You should always be able to say that your specializedclass “is a kind of” the parent class.• The terms “generalization” and “inheritance” are generally interchangeable. Ifyou need to distinguish, generalization is the name of the relationship, whileinheritance is the mechanism that the generalization relationshiprepresents/models.Inheritance can be defined as:The mechanism by which more-specific elements incorporate the structure andbehavior of more-general elements. (The Unified Modeling Language User Guide, Booch,1999)• Single inheritance: The subclass inherits from only one superclass (has only oneparent).• Multiple inheritance: The subclass inherits from more than one superclass (hasmultiple parents).2 - 44

Module 2 - Concepts of Object OrientationExample: Single InheritanceExample: Single Inheritance• One class inherits from anotherSuperclass(Parent)(Ancestor)Account- balance- name- number+ withdraw()+ createStatement()GeneralizationRelationshipSavingsCheckingSubclass(Child)(Descendents)Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 45• The generalization is drawn from the subclass class to the superclass/parent class.• The terms “ancestor” and “descendent” can be used instead of “superclass” and“subclass.”2 - 45

DEV475 Mastering Object-Oriented Analysis and Design with UMLExample: Multiple InheritanceExample: Multiple Inheritance• A class can inherit from several other classes.FlyingThingAnimalMultiple InheritanceAirplaneHelicopterBirdWolfHorseUse multiple inheritance only when needed andalways with caution!Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 46• Multiple inheritance means that a class can inherit from several other classes.For example, Bird inherits from both FlyingThing and Animal.• Multiple inheritance is conceptually straight forward and may be needed tomodel the real world accurately. However, there are potential implementationproblems when you use multiple inheritance, and not all implementationlanguages support it. Thus, be judicious with your use of multiple inheritance.Use it only where it accurately describes the concept you are trying to model andreduces the complexity of your model. Be aware, however, that thisrepresentation will probably need to be adjusted in design and implementation.• Generally, a class inherits from only one class.2 - 46

Module 2 - Concepts of Object OrientationWhat Gets Inherited?What Gets Inherited?• A subclass inherits its parent’s attributes,operations, and relationships• A subclass may:• Add additional attributes, operations,relationships• Redefine inherited operations (use caution!)• Common attributes, operations, and/orrelationships are shown at the highestapplicable level in the hierarchyInheritance leverages the similarities among classesMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 47Generalization is much more than just finding common attribute, operations, andrelationships. It should be more about the responsibilities and essence of the classes.2 - 47

DEV475 Mastering Object-Oriented Analysis and Design with UMLExample: What Gets InheritedExample: What Gets InheritedSuperclass(Parent)GroundVehicle+ owner0..* 1PersongeneralizationCarTruckTrailerSubclass(Child)Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 48In the above example, a truck is defined as a vehicle with tonnage and a car is avehicle with a size (for example, compact or mid-size).Specifically, attributes:• A GroundVehicle has two attributes: weight and licenseNumber• A Car has three attributes: licenseNumber, weight, and size• A Truck has three attributes: licenseNumber, weight, and tonnageOperations:• A GroundVehicle has one operation: register()• A Car has one operation: register()• A Truck has two operations: register() and getTax()Relationships:• A Car is related to a Person (the owner)• A Truck is related to a Person (the owner)• A Truck also has a Trailer and is related to a Person (the owner)2 - 48

Module 2 - Concepts of Object OrientationWhat Is Realization?What Is Realization?• One classifier serves as the contract that the otherclassifier agrees to carry out, found between:• Interfaces and the classifiers that realize themComponentInterfaceClassInterfaceSubsystemInterface• Use cases and the collaborations that realize themCollaborationUseCaseMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 49Realization is a semantic relationship between two classifiers. One classifier serves asthe contract that the other classifier agrees to carry out.The realizes relationship is a combination of a dependency and a generalization. It isnot true generalization, as only the “contract” (that is to say, operation signature) is“inherited.” This “mix” is represented in its UML form, which is a combination ofdependency and generalization.The realizes relationship may be modeled as a dashed line with a hollow arrowheadpointing at the contract classifier (canonical form), or when combined with aninterface, as a “lollipop” (elided form).Again, from The Random House Collegiate Dictionary:• Elide: to pass over; omit; ignore.• Canonical: authorized; recognized; accepted.2 - 49

DEV475 Mastering Object-Oriented Analysis and Design with UMLWhat Are Notes?What Are Notes?• A comment that can be added to include moreinformation on the diagram• May be added to any UML element• A “dog eared” rectangle• May be anchored to an element with a dashedlineMaintainScheduleFormThere can be up to oneMaintainScheduleFormper user session.Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 502 - 50

Module 2 - Concepts of Object OrientationReviewReview: Concepts of Object Orientation• What are the four basic principles of objectorientation? Provide a brief description ofeach.• What is an object and what is a class?What is the difference between the two?• What is an attribute?• What is an operation?• What is polymorphism? Whatis an interface?Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 512 - 51

DEV475 Mastering Object-Oriented Analysis and Design with UMLReview: Concepts of Object Orientation (cont.)Review: Concepts of Object Orientation (cont.)• What is a package?• What is a subsystem? How does it relate toa package? How does it relate to a class?• Name the four basic UML relationships anddescribe each.• Describe the strengths of object orientation• What are stereotypes?Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 522 - 52

► ► ► Module 3Requirements OverviewMastering Object-Oriented Analysisand Design with UMLModule 3: Requirements OverviewTopicsIntroduction ......................................................................................................... 3-3Key Concepts ....................................................................................................... 3-7Use-Case Model................................................................................................. 3-10Glossary ............................................................................................................. 3-19Supplementary Specifications ............................................................................. 3-22Review............................................................................................................... 3-313 - 1

DEV475 Mastering Object-Oriented Analysis and Design with UMLObjectives: Requirements OverviewObjectives: Requirements Overview• Describe the basic Requirements conceptsand how they affect Analysis and Design• Demonstrate how to read and interpret theartifacts of Requirements that are used as astarting point for Analysis and DesignMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 2This Requirements Overview module provides an overview of the activities thatimmediately precede Analysis and Design. It is meant to describe the interfacebetween the Requirements and the Analysis and Design discipline.This Requirements Overview module will provide enough information to give you anappreciation for the Requirements discipline, and enable you to read and interpretthe Requirements artifacts that serve as the starting point for the Analysis and Designactivities.3 - 2

Module 3 - Requirements OverviewIntroductionRequirements Overview Topics• Introduction• Key Concepts• Use-Case Model• Glossary• Supplementary Specifications• CheckpointsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 3We will start with an introduction to the Requirements discipline, followed by areview of the key concepts in use-case modeling. Then we will look briefly at each ofthe Requirements’ artifacts and discuss how to read and interpret their contents. Wewill close by reviewing a series of checklists that will assist you in assessing the qualityand completeness of the Requirements artifacts.3 - 3

DEV475 Mastering Object-Oriented Analysis and Design with UMLRequirements in ContextRequirements in ContextThe purpose of Requirements is to:• Establish and maintain agreementwith the customers and otherstakeholders on what the systemshould do.• Give system developers a betterunderstanding of the requirementsof the system.• Delimit the system.• Provide a basis for planning thetechnical contents of the iterations.• Provide a basis for estimating costand time to develop the system.• Define a user interface of thesystem.Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 4The Business Modeling discipline provides organizational context for the system. Thisis the context in which the requirements are defined and analyzed.The purpose of the Requirements discipline is:• To establish and maintain agreement with the customers and other stakeholderson what the system should do.• To provide system developers with a better understanding of the systemrequirements.• To define the boundaries of (delimit) the system.• To provide a basis for planning the technical contents of iterations.• To provide a basis for estimating cost and time to develop the system.• To define a user-interface for the system, focusing on the needs and goals of theusers.The Analysis and Design discipline gets its primary input (the Use-Case Model andthe Glossary) from Requirements. Flaws in the Use-Case Model can be discoveredduring Analysis and Design; change requests are then generated, and applied to theUse-Case Model.3 - 4

Module 3 - Requirements OverviewRelevant Requirements ArtifactsRelevant Requirements ArtifactsUse-Case ModelActorsUse CasesGlossary...Use-Case SpecificationsSupplementarySpecificationMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 5The Use-Case Model describes what the system will do. The Use-Case Model servesas a contract between the customer, the users, and the system developers. It allowscustomers and users to validate that the system will become what they expected andallows system developers to ensure that what they build is what is expected. The Use-Case Model consists of use cases and actors. Each use case in the model is describedin detail, showing step-by-step how the system interacts with the actors and what thesystem does in the use case. The Use-Case Specification is the document where all ofthe use-case properties are documented (for example, brief description and use-caseflows of events).Note: The OOAD course requirements documentation includes Use-CaseSpecifications because it is the textual description that will drive Analysis and Designactivities. (Use-case specifications only include the textual use-case properties.)The Glossary defines a common terminology for all models and contains textualdescriptions of the required system.The Supplementary Specification contains those requirements that do not map to aspecific use case (for example, nonfunctional requirements). The SupplementarySpecification is an important complement to the Use-Case Model. Together theycapture all requirements (functional and nonfunctional) that need to be described fora complete System Requirements Specification.3 - 5

DEV475 Mastering Object-Oriented Analysis and Design with UMLCase Study: Course Registration Problem StatementCase Study: Course Registration Problem Statement• Review the problem statement provided inthe Course Registration RequirementsDocument.Course RegistrationRequirements DocumentMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 6Before we discuss the details of the artifacts that drive the Analysis and Designdiscipline, it is important that you understand the problem domain that all of thecourse exercises will be based on.With regards to the formal Requirements artifacts, the Problem Statement is part ofthe Vision document. The other sections have been omitted for scoping reasons. Formore information on the Vision document, see the Requirements discipline of theRational Unified Process.3 - 6

Module 3 - Requirements OverviewKey ConceptsRequirements Overview Topics• Introduction• Key Concepts• Use-Case Model• Glossary• Supplementary Specifications• CheckpointsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 7In this section, we will discuss the key concepts of use-case modeling — the actorand the use case, as well as what relationships can exist between them. We will alsolook at the artifacts that make up the Use-Case Model: Use-Case Specifications, andactivity diagrams.3 - 7

DEV475 Mastering Object-Oriented Analysis and Design with UMLWhat Is System Behavior?What Is System Behavior?• System behavior is how a system acts andreacts.• It is the outwardly visible and testable activity ofa system.• System behavior is captured in use cases.• Use cases describe the system, itsenvironment, and the relationship between thesystem and its environment.Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 8• No system exists in isolation. Every system interacts with people or automatedsystems for some purpose. These interactions result in some sort of predictableresult. This predictable result is system behavior.• Use cases are the mechanism for capturing the desired behavior for the systemthat is under development, but they do not specify how the behavior is to beimplemented.• The UML specifies a model for communicating system behavior — the Use-CaseModel.3 - 8

Module 3 - Requirements OverviewMajor Concepts in Use-Case ModelingMajor Concepts in Use-Case Modeling• An actor represents anything that interacts withthe system.Actor• A use case is a sequence of actions a systemperforms that yields an observable result ofvalue to a particular actor.UseCaseMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 9An actor represents a coherent set of roles that users of the system play wheninteracting with these use cases. Typically, an actor represents a role that a human, ahardware device, or even another system plays with a system.A use case is a sequence of actions a system performs to yield an observable resultthat is of value to a particular actor. A use case describes what a system does, but itdoes not specify how it does it.3 - 9

DEV475 Mastering Object-Oriented Analysis and Design with UMLUse-Case ModelRequirements Overview Topics• Introduction• Key Concepts• Use-Case Model• Glossary• Supplementary Specifications• CheckpointsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 103 - 10

Module 3 - Requirements OverviewWhat Is a Use-Case Model?What Is a Use-Case Model?• A model that describes a system’s functionalrequirements in terms of use cases• A model of the system’s intended functionality(use cases) and its environment (actors)View Report CardRegister for CoursesStudentLoginMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 11• A Use-Case Model describes a system’s functional requirements in terms of usecases. It is a model of the system's intended functionality and its environment.The Use-Case Model serves as a contract between the customer and thedevelopers. Because it is a very powerful planning instrument, the Use-CaseModel is generally used in all phases of the development cycle.• When the customer approves the Use-Case Model, you know the system is whatthe customer wants. You can also use the model to discuss the system with thecustomer during development.• Potential users use the Use-Case Model to better understand the system.• Designers use it as a basis for their work and to get a system overview.• Testers use it to plan testing activities (use case and integration testing) as early aspossible.• Those developing the next version of the system use it to understand how theexisting version works.• Documentation writers use the use cases as a basis for writing the system userguides.• The architect uses the Use-Case Model to identify architecturally significantfunctionality.• The manager uses it to plan and follow up on use-case modeling and subsequentdesign.3 - 11

DEV475 Mastering Object-Oriented Analysis and Design with UMLWhat Are the Benefits of a Use-Case Model?What Are the Benefits of a Use-Case Model?• Communication• Identification• VerificationCommunicationUse CaseVerificationIdentificationEnd UserDomain ExpertUsersMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 12There are many ways to model a system, each of which may serve a differentpurpose. However, the most important role of a Use-Case Model is to communicatethe system's behavior to the customer or end user. Consequently, the model must beeasy to understand.Communication with the end users and domain experts:• Provides buy-in at an early stage of system development.• Ensures a mutual understanding of the requirements.Identification of system users and what the system should do:• Establishes the requirements for the system interfaces.Verification that all requirements have been captured:• Ensures that the development team understands the requirements.The Use-Case Model is also used to identify the actors that interact with the system.Because they represent system users, actors help delimit the system and give a clearerpicture of what it is supposed to do. Use cases are developed on the basis of theactors' needs, ensuring that the system will turn out to be what the users expected.3 - 12

Module 3 - Requirements OverviewHow Would You Read This Diagram?How Would You Read This Diagram?View Report CardRegister for CoursesCourse CatalogMaintain ProfessorInformationStudentLoginSelect Courses toTeachRegistrarMaintain StudentInformationClose RegistrationProfessorSubmit GradesBilling SystemMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 13Answer the following questions:1. Which use cases will a student be able to perform? A professor? The CourseCatalog?2. If Charlie is a student and professor, which use cases will he be able to execute?3. Describe the functionality of this system.4. Describe the actor relationships for the Close Registration and Select Courses ToTeach use cases.5. What doesn’t this model say?6. Which use case needs to run first — Register for Courses or View Report Card?3 - 13

DEV475 Mastering Object-Oriented Analysis and Design with UMLUse-Case SpecificationsUse-Case Specifications• Name• Brief description• Flow of Events• Relationships• Activity diagrams• Use-Case diagrams• Specialrequirements• Pre-conditions• Post-conditions• Other diagramsUse-Case ModelActorsUse Cases...Use-Case SpecificationsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 14The use case has a set of properties as shown in the graphic. The use-case propertiesmay be documented in use-case specifications, which can include the items listedbelow:• Brief description describes the role and purpose of the use case.• Flow of events are textual descriptions of what the system does with regard tothe use case. There can be multiple flows of events — for example, a basic flowand alternative flows.• Relationships are communicates-associations. The use case includes and extendsrelationships that the use case participates in.• Activity diagrams can be used to illustrate the structure of the flow of events.• Use-case diagrams can be used to show the relationships involving the use case.• Special requirements is a textual description that collects all use-caserequirements, like nonfunctional requirements, that are not considered in theUse-Case Model, yet need to be taken care of during design or implementation.• Pre-conditions define a constraint on the system regarding when the use casemay start.• Post-conditions define a constraint on the system that applies after the use casehas terminated.• Other diagrams can be used to illustrate the use case, like hand-drawn sketchesor screen captures from an user-interface prototype.3 - 14

Module 3 - Requirements OverviewUse-Case Flow of EventsUse-Case Flow of Events• Has one normal, basic flow• Several alternative flows• Regular variants• Odd cases• Exceptional flows for handling error situationsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 15A use case flow of events:• Contains the most important information derived from use-case modeling work.• Should describe the use case's flow clearly enough for an outsider to easilyunderstand it.• Should present what the system does, not how the system is designed to performthe required behavior.Guidelines for the flow of events. Specify that the content must:• Detail the flow of events. All "what“ questions should be answered. Rememberthat test designers will use this text to identify test cases.• Describe how the use case starts and ends.• Describe the flow of events, not only the functionality. To reinforce this, startevery action with "When the actor. . . .”• Describe only the events that belong to the use case and not what happens inother use cases or outside of the system.• Describe the data exchanged between the actor and the use case.• Avoid describing the details of the user interface unless they are needed toprovide an understanding the behavior of the system.• Avoid vague terminology such as "for example", "etc.," and "information."3 - 15

DEV475 Mastering Object-Oriented Analysis and Design with UMLWhat Is a Scenario?What Is a Scenario?• A scenario is an instance of a use case.Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 16A scenario is an instance of a use case. It is one flow through a use case.Each use case has a web of flow of events with a scenario being an instance of aparticular flow of events. The scenario may involve the basic flow and any number ofalternative flows in any number of combinations.In the example, the bold lines highlight some possible scenarios for the basic andalternative flows previously described.How many scenarios are needed?As many as one needs to understand the system being developed. You mustelaborate the scenarios of the interesting and high-risk use cases. Scenarios can beused to understand, as well as to validate, the use-case flows of events. Some peoplewrite scenarios first and extract use cases, while others find use cases first and validatethose use cases by writing scenarios.Scenarios make excellent test cases.3 - 16

Module 3 - Requirements OverviewWhat Is an Activity Diagram?What Is an Activity Diagram?• An activity diagram in the Use-Case Model can be used tocapture the activities in a use case.• It is essentially a flow chart, showing flow of control fromactivity to activity.Flow of EventsThis use case starts when the Registrar requests that thesystem close registration.1. The system checks to see if registration is in progress. If itis, then a message is displayed to the Registrar and the usecase terminates. The Close Registration processing cannotbe performed if registration is in progress.2. For each course offering, the system checks if a professorhas signed up to teach the course offering and at least threestudents have registered. If so, the system commits thecourse offering for each schedule that contains it.Activity1Activity2Activity3Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 17• The workflow of a use case describes what needs to be done by the system toprovide the value that the served actor is looking for.• It consists of a sequence of activities that, together, produce something for theactor.• The workflow often consists of a basic flow and one or several alternative flows.• The structure of the workflow can be described graphically with the help of anactivity diagram.3 - 17

DEV475 Mastering Object-Oriented Analysis and Design with UMLExample: Activity DiagramExample: Activity DiagramConcurrentThreadsGuardConditionCheckScheduleSelect Course[ add course ]Decision[ delete course ]CheckPre-requisites[ checks completed ] [ checks failed ]Delete CourseActivityStateSynchronizationBar (Fork)SynchronizationBar (Join)Assign toCourseResolveConflictsTransitionUpdateScheduleMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 18An activity diagram may include the following elements:• Activity states represent the performance of an activity or step within theworkflow.• Transitions show what activity state follows after another.• Decisions evaluate conditions defined by guard conditions. These guardconditions determine which of the alternative transitions will be made and, thus,which activities are performed. You may also use the decision icon to showwhere the threads merge again. Decisions and guard conditions allow you toshow alternative threads in the workflow of a use case.• Synchronization bars show parallel sub-flows. They allow you to showconcurrent threads in the workflow of a use case.3 - 18

Module 3 - Requirements OverviewGlossaryRequirements Overview Topics• Introduction• Key Concepts• Use-Case Model• Glossary• Supplementary Specifications• CheckpointsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 193 - 19

DEV475 Mastering Object-Oriented Analysis and Design with UMLGlossaryGlossaryGlossaryCourse Registration System Glossary1. IntroductionThis document is used to define terminology specific to the problemdomain, explaining terms, which may be unfamiliar to the reader of theuse-case descriptions or other project documents. Often, this documentcan be used as an informal data dictionary, capturing data definitions sothat use-case descriptions and other project documents can focus onwhat the system must do with the information.2. DefinitionsThe glossary contains the working definitions for the key concepts in theCourse Registration System.2.1 Course: A class offered by the university.2.2 Course Offering: A specific delivery of the course for a specificsemester – you could run the same course in parallel sessions in thesemester. Includes the days of the week and times it is offered.2.3 Course Catalog: The unabridged catalog of all courses offered bythe university.Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 20The Glossary defines important terms used in the project.There is one Glossary for the system. This document is important to many developers,especially when they need to understand and use the terms that are specific to theproject. The Glossary is used to facilitate communications between domain expertsand developers.The Glossary is developed primarily during the Inception and Elaboration phases,because it is important to agree on a common terminology early in the project. InInception and Elaboration, it is used by domain experts (for example, businessanalysts) to explain all the domain-specific terminology used in their use cases. InElaboration and Construction, developers use the Glossary to explain technical termsused in the other four models.A system analyst is responsible for the integrity of the Glossary, ensuring that it isproduced in a timely manner and is continuously kept consistent with the results ofdevelopment.The above is just a sample outline for the Glossary. Not all of these elements need tobe in it. A project needs to establish the template to be used on that particularproject.Introduction: Provides a brief description of the Glossary and its purpose.Terms: Define the term in as much detail as necessary to completely andunambiguously characterize it.3 - 20

Module 3 - Requirements OverviewCase Study: GlossaryCase Study: Glossary• Review the Glossaryprovided in the CourseRegistrationRequirements DocumentGlossaryMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 21The idea is not to go over the Glossary in vivid detail, but to demonstrate how to readit, where to look for information you will need during the Analysis and Designactivities, as well as how to detect if it is insufficient.3 - 21

DEV475 Mastering Object-Oriented Analysis and Design with UMLSupplementary SpecificationsRequirements Overview Topics• Introduction• Key Concepts• Use-Case Model• Glossary• Supplementary Specifications• CheckpointsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 223 - 22

Module 3 - Requirements OverviewSupplementary SpecificationSupplementary Specification• Functionality• Usability• Reliability• Performance• Supportability• Design constraintsSupplementarySpecificationMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 23The nonfunctional requirements and functional requirements not captured by the usecases are included in the Supplementary Specifications. The SupplementarySpecifications include constraints on the implementation.Functionality: List of the functional requirements that are general to many use cases.Usability: Requirements that relate to, or affect, the usability of the system. Examplesinclude ease-of-use requirements or training requirements that specify how readilythe system can be used by its actors.Reliability: Any requirements concerning the reliability of the system. Quantitativemeasures such as mean time between failure or defects per thousand lines of codeshould be stated.Performance: The performance characteristics of the system. Include specificresponse times. Reference related use cases by name.Supportability: Any requirements that will enhance the supportability ormaintainability of the system being built.Design Constraints: Any design constraints on the system being built.Supplementary Specifications go hand-in-hand with the Use-Case Model, implyingthat:• They are initially considered in the Inception phase as a complement to definingthe scope of the system.• They are refined in an incremental fashion during the Elaboration andConstruction phases.3 - 23

DEV475 Mastering Object-Oriented Analysis and Design with UMLExample: Supplementary SpecificationExample: Supplementary Specification• Review theSupplementarySpecification providedin the CourseRegistrationRequirementsDocument.CourseRegistrationRequirementsDocumentSupplementarySpecificationMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 24The idea is not to go over the Supplementary Specification in vivid detail, but todemonstrate how to read it, where to look for information you will need during theAnalysis and Design activities, as well as how to detect if it is insufficient.3 - 24

Module 3 - Requirements OverviewRequirements Overview TopicsRequirements Overview Topics• Introduction• Key Concepts• Use-Case Model• Glossary• Supplementary Specifications• CheckpointsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 253 - 25

DEV475 Mastering Object-Oriented Analysis and Design with UMLCheckpoints: Requirements: Use-Case ModelCheckpoints: Requirements: Use-Case Model• Is the Use-Case Modelunderstandable?• By studying the Use-Case Model,can you form a clear idea of thesystem's functions and how they arerelated?• Have all functional requirementsbeen met?• Does the Use-Case Model containany superfluous behavior?• Is the division of the model into usecasepackages appropriate?Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 26The above, as well as the remaining checklists in this section, is a sample of the kindsof things to look for when reviewing the Use-Case Model. Explicit, detailed checklistsshould be established for the project to support the review of the Use-Case Model.Verify that there are no open questions. The use cases you found must be able toperform all system behaviors; if not, some use cases are missing. If you intentionallyleft any requirements to be dealt with in the object models, such as nonfunctionalrequirements, you must mention this. Put the reference in the SupplementarySpecification(s) unless the requirement concerns a specific use case, in which casestate it in the Special Requirements section of the use case.The Use-Case Model should not present more functions than were called for in therequirements.Traceability from the original requirements to the use cases and the SupplementarySpecification is critical for project management and impact assessment as well as tomake sure nothing has been missed.The packaging should make the Use-Case Model simple and intuitive to understandand maintain.3 - 26

Module 3 - Requirements OverviewCheckpoints: Requirements: ActorsCheckpoints: Requirements: Actors• Have all the actors been identified?• Is each actor involved with at leastone use case?• Is each actor really a role? Shouldany be merged or split?• Do two actors play the same role inrelation to a use case?• Do the actors have intuitive anddescriptive names? Can both usersand customers understand thenames?Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 27Make sure that all the roles in the system's environment have been accounted for andmodeled. You will not be able to do this fully until you have found and described allthe use cases.Remove any actors not mentioned in the use-case descriptions or that have nocommunicates-associations with a use case. However, an actor mentioned in a usecasedescription is likely to have a communicates-association with that particular usecase.You should be able to name at least two people who would be able to perform as aparticular actor. If not, see if the role the actor models is part of another role. If so,you should merge the actors.If any actors play similar roles in relation to the system, they should be merged into asingle actor. If a particular actor will use the system in several completely differentways, or has several completely different purposes for using the use case, then thereshould probably be more than one actor.If two actors play the same role in relation to a use case, then actor-generalizationsshould be used to model their shared behavior.It is important that actor names correspond to their roles.3 - 27

DEV475 Mastering Object-Oriented Analysis and Design with UMLCheckpoints: Requirements: Use-CasesCheckpoints: Requirements: Use-Cases• Is each use case involved with atleast one actor?• Is each use case independent of theothers?• Do any use cases have very similarbehaviors or flows of events?• Do the use cases have unique,intuitive, and explanatory names sothat they cannot be mixed up at alater stage?• Do customers and users alikeunderstand the names anddescriptions of the use cases?Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 28A use case that does not interact with an actor is superfluous. You should remove it.If two use cases are always activated in the same sequence, you should probablymerge them into one use case.Use cases that have very similar behaviors or flows of events, or will be similar in thefuture, should be merged into a single use case. This makes it easier to introducefuture changes.Note: You must involve the users if you decide to merge use cases because the users,who interact with the new, merged use case will probably be affected.If some part of the flow of events is already part of another use case, the sub-flowshould be extracted and then be used by all of the use cases in question.Note: You must involve the users if you decide to "reuse" the sub-flow, because theusers of the existing use case will probably be affected.Each use-case name must describe the behavior the use case supports. The namesand descriptions must be understood by the users and customers.3 - 28

Module 3 - Requirements OverviewCheckpoints: Requirements: Use-Case SpecificationsCheckpoints: Requirements: Use-Case Specifications• Is it clear who wants to perform a usecase?• Is the purpose of the use case alsoclear?• Does the brief description give a truepicture of the use case?• Is it clear how and when the usecase's flow of events starts and ends?• Does the communication sequencebetween actor and use case conformto the user's expectations?• Are the actor interactions andexchanged information clear?• Are any use cases overly complex?Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 29Include any (nonfunctional) requirements to be handled in the object models in theuse-case Special Requirements.Behavior might exist that is activated only when a certain condition is not met. Thereshould be a description of what will happen in such a case.If you want your Use-Case Model to be easy to understand, you might have to splitup complex use cases. A use case that contains disparate flows of events will be verydifficult to understand and to maintain. It is best to divide such use cases into two ormore separate ones.3 - 29

DEV475 Mastering Object-Oriented Analysis and Design with UMLCheckpoints: Requirements: GlossaryCheckpoints: Requirements: Glossary• Does each term have a clear andconcise definition?• Is each glossary term includedsomewhere in the use-casedescriptions?• Are terms used consistently inthe brief descriptions of actorsand use cases?Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 30If each Glossary term is not included somewhere in the use-case descriptions, thatmay imply that a use case is missing or that the existing use cases are not complete. Itis more likely, though, that the term is not included because it is not needed, and itshould be removed from the Glossary.A term should represent the same thing in all use-case descriptions.3 - 30

Module 3 - Requirements OverviewReviewReview: Requirements Overview• What are the main artifacts of Requirements?• What are the Requirements artifacts used for?• What is a Use-Case Model?• What is an actor?• What is a use case? List examples of use caseproperties.• What is the difference between a use case and ascenario?• What is a Supplementary Specificationand what does it include?• What is a Glossary and what doesit include?Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 313 - 31

DEV475 Mastering Object-Oriented Analysis and Design with UMLExercise: Requirements OverviewExercise: Requirements Overview• Given the following Requirements artifacts:• Problem statement• Use-Case Model main diagram• Supplementary specification• Glossary• Review the given Requirements artifacts,noting any questions, issues,inconsistencies.Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 32These artifacts will be used as the basis for the remainder of the examples andexercises in this course, so you need to have a good foundation for moving forward.All questions, issues, etc. regarding the Requirements artifacts will be recorded andaddressed here.You will not be reviewing the use-case flow of events at this point. They will bereviewed in detail later in the course.The Requirements artifacts for this exercise can be found in the Payroll RequirementsDocument. See the document’s table of contents for specific page numbers.3 - 32

► ► ► Module 4Analysis and Design OverviewMastering Object-Oriented Analysisand Design with UMLModule 4: Analysis and Design OverviewTopicsKey Concepts ....................................................................................................... 4-5Analysis and Design Workflow............................................................................ 4-114 - 1

DEV475 Mastering Object-Oriented Analysis and Design with UMLObjectives: Analysis and Design OverviewObjectives: Analysis and Design Overview• Review the key Analysis and Design termsand concepts• Introduce the Analysis and Design process,including roles, artifacts and workflow• Explain the difference between Analysisand DesignMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 2This Analysis and Design Overview module provides an overview of the Analysis andDesign Discipline. It also defines the terms that span all Analysis and Design activities.The details of each of the Analysis and Design activities will be described insubsequent modules. This module is meant to provide context for these detailedAnalysis and Design activity modules.4 - 2

Module 4 - Analysis and Design OverviewAnalysis and Design in ContextAnalysis and Design in ContextThe purposes of Analysis and Designare to:• Transform the requirements into adesign of the system-to-be.• Evolve a robust architecture for thesystem.• Adapt the design to match theimplementation environment,designing it for performance.Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 3The purposes of Analysis and Design are to:• Transform the requirements into a system design.• Evolve a robust architecture for the system.• Adapt the design to match the implementation environment, designing it forperformance.The Analysis and Design Discipline is related to other process disciplines.• The Business Modeling Discipline provides an organizational context for thesystem.• The Requirements Discipline provides the primary input for Analysis and Design.• The Test Discipline tests the system designed during Analysis and Design.• The Environment Discipline develops and maintains the supporting artifacts thatare used during Analysis and Design.• The Management Discipline plans the project and each iteration (described inan Iteration Plan).4 - 3

DEV475 Mastering Object-Oriented Analysis and Design with UMLAnalysis and Design OverviewAnalysis and Design OverviewUse-Case ModelAnalysisand DesignDesign ModelGlossarySupplementarySpecificationArchitectureDocumentData ModelMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 4The input artifacts are the Use-Case Model, Glossary, and SupplementarySpecification from the Requirements Discipline. The result of Analysis and Design isa Design Model that serves as an abstraction of the source code; that is, the DesignModel acts as a blueprint of how the source code is structured and written. TheDesign Model consists of design classes structured into design packages; it alsocontains descriptions of how objects of these design classes collaborate to performuse cases (use-case realizations).The design activities are centered around the notion of architecture. The productionand validation of this architecture is the main focus of early design iterations.Architecture is represented by a number of architectural views that capture the majorstructural design decisions. In essence, architectural views are abstractions orsimplifications of the entire design, in which important characteristics are made morevisible by leaving details aside. The architecture is an important vehicle not only fordeveloping a good Design Model, but also for increasing the quality of any modelbuilt during system development. The architecture is documented in the ArchitectureDocument.The development of the Architecture Document is out of the scope of this course, butwe will discuss it is contents and how to interpret them.4 - 4

Module 4 - Analysis and Design OverviewKey ConceptsAnalysis & Design Overview Topics• Key Concepts• Analysis and Design WorkflowMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 5We will start out by defining some key terms and concepts needed to describe theAnalysis and Design workflow. These terms will be explained in more detail, alongwith other important terms and concepts in later modules of the course.Once we have a common vocabulary, then we will walk through the Analysis andDesign workflow.4 - 5

DEV475 Mastering Object-Oriented Analysis and Design with UMLAnalysis Versus DesignAnalysis Versus Design• Analysis• Focus onunderstanding theproblem• Idealized design• Behavior• System structure• Functionalrequirements• A small model• Design• Focus onunderstanding thesolution• Operations andattributes• Performance• Close to real code• Object lifecycles• Nonfunctionalrequirements• A large modelMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 6The differences between Analysis and Design are ones of focus and emphasis. Theabove slide lists the things that you focus on in Analysis versus Design.The goal in Analysis is to understand the problem and to begin to develop a visualmodel of what you are trying to build, independent of implementation andtechnology concerns. Analysis focuses on translating the functional requirements intosoftware concepts. The idea is to get a rough cut at the objects that comprise oursystem, but focusing on behavior (and therefore encapsulation). We then move veryquickly, nearly seamlessly, into “Design” and the other concerns.A goal of Design is to refine the model with the intention of developing a DesignModel that will allow a seamless transition to the coding phase. In design, we adaptto the implementation and the deployment environment. The implementationenvironment is the “developer” environment, which is a software superset and ahardware subset of the deployment environmentIn modeling, we start with an Object Model that closely resembles the real world(Analysis), and then find more abstract (but more fundamental) solutions to a moregeneralized problem (Design). The real power of software design is that it can createmore powerful metaphors for the real world that change the nature of the problem,making it easier to solve.4 - 6

Module 4 - Analysis and Design OverviewAnalysis and Design Are Not Top-Down or Bottom-UpAnalysis and Design Are Not Top-Down or Bottom-UpAnalysis and DesignTopDownSubsystemsBottomUpUse Cases(Define amiddle level)Analysis ClassesDesign ClassesMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 7The Analysis and Design Discipline is not top-down or bottom-up.The use case comes in from the left and defines a middle level.The analysis classes are not defined in a top-down pattern or a bottom-up pattern;they are in the middle. From this middle level one may move up or down.Defining subsystems is moving up and defining design classes is moving down.Analysis is both top-to-middle, middle-up, middle-down and bottom-to-middle.There is no way of saying that one path is more important than another — you haveto travel on all paths to get the system right.All of these four paths are equally important. That is why the bottom-up and topdownquestion cannot be solved.4 - 7

DEV475 Mastering Object-Oriented Analysis and Design with UMLWhat Is Architecture?What Is Architecture?• Software architecture encompasses a set ofsignificant decisions about the organizationof a software system.• Selection of the structural elements and theirinterfaces by which a system is composed• Behavior as specified in collaborations amongthose elements• Composition of these structural and behavioralelements into larger subsystems• Architectural style that guides this organizationGrady Booch, Philippe Kruchten, Rich Reitman, Kurt Bittner; Rational(derived from Mary Shaw)Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 8Based on extensive research, Rational has established a definition of architecture.“Significant” in this context implies strategic, of major impact.The architecture has a static and a dynamic perspective.The architecture for similar systems should be similar (a particular style is used).An equation we have used is:Architecture = Elements + Form + Rationale.Rationale is essential for justifying a good architecture.Patterns are the guidelines for assembling elements in some form. We will discusspatterns in the architecture modules.4 - 8

Module 4 - Analysis and Design OverviewArchitecture Constrains Design and ImplementationArchitecture Constrains Design and Implementation• Architecture involves a set of strategicdesign decisions, rules or patterns thatconstrain design and construction.CodeImplementationDesignArchitectureArchitecture decisions are the most fundamentaldecisions, and changing them will have significant effects.Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 9Architectures can be viewed as a set of key design decisions.The architecture is the initial set of constraints placed on the system. Such constraintsare the the most important ones. They constitute the fundamental decisions aboutthe software design. Architecture puts a framework around the design. Architecturehas been called strategic design.An architect’s job is to eliminate unnecessary creativity. As you move closer to code,creativity is eliminated. (The architecture constrains the design which constrains theimplementation.) This is good because during Implementation, the creativity can bespent elsewhere (for example, for improving the quality, and performance) of theimplementation (for example, code).4 - 9

DEV475 Mastering Object-Oriented Analysis and Design with UMLSoftware Architecture: The “4+1 View” ModelSoftware Architecture: The “4+1 View” ModelLogical ViewImplementation ViewAnalysts/DesignersStructureEnd-userFunctionalityUse-Case ViewProgrammersSoftware managementSystem integratorsPerformanceScalabilityThroughputProcess ViewDeployment ViewSystem engineeringSystem topologyDelivery, installationcommunicationMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 10The above diagram shows the model Rational uses to describe the softwarearchitecture.Architecture is many things to many different interested parties. On a particularproject, there are usually multiple stakeholders, each with their own concerns andview of the system to be developed. The goal is to provide each of these stakeholderswith a view of the system that addresses their concerns, and suppresses the otherdetails.To address these different needs, Rational has defined the “4+1 view” architecturemodel. An architectural view is a simplified description (an abstraction) of a systemfrom a particular perspective or vantage point, covering particular concerns, andomitting entities that are not relevant to this perspective. Views are “slices” of models.Not all systems require all views (for example, single processor: drop DeploymentView; single process: drop Process View; small program: drop Implementation View,and so forth). A project may document all of these views or additional views. Thenumber of views is dependent on the system you are building.Each of these views, and the UML notation used to represent them, will be discussedin subsequent modules.4 - 10

Module 4 - Analysis and Design OverviewAnalysis and Design WorkflowAnalysis & Design Overview Topics• Key Concepts• Analysis and Design WorkflowMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 11Because we have a common vocabulary, we can now briefly discuss the activities ofAnalysis and Design and how they work together.4 - 11

DEV475 Mastering Object-Oriented Analysis and Design with UMLAnalysis and Design WorkflowAnalysis and Design Workflow[EarlyElaborationIteration][InceptionIteration (Optional)]AnalysisDefine a CandidateArchitecturePerformArchitecturalSynthesisAnalyze BehaviorDesignRefine theArchitectureDefineComponents(Optional)Design theDatabaseMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 12A mere enumeration of all workers, activities, and artifacts does not constitute aprocess. We need a way to describe the activities, some valuable result, andinteractions between workers. A workflow is a sequence of activities that produces aresult of observable value.In UML terms, a workflow can be expressed as a sequence diagram, a collaborationdiagram, or an activity diagram. We use a form of activity diagram in the RationalUnified Process. For each core workflow, an activity diagram is presented. Thisdiagram shows the workflow, expressed in terms of workflow details.This slide shows the Analysis and Design workflow. The early Elaboration Phasefocuses on creating an initial architecture for the system (Define a CandidateArchitecture) to provide a starting point for the main analysis work. If the architecturealready exists (because it was produced in previous iterations, or projects, or isobtained from an application framework), the focus of the work changes to refiningthe architecture (Refine the Architecture) analyzing behavior, and creating an initialset of elements that provide the appropriate behavior (Analyze Behavior).After the initial elements are identified, they are further refined. Design Componentsand Design Real-Time Components produce a set of components that provide theappropriate behavior to satisfy the requirements on the system. In parallel with theseactivities, persistence issues are handled in Design the Database. The result is aninitial set of components that are further refined in the Implementation Discipline.4 - 12

Module 4 - Analysis and Design OverviewAnalysis and Design Activity OverviewAnalysis and Design Activity OverviewArchitectDesignerMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 13Remember, for Analysis and Design, we start out with the Use-Case Model and thesupplementary specifications from the Requirements Discipline and end up with theDesign Model that serves as an abstraction of the source code.The design activities are centered around the notion of architecture. The productionand validation of this architecture are the main focal points of early design iterations.The architecture is an important vehicle not only for developing a good DesignModel, but also for increasing the quality of any model built during systemdevelopment.The focus of this course is on the activities of the designer. The architect activities arediscussed, but many of the architectural decisions will be given. Each of the architectand designer activities will be addressed in individual course modules.4 - 13

DEV475 Mastering Object-Oriented Analysis and Design with UMLSoftware Architect’s ResponsibilitiesSoftware Architect’s Responsibilities• TheSoftwareArchitectleads andcoordinatestechnicalactivitiesand artifacts.ArchitectAnalysis ModelDesign ModelDeployment ModelReferenceArchitectureSoftwareArchitectureDocumentMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 14The software architect role leads and coordinates technical activities and artifactsthroughout the project. The software architect establishes the overall structure foreach architectural view: the decomposition of the view, the grouping of elements,and the interfaces between these major groupings. Therefore, in contrast to the otherroles, the software architect's view is one of breadth as opposed to one of depth.In summary, the software architect must be well-rounded and possess maturity,vision, and a depth of experience that allows for grasping issues quickly and makingeducated, critical judgment in the absence of complete information. Morespecifically, the software architect, or members of the architecture team, mustcombine these skills:• Experience in both the problem domain, through a thorough understanding ofthe requirements, and the software engineering domain. If there is a team, thesequalities can be spread among the team members, but at least one softwarearchitect must provide the global vision for the project.• Leadership in order to drive the technical effort across the various teams, and tomake critical decisions under pressure and make those decisions stick. To beeffective, the software architect and the project manager must work closelytogether, with the software architect leading the technical issues and the projectmanager leading the administrative issues. The software architect must have theauthority to make technical decisions.• Communication to earn trust, to persuade, to motivate, and to mentor. Thesoftware architect cannot lead by decree — only by the consent of the rest of theproject. In order to be effective, the software architect must earn the respect ofthe project team, the project manager, the customer, and the user community, aswell as the management team.• Goal orientation and being proactive with a relentless focus on results. Thesoftware architect is the technical driving force behind the project, not a visionaryor dreamer. The career of a successful software architect is a long series of suboptimaldecisions made in uncertainty and under pressure. Only those who canfocus on doing what needs to be done are successful in this environment of theproject.4 - 14

Module 4 - Analysis and Design OverviewDesigner’s ResponsibilitiesDesigner’s Responsibilities• The designermust knowuse-casemodelingtechniques,systemrequirements,and softwaredesigntechniques.Use-CaseRealizationPackage/SubsystemDesignerClassMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 15The designer role defines the responsibilities, operations, attributes, and relationshipsof one or several classes, and determines how they are adjusted to theimplementation environment. In addition, the designer role may have responsibilityfor one or more design packages, or design subsystems, including any classes ownedby the packages or subsystems.The designer must have a solid working knowledge of:• Use-case modeling techniques• System requirements• Software design techniques, including object-oriented Analysis and Designtechniques, and the Unified Modeling Language• Technologies with which the system will be implementedIn addition, the designer must:• Understand the architecture of the system, as represented in the SoftwareArchitecture Document.4 - 15

DEV475 Mastering Object-Oriented Analysis and Design with UMLReview: Analysis and Design Is Use-Case DrivenReview: Analysis and Design Is Use-Case Driven• Use cases defined for a system are thebasis for the entire development process.• Benefits of use cases:• Concise, simple, and understandable by a wide rangeof stakeholders.• Help synchronize the content of different models.Check BalanceCustomerWithdraw MoneyMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 16Use cases are one recommended method for organizing your requirements. Insteadof a bulleted list of requirements, you organize them in a way that tells how someonemay use the system. By doing so, you make a requirement more complete andconsistent. You can also better understand the importance of a requirement from auser’s perspective.It is often difficult to tell how a system does what it is supposed to do from atraditional object-oriented system model. This stems from the lack of a commonthread through the system when it performs certain tasks. Use cases are that thread,because they define the behavior performed by a system.Use cases are not part of "traditional" object orientation, but their importance hasbecome more and more apparent, further emphasizing the fact that use cases arepart of the UML.4 - 16

Module 4 - Analysis and Design OverviewWhat Is a Use-Case Realization?What Is a Use-Case Realization?Use-Case ModelDesign ModelUse CaseUse-Case RealizationSequence DiagramsCollaboration DiagramsUse CaseClass DiagramsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 17A use-case realization describes how a particular use case is realized within theDesign Model, in terms of collaborating objects. A use-case realization ties togetherthe use cases from the Use-Case Model with the classes and relationships of theDesign Model. A use-case realization specifies what classes must be built toimplement each use case.In the UML, use-case realizations are stereotyped collaborations. The symbol for acollaboration is an ellipsis containing the name of the collaboration.The symbol for ause-case realization is a dotted line version of the collaboration symbol.A use-case realization in the Design Model can be traced to a use case in the Use-Case Model. A realization relationship is drawn from the use-case realization to theuse case it realizes.Within the UML, a use-case realization can be represented using a set of diagramsthat model the context of the collaboration (the classes/objects that implement theuse case and their relationships — class diagrams), and the interactions of thecollaborations (how these classes/objects interact to perform the use cases —collaboration and sequence diagrams).The number and types of the diagrams that are used depend on what is needed toprovide a complete picture of the collaboration and the guidelines developed for theproject under development.4 - 17

DEV475 Mastering Object-Oriented Analysis and Design with UMLAnalysis and Design in an Iterative ProcessAnalysis and Design in an Iterative ProcessStart ofiterationUse Case AScenarios 1 & 2Use Case BScenario 1Use Case AScenario 3Use-CaseRealization AEnd ofiterationUse-CaseRealization AIteration n Iteration n + 1Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 18Use-CaseRealization BThis course assumes the developer is using an iterative process. Remember, eachpass through the sequence of process workflows is called an iteration. Thus, from adevelopment perspective, the software lifecycle is a succession of iterations, throughwhich the software develops incrementally.During the Analysis and Design workflow in an iteration a use case will serve as theprimary input artifact. By going through the a series of activities defined in theAnalysis and Design workflow, the development team will create an associated usecaserealization that describes how a particular use case will be realized.4 - 18

Module 4 - Analysis and Design OverviewReview: Analysis and Design OverviewReview: Analysis and Design Overview• What is the purpose of the Analysis andDesign Discipline?• What are the input and output artifacts?• Name and briefly describe the 4+1 Views ofArchitecture.• What is the difference between Analysisand Design?• What is architecture?Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 194 - 19

DEV475 Mastering Object-Oriented Analysis and Design with UML4 - 20

► ► ► Module 5Architectural AnalysisMastering Object-Oriented Analysisand Design with UMLModule 5: Architectural AnalysisTopicsArchitectural Analysis Overview............................................................................ 5-4Key Concepts ....................................................................................................... 5-5Define the high-level Organization of Subsystems ............................................... 5-10Identify Analysis Mechanisms.............................................................................. 5-19Identify Key Abstractions .................................................................................... 5-28Create Use-Case Realizations ............................................................................. 5-32Review............................................................................................................... 5-385 - 1

DEV475 Mastering Object-Oriented Analysis and Design with UMLObjectives: Architectural AnalysisObjectives: Architectural Analysis• Explain the purpose of Architectural Analysisand where it is performed in the lifecycle.• Describe a representative architectural patternand set of analysis mechanisms, and how theyaffect the architecture.• Describe the rationale and considerations thatsupport the architectural decisions.• Show how to read and interpret the results ofArchitectural Analysis:• Architectural layers and their relationships• Key abstractions• Analysis mechanismsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 2A focus on software architecture allows you to articulate the structure of the softwaresystem (the packages/components), and the ways in which they integrate (thefundamental mechanisms and patterns by which they interact).Architectural Analysis is where we make an initial attempt at defining thepieces/parts of the system and their relationships, organizing these pieces/parts intowell-defined layers with explicit dependencies, concentrating on the upper layers ofthe system. This will be refined, and the lower layers will be defined duringIncorporate Existing Design Elements.5 - 2

Module 5 - Architectural AnalysisArchitectural Analysis in ContextArchitectural Analysis in Context[EarlyElaborationIteration][InceptionIteration (Optional)]ArchitectureAnalysisArchitectDefine a CandidateArchitecturePerformArchitecturalSynthesisAnalyze BehaviorRefine theArchitecture(Optional)DefineComponentsDesign theDatabaseMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 3As you may recall, the above diagram illustrates the workflow that we are using in thiscourse. It is a tailored version of the Analysis and Design core workflow of theRational Unified Process. Architectural Analysis is an activity in the Define aCandidate Architecture workflow detail.Architectural Analysis is how the project team (or the architect) decides to definethe project’s high-level architecture. It is focused mostly on bounding the analysiseffort in terms of agreed-upon architectural patterns and idioms, so that the “analysis”work is not working so much from “first principles.” Architectural Analysis is verymuch a configuring of Use-Case Analysis.During Architectural Analysis, we concentrate on the upper layers of the system,making an initial attempt at defining the pieces/parts of the system and theirrelationships and organizing these pieces/parts into well-defined layers with explicitdependencies.In Use-Case Analysis, we will expand on this architecture by identifying analysisclasses from the requirements. Then, in Incorporate Existing Design Elements, theinitial architecture is refined, and the lower architecture layers are defined, takinginto account the implementation environment and any other implementationconstraints.Architectural Analysis is usually done once per project, early in the Elaborationphase. The activity is performed by the software architect or architecture team.This activity can be skipped if the architectural risk is low.5 - 3

DEV475 Mastering Object-Oriented Analysis and Design with UMLArchitectural Analysis OverviewArchitectural Analysis OverviewSupplementarySpecificationGlossarySoftwareArchitecture DocReferenceArchitectureVisionDocumentArchitecturalAnalysisProject-SpecificGuidelinesDesign ModelUse-Case ModelDeployment ModelMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 4Purpose:• To define a candidate architecture for the system based on experience gainedfrom similar systems or in similar problem domains.• To define the architectural patterns, key mechanisms, and modeling conventionsfor the system.• To define the reuse strategy.• To provide input to the planning process.Input Artifacts:• Use-Case Model• Supplementary Specifications• Glossary• Design Model• Reference Architecture• Vision Document• Project Specific Guidelines• Software Architecture DocumentResulting Artifacts:• Software Architecture Document• Design Model• Deployment Model5 - 4

Module 5 - Architectural AnalysisKey ConceptsArchitectural Analysis Steps• Key Concepts• Define the High-Level Organization ofSubsystems• Identify Analysis mechanisms• Identify Key Abstractions• Create Use-Case Realizations• CheckpointsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 5The above are the topics we will be discussing within the Architectural Analysismodule. Unlike the designer activity modules, you will not be discussing each step ofthe activity, as the objective of this module is to understand the importantArchitectural Analysis concepts, not to learn HOW to create an architecture.Before you discuss Architectural Analysis in any detail, it is important toreview/define some key concepts.5 - 5

DEV475 Mastering Object-Oriented Analysis and Design with UMLReview: What Is Architecture: The “4+1 View” ModelReview: What Is Architecture: The “4+1 View” ModelLogical ViewImplementation ViewAnalysts/DesignersStructureEnd-userFunctionalityUse-Case ViewProgrammersSoftware managementSystem integratorsPerformanceScalabilityThroughputProcess ViewDeployment ViewSystem engineeringSystem topologyDelivery, installationcommunicationMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 6The above diagram describes the model Rational uses to describe the softwarearchitecture. This is the recommended way to represent a software architecture.There may be other “precursor” architectures that are not in this format. The goal isto mature those architectural representations into the 4+1 view representation.In Architectural Analysis, you will concentrate on the Logical View. The other viewswill be addressed in later architecture modules:• The Logical View will be refined in the Identify Design Mechanisms, IdentifyDesign modules.• The Process View will be discussed in the Describe Run-time Architecturemodule.• The Deployment View will be discussed in the Describe Distribution module.• The Implementation View is developed during Implementation and is thusconsidered out of scope for this Analysis and Design course.5 - 6

Module 5 - Architectural AnalysisReview: What Is a Package?Review: What Is a Package?• A package is a general-purpose mechanismfor organizing elements into groups.• It is a model element that can contain othermodel elements.UniversityArtifacts• A package can be used• To organize the model under development.• As a unit of configuration management.Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 7Packages were first introduced in the Introduction to Object Orientation module.The slide is repeated here for review purposes.Packages can be used to group any model elements. However, in this module, wewill be concentrating on how they are used within the Design Model.5 - 7

DEV475 Mastering Object-Oriented Analysis and Design with UMLPackage Relationships: DependencyPackage Relationships: Dependency• Packages can be related to one another using adependency relationship.Client PackageDependency relationshipSupplierPackage• Dependency Implications• Changes to the Supplier package may affect theClient package.• The Client package cannot be reused independentlybecause it depends on the Supplier package.Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 8Elements in one package can import elements from another package. In the UML,this is represented as a dependency relationship.The relationships of the packages reflect the allowable relationships between thecontained classes. A dependency relationship between packages indicates that thecontents of the supplier packages may be referenced by the client. In the aboveexample, if a dependency relationship exists between the Client package and theSupplier package, then classes in the Client package may access classes in theSupplier package.Some of the implications of package dependency are:• Whenever a change is made to the Supplier package, the Client package must,potentially, be recompiled and re-tested.• The Client package cannot be reused independently because it depends on theSupplier package.The grouping of classes into logical sets and the modeling of their relationships canoccur anywhere in the process when a set of cohesive classes is identified.5 - 8

Module 5 - Architectural AnalysisAvoiding Circular DependenciesAvoiding Circular DependenciesAAABHierarchyshould beacyclicBBCCCircular dependencies make it impossibleto reuse one package without the other.Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 9A'It is desirable that the package hierarchy be acyclic. This means that the followingsituation should be avoided (if possible):• Package A uses package B, which uses package A.If a circular dependency exists between Package A and Package B, if you changePackage A it might cause a change in Package B, which might cause a change inPackage A, etc. A circular dependency between packages A and B means that theywill effectively have to be treated as a single package.Circles wider than two packages must also be avoided. For example, package A usespackage B, which uses package C, which uses package A.Circular dependencies may be able to be broken by splitting one of the packages intotwo smaller ones. In the above example, the elements in package A that wereneeded by the other packages were factored out into their own package, A’, and theappropriate dependencies were added.5 - 9

DEV475 Mastering Object-Oriented Analysis and Design with UMLDefine the High-Level Organization of SubsystemsArchitectural Analysis Steps• Key Concepts• Define the High-Level Organization ofSubsystems• Identify Analysis mechanisms• Identify Key Abstractions• Create Use-Case Realizations• CheckpointsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 10Early in the software development lifecycle, it is important to define the modelingconventions that everyone on the project should use. The modeling conventionsensure that the representation of the architecture and design are consistent acrossteams and iterations.5 - 10

Module 5 - Architectural AnalysisPatterns and FrameworksPatterns and Frameworks• Pattern• Provides a common solution to a common problemin a context• Analysis/Design pattern• Provides a solution to a narrowly-scoped technicalproblem• Provides a fragment of a solution, or a piece of thepuzzle• Framework• Defines the general approach to solving theproblem• Provides a skeletal solution, whosedetails may be Analysis/Design patternsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 11The selection of the upper-level layers may be affected by the choice of anarchitectural pattern or framework. Thus, it is important to define what these termsmean.A pattern codifies specific knowledge collected from experience. Patterns provideexamples of how good modeling solves real problems, whether you come up with thepattern yourself or you reuse someone else’s. Design patterns are discussed in moredetail on the next slide.Frameworks differ from Analysis and Design patterns in their scale and scope.Frameworks describe a skeletal solution to a particular problem that may lack manyof the details, and that may be filled in by applying various Analysis and Designpatterns.A framework is a micro-architecture that provides an incomplete template forapplications within a specific domain. Architectural frameworks provide the contextin which the components run. They provide the infrastructure (plumbing, if you will)that allows the components to co-exist and perform in predictable ways. Theseframeworks may provide communication mechanisms, distribution mechanisms,error processing capabilities, transaction support, and so forth.Frameworks may range in scope from persistence frameworks that describe theworkings of a fairly complex but fragmentary part of an application to domain-specificframeworks that are intended to be customized (such as Peoplesoft, SanFransisco,Infinity, and SAP). For example, SAP is a framework for manufacturing and finance.5 - 11

DEV475 Mastering Object-Oriented Analysis and Design with UMLWhat Is a Design Pattern?What Is a Design Pattern?• A design pattern is a solution to a commondesign problem.• Describes a common design problem• Describes the solution to the problem• Discusses the results and trade-offs of applying thepattern• Design patterns provide the capability to reusesuccessful designs.TemplateParametersPattern NameParameterizedCollaborationStructural AspectBehavioral AspectMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 12We will look at a number of design patterns throughout this course. Thus, it isimportant to define what a design pattern is up front.Design patterns are being collected and cataloged in a number of publications andmediums.You can use design patterns to solve issues in your design without“reinventing the wheel.” You can also use design patterns to validate and verify yourcurrent approaches.Using design patterns can lead to more maintainable systems and increasedproductivity.They provide excellent examples of good design heuristics and designvocabulary. In order to use design patterns effectively, you should become familiarwith some common design patterns and the issues that they mitigate.A design pattern is modeled in the UML as a parameterized collaboration.Thus it hasa structural aspect and a behavioral aspect. The structural part is the classes whoseinstances implement the pattern, and their relationships (the static view).Thebehavioral aspect describes how the instance collaborate — usually by sendingmessages to each other — to implement the pattern (the dynamic view).A parameterized collaboration is a template for a collaboration.The TemplateParameters are used to adapt the collaboration for a specific usage.These parametersmay be bound to different sets of abstractions, depending on how they are applied inthe design.5 - 12

Module 5 - Architectural AnalysisWhat Is an Architectural Pattern?What Is an Architectural Pattern?• An architectural pattern expresses a fundamentalstructural organization schema for softwaresystems. It provides a set of predefinedsubsystems, specifies their responsibilities, andincludes rules and guidelines for organizing therelationships between them – Buschman et al,“Pattern-Oriented Software Architecture — A System ofPatterns”• Layers• Model-view-controller (M-V-C)• Pipes and filters• BlackboardMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 13Architectural Analysis is where you consider architectural patterns, as this choiceaffects the high-level organization of your object model.Layers: The layers pattern is where an application is decomposed into different levelsof abstraction. The layers range from application-specific layers at the top toimplementation/technology-specific layers on the bottom.Model-View-Controller: The MVC pattern is where an application is divided intothree partitions: The Model, which is the business rules and underlying data, theView, which is how information is displayed to the user, and the Controllers, whichprocess the user input.Pipes and Filters: In the Pipes and Filters pattern, data is processed in streams thatflow through pipes from filter to filter. Each filter is a processing step.Blackboard: The Blackboard pattern is where independent specialized applicationscollaborate to derive a solution, working on a common data structure.Architectural patterns can work together. (That is, more than one architectural patterncan be present in any one software architecture.)The architectural patterns listed above imply certain system characteristics,performance characteristics, and process and distribution architectures. Each solvescertain problems but also poses unique challenges. For this course, you willconcentrate on the Layers architectural pattern.5 - 13

DEV475 Mastering Object-Oriented Analysis and Design with UMLTypical Layering ApproachTypical Layering ApproachSpecificfunctionalityApplication SubsystemsDistinct application subsystems that makeup an application — contains the valueadding software developed by theorganization.Business-SpecificMiddlewareSystem SoftwareBusiness specific — contains a number ofreusable subsystems specific to the type ofbusiness.Middleware — offers subsystems for utilityclasses and platform-independent servicesfor distributed object computing inheterogeneous environments and so on.System software — contains the softwarefor the actual infrastructure such asoperating systems, interfaces to specifichardware, device drivers, and so on.GeneralfunctionalityMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 14Layering represents an ordered grouping of functionality, with the application-specificfunctions located in the upper layers, functionality that spans application domains inthe middle layers, and functionality specific to the deployment environment at thelower layers.The number and composition of layers is dependent upon the complexity of both theproblem domain and the solution space:• There is generally only a single application-specific layer.• In domains with existing systems, or that have large systems composed of interoperatingsmaller systems, the Business-Specific layer is likely to partially existand may be structured into several layers for clarity.• Solution spaces, which are well-supported by middleware products and in whichcomplex system software plays a greater role, have well-developed lower layers,with perhaps several layers of middleware and system software.This slide shows a sample architecture with four layers:• The top layer, Application layer, contains the application-specific services.• The next layer, Business-Specific layer, contains business-specific componentsused in several applications.• The Middleware layer contains components such as GUI-builders, interfaces todatabase management systems, platform-independent operating system services,and OLE-components such as spreadsheets and diagram editors.• The bottom layer, System Software layer, contains components such asoperating systems, databases, interfaces to specific hardware, and so on.5 - 14

Module 5 - Architectural AnalysisArchitectural Pattern: LayersArchitectural Pattern: LayersEquipment andcustomer-specificcodeProcesses and otherapplication code54ApplicationMajor abstractions,classes, etc.Mechanisms,servicesH/W specific code, O/Sspecific code, generalpurposecode (forexample, ORB, MQS)321InfrastructureApplicationFrameworkMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 15ContextA large system that requires decomposition.ProblemA system that must handle issues at different levels of abstraction; for example:hardware control issues, common services issues, and domain-specific issues. Itwould be extremely undesirable to write vertical components that handle issues at alllevels. The same issue would have to be handled (possibly inconsistently) multipletimes in different components.Forces• Parts of the system should be replaceable.• Changes in components should not ripple.• Similar responsibilities should be grouped together.• Size of components — complex components may have to be decomposed.SolutionStructure the systems into groups of components that form layers on top of eachother. Make upper layers use services of the layers below only (never above). Try notto use services other than those of the layer directly below. (Do not skip layers unlessintermediate layers would only add pass-through components.)A strict layered architecture states that design elements (classes, components,packages, and subsystems) only utilize the services of the layer below them. Servicescan include event-handling, error-handling, database access, and so forth. It containsmore palpable mechanisms, as opposed to the raw operating system level callsdocumented in the bottom layer.5 - 15

DEV475 Mastering Object-Oriented Analysis and Design with UMLLayering ConsiderationsLayering Considerations• Level of abstraction• Group elements at the same level of abstraction• Separation of concerns• Group like things together• Separate disparate things• Application vs. domain model elements• Resiliency• Loose coupling• Concentrate on encapsulating change• User interface, business rules, and retained data tendto have a high potential for changeMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 16Layers are used to encapsulate conceptual boundaries between different kinds ofservices and provide useful abstractions that make the design easier to understand.When layering, concentrate on grouping things that are similar together, as well asencapsulating change.There is generally only a single Applicationlayer. On the other hand, the number ofdomain layers is dependent upon the complexity of both the problem and thesolution spaces.When a domain has existing systems, complex systems composed of inter-operatingsystems, and/or systems where there is a strong need to share information betweendesign teams, the Business-Specific layer may be structured into several layers forclarity.In Architectural Analysis, we are concentrating on the upper-level layers (theApplication and Business-Specific layers). The lower level layers (infrastructure andvendor-specific layers) will be defined in Incorporate Existing Design Elements.5 - 16

Module 5 - Architectural AnalysisModeling Architectural LayersModeling Architectural Layers• Architectural layers can be modeled usingstereotyped packages.• stereotypePackage NameMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 17Layers can be represented in Rose as packages with the stereotype. Thelayer descriptions can be included in the documentation field of the specification ofthe package.5 - 17

DEV475 Mastering Object-Oriented Analysis and Design with UMLExample: High-Level Organization of the ModelExample: High-Level Organization of the ModelApplicationBusiness ServicesMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 18The above example includes the Application and Business-Specific layers for theCourse Registration System.The Application layer contains the design elements that are specific to the CourseRegistration application.We expect that multiple applications will share some key abstractions and commonservices. These have been encapsulated in the Business Services layer, which isaccessible to the Application layer. The Business Services layer contains businessspecificelements that are used in several applications, not necessarily just this one.5 - 18

Module 5 - Architectural AnalysisIdentify Analysis MechanismsArchitectural Analysis Steps• Key Concepts• Define the High-Level Organization ofSubsystems• Identify Analysis mechanisms• Identify Key Abstractions• Create Use-Case Realizations• CheckpointsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 19The architecture should be simple, but not simplistic. It should provide standardbehavior through standard abstractions and mechanisms. Thus, a key aspect indesigning a software architecture is the definition and the selection of themechanisms that designers use to give "life" to their objects.In Architectural Analysis, it is important to identify the analysis mechanisms for thesoftware system being developed. Analysis mechanisms focus on and address thenonfunctional requirements of the system (that is, the need for persistence, reliability,and performance), and builds support for such non-functional requirements directlyinto the architecture.Analysis mechanisms are used during analysis to reduce the complexity of analysis,and to improve its consistency by providing designers with a shorthand representationfor complex behavior. Mechanisms allow the analysis effort to focus on translating thefunctional requirements into software abstractions without becoming bogged down inthe specification of relatively complex behavior that is needed to support thefunctionality but which is not central to it.5 - 19

DEV475 Mastering Object-Oriented Analysis and Design with UMLWhat Are Architectural Mechanisms?What Are Architectural Mechanisms?RequiredFunctionalityImplementationEnvironmentSupplementarySpecification“realized by clientclasses using”Mechanisms“constrained by”COTS ProductsDatabasesIPC Technologyetc.“responsible for”Use-Case ModelArchitectMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 20In order to better understand what an analysis mechanism is, we have to understandwhat an architectural mechanism is.An architectural mechanism is a strategic decision regarding common standards,policies, and practices. It is the realization of topics that should be standardized on aproject. Everyone on the project should utilize these concepts in the same way, andreuse the same mechanisms to perform the operations.An architectural mechanism represents a common solution to a frequentlyencountered problem. It may be patterns of structure, patterns of behavior, or both.Architectural mechanisms are an important part of the "glue" between the requiredfunctionality of the system and how this functionality is realized, given the constraintsof the implementation environment.Support for architectural mechanisms needs to be built in to the architecture.Architectural mechanisms are coordinated by the architect. The architect choosesthe mechanisms, validates them by building or integrating them, verifies that they dothe job, and then consistently imposes them upon the rest of the design of thesystem.5 - 20

Module 5 - Architectural AnalysisArchitectural Mechanisms: Three CategoriesArchitectural Mechanisms: Three Categories• Architectural Mechanism Categories• Analysis mechanisms (conceptual)• Design mechanisms (concrete)• Implementation mechanisms (actual)Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 21There are three categories of architectural mechanisms. The only difference betweenthem is one of refinement.Analysis mechanisms capture the key aspects of a solution in a way that isimplementation-independent. They either provide specific behaviors to a domainrelatedclass or component, or correspond to the implementation of cooperationbetween classes and/or components. They may be implemented as a framework.Examples include mechanisms to handle persistence, inter-process communication,error or fault handling, notification, and messaging, to name a few.Design mechanisms are more concrete. They assume some details of theimplementation environment, but are not tied to a specific implementation (as is animplementation mechanism).Implementation mechanisms specify the exact implementation of the mechanism.Implementation mechanisms are are bound to a certain technology, implementationlanguage, vendor, or other factor.In a design mechanism, some specific technology is chosen (for example, RDBMS vs.ODBMS), whereas in an implementation mechanism, a VERY specific technology ischosen (for example, Oracle vs. SYBASE).The overall strategy for the implementation of analysis mechanisms must be built intothe architecture. This will be discussed in more detail in Identify Design mechanisms,when design and implementation mechanisms are discussed.5 - 21

DEV475 Mastering Object-Oriented Analysis and Design with UMLWhy Use Analysis Mechanisms?Why Use Analysis Mechanisms?Oh no! I found a group of classes thathas persistent data. How am Isupposed to design these things if Idon’t even know what database we aregoing to be using?That is why we have a persistenceanalysis mechanism. We don’tknow enough yet, so we canbookmark it and come back to itlater.Analysis mechanisms are used during analysis to reduce the complexity ofanalysis and to improve its consistency by providing designers with ashorthand representation for complex behavior.Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 22An analysis mechanism represents a pattern that constitutes a common solution to acommon problem. These mechanisms may show patterns of structure, patterns ofbehavior, or both. They are used during analysis to reduce the complexity of theanalysis, and to improve its consistency by providing designers with a shorthandrepresentation for complex behavior. Analysis mechanisms are primarily used as“placeholders” for complex technology in the middle and lower layers of thearchitecture. When mechanisms are used as “placeholders” in the architecture, thearchitecting effort is less likely to become distracted by the details of mechanismbehavior.Mechanisms allow the analysis effort to focus on translating the functionalrequirements into software concepts without bogging down in the specification ofrelatively complex behavior needed to support the functionality but which is notcentral to it. Analysis mechanisms often result from the instantiation of one or morearchitectural or analysis patterns.Persistence provides an example of analysis mechanisms. A persistent object is onethat logically exists beyond the scope of the program that created it. The need tohave object lifetimes that span use cases, process lifetimes, or system shutdown andstartup, defines the need for object persistence. Persistence is a particularly complexmechanism. During analysis we do not want to be distracted by the details of how weare going to achieve persistence. This gives rise to a “persistence” analysis mechanismthat allows us to speak of persistent objects and capture the requirements we willhave on the persistence mechanism without worrying about what exactly thepersistence mechanism will do or how it will work.Analysis mechanisms are typically, but not necessarily, unrelated to the problemdomain, but instead are "computer science" concepts. As a result, they typicallyoccupy the middle and lower layers of the architecture. They provide specificbehaviors to a domain-related class or component, or correspond to theimplementation of cooperation between classes and/or components.5 - 22

Module 5 - Architectural AnalysisSample Analysis MechanismsSample Analysis Mechanisms• Persistency• Communication (IPC and RPC)• Message routing• Distribution• Transaction management• Process control and synchronization (resourcecontention)• Information exchange, format conversion• Security• Error detection / handling / reporting• Redundancy• Legacy InterfaceMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 23Analysis mechanisms either provide specific behaviors to a domain-related class orcomponent, or they correspond to the implementation of cooperation betweenclasses and/or components.Some examples of analysis mechanisms are listed on this slide. This list is not meantto be exhaustive.Examples of communication mechanisms include inter-process communication (IPC)and inter-node communication (a.k.a. remote process communication or RPC). RPChas both a communication and a distribution aspect.Mechanisms are perhaps easier to discuss when one talks about them as “patterns”that are applied to the problem. So the inter-process communication pattern (that is,“the application is partitioned into a number of communicating processes”) interactswith the distribution pattern (that is, “the application is distributed across a number ofnodes”) to produce the RPC pattern (that is, “the application is partitioned into anumber of processes, which are distributed across a number of nodes”). This processprovides us a way to implement remote IPC.5 - 23

DEV475 Mastering Object-Oriented Analysis and Design with UMLExamples of Analysis Mechanism CharacteristicsExamples of Analysis Mechanism Characteristics• Persistency mechanism• Granularity• Volume• Duration• Access mechanism• Access frequency (creation/deletion, update, read)• Reliability• Inter-process Communication mechanism• Latency• Synchronicity• Message size• ProtocolMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 24Analysis mechanism characteristics capture some nonfunctional requirements of thesystem.Persistency: For all classes whose instances may become persistent, we need toidentify:• Granularity: Range of size of the persistent objects• Volume: Number of objects to keep persistent• Duration: How long to keep persistent objects• Access mechanism: How is a given object uniquely identified and retrieved?• Access frequency: Are the objects more or less constant; are they permanentlyupdated?• Reliability: Shall the objects survive a crash of the process, the processor; thewhole system?Inter-process Communication: For all model elements that need to communicatewith objects, components, or services executing in other processes or threads, weneed to identify:• Latency: How fast must processes communicate with another?• Synchronicity: Asynchronous communication• Size of message: A spectrum might be more appropriate than a single number.• Protocol, flow control, buffering, and so on.5 - 24

Module 5 - Architectural AnalysisExample of Analysis Mechanism Characteristics (cont.)Example of Analysis Mechanism Characteristics (cont.)• Legacy interface mechanism• Latency• Duration• Access mechanism• Access frequency• Security mechanism• Data granularity• User granularity• Security rules• Privilege types• OthersMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 25Security:• Data granularity: Package-level, class-level, attribute level• User granularity: Single users, roles/groups• Security Rules: Based on value of data, on algorithm based on data, and onalgorithm based on user and data• Privilege Types: Read, write, create, delete, perform some other operation5 - 25

DEV475 Mastering Object-Oriented Analysis and Design with UMLDescribing Analysis MechanismsDescribing Analysis Mechanisms• Collect all analysismechanisms in a list• Draw a map of classesto analysis mechanisms• Identify characteristicsof analysis mechanisms• Model usingcollaborationsClassesFlightAircraftMissionScheduleRouteLoadAnalysisMechanismsPersistencyCommunicationParsingAuthenticationMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 26The process for describing analysis mechanisms is:1. Collect all analysis mechanisms in a list. The same analysis mechanism mayappear under several different names across different use-case realizations, oracross different designers. For example, storage, persistency, database, andrepository might all refer to a persistency mechanism. Inter-processcommunication, message passing, or remote invocation might all refer to aninter-process communication mechanism.2. Draw a map of the client classes to the analysis mechanisms (see graphic onslide).3. Identify Characteristics of the analysis mechanisms. To discriminate across arange of potential designs, identify the key characteristics used to qualify eachanalysis mechanism. These characteristics are part functionality, part size, andperformance.4. Model Using Collaborations. Once all of the analysis mechanisms are identifiedand named, they should be modeled through the collaboration of a “society ofclasses.” Some these classes do not directly deliver application functionality, butexist only to support it. Very often, these “support classes” are located in themiddle or lower layers of a layered architecture, thus providing a commonsupport service to all application-level classes.5 - 26

Module 5 - Architectural AnalysisExample: Course Registration Analysis MechanismsExample: Course Registration Analysis Mechanisms• Persistence• Distribution• Security• Legacy InterfaceMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 27The above are the selected analysis mechanisms for the Course Registration System.Persistency: A means to make an element persistent (that is, exist after theapplication that created it ceases to exist).Distribution: A means to distribute an element across existing nodes of the system.Security: A means to control access to an element.Legacy Interface: A means to access a legacy system with an existing interface.These are also documented in the Payroll Architecture Handbook, ArchitecturalMechanisms section.5 - 27

DEV475 Mastering Object-Oriented Analysis and Design with UMLIdentify Key AbstractionsArchitectural Analysis Steps• Key Concepts• Define the High-Level Organization ofSubsystems• Identify Analysis mechanisms• Identify Key Abstractions• Create Use-Case Realizations• CheckpointsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 28This is where the key abstractions for the problem domain are defined. Furthermore,this is where the “vocabulary” of the software system is established.The purpose of this step is to "prime the pump" for analysis by identifying anddefining the key abstractions that the system must handle. These may have beeninitially identified during business modeling and requirement activities. However,during those activities, the focus was on the problem domain. During analysis anddesign, our focus is more on the solution domain.5 - 28

Module 5 - Architectural AnalysisWhat Are Key Abstractions?What Are Key Abstractions?• A key abstraction is a concept, normallyuncovered in Requirements, that thesystem must be able to handle• Sources for key abstractions• Domain knowledge• Requirements• Glossary• Domain Model, or the BusinessModel (if one exists)Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 29Requirements and Business Modeling activities usually uncover key concepts that thesystem must be able to handle. These concepts manifest themselves as key designabstractions. Because of the work already done, there is no need to repeat theidentification work again during Use-Case Analysis. To take advantage of existingknowledge, we identify preliminary entity analysis classes to represent these keyabstractions on the basis of general knowledge of the system. Sources include theRequirements, the Glossary, and in particular, the Domain Model, or the BusinessObject Model, if you have one.5 - 29

DEV475 Mastering Object-Oriented Analysis and Design with UMLDefining Key AbstractionsDefining Key Abstractions• Define analysis class relationships• Model analysis classes and relationshipson class diagrams• Include brief description ofanalysis class• Map analysis classes tonecessary analysismechanismsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 30While defining the initial analysis classes, you can also define any relationships thatexist between them. The relationships are those that support the basic definitions ofthe abstractions. It is not the objective to develop a complete class model at thispoint, but just to define some key abstractions and basic relationships to “kick off” theanalysis effort. This will help to reduce any duplicate effort that may result whendifferent teams analyze the individual use cases.Relationships defined at this point reflect the semantic connections between thedefined abstractions, not the relationships necessary to support the implementationor the required communication among abstractions.The analysis classes identified at this point will probably change and evolve during thecourse of the project. The purpose of this step is not to identify a set of classes thatwill survive throughout design, but to identify the key abstractions the system musthandle. Do not spend much time describing analysis classes in detail at this initialstage, because there is a risk that you might identify classes and relationships that arenot actually needed by the use cases. Remember that you will find more analysisclasses and relationships when looking at the use cases.5 - 30

Module 5 - Architectural AnalysisExample: Key AbstractionsExample: Key AbstractionsProfessorStudentScheduleCourseCatalogCourseOfferingCourseMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 31Professor: A person teaching classes at the university.Student: A person enrolled in classes at the university.Schedule: The courses a student has enrolled in for a semester.CourseCatalog: Unabridged catalog of all courses offered by the university.CourseOffering: A specific offering for a course, including days of the week andtimes.Course: A class offered by the university.5 - 31

DEV475 Mastering Object-Oriented Analysis and Design with UMLCreate Use-Case RealizationsArchitectural Analysis Steps• Key Concepts• Define the High-Level Organization ofSubsystems• Identify Analysis mechanisms• Identify Key Abstractions• Create Use-Case Realizations• CheckpointsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 32A use-case realization represents the design perspective of a use case. It is anorganization model element used to group a number of artifacts related to the usecasedesign. Use cases are separate from use-case realizations, so you can manageeach individually and change the design of the use case without affecting the baselineuse case. For each use case in the Use-Case Model, there is a use-case realization inthe design model with a dependency (stereotyped «realize») to the use case.5 - 32

Module 5 - Architectural AnalysisReview: What is a Use-Case Realization?Review: What is a Use-Case Realization?Use-Case ModelDesign ModelUse CaseUse-Case RealizationSequence DiagramsCollaboration DiagramsUse CaseClass DiagramsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 33A use-case realization is the expression of a particular use case within the DesignModel. It describes the use case in terms of collaborating objects. A use-caserealization ties together the use cases from the Use-Case Model with the classes andrelationships of the Design Model. A use-case realization specifies what classes mustbe built to implement each use case.In the UML, use-case realizations are stereotyped collaborations. The symbol for acollaboration is an oval containing the name of the collaboration. The symbol for ause-case realization is a “dotted line” version of the collaboration symbol.A use-case realization in the Design Model can be traced to a use case in the Use-Case Model. A realization relationship is drawn from the use-case realization to theuse case it realizes.Within the UML, a use-case realization can be represented using a set of diagramsthat model the context of the collaboration (the classes/objects that implement theuse case and their relationships — class diagrams), and the interactions of thecollaborations (how these classes/objects interact to perform the use cases —collaboration and sequence diagrams).The number and types of the diagrams that are used depend on what is needed toprovide a complete picture of the collaboration and the guidelines developed for theproject under development.5 - 33

DEV475 Mastering Object-Oriented Analysis and Design with UMLThe Value of Use-Case RealizationsThe Value of Use-Case Realizations• Provides traceability from Analysis and Designback to Requirements• The Architect creates the Use-Case RealizationRequirementsAnalysis & DesignUse CaseUse-CaseRealizationMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 34Use cases form the central focus of most of the early analysis and design work. Toenable the transition between requirements-centric activities and design-centricactivities, the use-case realization serves as a bridge, providing a way to tracebehavior in the Design Model back to the Use-Case Model, as well as organizingcollaborations in the Design Model around the Use-Case concept.For each Use Case in the Use Case Model, create a use-case realization in the DesignModel. The name for the use-case realization should be the same as the associateduse case, and a trace dependency should be established from the use case realizationto its associated use case.5 - 34

Module 5 - Architectural AnalysisArchitectural Analysis StepsArchitectural Analysis Steps• Key Concepts• Define the High-Level Organization ofSubsystems• Identify Analysis mechanisms• Identify Key Abstractions• Create Use-Case Realizations• CheckpointsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 35This is where the quality of the architecture modeled up to this point is assessedagainst some very specific criteria.In this module, we will concentrate on those checkpoints that the designer is mostconcerned with (that is, looks for). The architect should do a much more detailedreview of the Architectural Analysis results and correct any problems before theproject moves on to the next activity. We will not cover those checkpoints, as theyare out of scope of this course. (Remember, this is not an architecture course.)5 - 35

DEV475 Mastering Object-Oriented Analysis and Design with UMLCheckpointsCheckpoints• General• Is the package partitioning andlayering done in a logicallyconsistent way?• Have the necessary analysismechanisms been identified?• Packages• Have we provided a comprehensivepicture of the services of thepackages in upper-level layers?(continued)Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 36The next few slides contains the key things a designer would look for when assessingthe results of Architectural Analysis. An architect would have a more detailed list.A well-structured architecture encompasses a set of classes, typically organized intomultiple hierarchiesNote: At this point, some of the packages/layers may not contain any classes, and thatis okay. More classes will be identified over time, starting in the next activity, Use-Case Analysis.5 - 36

Module 5 - Architectural AnalysisCheckpoints (cont.)Checkpoints (cont.)• Classes• Have the key entity classes andtheir relationships been identifiedand accurately modeled?• Does the name of each class clearlyreflect the role it plays?• Are the key abstractions/classesand their relationships consistentwith the Business Model, DomainModel, Requirements, Glossary,etc.?Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 37A well-structured class provides a crisp abstraction of something drawn from thevocabulary of the problem domain or the solution domain.5 - 37

DEV475 Mastering Object-Oriented Analysis and Design with UMLReviewReview: Architectural Analysis• What is the purpose of Architectural Analysis?• What is a package?• What are analysis mechanisms? Give examples.• What key abstractions are identified duringArchitectural Analysis? Why are they identifiedhere?• What is a layered architecture? Give examples oftypical layers.Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 385 - 38

Module 5 - Architectural AnalysisExercise: Architectural AnalysisExercise: Architectural Analysis• Given the following:• Some results from the Requirementsdiscipline:• Problem statement• Use-Case Model main diagram• Glossary• Some architectural decisions:• (textually) The upper-levelarchitectural layers and theirdependencies(continued)Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 39The goal of this exercise is to jump-start analysis.References to givens:• Requirements Results: Payroll Requirements Document• Architectural Decisions: Payroll Architecture Handbook, Logical View,Architectural Analysis section.Note: This exercise has been tightly scoped to emphasize the Analysis and Designmodeling concepts and reduce the emphasis on architectural issues. Thus, much ofthe architecture has been provided to you, rather than asking you to provide it as partof the exercise. Remember, this is not an architecture course.5 - 39

DEV475 Mastering Object-Oriented Analysis and Design with UMLExercise: Architectural Analysis (cont.)Exercise: Architectural Analysis (cont.)• Identify the following:• The key abstractions(continued)Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 40To identify the key abstractions, you can probably concentrate on the ProblemStatement and the Glossary.Create a class to represent each key abstraction Be sure to include a briefdescription for each class. You do not need to allocate the classes to packages. Thatwill occur in the next module. You do not need to define relationships between theclasses at this point. We will concentrate on class relationships in later modules.The class diagrams of the upper-level layers and their dependencies should be drawnusing the given textual descriptions.References to sample diagrams within the course that are similar to what should beproduced are:Refer to the following slides if needed;• What Are Key Abstractions – p. 5-29• Defining Key Abstractions – p. 5-305 - 40

Module 5 - Architectural AnalysisExercise: Architectural Analysis (cont.)Exercise: Architectural Analysis (cont.)• Produce the following:• Class diagram containing the keyabstractions• Class diagram containing theupper-level architectural layersand their dependenciesMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 41You will need to create two different class diagrams in this solution: one showing thekey abstractions and one showing the architectural layers and their dependencies.Refer to the following slides if needed;• Package Relationships: Dependency – p. 5-8• Example: Key Abstractions – p. 5-30• Example: High-level Organization of the Model – p. 5-185 - 41

DEV475 Mastering Object-Oriented Analysis and Design with UMLExercise: ReviewExercise: Review• Compare your key abstractionswith the rest of the class• Have the key concepts beenidentified?• Does the name of each classreflect the role it plays?• Compare your class diagramshowing the upper-level layers• Do the package relationshipssupport the Payroll Systemarchitecture?Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 425 - 42

► ► ► Module 6Use-Case AnalysisMastering Object-Oriented Analysisand Design with UMLModule 6: Use-Case AnalysisTopicsUse-Case Analysis Overview................................................................................. 6-4Supplement The Use-Case Description................................................................. 6-6Find Classes From Use-Case Behavior................................................................... 6-8Distribute Use-Case Behavior to Classes.............................................................. 6-26Describe Responsibilities .................................................................................... 6-36Describe Attributes and Associations................................................................... 6-40Use-Case Analysis Steps...................................................................................... 6-52Unify Analysis Classes......................................................................................... 6-57Review............................................................................................................... 6-636 - 1

DEV475 Mastering Object-Oriented Analysis and Design with UMLObjectives: Use-Case AnalysisObjectives: Use-Case Analysis• Explain the purpose of Use-CaseAnalysis and where in the lifecycle it isperformed• Identify the classes which perform a usecaseflow of events• Distribute the use-case behavior to thoseclasses, identifying responsibilities of theclasses• Develop Use-Case Realizations thatmodel the collaborations betweeninstances of the identified classesMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 2Use-Case Analysis is where we identify the initial classes of our system.As the analysis classes are defined and the responsibilities are allocated to them, wewill also note the usage of architectural mechanisms, more specifically, the usage ofany analysis mechanisms defined in Architectural Analysis.The analysis classes and the initial Use-Case Realizations are the key model elementsbeing developed in this activity. These will be refined in the remaining Analysis andDesign activities.6 - 2

Module 6 - Use-Case AnalysisUse-Case Analysis in ContextUse-Case Analysis in Context[EarlyElaborationIteration][InceptionIteration (Optional)]Define a CandidateArchitecturePerformArchitecturalSynthesisAnalyze BehaviorDesignerUse-CaseAnalysisRefine theArchitecture(Optional)DefineComponentsDesign theDatabaseMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 3As you may recall, the above diagram illustrates the workflow that we are using in thiscourse. It is a tailored version of the Analysis and Design core workflow of theRational Unified Process. Use-Case Analysis is an activity in the Analyze Behaviorworkflow detail.At this point, we have made an initial attempt at defining our architecture — we havedefined the upper layers of our architecture, the key abstractions, and some keyanalysis mechanisms. This initial architecture, along with the software requirementsdefined in the Requirements discipline, guides and serves as input to the Use-CaseAnalysis activity.An instance of Use-Case Analysis is performed for each use case to be developedduring an iteration. The focus during Use-Case Analysis is on a particular use case.In Use-Case Analysis, we identify the analysis classes and define theirresponsibilities. As the analysis classes and their responsibilities are defined, we willalso note the usage of any architectural (more specifically, analysis) patterns definedin Architectural Analysis. The architectural layers and their dependencies may affectthe allocation of responsibility to the defined analysis classes.The allocation of responsibility is modeled in Use-Case Realizations that describe howanalysis classes collaborate to perform use cases. The Use-Case Realizations will berefined in the Use-Case Design Model.6 - 3

DEV475 Mastering Object-Oriented Analysis and Design with UMLUse-Case Analysis OverviewUse-Case Analysis OverviewGlossaryProject SpecificGuidelinesSoftwareArchitectureDocumentUse-Case RealizationSupplementarySpecificationsUse-CaseAnalysisAnalysis ModelUse-Case ModelAnalysis ClassesMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 4Use-Case Analysis is performed by the designer, once per iteration per Use-CaseRealization. What event flows, and therefore what Use-Case Realizations you aregoing to work on during the current iteration are defined prior to the start of Use-Case Analysis in Architectural Analysis.Purpose• To identify the classes that perform a use case’s flow of events• To distribute the use case behavior to those classes, using Use-Case Realizations• To identify the responsibilities, attributes and associations of the classes• To note the usage of architectural mechanismsInput Artifacts• Glossary• Supplementary Specifications• Use-Case• Use-Case Model• Use-Case Realization• Software Architecture Document• Analysis Class• Analysis Model• Project Specific GuidelinesResulting Artifacts• Analysis Classes• Analysis Model• Use-Case RealizationsNote: We will not be developing a separate Analysis Model in this course.6 - 4

Module 6 - Use-Case AnalysisUse-Case Analysis StepsUse-Case Analysis Steps• Supplement the Use-Case Description• For each Use-Case Realization• Find Classes from Use-Case Behavior• Distribute Use-Case Behavior to Classes• For each resulting analysis class• Describe Responsibilities• Describe Attributes and Associations• Qualify Analysis Mechanisms• Unify Analysis Classes• CheckpointsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 5The above are the major steps of the Use-Case Analysis activity.First we must review the use-case descriptions developed in the Requirementsdiscipline. Chances are, they will need some enhancements to include enough detailto begin developing a model.Next, we study the use-case flow of events, identify analysis classes, and allocate usecaseresponsibilities to the analysis classes. Based on these allocations, and theanalysis class collaborations, we can begin to model the relationships between theidentified analysis classes.Once the use case has been analyzed, we need to take a good look at the identifiedclasses, making sure they are thoroughly documented and identify which analysis andmechanisms they implement.Last, but not least, we need to make sure that our developed Analysis Model isconsistent.6 - 5

DEV475 Mastering Object-Oriented Analysis and Design with UMLSupplement The Use-Case DescriptionUse-Case Analysis Steps• Supplement the Use-Case Description• For each Use-Case Realization• Find Classes from Use-Case Behavior• Distribute Use-Case Behavior to Classes• For each resulting analysis class• Describe Responsibilities• Describe Attributes and Associations• Qualify Analysis Mechanisms• Unify Analysis Classes• CheckpointsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 6The purpose of the Supplement the Descriptions of the Use Case is to captureadditional information needed in order to understand the required internal behaviorof the system that may be missing from the Use-Case Description written for thecustomer of the system. This information will be used as input to the rest of the stepsin Use-Case Analysis and is used to assist in the allocation of responsibility.Note: In some cases, we may find that some requirements were incorrect or not wellunderstood.In those cases, the original use-case flow of events should be updated(for example, iterate back to the Requirements discipline).6 - 6

Module 6 - Use-Case AnalysisSupplement the Use-Case DescriptionSupplement the Use-Case Description• The systemdisplays alist ofcourseofferings.• The systemretrieves anddisplays a list ofcurrent courseofferings from thecourse cataloglegacy database.Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 7The description of each use case is not always sufficient for finding analysis classesand their objects. The customer generally finds information about what happensinside the system uninteresting, so the use-case descriptions may leave suchinformation out. In these cases, the use-case description reads like a “black-box”description, in which internal details on what the system does in response to anactor’s actions is either missing or very summarily described. To find the objects thatperform the use case, you need to have the “white box” description of what thesystem does from an internal perspective.For example, in the case of the Course Registration System, the student might preferto say ”the system displays a list of course offerings.” While this might be sufficient forthe student, it gives us no real idea of what really happens inside the system. In orderto form an internal picture of how the system really works, at a sufficient level ofdetail to identify objects, we might need additional information.Taking the Register for Courses use case as an example, the expanded descriptionwould read as: “The system retrieves a list of current course offerings from the coursecatalog legacy database.” This level of detail gives us a clear idea of what informationis required and who is responsible for providing that information.6 - 7

DEV475 Mastering Object-Oriented Analysis and Design with UMLFind Classes From Use-Case BehaviorUse-Case Analysis Steps• Supplement the Use-Case Description• For each Use-Case Realization• Find Classes from Use-Case Behavior• Distribute Use-Case Behavior to Classes• For each resulting analysis class• Describe Responsibilities• Describe Attributes and Associations• Qualify Analysis Mechanisms• Unify Analysis Classes• CheckpointsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 8Now that we have a more detailed understanding of the Requirements, asdocumented in the use case, we can identify the candidate analysis classes for oursystem.The purpose of the Find Classes from Use-Case Behavior step is to identify acandidate set of model elements (analysis classes) that will be capable of performingthe behavior described in the use case.6 - 8

Module 6 - Use-Case AnalysisReview: ClassReview: Class• An abstraction• Describes a group of objects with common:• Properties (attributes)• Behavior (operations)• Relationships• Semantics Class NameProfessorAttributesnameProfessorId : UniqueIdOperationscreate()save()delete()change()Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 9As discussed in the Concepts of Object Orientation module, a class is a description ofa group of objects with common properties (attributes), common behavior(operations), common relationships, and common semantics.A class is an abstraction in that it:• Emphasizes relevant characteristics.• Suppresses other characteristics.A class is comprised of three sections:• The first section contains the class name.• The second section shows the structure (attributes).• The third section shows the behavior (operations).6 - 9

DEV475 Mastering Object-Oriented Analysis and Design with UMLReview: Use-Case RealizationReview: Use-Case RealizationUse-Case ModelDesign ModelUse CaseUse-Case RealizationSequence DiagramsCollaboration DiagramsUse CaseClass DiagramsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 10As discussed in the Analysis and Design Overview module, a Use-Case Realizationdescribes how a particular use case is realized within the Design Model in terms ofcollaborating objects. A Use-Case Realization in the Design Model can be traced to ause case in the Use-Case Model. A realization relationship is drawn from the Use-Case Realization to the use case it realizes.A Use-Case Realization is one possible realization of a use case. A Use-CaseRealization can be represented using a set of diagrams (the number and type mayvary by project).• Interaction diagrams (Sequence and/or Collaboration diagrams) can be used todescribe how the use case is realized in terms of collaborating objects. Thesediagrams model the detailed collaborations of the Use-Case Realization.• Class diagrams can be used to describe the classes that participate in therealization of the use case, as well as their supporting relationships. Thesediagrams model the context of the Use-Case Realization.During analysis activities (Use-Case Analysis), the Use-Case Realization diagrams areoutlined. In subsequent design activities (Use-Case Design), these diagrams arerefined and updated according to more formal class interface definitions.A designer is responsible for the integrity of the Use-Case Realization. He or she mustcoordinate with the designers responsible for the classes and relationships employedin the Use-Case Realization. The Use-Case Realization can be used by class designersto understand the class’s role in the use case and how the class interacts with otherclasses. This information can be used to determine or refine the class responsibilitiesand interfaces.6 - 10

Module 6 - Use-Case AnalysisAnalysis Classes: A First Step Toward ExecutablesAnalysis Classes: A First Step Toward ExecutablesUse CasesAnalysisClassesDesignElementsSourceCodeExecUse-Case AnalysisMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 11Finding a candidate set of roles is the first step in the transformation of the systemfrom a mere statement of required behavior to a description of how the system willwork.The analysis classes, taken together, represent an early conceptual model of thesystem. This conceptual model evolves quickly and remains fluid for some time asdifferent representations and their implications are explored. Formal documentationcan impede this process, so be careful how much energy you expend on maintainingthis “mode”’ in a formal sense; you can waste a lot of time polishing a model that islargely expendable. Analysis classes rarely survive into the design unchanged. Manyof them represent whole collaborations of objects, often encapsulated by subsystems.Analysis classes are “proto-classes,” which are essentially "clumps of behavior." Theseanalysis classes are early conjectures of the composition of the system; they rarelysurvive intact into Implementation. Many of the analysis classes morph intosomething else later (subsystems, components, split classes, or combined classes).They provide you with a way of capturing the required behaviors in a form that wecan use to explore the behavior and composition of the system. Analysis classesallow us to "play" with the distribution of responsibilities, re-allocating as necessary.6 - 11

DEV475 Mastering Object-Oriented Analysis and Design with UMLFind Classes from Use-Case BehaviorFind Classes from Use-Case Behavior• The complete behavior of a use case has tobe distributed to analysis classesMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 12The technique for finding analysis classes described in this module uses threedifferent perspectives of the system to drive the identification of candidate classes.These three perspectives are:• The boundary between the system and its actors• The information the system uses• The control logic of the systemThe use of stereotypes to represent these perspectives (for example, boundary,control, and entity) results in a more robust model because they isolate those thingsmost likely to change in a system: the interface/environment, the control flow, andthe key system entities. These stereotypes are conveniences used during Analysis thatdisappear in Design.Identification of classes means just that: They should be identified, named, anddescribed briefly in a few sentences.The different stereotypes are discussed in more detail throughout this module.6 - 12

Module 6 - Use-Case AnalysisWhat Is an Analysis Class?What Is an Analysis Class?SystemboundarySysteminformationUse-casebehaviorcoordinationSystemboundarySysteminformationMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 13Analysis classes represent an early conceptual model for “things in the system thathave responsibilities and behavior.” Analysis classes are used to capture a “first-draft”rough-cut of the Object Model of the system.Analysis classes handle primarily functional requirements. They model objects fromthe problem domain. Analysis classes can be used to represent "the objects we wantthe system to support" without making a decision about how much of them tosupport with hardware and how much with software.Three aspects of the system are likely to change:• The boundary between the system and its actors• The information the system uses• The control logic of the systemIn an effort to isolate the parts of the system that will change, the following types ofanalysis classes are identified with a “canned” set of responsibilities:• Boundary• Entity• ControlStereotypes may be defined for each type. These distinctions are used duringAnalysis, but disappear in Design.The different types of analysis classes can be represented using different icons or withthe name of the stereotype in guillemets (>): , , .Each of these types of analysis classes are discussed on the following slides.6 - 13

DEV475 Mastering Object-Oriented Analysis and Design with UMLWhat Is a Boundary Class?What Is a Boundary Class?• Intermediates between the interface andsomething outside the system• Several Types• User interface classes• System interface classes• Device interface classes• One boundary class per actor/use-case pairAnalysis classstereotypeMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 14Environment DependentA boundary class intermediates between the interface and something outside thesystem. Boundary classes insulate the system from changes in the surroundings (forexample, changes in interfaces to other systems and changes in user requirements),keeping these changes from affecting the rest of the system.A system can have several types of boundary classes:• User interface classes—Classes that intermediate communication with humanusers of the system.• System interface classes—Classes that intermediate communication with othersystems. A boundary class that communicates with an external system isresponsible for managing the dialog with the external system; it provides theinterface to that system for the system being built.• Device interface classes—Classes that provide the interface to devices whichdetect external events. These boundary classes capture the responsibilities of thedevice or sensor.One recommendation for the initial identification of boundary classes is oneboundary class per actor/use-case pair.6 - 14

Module 6 - Use-Case AnalysisThe Role of a Boundary ClassThe Role of a Boundary ClassActor 1Actor 2Model interaction between the system and its environmentMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 15A boundary class is used to model interaction between the system's surroundings andits inner workings. Such interaction involves transforming and translating events andnoting changes in the system presentation (such as the interface).Boundary classes model the parts of the system that depend on its surroundings. Theymake it easier to understand the system because they clarify the system's boundariesand aid design by providing a good point of departure for identifying related services.For example, if you identify a printer interface early in the design, you will realize thatyou must also model the formatting of printouts.Because boundary classes are used between actors and the working of the internalsystem (actors can only communicate with boundary classes), they insulate externalforces from internal mechanisms and vice versa. Thus, changing the GUI orcommunication protocol should mean changing only the boundary classes, not theentity and control classes.A boundary object (an instance of a boundary class) can outlive a use-case instance if,for example, it must appear on a screen between the performance of two use cases.Normally, however, boundary objects live only as long as the use-case instance.6 - 15

DEV475 Mastering Object-Oriented Analysis and Design with UMLExample: Finding Boundary ClassesExample: Finding Boundary Classes• One boundary class per actor/use case pairStudentRegister for CoursesCourse Catalog SystemRegisterForCoursesFormCourseCatalogSystemMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 16The goal of Analysis is to form a good picture of how the system is composed, not todesign every last detail. In other words, identify boundary classes only for phenomenain the system or for things mentioned in the flow of events of the Use-CaseRealization.Consider the source for all external events and make sure there is a way for thesystem to detect these events.One recommendation for the initial identification of boundary classes is oneboundary class per actor/use-case pair. This class can be viewed as havingresponsibility for coordinating the interaction with the actor. This may be refined as amore detailed analysis is performed. This is particularly true for window-based GUIapplications where there is typically one boundary class for each window, or one foreach dialog box.In the above example:• The RegisterForCoursesForm contains a Student's "schedule-in-progress." Itdisplays a list of Course Offerings for the current semester from which theStudent may select courses to be added to his or her Schedule.• The CourseCatalogSystem interfaces with the legacy system that provides theunabridged catalog of all courses offered by the university. This class replaces theCourseCatalog abstraction originally identified in Architectural Analysis.6 - 16

Module 6 - Use-Case AnalysisGuidelines: Boundary ClassGuidelines: Boundary Class• User Interface Classes• Concentrate on what information is presented tothe user• Do NOT concentrate on the UI details• System and Device Interface Classes• Concentrate on what protocols must be defined• Do NOT concentrate on how the protocols willbe implementedConcentrate on the responsibilities, not the details!Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 17When identifying and describing analysis classes, be careful not to spend too muchtime on the details. Analysis classes are meant to be a first cut at the abstractions ofthe system. They help to clarify the understanding of the problem to be solved andrepresent an attempt at an idealized solution (Analysis has been called “idealizedDesign”).User Interface Classes: Boundary classes may be used as “holding places” for GUIclasses. The objective is not to do GUI design in this analysis, but to isolate allenvironment-dependent behavior. The expansion, refinement and replacement ofthese boundary classes with actual user-interface classes (probably derived frompurchased UI libraries) is a very important activity of Class Design and will bediscussed in the Class Design module. Sketches or screen captures from a userinterfaceprototype may have been used during the Requirements discipline toillustrate the behavior and appearance of the boundary classes. These may beassociated with a boundary class. However, only model the key abstractions of thesystem; do not model every button, list, and widget in the GUI.System and Device Interface Classes: If the interface to an existing system or deviceis already well-defined, the boundary class responsibilities should be derived directlyfrom the interface definition. If there is a working communication with the externalsystem or device, make note of it for later reference during design.6 - 17

DEV475 Mastering Object-Oriented Analysis and Design with UMLWhat Is an Entity Class?What Is an Entity Class?• Key abstractions of the systemAnalysis classstereotypeUse CaseBusiness-DomainModelArchitectural AnalysisAbstractionsGlossaryEnvironment IndependentMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 18Entity objects represent the key concepts of the system being developed. Entityclasses provide another point of view from which to understand the system, becausethey show the logical data structure. Knowing the data structure can help youunderstand what the system is supposed to offer its users.Frequent sources of inspiration for entity classes are the:• Glossary (developed during requirements)• Business-Domain Model (developed during business modeling, if businessmodeling has been performed)• Use-case flow of events (developed during requirements)• Key abstractions (identified in Architectural Analysis)As mentioned earlier, sometimes there is a need to model information about an actorwithin the system. This is not the same as modeling the actor (actors are external. bydefinition). In this case, the information about the actor is modeled as an entityclass. These classes are sometimes called “surrogates.”6 - 18

Module 6 - Use-Case AnalysisThe Role of an Entity ClassThe Role of an Entity ClassActor 1Actor 2Store and manage information in the systemMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 19Entity classes represent stores of information in the system. They are typically used torepresent the key concepts that the system manages. Entity objects (instances of entityclasses) are used to hold and update information about some phenomenon, such asan event, a person, or a real-life object. They are usually persistent, having attributesand relationships needed for a long period, sometimes for the lifetime of the system.The main responsibilities of entity classes are to store and manage information in thesystem.An entity object is usually not specific to one Use-Case Realization and sometimes itis not even specific to the system itself. The values of its attributes and relationshipsare often given by an actor. An entity object may also be needed to help performinternal system tasks. Entity objects can have behavior as complicated as that of otherobject stereotypes. However, unlike other objects, this behavior is strongly related tothe phenomenon the entity object represents. Entity objects are independent of theenvironment (the actors).6 - 19

DEV475 Mastering Object-Oriented Analysis and Design with UMLExample: Finding Entity ClassesExample: Finding Entity Classes• Use use-case flow of events as input• Key abstractions of the use case• Traditional, filtering nouns approach• Underline noun clauses in the use-case flow ofevents• Remove redundant candidates• Remove vague candidates• Remove actors (out of scope)• Remove implementation constructs• Remove attributes (save for later)• Remove operationsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 20Taking the use-case flow of events as input, underline the noun phrases in the flow ofevents. These form the initial candidate list of analysis classes.Next, go through a series of filtering steps where some candidate classes areeliminated. This is necessary due to the ambiguity of the English language. The resultof the filtering exercise is a refined list of candidate entity classes. While the filteringapproach does add some structure to what could be an ad-hoc means of identifyingclasses, people generally filter as they go rather than blindly accepting all nouns andthen filtering.6 - 20

Module 6 - Use-Case AnalysisExample: Candidate Entity ClassesExample: Candidate Entity Classes• Register for Courses (Create Schedule)CourseOfferingScheduleStudentMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 21The following are the definitions for each of the classes shown in the above diagram:CourseOffering: A specific offering for a course, including days of the week andtimes.Schedule: The courses a student has selected for the current semester.Student: A person enrolled in classes at the university.As mentioned earlier, sometimes there is a need to model information about an actorwithin the system. This is not the same as modeling the actor. (Actors are external bydefinition.) These classes are sometimes called “surrogates”.For example, a course registration system maintains information about the studentthat is independent of the fact that the student also plays a role as an actor in thesystem. This information about the student is stored in a “Student” class that iscompletely independent of the “actor” role the student plays. The Student class willexist whether or not the student is an actor to the system.6 - 21

DEV475 Mastering Object-Oriented Analysis and Design with UMLWhat Is a Control Class?What Is a Control Class?• Use-case behavior coordinator• More complex use cases generally require oneor more control casesUse CaseAnalysis classstereotypeUse-case dependent, Environment independentMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 22Control classes provide coordinating behavior in the system. The system can performsome use cases without control classes by using just entity and boundary classes. Thisis particularly true for use cases that involve only the simple manipulation of storedinformation. More complex use cases generally require one or more control classesto coordinate the behavior of other objects in the system. Examples of control classesinclude transaction managers, resource coordinators, and error handlers.Control classes effectively decouple boundary and entity objects from one another,making the system more tolerant of changes in the system boundary. They alsodecouple the use-case specific behavior from the entity objects, making them morereusable across use cases and systems.Control classes provide behavior that:• Is surroundings-independent (does not change when the surroundings change).• Defines control logic (order between events) and transactions within a use case.• Changes little if the internal structure or behavior of the entity classes changes.• Uses or sets the contents of several entity classes, and therefore needs tocoordinate the behavior of these entity classes.• Is not performed in the same way every time it is activated (flow of eventsfeatures several states).Although complex use cases may need more than one control class it isrecommended, for the initial identification of control classes, that only one controlclass be created per use case.6 - 22

Module 6 - Use-Case AnalysisThe Role of a Control ClassThe Role of a Control ClassActor 1Actor 2Coordinate the use-case behaviorMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 23A control class is a class used to model control behavior specific to one or more usecases. Control objects (instances of control classes) often control other objects, sotheir behavior is of the coordinating type. Control classes encapsulate use-casespecificbehavior.The behavior of a control object is closely related to the realization of a specific usecase. In many scenarios, you might even say that the control objects "run" the Use-Case Realizations. However, some control objects can participate in more than oneUse-Case Realization if the use-case tasks are strongly related. Furthermore, severalcontrol objects of different control classes can participate in one use case. Not all usecases require a control object. For example, if the flow of events in a use case isrelated to one entity object, a boundary object may realize the use case incooperation with the entity object. You can start by identifying one control class perUse-Case Realization, and then refine this as more Use-Case Realizations areidentified, and commonality is discovered.Control classes can contribute to understanding the system, because they representthe dynamics of the system, handling the main tasks and control flows.When the system performs the use case, a control object is created. Control objectsusually die when their corresponding use case has been performed.6 - 23

DEV475 Mastering Object-Oriented Analysis and Design with UMLExample: Finding Control ClassesExample: Finding Control Classes• In general, identify one control class peruse case.• As analysis continues, a complex use case’scontrol class may evolve into more than oneclassStudentRegister for CoursesCourse CatalogSystemRegistrationControllerMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 24One recommendation is to identify one control class per use case. However, this canbecome more than one use case as analysis continues. Remember that morecomplex use cases generally require one or more control cases. Each control class isresponsible for orchestrating/controlling the processing that implements thefunctionality described in the associated use case.In the above example, the RegistrationController class has beendefined to orchestrate the Register for Courses processing within the system.6 - 24

Module 6 - Use-Case AnalysisExample: Summary: Analysis ClassesExample: Summary: Analysis ClassesStudentUse-Case ModelRegister for CoursesCourse CatalogSystemDesign ModelRegisterForCoursesForm CourseCatalogSystem Student ScheduleCourseOfferingRegistrationControllerMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 25For each Use-Case Realization, there is one or more class diagrams depicting itsparticipating classes, along with their relationships. These diagrams help to ensurethat there is consistency in the use-case implementation across subsystem boundaries.Such class diagrams have been called “View of Participating Classes” diagrams(VOPC, for short).The diagram on this slide shows the classes participating in the “Register for Courses”use case. [Note: The Part-time Student and Full-time Student classes from the Rosesolution have been omitted for brevity. (They both inherit from Student.) Classrelationships will be discussed later in this module.]6 - 25

DEV475 Mastering Object-Oriented Analysis and Design with UMLDistribute Use-Case Behavior to ClassesUse-Case Analysis Steps• Supplement the Use-Case Descriptions• For each Use-Case Realization• Find Classes from Use-Case Behavior• Distribute Use-Case Behavior to Classes• For each resulting analysis class• Describe Responsibilities• Describe Attributes and Associations• Qualify Analysis Mechanisms• Unify Analysis Classes• CheckpointsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 26Now that we have identified the candidate analysis classes, we need to allocate theresponsibilities of the use case to the analysis classes and model this allocation bydescribing the way the class instances collaborate to perform the use case in Use-Case Realization.The purpose of “Distribute Use-Case Behavior to Classes” is to:• Express the use-case behavior in terms of collaborating analysis classes• Determine the responsibilities of analysis classes6 - 26

Module 6 - Use-Case AnalysisDistribute Use-Case Behavior to ClassesDistribute Use-Case Behavior to Classes• For each use-case flow of events:• Identify analysis classes• Allocate use-case responsibilities to analysisclasses• Model analysis class interactions in InteractiondiagramsSequence DiagramsCollaboration DiagramsUse CaseUse-Case RealizationMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 27You can identify analysis classes responsible for the required behavior by steppingthrough the flow of events of the use case. In the previous step, we outlined someclasses. Now it is time to see exactly where they are applied in the use-case flow ofevents.In addition to the identified analysis classes, the Interaction diagram should showinteractions of the system with its actors. The interactions should begin with an actor,since an actor always invokes the use case. If you have several actor instances in thesame diagram, try keeping them in the periphery of that diagram.Interactions between actors should not be modeled. By definition, actors are external,and are out of scope of the system being developed. Thus, you do not includeinteractions between actors in your system model. If you need to model interactionsbetween entities that are external to the system that you are developing (for example,the interactions between a customer and an order agent for an order-processingsystem), those interactions are best included in a Business Model that drives theSystem Model.Guidelines for how to distribute behavior to classes are described on the next slide.6 - 27

DEV475 Mastering Object-Oriented Analysis and Design with UMLGuidelines: Allocating Responsibilities to ClassesGuidelines: Allocating Responsibilities to Classes• Use analysis class stereotypes as a guide• Boundary Classes• Behavior that involves communication withan actor• Entity Classes• Behavior that involves the data encapsulatedwithin the abstraction• Control Classes• Behavior specific to a use case or part of avery important flow of eventsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 28(continued)The allocation of responsibilities in analysis is a crucial and sometimes difficultactivity. These three stereotypes make the process easier by providing a set of cannedresponsibilities that can be used to build a robust system. These predefinedresponsibilities isolate the parts of the system that are most likely to change: theinterface (boundary classes), the use-case flow of events (control classes), and thepersistent data (entity classes).6 - 28

Module 6 - Use-Case AnalysisGuidelines: Allocating Responsibilities to Classes (cont.)Guidelines: Allocating Responsibilities to Classes (cont.)• Who has the data needed to perform theresponsibility?• If one class has the data, put the responsibility withthe data• If multiple classes have the data:• Put the responsibility with one class and add arelationship to the other• Create a new class, put the responsibility in thenew class, and add relationships to classesneeded to perform the responsibility• Put the responsibility in the control class, and addrelationships to classes needed to perform theresponsibilityMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 29A driving influence on where a responsibility should go is the location of the dataneeded to perform the operation.The best case is that there is one class that has all the information needed to performthe responsibility. In that case, the responsibility goes with the data (after all, that isone of the tenets of OO — data and operations together).If this is not the case, the responsibility may need to be allocated to a “third party”class that has access to the information needed to perform the responsibility. Classesand/or relationships might need to be created to make this happen. Be careful whenadding relationships — all relationships should be consistent with the abstractionsthey connect. Do not just add relationships to support the implementation withoutconsidering the overall effect on the model. Class relationships will be discussed laterin this module.When a new behavior is identified, check to see if there is an existing class that hassimilar responsibilities, reusing classes where possible. You should create new classesonly when you are sure that there is no existing object that can perform the behavior.6 - 29

DEV475 Mastering Object-Oriented Analysis and Design with UMLThe Anatomy of Sequence DiagramsThe Anatomy of Sequence DiagramsThis is a sample script.Client ObjectSupplier Object:Client:SupplierObject Lifeline1: PerformResponsibilityReflexive MessageMessage1.1: PerformAnotherResponsibilityFocus of ControlHierarchical MessageNumberingMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 30A Sequence diagram describes a pattern of interaction among objects, arranged in achronological order. It shows the objects participating in the interaction and themessages they send.An object is shown as a vertical dashed line called the "lifeline." The lifelinerepresents the existence of the object at a particular time. An object symbol is drawnat the head of the lifeline, and shows the name of the object and its class separatedby a colon and underlined.A message is a communication between objects that conveys information with theexpectation that activity will result. A message is shown as a horizontal solid arrowfrom the lifeline of one object to the lifeline of another object. For a reflexivemessage, the arrow starts and finishes on the same lifeline. The arrow is labeled withthe name of the message and its parameters. The arrow may also be labeled with asequence number.Focus of control represents the relative time that the flow of control is focused in anobject, thereby representing the time an object is directing messages. Focus ofcontrol is shown as narrow rectangles on object lifelines.Hierarchical numbering bases all messages on a dependent message. Thedependent message is the message whose focus of control the other messagesoriginate in. For example, message 1.1 depends on message 1.Scripts describe the flow of events textually.6 - 30

Module 6 - Use-Case AnalysisExample: Sequence DiagramExample: Sequence Diagram: Student: RegisterForCoursesForm : RegistrationController : CourseCatalogSystem : Schedule : Student : Course CatalogCreate a newschedule1: // create schedule( )2: // get course offerings( )3: // get course offerings(forSemester)4: // get course offerings( )A list of the availablecourse offerings for thissemester are displayed5: // display course offerings( )A blank scheduleis displayed for thestudents to selectofferings6: // display blank schedule( )7: // select 4 primary and 2 alternate offerings( )8: // create schedule with offerings( ) 9: // create with offerings( )10: // add schedule(Schedule)At this point, the Submit Schedule sub-flow is executed.Sequence Diagram: Register forCourses / Register for Courses - BasicFlow (Submit Schedule)Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 31The above example shows the object interactions to support the Create a Schedulesub-flow of the Register for Courses use case. Some of the rationale for responsibilityallocation is as follows:• The RegisterForCoursesForm knows what data it needs to display and how todisplay it. It does not know where to go to get it. That is one of theRegistrationController’s responsibilities.• Only the RegisterForCoursesForm interacts with the Student actor.• The RegistrationController understands how Students and Schedules are related.• Only the CourseCatalogSystem class interacts with the external legacy CourseCatalog System.• Note the inclusion of the actors. This is important as the diagram explicitlymodels what elements communicate with the “outside world.”6 - 31

DEV475 Mastering Object-Oriented Analysis and Design with UMLThe Anatomy of Collaboration DiagramsThe Anatomy of Collaboration DiagramsClient ObjectLinkSupplier Object:ClientPerformResponsibility:SupplierMessageMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 32A Collaboration diagram describes a pattern of interaction among objects. It showsthe objects participating in the interaction by their links to each other and themessages that they send to each other.An object is represented in one of three ways:• Objectname:Classname• ObjectName• :ClassNameA link is a relationship between objects that can be used to send messages. InCollaboration diagrams, a link is shown as a solid line between two objects. An objectinteracts with, or navigates to, other objects through its links to these objects. A link isdefined as an instance of an association.A message is a communication between objects that conveys information with theexpectation that activity will result. In Collaboration diagrams, a message is shown asa labeled arrow placed near a link. This means that the link is used to transport orotherwise implement the delivery of the message to the target object. The arrowpoints along the link in the direction of the target object (the one that receives themessage). The arrow is labeled with the name of the message and its parameters. Thearrow may also be labeled with a sequence number to show the sequence of themessage in the overall interaction. Sequence numbers are often used in Collaborationdiagrams because they are the only way of describing the relative sequencing ofmessages. A message can be unassigned, meaning that its name is a temporary stringthat describes the overall meaning of the message. You can later assign the messageby specifying the operation of the message's destination object. The specifiedoperation will then replace the name of the message.6 - 32

Module 6 - Use-Case AnalysisExample: Collaboration DiagramExample: Collaboration Diagram5: // display course offerings( )6: // display blank schedule( ): Course Catalog: RegisterForCoursesForm4: // get course offerings( ): CourseCatalogSystem2: // get course offerings( )8: // create schedule with offerings( )1: // create schedule( )7: // select 4 primary and 2 alternate offerings( )3: // get course offerings(forSemester): RegistrationController: Student: Schedule9: // create with offerings( )10: // add schedule(Schedule): StudentMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 33The above example shows the collaboration of objects to support the Register forCourses use case, Create a Schedule subflow. It is the “Collaboration diagramequivalent” of the Sequence diagram shown earlier.6 - 33

DEV475 Mastering Object-Oriented Analysis and Design with UMLOne Interaction Diagram Is Not Good EnoughOne Interaction Diagram Is Not Good EnoughBasic FlowAlternate Flow 1 Alternate Flow 2 Alternate Flow 3AF3AF1AF2Alternate Flow 4 Alternate Flow 5 Alternate Flow nMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 34Model most of the flow of events to make sure that all requirements on theoperations of the participating classes are identified. Start with describing the basicflow, which is the most common or most important flow of events. Then describevariants such as exceptional flows. You do not have to describe all the flow of events,as long as you employ and exemplify all operations of the participating objects. Verytrivial flows can be omitted, such as those that concern only one object.Examples of exceptional flows include the following:• Error handling. What should the system do if an error is encountered?• Time-out handling. If the user does not reply within a certain period, the use caseshould take some special measures.• Handling of erroneous input to the objects that participate in the use case (forexample, incorrect user input).Examples of optional flows include the following:• The actor decides-from a number of options — what the system is to do next.• The subsequent flow of events depends on the value of stored attributes orrelationships.• The subsequent flow of events depends on the type of data to be processed.You can use either Collaboration or Sequence diagrams.6 - 34

Module 6 - Use-Case AnalysisCollaboration Diagrams vs. Sequence DiagramsCollaboration Diagrams vs. Sequence Diagrams• CollaborationDiagrams• Show relationships inaddition to interactions• Better for visualizingpatterns of collaboration• Better for visualizing allof the effects on a givenobject• Easier to use forbrainstorming sessions• Sequence Diagrams• Show the explicitsequence of messages• Better for visualizingoverall flow• Better for real-timespecifications and forcomplex scenariosMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 35Sequence diagrams and Collaboration diagrams express similar information, but showit in different ways.Collaboration diagrams emphasize the structural collaboration of a society of objectsand provide a clearer picture of the patterns of relationships and control that existamongst the objects participating in a use case. Collaboration diagrams show morestructural information (that is, the relationships among objects). Collaborationdiagrams are better for understanding all the effects on a given object and forprocedural design.Sequence diagrams show the explicit sequence of messages and are better for realtimespecifications and for complex scenarios. A Sequence diagram includeschronological sequences, but does not include object relationships. Sequencenumbers are often omitted in Sequence diagrams, in which the physical location ofthe arrow shows the relative sequence. On Sequence diagrams, the time dimension iseasier to read, operations and parameters are easier to present, and a larger numberof objects are easier to manage than in Collaboration diagrams.Both Sequence and Collaboration diagrams allow you to capture semantics of theuse-case flow of events; they help identify objects, classes, interactions, andresponsibilities; and they help validate the architecture.6 - 35

DEV475 Mastering Object-Oriented Analysis and Design with UMLDescribe ResponsibilitiesUse-Case Analysis Steps• Supplement the Use-Case Descriptions• For each Use-Case Realization• Find Classes from Use-Case Behavior• Distribute Use-Case Behavior to Classes• For each resulting analysis class• Describe Responsibilities• Describe Attributes and Associations• Qualify Analysis Mechanisms• Unify Analysis Classes• CheckpointsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 36At this point, analysis classes have been identified and use-case responsibilities havebeen allocated to those classes. This was done on a use-case-by-use-case basis, witha focus primarily on the use-case flow of events. Now it is time to turn our attentionto each of the analysis classes and see what each of the use cases will require ofthem. A class and its objects often participate in several Use-Case Realizations. It isimportant to coordinate all the requirements on a class and its objects that differentUse-Case Realizations may have.The ultimate objective of these class-focused activities is to to document what theclass knows and what the class does. The resulting Analysis Model gives you a bigpicture and a visual idea of the way responsibilities are allocated and what such anallocation does to the class collaborations. Such a view allows the analyst to spotinconsistencies in the way certain classes are treated in the system, for example, howboundary and control classes are used.The purpose of the Describe Responsibilities step is namely to describe theresponsibilities of the analysis classes.6 - 36

Module 6 - Use-Case AnalysisDescribe ResponsibilitiesDescribe Responsibilities• What are responsibilities?• How do I find them?Interaction Diagram:Client:Supplier// PerformResponsibilityClass DiagramSupplier// PerformResponsibilityMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 37A responsibility is a statement of something an object can be asked to provide.Responsibilities evolve into one (or more) operations on classes in design; they can becharacterized as:• The actions that the object can perform.• The knowledge that the object maintains and provides to other objects.Responsibilities are derived from messages on Interaction diagrams. For eachmessage, examine the class of the object to which the message is sent. If theresponsibility does not yet exist, create a new responsibility that provides therequested behavior.Other responsibilities will derive from nonfunctional requirements. When you createa new responsibility, check the nonfunctional requirements to see if there are relatedrequirements that apply. Either augment the description of the responsibility, orcreate a new responsibility to reflect this.Analysis class responsibilities can be documented in one of two ways:• As “analysis” operations: When this approach is chosen, it is important thatsome sort of naming convention be used. This naming convention indicates thatthe operation is being used to describe the responsibilities of the analysis classand that these “analysis” operations WILL PROBABLY change/evolve in design.• Textually: In this approach, the analysis class responsibilities are documented inthe description of the analysis classes.For the OOAD course example, we will use the “analysis” operation approach. Thenaming convention that will be used is that the “analysis” operation name will bepreceded by '//'.6 - 37

DEV475 Mastering Object-Oriented Analysis and Design with UMLExample: View of Participating Classes (VOPC) Class DiagramExample: View of Participating Classes (VOPC) Class DiagramStudent// get tuition()// add schedule()// get schedule()// delete schedule()// has pre-requisites()RegistrationController// get course offerings()// get current schedule()// delete current schedule()// submit schedule()// is registration open?()// save schedule()// create schedule with offerings()// update schedule with new selections()Schedule// commit()// select alternate()// remove offering()// level()// cancel()// get cost()// delete()// submit()// save()// any conflicts?()// create with offerings()// update with new selections()RegisterForCoursesFormCourseCatalogSystem// get course offerings()// display course offerings()// display blank schedule()// update offering selections()Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 38The View of Participating Classes (VOPC) class diagram contains the classes whoseinstances participate in the Use-Case Realization Interaction diagrams, as well as therelationships required to support the interactions. We will discuss the relationshipslater in this module. Right now, we are most interested in what classes have beenidentified, and what responsibilities have been allocated to those classes.6 - 38

Module 6 - Use-Case AnalysisMaintaining Consistency: What to Look ForMaintaining Consistency: What to Look For• In order of criticality• Redundant responsibilities across classes• Disjoint responsibilities within classes• Class with one responsibility• Class with no responsibilities• Better distribution of behavior• Class that interacts with many other classesMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 39Examine classes to ensure they have consistent responsibilities. When a class’sresponsibilities are disjoint, split the object into two or more classes. Update theInteraction diagrams accordingly.Examine classes to ensure that there are not two classes with similar responsibilities.When classes have similar responsibilities, combine them and update the Interactiondiagrams accordingly.Sometimes a better distribution of behavior becomes evident while you are workingon another Interaction diagram. In this case, go back to the previous Interactiondiagram and redo it. It is better (and easier) to change things now than later in design.Take the time to set the diagrams right, but do not get hungup trying to optimize theclass interactions.A class with only one responsibility is not a problem, per se, but it should raisequestions on why it is needed. Be prepared to challenge and justify the existence ofall classes.6 - 39

DEV475 Mastering Object-Oriented Analysis and Design with UMLDescribe Attributes and AssociationsUse-Case Analysis Steps• Supplement the Use-Case Descriptions• For each Use-Case Realization• Find Classes from Use-Case Behavior• Distribute Use-Case Behavior to Classes• For each resulting analysis class• Describe Responsibilities• Describe Attributes and Associations• Qualify Analysis Mechanisms• Unify Analysis Classes• CheckpointsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 40Now that we have defined the analysis classes and their responsibilities, and have anunderstanding of how they need to collaborate, we can continue our documentationof the analysis classes by describing their attributes and associations.The purpose of Describe Attributes and Operations is to:• Identify the other classes on which the analysis class depends.• Define the events in other analysis classes that the class must know about.• Define the information that the analysis class is responsible for maintaining.6 - 40

Module 6 - Use-Case AnalysisReview: What Is an Attribute?Review: What Is an Attribute?ClassNameAttribute : Type = InitValueAttribute : Type = InitValueAttribute : Type = InitValueIn analysis, do not spendtime on attribute signaturesCourseOfferingattributenumber : String = "100"startTime : TimeendTime : Timedays : EnumnumStudents : IntMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 41Attributes are used to store information. They are atomic things with noresponsibilities.The attribute name should be a noun that clearly states what information the attributeholds. The description of the attribute should describe what information is to bestored in the attribute; this can be optional when the information stored is obviousfrom the attribute name.During Analysis, the attribute types should be from the domain, and not adapted tothe programming language in use. For example, in the above diagram, enum willneed to be replaced with a true enumeration that describes the days theCourseOffering is offered (for example, MWF or TR).6 - 41

DEV475 Mastering Object-Oriented Analysis and Design with UMLFinding AttributesFinding Attributes• Properties/characteristics of identifiedclasses• Information retained by identified classes• “Nouns” that did not become classes• Information whose value is the important thing• Information that is uniquely "owned” by anobject• Information that has no behaviorMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 42Sources of possible attributes:• Domain knowledge• Requirements• Glossary• Domain Model• Business ModelAttributes are used instead of classes where:• Only the value of the information, not it's location, is important• The information is uniquely "owned" by the object to which it belongs; no otherobjects refer to the information.• The information is accessed by operations that only get, set, or perform simpletransformations on the information; the information has no "real" behavior otherthan providing its value.If, on the other hand, the information has complex behavior, or is shared by two ormore objects, the information should be modeled as a separate class.Attributes are domain-dependent. (An object model for a system includes thosecharacteristics that are relevant for the problem domain being modeled.)Remember, the process is use-case-driven. Thus, all discovered attributes shouldsupport at least one use case. For this reason, the attributes that are discovered areaffected by what functionality/domain is being modeled.6 - 42

Module 6 - Use-Case AnalysisReview: What Is an Association?Review: What Is an Association?•The semantic relationship between two ormore classifiers that specifies connectionsamong their instances• A structural relationship, specifying that objectsof one thing are connected to objects of anotherStudentScheduleCourseMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 43Associations represent structural relationships between objects of different classes;they connect instances of two or more classes together for some duration.You can use associations to show that objects know about other objects. Sometimes,objects must hold references to each other to be able to interact; for example, tosend messages to each other. Thus, in some cases, associations may follow frominteraction patterns in Sequence diagrams or Collaboration diagrams.Most associations are simple (exist between exactly two classes), and are drawn assolid paths connecting pairs of class symbols. Ternary relationships are also possible.Sometimes a class has an association to itself. This does not necessarily mean that aninstance of that class has an association to itself; more often, it means that oneinstance of the class has associations to other instances of the same class.An association may have a name that is placed on, or adjacent to the associationpath. The name of the association should reflect the purpose of the relationship andbe a verb phrase. The name of an association can be omitted, particularly if rolenames are used.Avoid names like "has" and "contains," as they add no information about what therelationships are between the classes.6 - 43

DEV475 Mastering Object-Oriented Analysis and Design with UMLFinding RelationshipsFinding RelationshipsPerformResponsibilityCollaborationDiagram:Client:SupplierClientLinkSupplierClassDiagramClient 0..*0..*Prime suppliersAssociationSupplierPerformResponsibility()Relationship for every link!Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 44To find relationships, start studying the links in the Collaboration diagrams. Linksbetween classes indicate that objects of the two classes need to communicate withone another to perform the use case. Thus, an association or an aggregation isneeded between the associated classes.Reflexive links do not need to be instances of reflexive relationships; an object cansend messages to itself. A reflexive relationship is needed when two different objectsof the same class need to communicate.The navigability of the relationship should support the required message direction. Inthe above example, if navigability was not defined from the Client to the Supplier,then the PerformResponsibility message could not be sent from the Client to theSupplier.Focus only on associations needed to realize the use cases; do not add associationsyou think "might" exist unless they are required based on the Interaction diagrams.Remember to give the associations role names and multiplicities. You can alsospecify navigability, although this will be refined in Class Design.Write a brief description of the association to indicate how the association is used, orwhat relationships the association represents.6 - 44

Module 6 - Use-Case AnalysisReview: What Is Aggregation?Review: What Is Aggregation?• A special form of association that models awhole-part relationship between anaggregate (the whole) and its partsWhole/aggregatePartStudent10..*Schedule0..* 0..2 CourseOfferingMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 45Aggregation is a stronger form of association which is used to model a whole-partrelationship between model elements. The whole/aggregate has an aggregationassociation to the its constituent parts. A hollow diamond is attached to the end of anassociation path on the side of the aggregate (the whole) to indicate aggregation.Since aggregation is a special form of association, the use of multiplicity, roles,navigation, and so forth is the same as for association.Sometimes a class may be aggregated with itself. This does not mean that an instanceof that class is composed of itself (that would be silly). Instead, it means that oneinstance if the class is an aggregate composed of other instances of the same class.Some situations where aggregation may be appropriate include:• An object is physically composed of other objects (for example, car beingphysically composed of an engine and four wheels).• An object is a logical collection of other objects (for example, a family is acollection of parents and children).• An object physically contains other objects (for example, an airplane physicallycontains a pilot).In the example on the slide, the relationship from Student to Schedule is modeled asan aggregation, because a Schedule is inherently tied to a particular Student. ASchedule outside of the context of a Student makes no sense in this CourseRegistration System. The relationship from Schedule to CourseOffering is anassociation because CourseOfferings may appear on multiple Schedules.6 - 45

DEV475 Mastering Object-Oriented Analysis and Design with UMLAssociation or Aggregation?Association or Aggregation?• If two objects are tightly bound by a whole-partrelationship• The relationship is an aggregation.CarDoor10..2,4• If two objects are usually considered asindependent, although they are often linked• The relationship is an association.CarDoor10..2,4When in doubt use associationMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 46Aggregation should be used only where the "parts" are incomplete outside the contextof the whole. If the classes can have independent identity outside the contextprovided by other classes, or if they are not parts of some greater whole, then theassociation relationship should be used.When in doubt, an association is more appropriate. Aggregations are generallyobvious. A good aggregate should be a natural, coherent part of the model. Themeaning of aggregates should be simple to understand from the context. Choosingaggregation is only done to help clarify; it is not something that is crucial to thesuccess of the modeling effort.The use of aggregation versus association is dependent on the application you aredeveloping. For example, if you are modeling a car dealership, the relationshipbetween a car and the doors might be modeled as aggregation, because the caralways comes with doors, and doors are never sold separately. However, if you aremodeling a car parts store, you might model the relationship as an association, as thecar (the body) might be independent of the doors.6 - 46

Module 6 - Use-Case AnalysisWhat Are Roles?What Are Roles?• The “face” that a class plays in theassociationCourseOfferinginstructorProfessorDepartmentDepartment HeadRole NameCoursepreRequisitesMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 47Each end of an association has a role in relationship to the class on the other end ofthe association. The role specifies the face that a class presents on each side of theassociation. A role must have a name, and the role names on opposite sides of theassociation must be unique. The role name should be a noun indicating theassociated object's role in relation to the associating object.The use of association names and role names is mutually exclusive: one would notuse both an association name and a role name. For each association, decide whichconveys more information.The role name is placed next to the end of the association line of the class itdescribes.In the case of self-associations, role names are essential to distinguish the purpose forthe association.In the above example, the Professor participates in two separate associationrelationships, playing a different role in each.6 - 47

DEV475 Mastering Object-Oriented Analysis and Design with UMLReview: MultiplicityReview: MultiplicityUnspecifiedExactly OneZero or MoreZero or MoreOne or MoreZero or One (optional scalar role)Specified RangeMultiple, Disjoint Ranges10..**1..*0..12..42, 4..6Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 48For each role you can specify the multiplicity of its class. Multiplicity is the number ofobjects of the class that can be associated with one object of the other class.Multiplicity is indicated by a text expression on the association line. The expression isa comma-separated list of integer ranges. A range is indicated by an integer (the lowervalue), two dots, and an integer (the upper value). A single integer is a valid range.You may also specify narrower limits such as 2..4.During Analysis, assume a multiplicity of 0..* (zero to many) unless there is someclear evidence of something else.A multiplicity of zero implies that the association is optional. When you use thisnotation, make sure this is what you mean. If an object might not be there,operations that use the association will have to adjust accordingly.Within multiplicity ranges, probabilities may be specified. Thus, if the multiplicity is0..*, and is expected to be between 10 and 20 in 85% of the cases, make note of it.This information will be of great importance during Design. For example, if persistentstorage is to be implemented using a relational database, narrower limits will helpbetter organize the database tables.6 - 48

Module 6 - Use-Case AnalysisWhat Does Multiplicity Mean?What Does Multiplicity Mean?• Multiplicity answers two questions:• Is the association mandatory or optional?• What is the minimum and maximum number ofinstances that can be linked to one instance?CourseOffering0..* 1Course0..*preRequisites 0..3Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 49• Multiplicity lets you know the lower and the upper bound number ofrelationships that a given object can have with another object. Many times youdo not know what the maximum number of instances may be, and you will usethe “*” to specify that this number is unknown.• The most important question that multiplicity answers: Is the association ismandatory? A lower bound number that is greater than zero indicates that therelationship is mandatory.• This example indicates that a course object can be related to zero or more courseofferings. You can tell that the relationship is optional because the lower boundnumber is zero. The upper bound number of the relationship is unknown, asindicated by the “*”. If you read the association the other way, you will see that agiven course offering object can be related to only one course. This relationship ismandatory and indicates that it is not possible for a course offering object to existwithout an associated course object.6 - 49

DEV475 Mastering Object-Oriented Analysis and Design with UMLExample: Multiple AssociationsExample: Multiple AssociationsScheduleprimaryCoursesCourseOfferingalternateCoursesScheduleadd student toremove student fromCourseOfferingMultiple associations must reflect multiple roles.Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 50There can be multiple associations between the same two classes, but they shouldrepresent distinct relationships, and DIFFERENT ROLES; they should not be just forinvoking different operations.If there is more than one association between two classes then they MUST be named.It is unusual to find more than one association between the same two classes.Occurrences of multiple associations should be carefully examined.To determine if multiple associations are appropriate, look at instances of the classes.ClassA and ClassB have two associations between them, Assoc1 and Assoc2. If aninstance of ClassA has a link with two SEPARATE instances of ClassB, then multipleassociations are valid.In the above example, the top diagram is an appropriate use of multiple associations,but the bottom diagram is not. In the valid case, two associations are requiredbetween Schedule and CourseOffering, as a Schedule can contain two kind ofCourseOfferings, primary and alternate. These must be distinguishable, so twoseparate associations are used. In the invalid case, the two relationships representtwo operations of CourseOffering, not two roles of CourseOffering.Remember, Students and CourseOfferings are related via the Schedule class. Studentsare enrolled in a CourseOffering if there is a relationship between the Student’sSchedule and the CourseOffering.6 - 50

Module 6 - Use-Case AnalysisExample: VOPC: Finding RelationshipsExample: VOPC: Finding RelationshipsRegisterForCoursesForm1 1RegistrationController0..1Student1currentSchedule0..*Schedule0..10..*primaryCourses0..4CourseOfferingMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 51The diagram on this slide shows classes that collaborate to perform the “Register forCourses” use case, along with their relationships. As noted earlier, this type ofdiagram is called a View of Participating Classes (VOPC) diagram.The relationships in this diagram are defined using the Interaction diagrams for theRegister for Courses use case provided earlier in this module.Rationale for relationships:• From RegisterForCoursesForm to RegistrationController: There is one controllerfor each Schedule being created (for example, each Student registration session).• From RegistrationController to Schedule. A RegistrationController deals with oneSchedule at a time (the current Schedule for the Student registering for courses).Note the use of the “currentSchedule” role name. Note: ManyRegisterForCoursesForms can be active at one time (for differentsessions/students), each with their own RegistrationController.• From Schedule to CourseOffering: Each Schedule may have up to four primaryCourse Offerings and up to two alternate Course Offerings. A particular CourseOffering may appear on many Schedules as either a primary or an alternate.• From Student to Schedule: A Student may have many schedules or none. ASchedule is only associated with a single Student and does not exist without aStudent to be associated to.6 - 51

DEV475 Mastering Object-Oriented Analysis and Design with UMLUse-Case Analysis StepsUse-Case Analysis Steps• Supplement the Use-Case Descriptions• For each Use-Case Realization• Find Classes from Use-Case Behavior• Distribute Use-Case Behavior to Classes• For each resulting analysis class• Describe Responsibilities• Describe Attributes and Associations• Qualify Analysis Mechanisms• Unify Analysis Classes• CheckpointsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 52At this point, we have a pretty good understanding of the analysis classes, theirresponsibilities, and the collaborations required to support the functionality describedin the use cases.Now we must look into how each of the defined analysis classes implements theanalysis mechanisms identified in Architectural Analysis.The purpose of the Qualify Analysis Mechanisms step is to:• Identify analysis mechanisms (if any) used by the class.• Provide additional information about how the class applies the analysismechanism.For each such mechanism, qualify as many characteristics as possible, giving rangeswhere appropriate, or when there is still much uncertainty.Different architectural mechanisms will have different characteristics, so thisinformation is purely descriptive and need only be as structured as necessary tocapture and convey the information. During Analysis, this information is generallyquite speculative, but the capturing activity has value, since conjectural estimates canbe revised as more information is uncovered. The analysis mechanism characteristicsshould be documented with the class.6 - 52

Module 6 - Use-Case AnalysisReview: Why Use Analysis Mechanisms?Review: Why Use Analysis Mechanisms?Oh no! I found a group of classes thathas persistent data. How am Isupposed to design these things if Idon’t even know what database we aregoing to be using?That is why we have a persistenceanalysis mechanism. We don’tknow enough yet, so we canbookmark it and come back to itlater.Analysis mechanisms are used during analysis to reduce the complexity ofanalysis, and to improve its consistency by providing designers with ashorthand representation for complex behavior.Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 53An analysis mechanism represents a pattern that constitutes a common solution to acommon problem. These mechanisms may show patterns of structure, patterns ofbehavior, or both. They are used during Analysis to reduce the complexity ofAnalysis, and to improve its consistency by providing designers with a shorthandrepresentation for complex behavior. Analysis mechanisms are primarily used as“placeholders” for complex technology in the middle and lower layers of thearchitecture. By using mechanisms as “placeholders” in the architecture, thearchitecting effort is less likely to become distracted by the details of mechanismbehavior.Mechanisms allow the Analysis effort to focus on translating the functionalrequirements into software concepts without bogging down in the specification ofrelatively complex behavior needed to support the functionality but which is notcentral to it. Analysis mechanisms often result from the instantiation of one or morearchitectural or analysis patterns. Persistence provides an example of analysismechanisms. A persistent object is one that logically exists beyond the scope of theprogram that created it. During analysis, we do not want to be distracted by thedetails of how we are going to achieve persistence.This gives rise to a “persistence”analysis mechanism that allows us to speak of persistent objects and capture therequirements we will have on the persistence mechanism without worrying aboutwhat exactly the persistence mechanism will do or how it will work.Analysis mechanisms are typically, but not necessarily, unrelated to the problemdomain, but instead are "computer science" concepts. As a result, they typicallyoccupy the middle and lower layers of the architecture. They provide specificbehaviors to a domain-related class or component, or correspond to theimplementation of cooperation between classes and/or components.6 - 53

DEV475 Mastering Object-Oriented Analysis and Design with UMLDescribing Analysis MechanismsDescribing Analysis Mechanisms• Collect all analysis mechanisms in a list• Draw a map of the client classes to theanalysis mechanisms• Identify characteristics of the analysismechanismsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 54In Architectural Analysis, the possible analysis mechanisms were identified anddefined.From that point on, as classes are defined, the required analysis mechanisms andanalysis mechanism characteristics should be identified and documented. Not allclasses will have mechanisms associated with them. Also, it is not uncommon for aclient class to require the services of several mechanisms.A mechanism has characteristics, and a client class uses a mechanism by qualifyingthese characteristics. This is to discriminate across a range of potential designs. Thesecharacteristics are part functionality, and part size and performance.6 - 54

Module 6 - Use-Case AnalysisExample: Describing Analysis MechanismsExample: Describing Analysis Mechanisms• Analysis class to analysis mechanism mapAnalysis ClassStudentScheduleCourseOfferingCourseRegistrationControllerAnalysis Mechanism(s)Persistency, SecurityPersistency, SecurityPersistency, Legacy InterfacePersistency, Legacy InterfaceDistributionMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 55As analysis classes are identified, it is important to identify the analysis mechanismsthat apply to the identified classes.The classes that must be persistent are mapped to the persistency mechanism.The classes that are maintained within the legacy Course Catalog system are mappedto the legacy interface mechanism.The classes for which access must be controlled (that is, control who is allowed toread and modify instances of the class) are mapped to the security mechanism.Note: The legacy interface classes do not require additional security as they are readonlyand are considered readable by all.The classes that are seen to be distributed are mapped to the distribution mechanism.The distribution identified during analysis is that which is specified/implied by theuser in the initial requirements. Distribution will be discussed in detail in theDescribe Distribution module. For now, just take it as an architectural given that allcontrol classes are distributed for the OOAD course example and exercise.6 - 55

DEV475 Mastering Object-Oriented Analysis and Design with UMLExample: Describing Analysis Mechanisms (cont.)Example: Describing Analysis Mechanisms (cont.)• Analysis mechanism characteristics• Persistency for Schedule class:• Granularity: 1 to 10 Kbytes per product• Volume: up to 2,000 schedules• Access frequency• Create: 500 per day• Read: 2,000 access per hour• Update: 1,000 per day• Delete: 50 per day• Other characteristicsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 56The above is just an example of how the characteristics for an analysis mechanismwould be documented for a class. For scoping reasons, the analysis mechanisms andtheir characteristics are not provided for all of the analysis classes.6 - 56

Module 6 - Use-Case AnalysisUnify Analysis ClassesUse-Case Analysis Steps• Supplement the Use-Case Descriptions• For each Use-Case Realization• Find Classes from Use-Case Behavior• Distribute Use-Case Behavior to Classes• For each resulting analysis class• Describe Responsibilities• Describe Attributes and Associations• Qualify Analysis Mechanisms• Unify Analysis Classes• CheckpointsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 57At this point, we have a pretty good understanding of the analysis classes, theirresponsibilities, the analysis mechanisms they need to implement, and thecollaborations required to support the functionality described in the use cases.Now we must review our work and make sure that it is as complete and as consistentas possible before moving on to the architecture activities.The purpose of Unify Analysis Classes is to ensure that each analysis class represents asingle well-defined concept, with non-overlapping responsibilities.6 - 57

DEV475 Mastering Object-Oriented Analysis and Design with UMLUnify Analysis ClassesUnify Analysis ClassesRegisterForCoursesFormRegistrationControllerCourseCatalogSystemRegisterForCoursesFormRegistrationControllerRegister forCoursesCourseOfferingScheduleStudentCourseOfferingStudentCloseRegistrationCloseRegistrationFormBillingSystemCourseOfferingCloseRegistrationControllerCourseCatalogSystemStudentScheduleCourseCatalogSystemCloseRegistrationFormCloseRegistrationControllerScheduleBillingSystemMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 58Before the Design work can be done, the analysis classes need to be filtered to ensurethat a minimum number of new concepts have been created.Different use cases will contribute to the same classes. In the example above, theclasses CourseCatalogSystem, CourseOffering, Schedule and Student participate inboth the Register for Courses and Close Registration use cases.A class can participate in any number of use cases. It is therefore important toexamine each class for consistency across the whole system.Merge classes that define similar behaviors or that represent the same phenomenon.Merge entity classes that define the same attributes, even if their defined behavior isdifferent; aggregate the behaviors of the merged classes.When you update a class, you should update any “supplemental” use-casedescriptions (described earlier in this module), where necessary. Sometimes anupdate to the original Requirements (that is, use cases) may be necessary, but thisshould be controlled, as the Requirements are the contract with the user/customer,and any changes must be verified and controlled.6 - 58

Module 6 - Use-Case AnalysisEvaluate Your ResultsEvaluate Your ResultsDesign ModelGlossarySupplementarySpecificationAnalysis ClassesUse-Case ModelMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 59We now have a pretty good feeling about our Analysis Model. Now it is time toreview our work for completeness and consistency.Be sure to:• Verify that the analysis classes meet the functional requirements made on thesystem.• Verify that the analysis classes and their relationships are consistent with thecollaborations they support.It is very important that you evaluate your results at the conclusion of the Use-CaseAnalysis.The number of reviews, the formality of the reviews, and when they are performedwill vary, depending on the process defined for the project.6 - 59

DEV475 Mastering Object-Oriented Analysis and Design with UMLUse-Case Analysis StepsUse-Case Analysis Steps• Supplement the Use-Case Descriptions• For each Use-Case Realization• Find Classes from Use-Case Behavior• Distribute Use-Case Behavior to Classes• For each resulting analysis class• Describe Responsibilities• Describe Attributes and Associations• Qualify Analysis Mechanisms• Unify Analysis Classes• CheckpointsMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 60This is where the quality of the model up to this point is assessed against some veryspecific criteria.In this module, we will concentrate on those checkpoints that the designer is mostconcerned with (that is, looks for).6 - 60

Module 6 - Use-Case AnalysisCheckpoints: Analysis ClassesCheckpoints: Analysis Classes• Are the classes reasonable?• Does the name of each classclearly reflect the role it plays?• Does the class represent a singlewell-defined abstraction?• Are all attributes andresponsibilities functionallycoupled?• Does the class offer the requiredbehavior?• Are all specific requirements onthe class addressed?Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 61(continued)The above checkpoints for the analysis classes might be useful.Note: All checkpoints should be evaluated with regards to the use cases beingdeveloped for the current iteration.The class should represent a single well-defined abstraction. If not, consider splittingit.The class should not define any attributes or responsibilities that are not functionallycoupled to the other attributes or responsibilities defined by that class.The classes should offer the behavior the Use-Case Realizations and other classesrequire.The class should address all specific requirements on the class from the requirementspecification.Remove any attributes and relationships if they are redundant or are not needed bythe Use-Case Realizations.6 - 61

DEV475 Mastering Object-Oriented Analysis and Design with UMLCheckpoints: Use-Case RealizationsCheckpoints: Use-Case Realizations• Have all the main and/or sub-flowsbeen handled, including exceptionalcases?• Have all the required objects beenfound?• Has all behavior been unambiguouslydistributed to the participating objects?• Has behavior been distributed to theright objects?• Where there are several Interactiondiagrams, are their relationships clearand consistent?Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 62The above checkpoints for the Use-Case Realizations might be useful.Note: All checkpoints should be evaluated with regards to the use cases beingdeveloped for the current iteration.The objects participating in a Use-Case Realization should be able to perform all ofthe behavior of the use case.If there are several Interaction diagrams for the Use-Case Realization, it is importantthat it is easy to understand which Interaction diagrams relate to which flow ofevents. Make sure that it is clear from the flow of events description how thediagrams are related to each other.6 - 62

Module 6 - Use-Case AnalysisReviewReview: Use-Case Analysis• What is the purpose of Use-Case Analysis?• What is an analysis class? Name anddescribe the three analysis stereotypes.• What is a Use-Case Realization?• Describe some considerationswhen allocating responsibilitiesto analysis classes.• How many Interaction diagramsshould be produced duringUse-Case Analysis?Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 636 - 63

DEV475 Mastering Object-Oriented Analysis and Design with UMLExercise: Use-Case AnalysisExercise: Use-Case Analysis• Given the following:• Use-Case Model, especially theuse-case flows of events• Key abstractions/classes• The Supplementary Specification• The possible analysismechanisms(continued)Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 64The goal of this exercise is to identify classes that must collaborate to perform a usecase, allocate the use-case responsibilities to those classes, and diagram thecollaborations.Good sources for the analysis classes are the Glossary and any analysis classes definedduring Architectural Analysis.References to the givens:• Use-Case Model: Payroll Requirements Document, Use-Case Model section.• Key abstractions: Payroll Exercise Solution, Architectural Analysis section.• Supplementary Specification: Payroll Requirements Document, SupplementarySpecification section.• The analysis mechanisms we are concentrating on in this course include:persistency, distribution, security, and legacy interface). See the PayrollArchitecture Handbook, Architectural Mechanisms, Analysis Mechanisms sectionfor more information on these analysis mechanisms.6 - 64

Module 6 - Use-Case AnalysisExercise: Use-Case Analysis (cont.)Exercise: Use-Case Analysis (cont.)• Identify the following for a particularuse case:• The analysis classes, along with their:• Brief descriptions• Stereotypes• Responsibilities• The collaborations needed toimplement the use case• Analysis class attributes andrelationships• Analysis class analysis mechanisms(continued)Mastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 65When identifying analysis classes from the use-case flows of events, use the analysisstereotypes for guidance (boundary, control, and entity).Be sure to define the identified classes. These definitions become very important asyou start to allocate responsibilities to those classes.The relationships to be identified are those needed to support the collaborationsmodeled in the use-case Interaction diagrams. The attributes to be identified are the“obvious” properties of the identified classes. More attributes may be defined duringlater Class Design.For each identified analysis class, determine if any of the analysis mechanisms apply.To make this decision, the Supplementary Specification may be needed.Refer to the following slides if needed:• Example: Finding Boundary Classes – p. 6-16• Example: Finding Entity Classes – p. 6-20• Example: Finding Control Classes – p. 6-24• Describe Responsibilities – p. 6-37• Finding Attributes – p. 6-42• Finding Relationships – p. 6-44• Example: Describing Analysis Mechanisms – p. 6-556 - 65

DEV475 Mastering Object-Oriented Analysis and Design with UMLExercise: Use-Case Analysis (cont.)Exercise: Use-Case Analysis (cont.)• Produce the following for aparticular use case:• Use-Case Realization Interactiondiagram for at least one of the usecaseflows of events• VOPC class diagram, containingthe analysis classes, theirstereotypes, responsibilities,attributes, and relationships• Analysis class to analysismechanism mapMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 66Start with diagramming the basic flow and then do the other sub-flows if you havetime.The Interaction diagrams may be collaboration or Sequence diagrams. On anInteraction diagram, sending a message to an object means that you are allocatingresponsibility for performing that task to the object.Be sure to use the “//” naming convention for responsibilities.Refer to the following slides if needed:• Review: What is a Use-Case Realization? – p. 6-10• Example: Sequence Diagram – p. 6-31• Example: Collaboration Diagram – p. 6-33• Example: VOPC Finding Relationship – p. 6-526 - 66

Module 6 - Use-Case AnalysisExercise: ReviewExercise: Review• Compare your Use-CaseRealization with the rest of the class• Do the Interaction diagrams carry outthe use-case flow of events?• Are the stereotypes behaving properly?• Is each association supported by alink?• Does each association have multiplicityassigned?• Have role names been assigned? Dothey accurately represent the face theclass plays in the relationship?Payroll SystemMastering Object Oriented Analysis and Design with UMLCopyright © 2003 Rational Software, all rights reserved 67After completing a model, it is important to step back and review your work. Somehelpful questions are the following:• Has the use case behavior been successfully represented in the model? In otherwords, is the flow of events the same in the specifications as it is in the model?• Has there been any significant behavior that was added? Removed? Changed?The model should reflect the intent of the Use-Case Specifications.• Is each stereotype behaving properly? Are actors only interfacing with boundaryclasses? Are control classes controlling the use-case flow of events only? Are anyclasses doing operations on data (attributes) that are not owned by that class?6 - 67

DEV475 Mastering Object-Oriented Analysis and Design with UML6 - 68