These are the slides for the second lecture of the course "Model-Driven Software Development" taught at Delft University of Technology in the academic year 2009-2010.
1. Domain Analysis
& Data Modeling
Lecture2
Course IN4308
Eelco Visser
Master Computer Science
http://eelcovisser.org Delft University of Technology
Thursday, February 11, 2010
2. Course Goal
Learn to design and implement
domain-specific languages
Understand DSL design choices and make
reasoned decisions about their application
Thursday, February 11, 2010
3. Model-Driven Software Development
Problem
DSL HLL Machine
Domain
domain-specific models reduce gap between
problem domain and implementation
Thursday, February 11, 2010
4. Why domain-specific languages?
Domain-specific models
- increase level of abstraction
- are closer to problem domain
- are smaller
- are easier to write
- are easier to maintain
Thursday, February 11, 2010
5. What is a model?
A model
- is a simplification of a system
★ abstraction, description, specification, information
- can answer questions in place of actual system
★ analysis, inference, predictions
- is used for a purpose
★ understanding, planing, risk analysis, ...
Thursday, February 11, 2010
6. How are ‘models’ different from ‘code’
- Models are just another form of code
- Are models better than code?
★ no, models provide different level of abstraction
★ depends on the purpose
★ how well does DSL fit purpose
★ should be easier to analyze
- Continuum of abstractions
- Abstraction => giving up control
Thursday, February 11, 2010
7. “Far better at some key things”
Thursday, February 11, 2010
8. How do we make DSLs?
Thursday, February 11, 2010
9. Syntax
Checks
described by
Model DSL Editor
consists of
generate Transformation
Software
System Generator
Thursday, February 11, 2010
13. Domain Engineering is the activity of collecting,
organizing, and storing past experience in building
systems or parts of systems in a particular domain in
the form of reusable assets (i.e. reusable work
products), as well as providing an adequate means for
reusing these assets (i.e., retrieval, qualification,
dissemination, adaptation, assembly, and so on) when
building new systems
Source: Czarnecki & Eisenecker, Generative Programming, 2000
Thursday, February 11, 2010
14. Domain Engineering
domain domain system family
knowledge model architecture
Domain Domain Domain
Analysis Design Implementation
DSLs
requirements components
generators
Requirements Product Integration
Analysis Configuration and Test
requirements features configuration product
Application Engineering
Source: Czarnecki & Eisenecker, Generative Programming, 2000
s Thursday, February 11, 2010
15. Application Domain = Family of Systems
Identify
- Commonality
★ What is the same in all systems?
★ Can be reused between applications
★ Standard components
★ Generated code
- Variability
★ What is different between systems?
★ Needs to be defined for each application
★ Using domain-specific language
Thursday, February 11, 2010
16. Domain analysis in
application engineering
implement
Problem Solution
Domain validate
Domain
Thursday, February 11, 2010
17. Domain: “A sphere of knowledge, influence, or activity”
“The subject to which the user applies a
program is the domain of the software”
Eric Evans, Domain-Driven Design, 2004
Thursday, February 11, 2010
21. X + Computer = Computer
Cognitive Friction
Dancing Bearware
Thursday, February 11, 2010
22. Analysis
Software design driven by developers
- implementation model is leading
- convenient for developer, not for user
- developers drive design ‘from the back seat’
Thursday, February 11, 2010
24. User Personas
Goals (not Tasks)
Thursday, February 11, 2010
25. Polite software is
★ interested in me
★ forthcoming
★ has common sense
★ anticipates my needs
★ is responsive
★ is taciturn about its problems
★ is well informed
★ is perceptive
★ is self-confident
★ stays focused
★ is fudgable
★ is trustworthy
Thursday, February 11, 2010
26. Interaction Design
requires
Big Up Front Design
Thursday, February 11, 2010
27. How can we integrate interaction design
in software engineering?
Can programmers be interaction designers?
Thursday, February 11, 2010
28. Some lessons that I have tried to apply
- Direct manipulation
★ edit where you view
- No confirmations
★ no destructive, catastrophic actions
- No inaccessible actions/links
★ apply access control to source of navigation
- Limitations for user should be based on policy
★ policy: rules based on domain requirements
★ mechanism: inconvenient to implement
Thursday, February 11, 2010
29. Student
Course
University
Guests Management Administration
System
Lecturer
Thursday, February 11, 2010
48. “Every software program relates to some
activity or interest of its use. That subject
area to which the user applies a program
is the domain of the software”
Eric Evans, Domain-Driven Design, 2004
Thursday, February 11, 2010
49. “A model is a selectively simplified and
consiously structured form of knowledge”
Eric Evans, Domain-Driven Design, 2004
Thursday, February 11, 2010
50. Ubiquitous Language: “a language
structured around the domain model and
used by all team members to connect all the
activities of the team with the software”
Eric Evans, Domain-Driven Design, 2004
Thursday, February 11, 2010
54. Collaboration on Assignments
Scenario 1
- Piet starts submission for Design 1
- Jan starts submission for Design 1
- Piet and Jan want to work together
on Design 1
Scenario 2
- Piet, Jan work together on Design 1
- They want to split
Thursday, February 11, 2010
55. Binding Students to Submissions
- Creating submissions
★ should be enrolled
- Can be partner if
★ no active submission
★ #students < limit
- Start submission if
★ not part of active submission
Thursday, February 11, 2010
56. Submissions & Deadlines
- Edit assignment after submission?
★ before deadline
★ after deadline
★ after/during grading
- Status of assignment not submitted before
deadline?
- Submitting partial assignments?
Thursday, February 11, 2010
57. Domain Model = Concepts + Interaction
System
Domain analysis is more than drawing a class diagram
Thursday, February 11, 2010
67. From conceptual to physical data model
In memory
- objects
- hash maps
Persistent data
- Records in RDBS
- XML
- JSON
- Text (csv)
Thursday, February 11, 2010
68. Schedule
Lab this week:
★ WebDSL tutorial => submit page index
★ Make design proposal for a web application
★ Entity declarations for your web application
Read/think:
★ Read: interaction design, domain-driven design
★ Case 1: analysing issues in digital library domain
Next week
★ Web Abstractions
Thursday, February 11, 2010