1、Page 1Chapter 7 Analysis and Designwith UMLPage 2Agendan7.1 Benefits of Visual Modelingn7.2 Visual Modeling with UMLn7.3 The Iterative Development ProcessPage 3Computer SystemBusiness ProcessOrderItemShip viaModeling captures essential parts of the system. Dr. James RumbaughVisual Modeling is modeli
2、ngusing standard graphical notationsWhat is Visual Modeling?7.1 Benefits of Visual ModelingPage 4Use Case Analysis is a technique to capture business process from users perspectiveVisual Modeling Captures Business ProcessPage 5Visual Modeling is a Visual Modeling is a Communication ToolCommunication
3、 ToolUse visual modeling to capture business objects and logicUse visual modeling to analyze and design your application7.1 Benefits of Visual ModelingPage 6Visual Modeling Visual Modeling Manages Complexity Manages Complexity 7.1 Benefits of Visual ModelingPage 7User Interface(Visual Basic,Java)Bus
4、iness Logic(C+, Java)Database Server(C+ & SQL)Model your systemindependent of implementation languageVisual Modeling Defines Visual Modeling Defines Software ArchitectureSoftware Architecture7.1 Benefits of Visual ModelingPage 8Multiple SystemsVisual Modeling Visual Modeling Promotes ReusePromotes R
5、euseReusableComponents7.1 Benefits of Visual ModelingPage 9UML ConceptsnThe UML may be used to:Display the boundary of a system & its major functions using use cases and actorsIllustrate use case realizations with interaction diagramsRepresent a static structure of a system using class diagrams Mode
6、l the behavior of objects with state transition diagramsReveal the physical implementation architecture with component & deployment diagrams Extend your functionality with stereotypes7.2 Visual Modeling with UMLPage 10Putting the UML to WorknThe ESU University wants to computerize their registration
7、 systemThe Registrar sets up the curriculum for a semesterOne course may have multiple course offeringsStudents select 4 primary courses and 2 alternate coursesOnce a student registers for a semester, the billing system is notified so the student may be billed for the semesterStudents may use the sy
8、stem to add/drop courses for a period of time after registrationProfessors use the system to receive their course offering rostersUsers of the registration system are assigned passwords which are used at logon validation7.2 Visual Modeling with UMLPage 11ActorsnAn actor is someone or some thing that
9、 must interact with the system under developmentStudentRegistrarProfessorBilling System7.2 Visual Modeling with UMLPage 12Use CasesnA use case is a pattern of behavior the system exhibitsEach use case is a sequence of related transactions performed by an actor and the system in a dialogue nActors ar
10、e examined to determine their needsRegistrar - maintain the curriculumProfessor - request rosterStudent - maintain scheduleBilling System - receive billing information from registrationMaintain ScheduleMaintain CurriculumRequest Course Roster7.2 Visual Modeling with UMLPage 13Documenting Use CasesnA
11、 flow of events document is created for each use casesWritten from an actor point of viewnDetails what the system must provide to the actor when the use cases is executednTypical contentsHow the use case starts and endsNormal flow of eventsAlternate flow of eventsExceptional flow of events7.2 Visual
12、 Modeling with UMLPage 14Maintain Curriculum Flow of EventsnThis use case begins when the Registrar logs onto the Registration System and enters his/her password. The system verifies that the password is valid (E-1) and prompts the Registrar to select the current semester or a future semester (E-2).
13、 The Registrar enters the desired semester. The system prompts the registrar to select the desired activity: ADD, DELETE, REVIEW, or QUIT.nIf the activity selected is ADD, the S-1: Add a Course subflow is performed.nIf the activity selected is DELETE, the S-2: Delete a Course subflow is performed.nI
14、f the activity selected is REVIEW, the S-3: Review Curriculum subflow is performed.nIf the activity selected is QUIT, the use case ends. n.7.2 Visual Modeling with UMLPage 15Use Case DiagramnUse case diagrams are created to visualize the relationships between actors and use casesStudentRegistrarProf
15、essorMaintain ScheduleMaintain CurriculumRequest Course RosterBilling System7.2 Visual Modeling with UMLPage 16Uses and Extends Use Case RelationshipsnAs the use cases are documented, other use case relationships may be discoveredA uses relationship shows behavior that is common to one or more use c
16、asesAn extends relationship shows optional behavior Register for coursesLogon validationMaintain curriculum7.2 Visual Modeling with UMLPage 17Use Case RealizationsnThe use case diagram presents an outside view of the systemnInteraction diagrams describe how use cases are realized as interactions amo
17、ng societies of objectsnTwo types of interaction diagramsSequence diagramsCollaboration diagrams7.2 Visual Modeling with UMLPage 18Sequence DiagramnA sequence diagram displays object interactions arranged in a time sequence : Studentregistration formregistration managermath 1011: fill in info2: subm
18、it3: add course(joe, math 101)4: are you open?5: are you open?6: add (joe)7: add (joe)math 101 section 17.2 Visual Modeling with UMLPage 19 : Registrarcourse form : CourseFormtheManager : CurriculumManageraCourse : Course1: set course info2: process3: add course4: new courseCollaboration DiagramnA c
19、ollaboration diagram displays object interactions organized around objects and their links to one another7.2 Visual Modeling with UMLPage 20Class DiagramsnA class diagram shows the existence of classes and their relationships in the logical view of a systemnUML modeling elements in class diagramsCla
20、sses and their structure and behaviorAssociation, aggregation, dependency, and inheritance relationshipsMultiplicity and navigation indicatorsRole names7.2 Visual Modeling with UMLPage 21ClassesnA class is a collection of objects with common structure, common behavior, common relationships and commo
21、n semanticsnClasses are found by examining the objects in sequence and collaboration diagramnA class is drawn as a rectangle with three compartmentsnClasses should be named using the vocabulary of the domainNaming standards should be createde.g., all classes are singular nouns starting with a capita
22、l letter7.2 Visual Modeling with UMLPage 22ClassesRegistrationFormRegistrationManagerCourseStudentCourseOfferingProfessorScheduleAlgorithm7.2 Visual Modeling with UMLPage 23OperationsnThe behavior of a class is represented by its operationsnOperations may be found by examining interaction diagramsre
23、gistration formregistration manager3: add course(joe, math 01)RegistrationManageraddCourse(Student,Course)7.2 Visual Modeling with UMLPage 24AttributesnThe structure of a class is represented by its attributesnAttributes may be found by examining class definitions, the problem requirements, and by a
24、pplying domain knowledgeEach course offeringhas a number, location and timeCourseOfferingnumberlocationtime7.2 Visual Modeling with UMLPage 25ClassesRegistrationFormRegistrationManageraddStudent(Course, StudentInfo)CoursenamenumberCreditsopen()addStudent(StudentInfo)StudentnamemajorCourseOfferingloc
25、ationopen()addStudent(StudentInfo)ProfessornametenureStatusScheduleAlgorithm7.2 Visual Modeling with UMLPage 26RelationshipsnRelationships provide a pathway for communication between objectsnSequence and/or collaboration diagrams are examined to determine what links between objects need to exist to
26、accomplish the behavior - if two objects need to talk? there must be a link between themnThree types of relationships are:AssociationAggregationDependency7.2 Visual Modeling with UMLPage 27RelationshipsnAn association is a bi-directional connection between classesAn association is shown as a line co
27、nnecting the related classesnAn aggregation is a stronger form of relationship where the relationship is between a whole and its partsAn aggregation is shown as a line connecting the related classes with a diamond next to the class representing the wholenA dependency relationship is a weaker form of
28、 relationship showing a relationship between a client and a supplier where the client does not have semantic knowledge of the suppliernA dependency is shown as a dashed line pointing from the client to the supplier7.2 Visual Modeling with UMLPage 28Registration ManagerMath 101: Course3: add student(
29、joe)RegistrationManagerCourseFinding RelationshipsnRelationships are discovered by examining interaction diagramsIf two objects must talk?there must be a pathway for communication7.2 Visual Modeling with UMLPage 29RelationshipsRegistrationFormRegistrationManagerCourseStudentCourseOfferingProfessorad
30、dStudent(Course, StudentInfo)namenumberCreditsopen()addStudent(StudentInfo)namemajorlocationopen()addStudent(StudentInfo)nametenureStatusScheduleAlgorithm7.2 Visual Modeling with UMLPage 30Multiplicity and NavigationnMultiplicity defines how many objects participate in a relationshipsMultiplicity is
31、 the number of instances of one class related to ONE instance of the other classFor each association and aggregation, there are two multiplicity decisions to make: one for each end of the relationshipnAlthough associations and aggregations are bi-directional by default, it is often desirable to rest
32、rict navigation to one directionnIf navigation is restricted, an arrowhead is added to indicate the direction of the navigation7.2 Visual Modeling with UMLPage 31Multiplicity and NavigationRegistrationFormRegistrationManagerCourseStudentCourseOfferingProfessoraddStudent(Course, StudentInfo)namenumbe
33、rCreditsopen()addStudent(StudentInfo)majorlocationopen()addStudent(StudentInfo)tenureStatusScheduleAlgorithm10.*0.*111.*43.100.417.2 Visual Modeling with UMLPage 32InheritancenInheritance is a relationships between a superclass and its subclassesnThere are two ways to find inheritance:Generalization
34、SpecializationnCommon attributes, operations, and/or relationships are shown at the highest applicable level in the hierarchy7.2 Visual Modeling with UMLPage 33InheritanceRegistrationFormRegistrationManagerCourseStudentCourseOfferingProfessoraddStudent(Course, StudentInfo)namenumberCreditsopen()addS
35、tudent(StudentInfo)majorlocationopen()addStudent(StudentInfo)tenureStatusScheduleAlgorithmnameRegistrationUser7.2 Visual Modeling with UMLPage 34The State of an ObjectnA state transition diagram shows The life history of a given classThe events that cause a transition from one state to anotherThe ac
36、tions that result from a state changenState transition diagrams are created for objects with significant dynamic behavior7.2 Visual Modeling with UMLPage 35State Transition DiagramInitializationOpenentry: Register studentexit: Increment countClosedCanceleddo: Initialize coursedo: Finalize coursedo:
37、Notify registered studentsAdd Student / Set count = 0Add student count 10 count = 10 CancelCancelCancel7.2 Visual Modeling with UMLPage 36The Physical WorldnComponent diagrams illustrate the organizations and dependencies among software componentsnA component may be A source code componentA run time
38、 components orAn executable component7.2 Visual Modeling with UMLPage 37CourseCourseOfferingStudentProfessorComponent DiagramCourse.dllPeople.dllCourseUserRegister.exeBilling.exeBillingSystem7.2 Visual Modeling with UMLPage 38Deploying the SystemnThe deployment diagram shows the configuration of run
39、-time processing elements and the software processes living on them.nThe deployment diagram visualizes the distribution of components across the enterprise.7.2 Visual Modeling with UMLPage 39Deployment DiagramRegistrationServerDatabaseServerClient for LibraryClient forDorm Client forMain Building7.2
40、 Visual Modeling with UMLPage 40Extending the UMLnStereotypes can be used to extend the UML notational elementsnStereotypes may be used to classify and extend associations, inheritance relationships, classes, and componentsnExamples:Class stereotypes: boundary, control, entity, utility, exceptionInh
41、eritance stereotypes: uses and extendsComponent stereotypes: subsystem7.2 Visual Modeling with UMLPage 417.3 The Iterative Development ProcessWhat the Iterative Life Cycle Is NotnIt is not hackingnIt is not a playpen for developersnIt is not unpredictablenIt is not redesigning the same thing over an
42、d over until it is perfectnIt is not an excuse for not planning and managing a projectnIt is not something that affects only the developers on a projectPage 42What the Iterative Life Cycle IsnIt is planned and managednIt is predictablenIt accommodates changes to requirements with less disruptionnIt
43、is based on evolving executable prototypes, not documentationnIt involves the user/customer throughout the processnIt is risk driven7.3 The Iterative Development ProcessPage 43Three Important Features of the Iterative ApproachnContinuous integrationNot done in one lump near the delivery datenFrequen
44、t, executable releasesSome internal; some deliverednAttack risks through demonstrable progressProgress measured in products, not documentation or engineering estimates7.3 The Iterative Development ProcessPage 44Resulting BenefitsnReleases are a forcing function that drives the development team to cl
45、osure at regular intervalsnCan incorporate problems/issues/changes into future iterations rather than disrupting ongoing productionnThe projects supporting elements (testers, writers, QA, etc.) can better schedule their work7.3 The Iterative Development ProcessPage 45RiskTransitionInceptionElaborati
46、onConstructionPreliminaryIterationArchitect.IterationArchitect.IterationDevel. IterationDevel. IterationDevel. IterationTransitionIterationTransitionIterationPost-deploymentWaterfallTimeRisk Profile of an Iterative Development7.3 The Iterative Development ProcessPage 46Risk Management Phase-by-Phase
47、nInceptionBracket the projects risks by building a proof of conceptnElaborationDevelop a common understanding of the systems scope and desired behavior by exploring scenarios with end users and domain expertsEstablish the systems architectureDesign common mechanisms to address system-wide issues7.3
48、The Iterative Development ProcessPage 47Risk Management Phase-by-Phase (cont.)nConstructionRefine the architectureRisk-driven iterationsContinuous integrationnTransitionFacilitate user acceptanceMeasure user satisfactionnPost-deployment cyclesContinue evolutionary approachPreserve architectural inte
49、grity7.3 The Iterative Development ProcessPage 48Initial Project RisksInitial Project ScopeRevise Overall Project Plan Cost Schedule Scope/ContentPlan Iteration N Cost ScheduleAssess Iteration NRisks EliminatedRevise Project Risks ReprioritizeDevelop Iteration N Collect cost and quality metricsDefin
50、e scenarios to address highest risksIteration NRisk Reduction Drives Iterations7.3 The Iterative Development ProcessPage 49InceptionElaborationConstructionTransitionIteration 1Iteration 2Iteration 3Iteration PlanningRqmts Capture Analysis & DesignImplementation Test Prepare Releasemini-Waterfall Pro
