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.
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.
We need to create a booking system that allows rape victims to book sessions with a counsellor (who is a volunteer therefore is not on duty 24/7) online. The organisation used to do the booking process over the phone, writing down important information.
This is the package diagram I created for a project. I am not sure: am I allowed to just use the packages as entities for the class diagram?
A package is a tool to structure models by grouping somehow related pieces into namespaces.
It is not unusual to recognize a decomposition that coincides somehow with larger components (e.g. Client, Application and Data). But it is not correct to use packages as a substitute for a class. It may even look confusing.
It is not a problem to keep enclosing or nested packages such as Booking system in a class diagram. But you should use a proper class box for classes. You would then be able to show not only the properties but also the operations in a different compartment. Last but not least, you could be more precise in the relationships between classes, considering that packages are only related via dependencies and some special package operations, whereas classes can be related also with associations, inheritance, etc..
For example, your diagram tells only that Booking is dependent on Client. And this means the content of one package needs to know about the other packages. But in reality Client and Booking should be associated i.e. an instance of Client would be related for a longer time to some specific instances of Booking. In this case, you'd expect that you could easily navigate from the one to the other. Associations also allow to specify multiplicity, e.g. that one client could have 1 or more bookings, but each booking would be for only one client.
Other remarks, unrelated to the question:
Your comment box suggests that you try to explain the purpose of the system, perhaps for some stakeholders. You may therefore consider using a use-case diagram to show the big picture with the different actors and the goals they want to achieve with the system.
In a class box, you could add an «Entity» stereotype above the name of the class. Entities are domain classes that matter to the users.
Data storage system seems not to fit in the diagram: it's not really an entity. Perhaps it's a class, a component or a package, but not really an entity.
Besides using EA for developing and maintaining various model definitions - is it possible to use it as a repository of instance data?
Let's say that I have defined an class, "Activity". Can I use EA as a repo for the instances of this class?
In my particular use case I'm trying to document various aspects of our helpdesk. In addition to documenting the components pertaining to our support process, I would also like to store the actual implementation information pertaining to these components.
An example:
In a sense, I would like to use EA as a central database of configuration data (the collection of defined activities) and at the same time be able to trace each configuration data item to the formal class definition. Having the possibility to trace these relationships would make it easy for us to know what defined activities nned to be updated if we change the class model, and vice versa.
How can I implement this in EA?
Does this make sense, or am I completely off when it comes to what EA can be used for?
Yes you could do that by creating instances of your classes and setting the run-state.
Create an instance by (Ctrl+) dragging your class onto a class diagram and choosing Instance(Object) for Drop As:
Then use the context menu option Features | Set Run State (Ctrl + Shift + R) to set the run states.
Whether or not this is a good idea I'll leave in the middle.
I see that Magic Draw supports both graphical and tabular notations. However, I would like to know if they can be synchronized to one another or they only function separately. So, if I create a class diagram with the graphical editor, can I generate a table from it in MagicDraw? And whenever I make the changes to one editor, the changes to be reflected in the other editor?
Thank you!
The answer is complex.
First, diagrams are views of the model. Tables, as just another kind of diagrams, are therefore views of the model. In other words, changing an element in a table will change the element in any diagram it is displayed.
Now it gets complex - but how you use the tool can simplify the. You seemed to ask, can a table be synchronized with a table and a table with a diagram? A table can be based on a scope, a query, or by composition (drag an element onto the table or create on the table). Scope or query is is a lot better because they can be used to match the diagram or package where the diagram puts its data (by default, the package where the diagram is stored).
However, diagrams are intended to be expressions of the human for us humans. Thus the diagram does not automatically add elements if they were added in a table.
How do we square the circle? How do we add (or even detect) an element created on a diagram? There is a way to get a list of diagrams (https://community.nomagic.com/usage-in-diagram-displayed-in-generic-table-t5789.html ). Using a similar technique a rule could be created to warn about elements that are not on any diagram. It is still up to you to add the element to the diagram with this information at hand (or write a fancy plugin).
I'm not sure how to draw a UML diagram for two classes match this natural language description?
The Server class has one attribute named 'disk' of type Disk.
Which one of these two diagrams is the right one?
I think the first one describes well the relationship between the classes, but the second one is a better description of the single class.
If 'disk' is an attribute, it have to has a 'dot' on the association's end.
If there is NO navigability from Disk to Server, the association should have a cross on the Server end.
If there IS navigability in both sides (attribute IS a navigability), there is NO arrows on both sides (both are omitted).
IBM SW is not in accordance to UML standards. Beware!
Go to http://omg.org and read the new standard 2.5. It is NOT accepted, but it is much more easy than old ones and is different in the documentation organization and understandability only.
Create a data type for disk.
Please go through the below link:
http://publib.boulder.ibm.com/infocenter/rsmhelp/v7r0m0/index.jsp?topic=/com.ibm.xtools.modeler.doc/topics/cclassd.html
Both diagrams could express what you need.But first one better correspond to reality. Just change composition to server side. Server is composed of Disk. It is possible to set multiplicity on disk side to zero or more and zero to one on server side. It express situation when server does not contain disk and disk can be part of other device (example. video recorder).