Let A and B are classes.
A is the class which is responsible for creating class B
after creating of ,B A is associated with B
after some time class A is Delete class B
as a example for above scenario consider
there is project manager and he is responsible for creating,editing,deleting project from the system
i know class A create class b can show in UML as dependency relationship
i have two questions
how to represent class delete another class
so there is both association and dependency relationship from A to B.
How should this relationship be demonstrated on UML class diagram? Should I use booth association(straight line) and dependency(dashed line) relationships
You simply put a multiplicity of 0..1 towards the association to B. And that's it. No extra dependency.
Related
I am making an UML Class diagram, and got a question on which i could not find an answer.
So the situation is-
I have a class for employee and a class for the client. Both need their name added. Can I use one enumerator called "Name" for both classes, or I need to make an separate enumerator for each class with different naming?
For example-
One enumerator for both classes-
Or two enumerators- one for each class
I'm drawing a class UML for a JAVA software design. I don't really understand what is a stereotype. The formal definition:
The stereotype is a profile class which defines how an existing metaclass may be extended as part of a profile. It enables the use of a platform or domain specific terminology or notation in place of, or in addition to, the ones used for the extended metaclass
Is that mean the stereotype should be the name of the parent class? But why there are some superclasses also has a stereotype?
So for example, I have a superclass Animal and a class dog which extends the Animal class, what could be the stereotype of both classes? Also, why there are some classes without stereotype.
What is a stereotype and what are its purpose?
A stereotype extends UML by allowing to categorize some elements in a more detailed way than foreseen natively by UML. It helps to make the model more expressive.
A typical example are the Entity, Control, and Boundary stereotypes. They are used in a use-case driven design: in a class diagram, you can immediately find-out which classes represents the use-case logic (marked as «control» stereotype), which classes represents user-interface with actors («boundary» stereotype), and which classes represents business/domain objects (marked as «entity»).
Another use of stereotypes is to indicate the way a class is supposed to be implemented, for example to mark as «table» classes that correspond to database tables that are related to in-memory objects, or to indicate among the objects which ones are «persistent». An even more common use is to show some concepts that are language specific and have no equivalent in UML. I think in particular to C# «struct» which have a value semantic wheres C# classes have a reference semantic, or C# «property» (which is a stereotype at attribute level).
How are stereotypes defined?
Sterotypes are defined in a profile. You can see a stereotype as a class in a profile diagram.
But it's not an ordinary class that you could relate to other classes in your model. So there is no inheritance at play here. You would never indicate a superclass as stereotype.
A stereotype is a class related to the "metamodel", which means the UML standard elements defined in the UML standard. So it's a class of classes (or a class of associations, or of any other UML element).
To elaborate on your example, with an abstract superclass Animal and concrete sub-classes Cat and Dog:
you could affect them all an «entity» profile, because they all belong to the domain model.
if you would want to store the objects in an RDBMS using the concrete table inheritance, you may use a stereotype «persistent» for Cat and Dog (since concrete table inheritance pattern does not implement persistence for the abstract classes)
Let A and B are classes. A is associated with B and A also uses some static methods of B, so there is both association and dependency relationship from A to B.
How should this relationship be demonstrated on UML class diagram? Should I use 2 arrows between those classes?
You can use two association lines, but that's not necessary. You would usually denote that with association role names and the dot-notation. So this notation
is representing the same as this one:
Or in the double association representation:
In almost all EF methods that use inheritance, I see that the parent class is marked as abstract. Is there any reason why this is done? Or is it just so the abstract class cannot be instantiated?
No, that is not mandatory, your base class could not be abstract, but as you already said it's the most common. It's like a inheritance by generalization, which is extracting shared characteristics from two or more classes, and combining them into a generalized superclass, that's why is common see the base class as abstract.
In EF there are three different approaches to representing an inheritance hierarchy:
Table per Hierarchy (TPH): Enable polymorphism by denormalizing the
SQL schema, and utilize a type discriminator column that holds type
information.
Table per Type (TPT): Represent "is a" (inheritance) relationships as
"has a" (foreign key) relationships.
Table per Concrete class (TPC): Discard polymorphism and inheritance
relationships completely from the SQL schema.
In the last approach if the base class was concrete, then an additional table would be needed to hold instances of that class.
In summary, if the base class is abstract or not depends more on your side if that make sense or not in the model you are trying to represent.
I'd assume because the methods you override are also abstract? Can't have an abstract method on a non-abstract class.
So, for example, it never makes sense to instantiate a plain old DbContext -- you always need collection properties and such. The base DbContext provides functionality which all DbContext derivatives would need (connecting to a database, etc), but isn't useful as a stand-alone object.
I use standard ObjectContext and EntityObjects in my application. Let's say two of my tables are Projects & Services. Projects have Subproject (from Projects table with ParentID == ProjectID) and also Services. So I would have a hierarchy like Projects->Subprojects->Services. But I need to inherit Projects and Services from an abstract base class so I can use any of these entities as a new Task/Job entity in my application. Then, for example I can create a TreeList listing all Tasks (either a Project or Service). Is there anyway in EDMX designer I can create a new type (entity) which is the base calss for two or more concrete types?
It is possible with TPC inheritance but it will include a lot of complication to your design. For example:
you will have to move shared properties to the base class
you will probably have to maintain some mappings manually in EDMX (at least I had when I did the sample on screenshot)
you will have only single ObjectSet<Tasks> and you will have to use OfType to query only Projects or Services
you will have to use unique Id per Task = across both Project and Service tables (can be achieved by correctly configured identities in database)
It will look like:
Another option is using interface on your entity objects instead of parent class. You can define interface in your partial part of entity object and handle retrieving both Projects and Services by yourselves where your UI will expect only list of types implementing your interface.
http://blogs.microsoft.co.il/blogs/gilf/archive/2010/01/25/table-per-concrete-type-inheritance-in-entity-framework.aspx
Since it sounds like your data is coming from 2 separate tables, Projects and Services, no, I don't think you can achieve this in the designer (at least, not without hand-editing the generated edmx). If there were a common table to represent the base class, that could be done in the designer, but that doesn't sound like it fits your situation.
What you may be able to do is use an interface instead of an abstract base class, and use partial classes in your entity model to implement the interface for each of your entities. You can't directly inherit from your abstract base class in your entity model, because all of your entities already derive from EntityObject. If you have a lot of shared implementation that resides in your base class, it might be worthwhile to switch to POCO, where you can define your own inheritance hierarchy.