Presentation is loading. Please wait.

Presentation is loading. Please wait.

CSDP Preparation Course Module IV: Software Construction

Similar presentations


Presentation on theme: "CSDP Preparation Course Module IV: Software Construction"— Presentation transcript:

1 CSDP Preparation Course Module IV: Software Construction
Time per slide (min.) / Section Milestone (min) Facilitator Notes: Module IV - Software Construction

2 Module IV - Software Construction
Specifications The exam specific topics covered in this module are listed below, and are the basis for the outline of its content Construction Planning Code Design Data Design and Management Error Processing Source Code Organization Code Documentation Construction Quality Assurance System Integration and Deployment Code Tuning Construction Tools Module IV - Software Construction Module IV - Software Construction

3 Module IV - Software Construction
Objectives After completing this module, you should be able to… Define the “software construction” Discuss how to plan for software construction Examine the factors that effect the size, cost, and schedule for software construction Discuss software construction quality factors and quality assurance List and describe software construction tools Describe how to design and document code Describe what is meant by code tuning and how to do it Describe error processing Define the various types of system integration 2 min. / 20 min. Facilitator Notes: Module IV - Software Construction Module IV - Software Construction

4 Module IV - Software Construction
Organization The organization of information for each specification topic is as follows: Topic Content Slides - detail the important issues concerning each topic and support the module objectives Topic Reference Slides - detail the sources for the topical content and provides additional references for review Topic Quiz Slides - allow students to prepare for the exam Module IV - Software Construction Module IV - Software Construction

5 Module IV - Software Construction
Introduction Definition of Software Construction: Detailed creation of working, meaningful software through a combination of coding, verification, unit testing, integration testing, and debugging Software construction closely tied to Software design Software testing Design Construction Testing Topic estimate: 15 minutes The term software construction refers to the detailed creation of working, meaningful software through a combination of coding, verification, unit testing, integration testing, and debugging. Software construction is linked to all other software engineering disciplines, and most strongly to software design and software testing. This is because the software construction process itself involves significant software design and test activity. It also uses the output of design and provides one of the inputs to testing, both design and testing being the activities. Detailed boundaries between design, construction, and testing (if any) will vary depending upon the software life cycle processes that are used in a project. [IE04] p. 4-1 Module IV - Software Construction Module IV - Software Construction

6 Module IV - Software Construction
Introduction - 2 More on Construction Significant detailed design occurs during construction Low-level (e.g. unit and module integration) testing occurs during construction Construction produces high volume of configuration items Thus construction linked to configuration management Construction is tool intensive Quality (or lack thereof) is very evident in the construction products Construction highly related to Computer Science due to Use of algorithms Detailed coding practices Although some detailed design may be performed prior to construction, much design work is performed within the construction activity itself. Thus the software construction activity is closely linked to the software design activity. Throughout construction, software engineers both unit test and integration test their work. Thus, the software construction activity is closely linked to the software testing activity as well. Software construction typically produces the highest volume of configuration items that need to be managed in a software project (source files, content, test cases, and so on). Thus, the software construction activity is also closely linked to the software configuration management activity. Since software construction relies heavily on tools and methods, and is probably the most tool-intensive of the activities, it is linked to the software engineering tools and methods activity. While software quality is important in all the activities, code is the ultimate deliverable of a software project, and thus software quality is also closely linked to software construction. Among the related disciplines of software engineering, the software construction activity is most akin to computer science in its use of knowledge of algorithms and of detailed coding practices, both of which are often considered to belong to the computer science domain. It is also related to project management, insofar as the management of construction can present considerable challenges. [IE04] p. 4-1 Module IV - Software Construction Module IV - Software Construction

7 Introduction - 3 Software Construction Fundamentals
The fundamentals of software construction include: Minimizing complexity Anticipating change Constructing for verification Standards in construction The following slides discuss each of these fundamentals Minimizing complexity, anticipating change, and constructing for verification apply to design as well as to construction. The following remainder of this introduction section will define these concepts and describe how they apply to construction. [IE04] p. 4-1 Module IV - Software Construction Module IV - Software Construction

8 Introduction - 4 Minimizing Complexity
Humans are severely limited in our ability to hold complex information in our working memories As a result, minimizing complexity is one the of strongest drivers in software construction Need to reduce complexity throughout the lifecycle As functionality increases, so does complexity Accomplished through use of standards Examples: J2EE for complex, distributed Java applications UML for modeling all aspects of complex systems High-order programming languages such as C++ and Java Source code formatting rules to aid readability A major factor in how people convey intent to computers is the severely limited ability of people to hold complex structures and information in their working memories, especially over long periods of time. This leads to one of the strongest drivers in software construction: minimizing complexity. The need to reduce complexity applies to essentially every aspect of software construction, and is particularly critical to the process of verification and testing of software constructions. In software construction, reduced complexity is achieved through emphasizing the creation of code that is simple and readable rather than clever. Minimizing complexity is accomplished through making use of standards, and through numerous specific coding techniques. It is also supported by the construction-focused quality techniques. [IE04] p. 4-1 Module IV - Software Construction Module IV - Software Construction

9 Module IV - Software Construction
Introduction - 5 Anticipating Change Software changes over time Anticipation of change affect how software is constructed This can effect Use of control structures Handling of errors Source code organization Code documentation Coding standards Most software will change over time, and the anticipation of change drives many aspects of software construction. Software is unavoidably part of changing external environments, and changes in those outside environments affect software in diverse ways. Anticipating change is supported by many specific techniques such as: Techniques for creating understandable source code, including naming and source code layout Use of classes, enumerated types, variables, named constants, and other similar entities Use of control structures Handling of error conditions—both planned errors and exceptions (input of bad data, for example) Prevention of code-level security breaches (buffer overruns or array index overflows, for example) Resource usage via use of exclusion mechanisms and discipline in accessing serially reusable resources (including threads or database locks) Source code organization (into statements, routines, classes, packages, or other structures) Code documentation Code tuning [IE04] pp. 4-1 through 4-5 Module IV - Software Construction Module IV - Software Construction

10 Introduction - 6 Constructing for Verification
Construct software that allows bugs to be easily found and fixed Examples: Enforce coding standards Helps support code reviews Unit testing Organizing code to support automated testing Restricted use of complex or hard-to-understand language structures Constructing for verification means building software in such a way that faults can be ferreted out readily by the software engineers writing the software, as well as during independent testing and operational activities. Specific techniques which support constructing for verification include following coding standards to support code reviews, unit testing, organizing code to support automated testing, and restricted use of complex or hard-to-understand language structures, among others. [IE04] p. 4-2 Module IV - Software Construction Module IV - Software Construction

11 Introduction - 7 Standards in Construction
Standards which directly affect construction issues include: Programming languages E.g. standards for languages like Java and C++ Communication methods E.g. standards for document formats and contents Platforms E.g. programmer interface standards for operating system calls, J2EE Tools E.g. diagrammatic standards for notations like the Unified Modeling Language Standards in software development are important because they bring consistency the process and product. Use of external standards: Construction depends on the use of external standards for construction languages, construction tools, technical interfaces, and interactions between Software Construction and other activities. Standards come from numerous sources, including hardware and software interface specifications such as the Object Management Group (OMG) and international organizations such as the IEEE or ISO. Use of internal standards: Standards may also be created on an organizational basis at the corporate level or for use on specific projects. These standards support coordination of group activities, minimizing complexity, anticipating change, and constructing for verification. [IE04] p. 4-2 Module IV - Software Construction Module IV - Software Construction

12 Module IV - Software Construction
References [IE04] IEEE Computer Society, Guide to the Software Engineering Body of Knowledge (SWEBOK), IEEE Computer Society Press, Los Alamitos, CA 20001, June 2004 Module IV - Software Construction Module IV - Software Construction

13 A. Construction Planning
What is Construction Planning? Laying out the work plan (i.e. schedule) to design, implement, debug, and unit test the software Construction planning major concerns: Coders are typically not planners Schedules will be difficult to maintain unless a good architecture design is in place Many organizations to not collect project data on which to plan future projects Many managers consider planning to be a waste of time and therefore don’t encourage it Project plans may be limited to the construction plans Many organizations and projects do not use systematic cost estimating methods such as models Topic estimate: 26 minutes Planning for software construction is important. A schedule must be in place in order to guide design, implementation, unit test/debug, and integration and make mid-course corrections if necessary. Some issues involved with construction planning include: Coders are typically not good planners, nor do they like the idea of doing “project management” tasks Schedules will be difficult to maintain unless a good architecture design is in place Many organizations to not collect project data on which to plan future projects, and those who do not understand history are doomed to repeat it Many managers consider planning to be a waste of time and therefore don’t encourage it Project plans may be limited to the construction plans when all aspects of development need to be reflected in the schedule Many organizations and projects do not use systematic cost estimating methods such as models and therefore do a poor job of resource allocation and are often over budget [RT03] Module IV - Software Construction Module IV - Software Construction

14 A. Construction Planning - 2
Improving Software Economics Consider reducing development costs by planning to: Reduce the size and/or complexity Improve the development process Use more highly skilled people and build better teams Use better tools Reduce quality thresholds Some actions include Use an object-oriented approach Use COTS components Use an iterative approach Provide training to development team Automate tedious tasks with tools Improvements in the area of software development have been difficult to achieve and also difficult to measure and substantiate. Five basic areas on which to focus are listed here, in order of priority: Reduce the size and/or complexity Improve the development process Use more highly skilled people and build better teams Use better tools Consider reducing quality thresholds Size/complexity Use an object oriented approach Focus on reuse Look for opportunities to use commercial off-the-shelf (COTS) components Process Use an iterative approach Improve the process maturity Focus on architecture early in the life cycle People/teams Provide appropriate training Encourage teamwork Create a win-win culture Tools Use integrated tools Use open (as opposed to propriety) systems Use appropriately sized hardware Automate tedious tasks such as coding (where possible) documentation testing metrics collection & analysis Quality Ensure appropriate hardware platform performance Use a demonstration-based assessment approach Use statistical quality control [WR01] pp Module IV - Software Construction Module IV - Software Construction

15 A. Construction Planning - 3
Construction Prerequisites As with building construction, much of the success or failure of the project already determined before construction begins Upstream activities such as project planning, requirements, architecture, and design are crucial to success Typical high-risk areas Project planning Requirements Architecture Preparation is a way to reduce these risks A best practice for building high-quality software emphasizes quality throughout the software development lifecycle. Since construction is in the middle of a software project, by the time you get to construction, the earlier parts of the project have already laid some of the groundwork for success or failure. During construction, however, you should at least be able to determine how good your situation is and to back up if you see problems. The overall goal of preparation is risk reduction – a good project planner identifies and resolves major risks as early as possible so that the bulk of the project can proceed as smoothly as possible. Be far, the most common project risks in software development are poor requirements, poor architecture, and poor project planning. As such, it is crucial that construction preparation include an assessment of these areas. [SM04] pp Module IV - Software Construction Module IV - Software Construction

