《軟件工程》Computer Science 上ppt課件

1、Computer Science 3061/15/03Bill BondClass Communication Email your name and email address to Normally will post notes before class Assignments got to Web page should be in following location: /umreec/web-courses/Software Crisis Programs dont reflect custome

2、r desires Schedule and cost estimates are often grossly inaccurate “Productivity” of software people has not kept pace with the demand for their services Software complexity increases Quality of software is sometimes less than adequate Difficult to maintain existing programsThe Problem Building comp

3、uter solution is hard Understand problem Design solution Implement solution Complexity is the problem Lots to do Lots to keep track ofSoftware Engineering Managing complexity by imposing discipline Abstraction - focus only on essential details, ignore others (for now) Decomposition - break into mana

4、geable pieces Analysis/Design methods and Tools support these ideasLarge Projects Require Teams Key elements Communication - has cost Artifacts - support communicationArtifacts Which should be produced? “Discovery” value Which should be maintained? Maintenance value Recognize cost of producing artif

5、actsSoftware Engineering Book definition The establishment and use of sound engineering principles in order to obtain economical software that is reliable and works efficiently on real machinesResult Comprehensive methods “how to” Process context in which technical methods applied, deliverables prod

6、uced Better tools More powerful building blocks Better quality assurance CommunicationThree Generic Phases Definition phase What Information to be processed Function/Performance desired System Engineering Software Project Planning Requirements AnalysisThree Generic Phases, cont Development phase how

7、 Software architecture Implementation TestingThree Generic Phases, cont Maintenance phase change Correction defect correction Adaptation supports new environment Enhancement Prevention changes to allow correction, adaptation, enhancementCourse Description All aspects of software engineering Project

8、management Requirements Analysis Design Implementation Testing MoreIntroduction to Object-OrientedAnalysis and DesignBill Bond10/16/02Schedule 10/16 - Background 10/23 - Exam 10/30 - Analyze - Use Cases, Domain Model 11/6 - Design - Collaboration / Design diagrams 11/13 - Construct - Code 11/20 - Co

9、mplete, Begin examples 11/27 - No class 12/4 - Examples 12/11 - Project due, UML Odds and Ends 12/18 - Final ExamChapter 1 - Goals Describe Process Repeatable, predictable results Requirements development Use Cases Conceptual Model Design Model Sequence Diagrams Produce codeGoals Learn basic set of

10、UML Unified Modeling Language Capture Analysis/Design Communicate with other developers Apply “good” design principles Patterns (good design solutions) Work examplesPart of Engineering Process Estimating Planning/Scheduling Configuration Management Change Control Peer Reviews TestingUnified Modeling

11、 Language Industry standard Rational proposal Booch - Booch diagrams Model diagrams Rumbaugh - Object Modeling Technique Model diagrams Jacobson - Objectory ProcessUnified Modeling Language Set of Diagrams Different views of a system Concentrate on a subset Use cases Sequence / Collaboration diagram

12、s Dynamic (Execution) view Conceptual / Design model Static view - can produce codeSequence DiagramCollaboration DiagramanX : ClassXp1 : Person1 : message1(anX)2 color=red : message2()firstMessage()id-4 : ClasslistOfTofu : Tofu3 * : w := getWeight(): Weightdomain:ClassXmyRunner : Runnable.11More Cla

13、ss Diagram Notationparameterizedclass (template)iteration across allelements of a collectioninterfaceRunnablerun()home package of classmap.get( KEY_TYPE ) : VAL_TYPEput( KEY_TYPE, VAL_TYPE )KEY_TYPE,VAL_TYPEmapnavigabilitythreadClassYmyThread : Thread.run().active class active psa : LocalProductsext

14、ernalService :DBProductsAdapterinitialize()run()psa := getProductsAdapter()create()create( externalService )A: products :=getProductUpdates()* forever/ activation is on its own thread loop forever: -sleep N minutes -ask for product updates active object that implementsseveral interfacesIn Java (as a

15、nexample), run to aRunnable may beconsidered anasynchronousmessage. These areillustrated with astick arrowhead.When methods run on a different thread, thesequence expression can start with a name orletter indicating the thread. All messages runningon the LocalProducts thread will start with A,for ex

