Life cycle Application Generation

Life cycle Application Generation

Peter BellChief Technology Officer

SystemsForge

pbell@systemsforge.com

Peter BellChief Technology Officer

SystemsForge

pbell@systemsforge.com

Overview

• Introducing SystemsForge

• Lifecycle Solutions

• Core Concepts

• Anatomy of a Generator

• Outstanding Problems

Where We Fit

• Five types of features

• Rocket Science

• Lab experiment (non-functional)

• New to me

• With a twist - sweet spot == 80%

• Here we go again . . .

What we do

• Generate custom web apps

• CMS, E-comm, Newsletter, etc.

• Unique: Insurance portal, SPLs, etc.

• “With a twist”

• Retail: $5,000 - $50,000

• Wholesale providers (usually under $5,000)

Resellers

• Marketing/design

• Selling to SMB’s

• Them: Project management, data entry, support

• Us: Code, tools, deployment

State of Play

• 80 clients

• 4 active resellers

• Profitable

• Soft launch this summer

• “Finishing up”

What We’re Not

• Vendor

• Experts

• Usual

Business Drivers

• Build Anything

• Change Everything

• Rapid Process

• 80/20

• Non technical roles

Lifecycle Solution

• Quote

• Specify

• Generate

• Manage

• Deploy

• Must optimize ALL

Quote

• Priced features

• Configure for free

• Discovery fee if complex (if possible!)

• Customization heuristics (per object)

• Named variability (includes only x)

Specify

• Features and configurators

• Requirements output => DSL input

• Agile Fixed Price

• Reduce (our) cost of most iterations

Generate

• Layered SPL - iterative approach

• Choose (feature model)

• Configure (decision support)

• Customize (DSLs)

• Extend (just add code)

Choose - Feature Model

• N-Features

• Parent

• Essential, optional, requires one

What IS A Feature?

• 1..n statements

• Essential/optional

• Config questions/mappings

• Question specific guidance

Configure

• Select optional

• Decision Support

• Answer: 0..n questions, 0..n statements

Customize (DSLs)

• Overload or add statements

• Issue: capturing customizations

• Intent Driven Design

Intent Driven Design

• Business intent

• Roles (and objectives)

• Essential tasks

• Interfaces and actions

• Infer object model

• Non non-functional specs

Extend (Just Add Code)

• Passive generation

• Protected areas

• Mixins/Partial Classes

• Subclass

• Events

• AOP

Generate

• Layered SPL - iterative approach

• Choose (feature model)

• Configure (decision support)

• Customize (DSLs)

• Extend (just add code)

Domain Specific Languages

• Three types of languages

• Abstract grammar vs. concrete syntax

• In language vs. external DSL

Three Types of Language

• Declaritive: What to do (requirements)

• Templating: Where to put (layout)

• Scripting: How to do (imperative)

Declaritive

User@FullName: Name: Optional@Email: Email: Required@Password: Password: Required

SELECT FullNameFROM tbl_UserWhere UserID = 7

Templating

<cfoutput query="ProductList">#Title#<br />$#Price#<br /><br />

</cfoutput>

Scripting

For (Count = 1; Count lte listlen(ObjectDependencyList); Count=Count+1){

// Get current object nameLoopObjectName = ListGetAt(ObjectDependencyList, Count);If (LoopObjectName NEQ "LightWire")

{ // Prepend it with ObjectName LoopObjectName=ListAppend(arguments.ObjectName,LoopObjectName,"|"); // Add it to the new object dependency list

TempObjectDependencyList=ListAppend(TempObjectDependencyList,LoopObjectName) };};

Three Types of Language

• Declaritive: Statement level reuse

• Templating: Simplify for designers

• Scripting: Use to implement

Abstract vs. Concretegrammar vs. Syntax

WHAT say vs. HOW say

Objects.User.Title = “User”;Objects.User.Attribute.Name = “FirstName”;

<Object title=”User”> <Name>FirstName</Name></Object>

User@FirstName

Boxes and Arrows

In-Language vs. External DSL

In Language:•API, Language extension•Easy to create•No validation•Can use core language

External:•XML/custom file•Store in database•Harder to create•Validation•Can limit language

Anatomy of a Generator

• Grammar

• Metadata

• Templates

• Iterator

• Orchestrator

• Extensions

Grammar

• Context free

• Concepts

• 0..n Attributes (optional or required)

• 0..n Relationships (0/1..1/n)

• BNF, API, DTD/Schema

• Example . . .

GrammarObject Name:string:required @Parent:Object 0..1@Property 1..n@Relationship 0..n

Property Name:string:required @DataType 1..1

Relationship Title:string

DataType Name:string:required SQLDataType:enum:required

Metadata

•Scripting•XML•Custom Syntax•Databased

Templates

Generating n-Getters:<cffunction name="get#PropertyName#" returntype="string">

   <cfreturn this.#PropertyName#></cffunction>

Template:<<cfset PropertyNameList = “FirstName,LastName,Email”>><<cfloop list="#PropertyNameList#" index="PropertyName">><cffunction name="get##PropertyName##" returntype="string">

   <cfreturn this.##PropertyName##></cffunction>

<</cfloop>>

Velocity - XSLT - CF Template

Generate a File

Templates<cffunction name="getFirstName" returntype="string">

   <cfreturn this.FirstName></cffunction>

<cffunction name="getLastName" returntype="string">   <cfreturn this.LastName>

</cffunction>

<cffunction name="getEmail" returntype="string">   <cfreturn this.Email>

</cffunction>

Iterator

• One DAO per business object

• One template per screen

• In general: one file per instance of concept

• Need filter support

Generate n-Files

Orchestrator

• Metadata (get(“ObjectList”))

• Template (ObjectDAO.cft)

• Iterator (Object: All)

• File name (#ObjectName#DAO.cfc)

Generate m-Collections of n-Files

Anatomy of a Generator

• Grammar

• Metadata

• Templates

• Iterator

• Orchestrator

• Extensions

Framework vs. Code Gen

• Not either/or

• Language features

• Intellectual property

• Performance

• Can refactor . . .

Problems Outstanding• Handling “dark matter”

• Evolving DSLs (versioning, refactoring)

• Pretty pictures(!)

Peter Bellhttp://www.pbell.com

Email: pbell@systemsforge.com

SystemsForgehttp://www.systemsforge.com

Object ModelObjects: Attributes: Relationships

Objects and Attributes:

Content@LiveDate: Optional: Datetime: 1/1/2000@KillDate: Optional: Datetime: 1/1/3000@Status: Required: Status: approved

Page: extends Content@Title: Required: Title

Article: extends Content@Content: Optional: HTML

Relationships:

Page: Article: optional: multipleArticle: Page: required: single

Object Model (2)Custom Data Types

Custom Data Types

LiveDate@Transform: Date@Validate: IsDate@Field: DatePicker@Display: AsDate

Status@Validate: IsDate@Field: Dropdown@List: StatusList

Content@Transform: SafeHTML@Field: WYIWYG

Interface Model

Screens: Actions: Steps

Screens

BaseList@Type=List@Paging = Yes@DefaultRecordsPerPage = 50@RecordsPerPageList = 10,25,50,all

ArticleAdminList extends BaseList@Type=List@AttributeList: Title,Status@OrderByAttributes: Title,Status@DefaultOrderBy: Title