1. Implementation 1

2. Software Implementation – transforming design into code Requirements Analysis Software Design Implementation Testing Deployment Evolution Systems Engineering 2

3. Implementation Approaches Big bang Code entire system and test in an unstructured manner Top-down Start by implementing modules on top of hierarchy and test by coding stubs Bottom-up Start by implementing modules on bottom of hierarchy and code drivers to test Feature-driven Implement and test a minimal set of modules implementing a function 3

4. Implementation Approaches Advantages and Disadvantages Big bang advantages None Big bang disadvantages Difficult to debug Much throwaway code Critical and peripheral modules not distinguished User does not see product until very late in the development cycle 4

5. Implementation Approaches Advantages and Disadvantages Top-down advantages Separately debugged modules System test by integrating previously debugged modules Stubs are easier to code than drivers User interfaces are top- level modules Top-down disadvantages Stubs must be written Low-level, critical modules built last Testing upper-level modules is difficult 5

6. Implementation Approaches Advantages and Disadvantages Bottom-up advantages Separately debugged modules System test by integrating previously debugged modules Testing upper-level modules is easier Bottom-up disadvantages Drivers must be written Upper-level, critical modules are built last Drivers are more difficult to write than stubs User interfaces are top- level modules 6

7. Implementation Plan Specifies which implementation strategy will be employed Divides the project into phases Specifies a schedule for each phase including the following steps for each phase: Coding Unit testing Integration of units Integration testing 7

8. Sample Implementation Plan Schedule Week number4 5 6 7 8 Activity Phase I coding Phase I unit testing Phase I integration Phase I integration testing Phase II coding Phase II unit testing Phase II integration Phase II integration testing 8

9. Programming Standards Most organization insist that their code conform to style, format and content standards. Coding standards help organizations in several ways: Codes and associated documentation are clear to everyone. Standards and procedures help the organization of thoughts and avoid mistakes. Individuals can leave and return to their work without losing track of what they were doing. Standardized documentation helps in locating faults and making changes. Standardized documentation clarifies which section of your program perform which functions. Standards and procedures help in translating designs to code, and make changes in design easier to implement in the code. 9

10. Programming Standards “A most critical standard is the need for a direct correspondence between the design components and the code components. This correspondence should occur in such areas as modularity, coupling, cohesion, etc. Without this correspondence testing, maintenance and configuration management become impossible.” 10

11. Why Programming Standards? The need to return to the code later to correct a problem, integrate a new feature, or tune for performance. It should be possible to determine what you are doing without reading the code line by line. waste resources?, misinterpret the original intent?, introduce errors? A well documented program will be easier to modify, debug, and maintain. 11

12. Programming Standards Areas where standards are usually applied End-user documentation Application design documentation Source code Layout & Style Classes/modules Methods/procedures Coding for Efficiency 12

13. Programming Standards End-user Documentation “There's nothing more frustrating for a user than to be sitting in front of an application and not know how to accomplish a task that the application is capable of doing.” Provide online help Provide user manuals Provide Developers manual? write the documentation at the level of understanding of the people who will use the software. 13

14. Programming Standards Application Documentation Give the application a name. State the goal of the application. Describe the features/packages of the application. Provide a list of the features the application will support and how the features will be integrated into the final product. Develop an implementation strategy. Break down the major components of the application design, describing how each will be implemented into the application and integrated with the other components. 14

15. Layout & Style Programmers should strive for simple and readable code Shorter code is usually simpler code Simpler code typically contains fewer decisions Excessively nested logic should be avoided 15

16. Layout & Style Indent properly. Indent all the code within methods, indent all conditionals and loops, etc. Use white space liberally. Use inline comments liberally. Code should be simple and easy to read 16

17. Comments and Internal Documentation Most successful software systems exist for several years and require modification during that time Comments are the chief source of information about the source code, and thus are extremely important A header comment block summarizes the purpose of a module (class or method) Line comments are inserted into the source code to explain the objectives of a subset of the instructions comprising a module to describe data declarations and blocks of code where the purpose of a statement is not entirely obvious Each major control structure (loop, selection) should be clarified through a line comment 17

18. Comment Blocks Place a header comment block at the top of each method/module. what the method is called who wrote it where it fits in the general system when the method was written and revised why the method exists how it uses its data structures and algorithms. Expected input and possible output Expected extensions or revisions 18

19. Programming Standards Modularization Rules: Each method must perform only one task Global variables should be used with care. Data should be shared through the parameter list If, during implementation, a need arises for a class not specified in the design, the design must be reexamined before the new class is implemented Separate data management from the user interface. Write separate procedures to manage data and call them from the user interface code. Give each module a clear, simple name that indicates what it does. 19

20. Programming Standards Declarations: All variables must be declared and explicit types used Name of variables and methods should describe their content or usage. An exception can be made for naming subscripts and counters Declarations of any files should precede variable declarations Declarations of instance variables in a class should precede method definitions 20

21. Programming Standards Naming Conventions: Name of variables and methods should describe their content or usage. E.g. a variable that represents the total number of employees EmployeeTotal or EmployeeCount Is much better than n. Use abbreviations consistently. "Tm", for example, is only two characters shorter than "Time" and much less readable. Use common tags but be consistent Num for Number, Idx for Index, … Don't use Num some of the time and Number or Count at other times. 21

22. Programming Standards Naming Conventions: Make the name readable. A good rule to apply here is that you should be able to read your code to someone over the phone and have them be able to write it down without asking you for spellings. Use a noun for variables - a word that represents the data. Use a noun and a verb for procedures. E.g. "AddContact" for a procedure that adds a new contact to a database. 22

23. Programming Standards User interface: Put control in the hands of the users. provides features so users can customize their environment. design interface to have the look, feel, and functionality of the applications with which users are already using. Integrate your application with the operating system. associating file types with your application supporting drag and drop where applicable supporting mail features, etc. Apply the quality function deployment paradigm 23

24. Quality function deployment Goal Maximize user satisfaction Needs of user  software requirements Requirements Normal requirements Expected requirements Exciting requirements 24

25. Performance & Perception True Performance This is the actual speed at which the code is executing Perceived Performance This is the performance as perceived by the user. 25

26. Performance Two basic ways to increase the perceived performance of an application: Distract the user during long processes. Splash screens, pretty pictures, and progress meters are common tools used to give users something to look at while a long running process is taking place. Give users something else to do during long processes. When possible, you should try to move time consuming tasks into a background process and allow the user to continue with something else while the process is running. 26

27. Examples of Coding Standards Examples of Java coding standards may be found Here Here 27

28. Summary Understand the problem before you begin building the solution. Follow accepted standards for code/user interface design. Write code that is readable. Separate user interface and data management. Design for the most efficient use of the program by the user. Design code that can be re-used. Keep the program simple Localize input and output 28

29. The End 29 ______________________ Devon M. Simmonds Computer Science Department University of North Carolina Wilmington ____________________________________________ _________________ Qu es ti ons?