軟件需求分析英文課件：Chap 5(2) - Object Oriented Design

1、Chapter 5(2) Object Oriented Design 5.1 OO Design Overview 5.2 Architectural Design 5.3 Use Case Design 5.4 Subsystem Design 5.5 Class DesignUse Case Design5.3 Use Case Design Use Case Design Overview Use Case Design StepsUse-Case Design OverviewSupplementarySpecificationsUse-CaseDesignUse-Case Real

2、izationUse-Case Realization(Refined)Design Subsystems and Interfacesuse-caseUse Case Design - Purpose To refine use-case realizations in terms of interactions To refine requirements on the operations of design classes To refine requirements on the operations of subsystems and/or their interfaces.Use

3、-Case Design StepsDescribe interaction between design objectsSimplify sequence diagrams using subsystemsDescribe persistence related behaviorRefine the flow of events descriptionUnify classes and subsystemsUse-Case Design StepsDescribe interaction among design objectsSimplify sequence diagrams using

4、 subsystemsDescribe persistence-related behaviorRefine the flow of events descriptionUnify classes and subsystemsReview: Use-Case RealizationClass DiagramsUse CaseCommunication DiagramsUse-Case ModelDesign ModelUse CaseUse-Case RealizationSequence DiagramsFrom Analysis Classes to Design ElementsClas

5、s DiagramsUse-Case Realization RefinementIdentify participating objectsAllocate responsibilities among objectsModel messages between objectsDescribe processing resulting from messagesModel associated class relationshipsSequence DiagramsIdentify each object that participates in the flow of the use ca

6、seRepresent each participating object in a sequence diagramIncrementally incorporate applicable architectural mechanismsUse-Case Realization Refinement StepsRepresenting Subsystems on a Sequence DiagramInterfacesRepresent any model element that realizes the interfaceNo message should be drawn from t

7、he interfaceProxy classRepresents a specific subsystemMessages can be drawn from the subsystemExample: Incorporating Subsystem InterfacesExample: Incorporating Subsystems (Before)Example: Incorporating Subsystems (After)Example: Incorporating Subsystem Interfaces (VOPC)Analysis ClassAnalysis Mechani

8、sm(s)StudentCourseOfferingCourseRegistrationControllerPersistency, SecurityPersistency, Legacy InterfacePersistency, Legacy InterfaceDistributionIncorporating Architectural Mechanisms: SecurityAnalysis Class to Architectural-Mechanism Map from Use-Case AnalysisSchedulePersistency, SecurityUse-Case D

9、esign StepsDescribe interaction among design objectsSimplify sequence diagrams using subsystemsDescribe persistence-related behaviorRefine the flow of events descriptionUnify classes and subsystemsRaises the level of abstraction.Encapsulating Subsystem InteractionsInteractions can be described at se

10、veral levelsSubsystem interactions can be described in their own interaction diagramsInterfaceAMySubsystemop1()Guidelines: Encapsulating Subsystem InteractionsSubsystems should be represented by their interfaces on interaction diagramsMessages to subsystems are modeled as messages to the subsystem i

11、nterfaceMessages to subsystems correspond to operations of the subsystem interfaceInteractions within subsystems are modeled in Subsystem Design:InterfaceAUse-Case Design StepsDescribe interaction among design objectsSimplify sequence diagrams using subsystemsDescribe persistence-related behaviorRef

12、ine the flow of events descriptionUnify classes and subsystemsDescribe Persistence-Related Behavior Use-Case Design Steps: Describe Persistence-Related Behavior Reading Persistent ObjectsDeleting Persistent ObjectsModeling TransactionsWriting Persistent ObjectsModeling TransactionsWhat is a transact

13、ion?Atomic operation invocations“All or nothing”Provide consistencyModeling optionsTextually (scripts)Explicit messagesError conditionsRollbackFailure modesMay require separate interaction diagramsAnalysis ClassAnalysis Mechanism(s)StudentCourseOfferingCourseRegistrationControllerPersistency, Securi

14、tyPersistency, Legacy InterfacePersistency, Legacy InterfaceDistributionIncorporating the Architectural Mechanisms: PersistencyAnalysis-Class-to-Architectural-Mechanism Map from Use-Case AnalysisSchedulePersistency, SecurityLegacy persistency (RDBMS ) is deferred to Subsystem Design.OODBMS Persisten

15、cyRDBMS PersistencyUse-Case Design StepsDescribe interaction among design objectsSimplify sequence diagrams using subsystemsDescribe persistence-related behaviorRefine the flow of events descriptionUnify classes and subsystemsDetailed Flow of Events Description OptionsAnnotate the interaction diagra

