I have a question about modeling associations between classes and interfaces. As far as I know, an interface specifies what an object can do; without providing the state or functionality (When to use an interface instead of an abstract class and vice versa?). Also, my book on OOAD (Object Oriented Modeling and Design by James Rubaugh)states that an association describes a group of links with common structure and common semantics, between object instances.
Now, suppose I have the following entities:
1) ICar Interface: Defines the operations a car can do
2) BMW : A class that realizes the ICar interface
3)IWheel : An interface defining the wheel capabilities
4) LuxuryWheel : A class that realizes the IWheel interface
Now, to model the relationship between BMW and LuuryWheel, which of the following do you think is correct, in a design perspective? I have shared my thoughts on each one
A) Create an association between ICar and Iwheel. BMW class can create concrete instances of LuxuryWheel class. This is highly flexible but couples car's capabilities with Wheel' s capabilities. Also, the definition of association says the relation is between instances.
B) Create an association between the BMW class and LuxuryWheel class. Solves the particular problem; but tightly couples BMW to Luxury wheels
C) Create an association between BMW class and Iwheel interface. This way BMW can use any type that realizes the IWheel interface.
Option C) looks better to me. Please share your thoughts.
I agree with Vladimir that, since you want to model cars and wheels with the help of interfaces, the association between them (which is actually a composition) should be modeled between the interfaces ICar and IWheel, as in the following diagram:
Since the classes BMW and LuxuryWheel realize the interfaces ICar and IWheel, they also need to realize/implement this association/composition, e.g. with the help of a 4-valued reference property BMW::wheels, or with the help of 4 different reference properties in BMW: leftRearWheel, rightRearWheel, leftFrontWheel, rightFrontWheel.
In order to get robust solution, create association between ICar and IWheel interfaces. It is possible , because interfaces are types. Connecting interfaces using association means, that any instance of classifier which realizes ICar interface must be associated to instance of classifier which realizes IWheel. You also define abstract classes for car and wheel and make association between them. The result will be similar.
Simply speaking a car can support different type of motors. So you must think to an additional class that permit to add different type of motors. In this case relation between interfaces or classes must be do it with some additional interface.
Related
Currently I am trying to model a UML diagram for cars. I have the problem that besides the combustion engines also electric cars exist.
When you look at the diagram, you can see that the Golf has the data type Fuel for the attribute consumes, while the e-Golf has the data type EnergyType.
How would you adapt this diagram?
Inheritance is meant differently. You already define consumes an enumeration in the abstract class. Now in the inheriting ones you do not override this attribute but just assign fixed values. Plus you use a wrong notation in that case. It would be rather consumes: Energytype = electrical energy (etc.). This type anyway is superfluous since you would have it in the class type itself. A concrete electric car is of the type you want. So that enumeration would contain the possible concrete class types (if needed at all). Now you should rather concentrate on what the different car types are. The only common thing is probably the chassis which will be defined in the abstract car.
N.B. thinking this way of cars is what the dinosaurs actually do and which is why they have so much trouble. E-cars are much more different than classic cars. Basically you need to go back to the seats for humans inside for the abstract car.
Amendment
could be a way to express a car (there are lots and lots of ways to show variants and it takes weeks and months to get to something appropriate for cars). You see that the abstract car (written in italics) has no attributes but just associations with role names. Some to abstract classes and one to a concrete class (note that this is just something meant as example). The abstract classes just have associations and contain attributes which are agreed to be common to that thing.
Now if you're building some concrete car configuration you will only have concrete classes:
The MySuperNewCar has an electric drive with 4 wheels and 2 leather seats. I repeated the abstract classes in this diagram. But that's not needed (since you probably would already guess so).
So, thats one way to describe a car. There are much more ways which need long discussions. In any way you should get a consultant aboard who's talking UML fluently (in other words who's good at modeling things).
I would advise to use different names for attributes with different types. Instead of 'consumes' you could use 'energyType' and 'fuelType'.
Hello I'm trying to prepare an ER diagram + a class diagram.
The system is very simple. It involves a simple flight reservation system with two roles (actors).
In the ERD, we can distinguish between the two roles using the "IsAdmin" attribute("true" for admin, and "false" for customer).
In the class diagram, I have a base class named "User" (containing all the attributes and methods of the customer role and all the attributes and some of the methods of the admin role).
Should I use the User class when dealing with the customer entity (since the attributes and methods are the same), or should I create an empty class derived from the User class for clarity?
It depends...
Basically when dealing with business objects I would not use a class named "User" which says all or nothing. You have a "Customer" and an "Admin" and likely many other "User"s. Don't make the "User" a "Customer".
Setting that aside, if you are using a serialization framework that often requires table and class to have the same name.
Also you shouldn't start a system with optimization. Give clarity an advantage in favor of that. It will pay out more sooner than later. And in any case: you can optimize at later stages as well.
ER Diagrams (ERDs) and UML Class Diagrams (CDs) are both information modeling languages that essentially cover the same concepts, but using a different visual syntax. Both allow modeling classes with properties/attributes (and operations/methods in the case of CDs) defining entity types, and associations (or relationship types).
Since CDs have been defined more recently, they are more expressive than, and subsume, ERDs. Consequently, there is no need to duplicate an information model both as an ERD and a CD. Rather, you should make a logical class design diagram from which you can obtain both OOP class models (defining, e.g., Java classes) and RDB table models.
If needed, you can derive an ERD from your CD.
I have a class called pet, which is dynamically associated to either 1 dog or cat but not both at the same time.
What's the name for this type of dynamic association? How can I represent this in a UML class diagram while making it clear that each pet is associated to either one dog or cat but not both at the same time?
Is what you're after simply inheritance? Pet seems to me to be an abstract concept, where as Dog and Cat would be concrete concepts. My initial solution in your situation would probably be to have an abstract Pet class (which cannot be instantiated) which is specialized to Dog and Cat (which can).
If you are really keen to have an instance of a Pet which is associated with an instance of either a Cat or a Dog, then you'd probably have to manage this by inheritance anyway. Something like this perhaps:
The wording of your question is bit funny when reading it as a model of the real world (a domain model).
In the real world, a pet is not associated with an animal. Rather, a pet IS an animal. Consequently, the class pets is a (role) subclass of animals, in a domain model, based on the meaning of the term "pet" in English.
The concept of role classes is not very well supported by mainstream OOP languages. An object may play many roles (that is, instantiate many role classes) at the same time (multiple classification) and it may cease to play a role, that is, cease to instantiate the corresponding role class (dynamic classification).
Maybe you are not interested in making a domain model first, before making a (technology-independent) design model, which you may then turn, e.g., into a Java or C# class model.
Maybe you want to jump to a C++ class model directly, without first trying to understand the underlying domain concepts.
You can do this, but I don't think it's a good idea.
I have read about meta-modeling (including M0,M1,M2,M3)
I understood the goal of M0 (runtime execution), but I don't understand the meaning of M1,M2, can someone give a good example to where and how to define a profile? and what is the meaning of the tagged values in a profile?
They are abstraction levels. The higher the number the more abstract the definition. The M3 level describes a framework in which you build your system. This framework is called profile. Imagine a car factory. They build cars. So in the profile you define such a car with what it would need. Then you can create a car class in a concrete model and it is distinct in certain respects (e.g. it must have 4 wheels, a motor etc.). Or take requirements: A requirement can simply be a piece of text. But in your modeling environment you might require them to have a distinction functional/non-functional, a source, a priority, whatever. So you define those as attributes in the meta-model and when you use the so defined Requirement stereotype the concrete class will have tagged values with the name of the attributes.
On Wikipedia, I'm reading that an association relationship is an instance level relationship so we are talking about the relationship between the objects of two classes.
When we actually draw a class diagram, why do we use association on the class elements or blocks rather than objects? And there are also class level relationships for which we again use class elements. Since we don't have any way to show if we are talking about objects or classes I find this confusing. For example: I've heard people saying "Associate these two classes" Doesn't that sound wrong?
Links are to Associations as Objects are to Classes.
A Class is an abstraction that describes many specific objects. Similarly, an Association is an abstraction that describes many links between objects.
So your statement
an association relationship is an instance level relationship
isn't strictly correct because it mixes the abstraction (Association Relationship) with the instances it represents.
hth.
In fact, when you associate two or more classes it is done thanks to two or more UML Properties.
These latter are the "ends" of your associations and are "instance" i.e. they are typed by classe.
So an association is created between two classes on a class diagram but between each classes and the association you have a UML property.
Hoping it sounds clear ...
When you are making a class diagram you are defining types. Suppose you have a class User and a class Account, you use an association between User and Account to say: User instances can have link(s) with Account instances at runtime.
So, you use classes and associations at type level (class diagram) to define what can be possible at runtime (instance level).
The object is actually the Class that has been created virtualy. So a class is the "static" version of an Object. So, when we speak of UML, we speak about classes and not object.
But correct me if I'm wrong!