16 A. Construction Planning - 4
Problem Definition Prerequisite The problem being solved via the application must be well defined Common names for the document containing the problem statement: Product Vision Vision Statement Product Definition Defines the problem without reference to potential solutions Helps avoid solving the wrong problem! The first prerequisite before beginning construction is a clear statement of the problem that the system is supposed to solve. This is sometimes called “product vision,” “vision statement,” or, as used here, “product definition.” A problem definition defines what the problem is without any reference to possible solutions. The problem definition should be in user language, and the problem should be described from a user's point of view. It usually should not be stated in technical computer terms. Without a good problem definition, you might put effort into solving the wrong problem. [SM04] pp The Rational Unified Process names the product definition the “Vision” and provides the following explanation: The Vision defines the stakeholders view of the product to be developed, specified in terms of the stakeholders key needs and features. Containing an outline of the envisioned core requirements, it provides the contractual basis for the more detailed technical requirements.  The Vision captures the "essence" of the envisaged solution in the form of high-level requirements and design constraints that give the reader an overview of the system to be developed from a behavioral requirements perspective. It communicates the fundamental "why and what" for the project and is a gauge against which all future decisions should be validated [RS04] Module IV - Software Construction Module IV - Software Construction

17 A. Construction Planning - 5
Requirements Prerequisite Requirements describe in detail what a system is supposed to do, therefore are invaluable for construction Explicit requirements: Help ensure the user drives system functionality Rather than the programmer Reduce the number of construction debates Help minimize changes after development begins Specifying requirements adequately is a key to project success Requirements describe in detail what a software system is supposed to do, and they are the fist step toward a solution. The requirements activity is also known as “requirements development,” “requirements analysis,” “analysis,” “requirements definition,” “software requirements specification,” and “functional specification” Explicit requirements help ensure that the user, rather than the programmer, drives the system’s functionality. Explicit requirements help to avoid arguments Attention to requirements helps minimize changes to a system after development begins. Specifying requirements adequately is a key to project success [SM04] pp Module IV - Software Construction Module IV - Software Construction

18 A. Construction Planning - 6
Architecture Prerequisite Quality of the architecture determines the conceptual integrity of the system A proper architecture: Gives structure to maintain conceptual integrity Provides guidance to programmers Partitions work Architecture-level problems are much more costly to fix than are coding errors Good architecture can make construction easy Bad architecture makes construction difficult Software architecture is the high-level part of software design, the frame that holds the more detailed parts of the design. Architecture is also known as “system architecture,” and “top-level design.” Typically, the architecture is described in a single document referred to as the “architecture specification”. Architecture is a prerequisite to construction because the quality of the architecture determines the conceptual integrity of the system. A well-thought-out architecture provides the structure needed to maintain a system’s conceptual integrity from the top levels down to the bottom. It provides guidance to programmers. It partitions the work so that multiple developers or multiple development teams can work independently. Good architecture can make construction easy. Bad architecture makes construction difficult. Architectural changes are expensive to make during construction or later. The time needed to fix an error in a software architecture is on the same order as that needed to fix a requirements error, and both are more timely than fixing coding errors. [SM04] pp Module IV - Software Construction Module IV - Software Construction

19 A. Construction Planning - 7
Regarding Upstream Prerequisites Time budgeted for requirements and architecture work 10 to 20 percent of manpower 20 to 30 percent of schedule If requirements are unstable Do not ignore, spend time to fix The analyst should fix if a formal project Can be fixed by the programmer for informal projects Use same heuristics for problems with the architecture The amount of time to spend on problem definition, requirements, and software architecture varies according to the needs of your project. Generally, a well-run project devotes approximately 10 to 20 percent of its effort (manpower) and about 20 to 30 percent of its schedule to requirements, architecture, and up-front planning. Since detailed design is considered part of construction, these figures exclude time for this. If requirements are unstable and you're working on a large, formal project, you'll probably have to work with a requirements analyst to resolve requirements problems that are identified early in construction. Allow time to consult with the requirements analyst and for the requirements analyst to revise the requirements before you'll have a workable version of the requirements. If requirements are unstable and you're working on a small, informal project, you'll probably need to resolve requirements issues yourself. Allow time for defining the requirements well enough that their volatility will have a minimal impact on construction. If the requirements are unstable on any project, formal or informal, treat requirements work as its own project. Estimate the time for the rest of the project after you've finished the requirements. This is a sensible approach since no one can reasonably expect you to estimate your schedule before you know what you're building. When allocating time for software architecture, use an approach similar to the one for requirements development If the software is a kind that you haven't worked with before, allow more time for the uncertainty of designing in a new area. Ensure that the time you need to create a good architecture won't take away from the time you need for good work in other areas. If necessary, plan the architecture work as a separate project, too. [SM04] pp Module IV - Software Construction Module IV - Software Construction

20 A. Construction Planning - 8
Choose an Approach Many software development approaches have been tried over the years Some examples (not mutually exclusive): Functional Object-Oriented Iterative Waterfall Agile Data-centric The construction team must follow some approach Chosen approach must be appropriate for the task at hand Many approaches to software development have been documented. Functional vs. object-oriented. Iterative vs. waterfall. Agile vs. formal. User-centric vs. data-centric vs. process-centric. The construction team must follow some approach, and the chosen approach should be appropriate for the task at hand. Many books are available that map out different approaches to conducting a software project. Some are more sequential, and some are more iterative. Here is a list of several current texts that provide a variety of these approaches. McConnell, Steve. Software Project Survival Guide. Redmond, WA Microsoft Press, This book presents one particular way to conduct a project. The approach presented emphasizes deliberate up-front planning, requirements development, and architecture work followed by careful project execution. It provides long-range predictability of costs and schedules, high quality, and a moderate amount of flexibility. Kruchten, Philippe. The Rational Unified Process: An Introduction, 2d ed. Reading, MA: Addison-Wesley, This book presents a project approach that is "architecture-centric and use-case driven." Like Software Project Survival Guide, it focuses on up-front work that provides good long-range predictability of costs and schedules, high quality, and moderate flexibility. This book's approach requires somewhat more sophisticated use than the approaches described in Software Project Survival Guide and Extreme Programming Explained: Embrace Change. Jacobson, Ivar, Grady Booch, and James Rumbaugh. The Unified Software Development Process. Reading, MA Addison-Wesley, This book is a more in-depth treatment of the topics covered in The Rational Unified Process: An Introduction, 2d ed. Beck, Kent. Extreme Programming Explained: Embrace Change. Reading, MA: Addison- Wesley, Beck describes a highly iterative approach that focuses on developing requirements and designs iteratively, in conjunction with construction. The Extreme Programming approach offers little long-range predictability but provides a high degree of flexibility. Gilb, Tom. Principles of Software Engineering Management. Wokingham, England: Addison-Wesley, Gilb's approach explores critical planning, requirements, and architecture issues early in a project and then continuously adapts the project plans as the project progresses. This approach provides a combination of long-range predictability, high quality, and a high degree of flexibility. McConnell, Steve. Rapid Development. Redmond, WA: Microsoft Press, This book presents a toolbox approach to project planning. An experienced project planner can use the tools presented in this book to create a project plan that is highly adapted to a project's unique needs. Boehm, Barry and Richard Turner. Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison-Wesley, This book explores the contrast between agile development and plan-driven development styles. Chapter 3 has four especially revealing sections: "A Typical Day using PSP/TSP," "A Typical Day using Extreme Programming," "A Crisis Day using PSP/TSP," and "A Crisis Day using Extreme Programming." Chapter 5 is on using risk to balance agility, which provides incisive guidance for selecting between agile and plan- driven methods. Chapter 6, "Conclusions," is also well balanced and gives great perspective. Appendix E is a gold mine of empirical data on agile practices. Larman, Craig. Agile and Iterative Development: A Manager's Guide. Boston, MA Addison Wesley, This is a well-researched introduction to flexible, evolutionary development styles. It overviews Scrum, Extreme Programming, and the Unified Process. [SM04] pp Module IV - Software Construction Module IV - Software Construction

21 A. Construction Planning - 9
Choose a Programming Language Programming language choices affect Productivity Code quality Programmers more productive using a familiar language High-level languages provided higher quality and better productivity Some languages better at expressing programming concepts than others The ways in which a programmers express themselves are affected by the chosen language The programming language in which the system will be implemented should be of great interest to you since you will be immersed in it from the beginning of construction to the end. Studies have shown that the programming-language choice affects productivity and code quality in several ways. Programmers are more productive using a familiar language than an unfamiliar one. Data from the Cocomo II estimation model shows that programmers working in a language they've used for three years or more are about 30 percent more productive than programmers with equivalent experience who are new to a language. An earlier study at IBM found that programmers who had extensive experience with a programming language were more than three times as productive as those with minimal experience. Programmers working with high-level languages achieve better productivity and quality than those working with lower-level languages. Languages such as C++, Java, Smalltalk, and Visual Basic have been credited with improving productivity, reliability, simplicity, and comprehensibility by factors of 5 to 15 over low-level languages such as assembly and C. Moreover, higher-level languages are more expressive than lower-level languages. Each line of code says more. Some languages are better at expressing programming concepts than others. You can draw a parallel between natural languages such as English and programming languages such as Java and C++. In the case of natural languages, the linguists Sapir and Whorf hypothesize a relationship between the expressive power of a language and the ability to think certain thoughts. The Sapir-Whorf hypothesis says that your ability to think a thought depends on knowing words capable of expressing the thought. If you don't know the words, you can't express the thought and you might not even be able to formulate it. Programmers may be similarly influenced by their languages. The words available in a programming language for expressing your programming thoughts certainly determine how you express your thoughts and might even determine what thoughts you can express. [SM04] pp Module IV - Software Construction Module IV - Software Construction

22 A. Construction Planning - 10
Choose Construction Practices Questions to answer regarding practices: How detailed will the design be? What are the coding conventions for names, comments, layout, etc.? How will the architecture be enforced? Is the project’s use of technology ahead of or behind the power curve, and is this appropriate given the circumstances? What is the integration procedure, how often is it done, and who participates? Will developers program individually, in pairs, or some combination of this? Where and when will builds occur? Part of preparing for construction is deciding which of the available practices will be emphasized. Some choices include pair programming with test-first development, solo development with formal inspections, or some other combination of these. The right choice is guided by the specific circumstances of the project. Here is a list of questions that should be answered in advance of code construction: Have you defined how much design will be done up front and how much will be done at the keyboard while code is being written (i.e. to what level will the design be specified)? Have you defined coding conventions for names, comments, and layout? Have you defined specific coding practices that are implied by the architecture, such as how error conditions will be handled, how security will be addressed, what conventions will be used for class interfaces, what standards will apply to reused code, how much to consider performance while coding? Have you identified your location on the technology wave and adjusted your approach to match? Have you defined an integration procedure, i.e. have you defined the specific steps a programmer must go through before checking code into the master repository? Will developers program individually, in pairs, or some combination thereof? Where and when will system builds occur [SM04] p. 69 Module IV - Software Construction Module IV - Software Construction