16、ms : Actor1 : ClassA : ClassB1: Do Something2: Do Something MoreScripts can be used to describe the details surrounding these messages. Notes can include more information about a particular diagram element ScriptNoteUse-Case Design StepsDescribe interaction among design objectsSimplify sequence diag

17、rams using subsystemsDescribe persistence-related behaviorRefine the flow of events descriptionUnify classes and subsystemsModel element names should describe their functionMerge similar model elementsUse inheritance to abstract model elementsKeep model elements and flows of events consistentDesign

18、Model Unification ConsiderationsSubsystem Design5.4 Subsystem Design StepsSubsystem Design OverviewSubsystem GuidelinesSubsystem Design StepsSubsystem Design OverviewSubsystemDesignUse-Case RealizationUse-Case Realization(updated)Design Subsystems and InterfacesDesign Subsystems and Interfaces(updat

19、ed)DesignGuidelinesSubsystem Design - Purpose To define the behaviors specified in the subsystems interfaces in terms of collaborations of contained classes To document the internal structure of the subsystem To define realizations between the subsystems interfaces and contained classes To determine

20、 the dependencies upon other subsystems A Subsystem:Is a “cross between” a package and a classRealizes one or more interfaces which define its behaviorSubsystem NameInterfaceSubsystemSubsystem NameInterfaceRealization (Canonical form)Realization (Elided form)InterfaceReview: Subsystems and Interface

21、sKey is abstraction and encapsulationABCSubsystem GuidelinesGoalsLoose coupling Portability, plug-and-play compatibility Insulation from change Independent evolutionStrong SuggestionsDont expose details, only interfacesOnly depend on other interfacesReview: Modeling Convention for Subsystems and Int

22、erfacesCourseCatalogSystemICourseCatalogSystemICourseCatalogSystemCourseCatalogSystemCourseCatalogSystemInterfaces start with an “I” package classSubsystem Design StepsDistribute subsystem behavior to subsystem elementsDocument subsystem elementsDescribe subsystem dependenciesCourseCatalogSystemICou

23、rseCatalogSystemgetCourseOfferings()subsystem responsibilitySubsystem ResponsibilitiesSubsystem responsibilities defined by interface operationsModel interface realizationsInterface operations may be realized byInternal class operationsInternal subsystem operationsDistributing Subsystem Responsibili

24、tiesIdentify new, or reuse existing, design elements (e.g., classes and/or subsystems)Allocate subsystem responsibilities to design elements Incorporate applicable mechanisms (e.g., persistence, distribution, etc.)Document design element collaborations in “interface realizations”O(jiān)ne or more interact

25、ion diagrams per interface operationClass diagram(s) containing the required design element relationshipsRevisit “Identify Design Elements”Adjust subsystem boundaries and/or dependencies, as neededInternal subsystem interactionsSubsystem responsibilitySubsystem Interaction Diagrams: Client Subsystem

26、:Supplier SubsystemperformResponsibility( )Black box view of subsystemsModeling Convention: Subsystem Interaction DiagramsExample: CourseCatalogSystem Subsystem in ContextAnalysis ClassAnalysis Mechanism(s)StudentCourseOfferingCourseRegistrationControllerPersistency, SecurityPersistency, Legacy Inte

27、rfacePersistency, Legacy InterfaceDistributionIncorporating the Architectural Mechanisms: PersistencyAnalysis-Class-to-Architectural-Mechanism Map from Use-Case AnalysisSchedulePersistency, SecurityOODBMS Persistency was discussed in Use-Case DesignOODBMS PersistencyRDBMS PersistencyProvide access t

28、o the class libraries needed to implement JDBC Provide java.sql packageCreate the necessary DBClassesOne DBClass per persistent classCourse Offering persistent class = DBCourseOfferingReview: Incorporating JDBC: Steps = DoneIncorporate DBClasses into the designAllocate to package/layerDBCourseOfferi

29、ng placed in CourseCatalogSystem subsystemAdd relationships from persistency clientsPersistency clients are the CourseCatalogSystem subsystem clientsCreate/Update interaction diagrams that describe:Database initializationPersistent class access: Create, Read, Update, DeleteReview: Incorporating JDBC

30、: Steps (continued)Review : Persistency: RDBMS: JDBC: Read : PersistentClass : Connection : Statement : ResultSet : PersistencyClient : DBClass : PersistentClassList1. read(string)1.1. createStatement( )1.2. executeQuery(string)1.4. new()1.5. getString( )1.6. setData( )Returns a Statement1.3. new( )

