Phase Implementation overview Class skeletons Coding standards 1

Phase Implementation: overview Class skeletons Coding standards 1

Overview of Implementation phase Define Create Class Define Implementation Plan Skeletons Coding (+ determine Standards For each group of units subphases) For each unit Create unit Test plans Create system Test plan System Testing Janice Regan, 2008 Release unit for integration Integratio n Testing Implement Methods in class/es Unit test Code review Create integration Test plan 2

Today ] Class Skeleton ] Internal Comments ] Programming Style ] Code Standards ] Validation & Verification u Code reviews Janice Regan, 2008 3

Overview of Implementation phase Define Create Class Define Implementation Plan Skeletons Coding (+ determine Standards For each group of units subphases) For each unit Create unit Test plans Create system Test plan System Testing Janice Regan, 2008 Release unit for integration Integratio n Testing Implement Methods in class/es Unit test Code review Create integration Test plan 4

Method Design ] When designing your methods: u Each method must perform only one task (Modularization rule) u Repeated code should be put into a method u Specify the algorithm to be used for non-trivial methods ] Note: 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 Janice Regan, 2008 5

Class Skeletons ] Class skeletons are partial class definitions ] Can be created at the end of Low Level Design (they embody all analysis and design information created to this point) and completed during Implementation (class skeletons are the basis for the Implementation phase) ] Class skeletons should be heavily commented, so that the purpose of all attributes, methods, and constructors is clear Janice Regan, 2008 6

Class Skeleton - 1 • Class Skeleton starts with a header comment block • Example: // filename (name of class) // author/s // copyright and licensing info // revision history table. . . Janice Regan, 2008 7

Comments ] Authors should include all those that worked on the class, this is where you reference use of code from other sources as well. Always give credit if you use existing code. ] If you use existing code or support packages that require licensing that information regarding license limitations and authorizations should be provided here. This is also where you declare copyright on your own code. ] Revision history of the code should show the releases of the code. The initial release (1. 0) of your code is the code prepared for the UAT Janice Regan, 2008 8

Class Skeleton - 2 public class <class name> { // Class Description // Describes the purpose of a class // Class invariants // Attributes - Class variables private static <type> <name>; // … * // Attributes - Instance variables <access modifier> <type> <name>; // … * *comment to describe the purpose of attributes Janice Regan, 2008 9

Comments ] Class description should be concise and informative ] Class Invariants are conditions that are true from the time any object of the class is created to the time that object is destroyed. Must be true for all objects in the class u In the LMS system - //-Patron must have a valid university ID ] Method signature: parameter listing including name and type of each parameter (see next slide) Janice Regan, 2008 10

Class Skeleton - 3 // Static methods public static <return type> <method signature> // Method Description (describes purpose of method) // Non-Static Methods // (starting with Constructors) <access modifier> <return type> <method signature> // Method Description (describes purpose of method) // Pre Conditions (if any) // Functional requirements satisfied(if any) // Post Conditions } // end of class <name> Janice Regan, 2008 11

Class Skeletons: ] As use cases (methods) are added to the system the class skeletons will evolve u New methods will be added u Code for methods will be added u New attributes may also be added Janice Regan, 2008 12