I'm planning to migrate a tool I build some time ago to Jetbrains Mps, I'm evaluating it but have some doubts.
The main one is if model transformation in Mps is only 1 model to 1 model. Or can I combine several models to generate some others.
Think I have a certain language called "Page language" that represent Page structures. It lets you define general layout of a kind of page.
For example, I define two models "List page" (list records of a given entity) and "Instance Page" (pages for "crud" operations).
There is another language called "Entities language", this one lets you define entities. In a Solution I create 3 models of this language: Person, City and Country to represent 3 entities.
The generation process I need to build must combine the 3 entity's models and the 2 page's models to produces 6 models of some other language, which will represent every page complete, with de structure from the Page Model and the entity's fields from the Entity Model.
Is this possible with Mps?
For example, can I iterate through Entities models and for each perform a nested iteration of Pages models, then fire one model transformation that combine the current entity with the current Pages model?
Thank you very much.
In MPS terminology we call these entities not models but "root nodes". You can certainly generate such combinations of nodes - I'd perhaps use a pre-processing script to generate the six combinations as new root nodes referring to the original entities. The concept for it could look somewhat like this:
concept TemporaryCombination extends BaseConcept
...
references:
page:Page[1]
entity:Entity[1]
...
Then a root mapping rule for the TemporaryCombination concept could drive the generation of your target nodes.
Related
How do you solve a situation when you have multiple representations of same object, depending on a view?
For example, lets say you have a book store. Within a book store, you have 2 main representations of Books:
In Lists (search results, browse by category, author, etc...): This is a compact representation that might have some aggregates like for example NumberOfAuthors and NumberOfRwviews. Each Author and Review are entities themselves saved in db.
DetailsView: here you wouldn't have aggregates but real values for each Author, as Book has a property AuthorsList.
Case 2 is clear, you get all from DB and show it. But how to solve case 1. if you want to reduce number of connections and payload to/from DB? So, if you don't want to get all actual Authors and Reviews from DB but just 2 ints for count for each of them.
Full normalized solution would be 2, but 1 seems to require either some denormalization or create 2 different entities: BookDetails and BookCompact within Business Layer.
Important: I am not talking about View DTOs, but actually getting data from DB which doesn't fit into Business Layer Book class.
For me it sounds like multiple Query Models (QM).
I used DDD with CQRS/ES style, so aggregate roots are producing events based on commands being passed in. To those events multiple QMs are subscribed. So I create multiple "views" based on requirements.
The ES (event-sourcing) has huge power - I can introduce another QMs later by replaying stored events.
Sounds like managing a lot of similar, or even duplicate data, but it has sense for me.
QMs can and are optimized to contain just enough data/structure/indexes for given purpose. This is the way out of "shared data model". I see the huge evil in "RDMS" one for all approach. You will always get lost in complexity of managing shared model - like you do.
I had a very good result with the following design:
domain package contains #Entity classes which contain all necessary data which are stored in database
dto package which contains view/views of entity which will be returned from service
Dto should have constructor which takes entity as parameter. To copy data easier you can use BeanUtils.copyProperties(domainClass, dtoClass);
By doing this you are sharing only minimal amount of information and it is returned in object which does not have any functionality.
First, don't think i'm trying to get the job done by someone else, but i'm trying to design a class diagram for a domain model and something I do is probably wrong because I'm stuck, so I just want to get hints about what i'm not doing correctly to continue...
For example, the user needs to search products by categories from a product list. Each category may have subcategories which may have subcategories, etc.
The first diagram I made was this (simplified):
The user also needs to get a tree list of categories which have at least one product.
For example, if this is all the categories tree:
Music instruments
Wind
String
Guitars
Violins
Percussion
Books
Comics
Fiction
Romance
I can't return a tree of Category which have at least one product because I would also get all subCategories, but not each sub category has a product associated to it.
I also can't remove items from the Category.subCategories collection to keep only items which have associated products because it would alter the Category entity, which may be shared elsewhere, this is not what I want.
I thought of doing a copy, but than I would get 2 different instances of the same entity in the same context, isn't it a bad thing ?
So I redesigned to this:
Now I don't get a collection of child categories I don't want with each Category, I only know about its parent category, which is ok.
However, this creates a tree of categories which is navigable only from the bottom to the top, it makes no sense for the client of ProductList who will always need a top -> bottom navigation of categories.
As a solution I think of the diagram below, but i'm not sure it is very good because it kinda dupplicates things, also the CategoryTreeItem does not seems very meaningful in the domain language.
What am I doing wrong ?
This is rather an algorithmic question than a model question. Your first approach is totally ok, unless you were silent about constraints. So you can assign a category or a sub-category to any product. If you assign a sub-category, this means as per this model, the product will also have the parent category. To make it clear I would attach a constraint that tells that a product needs to be assigned to the most finest know category grain. E.g. the guitar products would be assigned to the Guitar category. As more strange instrument like the Stick would get the Strings category (which not would mean its a guitar and a violin but just in the higher category.
Now when you will implement Category you might think of a method to return a collection of assignedInstruments() which for Guitar would return Fender, Alhambra, etc. You might augment this assignedInstruments(levelUp:BOOL) to get also those instruments of the category above.
Generally you must be clear about what the category assignment basically means. If you change the assignment the product will end up in another list.
It depends on the purpose of the diagram. Do you apply a certain software development method that defines the purpose of this diagram in a certain context and the intended readers audience?
Because you talk about a 'domain model', I guess your goal is to provide a kind of conceptual model, i.e. a model of the concepts needed to communicate the application's functionality to end users, testers etc. In that case, the first and the second diagram are both valid, but without the operations (FilterByCategory and GetCategories), because these are not relevant for that audience. The fact that the GUI only displays a subset of the full category tree is usually not expressed in a UML diagram, but in plain text.
On the other hand, if your intention is to provide a technical design for developers, then the third diagram is valid. The developers probably need a class to persist categories in the database ('Category') and a separate class to supply categories to the GUI ('CategoryTreeItem'). You are right that this distinction is not meaningful in the domain language, but in a technical design, it is common to have such additional classes. Please check with the developers if your model is compatible with the programming language and libraries/frameworks they use.
One final remark:
In the first diagram, you specified multiplicity=1 on the parent side. This would mean that every Category has a parent, which is obviously not true. The second diagram has the correct multiplicity: 0..1. The third diagram has an incorrect multiplicity=1 on the composition of CategoryTreeItem.
From my perspective your design is overly complex.
Crafting a domain model around querying needs is usually the wrong approach. Domain models are most useful to express domain behaviors. In other words, to process commands and protect invariants within the correct boundaries.
If your Product Aggregate Root (AR) references a Category AR by id and this relationship is stored in a relationnal DB then you can easily fulfill any of the mentionned querying use cases with a simple DB query. You'd start by gathering a flat representation of the tree which could then be used to construct an in-memory tree.
These queries could be exposed through a ProductQueryService that is part of the application layer, not the domain as those aren't used to enforce domain rules or invariants: I assumed they are used to fullfil reporting or UI display needs. It is there you could have a concept such as ProductCategoryTreeItemDTO for the in-memory representation.
You are also using the wrong terms according to DDD tactical patterns in your diagrams which is very misleading. An AR is an Entity, but an Entity is not necessarily an AR. The Entity term is mostly used to refer to a concept that is uniquely identified within the boundary of it's AR only, but not globally.
I'm studying for a reexam in OOAD and doing some old exam questions. I'm trying to develop an analysis class model that may be used to manage a restaurant's menus. Here are the requirements:
Several different menus (breakfast,lunch,dinner)
Dishes may exists in several different menus
The restaurant also provides catering
Dishes should keep information which is relevant for guests with special requests (vegetarian,allergies etc..) Special menus may be created using this information as search criteria.
How I should model the catering? Should there be a Menu class and then breakfast,lunch,dinner and special as specialization classes or should I just have one Menu class? Should there be specialization classes for vegetarian,gluten free..etc dishes?
Then I have this question which confuses me a bit..
"What are 4 tasks that must be addressed when you transform this analysis class model into a design model?"
What is meant by this? Are there 4 general tasks/steps that always should be done when translating an analysis model into a design model or is it 4 specific tasks specifically for this analysis class model?
I've looked thorugh the presentations and the book (OOAD with applications) and the only thing I found related to these 4 steps/tasks was in a case study:
■ Identify the architectural elements at the given level of abstraction to further establish the problem boundaries and begin the object-oriented decomposition.
■ Identify the semantics of the elements, that is, establish their behavior and attributes.
■ Identify the relationships among the elements to solidify their boundaries and collaborators.
■ Specify the interface of the elements and then their refinement in preparation for analysis at the next level of abstraction.
Regards
How I should model the catering? Should there be a Menu class and then breakfast,lunch,dinner and special as specialization classes or should I just have one Menu class? Should there be specialization classes for vegetarian,gluten free..etc dishes?
You should be modeling your business requirements. In your case, the requirements you have are from your exam task only. So you will have to decide what you include in your model. Only include in your business domain model what you think you will need to hold a state, or perform an operation on.
Should there be specialization classes for vegetarian,gluten free..etc dishes?
Should be possible to save that in a simple boolean flag in the meal class, don't you think?
The "4 tasks" question is open for interpretation and is probably best answered when you have the documents from your studies available. At least I'd consider the 4 tasks you list a reasonable answer to the question.
Welcome to StackOverflow.
If you post your modeling attempts as a image file, you may receive more detailed help. You may use a service like dropbox to reference graphics until you have enough reputation for uploads to SO.
Class diagram by myself,for reference.
1.Which of the following types of written design documents do we normally use on DDD projects:
a. Requirements specifications document
b. Document explaining the the meaning of core elements
c. Document giving the bird's eye view of an application structure
d. Document explaining the meaning behind the terms used by Ubiquitous language
e. Document listing the vocabulary of Ubiquitous language
f. Informal UML diagrams
anything else?
2.Which document types should be created as standalone documents and which should be combined within a single document ( example: document containing diagrams surrounded by text )?
3.And what are Requirements specifications? A list of use cases, a list of tasks program is able to perform or combination of both?
thanks
Consider the following:
A statement of the purpose of your application in 25 words or less
A representation of your model in both code and uml
A list of features corresponding to the current or desired model
A list of constraints (business rules) on the model
Where applicable, a sequence diagram for each feature
A statement of non-functional requirements
An architectural overview for team members (including model boundaries and contexts)
Team instructions and procedures
Note: use cases or user stories can inform your list of features. However, I recommend that a feature be the unit of work.
I recommend that the initial model be created (discovered) in a modeling workshop attended by both domain experts (business) and developers. It must be led by someone proficient in domain modeling.
Business rules are constraints on the model of two types: Property and Collaboration. By way of example, business rules prevent an elevator from moving with the doors open, a perishable item being placed in a non-refrigerated bin, or a cancelled purchase being shipped.
I think Event Storming might be a good solution. A photo of the workshop should be enough. If not you can use the same artifacts into a digital document.
What is the difference between a domain model and a data model?
A datamodel is a design model that only describes data and it's relations. The model contains entities, but they are described in terms of what data they own not how they act on this data or what their responsibilities are.
An domain model on the other hand, is a conceptual model used in analysis of a problem domain. It describes the domain in terms of entities that have relations, data and behaviour. It describes the responsibilities of those entities as relevant for understanding the problem domain.
BTW an excelent and very short introduction to UML is:
UML Distilled: A Brief Guide to the Standard Object Modeling Language
A data model is focused on the DB schema definition, including tables, columns, and relationships.
A domain model is focused on the business domain, including concepts (classes of objects), behavior (methods/logic), and relationships.
In both cases, the cardinality is used for relationships (e.g. 1:1, 1:Many, 0:Many, ...).
That said, you would ideally like the data model and domain model to be closely related, i.e. a Person with name, ... and a MailingAddress, ... relates to a PERSON table with a NAME column and a FK to a MAILING_ADDR table entry. You have to decide where logic is hosted - in the objects in the software system vs. in the DB via procedures, triggers, and such.
I think it's important to provide some clarity here for posterity.
A data model is a design for how to structure and represent information. By structure, I mean concerns like "fifth normal form". By representation, I mean choosing a computer serialization, such as integer, floating point, or string.
The term domain model actually has two conflated meanings.
A model of essential characteristics of real or imaginary things in the world. In this kind of model, classes represent human conceptualizations and instances are things in the world. For example, a "Person" class would have instances including you and me, and an essential characteristic might be that every Person has a mother. This kind of model is often called an conceptual ontology or concept model and is intended to provide meaning.
A model of required information about things in the world, usually with some system in mind. In this kind of model, classes represent information that must be stored about things in the world. For example, a "Person" class would have instances representing required information about you and me, such as first name, last name, date of birth, current height, and current weight. This information often does not include all essential characteristics, such as our mothers, because, for the purposes of a particular system, that information is not required. This kind of model is often called an information model, conceptual data model, or operational ontology.
Both the UML and OWL languages can be used to represent either kind of domain model. Both can be considered analysis models, as they are used to analyze a domain. One is used to understand things in a domain, the other is used to gather requirements to build a particular software or database system for things in a domain. Both are necessary, and, unfortunately, they are usually conflated such that people building an analysis model are themselves confused about what they are modeling!
I think that domain model and data model are now pretty much the same with new top down modelling technologies. I mean that you can model in a class diagram and only add database stereotypes in your diagram. If you use the tool that I use then your ejb3 annotation would be immediately synchronized with your code. The next step is only to use a mapper to create your database. This technology only works with Java