ICS Software Development

1. ICS Software Development

2. Becoming a Cohesive Development Team

3. Part 1 Simple Project Structure

4. -ICSDist -base -models -views -controllers -development -models -views -controllers -production -models -views -controllers

5. -Base: what is it? Provides core routing logic Manages automatable actions Promotes code reuse Dictates project structure Provides timesaving APIs

6. -Development: what is it? The developer’s playground Contains the latest source files May not be in working condition Runs on TESTICS physical files Everyone shares the env.

7. -PreProduction: what is it? Surprise! The staging area Production ready, but not quite 0% test failures

8. -Production: what is it? Live programs, live data Only from PreProduction pgms. No Automated Testing. No Direct Changes! (Only users share this env.)

9. Part 2 Standard Design Pattern (semi-familiar)

10. MVC - structural design pattern -development -models : data interface -views : data presenter -controllers : program flow / logic -testics -qddssrc : file descriptions -qddssrc : screen prensentations -qrpgsrc : program flow / logic

11. Models [ Mvc ] Defines the data source Allows indirect manipulation Centralizes data validation Encourages uniformity Hastens development Softens schema changes

12. Controllers [ mvC ] Executes requests (actions) Encourages bite-size code (1 request 1 action) Leverages Models Centralizes like tasks Prepares response

13. Views [ mVc ] The display or response Mostly HTML + display logic Made by Designer or Developer No business logic!

14. Part 3 Simple Conventions

15. -The Good, The Bad, The Ugly account_controller.php account.php act.php

16. - Controllers • laborop_controller.php • laboropinq_controller.php • menu_controller.php • Models • Oehdr.php • Tatkt.php • Tatkt0.php • Oebus.php

17. - Views -laborop checkoff.php select.php -laboropinq checkoff.php select.php -menu main.php -templates default.php default_view.php

18. -URL Conventions http://www.icsi5.com:89/laborop_select.php -too static, prone to maintainability issues http://www.icsi5.com:89/development/laborop/select -allows framework to determine processor -becomes language / file agnostic /development => Application / environment /laborop => Controller / logic processor /select => Action / specific request

19. -Controller Conventions http://www.icsi5.com:89/development/laborop/select public function get_select_laborop(){ //business logic //business logic //prepare data response (output) //give response to view }

20. -Controller Conventions contd. <form method=“post”> <input type=“hidden” name=“post” value=“select_laborop”> </form> public function post_select_laborop(){ //business logic //business logic //prepare data response (output) //give response to view }

21. -Model Conventions -centralized data validation + error messages Validate.php – common validation functions Error.php – common error messages Oelbr.php public function validate_locomp(){ if(!validate::company_code($this->locomp)) return error::invalid_doc(); }

22. Building a Foundation on Agile Software Design

23. Part 1 Development Methods

24. -Procedural Logic reads top down Function calls are global Variables are in the global scope Perfect for business logic -Object Oriented – OOP Used inside Procedural code Function calls only affect “instance” variables Variables are local to the instance Perfect for creating reusable code

25. -Procedural and OOP Controller logic is procedural -easier to read / write -leverages objects sometimes View logic is procedural Models are Objects -allows greatest code reuse (think data validation, data manipulation)

26. Controller • Is really a class (an object) • Each action is a function of the class • Code inside each function is procedural • Then WHY make the controller an Object? • - provides certain functionality to all • - allows overriding actions (decorating) • class laborop_controller extends controller • { • public function get_select_laborop(){ • //business logic • } • }

27. Model • An object representation of a physical file • Has variables based on file field names • Can log information about its own state • Provides an easy interface for finding / updating • $oelbr = new_(“Oelbr”); • $oelbr->locomp = “J”; • //set other keyed fields • $oelbr->lotype = “R”; • $oelbr->find(); • $oelbr->loprfm = ‘Y’; • $oelbr->save(); // runs validations!

28. Part 2 Decorator Design Pattern

29. -ICSDist -development -models -views -controllers -DECORATORS - JTI -models -views -controllers - ICS -models -views -controllers

30. Decorator • Allows you to add more functionality • Allows you to remove current functionality • Doesn’t require a complete copy of program • - only overrides same functions • - uses functions defined in base class • - brings in new functions

31. Decorator • Current decorator “ICS” • - provides debugging information • Potentially add unlimited runtime decorators • Can override / modify (decorate!) • - Models || Views || Controllers

32. Best Practices Better Automation

33. PHP documentor • Parses comments for documentation • Comments follow a simple pattern • /** • * This is the comment that … • */ • Zend Studio auto fills comments • Documentor creates HTML / PDF docs

34. SimpleTest • Automated testing of controllers / Models • Provides a safety net for functionality • Write once, run … • Used in PreProduction environment • Acts like a real browser, through code! • Find a bug once, never allow it again

35. <?php break; ?>