In this presentation Johan den Haan (head R&D Mendix) talks about the Mendix approach towards Model-Driven Development. Bridging the gap between theory and practice, den Haan explains how Mendix enables business analysts to develop complex Service Oriented Business Applications (SOBAs) starting from a process design and guided by a modeling methodology and appropriate tools.
3. Contents
• Introducing Mendix
• From software engineering to business
engineering
• Modeling method
• Tool support
• Mendix Solution stack
4. Introducing Mendix
• Innovative, groundbreaking New Solution for Application
Delivery
• Awarded by Shell & Deloitte
• Gartner acknowledgment: Cool Vendor in 2009
• University background
• Backed by Venture Capital partner
• Worldwide customer base.
• Offices in Netherlands (Headquarters), US, Sweden & Thailand.
• Extending Partner Network
– Implementation partners in US, EMEA (Europe & UAE).
– Technology partners
5. Introducing Mendix
Business application delivery made:
Fast Flexible Future-proof
Develop and Extend the Easily adapt
integrate dynamic development applications to
business apps process to changing business
in days business analysts requirements
6. Contents
• Introducing Mendix
• From software engineering to business
engineering
• Modeling method
• Tool support
• Mendix Solution stack
7. From Software Engineering to Business Engineering
• Software Engineering
– Programmer (“technical expert”)
– Writing code
– Modeling the structure (“How”)
• Business Engineering
– Domain expert (“business analyst”)
– Domain models
– Modeling the function (“what”)
8. From Software Engineering to Business Engineering
Model Driven Software Development:
model model model model
code code code code engine
code code roundtrip
code only model only
visualization generation engineering
10. From Software Engineering to Business Engineering
• Involve non-programmer domain experts in the
development process.
• No complex transformation from model to code.
• Models and code cannot be out-of-sync.
• Changing an application is just changing the model.
• Understanding the behavior of an application just
asks for reading the models (instead of source code).
• Debugging an application means debugging the
models (i.e. debugging in terms of business models
instead of source code).
11. Contents
• Introducing Mendix
• From software engineering to business
engineering
• Modeling method
• Tool support
• Mendix Solution stack
15. Mendix Modeling Methodology
deploy Functional
Model
test
Process Functional
Manage
design requirements Component 1
Component 2
Component 3
Realization
Business Process Improvement
16. Mendix Model Framework
Process Domain
Process
analyst dictionary
Process
design
Actors &
systems
Service identification
Business
Documentation
engineer
Functional Workflow
requirements
Architect Component
identification
Business &
Decision service System service User service
IT engineer
Realisation
Domain
Rules Logic Forms Reports
model
17. Contents
• Introducing Mendix
• From software engineering to business
engineering
• Modeling method
• Tool support
• Mendix Solution stack
18. Mendix solution
Optimizing collaboration between Business and IT
Application Development Business Modelling
• Data modeling • Business requirements
• Business logic • Business rules
• Architecture • Forms
• Service design • Process models
• Integration • Use cases
New
functionality
20. Process design
• Import XPDL (e.g. Bizzdesign)
• Link to implementation elements
• Tracing
• Change impact analysis
21. Multiple DSL’s integrated in 1 platform
The model = the code
Open standards
Collaboration
between business & IT
DSLs easy to extend
with Java
22. Mendix Business Modeler: a unified modeling space
Graphical “drag & drop” DSL editor
“1-click-deploy&run” button
DSL object properties
Project explorer
with direct access
to all DSL editors
and project
resources
Connector window
for mapping DSLs
Automatic console for real-time
testing and consistency checking