ICS

Software Development

Becoming a Cohesive

Development Team

Part 1

Simple Project Structure

-ICSDist-base

-models

-views

-controllers

-development

-models

-views

-controllers

-production

-models

-views

-controllers

-Base: what is it?

Provides core routing logic

Manages automatable actions

Promotes code reuse

Dictates project structure

Provides timesaving APIs

-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.

-PreProduction: what is it?

Surprise!

The staging area

Production ready, but not quite

0% test failures

-Production: what is it?

Live programs, live data

Only from PreProduction pgms.

No Automated Testing.

No Direct Changes!

(Only users share this env.)

Part 2

Standard Design Pattern

(semi-familiar)

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

Models [ Mvc ]

Defines the data source

Allows indirect manipulation

Centralizes data validation

Encourages uniformity

Hastens development

Softens schema changes

Controllers [ mvC ]

Executes requests (actions)

Encourages bite-size code

(1 request 1 action)

Leverages Models

Centralizes like tasks

Prepares response

Views [ mVc ]

The display or response

Mostly HTML + display logic

Made by Designer or Developer

No business logic!

Part 3

Simple Conventions

-The Good, The Bad, The Ugly

account_controller.php

account.php

act.php

- Controllerslaborop_controller.php

laboropinq_controller.php

menu_controller.php

-ModelsOehdr.php

Tatkt.php

Tatkt0.php

Oebus.php

- Views-laborop

checkoff.php

select.php

-laboropinq

checkoff.php

select.php

-menu

main.php

-templates

default.php

default_view.php

-URL Conventionshttp://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

-Controller Conventionshttp://www.icsi5.com:89/development/laborop/select

public function get_select_laborop(){

//business logic

//business logic

//prepare data response (output)

//give response to view

}

-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

}

-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();

}

Building a Foundation on

Agile Software Design

Part 1

Development Methods

-Procedural

Logic reads top down

Function calls are global

Variables are in the global scope

Perfect for business logic

-Object Oriented – OOPUsed inside Procedural code

Function calls only affect “instance” variables

Variables are local to the instance

Perfect for creating reusable code

-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)

-ControllerIs 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

}

}

-ModelAn 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!

Part 2

Decorator Design Pattern

-ICSDist-development

-models

-views

-controllers

-DECORATORS

- JTI

-models

-views

-controllers

- ICS

-models

-views

-controllers

-DecoratorAllows 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

-DecoratorCurrent decorator “ICS”

- provides debugging information

Potentially add unlimited runtime decorators

Can override / modify (decorate!)

- Models || Views || Controllers

Best Practices

Better Automation

-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

-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

<?php break; ?>