23 A. Construction Planning - 11
Choose Tools Modern programming tools Are essential to maintain programmer productivity Reduce tedious and redundant tasks Must be appropriate for the task at hand Tools preparation checklist: Are all product licenses current? Are all products at current, supported revision level? Have all programmers received proper training on the tools? Does the project have a configuration management tool? Does the project have a tool to track change requests? Do project team members have sufficient workstations? Does the project have sufficient test environments? Does the project have sufficient build environments? Modern programming tools decrease the amount of time required for construction. Use of appropriate toolset (with the appropriate training) can increase productivity by 50% or more. Also, tools can reduce the amount of tedious detail work that programming requires. Is there an available integrated development environment (IDE) that is appropriate for the project Are all product licenses current? Are all products at current, supported revision level? Have all programmers received proper training on the tools? Does the project have a configuration management tool? Does the project have a tool to track change requests? Does the project have appropriate third-party code libraries to reduce custom-written code? Do project team members have sufficient workstations? Does the project have sufficient test environments? Does the project have sufficient build environments? [SM04] pp Module IV - Software Construction Module IV - Software Construction

24 A. Construction Planning - 12
Construct the Team For small development efforts Self managed Everyone is a peer For mid-size development efforts Single team For large development efforts Multiple teams Role # / Team* Lead 1 Detailed designer 1 to 4 Coder 5 to 10 Integrator 1 to 2 Unit tester Same as coder System tester “Buildmeister” Configuration manager * Individuals will play multiple roles Team size and composition is dependent upon the size of the development effort. Most construction teams accommodate the following roles: Lead Detailed designer Coder Integrator Unit tester Integration tester “Buildmeister” Configuration manager For “small” projects, the number of developers on the team is low, on the order of 1 to 4. Teams of this size generally are self-managed and everyone is a peer. For medium sized projects, the number of developers can be anywhere from roughly 5 to 15. The team structure is typically as follows: 1 team lead 5 to 10 coders 1 buildmeister (the person who performs the periodic build) 1 configuration manager 1 Integrator 1 System tester Table 1: Team Composition Module IV - Software Construction Module IV - Software Construction

25 Module IV - Software Construction
A. References [IE04] IEEE Computer Society, Guide to the Software Engineering Body of Knowledge (SWEBOK), IEEE Computer Society Press, Los Alamitos, CA 20001, June 2004 [RS04] IBM Rational Software, The Rational Unified Process v , 2004 [RT03] [SM04] S. McConnell, Code Complete: A Practical Handbook of Software Construction, Second Edition, Microsoft Press, 2004. [WR01] Walker Royce, Software Project Management, A Unified Framework, Addison-Wesley, Boston, MA, 2001 Module IV - Software Construction

26 Module IV - Software Construction
Quiz – 1 According to this lesson, construction planning involves creating a schedule for all except which of the following: a) Design b) Implement c) Integrate d) Unit test 1) a 2) b 3) c 4) d 3) c Module IV - Software Construction Module IV - Software Construction

27 Module IV - Software Construction
Quiz – 2 Which are valid ways to reduce development costs: a) Reduce the number of requirements b) Reduce quality c) Use more highly skilled people 1) a 2) b 3) c 4) None are valid 5) All are valid 5) All are valid Module IV - Software Construction Module IV - Software Construction

28 Module IV - Software Construction
Quiz – 3 The name given to the document that contains the problem statement is a) Product Vision b) Vision Statement c) Product Definition 1) a 2) b 3) c 4) All of the above 4) All of the above Module IV - Software Construction Module IV - Software Construction

29 Module IV - Software Construction
Quiz – 4 After the completion of construction, problems discovered with the architecture are typically a) More costly to fix than coding errors b) Less costly to fix than coding errors c) Due to incorrect requirements d) Due to missing requirements 1) a 2) b 3) c 4) d 1) a Module IV - Software Construction Module IV - Software Construction

30 Module IV - Software Construction
Quiz – 5 Up to 30 percent of the schedule should be allocated to requirements and architecture activities. 1) True 2) False 1) True Module IV - Software Construction Module IV - Software Construction

31 Module IV - Software Construction
B. Code Design Software Design The process of defining the software architecture, components, modules, interfaces, test approach, and data for a software system to satisfy specified requirements. IEEE Standard Topic estimate: 33 minutes Module IV - Software Construction Module IV - Software Construction

32 B. Code Design - 2 Importance of Managing Complexity
Most technical issues are due to high complexity Users are demanding more functionality Frequent source of complexity Software Crisis: Ability to produce suitable applications is not keeping pace with demand Causing systems to be unreliable, slow, insecure, buggy “Separation of concerns” is one method to overcome complexity Software project surveys have shown that most project failures are not technical in nature. However, when project do fail because of technical issues, the underlying cause is usually due to high complexity. Therefore, managing complexity is the most important technical issue in software development today. Due in part to the ever increasing capability of hardware, users are demanding more application functionality. With this increase in functionality comes an increase in complexity. The software crisis is a well-known issue where the practice of software engineering is not able to keep up with the demands being made on application software, thus creating a situation where modern complex computer systems are unreliable, slow, insecure and buggy. This is what makes software architecture so important. A proper architecture divides the system into small pieces (e.g. subsystems, packages). Humans can much more easily comprehend several small pieces compared to one big piece. “Separation of concerns” allow developers to focus on one bit of complexity at a time. [SM04] p Module IV - Software Construction Module IV - Software Construction

33 B. Code Design - 3 How to Overcome Complexity
Ineffective designs come from three sources: A complex solution to a simple problem A Simple, incorrect solution to a complex problem An inappropriate, complex solution to a complex problem 2 ways to manage complexity: Minimize the amount of essential complexity Keep accidental complexity from proliferating Ineffective designs come from three sources: A complex solution to a simple problem A simple, incorrect solution to a complex problem An inappropriate, complex solution to a complex problem A two-prong approach to managing complexity is: Minimize the amount of essential complexity that anyone's brain has to deal with at anyone time. Keep accidental complexity from needlessly proliferating. [SM04] p. 79 Module IV - Software Construction Module IV - Software Construction

34 B. Code Design - 4 Desirable Design Characteristics
Steve McConnell suggests achievement of the following: Minimal complexity Ease of maintenance Loose coupling Extensibility High fan-in Low-to-medium fan-out Portability Leanness Stratification Standard techniques Steve McConnell has cataloged the following desirable design characteristics. The more characteristics the detailed design team can employ, the better the design will be. Minimal complexity Ease of maintenance Loose coupling Extensibility High fan-in Low-to-medium fan-out Portability Leanness Stratification Standard techniques Each of these desirable design characteristics are detailed in subsequent slides. [SM04] pp Module IV - Software Construction Module IV - Software Construction

35 B. Code Design - 5 Desirable Design Characteristics (cont.)
Minimal complexity KISS: Keep it simple, stupid! Ease of maintenance Use common programming constructs and consistent naming conventions Loose coupling Reduce interdependencies within the code Extensibility Minimal ripple effect when changes are made Reusability Modules, components, & subsystems can be and are reused Minimal complexity The primary goal of design should be to minimize complexity for all the reasons provided earlier. Avoid making "clever" designs. Clever designs are usually hard to understand. Instead make "simple" and "easy-to-understand" designs. If your design doesn't let you safely ignore most other parts of the program when you're immersed in one specific part, the design isn't doing its job. Ease of maintenance Ease of maintenance means designing for the maintenance programmer. Continually imagine the questions a maintenance programmer would ask about the code you're writing. Think of the maintenance programmer as your audience, and then design the system to be self-explanatory. This includes using common programming constructs and consistent naming conventions. Loose coupling Loose coupling means designing so that you hold connections among different parts of a program to a minimum. Use the principles of good abstractions in class interfaces, encapsulation, and information hiding to design classes with as few interconnections as possible. Minimal connectedness minimizes work during integration, testing, and maintenance. Extensibility Extensibility means that you can enhance a system without causing violence to the underlying structure. You can change a piece of a system without affecting other pieces. The most likely changes cause the system the least trauma. Ideally, changes will have minimal ripple effect and certainly won’t have tidal wave effect. Reusability Reusability means designing the system so that you can reuse pieces of it in other systems. [SM04] pp Module IV - Software Construction Module IV - Software Construction

36 B. Code Design - 6 Desirable Design Characteristics (cont.)
High fan-in Highly utilized classes Low to medium fan-out Call tree not to large Portability Able to be redeployed in a different environment Leanness No extra parts Stratification Consistent levels of abstraction across subsystems Standard techniques Stay with the “tried and true” High fan-in High fan-in refers to having a high number of classes that use a given class. High fan-in implies that a system has been designed to make good use of utility classes at the lower levels in the system. Low to medium fan-out Low to medium fan-out means having a given class use a low to medium number of other classes. High fan-out (more than about seven) indicates that a class uses a large number of other classes and may therefore be overly complex. Researchers have found that the principle of low fan-out is beneficial whether you're considering the number of routines called from within a routine or from within a class. Portability Portability means designing the system so that you can easily move it to another environment. Leanness Leanness means designing the system so that it has no extra parts. Voltaire said that a book is finished not when nothing more can be added but when nothing more can be taken away. In software, this is especially true because extra code has to be developed, reviewed, tested, and considered when the other code is modified. Future versions of the software must remain backward-compatible with the extra code. The fatal question is "It's easy, so what will we hurt by putting it in?" Stratification Stratification means trying to keep the levels of decomposition stratified so that you can view the system at any single level and get a consistent view. Design the system so that you can view it at one level without dipping into other levels. For example, if you're writing a modern system that has to use a lot of older, poorly designed code, write a layer of the new system that's responsible for interfacing with the old code. Design the layer so that it hides the poor quality of the old code, presenting a consistent set of services to the newer layers. Then have the rest of the system use those classes rather than the old code. The beneficial effects of stratified design in such a case are (1) it compartmentalizes the messiness of the bad code and (2) if you're ever allowed to jettison the old code or refactor it, you won't need to modify any new code except the interface layer. Standard techniques The more a system relies on exotic pieces, the more intimidating it will be for someone trying to understand it the first time. Try to give the whole system a familiar feeling by using standardized, common approaches. [SM04] pp Module IV - Software Construction Module IV - Software Construction

37 Module IV - Software Construction
B. Code Design - 7 Levels of Design 5 levels of abstraction in software design: Level 1 – Software System Level 2 – Subsystems Level 3 – Classes Level 4 – Routines Level 5 – Internal Routine Design Design is needed at several different levels of detail in a software system. Some design techniques apply at all levels, and some apply at only one or two. If your approach is top-down, you’ll start at level 1 and proceed through level 5. Conversely, level 5 is the lowest, so if your approach is bottom-up, you will start here. The next slides will detail the 5 levels of software design. [SM04] p. 81 Module IV - Software Construction Module IV - Software Construction

