Life cycle Application Generation Peter Bell Chief Technology Officer SystemsForge...
-
Upload
sandra-tucker -
Category
Documents
-
view
218 -
download
1
Transcript of Life cycle Application Generation Peter Bell Chief Technology Officer SystemsForge...
Life cycle Application Generation
Life cycle Application Generation
Peter BellChief Technology Officer
SystemsForge
Peter BellChief Technology Officer
SystemsForge
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: [email protected]
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