Bdd and dsl как способ построения коммуникации на проекте
- 1. BDD DSL как формализованный способ построения эффективной коммуникации между всеми участниками Delivery and Value Team Anton Semenchenko ISSoft
- 2. BDD Behavior-Driven Development • Behavioral specifications • Backlog Items • Acceptance test as a part of Definition of Done • Specification as a ubiquitous language • TDD Test-Driven Development • Tooling principles • DSL • User stories • Story versus specification
- 3. DSL Domain Specific Language A computer programming language of limited expressiveness focused on a particular domain. • Computer programming language • Language nature – sense of fluency, structure • Limited expressiveness - a bare minimum of features to support its domain. It’s impossible to build entire system in a DSL; you use a DSL for one particular aspect of the system. • Domain focus – clear focus on a small domain.
- 4. DLS – 3 main categories • External DSL- SQL, Regular Expressions, AWK, XML (for configuration BI and Mockup frameworks) • Internal DSL – Lisp, Ruby … Flow DP • A Language workbench • Fragmentary (external – regular expressions; internal – Mock frameworks) • Stand-alone DSL’s
- 5. Boundaries of DSLs •Language nature •Domain focus •Limited expressiveness • The domain focus isn’t a good boundary condition – the boundaries more commonly resolve around limited expressiveness and language nature.
- 6. Architecture of DSL processing •DSL script •Parse •Semantic model •Generate •Target code
- 7. “Low” level details • In thisour point of view a DSL is a front-end to a library providing a different style of manipulation to the “std” command-query interface. • In this context, the library is a Semantic Model of the DSL. • Without code generation- “interpretation language” • With code generation – “compilation language” • Efforts to build DSL is usually much smaller than for building the underling model.
- 8. DSL – Why? •Improving development productivity 1. The easier it is to read a lump of code, the easier it is to find mistakes, and the easier it is to modify the system. 2. The limited expressiveness of DSL’s makes it harder to say wrong things and easier to see when you’ve made an error. 3. Avoids duplication by gathering together common code. 4. Provides an abstraction 5. DSl can help learn how to use API – how to combine “call’s” together.
- 9. DSL – Why? •Communication with Domain experts 1. Provides language for communication with Domain experts Notes: Only subset of DSL’s could be used for this purpose (for example regular expressions can’t) 2. Write and READ DSL code 3. Involve Domain experts on building a model 4. Involve Domain experts on building a ubiquitous language 5. Note: Trying to describe a domain using a DSL is useful even if DSL is never implemented. It can be beneficial just as a platform for communication
- 10. Problems with DSL’s •There is no experience in DSL usage •There is no experience in DSL development •There is no resources for “time consuming” DSL development
- 11. Problems with DSL’s • A huge set of DSL’s inside one project Incremental costs of learning the DSL is quite small compared to the cost of understanding model. • Cost of Building (another point of view) A DSL may be a small incremental cost over its underling library, but it’s still a cost. The cost of DSL is the cost over the cost of building the model. A DSL may help think about the model and reduce cost of building it. • Too specific Language Make sure you have a clear sense of what narrow problem the DSL is focused on.
- 12. Real life example •2 independent phases •2 independent contracts •2 absolutely different solutions
- 13. Real life example • General “business” context • Current “business” context • General “technical” context • Phase 1 • Solution 1 – “classical” • Pros and Cons • Phase 2 • Solution 2 1. Ubiquitous language 2. BDD 3. 3 Models (State Machines) 4. 3 DSL • Pros and Cons (almost for free)
- 14. Anton Semenchenko Skype: csi.AntonSemenchenko Cell: +375 44 74 00 385 +375 33 33 46 120 ISSoft [email protected] Thanks