31、Create a list to hold all retrieved data1.7. add(PersistentClass)The SQL statement built by the DBClass using the given criteria is passed to executeQuery()The criteria used to access data for the persistent class for each class from execute queryfor each attribute in classExample: Local CourseCatal

32、ogSystem Subsystem InteractionpersistentClass: CourseOffering: Connection: Statement: ResultSetpersistencyClient :CourseCatalogSystemdbClass :DBCourseOfferingpersistentClassList: CourseOfferingList : Course CatalogrefJDBC Read/executeQuery()getCourseOffering()SubsystemExample: Billing System Subsyst

33、em In ContextExample: Local BillingSystem Subsystem InteractionExample: CourseCatalogSystem Subsystem ElementsExample: Billing System Subsystem ElementsSubsystem dependency on a subsystemSubsystem dependency on a packageSubsystem Dependencies: GuidelinesFlexible, PreferredServerClient SupportServer

34、SupportUse with careClient SupportSupportingTypesExample: CourseCatalogSystem Subsystem DependenciesExample: BillingSystem Subsystem DependenciesClass Design5.5 Class Design Create Initial Design ClassesDefine OperationsDefine MethodsDefine StatesDefine AttributesDefine DependenciesDefine Associatio

35、nsDefine GeneralizationResolve Use-Case CollisionsHandle Non-Functional Requirements in GeneralClass Design ConsiderationsClass stereotypeBoundaryEntityControlApplicable design patternsArchitectural mechanismsPersistenceDistributionetc.A class should have a single well focused purpose. A class shoul

36、d do one thing and do it well!How Many Classes Are Needed?Many, simple classes means that each class Encapsulates less of the overall system intelligenceIs more reusableIs easier to implementA few, complex classes means that each classEncapsulates a large portion of the overall system intelligenceIs

37、 less likely to be reusableIs more difficult to implementMainFormSubWindowDropDownListButtonMainWindowStrategies for Designing Boundary ClassesUser interface (UI) boundary classesWhat user interface development tools will be used?How much of the interface can be created by the development tool?Exter

38、nal system interface boundary classesUsually model as subsystemAnalysisFatClassLazyDataHelper- rarelyUsedAtt3- rarelyUsedAtt4DesignFatClass- transientBookeeping+ getCommonlyUsedAtt1()+ getCommonlyUsedAtt2()+ getRarelyUsedAtt3()+ getRarelyUsedAtt4()FatClassDataHelper- commonlyUsedAtt1- commonlyUsedAt

39、t211FatClass- transientBookeeping- commonlyUsedAtt1- commonlyUsedAtt2- rarelyUsedAtt3- rarelyUsedAtt4Strategies for Designing Entity ClassesEntity objects are often passive and persistentPerformance requirements may force some re-factoringSee Identify Persistent Classes stepStrategies for Designing

40、Control ClassesWhat happens to Control Classes?Are they really needed?Should they be split?How do you decide?ComplexityChange probabilityDistribution and performanceTransaction managementMessages displayed in interaction diagramsOther implementation dependent functionality Manager functionsNeed for

41、class copiesNeed to test for equality:ClassA/ Perform responsibility:ClassB:ClassAperformResponsibility():result:ClassBOperations: Where Do You Find Them?Name and Describe the OperationsAppropriate operation namesIndicate the outcomeUse client perspectiveConsistent across classesDefine operation sig

42、naturesoperationName(parameter : class,.) : returnTypeProvide short description, including meaning of all parametersGuidelines: Designing Operation SignaturesWhen designing operation signatures, consider if parameters are:Passed by-value or by-reference?Changed by the operation?Optional?Set to defau

43、lt values?In valid parameter ranges?The fewer the parameters, the betterPass objects instead of “data bits”Public operationsProtected operationsPrivate operationsOperation VisibilityVisibility is used to enforce encapsulationMay be public, protected, or private- privateAttributeClass# protectedAttri

44、bute+publicOp()# protectedOp()- privateOp()How Is Visibility Noted?The following symbols are used to specify export control: +Public access #Protected access -Private accessClass- classifierScopeAttributeclassifierScopeOperation()- instanceScopeAttributeinstanceScopeOperation()ScopeDetermines number