38 B. Code Design - 8 Level 1 – Software System The entire system
Concern of the architect, not detailed designer Unless system is extremely small Level 1 is the entire system as a whole. Focus on this level is the main concern of the architect, not necessarily the detailed designer, unless the system is relatively small and not overly complex. [SM04] p. 82 Module IV - Software Construction Module IV - Software Construction

39 Module IV - Software Construction
B. Code Design - 9 Level 2 – Subsystems Identify all major subsystems I.e. identity the architectural layers and the contents in each layer Major design activities at this level are Partition the program into major subsystems Define subsystem interfaces The goal at this level is to identify all major subsystems. Some commons subsystem examples include: Operating system services interface The database User interface components Business rules Command interpreter Report engine Communications The major design activities at this level are Partition the program into major subsystems Define how each subsystem is allowed to use each other subsystem, i.e. defining the interfaces. Level 2 activities are necessary on any project that takes longer than a few weeks. Within each subsystem, different methods of design can be used. Use the most appropriate technique for the job Define rules on how the various subsystems can communicate. If all subsystems communicate with all other subsystems, the benefit of separating them is lost. One way to achieve this is through a layered-architecture, where any layer can only communicate with an adjacent layer. [SM04] p Module IV - Software Construction Module IV - Software Construction

40 Module IV - Software Construction
B. Code Design - 10 Level 3 – Classes Identify all classes by subsystem Define class relationships Generalizations Dependencies Associations For each class, define its interface Design at this level includes identifying all classes in the system. For example, a database-interface subsystem might be further partitioned into data access classes and persistence framework classes as well as database metadata. Relationships between classes are defined at level 3. In UML terms, this includes generalizations, dependencies, and associations. Finally, the interface for each class is defined in order to describe the class’s externally visible behavior. In summary, level 3 provides details to each subsystem by defining the subsystems’ classes, relationships between classes, and the interface for each class [SM04] p. 86 Module IV - Software Construction Module IV - Software Construction

41 Module IV - Software Construction
B. Code Design - 11 Level 4 – Routines Define the routines for each class Previously defined interfaces will help Need to also identify internal routines Level 4 activities may necessitate a return to Level 3 to further define the interface This is normal and encouraged in an iterative development approach Design at this level includes defining routines (a.k.a methods) for each class. The routines defined via the class interface defined at Level 3 will define the routines that describe the behavior that is visible outside of the class but addition internal (class-private) routines can be defined. Activities in level 4 may require a return to level 3 in order to make modifications to the interface. It is normal to iterate between interface definition and class-private routines definition. [SM04] p. 86 Module IV - Software Construction Module IV - Software Construction

42 B. Code Design - 12 Level 5 – Internal Routine Design
Lay out the detailed functionality of each routine Closest activity to programming This includes: Deciding program flow, perhaps by writing pseudocode Choosing algorithms Determining program calls Determining return points Inserting programming constructs such as loops and case statements Here are the set of design activities that is closest to programming -- laying out the detailed functionality of the individual routines. This includes: Deciding program flow, perhaps by writing pseudocode Choosing algorithms Determining program calls Determining return points Inserting programming constructs such as loops and case statements [SM04] p. 87 Module IV - Software Construction Module IV - Software Construction

43 Module IV - Software Construction
B. Code Design - 13 Design Techniques Find Real-World Objects Form Consistent Abstractions Encapsulate Implementation Details Apply Inheritance Hide Internal Information Identify Areas Likely to Change Ensure Loose Coupling Apply Design Patterns The following slides provide a list of design techniques (McConnell refers to these as heuristics) that can improve any software design. These are: Find Real-World Objects Form Consistent Abstractions Encapsulate Implementation Details Apply Inheritance Hide Internal Information Identify Areas Likely to Change Ensure Loose Coupling Apply Design Patterns Miscellaneous Heuristics [SM04] pp Module IV - Software Construction Module IV - Software Construction

44 Module IV - Software Construction
B. Code Design - 14 More Techniques Aim for Strong Cohesion Build Hierarchies Formalize Class Contracts Assign Responsibilities Design for Test Avoid Failure Choose Binding Time Consciously Make Central Points of Control Consider Using Brute Force Draw a Diagram Keep Your Design Modular Additional techniques suggested by McConnell [SM04] pp Module IV - Software Construction Module IV - Software Construction

45 Module IV - Software Construction
B. Code Design - 15 Design Approaches Iterate Don’t stagnate in any one activity Instead, cycle through activities and return to the beginning Build on previous work Divide and Conquer Divide problem into more manageable chunks Prototype Create a “quick and dirty” version of the application Provides insight into the problem Collaborative Design Two (or more) heads is better than one Can be formal or informal Iterative: Cycle through high-level and low-level views and you’ll be able to put both into perspective. By moving on you gain a renewed perspective that can help facilitate arrival at an appropriate solution. Each pass through the design activities will result in incremental work, so visible progress will be made. Divide and Conquer: Manage complexity by dividing the problem into “chunks”. But where do you start? Two general approaches are top-down and bottom-up. A top-down approach is appropriate then the problem is generally understood and can be decomposed into more and more lower level elements. A bottom-up approach is appropriate when the problem is so large or not well understood that it’s difficult to know where to start. This way you can drill down on some area that is understood, conquer that, and then move onwards and upwards. Prototype: Sometimes it is helpful to actually build a “quick and dirty” version of the application, or some piece of the application, in order to gain a more detailed understanding of the problem. Much like a model, a prototype can provide insight into the problem itself, and therefore aid in the creation of the solution. Collaborative Design: Instead of a single designer working on a piece of the application, two designer collaborate on the design. This increases the brainpower and adds another perspective of the solution. [SM04] pp Module IV - Software Construction Module IV - Software Construction

46 Module IV - Software Construction
B. References [IE04] IEEE Computer Society, Guide to the Software Engineering Body of Knowledge (SWEBOK), IEEE Computer Society Press, Los Alamitos, CA 20001, June 2004 [SM04] S. McConnell, Code Complete: A Practical Handbook of Software Construction, Second Edition, Microsoft Press, 2004. Module IV - Software Construction

47 Module IV - Software Construction
B. Quiz – 1 The issues related to the software crisis include: a) Ineffective development practices b) Inherent complexities of application development c) Poor application quality 1) a & b 2) a & c 3) a 4) All of the above 4) All of the above Module IV - Software Construction Module IV - Software Construction

48 Module IV - Software Construction
B. Quiz – 2 Levels of design deal with the: a) Levels of abstraction within an application b) Levels of abstraction within a subsystem c) Levels of abstraction within a class d) Levels of abstraction within a routine 1) a 2) b 3) c 4) d 1) a Module IV - Software Construction Module IV - Software Construction

49 Module IV - Software Construction
B. Quiz – 3 Subsystems are synonymous with architecture layers. a) True b) False b) False Module IV - Software Construction Module IV - Software Construction

50 Module IV - Software Construction
B. Quiz – 4 Level 5 - Internal Routine Design includes: a) Deciding program flow b) Coding algorithms c) Writing pseudocode 1) a 2) b 3) c 4) a & c 4) a & c Module IV - Software Construction Module IV - Software Construction

51 C. Data Design And Management
What is Data Design? A method used to define and analyze data requirements needed to support the business functions of an enterprise. These data requirements are recorded as a conceptual data model with associated data definitions. Data Design defines the relationships between data elements and structures. What is Data Management? The act of ensuring database integrity, security, performance, and recovery of data. Topic estimate: 33 minutes Also, Data Design and Management is a method used to define and analyze data requirements needed to support the business functions of an enterprise. These data requirements are recorded as a conceptual data model with associated data definitions. Data modeling defines the relationships between data elements and structures. Module IV - Software Construction Module IV - Software Construction

52 C. Data Design And Management - 2
Stages of Data Modeling The data model evolves through three stages Conceptual High level key entities and their relationships Logical Refinement of the conceptual model into more detailed logical entities Physical Detailed and optimized phyiscal database table designs The data model typically evolves through the following three general stages: Conceptual: This stage involves the identification of the high level key business and system entities and their relationships that define the scope of the problem to be addressed by the system. These key business and system entities are defined using the modeling elements of the UML profile for business modeling included in the Business Analysis model and the Analysis Class model elements of the Analysis model. Logical: This stage involves the refinement of the conceptual high level business and system entities into more detailed logical entities. These logical entities and their relationships can be optionally defined in a Logical data model using the modeling elements of the UML profile for database design as described in Guidelines: data model. This optional Logical data model is part of the Artifact: data model and not a separate RUP artifact. Physical: This stage involves the transformation of the logical class designs into detailed and optimized physical database table designs. The physical stage also includes the mapping of the database table designs to tablespaces and to the database component in the database storage design. [RS04] Module IV - Software Construction Module IV - Software Construction

53 C. Data Design And Management - 3
Conceptual Data Modeling Initial stage of database design High-level definition of persistent data and its storage Business model provides business and system entities Starting point in the evolution of the data model Can be represented by an Entity-Relationship (ER) model Graphically via ER diagrams Conceptual data modeling represents the initial stage in the development of the design of the persistent data and persistent data storage for the system.  In many cases, the persistent data for the system are managed by a relational database management system (RDBMS). The business and system entities identified at a conceptual level from the business models and system requirements will be evolved via database design activities into detailed physical table designs that will be implemented in the RDBMS. An Entity-Relationship (ER) model is commonly used to represent the conceptual data model (as well as the logical and physical model). The ER model contains one or more diagrams that show entities and their relationships and is called the Entity-Relationship Diagram (ERD). [RS04] [UT04] Module IV - Software Construction Module IV - Software Construction

54 C. Data Design And Management - 4
Logical Data Modeling Provides idealized view of key logical data entities and relationships Independent of any software or database implementation Useful for modeling data structures to be shared across applications Obtain buy-in from relevant stakeholders in order to “get it right” Reduces risk Not always necessary, especially for small data needs Can skip the conceptual and logical model and start with physical The purpose of the Logical data model is to provide an idealized view of the key logical data entities and their relationships that is independent of any specific software or database implementation. It is generally in third normal form, which is a data-modeling form that minimizes redundancy and ensures no transitive dependencies. Such a model is concerned with what the database will look like when capturing data, rather than with the applications that use the data and their performance. Note that a Logical data model is considered to be part of the Artifact: data model and is not a separate RUP artifact. However, it is often important to define individual Logical data models for: Projects in which the database and application designs are being developed by separate teams Projects in which there are multiple applications that will share a common database If you are creating a logical data model, you can start from scratch, or you can begin by starting with entities for each persistent class in the analysis model or design model. You might decide not to create a separate logical data model, especially if you are designing a database that serves a single application. In this case, the database designer develops the physical data model based on the set of persistent classes and their associations in the design model. In either approach, it is important for the database designer and the designer to collaborate throughout the analysis and design process to identify which classes in the design model need to store information in a database. As described in the step titled, "Identify persistent classes of the class design," the database designer works with the designer to identify which design classes in the design model are considered to be persistent and are potential candidates for becoming tables in the database. [RS04] Module IV - Software Construction Module IV - Software Construction