16、ample.pc:ProductCatalogsingleton:ServicesFactoryvisibility viaSingleton designpattern*: SystementerItem(id, quantity).Process Sale1. Customerarrives .2. Cashiermakes newsale.3. .Use CasesSystem Sequence DiagramsmakeNewSale()SaletimeStampRegister.11ProductCatalog. . .domain conceptssystemeventsDomain

17、 ModelUse-Case ModelDesign Model: RegisterenterItem(id, quantity): ProductCatalogspec := getSpecification( id )addLineItem( spec, quantity ): Sale. . .use-caserealization withinteractiondiagramsconceptualclasses inthedomaininspire thenames ofsomesoftwareclasses inthe designmakeNewSale()create()Regis

18、ter.makeNewSale()enterItem(.).ProductCatalog.getSpecification(.) : ProductSpecification.the designclassesdiscoveredwhile designingUCRs can besummarized inclass diagramsCashierProcessSaleUse Case Diagrams: Cashier11. . . . .Captured-onInterfaceXUse Case DiagramMethodsNotSpecifiedbar : int.AbstractCla

19、ssX.interfaceInterfaceXoperation1()Class DiagramClassAClassBAssociation-name role-1role-211zero ormore;manyone ormoreone tofortyexactlyfiveClassClassClassClass*1.*1.405WholePart1*AssociationClassCompositionMultiplicity:Associations:Sample UML NotationNote: A UML class maybe used to model either doma

20、inconcepts or software classes.NextGen POSincludeactorCreditAuthorizationServiceHandle CreditPaymentProcess SaleExtension Points:PaymentVIP CustomerextendPayment, if Customerpresents a gift certificateHandle Gift CertificatePaymentCashierClassXclassAttribute+ publicAttribute- privateAttributeattribu

21、teWithVisibilityUnspecifiedattribute1 : typeburgers : List of VeggieBurgerattribute2 : type = initial valuefinalConstantAttribute : int = 5 frozen /derivedAttributeclassMethod()+ constructor ClassX(int)signal CaughtException1()methodWithVisibilityUnspecified()methodReturnsSomething() : FooabstractMe

22、thod()abstractMethod2() abstract / alternate+ publicMethod()- privateMethod()# protectedMethod() packageVisibleMethod()finalMethod() leaf methodWithoutSideEffects() query synchronizedMethod() guarded method1WithParms(in parm1:String, inout parm2:int)method2WithParms(parm1:String, parm2:float)method3

23、WithParms(parm1, parm2)method4WithParms(String, int)methodWithParmsAndReturn(parm1: String) : FoomethodWithParmsButUnspecified(.) : FoomethodWithParmsAndReturnBothUnspecified()exceptionsThrownException1AttributesNotSpecifiedfoo().NoAttributesfoo()AttributesButNotSpecified.foo()AlternateUMLForAbstrac

24、tClassabstract.ClassYoperation1().generalizationinterfaceimplementationAlternateUMLForImplOfInterfaceXoperation1()FinalClassleaf.Unified Modeling Language Does not define an approach But we will - Unified ProcessGlossarySoftwareArchitecture Doc.DomainModelRequirementsProjectManagementBusinessModelin

25、gDesignSample UP ArtifactsPartial artifacts,refined in eachiteration.TestTestPlanSoftwareDev. Plan. . .Use-Case Modeltextusecases:Systemfoo( x )systemoperationcontractssystemsequencediagramssystemevents &datasystemoperationsdesign objectsto handle thesystem eventsparameter orreturn data may beel

26、aborated in theGlossaryDesign Modelbar( y )EnvironmentDevelopmentCaseArtifacts What artifacts should be produced? What artifacts should be peer reviewed? What artifacts should be maintained? Design evolves over timeArtifacts Represent cost Improved process repeatability Improved design / quality thr

27、ough self-discovery Improved design / quality through peer reviewWhat Does Customer Want? Reasonable cost Delivered on schedule Meets requirements High qualityAnalysis / Design Analysis (what) - Investigation of the problem domain, rather than how the solution is defined Design (how) - Logical solut

