Modelbaseret softwareudvikling
Lektion 4: Design Patterns and EMF Commands
Ole Rasmussen – Senior IT Arkitekt 5. Marts 2010
"The best architectures are full of patterns.“
Interpretation of Christopher Alexander by Grady Booch
We have several topics to cover today
We are here … Expectations on you
Project effort and obligations
Finding a way to catch up with missing lecture(s) Design patterns
EMF Commands
We are here …
and you should be able to ….
Create a ecore (meta) model via a diagram
Understand how to find and fix errors in the model
Create a (instance) model using this meta model
Create and use a popup menu
http://help.eclipse.org/galileo/topic/org.eclipse.emf.doc/references/overview/EMF.html
It is important that you can do this ….
And remember …
This course has five aspects
Lecture (in this room; approx 2 hours) Exercise (in the e-bar; approx 2 hours)
Assignment (wherever) – most often related to the exercises or the project Project (in the e-bar or wherever)
Self study (wherever)
This implies you are expected to do more effort than contained in the scheduled modules!
And there is a sixth aspect
Exam
The project is your foundation for the exam
“I love deadlines. I like the whooshing sound they make as they fly by.”
- Douglas Adams
We have a fixed end date, fixed number of lectures, one missing lecture and one new week where I’m away. Where do we find the necessary lecture slots?
Eksam 28-05-2010
21 20
OBS tirsdag 11-05-2010
19 13
07-05-2010 18
12
? 18
11
Store bededag 17
Ole away 16
16-04-2010 15
10
09-04-2010 14
9
? 14
8
Påske 13
26-03-2010 12
7
19-03-2010 11
6
12-03-2010 10
5
05-03-2010 9
4
Cancelled 8
19-02-2010 7
3
12-02-2010 6
2
05-02-2010 5
1
Comment Date
Week Lecture
Our goal is to create a concrete syntax (custom user interface) for manipulating our model but we are not fully there…
:Place
:Transition :Arc :Transition
:Place :Arc
:Arc
source
target source
target target source
:Arc source
target
:Petrinet
:Token
Place Transition
1 source 1 target
Arc
* PetriNet
Token
* Node
Object
model
meta model
is instance of
concrete syntax abstract syntax
Place Transition
Arc
Token
generate an
editor
The underlying idea in our approach to model based software development is
The domain models are an (the) essential part of the software
In addition to that we need
– Information about the presentation of the model to the user – The coordination with the user
Note: These parts of the software can be mo delled
(don’t get confused : „models
are everywhere“).
Model View Controller (MVC)
Model
Place Transition
1 source 1 target
Arc
* PetriNet
Token
* Node
Object
View
Controller
:Arc
The domain models
The presentation of the model to the user
The coordinator with the user
MVC responsibilities
Model
Domain model and functions
View
Representation of model and user interaction
Controller
Makes changes and calls functions of the model queries
informs on changes
makes changes
selects informs on
user interactions
Notes:
• This is a rough id ea only!
• There are many variants (e.g.
GEF/GMF uses this a
bit differently)
MVC is a principle (pattern / architecture) according to which software should be structured
Eclipse and GMF are based on this principle and guide (force) you in properly using it
Model
Place Transition
1 source 1 target
Arc
* PetriNet
Token
* Node
Object
View
Controller
:Arc The domain models
The presentation of the model to the user
The coordinator with the user
This part can be ge nerated
automatically
Excursion on Design Patterns
"The best designers will use many design patterns that dovetail and intertwine to produce a greater whole.“
from “Design Patterns” by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
"Each pattern describes a problem which occurs over and over again in our
environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice."
- Christopher Alexander
In software engineering “Design patterns” are the distilled experience of software engineering experts on how to solve standard problems in software design.
Design Patterns is “big business” with many references – we take a small dip into this world
Gamma, Helm, Johnson, Vlissides: Design Patterns. Addison-Wesley 1995.
(Gang of Four / GoF / Go4)
http://c2.com/cgi/wiki?DesignPatterns
“A design pattern systematically names, motivates, and explains a general design that addresses a recurring design problem in object-oriented systems. It describes the problem, the solution, when to apply the solution, and its consequences. It also gives implementation hints and examples. The solution is a general arrangement of objects and classes that solve the problem. The solution is customized and implemented to solve the problem in a particular context.”
http://sourcemaking.com/design_patterns
Eric Freeman, Elisabeth Freeman:
Head First Design Patterns. O’Reilly 2004.
…
Design Pattern Scheme (GoF)
Name and classification Intent
Also known as Motivation
Application Structure
Participants Collaboration Consequences Implementation Sample code Known uses
Related patterns
Sometimes th ere is more: V ariants,
counter indica tions, …
Pattern: Strategy (GoF)
Name and classification Strategy, behavioural Intent
Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it [GoF]
Motivation
Avoid hard-wiring of algorithms for making it easier to change the algorithm … Structure
Context
contextInterface()
Strategy
algInterface()
AlgorithmB
algInterface() 1
strategy
AlgorithmA
algInterface()
AlgorithmC
algInterface()
How does “St rategy”
relate to the p lugin
architecture in Eclipse
and EMF?
Pattern: Abstract Factory
Name and classification Abstract factory, creational Intent
Provide an interface for creating families of related or dependent objects without specifying their concrete classes [GoF]
Motivation
Use of different implementations in different contexts with easy portability … Structure
AbsFactory
createProdA() createProdB()
Factory1
createProdA() createProdB()
Factory2
createProdA() createProdB()
Client
AbsProdA
ProdA1 ProdA2
AbsProdB
ProdB1 ProdB2
Pattern: Singleton (GoF)
Name and classification Singleton, creational Intent
Ensure that a class has only one instance, and provide a global point of access to it [GoF]
Motivation
… Structure
Singleton
+static instance()
Client
Pattern: Decorator
Name and classification Decorator, structural Intent
Attach additional responsibilities to an object dynamically.
Motivation
You want to add behavior or state to individual objects at run-time. Inheritance is not feasible because it is static and applies to an entire class.
Structure
Problem!
Solution!
Pattern: Observer (GoF)
Name and classification Observer, behavioural Intent
Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically [GoF]
Motivation
Update a view when the model (subject) changes … Structure
Used in MVC and in EMF/GMF ed itors
(observers ar e called
“adaptors” the re).
Design Patterns in the end…
GoF present 23 patterns
There are many more (and more complex combinations of patterns, e.g. MVC)
“Pattern terminology” can be used to communicate design!
Patterns should not be used to schematically (when used manually)
Generated code, typically, makes use of many patterns. Automatic code
generation “saves us making some design decisions” (observer, singleton,
factory are part of the EMF-generated code)
Let’s turn towards our goal again
We have an EMF-based model that you've generated code for using the EMF generator, and you are now ready to add user interfaces to your model and code
EMF.Edit framework will make your job easier.
EMF.Edit is an Eclipse framework that includes generic reusable classes for building editors for EMF models. It provides:
– Content and label provider classes, property source support, and other convenience classes that allow EMF models to be displayed using standard desktop (JFace) viewers and property sheets.
– A command framework, including a set of generic command implementation classes for building editors that support fully automatic undo and redo.
– A code generator capable of generating everything needed to build a complete editor plug-in for your EMF model. It produces a properly structured editor that conforms to the recommended style for Eclipse EMF model editors. You can then customize the code however you like, without losing your connection to the model.
:Place
:Transition :Arc :Transition
:Place :Arc
:Arc
source
target source
target target source
:Arc source target
:Petrinet
:Token
Place Transition
1 source 1 target Arc
* PetriNet
Token
* Node Object
model meta model
is instance of
concrete syntax abstract syntax
Place Transition
Arc Token
generate an editor
Focus for today
EMF Commands are part of EMF.Edit
The structure is based on abstract factories, observers and strategies
For editors – getting to the model For editors – getting labels For commands
Observer structure
Factory: Provider of model objects
Model objects For commands – support for undo/redo
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.emf.doc/references/overview/EMF.Edit.html
And read the tutorial!!!!
Override method
Use Use