55 C. Data Design And Management - 5
Physical Data Design Define the detailed physical design of the database Tables Views Stored procedures Steps to create the physical data model: Define domains Create initial physical database design elements Define reference tables Create primary key and unique constraints Define data and referential integrity enforcement rules De-normalize database design Optimize data access Define storage characteristics Design stored procedures Develop Physical Database Design Purpose: Define the detailed physical design of the database The physical database design includes model elements (such as tables, views, and stored procedures) that represent the detailed physical structure of the database and model elements (such as schemas and tablespaces) that represent the underlying data storage design of the database. Collectively, these model elements comprise the physical data model of the database. This physical data model is contained in the data model and is not a separate model artifact. The detailed steps for developing the physical database design are as follows: Define domains Create initial physical database design elements Define reference tables Create primary key and unique constraints Define data and referential integrity enforcement rules De-normalize database design to optimize for performance Optimize data access Define storage characteristics Design stored procedures to distribute class behavior to the database The database designer models the physical data model elements using tables and columns in tables, as described in data model. If a logical data model has been created, then its logical entities can be used as the basis for an initial set of tables. Alternatively, the database designer might jump-start the physical data model by using the persistent classes in the design model as a starting point for tables in the physical data model. The database designer models the persistent classes and their attributes as tables and columns respectively. The database designer also needs to define the relationships between the tables based on the associations between the persistent classes in the design model. If you are starting the model from persistent classes rather than from a normalized logical data model, then you will generally need to apply some normalization in order to eliminate data redundancies and non-key field dependencies. [RS04] Module IV - Software Construction Module IV - Software Construction

56 C. Data Design And Management - 6
Define Domains A domain is used to enforce data type standards Definitions of user-defined data types Enhances interoperation across applications Example: day_of_week column defined as: MON, TUE, WED, THU, FRI, SAT, SUN A domain would limit possible values in this column to these values Define Domains Purpose: To define reusable user-defined types. Domains might be used by the database designer to enforce type standards throughout the database design. Domains are definitions of user-defined data types that can be applied to a column in a table. Domains have the properties of a column without the name. Domains are useful for defining standard data types in order to enhance interoperation across applications. For example, it would be beneficial that a customer record be defined is such a way that the billing system, sales/distribution system, and customer support system all see the data in the same format because the data is always in a single format, as defined in the domain. [RS04] Module IV - Software Construction Module IV - Software Construction

57 C. Data Design And Management - 7
Create Initial Elements Initial elements are tables and relationships Columns are defined for each table Logical entities from logical data model can be used as starting point for creating tables Or, persistent classes from the design model CustID Name Phone Zip 2332 Mary Martin (931) 23993 4048 Joe Denver (231) 64412 6301 Peg Thrush (721) 49921 4893 Amy Meyer (818) 83845 2943 Curt Sanchez (319) 73814 Create Initial Physical Database Design Elements Purpose: Create the initial database tables and relationships. The database designer models the physical data model elements using tables and columns in tables. If a logical data model has been created, then its logical entities can be used as the basis for an initial set of tables. Alternatively, the database designer might jump-start the physical data model by using the persistent classes in the design model as a starting point for tables in the physical data model. The database designer models the persistent classes and their attributes as tables and columns respectively. The database designer also needs to define the relationships between the tables based on the associations between the persistent classes in the design model. If you are starting the model from persistent classes rather than from a normalized logical data model, then you will generally need to apply some normalization in order to eliminate data redundancies and non-key field dependencies. [RS04] Module IV - Software Construction Module IV - Software Construction

58 C. Data Design And Management - 8
Define Reference Tables Reference table: Frequently-accessed tables whose data changes infrequently Used to optimize access to data in the database Examples: Standard product codes 2 character U.S. state codes Conversion rates Postal codes Reference tables can reduce disk I/O and and increase database performance Define Reference Tables Purpose: To define standard reference tables used across the project. Often there are standard look-up tables, validation tables, or reference tables used throughout the project. Since the data in these tables tends be frequently accessed but seldom-changing, that data is worth special consideration. In the design model, these tables might contain standard product codes, state or province codes, postal or zip codes, tax tables, area code validation tables, or other frequently accessed information. In financial systems, these tables might contain lists of policy codes, insurance policy rating categories, or conversion rates. Look in the design model for classes that are primarily read-only, providing validation information for a large number of clients. If the reference table is small, do not bother to index it, since indexing might actually add additional overhead for small tables. A small, frequently accessed table also tends to remain in memory, because caching algorithms often keep frequently accessed tables in the data cache. If possible, make sure that the database cache is large enough to keep all reference tables in memory, along with normal "working set space" for queries and transactions. One technique to increasing database performance is reducing disk I/O. Once the reference table structures are defined, determine a strategy for populating the reference tables. Since these tables are accessed near the beginning of the project, determining the reference values and loading the tables often need to occur relatively early during application runtime. While the database designer is not responsible for obtaining the data, he or she is responsible for determining how and when the reference tables will be refreshed. [RS04] Module IV - Software Construction Module IV - Software Construction

59 C. Data Design And Management - 9
Create Primary Key & Unique Constraints Purpose of primary keys: Define the one or more columns that uniquely identify a row in the table Purpose of unique constraint: Define constraints on columns that guarantee the uniqueness of the data or collection of data One primary key per table Choose a non-meaningful, non-user-entered column, if possible A unique constraint designates that the data in the column is unique per row. A Customer_ID column frequently has a unique constraint to ensure unique IDs Create Primary Key and Unique Constraints Purpose: To define the one or more columns that uniquely identify a row in the table. To define constraints on columns that guarantee the uniqueness of the data or collection of data. A primary key is one or more columns that uniquely identify rows in a table. A table has a single primary key. There is often a "natural" key that can be used to uniquely identify a row of data (for example, the postal code in a reference table). The primary key should not contain data that might change with the business environment. If the "natural" key is a value that can change (for example a person's name), then it is recommended that the database designer create a single non-meaningful, non-user-entered column when creating a primary key. This creates a data structure that has greater adaptability to changes in the business structure, rules, or environment. The use of a non-meaningful, non-user-entered column as the primary key is an essential concept in designing a data warehouse. Transactional systems often choose a "natural" primary key that might be subject to minimal change over a non-meaningful, non-user-entered column. A unique constraint designates that the data in the column or collection of columns is unique per row. If the unique constraint is on a column, the data in a specific row in the specified column must be unique from the data in a different row in the same column. When a unique constraint is defined for a group of columns, the uniqueness is based on the collective whole of the data in the columns that make up that unique constraint. The data in a specific row in a specific column does not have to be unique from the data in a different row in the same column. The database designer uses the unique constraint to ensure uniqueness of business data. [RS04] Module IV - Software Construction Module IV - Software Construction

60 C. Data Design And Management - 10
Define Rules Purpose: To ensure the integrity of the database Data integrity rules also know as constraints Ensure data values are within allowed ranges Foreign key is one or more columns in a table that map to the primary key in another table One table could have many foreign keys Each foreign key maps to a different table Each foreign key maps to a primary key in a different table Define Data and Referential Integrity Enforcement Rules Purpose: To ensure the integrity of the database. Data integrity rules, also known as constraints, ensure that data values lie within defined ranges. Where these ranges can be identified, the database can enforce them. (This is not to say that data validation should not be done in the application, but only that the database can serve as a "validator of last resort" in the event that the application does not work correctly). Where data validation rules exist, the database constraints must be designed to enforce them. A foreign key is one or more columns in a table that map to the primary key in another table. One table might have many foreign keys, and each foreign key is a map to a different table. This mapping, or relationship, between the tables is often referred to as a parent-child relationship. The child table contains the foreign key, which maps to the primary key in the parent table. The definition of foreign key constraints is also often used by the query optimizer to accelerate query performance. In many cases, the foreign key enforcement rules use reference tables. [RS04] Module IV - Software Construction Module IV - Software Construction

61 C. Data Design And Management - 11
De-normalize Database De-normalizing optimized the data structures to increase performance Reduces number of table joins the DBMS has to do by combining certain tables Reduces access time but can increase update time De-Normalize Database Design to Optimize for Performance Purpose: To optimize the database data structures for performance. In the case of a relational data model, the initial mapping generally yields a simple class-to-table mapping. If objects from different classes need to be retrieved at the same time, the RDBMS uses an operation called a "table join" to retrieve the rows related to the objects of interest. For frequently accessed data, join operations can be computationally expensive. To eliminate the cost of the join, a standard relational technique called "de-normalization" is often employed. De-normalization combines columns from two or more different tables into the same table, effectively pre-joining the information. De-normalization reflects a tradeoff between more-expensive update operations in favor of less-expensive retrieval operations. This technique also reduces the performance of the system in queries that are interested only in the attributes of one of the objects that are effectively joined in the de-normalized table, since all attributes are normally retrieved on every query. For cases in which the application normally wants all attributes, there can be a significant performance improvement. De-normalizing more than two tables is rare and increases the cost of inserts and updates as well as the cost of non-join queries. Limiting de-normalization to two tables is a good policy unless strong and convincing evidence can be produced regarding the benefits. De-normalization can be inferred from the design classes in cases in which classes are nested. Nested classes can be mapped to a de-normalized table.Some object databases allow a concept similar to de-normalization, in which related objects are clustered together on disk and retrieved in single operations. The concept in use is similar: Reduce object retrieval time by reducing the work the system must do in order to retrieve related objects from the database. In some cases, optimizing the data model can unmask problems in the design model, including performance bottlenecks, poor modeling, or incomplete designs. In this event, discuss the problems with the designer of the class, triggering change requests where appropriate. [RS04] Module IV - Software Construction Module IV - Software Construction

62 C. Data Design And Management - 12
Optimize Data Access Use indexing and database views for better data access Indexing Requires knowledge of how data will be accessed Can have large impact on performance Views A virtual table Contains data from multiple tables Decreases time to select data Especially for heavily queried tables Can increase security by restricting access to data Optimize Data Access Purpose: To provide for efficient data access using indexing. To provide for efficient data access using database views. Once the table structure has been designed, you must determine the types of queries that will be performed against the data. Indexing is used by the database to speed access. Indexing is most effective when the data values in the column being indexed are relatively distinct. Your choice of indexing strategy and timing of index creation can have a large impact on performance. Bulk data loads should be performed without indexes (this can be achieved by dropping the index, loading the data, and then re-creating the index). The reason for this is that the index structure is re-balanced as each row is added. Since subsequent rows will change the optimal index structure, the work done re-balancing the index as each row is inserted is largely wasted. It is faster and more efficient to load data without indexes, then re-create the index when the data load is done. Some databases provide bulk data-loaders to do this automatically. Another strategy for optimizing database access performance is the use of views. Database views are virtual tables that have no independent storage of their own. To the calling program (or user), however, a view behaves like a table. A view supports retrieval of data, and it can be used to update data as well-depending on the database structure and database vendor. The view contains data from one or more tables that can be accessed through a single select statement. The performance gain occurs during the selection of data, especially in frequently queried tables. The data is retrieved from a single location (the view) instead of by searching the multiple or large tables that exist in the database. Views also play a significant role in database security. A view containing parts of a table can restrict access to sensitive data contained in the base table. [RS04] Module IV - Software Construction Module IV - Software Construction

63 C. Data Design And Management - 13
Define Storage Characteristics Design space allocation Design disk page organization Tablespaces Take advantage of block disk I/O Allow specification of physical data layout Define Storage Characteristics Purpose: To design the space allocation and disk page organization of the database. A database designer uses tablespaces to represent the amount of storage space that is allocated to tables, indexes, stored procedures, and so forth. One or more tablespaces are mapped to a database. The database designer must analyze the tables in the data model to determine how to distribute them, along with other support database elements, across the storage space in the database. In determining the tablespace structures for the database, bear in mind that databases do not perform I/O on rows, records, or even whole tables. Instead they perform I/O on disk blocks. The reason for this is simple: Block I/O operations are usually optimized in the software and hardware on the system. As a result, the physical organization of the tables and indexes in the database can have a dramatic impact on the performance of the system. When planning the space allocation and disk page organization of the database, consider the following factors: The density of information in the disk pages The location of disk pages on disk and across disk drives The amount of disk space to allocate to the table [RS04] Module IV - Software Construction Module IV - Software Construction

64 C. Data Design And Management - 14
Design Stored Procedures Stored procedure: Executable code that runs on the database server Performs database-related actions on the server Without having to transfer data across a network Triggers are a special case of stored procedures Triggers invoked implicitly based on some event Design Stored Procedures to Distribute Class Behavior to the Database Purpose: To determine if the stored procedures or triggers should be used to implement data access class operations. Most databases support a stored procedure capability. A stored procedure is executable code that runs within the process space of the database management system. It provides the ability to perform database-related actions on the server without having to transfer data across a network. The judicious use of stored procedures can the improve performance of the system. Stored procedures are usually one of these two types: actual procedures or triggers. Procedures are executed explicitly by an application, generally have parameters, and provide an explicit return value. Triggers, on the other hand, are invoked implicitly when some database event occurs (for example, insert a row, update a row, or delete a row), have no parameters other than the row being modified (since they are invoked implicitly), and do not provide an explicit return value. In database systems that lack constraints, triggers are often used to enforce referential and data integrity. Otherwise, they tend to be used when an event needs to trigger (or cause) another event. Triggers are also frequently used for security purposes by auditing the trigger event. The design classes in the design model must be examined to see if they have operations that should be implemented using the stored procedure or trigger facility. Candidates include: any operations that primarily deal with persistent data (creating, updating, retrieving, or deleting it). any operations in which a query is involved in a computation (such as calculating the average quantity and value of a product in inventory). operations that must access the database in order to validate data. Remember that improving database performance usually means reducing I/O. Therefore, if performing a computation on the DBMS server will reduce the amount of data passed over the network, the computation should probably be performed on the server. Work with the designer of the design class to discuss how the database can be used to improve performance. The designer will update the operation method to indicate whether one or more stored procedures can be used to implement the operation. [RS04] Module IV - Software Construction Module IV - Software Construction

65 C. Data Design And Management - 15
Review Results The final step in a data design iteration Assesses the completeness and quality of work to date Ensure that the data model and physical implementation are in sync Discrepancies and other issues are noted and fixed If the fixes are deferred, the issue should be tracked as a change request Review the Results Purpose: To ensure the quality and integrity of the data model Just as with many other activities in software development, performing data design is effectively an iterative process. Continuously throughout this activity, you must consider the data model to assess the completeness and quality of the effort.  Furthermore, the database designer must regularly review the implemented structure of the database to ensure that the data model is consistent with any changes that have been made directly in the database.  If the project is using data-modeling tools that support synchronization of the data model with the physical structure of database, the database designer must periodically check the state of the data model with the database and makes adjustments as needed.  Identified defects that will not be corrected at this time must be documented in as a change request and eventually assigned to someone to own and drive to resolution. Module IV - Software Construction Module IV - Software Construction

66 Module IV - Software Construction
C. References [RS04] IBM Rational Software, The Rational Unified Process v , 2004 [UT04] University of Texas at Austin, “Introduction to Data Modeling”, -datamodeling, 2004 Module IV - Software Construction

67 Module IV - Software Construction
C. Quiz – 1 Which of the following is not part of data management? a) Data integrity b) Security c) User access d) Performance e) Data recovery 1) a 2) b 3) c 4) All are aspects of data management 4) All are aspects of data management Module IV - Software Construction Module IV - Software Construction