28、ion, how system fulfills the requirementsAnalysis / DesignAnalysisDesignWhatRequirementsInvestigation of DomainHowLogical solutionFunction-Oriented Approach Decomposition is primary strategy Construct a “control” hierarchyControlI/OProcessingOOA /OOD Consider problem domain /solution from the perspe

29、ctive of objects OOA - Find and describe domain (problem space) objects OOD - Define logical software objects that will be implemented in an Object-Oriented Programming LanguageApproach Assign responsibilities to components Important question (should be able to answer) - What is this component respo

30、nsible for? What does it do (exactly)? Find suitable objects / abstractions Domain (Conceptual) model - Representation - CodeIs An Object-Oriented Language Required? NoBusiness Example Textual narrative description of business processes External actors - cause business to process data Results produc

31、ed by interaction between people Expectations - what should be the outcome? Use caseBusiness Example People roles What “categories” of people participate in the domain Responsibilities Conceptual (domain) model Interactions How collaboration occurs to achieve overall goals Collaboration (sequence) d

32、iagramsChapter 2 - Macro Process Development Process - Organize software activities for creation, delivery, and maintenance Macro level Plan and Elaborate Build DeployPlan and Elaborate Plan - schedule, resources, budget Preliminary investigation report Requirements investigation Glossary Prototype

33、Use Cases - text Use Case Diagrams Draft Conceptual ModelUnified Process Book describes a simplified version of the Rational Unified Process A “typical” OOA / OOD processIterative Development Successive refinement through multiple cycles (adding more functions) of Analysis Design Implementation Test

34、 Waterfall - a single cycleIterative Development Each iteration produces an executable but incomplete system System may not be eligible for production deployment for many iterations Iteration output is not a “throw-away” prototype, it is a production-grade subset of the final systemBenefits Early ra

35、ther than late mitigation of high risks (technical, requirements, usability, etc.) Early visible progress Early user feedback Managed complexity Development feedback can be used to update the processWaterfallIn a waterfall lifecycle,high risk issues such asintegration and load testmay be tackled lat

36、e.TimePotentialimpact ofrisks beingtackledRequirementsAnalysisDesignImplementIntegrate &System TestIterationIn an iterative lifecycle,high-risk issues aretackled early, to drivedown the riskiest projectelements.TimePotentialimpact ofrisks beingtackledIterationIterations Time Boxing - Fixed time

37、iteration cycle Choose iteration requirements carefully Organized by Use Cases Each iteration implements a set of use casesAdvantagesEarly iterations are farther from the truepath of the system. Via feedback andadaptation, the system converges towardsthe most appropriate requirements anddesign.In la

38、te iterations, a significant change inrequirements is rare, but can occur. Suchlate changes may give an organization acompetitive business advantage.one iteration of design,implement, integrate, and testIterationsRequirementsDesignImplementation &Test & Integration& More DesignFinal Inte

39、gration& System TestRequirementsDesign4 weeks (for example)The system growsincrementally.Feedback fromiteration N leads torefinement andadaptation of therequirements anddesign in iterationN+1.Iterations are fixed inlength, or timeboxed.TimeImplementation &Test & Integration& More Des

40、ignFinal Integration& System TestWork ActivitiesIterationsSample Disciplines(Workflows)RequirementsDesignImplementationTestNote that although aniteration includes workin most disciplines, therelative effort andemphasis change overtime.A four-week iteration (for example).A mini-project that inclu

41、des work in mostdisciplines, ending in a stable executable.UP Best Practices Tackle high-risk, high-value issues early Continuously engage users Build cohesive, core architecture early Continuously verify quality through test Model software visually with UML Carefully manage requirements Practice ch

42、ange request and configuration managementChapter 4 - Inception Envision the product scope, vision, and business case The main problem: Do the stakeholders have basic agreement on the vision of the project, and is it worth investing in serious investigation?Chapter 5 - Requirements Requirements are c

43、apabilities and conditions to which the system must conformUP Requirements Manage 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 requirme

44、nts of a system“Challenged” ProjectsPoor user input13%Changing requirements12%Poor technical skills7%Poor staffing6%Other50%Incomplete requirements12%FURPS+ Functional - features, capabilities, security Usability - human factors, help, documentation Reliability - frequency of failure recoverability,

