1 / 20

Exploring Domain Models and Aspect-Oriented Concepts in Software Engineering

This paper examines the roles of domain models and the concept of 'aspects' in software engineering, specifically within domain modeling. It discusses the scientific underpinnings of modeling, contrasting traditional domain models with the proposed aspect-oriented methodology. The paper addresses the challenges of defining and identifying true domain aspects, refuting common misconceptions, and providing theoretical proof for the argument that domain models can exist without aspects. Practical examples highlight the necessity for clarity in aspect-oriented programming and the implications for modeling languages.

kordell
Download Presentation

Exploring Domain Models and Aspect-Oriented Concepts in Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Domain Models Are Aspect Free Friedrich Steimann Fernuniversität in Hagen @ MoDELS 2005

  2. Outline • motivation • presentation as scientific work • modelling and aspect orientation

  3. Motivation • aspects are a new concept • that is useful • offers something unavailable before • or something that had to simulated • that is generally useful in SE • that is useful in domain modelling • everything must become aspect ready • including domain modelling

  4. frankly, I doubt it!

  5. Scientific approach • observation • explanation (hypothesis) • theory • proof or • falsification • falsifiable(theory) scientific(theory) • says Karl Popper

  6. Observation • monotony of examples • usually some technicality or programming issue • seldom concepts that I would expect in a domain model • if domain-level, reason for it being an aspect is typically lacking (or informally argued) • e.g. interest rates in a banking application • e.g. card verification in a transportation system • e.g. give crystals in a game

  7. Explanation why is this so? • domain aspects are so obvious that there is no need to talk about them? • do you think so? • why then recurrence to technical aspects in examples? • there are no aspects in domain modelling? • maybe

  8. Theory Domain modelsareaspect free.

  9. Problems Domain models are aspect free. • What is a domain model? • (formal) description of that part of the world that hosts a particular programming problem • What is an aspect? • concept involving obliviousness + quantification

  10. Proof attempt This sentence is false. • a language is logically unsound if above sentence may refer to itself (says Tarski) • introduction of orders to separate levels • FOPL is standard semantics for data models • e.g. relational data model • e.g. entity relationship model • they admit no propositions over propositions • sufficient for domain modelling

  11. Proof attempt • obliviousness: every aspect has a where/when clause • quantification: not based on an enumeration of targets • set of targets unpredictable (potentially infinite) • no natural translation to FOPL • aspects are second order • and not first order  m(x, …): s(m(x, …))  (m(x, …)  a(x, …))  m(x, …): s(m(x, …))  (m(x, …)  a(x, …))  m(x, …): s(m(x, …))  (m(x, …)  a(x, …))

  12. firstOrder(domainModels)  secondOrder(aspects) aspectFree(domainModels) q.e.d.

  13. Refutation • falsification of theory is methodically simple: provision of counterexamples • but: where are they? • “pseudo aspects” to be excluded from refutation • roles are no aspects • subroutine calls (or even annotations) are no aspects • everything coming without obliviousness + quantification is not an aspect • (everything that can be expressed without aspects)

  14. Pseudo aspects “roles” • a role specifies context-specific properties and behaviour • objects of different types (classes) can play the same role • roles classify objects • classification crosscuts class hierarchy • but: role implementation differs per class

  15. Role named type definition depends on (collaboration with) other roles implementation is polymorphic Aspect not a type (not today) definition is isolated (independent of other aspects) implementation is the same throughout Roles  Aspects

  16. Concrete pseudo aspects • interest rate seems to be a POSC • validate card seems to be a sub use case • give crystal seems to be a subroutine that is called in certain conditions of a game • Personalization (e.g., car convenience scenario) is a role Personalizable (it’s polymorphic!)

  17. Aspects and modelling • aspects break with locality principle • graphical modelling lives on locality(n-dimensional neighbourhood through lines) • aspects difficult to depict graphically • as subroutines before • as design patterns

  18. Aspects and modelling • modelling itself is perhaps aspect oriented • different views = different aspects? • AOP concepts and techniques may be useful in defining a modelling langauge • weaving is certainly needed • the metamodelling language is aspect oriented, but not the language it models! • in line with second orderedness of aspects

  19. Prove me wrong! Send me aspects • that are not pseudo • that are part of a domain model • that need aspects as a modelling concept • one is not enough! steimann@acm.org

  20. Thank You! Questions?

More Related