68 Module IV - Software Construction
C. Quiz – 2 The 3 stages of data modeling include: a) Conceptual b) Preliminary c) Detailed d) Logical e) Physical 1) b, c, & e 2) b, c, & d 3) a, d, & e 4) a, b, & c 3) a, d, & e Module IV - Software Construction Module IV - Software Construction

69 Module IV - Software Construction
C. Quiz – 3 Entity Relationship Diagrams are useful for which data modeling stage? a) Preliminary b) Detailed c) Logical 1) a & b 2) b only 3) c only 4) All stages 4) All stages Module IV - Software Construction Module IV - Software Construction

70 Module IV - Software Construction
C. Quiz – 4 A database domain is used for what purpose? a) Enforce data standards b) Group frequently used tables c) Logically group tables d) Define client access 1) a 2) b 3) c 4) d 1) a Module IV - Software Construction Module IV - Software Construction

71 Module IV - Software Construction
C. Quiz – 5 The benefit of a de-normalized database is: a) Reduce update time b) Reduce access time c) Reduce number of tables 1) a 2) b 3) a & c 4) b & c 2) b Module IV - Software Construction Module IV - Software Construction

72 Module IV - Software Construction
D. Error Processing Software error: A human action that results in software containing a fault [ANSI/IEEE Standard ] Software fault: 1. An accidental condition that causes a functional unit to fail to perform its required function 2. A manifestation of an error in software [ANSI/IEEE Standard ] Software failure: 1. The inability of a system or system component to perform a required function within specified limits. A failure may be produced when a fault is encountered. 2. A departure of program operation from program requirements. Topic estimate: 7 minutes A human makes a software error that creates a fault that may result in a software failure. It all starts with a human mistake For more information: McConnell, Steve, Code Complete, Microsoft Press, Redmond, WA, 1983, pp Module IV - Software Construction Module IV - Software Construction

73 Module IV - Software Construction
D. Error Processing - 2 Debugging Debugging: The Process of correcting syntactic and logical errors detected during coding. -- With the primary goal of obtaining and executing a piece of code, debugging shares the testing of certain techniques and strategies but differs in its usual ad hoc application and local scope. [FIPS Publication 101, 1983] The Process of locating, analyzing, and correcting suspected faults. Sometimes synonymous with unit testing. A bug is an euphemism for fault (error) Debugging is associated with coding in that it is normally done by the coder who built the code Therefore, debugging is the search for faults, i.e. testing Testing is the process of executing a computer program for the purpose of finding faults For more information: McConnell, Steve, Code Complete, Microsoft Press, Redmond, WA, 1983, pp Debugging is the process of identifying the root cause of an error and correcting it. It contrasts with testing, which is the process of detecting the error initially. On some projects, debugging occupies as much as 50% of the total development time. For many programmers, debugging is the hardest part of programming. Debugging doesn’t have to be the hardest part. If you follow some advice, debugging can be the easiest part. You’ll have few errors to debug. Most of the errors you will have will be minor oversights and typos, easily found by looking at a source-code listing or stepping through the code in a debugger. Module IV - Software Construction Module IV - Software Construction

74 Learning how to debug a computer program
D. Error Processing - 3 Learning how to debug a computer program General methods -- Learn in-depth how the program you are working on operates -- Learn the kinds of mistakes you typically make -- Learn how to solve software problems Solving software problems -- Stabilize the error : Otherwise it is almost impossible to fix -- Locate the source of the error : Through creative testing -- Fix the error : Determine the impact on other areas of the program -- Test the fix : Use regression testing -- Look for similar errors : They probably exist For more information: McConnell, Steve, Code Complete, Microsoft Press, Redmond, WA, 1993, p. 628 The steps involved in the Scientific method of debugging are Gather data through repeatable experiments Form a hypothesis that accounts for as much of the relevant data as possible Design an experiment to prove or disprove the hypothesis Prove or disprove the hypothesis Repeat as needed. This process has many parallels in debugging. Here’s an effective approach for finding an error Stabilize the error Locate the source of the error Fix the error Test the fix Look for similar errors The first step is similar to the scientific method’s first step in that it relies on repeatability. The defect is easier to diagnose if you can make it occur reliably. The second step uses all the steps of the scientific method. You gather the test data that divulged the error, analyze the data that has been produced, and form hypothesis about the source of the error. You design a test case or an inspection to evaluate the hypothesis and then declare success or renew your efforts as appropriate. Module IV - Software Construction Module IV - Software Construction

75 Module IV - Software Construction
D. References McConnell, Steve, Code Complete: A Practical Handbook of Software Construction, Microsoft Press, Redmond, WA, 1983, Chapter 26, pp ANSI/IEEE Standard FIPS Publication 101, 1983 Module IV - Software Construction

76 Module IV - Software Construction
D. Quiz 1) The simplest type of construction language is a) Programming language b) Toolkit language c) Configuration language d) Formal language 2) The language in which software engineers choose from a limited set of predefined options to create new or custom software installations is a) Formal language b) Configuration language c) Toolkit language d) Programming language Answers: C B Guide to the software engineering body of knowledge (SWEBOK) – chapter 4, Section 3.2 Module IV - Software Construction Module IV - Software Construction

77 E. Source Code Organization
Code that needs order Order counts if the statement must be executed in a particular order -- For example, if there is a need to read a record before it can be written Make order obvious through: -- Naming the routines so order is obvious -- Use routine parameters to reflect the execution order Document the dependency between parts of the code The strongest principle for organizing straight-line code is order dependencies Dependencies should be made obvious through the use of good routine names, parameter lists and comments. Topic estimate: 4 minutes If code doesn’t have order dependencies, you should keep related statements as close together as possible-especially statements that work with the same variables. Module IV - Software Construction Module IV - Software Construction

78 E. Source Code Organization - 2
Other reasons for organizing code Keep related statements together -- That operate on the same data -- That perform similar tasks -- That depend on each other being performed in order Assign variables close to where they will be used Keep variables live for as short a time as possible -- Measure the live time of a variable -- A short live time makes your code more readable Make sure readability is consistent from top to bottom For more information: McConnell, Steve, Code Complete, Microsoft Press, Redmond, WA, 1993, pp Although organizing straight-line code is a relatively simple task, some subtleties of organization influence code quality, correctness, readability, and maintainability. Module IV - Software Construction Module IV - Software Construction

