《软件工程》Computer-Science-上.ppt

Computer Science 3061/15/03Bill BondClass CommunicationEmail your name and email address to bondwumr.eduNormally will post notes before classAssignments got to bondwumr.eduWeb page should be in following location:http:/web.umr.edu/umreec/web-courses/Software CrisisPrograms dont reflect customer desiresSchedule and cost estimates are often grossly inaccurate“Productivity”of software people has not kept pace with the demand for their servicesSoftware complexity increasesQuality of software is sometimes less than adequateDifficult to maintain existing programsThe ProblemBuilding computer solution is hardUnderstand problemDesign solutionImplement solutionComplexity is the problemLots to doLots to keep track ofSoftware EngineeringManaging complexity by imposing disciplineAbstraction-focus only on essential details,ignore others(for now)Decomposition-break into manageable piecesAnalysis/Design methods and Tools support these ideasLarge ProjectsRequire TeamsKey elementsCommunication-has costArtifacts-support communicationArtifactsWhich should be produced?“Discovery”valueWhich should be maintained?Maintenance valueRecognize cost of producing artifactsSoftware EngineeringBook definition The establishment and use of sound engineering principles in order to obtain economical software that is reliable and works efficiently on real machinesResultComprehensive methods “how to”Process context in which technical methods applied,deliverables producedBetter toolsMore powerful building blocksBetter quality assuranceCommunicationThree Generic PhasesDefinition phaseWhatInformation to be processedFunction/Performance desiredSystem EngineeringSoftware Project PlanningRequirements AnalysisThree Generic Phases,contDevelopment phase howSoftware architectureImplementationTestingThree Generic Phases,contMaintenance phase changeCorrection defect correctionAdaptation supports new environmentEnhancementPrevention changes to allow correction,adaptation,enhancementCourse DescriptionAll aspects of software engineeringProject managementRequirementsAnalysisDesignImplementationTestingMoreIntroduction to Object-OrientedAnalysis and DesignBill Bond10/16/02Schedule10/16-Background10/23-Exam10/30-Analyze-Use Cases,Domain Model11/6-Design-Collaboration/Design diagrams11/13-Construct-Code11/20-Complete,Begin examples11/27-No class12/4-Examples12/11-Project due,UML Odds and Ends12/18-Final ExamChapter 1-GoalsDescribe ProcessRepeatable,predictable resultsRequirements developmentUse CasesConceptual ModelDesign ModelSequence DiagramsProduce codeGoalsLearn basic set of UMLUnified Modeling LanguageCapture Analysis/DesignCommunicate with other developersApply“good”design principlesPatterns(good design solutions)Work examplesPart of Engineering ProcessEstimatingPlanning/SchedulingConfiguration ManagementChange ControlPeer ReviewsTestingUnified Modeling LanguageIndustry standardRational proposalBooch-Booch diagramsModel diagramsRumbaugh-Object Modeling TechniqueModel diagramsJacobson-ObjectoryProcessUnified Modeling LanguageSet of DiagramsDifferent views of a systemConcentrate on a subsetUse casesSequence/Collaboration diagramsDynamic(Execution)viewConceptual/Design modelStatic view-can produce codeUnified Modeling LanguageDoes not define an approachBut we will-Unified ProcessArtifactsWhat artifacts should be produced?What artifacts should be peer reviewed?What artifacts should be maintained?Design evolves over timeArtifactsRepresent costImproved process repeatabilityImproved design/quality through self-discoveryImproved design/quality through peer reviewWhat Does Customer Want?Reasonable costDelivered on scheduleMeets requirementsHigh qualityAnalysis/DesignAnalysis(what)-Investigation of the problem domain,rather than how the solution is definedDesign(how)-Logical solution,how system fulfills the requirementsAnalysis/DesignAnalysisDesignWhatRequirementsInvestigation of DomainHowLogical solutionFunction-Oriented ApproachDecomposition is primary strategyConstruct a“control”hierarchyControlI/OProcessingOOA/OODConsider problem domain/solution from the perspective of objectsOOA-Find and describe domain(problem space)objectsOOD-Define logical software objects that will be implemented in an Object-Oriented Programming LanguageApproachAssign responsibilities to componentsImportant question(should be able to answer)-What is this component responsible for?What does it do(exactly)?Find suitable objects/abstractionsDomain(Conceptual)model-Representation-CodeIs An Object-Oriented Language Required?NoBusiness ExampleTextual narrative description of business processesExternal actors-cause business to process dataResults produced by interaction between peopleExpectations-what should be the outcome?Use caseBusiness ExamplePeople rolesWhat“categories”of people participate in the domainResponsibilitiesConceptual(domain)modelInteractionsHow collaboration occurs to achieve overall goalsCollaboration(sequence)diagramsChapter 2-Macro ProcessDevelopment Process-Organize software activities for creation,delivery,and maintenanceMacro levelPlan and ElaborateBuildDeployPlan and ElaboratePlan-schedule,resources,budgetPreliminary investigation reportRequirements investigationGlossaryPrototypeUse Cases-textUse Case DiagramsDraft Conceptual ModelUnified ProcessBook describes a simplified version of the Rational Unified ProcessA“typical”OOA/OOD processIterative DevelopmentSuccessive refinement through multiple cycles(adding more functions)ofAnalysisDesignImplementationTestWaterfall-a single cycleIterative DevelopmentEach iteration produces an executable but incomplete systemSystem may not be eligible for production deployment for many iterationsIteration output is not a“throw-away”prototype,it is a production-grade subset of the final systemBenefitsEarly rather than late mitigation of high risks(technical,requirements,usability,etc.)Early visible progressEarly user feedbackManaged complexityDevelopment feedback can be used to update the processWaterfallIterationIterationsTime Boxing-Fixed time iteration cycleChoose iteration requirements carefullyOrganized by Use CasesEach iteration implements a set of use casesAdvantagesIterationsWork ActivitiesUP Best PracticesTackle high-risk,high-value issues earlyContinuously engage usersBuild cohesive,core architecture earlyContinuously verify quality through testModel software visually with UMLCarefully manage requirementsPractice change request and configuration managementChapter 4-InceptionEnvision the product scope,vision,and business caseThe main problem:Do the stakeholders have basic agreement on the vision of the project,and is it worth investing in serious investigation?Chapter 5-RequirementsRequirements are capabilities and conditions to which the system must conformUP RequirementsManage requirements-define and stabilize the requirements-in the context of inevitably changing and unclear stakeholders wishes,a systematic approach to finding,documenting,organizing and tracking the changing requirments of a system“Challenged”ProjectsFURPS+Functional-features,capabilities,securityUsability-human factors,help,documentationReliability-frequency of failure recoverability,predictabilityPerformance-response times,throughput,accuracy,availability,resource usageSupportability-adaptability,maintainability,internationalization,configurabilityThe+Implementation-resource limitations,languages and tools,hardwareInterface-constraints imposed by interfacing with external systemsOperations-system management in its operational settingPackagingLegal-licensing and so forthRequirements DevelopmentGet it written down(shalls)Can be verifiedGet consensus with userNextUse CasesDomain ModelsObject-Oriented Analysis Use Cases,Domain ModelBill Bond10/30/02Chapter 6-Use CasesUse case-Narrative description that describes sequence of events of an actor(external agent)using system to complete a process(documents responses).ActorHumanAnother systemExampleUse case:Buy ItemsActors:Customer,CashierDescription:A customer arrives at a checkout with items to purchase.The cashier records the purchase items and collects payment.On completion,the Customer leaves with the items.Use CaseNo rigid formatAlternative solutionsHandled at endMistake-identify individual steps as a use caseUse case usually includes many stepsActorExternal EntityStimulates systemReceives responseCapitalize to identifyActorInitiator actorParticipating actorsKinds of actorsRoles that people playComputer systemsElectrical or mechanical devicesIdentifying Use CasesActor-basedIdentify actors related to a systemFor each actor,identify the processes they initiate or participate inEvent-basedIdentify the external events that the system must respond toRelate the events to actors and use casesUML NotationTraceabilityFunctions should all be allocated to Use CasesVia cross reference verify all functions have been allocatedSystem BoundaryExamplesHardware/software boundary of device/computer systemDefines systems responsibilitiesDepends on IntentExampleLog InRefundBuy ItemsRefundBuy ItemsPOSTStoreCashierCustomerCustomerUse Case RefinementRealVery concreteDesign detailsUser interfaceEssentialVery abstractWhich best supports testing?NamingStart with verbIt is a processDecisions and BranchingMain:If _,see section X If _,see section YX:Y:Using Use CasesDefine system boundary,actors,use casesWrite use cases in high-level formatDraw Use Case diagramRelate Use CasesFor critical,influential,risky use cases,expand detailRank Use Cases for implementationChapter 7Chapter 8-SchedulingRanking and scheduling Use casesAssuming desired artifacts produced(requirements,use cases),transition to iterative developmentRankingSignificant impact on architectural designSignificant information and insight regarding design,with little effortRisky,time-critical,complexSignificant researchPrimary processesDirectly support increased revenue/decreased cost“Start Up”May not rank highProvides initialization used by other use casesOften“falls out”Chapter 9-System SequenceSystem sequence diagram-for a particular scenario of a use case the events that external actors generate,their orderTime proceeds downwardOrder of events follow use caseConstructionDraw line representing system as black boxIdentify each actor,draw lineFrom use case,identify external events that each actor generates-Illustrate on diagramOptionally include use case textSystem boundary must be clearNaming operations-begin with verbChapter 10-Domain ModelRepresentation of“real-world”thingsStatic structure diagramContentsConceptsAssociations between conceptsAttributes of conceptsTool of communicationNot Software DesignFollowing should not be in modelNo software artifacts-window/databaseNo responsibilities or methodsConceptIdeaThingObjectMay be defined usingSymbol-word representing a conceptIntension-definition of a conceptExtension-set of examples to which the concept appliesApproachDecompose domain into conceptsStrategy to identify conceptsGuideline-better to over specify with many fine-grained concepts,than to under specify itDo not exclude concept because requirements do not indicate any need to“remember”information or it has no attributesUse domain vocabularyConcept Category ListPhysical or tangible objectsSpecifications or descriptions of thingsPlacesTransactionsTransaction line itemsRoles of peopleContainers of other thingsThings in a containerConcept Category ListOther computer or mechanical systems external to our systemOrganizationsEventsProcessesCatalogs,manuals,booksRecords of finance,work,contracts,legal mattersNoun Phrase IdentificationNoun and noun phrases in textual description of problem domainSome may be attributesConstruction of Domain ModelList candidate concepts using Concept Category List,Noun Phrase IdentificationDraw domain modeladd associations necessary to record relationships for which there is a need to preserve some memoryAdd the attributes necessary to fulfill information requirementsExampleConcept or Attribute?If we do not think of some concept as a number or text in the real world,X is probably a concept,not an attributeSpecificationDescription of item,distinct from itemUse specification when:Deleting instances of things results in a loss of informationIt reduces redundant or duplicate informationChapter 11-Adding AssociationsAssociation-relationship between concepts that indicates some meaningful and interacting connectionUML Association NotationGuidelinesFocus on associations for which knowledge of the relationship needs to be preserved for some durationIt is more important to identify concepts than associationsToo many associations tend to confuse domain model rather than illuminate itAvoid showing redundant or derivable associationsCommon Association ListA is a physical part of BA is a logical part of BA is physically contained in BA is logically contained in BA is a description for BA is line item of a transaction/report in BA is known/logged/recorded/reported/captured in BCommon Association ListA is a member of BA is an organizational subunit of BA uses or manages BA communicates with BA is related to a transaction BA is next to BA is owned by BHigh PriorityA is a physical or logical part of BA is physically or logically contained in BA is recorded in BRemove associations not required by requirements,could change with requirementsAssociationEach end of an association is called a roleNameMultiplicity expressionNaming associationsTypeName VerbPhrase TypeNameMultiplicityHow many instances of type A can be associated with one instance of type B*zero or more1.*one or more1.40 one to forty5 exactly five3,5,8 three,five,eightMultiplicityChapter 12-Adding AttributesAttribute-logical data value of an objectPrefer simple attribute typesBooleanDateNumberTextTimeUML Attribute NotationNon Primitive TypesUse non primitive type ifIt is composed of separate sections-phone number,name of personOperations are associated with it,parsing/validation-social security numberHas other attributes-promotional price,start/end dateQuantity with unit-unit of currencyExampleChapter 13-ContractsContract-document that describes what an operation commits to achieve,emphasizes what will happen(not how),common to express pre-and post-condition state changesSystem operation contract-changes in overall system when operation is invokedConstructionIdentify system operations from system sequence diagramsFor each operation,construct a contractWrite responsibilities section firstComplete post-conditions section describing state changesInstance creation and deletionAttribute modificationAssociations formaed and brokenChapter 14-Analysis To DesignAnalysis-WhatChapter 14-Analysis To DesignAnalysis-WhatArtifactUse CasesDomain modelSystem Sequence DiagramsContractsAnsweredWhat are domain processes?What are concepts,terms?What are system events and operations?What do the system operations do?Next WeekObject-Oriented DesignCollaboration/Design Diagrams