Lecture 2 Software Engineering and Design

Transcription

1 Lecture 2 Software Engineering and Design Software Engineering ITCS 3155 Spring 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte August 28, 2008

2 Lecture Overview Chapter 1: A Discipline of Software Engineering Design Terminology Software design as problem solving Abstraction Modeling Software lifecycle Software engineering design methods 2

3 The Importance of Software

4 The Impact of Design Design is often the cause of poor quality 85% of problems with mechanical products Poor designs impose costs Customer service Returns Product liability Lost business Good software design is essential! Save costs, but also reduce frustration with pervasive computing and.. safety-critical systems! 4

5 Software Design Terminology Software Any executable entity, such as a program, or its parts Software designers do more than just produce software Software product An entity comprised of one or more programs, data, and supporting materials and services that satisfies client needs Either an independent artifact, or Essential ingredient in some other artifact e.g., motion control module in a robotic arm 5

6 Software Design Software design is the activity of specifying the nature and composition of software products Satisfy client needs Subject to constraints 6

7 Types of Design Product design concerned with styling and aesthetics, function, -bilities Industrial designers, (building) architects, interior designers, graphic designers, etc. Engineering design concerned with technical mechanisms and workings Often have special training in science and math Structural, mechanical, chemical, and electrical engineers Design teams often include both product and engineering designers 7

8 Product Design Software Product Design Specifying software product features, capabilities, and interfaces to satisfy client needs and desires Requires skills in: user interface design communications industrial design marketing 8

9 Engineering Design Software engineering design Specifying parts, structure, behavior of software in a way that meets meet product specifications (i.e., requirements) Requires skills in: Programming Algorithms Data structures Software design principles, practices, processes, techniques Software architectures Software design patterns We ll focus mostly on software engineering design 9

10 Design as Problem Solving Benefits Partitioning information between problem and solution Helps with confusion over what is a requirement of the system and what is the design solution to meet requirements Emphasizes that there may be more than one good solution Not just one perfect design for a software product Suggests techniques to approach the design problem Changing the problem Trial and error Brainstorming Abstraction 10

11 Simplifying through Abstraction Abstraction Suppressing or ignoring some properties of objects, events, or situations Problem simplification Focus on the most important aspects of a problem in (partially) solving it Structuring problem solving Top-down strategy: Solve an abstract version of the problem, then add details (refinement) Bottom-up strategy: Solve parts of a problem and connect them for a complete solution 11

12 Abstraction and Modeling The use of abstraction allows us to model a software design solution Model An entity used to represent another Target parts map to model parts Target relationships map to model relationships Target Model 12

13 Examples of Models ΔTFR = αδ* ln(per Capita GNP) 13

14 The Use of Models in Design Modeling is used for: Problem understanding Design creation Design investigation Documentation A model provides an abstract representation but must capture important and relevant details to be useful! 14

15 Modeling Approaches Static models Represent aspects of programs that do not change during execution Car Wheel Engine Body Piston Valve Door Hood Dynamic models Represent what happens during program execution 15

16 How do we engineer software? Software development process (a.k.a. software lifecycle) A structured set of activities required to develop a software system Requirements specification Design Implementation Validation (a.k.a. testing) Evolution (a.k.a. maintenance) 16

17 Software Process Activity: Requirements Specification Software product requirement Statement that a software product must have a certain feature, function, capability, or property Requirements Specification Activity Capture and document software product requirements Needs and desires of customer Capture and document design constraints Limiting factors: cost, time, size, technology, etc. Results in software requirements specification (SRS) A detailed statement of the problem to solve Product must meet requirements in SRS 17

18 Software Process Activity: Design Design activity Developers determine how to solve the problem Select an overall program structure Determine major parts and subsystems Determine interactions among them Determine how each part will be constructed Determine the parts of the subsystems Determine how they store data and operate Choose data structures and algorithms Results in a design document Presents a solution to problem state in the SRS Usually contains several models (dynamic and static) 18

19 Software Process Activity: Implementation Implementation Activity Developers write code that meets the specifications of the solution in the design document Since design is often high-level, may include: Choice of data types Choice/design of data structures Choice/design of algorithms Results in an executable program 19

20 Software Process Activity: Validation Validation activity Determine if right program was developed Does it meet client needs? Determine if program was developed right Does the program meet the specification? Usually performed bottom-up Test small pieces of functionality first, then their integration Should result in a working program that has acceptable level of performance 20

21 Software Process Activity: Evolution Evolution activity Enhancing the product with new functions and capabilities May include: Improving user interface Adapting program for new execution platforms Fixing bugs Improving software design for future maintenance and reuse 21

22 Design Across the Lifecycle Software Product Life Cycle Requirements Specification Product Design Design Engineering Design Implementation Validation Evolution Product Redesign and Engineering Redesign 22

23 What Versus How Traditional way to make the distinction between requirements and design activities Not adequate because Sometimes how statements are really requirements Sometimes what statements come up during design 23

24 Design as Problem Solving Instead, distinguish requirements from design based on problem solving Requirements activity formulates a problem Problem is solved in design But can t you say the same thing about overlapping problems and solutions? Design problems within design problems! Still a better metaphor More effectively separates problem as stated by customer from solution Allows us to apply problem solving techniques 24

25 Design Problems and Solutions Software Design Product Design Design Features and Capabilities Design Interactions Problem: Needs, Desires, Constraints Solution: Features and Capabilities Solution: Interactions Engineering Design Create High-Level Design Create Low-Level Design Write Code Solution: SRS Solution: High- Level Design Solution: Low- Level Design Solution: Design Document Solution: Code 25

26 The Big Picture: Design Methods Software design method procedure for generating a precise and complete software design solution that meets clients needs and constraints Design method components Design Process Collection of related tasks that transforms set of inputs into set of outputs Design Notations Symbolic representational system Design Heuristics Rules providing guidance, but no guarantee, for achieving some end Design methods also use design principles stating characteristics of design that make them better or worse 26

27 Coming Up Software Development Processes So far, we ve considered design activities as occurring sequentially Waterfall model Design is not purely sequential activity (and shouldn t be!!!) Next time, we ll talk about more sophisticated approaches Include same set of design process activities 27

28 Next time Software design processes We ll cover: Spiral model Capability Maturity Model Rational Unified Process Read Chapter 2 Take notes! Some material covered will not be in the text book 28