Kĩ thuật lập trình - Lecture 1: Introduction

Complex  complicated Complex = composed of many simple parts related to one another Complicated = not well understood, or explained

ppt42 trang | Chia sẻ: thuychi16 | Lượt xem: 852 | Lượt tải: 0download
Bạn đang xem trước 20 trang tài liệu Kĩ thuật lập trình - Lecture 1: Introduction, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
Ivan MarsicRutgers UniversityLECTURE 1: IntroductionLecture time: 1 hr. 20 min.Course InformationWeb: Notes: (see more on the course website)Bruegge & Dutoit: Object-Oriented Software Engineering: Using UML, Patterns and Java, Third Edition, Prentice Hall, 2010. | ISBN 0-13-6061257Miles & Hamilton: Learning UML 2.0, O’Reilly Media, 2006. ISBN: 0-596-00982-8Teaching Assistant: Swapnil Mhaske *Team ProjectsForm teams of 6 (± 1?) students DEADLINE: Friday, January 25, 2013 After that, teams assigned randomlyProject Ideas: more than two (2) groups working on the same projectOne (1) new project allowedEmail your project idea ASAP, before proposal is due, for feedback*Personal Health Monitoring Devices*Available budget:$500To do:1. Search the Web for devices and apps that you would like to work with2. Email the components list with costs+websitesProject Deliverables*ItemDue dateI t e r a t. #1 1.   Proposal January 29 2.   First report   (Specification only)       • Part 1 (Statement of Work & Requirements)       • Part 2 (Functional Requirements Spec & UI)       • Full Report #1   February 12 February 18 February 22 3.   Second report   (Design only)       • Part 1 (Interaction Diagrams)       • Part 2 (Class Diagram and System Architecture)       • Full Report #2   March 1 March 8 March 15 4.   First demo April 2 ► ... I t e r #25.   Third report   (All reports collated) April 27 6.   Second demo May 1 ► ... 7.   Electronic Project Archive May 3 Team Project Grading35pts26pts12 p100Team 321 p50 pts70Team 230pts100Team 130pts30ptsEarned pointsProject grade21 ptsTeamProject gradeMember IDEarned pointsAdjusted pointsNormalized pointsT1100%M1,13030(30/35 * 100) = 86M1,23030(30/35 * 100) = 86M1,33030(30/35 * 100) = 86T270%M2,121(21 * 0.7) = 14.7(14.7/35 * 100) = 42M2,250(50 * 0.7) = 35100T3100%M3,12121(19/35 * 100) = 60M3,21212(12/35 * 100) = 34M3,33535100M3,42626(26/35 * 100) = 74Introduction: Software is ComplexComplex  complicatedComplex = composed of many simple parts related to one anotherComplicated = not well understood, or explainedComplexity Example: Scheduling Fence Construction TasksSetting posts[ 3 time units ]Cutting wood[ 2 time units ]Painting[ 5 time units for uncut wood;4 time units otherwise ]Nailing[ 2 time units for unpainted;3 time units otherwise ]Setting posts  Nailing, PaintingCutting  Nailingshortest possible completion time = ?*[  “simple” problem, but hard to solve without a pen and paper ]More ComplexitySuppose today is Tuesday, November 29What day will be on January 3?[ To answer, we need to bring the day names and the day numbers into coordination, and for that we may need again a pen and paper ]The Role of Software Engg. (1)CustomerSoftware EngineeringProgrammerA bridge from customer needs to programming implementationFirst law of software engineeringSoftware engineer is willing to learn the problem domain(problem cannot be solved without understanding it first)*The Role of Software Engg. (2)*Example: ATM MachineUnderstanding the money-machine problem:*How ATM Machine Might WorkDomain model created with help of domain expert*Cartoon Strip: How ATM Machine Works*Software Engineering BlueprintsSpecifying software problems and solutions is like cartoon strip writingUnfortunately, most of us are not artists, so we will use something less exciting: UML symbolsHowever *Second Law of Software EngineeringSoftware should be written for people first( Computers run software, but hardware quickly becomes outdated )Useful + good software lives longTo nurture software, people must be able to understand it*Software Development MethodsMethod = work strategyThe Feynman Problem-Solving Algorithm: (i) Write down the problem (ii) think very hard, and (iii) write down the answer.WaterfallUnidirectional, finish this step before moving to the nextIterative + IncrementalDevelop increment of functionality, repeat in a feedback loopAgileUser feedback essential; feedback loops on several levels of granularity*Waterfall Method*Unidirectional, no way back finish this step before moving to the nextUML – Language of Symbols*UML = Unified Modeling LanguageOnline information: the Problem DomainSystem to be developedActorsAgents external to the systemConcepts/ ObjectsAgents working inside the systemUse CasesScenarios for using the system*ATM: Gallery of PlayersActors(Easy to identify because they are visible!)*Gallery of Workers + ThingsConcepts(Hard to identify because they are invisible/imaginary!)*Use Case: Withdraw Cash*How ATM Machine Works (2)Domain Model (2)Alternative solutionHow ATM Machine Works (3)Domain Model (3)Alternative solutionWhich solution is the best or even feasible?Rube Goldberg Design*Garage door openerActual Design*Software MeasurementWhat to measure?Project (developer’s work), for budgeting and schedulingProduct, for quality assessment*Formal hedge pruning*Sizing the Problem (1)Size(  ) = 10Size(  ) = 7Size(  ) = 4Size(  ) = 3Size(  ) = 4Size(  ) = 2Size(  ) = 4Size(  ) = 7Step 2:Estimate relative sizes of all partsStep 1: Divide the problem into small & similar partsSizing the Problem (2)Step 3: Estimate the size of the total workTotal size =  points-for-section i (i = 1..N)Step 4: Estimate speed of work (velocity)Step 5: Estimate the work duration Travel duration = Path sizeTravel velocitySizing the Problem (3)Advantages:Velocity estimate may need to be adjusted (based on observed progress)However, the total duration can be computed quickly (provided that the relative size estimates of parts are accurate – easier to achieve if the parts are small and similar-size)Exponential Cost of EstimationEstimation costEstimation accuracy100% Improving accuracy of estimation beyond a certain point requires huge cost and effort (known as the law of diminishing returns) In the beginning of the curve, a modest effort investment yields huge gains in accuracy*Estimation Error Over TimeTimeEstimationerrorCompletionStartThe cone of uncertainty starts high and narrows down to zero as the project approaches completion.RequirementsDesignImplementationAgile Project Effort Estimation*Measuring Quality of Work*Concept MapsPropositionConceptRelationConcept1.Ihavefriend2.friendengages incoding3.codingconstructs aprogram4.programisnewSENTENCE: “My friend is coding a new program”translated into propositionsSearch the Web for Concept Maps*Useful tool for problem domain descriptionCase Study: Home Access ControlObjective: Design an electronic system for:Home access controlLocks and lighting operationIntrusion detection and warning*Case Study – More Details*Know Your ProblemMortise Lock Parts*Concept Map for Home Access Control*States and Transition RuleslockedunlockedIF validKey THEN unlockIF pushLockButton THEN lockIF timeAfterUnlock ≥ max{ autoLockInterval, holdOpenInterval } THEN lockIF validKey AND holdOpenInterval THEN unlock* what seemed a simple problem, now is becoming complex