The document outlines a lecture on domain analysis and data modeling in the context of designing and implementing domain-specific languages (DSLs) within software development. It emphasizes the importance of models in understanding systems, domain engineering as a way to utilize reusable assets, and the integration of interaction design into software engineering practices. Key concepts like abstraction, user needs, and effective collaboration through DSLs are discussed throughout the lecture.

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

10. What makes a DSL?
Thursday, February 11, 2010

11. What makes a DSL?
The Domain
Thursday, February 11, 2010

12. What is a domain?
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

18. System
Thursday, February 11, 2010

19. Interaction Design
Domain-Driven Design
Data Model Design
Thursday, February 11, 2010

20. Interaction Design
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

23. 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

30. Thursday, February 11, 2010

31. Thursday, February 11, 2010

32. Thursday, February 11, 2010

33. Thursday, February 11, 2010

34. Thursday, February 11, 2010

35. Thursday, February 11, 2010

36. Thursday, February 11, 2010

37. Thursday, February 11, 2010

38. Thursday, February 11, 2010

39. Thursday, February 11, 2010

40. Thursday, February 11, 2010

41. Thursday, February 11, 2010

42. Thursday, February 11, 2010

43. Thursday, February 11, 2010

44. Thursday, February 11, 2010

45. Thursday, February 11, 2010

46. What goals does/should ‘The Department’ support?
Thursday, February 11, 2010

47. 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

51. Thursday, February 11, 2010

52. [Course]-*[Student]
[Course]-*[Lecturer]
[Course]-*[Assistant]
[Course]-*[Lecture]
[Course]-*[Assignment]
[Assignment]-*[Submission]
[Submission]1-1..[Student]
[Lecture]-[Slides]
[Lecture]-[Notes]
http://yUML.me: a DSL for drawing UML diagrams
Thursday, February 11, 2010

53. 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

58. A domain-specific language
for domain-driven design
Thursday, February 11, 2010

59. entities with properties
Thursday, February 11, 2010

60. Thursday, February 11, 2010

61. Thursday, February 11, 2010

62. Thursday, February 11, 2010

63. Thursday, February 11, 2010

64. Thursday, February 11, 2010

65. Thursday, February 11, 2010

66. ‘Physical’ Data Models
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