I was asked to create a toolbox with some stereotypes and some custom relationships. For example, "Functional Requirements" are "Affected by" "Usability Requirements". I noticed, however, that the former already exists in the "SysML 1.5 requirements" toolbox, so I would expect to include that one in my toolbox, create the one that doesn't exist and set the relationship.
Does this make sense in the EA context or should I create the custom toolbox fully from scratch?
Related
I have an ERD Diagram of an E-commerce with the following entities Product , Tag , ProductTag,Category and other entities of course.
I tried to convert it into class diagram as follows:
1- removed the id
2- converted the foreign key into object of the type i'm refering to(product_id converted into => product: Product)
my question is , is this good approach to follow on all my entities? does it like achieve the SOLID principle? I have a presentation in 2 days and I want to be very sure of what I have made , any comment or modification would be really enough .I also chose these tables because they represent one to many and many to many. thanks in advance.
Basically your approach is correct. It's just a couple of UML specifications you got wrong.
The label in the middle of the connectors is just the name of the connector. Unless you do some OCL wizardry this name is meaningless. There is a way to adorn it with a black triangle to show the reading direction. This sometimes helps business people to understand how classes are related to each other (see Fig. 11.27 on p. 202 of UML 2.5). But usually you would not use it.
The shared aggregation has no semantics (p. 110 of UML: Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.). So leave the open diamond away. Composite (filled diamond) can be used to show responsibility (when I'm killed I will kill my composites first). Usually it adds too little to be really useful, it only heats up the futile composition-discussion.
The navigation-direction is incorrect. The AC in the middle sees both connected classes so it's shown without any arrow. If you have an additional (directed) association you place it as lone (extra) connector. In that case put role names towards any end. That makes navigation clearer than just a simple arrow. I for myself use arrows only on rough sketches on the drawing board.
P.S. Just noticing that you have operations in your classes that have the same name as the class and take one paramter being also the class. I would guess you intend to show a constructor here. In that case you would make it Classname():Classname and provide only the paramaters that are needed for the constructor. Else these opreations don't seem to make much sense. Similarly the CRUD operations seem to work on a list of 'itself' which is also probably not desired. You would have a collection class which handles the base class where these operation make sense. So to summarize: you would only add getter/setter operations for the (private) properties matching the columns from your table.
P.P.S.: As per Christophe's comment it's a good idea to adorn the class instantiation operation with a <<create>> stereotype which highlights its purpose. See p. 196 of UML 2.5:
This stereotype is part of the standard (see p. 677) and the table on p. 678 states:
Specifies that the designated feature creates an instance of the classifier to which the feature is attached.
On the modeling part of your question, there’s already a perfect answer. For the records, I’d nevertheless like to add a complementary answer on the SOLID part:
Single responsibility: your classes have more than one reason to change, because you may want to change Product for what it is (e.g. add more product-related attributes), but you may also want to change the class to add new getByXxx() operations to find products in the database based on other criteria, independently of what a product really is. SO it's not complying.
Open-closed principle: we cannot tell
Liskov substitution principle: in absence of inheritance, this is not relevant. Moreover, you couldn't tell without having precondition, postcondition and invariant constraints.
Interface segregation principe: is probably not compliant, because you impose an implicit interface that all inheriting class would have to provide, even if they don't need it (e.g. products not stored in a database). A first step in the right direction, would be to use an interface for the common database operations.
Dependency inversion: we cannot tell but probably it isn't , because update(), delete(),... probably depends on some database, so that you can't switch it to another database. With DIP, you'd inject the database in the class that use it, so that you could at any moment inject another database that offers the same interface.
You didn't ask, but your design seems to correspond to active records. If you want to go for a cleaner, more SOLID design, you should prefer factor out the database related code to either repositories or table data gateways.
In a project I work on there is a C# library containing business objects which are related to the backing database tables/stored procedures.
We imported the code into EA model (where we already have database model) and now I'd like to show dependency between a class and a table (or stored procedure output).
Since these are loosely coupled (i.e. only a portion of properties are shared between them) I'd like to have a relation between a class A and table B and in the properties of this relation to have the mapping (A.a <-> B.a , ...).
Is this possible and how?
You can draw connectors between two elements and then link one or both ends to an element feature (an attribute or an operation). Draw the connector, then right-click near the end and select Link to Element Feature.
You can draw any number of connectors between two elements, and link any number of them to any features at either or both ends.
You should note that this is an EA feature which is not in the UML standard. As such, it is also a little trickier to automate (the feature link is not documented in the API), but I've done it before for a client so it can be done. However, from your question I assume it's the manual case you're interested in.
i have a question:
Within my modeling tool (Enterprise Architect) I have modeled a meta-model (UML based).
Now I want to transform the meta-model into Ecore. But I don't know how to do it.
Within Enterprise Architect I can export the Meta-Model to UML XMI. Does anyone know if it is possible to transform the generated XMI to Ecore XMI ?!
Thanks
Does anyone know if it is possible to transform the generated XMI to Ecore XMI ?!
Yes, it's possible - at least in outline. You can think of the problem in two parts:
What's the semantic mapping? In other words, how do you map concepts in the source XMI to concepts in the target eCore model?
How will you implement those mappings in practice?
Semantic Mapping
I'm assuming here your metamodel focuses on static structure. ECore doesn't support dynamic concepts outside of declaring EOperations. More on dynamics below if that's of relevance.
I don't know EA specifically, nor which version(s) of XMI it supports. However, it will be some variant of the core UML concepts: Class, Attribute, Operation, Association, AssociationEnd, etc.
eCore has a similar (if smaller) set of concepts: EClass, EAttribute, EDataType, EReference, EOperation, etc. There's a fairly strong correlation among the 'type' concepts; for example:
UML Class --> EClass
Attribute --> EAttribute
Operation --> EOperation
So the mapping there should be straighforward. Basically create one instance of the ECore equivalent for each UML concept.
Relationships are a little less obvious but still doable. ECore doesn't support relationships directly; EReference is the only analogous concept. However it's pretty easy to synthesise associations, for example:
A one way navigable UML association becomes a single EReference with min & max cardinality copied over
A UML bi-directional association becomes two EReferences, one in each direction. You should also set the EOtherEnd property, which effectively says the two EReferences are part of the same association.
Hopefully that gives you the idea.
Implementation
Having defined your conceptual mapping there are lots of options on how to do it. All will generally follow the same basic model:
Parse Source --> Map Source Concepts to Target Concepts --> generate target text.
You could use xslt (since it's just an XML->XML transformation). You could also use one of the many Model-to-model (M2M) and/or Model-to-text (M2T) toolkits available. See e.g. the eclipse modeling project (M2M, M2T). You could also go direct from EA by reading the model using the EA API instead of generating & parsing XMI. Which you choose will depend on your environment, skillset, etc.
If you want to see what it could look like in practice, you might take a look at MagicDraw. It provides ECore export out of the box. (Note it's a paid-for tool - but eval is available).
It might also be worth asking Sparx directly: I'd be a bit surprised if there isn't some ECore export add-on/plugin available for EA.
hth.
Dynamics
If your model has dynamics (state models etc.) then you have more of a problem. ECore doesn't cover those concepts at all. It's possible to extend ECore and that might be an option - but it's potentially more work as the tools that work with ECore will be less likely to understand your extensions.
You can easily go from Ecore to UML but the other way is not really possible. You have few plugins but when you try to use them it does not work.
I am defining the meta model of a domain specific modeling language by means of Ecore in EMF. I therefore generate an editor from the related genmodel I can use to create models conform to the meta-model.
I would like to specify some OCL constraint on the values that some elements of the meta-model can assume. It would be very nice if I could specify these constraint in the Ecore model and have the related checks automatically generated editor Java code.
Is there a standard way to do that?
First step is to decide how you want to add constraints to your ecore (meta-)model. There is two ways I am aware at the moment, you can do this:
1- having ocl expressions embedded in annotation elements of the ecore model.
2- having OCL expressions in the separate file beside ecore.
For getting more information on the first approach look at OCLInEcore , and for the second one look at OCLComplete . It seems that they are providing some API for checking OCL constraint for the given models (conformance check).
For your purpose, it seems that OCLInEcore is suitable. You can have your ocl embedded in ecore, and you can use the API provided by OCLInEcore to check if the given model satisfy ocl constraints.
Hope this helps.
You should have a look at the recent work of the OCL project in Eclipse with "OCL in Ecore" or you could try one of the other way to integrate OCL with Ecore specified in the OCL Juno documentation.
Me and several other developers are currently cleaning up our legacy code base, mostly separating visual and data layers. To help developers not involved in this refactoring understand the model, I'd like to introduce a (rather informal) class diagram with comments about scope and desired usage for each class. Since I'm lazy, I'd like to use UMLGraph for that.
However there is a small problem: we've got a perl code base and the refactoring uses Moose roles extensively. Now I don't know UML good enough to find a proper abstaction for roles -- my first guess would be interfaces, but they also contain implementation; multiple inheritance doesn't quite cut it either.
How do I (or how would you) represent roles properly in a class diagram?
I'm no UML expert but in the original paper Traits were represented like this
Traits Diagram http://img.skitch.com/20100422-8iey4atkkama53ni81c3pca562.jpg
I would represent a role as a UML class with the «role» stereotype. The class composing the role would then have an association to the role with the stereotype «does».
Simple Composition http://img820.imageshack.us/img820/5665/simplecomposition.png
If I needed to further adapt the role, with aliases or exclusions, I'd create that as an association class with properly annotated members and with the «adaptation» stereotype. The name of the association class wouldn't matter, because it won't be a real type in the design; so I'd leave it unnamed.
Composition with Conflict Resolution http://img828.imageshack.us/img828/244/conflictcomposition.png
(Please note that I have shown the adaptation "class" connected to the composition and the role it adapts. What I really wanted to do was connect it to the association between MyComposition and MyRole1. It's just that the tool I used didn't support association classes).