PowerPoint PresentationChapter 7: Software EngineeringThe Software Engineering DisciplineComputer Aided Software Engineering (CASE) toolsFigure 7.1 The software life cycleFigure 7.2 The development phase of the software life cycleAnalysis StageDesign StageImplementation StageTesting StageSoftware Engineering MethodologiesModularityFigure 7.3 A simple structure chartFigure 7.4 The structure of PlayerClass and its instancesFigure 7.5 The interaction between objects resulting from PlayerA’s serveFigure 7.6 A structure chart including data couplingCoupling versus CohesionFigure 7.7 Logical and functional cohesion within an objectTools of the TradeFigure 7.8 A simple dataflow diagramFigure 7.9 A simple use case diagramFigure 7.10 A simple class diagramUnified Modeling LanguageFigure 7.11 One-to-one, one-to-many, and many-to-many relationships between entities of types X and YFigure 7.12 A class diagram depicting generalizationsFigure 7.13 A sequence diagram depicting a generic volleyStructured WalkthoughsDesign PatternsSoftware Testing StrategiesDocumentationSoftware OwnershipSoftware Ownership (continued)Copyright © 2012 Pearson Education, Inc. Computer Science: An OverviewEleventh Editionby J. Glenn BrookshearChapter 7:Software EngineeringCopyright © 2012 Pearson Education, Inc. 0-2Chapter 7: Software Engineering•7.1 The Software Engineering Discipline•7.2 The Software Life Cycle•7.3 Software Engineering Methodologies•7.4 Modularity•7.5 Tools of the Trade•7.6 Testing•7.7 Documentation•7.8 Software Ownership and LiabilityCopyright © 2012 Pearson Education, Inc. 0-3The Software Engineering Discipline•Distinct from other engineering fields–Prefabricated components–Metrics•Practitioners versus Theoreticians•Professional Organizations: ACM, IEEE, etc.–Codes of professional ethics–StandardsCopyright © 2012 Pearson Education, Inc. 0-4Computer Aided Software Engineering (CASE) tools•Project planning•Project management•Documentation•Prototyping and simulation•Interface design•ProgrammingCopyright © 2012 Pearson Education, Inc. 0-5Figure 7.1 The software life cycleCopyright © 2012 Pearson Education, Inc. 0-6Figure 7.2 The development phase of the software life cycleCopyright © 2012 Pearson Education, Inc. 0-7Analysis Stage•Requirements–Application oriented•Specifications–Technically oriented•Software requirements documentCopyright © 2012 Pearson Education, Inc. 0-8Design Stage•Methodologies and tools (discussed later)•Human interface (psychology and ergonomics)Copyright © 2012 Pearson Education, Inc. 0-9Implementation Stage•Create system from design–Write programs–Create data files–Develop databases•Role of “software analyst” versus “programmer”Copyright © 2012 Pearson Education, Inc. 0-10Testing Stage•Validation testing–Confirm that system meets specifications•Defect testing–Find bugsCopyright © 2012 Pearson Education, Inc. 0-11Software Engineering Methodologies•Waterfall Model•Incremental Model–Prototyping (Evolutionary vs. Throwaway)•Open-source Development•Extreme ProgrammingCopyright © 2012 Pearson Education, Inc. 0-12Modularity•Procedures -- Imperative paradigm–Structure charts•Objects -- Object-oriented paradigm–Collaboration diagrams•Components -- Component architectureCopyright © 2012 Pearson Education, Inc. 0-13Figure 7.3 A simple structure chartCopyright © 2012 Pearson Education, Inc. 0-14Figure 7.4 The structure of PlayerClass and its instancesCopyright © 2012 Pearson Education, Inc. 0-15Figure 7.5 The interaction between objects resulting from PlayerA’s serveCopyright © 2012 Pearson Education, Inc. 0-16Figure 7.6 A structure chart including data couplingCopyright © 2012 Pearson Education, Inc. 0-17Coupling versus Cohesion•Coupling –Control coupling–Data coupling•Cohesion–Logical cohesion–Functional cohesionCopyright © 2012 Pearson Education, Inc. 0-18Figure 7.7 Logical and functional cohesion within an objectCopyright © 2012 Pearson Education, Inc. 0-19Tools of the Trade•Data Flow Diagram•Entity-Relationship Diagram–One-to-one relation–One-to-many relation–Many-to-many relation•Data DictionaryCopyright © 2012 Pearson Education, Inc. 0-20Figure 7.8 A simple dataflow diagramCopyright © 2012 Pearson Education, Inc. 0-21Figure 7.9 A simple use case diagramCopyright © 2012 Pearson Education, Inc. 0-22Figure 7.10 A simple class diagramCopyright © 2012 Pearson Education, Inc. 0-23Unified Modeling Language•Use Case Diagram–Use cases–Actors•Class DiagramCopyright © 2012 Pearson Education, Inc. 0-24Figure 7.11 One-to-one, one-to-many, and many-to-many relationships between entities of types X and YCopyright © 2012 Pearson Education, Inc. 0-25Figure 7.12 A class diagram depicting generalizationsCopyright © 2012 Pearson Education, Inc. 0-26Figure 7.13 A sequence diagram depicting a generic volleyCopyright © 2012 Pearson Education, Inc. 0-27Structured Walkthoughs•“Theatrical” experiment•Class-responsibility-collaboration cardsCopyright © 2012 Pearson Education, Inc. 0-28Design Patterns•Well designed “templates” for solving recurring problems•Examples:–Adapter pattern: Used to adapter a module’s interface to current needs–Decorator pattern: Used to control the complexity involved when many different combinations of the same activities are required•Inspired by the work of Christopher Alexander in architectureCopyright © 2012 Pearson Education, Inc. 0-29Software Testing Strategies•Glass-box testing–Pareto principle–Basis path testing•Black-box testing–Boundary value analysis–Redundancy testing–Beta testingCopyright © 2012 Pearson Education, Inc. 0-30Documentation•User Documentation–Printed book for all customers–On-line help modules•System Documentation–Source code–Design documents•Technical Documentation–For installing, customizing, updating, etc.Copyright © 2012 Pearson Education, Inc. 0-31Software Ownership•Copyright–Allow a product to be released while retaining ownership of intellectual property–Asserted in all works:•Specifications•Source code•Final productCopyright © 2012 Pearson Education, Inc. 0-32Software Ownership (continued)•Software License–A legal agreement that grants the user certain permissions without transferring ownership•Patents–Must demonstrate that it is new, usable, and not obvious to others with similar