79 Module IV - Software Construction
E. References McConnell, Steve, Code Complete: A Practical Handbook of Software Construction, Microsoft Press, Redmond, WA, Chapter 13, Pages Module IV - Software Construction

80 Module IV - Software Construction
E. Quiz 1) How many forms of testing does construction involves? a) 4 b) 3 c) 2 d) 1 2) The purpose of _________ testing is to reduce the gap between the time at which faults are inserted into the code and the time those faults are detected? a) Unit testing b) Construction testing c) Integration testing d) Design testing Answers C B Guide to the software engineering body of knowledge (SWEBOK) – chapter 4, Section 3.4 Module IV - Software Construction Module IV - Software Construction

81 Types of Documentation
F. Code Documentation Types of Documentation Good documentation is a sign of professional pride by the programmer (coder) Documentation might be inside or outside the source code Outside (external) documentation is classically a: -- Users’ manual -- Operator’s manual (most recently combined with User’s manuals) -- Maintenance manual Outside documentation tends to be of the high-level (more abstract) type Inside documentation tend to be of the low-level (more concrete) type Topic estimate: 15 minutes For more information: McConnell, Steve, Code Complete, Microsoft Press, Redmond, WA, 1993, pp Most programmers enjoy writing documentation if the documentation standards aren’t unreasonable. Like layout, good documentation is a sign of the professional pride a programmer puts into a program. Software documentation can take many forms, and after describing the sweep of the documentation landscape, self-documenting code cultivates the specific patch of documentation known as “comments”. Module IV - Software Construction Module IV - Software Construction

82 Module IV - Software Construction
F. Code Documentation - 2 Inside documents are of two types: -- Online help manuals -- Commented code Outside documents are a number of different types, two of which are: -- Software design documents (SDD) – A design specification which can be based on IEEE Standard -- Unit development folder -- Based on work by Frank Ingrassia originally written in 1977 F.S. Ingrassia , “The unit Development Folder (UDF): A Ten year Perspective,” In Richard H. Thayer (ed.), Software Engineering Project Management, IEEE Computer Society Press, Los Alamitos, CA (Also see: McConnell, p.454) . Unit development folders: A UDF, or software development folder (SDF) is an informal document that contains notes used by a developer during construction. A “unit” is loosely defined, usually to mean either a routine or a module. The main purpose of a UDF is to provide a trail of design decisions that aren’t documented elsewhere. Many projects have standards that specify the minimum content of a UDF, such as copies of the relevant requirements, the parts of the top-level design the unit implements, a copy of the development standards, a current code listing, and design notes from the unit’s developer. Sometimes the customer requires a software developer to deliver the project’s UDFs; often they are for internal use only Module IV - Software Construction Module IV - Software Construction

83 Detailed Design Documentation
F. Code Documentation - 3 Detailed Design Documentation Detailed design can be a high-level design document (architectural design) or a low-level design document (detailed design document): Detailed design documents contain: --Identification –The name of the design entity. -- Type – A description of the kind of design entity -- Purpose – A description of why the design entity exists -- Function – A Statement of what the design entity does -- Subordinates – The identification of all entities composing this design entity IEEE Std , IEEE Recommended Practice for Software Design Descriptions, IEEE, Inc., Piscataway NJ, 1998 Module IV - Software Construction Module IV - Software Construction

84 Module IV - Software Construction
F. Code Documentation - 4 Detailed design documents contain (continued) -- Dependencies – A description of the relationships of this design entity with other entities -- Interface – A description of how other entities interact with this design entity. -- Resources – A description of the elements used by the design entity that are external to the design -- Processing – A description of the rules used by the design entity to achieve its function. -- Data – A description of data elements internal to the design entity Although not required by the standard, the software designer name or identification should be entered with each entity. IEEE Std , IEEE Recommended Practice for Software Design Descriptions, IEEE, Inc., Piscataway NJ, 1998 Module IV - Software Construction Module IV - Software Construction

85 Unit [software] Development Folders (UDF)
F. Code Documentation - 5 Unit [software] Development Folders (UDF) Definition UDF: -- A collection of material pertinent to the development of a given software module or subsystem. -- Contents typically include the requirements, design, technical reports, code listings, test plans, test results, problem reports, schedules, and notes for the module or subsystem Definition of a unit: -- In recent definition, a unit is a work package specification -- A work package specification is the amount of work that can be done by 3-4 people in 2-3 weeks A UDF provides low-level management control over low-level software units, tasks, work packages, or modules For more information: McConnell, Steve, Code Complete, Microsoft Press, Redmond, WA, 1993, pp Unit development folders: A UDF, or software development folder (SDF) is an informal document that contains notes used by a developer during construction. A “unit” is loosely defined, usually to mean either a routine or a module. The main purpose of a UDF is to provide a trail of design decisions that aren’t documented elsewhere. Many projects have standards that specify the minimum content of a UDF, such as copies of the relevant requirements, the parts of the top-level design the unit implements, a copy of the development standards, a current code listing, and design notes from the unit’s developer. Sometimes the customer requires a software developer to deliver the project’s UDFs; often they are for internal use only Module IV - Software Construction Module IV - Software Construction

86 Unit Development Folders (UDF) (continued)
F. Code Documentation - 6 Unit Development Folders (UDF) (continued) Provides an orderly and consistent approach in the development of each unit of the project Provides a uniform and visible collection point for all unit documentation and code Aids in the establishment and attainment of unit-level milestones Provides first-level management visibility and hands-on control over the development process. Module IV - Software Construction

87 Module IV - Software Construction
F. Code Documentation - 7 Commenting Code Useful comments: -- Summary of the code module -- Description of the code’s intent -- Use commenting styles that don’t breakdown or discourage modification; any style that is too fancy is annoying to maintain -- Outline the code (using PDL) in comments -- Avoid cryptic comments -- Place comments about undocumented features or error “work around” -- Place comments with: dimensions with numerical data, allowable numeric variables, the use of numbers to pass a meaning, global data, etc. Summary of the code module: A comment that summarizes code does just: It distills a few lines of code into one or two sentences. Such comments are more valuable than comments that merely repeat the code because a reader can scan them more quickly than the code. Summary comments are particularly useful when someone other than the code’ s original author tries to modify the code. Description of the code’s intent: A comment at the level of intent explains the purpose of a section of code. Intent comments operate more at the level of the problem than at the level of the solution. For Example { get current employee information } is an intent comment, whereas { update EmpRec structure } is a summary comment in terms of the solution. The distinction between intent and summary comments isn’t always clear, and it’s usually not important. Outline the code (using PDL) in comments: If you outline the code in comments before you write it, you win in several ways. When you finish the code, the comments are done. You don’t have to dedicate time to comments. You also gain all the design benefits of writing in high-level PDL before filling in the low-level programming language code. Comment anything that gets around an error or an undocumented feature in a language or an environment: If it’s an error, it ‘s probably not documented. Even if it’s documented somewhere, it doesn’t hurt to document it again in your code. If it’s an undocumented feature, by definition it isn’t documented elsewhere, and it should be documented in your code. For more information: McConnell, Steve, Code Complete, Microsoft Press, Redmond, WA, 1993, pp Module IV - Software Construction Module IV - Software Construction

88 Module IV - Software Construction
F. References McConnell, Steve, Code Complete, Microsoft Press, Redmond, WA, 1993, pp , F.S. Ingrassia , “The unit Development Folder (UDF): A Ten year Perspective,” In Richard H. Thayer (ed.), Software Engineering Project Management, IEEE Computer Society Press, Los Alamitos, CA (Also see: McConnell, p.454) IEEE Std , IEEE Recommended Practice for Software Design Descriptions, IEEE, Inc., Piscataway NJ, 1998 Module IV - Software Construction

89 Module IV - Software Construction
F. Quiz 1) The only two kinds of comments that are acceptable for completed code are: a) Repetitious and Explanatory comments b) Marker and Summary comments c) Intent and Summary comments d) Intent and Marker comments Answers 1) C McConnell, Steve, Code Complete, Microsoft Press, Redmond, WA, 1993, p. 464 Module IV - Software Construction Module IV - Software Construction

90 Definitions: Software Quality
G. Construction QA Definitions: Software Quality Software quality assurance: A planned and systematic pattern of all actions necessary to provide adequate confidence that the software and the delivered documentation conforms to established technical requirements [ANSI/IEEE Standard ] Construction quality assurance (QA) : Those QA techniques necessary assure that coding is being done according to coding standards Quality attributes: A requirement that specifies the degree of an attribute affecting qualities that the software must possess; e.g. correctness, reliability, maintainability, portability Topic estimate: 15 minutes Module IV - Software Construction Module IV - Software Construction

91 Module IV - Software Construction
G. Construction QA -2 Software quality: 1. The totality of features and characteristics of a software product that affects its ability to satisfy given needs (for example, to conform to specifications) 2. The composite characteristics of software that determine the degree to which the software will meet the expectations of the customer [ANSI/IEEE Standard ] 3. Attributes of software that affect its perceived value, for example, correctness, reliability, maintainability, and portability 4. Software quality includes fitness for purpose, reasonable cost, reliability, ease of use in relation to those who use it, design of maintenance and upgrade characteristics, and compares well against reliable products “Software: A vital key to UK Competitiveness, “ACARD Working Group, 1986 Module IV - Software Construction Module IV - Software Construction

92 Internal Quality Attributes of Code
G. Construction QA -3 Internal Quality Attributes of Code Maintainability: Average effort to locate and fix a software failure Flexibility: Effort to extend the software missions, functions, or data to satisfy other requirements Portability: Effort to convert the software for use in other operating environments Reusability: Effort to convert a software component for use in another application Readability: Effort to be able to read and understand source code Verifiability: Effort to verify the delivered operations and performance of the code. Software Quality management for distributed systems, RADC-TR (Also McConnell, pp, ), 1983. Programmers care about the internal characteristics of the software as well as the external ones. The internal quality characteristics include Maintainability: The ease with which you can modify a software system to change or add capabilities, improve performance, or correct defects. Flexibility: The extent to which you can modify a system for uses or environments other than those for which it was specifically designed. Portability: The ease with which you can modify a system to operate in an environment different from that for which it was specifically designed. Reusability: The extent to which and the ease with which you can use parts of a system in other systems. Readability: The ease with which you can read and understand the source code of a system, especially at the detailed-statement level. Verifiability: The ease with which you can verify the delivered operations and performance of the code. Module IV - Software Construction Module IV - Software Construction

