2. Small scale vs. large scale
Small Large
team
single developer
large feature set
small feature set
long lived
short lived
3. Small scale vs. large scale
Small Large
work properly understandable by others
(once)
throughout time
extensible
resilient to change
work properly (continuously)
4. Enterprise software is very hard
Problem domains are typically not very complex (information
management + business rules)
How come?
Secondary concerns abound
persistence, concurrency, (a)synchronism, distribution,
transactions, security, caching, replication, logging, ...
5. Two dominant dimensions
business domain concerns vs. technological or
implementation concerns
Completely different beasts
(why treat them the same way?)
change rate
abstraction level
tools
skills
reuse
Current approaches won't cut it
7. model: a simplified representation of something
from a particular point of view and with a
particular purpose
8. Models in software
brainstorming
communicating
documenting
understanding (rev. eng.)
That is not what MDD is about
9. Models in MDD
are the central artifacts in software (re: source vs.
object code)
are well-formed
are precise*
are complete*
are executable (directly/code gen.)*
are technology-independent*
15. Relevant UML features
UML has always had support for modeling:
structure: classes, attributes, operations and relationships
(class diagrams)
dynamics: state machines (state diagrams)
Added in 1.5 (2003)/2.0 (2005):
behavior: action semantics (no standard notation, typically
textual)
UML finally enabled for MDD
22. Diagrams vs. Text
graphical representation not suitable for AS
models != diagrams (no loss of abstraction)
textual notations preferred (action languages)
but... isn't UML required to be graphical?
but... aren't we back to coding?