45、 of instances of the attribute/operationInstance: one instance for each class instanceClassifier: one instance for all class instancesClassifier scope is denoted by underlining the attribute/operation nameExample: ScopeStudent- name- address- nextAvailID : int+ addSchedule(theSchedule : Schedule, fo

46、rSemester : Semester)+ getSchedule(forSemester : Semester) : Schedule+ hasPrerequisites(forCourseOffering : CourseOffering) : boolean# passed(theCourseOffering : CourseOffering) : boolean+ getNextAvailID() : int- studentIDExample: Define OperationsCourseOffering(from University Artifacts)Student.+ g

47、etTuition() : double+ addSchedule(theSchedule : Schedule)+ getSchedule(forSemester : Semester) : Schedule+ deleteSchedule(forSemester : Semester)+ hasPrerequisites(forCourseOffering : CourseOffering) : boolean# passed(theCourseOffering : CourseOffering) : boolean + getNextAvailID() : int+ getStudent

48、ID() : int+ getName() : string+ getAddress() : string(from University Artifacts)RegistrationController+ submitSchedule()+ saveSchedule()+ getCourseOfferings() : CourseOfferingList+ getCurrentSchedule(forStudent : Student, forSemester : Semester) : Schedule+ deleteCurrentSchedule() + new(forStudent :

49、 string)+ getStudent(withID : string) : Student(from Registration)Schedule(from University Artifacts)0.10.1+registrant0.*10.10.1+currentSchedule0.*0.*+primaryCourses0.4+alternateCourses0.2ICourseCatalogSystem+ getCourseOfferings()+ initialize()(from External System Interfaces)10.*Define MethodsWhat

50、is a method?Describes operation implementationPurposeDefine special aspects of operation implementation Things to consider :Special algorithmsOther objects and operations to be usedHow attributes and parameters are to be implemented and usedHow relationships are to be implemented and usedDefine Stat

51、esPurposeDesign how an objects state affects its behaviorDevelop statecharts to model this behaviorThings to consider :Which objects have significant state?How to determine an objects possible states? How do statecharts map to the rest of the model? State NamestateVar : type = valueentry/ entry acti

52、ondo/ activityexit/ exit actionevent(args) guard condition / operation(args) target.sendEvent(args) StateEventTransitionActionActivityWhat is a Statechart?A directed graph of states (nodes) connected by transitions(directed arcs)Describes the life history of a reactive objectInitial state The state

53、entered when an object is createdMandatoryCan only have one initial state Final state Indicates the objects end of life OptionalMay have more than oneFinal stateInitial stateSpecial StatesSignificant, dynamic attributesExistence and non-existence of certain linksnumStudents = 10ClosedAssignedUnassig

54、nedLink to ProfessorExistsLink to ProfessorDoesnt ExistProfessorCourseOffering0.*0.1Identify and Define the States+instructorCourseOffering+ addProfessor()+ removeProfessor()Professor0.10.*Events: addProfessor, removeProfessorIdentify the EventsLook at the class interface operationsUnassignedAssigne

55、dremoveProfessoraddProfessorIdentify the TransitionsFor each state, determine what events cause transitions to what states, including guard conditions, when neededTransitions describe what happens in response to the receipt of an eventCourseOffering+ addProfessor()+ removeProfessor()0.*+instructorPr

56、ofessor0.1ActivitiesAssociated with a stateStart when the state is enteredTake time to complete InterruptibleActionsAssociated with a transitionTake an insignificant amount of time to complete Non-interruptibleState AState Bdo: activityevent condition / actionState Cactivityactionentry: actionAdd Ac

57、tivities and ActionsExample: Statechartadd student / numStudents = numStudents + 1UnassignedAssignedFullCancelleddo: Send cancellation noticesCommitteddo: Generate class rostercloseRegistration has Professor assigned close / numStudents = 0addProfessorcloseRegistrationremove student / numStudents =

58、numStudents - 1cancelremoveProfessor numStudents = 10 close numStudents = 3 close numStudents = 3 add student /numStudents = numStudents + 1cancelremove student / numStudents = numStudents - 1close numStudents = 10 cancelExample: Statechart With Nested States and Historysuperstatesubstateadd student

59、 /numStudents = numStudents + 1OpenUnassignedAssignedHadd a professorClosedCancelleddo: Send cancellation noticesFullCommitteddo: Generate class rostercloseRegistrationcloseremove a professorclose numStudents = 3 close numStudents = 3 closeRegistration has Professor assigned close / numStudents = 0r

60、emove student / numStudents = numStudents - 1cancelcancelWhich Objects Have Significant State?Objects whose role is clarified by state transitionsComplex use cases that are state-controlledIt is not necessary to model all objectsObjects with straightforward mapping to implementationObjects that are