93 Techniques for improving code quality
G. Construction QA - 4 Techniques for improving code quality To improve the quality of the product you must improve the quality of the process [#1 rule of software engineering] Institute a set of coding guidelines (standards) for the development of code Institute code walkthroughs or inspections Institute a verification and validation (V&V) process to verify code Use external audits when necessary Develop a reward structure that rewards the “good” producers of code rather that the error prone producers of code McConnell, Steve, Code Complete, Microsoft press, Redmond, WA, 1993, pp Techniques for improving code quality : Software quality assurance is a planned and systematic program of activities designed to ensure that a system has the desired characteristics. Although it might seem that the best way to develop a high-quality product would be to focus on the product itself, in software quality assurance the best place to focus is on the process. Module IV - Software Construction Module IV - Software Construction

94 Defect – Detection Rates
G. Construction QA - 5 Defect – Detection Rates Detection Technique Lowest Rate (%) Model Rate (%) Highest Rate (%) Personal checking of design documents 15 35 70 Informal group design reviews 30 40 60 Formal design inspections 55 75 Formal code inspections Modeling or prototyping 65 80 Personal desk-checking of code 20 Unit testing (single routine) 10 25 50 Function testing (Related routine) Integration testing (Complete system) 45 Field testing (live data) 34 Cumulative effect of complete series 93% 99% Capers Jones, Programming Productivity, McGraw-Hill, HY, 1986 McConnell, pp.564 Module IV - Software Construction Module IV - Software Construction

95 Defect – Detection Rates (continued)
G. Construction QA - 6 Defect – Detection Rates (continued) Model defect rates are not above 65% of any single technique Code inspections found a 60% model defect rate The model defect rate for [the popular] unit testing is only 25% Code reading detected more interface defects; functional testing detected more control defects To improve defect detection use more than one technique The earlier a defect is caught, the cheaper it is to fix Approximately 50% of the construction phase is spent debugging finished code and finding errors Basili, Victor R, Richard W. Shelby, and David H. Hutchens, “Experiments in Software Engineering.” IEEE Transactions on Software Engineering, SE-12 No pp (Also McConnell, pp. 564) Module IV - Software Construction Module IV - Software Construction

96 Module IV - Software Construction
G. Construction QA - 7 The Primary techniques used for construction include [SWEBOK Chapter 4] a) Unit testing and integration testing b) Test-first development c) Code stepping d) Use of assertions e) Debugging f) Technical reviews g) Static analysis The specific technique or techniques selected depend on the nature of the software being constructed, as well as on the skills set of the software engineers performing the construction. Construction quality activities are differentiated from other quality activities by their focus on code and on artifacts that are closely related to code: small scale designs- as opposed to other artifacts which are less directly connected to the code, such as requirements, high-level designs, and plans. Module IV - Software Construction Module IV - Software Construction

97 Module IV - Software Construction
G. References ANSI/IEEE Standard “Software: A vital key to UK Competitiveness, “ACARD Working Group, 1986 Software Quality management for distributed systems, RADC-TR (Also McConnell, pp, ), 1983. McConnell, Steve, Code Complete, Microsoft press, Redmond, WA, 1993, pp Basili, Victor R, Richard W. Shelby, and David H. Hutchens, “Experiments in Software Engineering.” IEEE Transactions on Software Engineering, SE-12 No pp (Also McConnell, pp. 564 Module IV - Software Construction

98 Module IV - Software Construction
G. Quiz 1) ________ is a planned and systematic program of activities designed to ensure that a system has the desired characteristics? a) Software Testing b) Software Construction c) Software Quality Assurance d) Software Maintenance 2) In Software Quality Assurance, the best place to focus is on the a) Product b) Process c) Project d) People Answers 1) C, 2)B Module IV - Software Construction Module IV - Software Construction

99 H. System Integration and Deployment
System Integration – I [RT04, p ] System Integration: The act of merging a software element or elements with another element The act of merging a hardware component or components with another hardware component The act of merging software configuration items with hardware configuration items in order to produce a total system which satisfies customer requirements Types of Integration techniques All in one integration (a.k.a. the “big bang” integration) Incremental integration Top-down integration Bottom-up integration Sandwich integration Topic estimate: 18 minutes Module IV - Software Construction Module IV - Software Construction

100 H. System Integration and Deployment – 2
System Integration – II The Big Bang Integration All components, modules, and subsystems are combined and integrated at one time This is called the “big bang” because it frequently blows up If (and when) the system fails to integrate, it is next to impossible to determine the cause This is called the “smoke test” in the hardware world “Let’s put the power to it and see where the smoke rises” Unfortunately there is no smoke to indicate a fault in software Module IV - Software Construction

101 H. System Integration and Deployment – 3
System Integration – III Incremental Integration Incremental integration: Develop a small core of the system Test and debug it Design, code, test, and debug another part (module, routine, etc.) Integrate the new part with the core Ensure that the new partial system works Repeat steps 3 through 5 until finished Module IV - Software Construction

102 H. System Integration and Deployment – 4
System Integration – IV Benefits of Incremental Integration Errors are easy to locate – The last integration is probably at fault Incremental integration provides early evidence that progress is being made (better status information) Planning (scheduling) is more accurate Components are tested more fully and frequently Improves the development schedule by work being done in parallel Development and testing are more easily distributed Integration can be done beginning at the top or the bottom (called top-down integration an d bottom –up integration) Module IV - Software Construction

103 H. System Integration and Deployment – 5
System Integration – V Top-Down Integration Identify the order of development such that: When developing a routine, all higher routines are completed Harder problems are attacked first; easier problems are delayed Test stubbing is easiest Module IV - Software Construction

104 H. System Integration and Deployment – 6
System Integration – VI Top-Down Integration (continued) The order of development depends on the type of project Control oriented: Calling routines are higher than called routines Data oriented: Routines that primarily set data higher than routines that primarily use data Requirements oriented: Routines least sensitive to requirements or design choices are ranked higher than more sensitive routines Test oriented: Routines critically needed for testing of other routines are higher ranked than routines not needed for testing Difficulty oriented: Harder routines are ranked higher than easier routines (This is the order that is illustrated) Module IV - Software Construction

105 H. System Integration and Deployment – 7
System Integration – VII Top-Down vs. Bottom-Up Integration Module IV - Software Construction

106 H. System Integration and Deployment – 8
Software Deployment [RT04, p. 6-60] Software deployment is the delivery and implementation of a software system, usually to the customer who purchased the system Deployed systems have been factory (alpha) tested Deployment may be on a “try it and see basis” (called a beta test) or for permanent installation Deployed systems are placed under external configuration management Deployed systems may be maintained by either the original developer or a third party Module IV - Software Construction

107 Module IV - Software Construction
H. References [RT04] Thayer, Richard, 2004 Certified Software Development Professional (CSDP) Preparation Course, Chapter 6: Software Construction Module IV - Software Construction

108 Module IV - Software Construction
H. Quiz 1. Which of the following is not a benefit of incremental integration? Errors are easier to locate because the last integration is probably at fault. Integration can be done beginning at the top or the bottom. It requires less test planning than the big bang integration. Components are tested more fully and frequently. 1. Answer: C. It requires less test planning than the big bang integration. Module IV - Software Construction Module IV - Software Construction

109 Module IV - Software Construction
I. Code Tuning Definition Code tuning is the practice of modifying correct code to make it run more efficiently Code tuning is the enemy if code reliability Code efficiency focuses on the following: Program design Module and routine design Operating-system interactions Code compilations Hardware Code tuning [RT04, p.6-40] Topic estimate: 7 minutes Module IV - Software Construction Module IV - Software Construction

110 Module IV - Software Construction
I. Code Tuning – 2 Elements of Code Tuning [RT04, p. 6-41] Measures the performance or size to find the trouble (inefficient) areas Measures must be precise Small parts of the program can take a disproportionate share of the run time (80-20 rule) Iteration – Repeat the optimization process to continue receiving efficiency improvements Some areas of inefficiency Input/output operations Paging System calls Module IV - Software Construction

111 Module IV - Software Construction
Code Tuning – 3 In Summary… [RT04, p. 6-42] Develop the software using a good design with highly modular code that is easy to understand and modify If performance is poor, measure the system to find the trouble spots Determine whether the real performance comes form: design, data structures, or algorithms and whether code tuning is appropriate Tune the bottleneck identified Measure each improvement; remove it of it does not work Repeat steps 1-5 Module IV - Software Construction

112 Module IV - Software Construction
References [RT04] Thayer, Richard, 2004 Certified Software Development Professional (CSDP) Preparation Course, Chapter 6: Software Construction Module IV - Software Construction

113 Module IV - Software Construction
Quiz 1. Which of the following is least likely to be considered a source of inefficiency with respect to code tuning? Lines of code System calls Paging Input/output operations 1. Answer: A. Lines of code Module IV - Software Construction Module IV - Software Construction

114 Module IV - Software Construction
J. Construction Tools Defined [RT04, p. 6-24] Construction tools are used to improve productivity and software quality Construction tools include: Source-code tools Editing Browsing Analyzing code quality Restructuring source code Data dictionaries Executable-code tools Code creation Debugging Testing Code tuning Topic estimate: 11 minutes Module IV - Software Construction Module IV - Software Construction

115 Module IV - Software Construction
J. Construction Tools – 2 Design Tools [RT04, p. 6-25] Most design tools involve graphic development and drawing tools These tools support one or more of the new technologies, for example: Object-oriented design (OOD) Structured design Design entity-relationship diagrams (ERD) The tools take on the “housekeeping” task (CASE TOLS) For example, keeping the process connected in a “bubble chart” when a new level is defined Module IV - Software Construction

116 J. Construction Tools – 3 Source Code Tools [RT04, p. 6-26]
Editors—Support for adding, eliminating, and moving items in a document File comparators—Compares two files and identifies areas that are different Source-code beautifiers—Improve the look of code so that it appears consistent Templates—Develop macro steps to save time and improve quality Browsers—Useful for finding and modifying coding elements (strings) Cross-reference tools—Lists variables, routines, and each place they are used Module IV - Software Construction

117 J. Construction Tools – 4 Analyzing Code Quality Tools [RT04, p. 6-27]
Call-structure generators—Produces information about routines that call each other Picky syntax and semantics checker—Does a more thorough job than the compiler Metrics reporters – Report on selected quality and quantity metrics Restructurers—Convert “spaghetti code” to “structured code” Code translators—Translate code form one language to another Data dictionary—A database of variable names with descriptions Module IV - Software Construction

118 J. Construction Tools – 5 Executable-Code Tools [RT04, p. 6-28]
Linkers—Supports the connecting and compacting of object files Code libraries—Prepackaged software systems Code generators—Tools that write code from design inputs.. Also used to develop prototypes Macro preprocessors—Allow the creation of simple named constants with no run-time penalty Debuggers—Assist in finding system errors Execution profilers—Watch code while running, tabulating how many times each statement is executed and/or how much time the program spends on each statement Assembler listing—Converts assembler code to the machine code that the computer can use Module IV - Software Construction

119 Module IV - Software Construction
J. References [RT04] Thayer, Richard, 2004 Certified Software Development Professional (CSDP) Preparation Course, Chapter 6: Software Construction Module IV - Software Construction

120 Module IV - Software Construction
J. Quiz 1. Which of the following considered a source code tool? File comparators Restructurers Code-translators Debuggers 1. Answer: A. File comparators – Compares two files and identifies areas that are different Module IV - Software Construction Module IV - Software Construction


Download ppt "CSDP Preparation Course Module IV: Software Construction"

Similar presentations


Ads by Google