mdd with executable uml models
DESCRIPTION
Slide deck from a lecture given to a Software Engineering class at UVic (SENG330)TRANSCRIPT
Small scale vs. large scale
Small
single developer
small feature set
short lived
Largeteam
large feature set
long lived
Small scale vs. large scale
Small
work properly (once)
Large
understandable by others
throughout time
extensible
resilient to change
work properly (continuously)
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, ...
Two dominant dimensions
business domain concerns vs. technological or implementation concerns Completely different beasts(why treat them the same way?)
change rateabstraction level toolsskillsreuse
Current approaches won't cut it
Model Driven Development to the rescue
model: a simplified representation of something from a particular point of view and with a particular purpose
Models in software
brainstormingcommunicatingdocumentingunderstanding (rev. eng.)
That is not what MDD is about
Models in MDD
are the central artifacts in software (re: source vs. object code) are well-formedare precise*are complete*are executable (directly/code gen.)*are technology-independent*
MDA pattern
source: MDA Guide (OMG)
Technology-agnostic models
source: eclipse.org
source: openarchitectureware.org
Code generation
Model interpretation
MDD with UML
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
source: UML 1.5 spec (OMG)
Action Semantics: basic concepts
actions
input/output pins
data flows
activity nodes
activities
Action Semantics: basic actions
read/write variable
create/destroy object
read self ("this")
read/write attribute
create/destroy link
call operation
activity node (block)call function
conditional (if/switch)
loop
raise exception
send signal
newCustomer = new Customer();
source: UML 1.5 spec (OMG)
current_account.balance = new_balance;
source: same
if (factor == 2) { ... }
source: same
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?