45、 predictability Performance - response times, throughput, accuracy, availability, resource usage Supportability - adaptability, maintainability, internationalization, configurabilityThe + Implementation - resource limitations, languages and tools, hardware Interface - constraints imposed by interfac

46、ing with external systems Operations - system management in its operational setting Packaging Legal - licensing and so forthRequirements Development Get it written down (shalls) Can be verified Get consensus with userNext Use Cases Domain ModelsObject-Oriented Analysis Use Cases, Domain ModelBill Bo

47、nd10/30/02Chapter 6 - Use Cases Use case - Narrative description that describes sequence of events of an actor (external agent) using system to complete a process (documents responses). Actor Human Another systemExample Use case: Buy Items Actors: Customer, Cashier Description: A customer arrives at

48、 a checkout with items to purchase. The cashier records the purchase items and collects payment. On completion, the Customer leaves with the items.Use Case No rigid format Alternative solutions Handled at end Mistake -identify individual steps as a use case Use case usually includes many stepsActor

49、External Entity Stimulates system Receives response Capitalize to identifyActor Initiator actor Participating actors Kinds of actors Roles that people play Computer systems Electrical or mechanical devicesIdentifying Use Cases Actor-based Identify actors related to a system For each actor, identify

50、the processes they initiate or participate in Event-based Identify the external events that the system must respond to Relate the events to actors and use casesUML NotationNextGenProcess Sale. . .CashierShow computer system actorswith an alternate notation tohuman actors.primary actors onthe leftsup

51、porting actorson the rightFor a use case contextdiagram, limit the use cases touser-goal level use cases.actorPaymentAuthorizationServiceTraceability Functions should all be allocated to Use Cases Via cross reference verify all functions have been allocatedNextGenManage Users. . .CashierSystemAdmini

52、stratoractoruse casecommunicationsystem boundaryHandle ReturnsPaymentAuthorizationServiceactorTax CalculatoractorAccountingSystemalternatenotation fora computersystem actorProcess RentalactorHR SystemCash InProcess SaleactorSales ActivitySystemManage SecurityAnalyze ActivitySystem Boundary Examples

53、Hardware/software boundary of device/computer system Defines systems responsibilities Depends on IntentExampleLog InRefundBuy ItemsRefundBuy ItemsPOSTStoreCashierCustomerCustomerUse Case RefinementRealVery concreteDesign detailsUser interfaceEssentialVery abstractWhich best supports testing?Naming S

54、tart with verb It is a processDecisions and Branching Main: If _, see section X If _, see section Y X: Y: Using Use Cases Define system boundary, actors, use cases Write use cases in high-level format Draw Use Case diagram Relate Use Cases For critical, influential, risky use cases, expand detail Ra

55、nk Use Cases for implementationChapter 7Chapter 8 - Scheduling Ranking and scheduling Use cases Assuming desired artifacts produced (requirements, use cases), transition to iterative developmentRanking Significant impact on architectural design Significant information and insight regarding design, w

56、ith little effort Risky, time-critical, complex Significant research Primary processes Directly support increased revenue / decreased cost“Start Up” May not rank high Provides initialization used by other use cases Often “falls out”Chapter 9 - System Sequence System sequence diagram - for a particul

57、ar scenario of a use case the events that external actors generate, their order Time proceeds downward Order of events follow use caseenterItem(itemID, quantity):System: CashierendSale()makePayment(amount)box may enlose aniteration areathe * . is an iterationmarker and clauseindicating the box is fo

58、riterationexternal actor tosystemProcess Sale Scenariosystem as black boxthe name could be NextGenPOS but System keeps it simplethe : and underline imply an instance, and are explained in alater chapter on sequence diagram notation in the UMLa message withparametersit is an abstractionrepresenting t

59、hesystem event ofentering thepayment data bysome mechanismdescription, totalreturn value(s)associated with theprevious messagean abstraction thatignores presentationand mediumthe return line isoptional if nothing isreturnedtotal with taxeschange due, receipt* more itemsmakeNewSale()Construction Draw

60、 line representing system as black box Identify each actor, draw line From use case, identify external events that each actor generates - Illustrate on diagram Optionally include use case text System boundary must be clear Naming operations - begin with verbenterItem(itemID, quantity): CashierendSale()makePayment(amount)system boundar