When designing software (think UML diagrams for example) and real world objects.
How does one identify a suitable case for an Abstract class?
For example if we had an [Employee] and [Fireman] and [paidFireman] and [unpaidFireman]...I am having trouble seeing whether a Fireman or Employee should be abstract and why?
Abstract classes are one of those more esoteric constructs in UML. Since classes are already an abstraction of real world things, an abstract class is even one level higher. Abstract classes can not be instantiated (since it is assumed they miss something for a real life). Whether you say that Fireman is abstract while the paid/unpaid are not, is a pure point of view and must be argued in the specific domain.
As a rule of thumb: leave abstract classes out of the door until you come to a point where you feel the urgent need for it. Introducing abstractness limits your model (and can help to avoid some malformed results of it). But without those limits the model is still valid as long as the architect sticks to common sense rules.
It mainly depends on your functional requirements.
If it makes sense in your application just to have simple employees (without designating them as firemen, policemen, or craftsmen), then the class may not be abstract, as the application will have to make instances just of the Employee class.
If that doesn't make sense, i.e. the occupation of each of your employees needs to be known at creation time, abstract classes come into consideration. But still they aren't necessary in every case. The easiest way to make sure the occupation is known is to model it as a mandatory attribute. Introducing a subclass only makes sense if there is specialized behavior for each of those subclasses. If, e.g., the salary of the firemen is calculated as 50$ * count of the fires he exstinguished, but the salary of the policemen is 1000$ + 50 * rank, then you model an abstract operation getSalary() in the Employee class, which will be concretely specified and implemented in each of the subclasses.
As the concept of interface also got mentioned in one of the answers, an interface describes the obligation to implement certain operations in all classes realizing that interface. That's much the same as an abstract operation in an abstract class. But the abstract class can contain much more than an interface: attributes and non-abstract operations.
So the rule of thumb is: For concepts of your domain for which interface and behavior can be fully described, use non-abstract classes. For concepts for which only interfaces and no behavior can be described, use interfaces. For concepts for which interfaces and part of the behavior can be described, use abstract classes.
There are many uses for an abstract class. An abstract class is one that cannot have any direct instances.
In software design, it is one way to describe an interface. Some of the declared operations can be implemented in the superclass. Any remaining implementations must be specified in sub-classes. Regardless of where the implementations exist, an abstract class means there can be no direct instances, only instances of some non-abstract subclass.
In a domain analysis, an abstract class is a way of modeling an abstraction. For example, think of the abstraction Role. It is useful to say that a Person plays a number of Roles. However, there is no instance of a Role that makes sense, without it also being a more specific kind of Role, such as Employee, Fireman, or Teacher. For this situation, you not only want Role to be abstract, you also want a covering axiom. For more on that, please read https://stackoverflow.com/a/35950236/2596664.
Related
Let us take an example of a Consumer class. The functions related to a Consumer will go into this class. Gradually the Consumer class has lot of methods in it. And those are supposed to be part of the Consumer class itself. In such cases, how do we break it? are there any strategies related to solving this?
This is quite a broad question but I'll attempt to answer it.
SOLID principles are good practices to follow. If you apply these, especially the Single Responsibility Principle, you will end up with smaller classes with well defined responsibilities.
It's also important to look at cohesion which is a measure of how related the elements of your class are. You want to aim for high cohesion in your classes (and modules). For example, if every method in your class uses a certain member variable, then cohesion is high. If there is a member variable of your class which is only used in one method, this is a good case to be refactored into a separate class.
Use structural design patterns. I would use either the Composite or Decorator design pattern to address your issue. You can learn about them here: https://sourcemaking.com/design_patterns/structural_patterns
As already exposed by #MoonMoo the guidelines for refactoring a fat class should be SOLID principles and cohesion of classes.
The point is: even if a method is related to a Customer, should it stay in Customer class? Or that method can be called by the Customer from another class?
The answer to these question could be a first starting point to understand which methods must stay in the Customer class and which methods can be relocated in another form in another class to which the Customer has a reference.
Why and how are dependency relationships used?
I've come across a PiggyBank example where the Analysis Model consists of a class diagram with dependency relationships.
They use two relationships "use" and "instantiate" to describe the relationships between the classes.
I don't agree with the relationship that the boundary class TransferMoneyForm has a "use" to the TranferMoneControl. I believe it should be the other way around.
Can someone exaplain to me how these two relationships should be used. Thank you in advance.
The diagram shown there is not a correct and full UML class diagram. In such all the associations and generalizations should be defined, and what is abstract, what is public or not. To show what descends from what, what is hidden, what will be never instantiated and what fields of one class has types of other classes. Here we see only information about the
functions.
And it is logical. If you'll look at the previous chapter, there is written: "A control class represents a self-contained process..." So, they are talking on processes, not classes, instances and fields.
It is NOT a class diagram. And nowhere is said that it is. It is named "Transfer Money Participants diagram". They do use the elements of the class diagram, but not to the fullest and so create something more common. It is some approximate undefined diagram on some classes, something between class, communication or component diagrams. Maybe, it is the old style of IBM? Experts (What's the best UML diagramming tool?, 1st answer) say, "IBM Rational Software Architect did not implement UML 2.0". )
As for the question, who uses whom... According to Sparx VP UML, a "usage dependency" is a "relationship in which one element requires another element ... for its full functionality". According to wiki, "The client element somehow "uses" the supplier". Here the form hasn't sense without the controlling class, and vice versa. So, I'd say, the use goes in both sides. But more honest would be to create a normal communication or component diagram. The class diagram has NOT an element to say about sending and accepting the messages. And the "use" is definitely not for it. And when they have decided not to use logic, they can put there virtually anything.
If you are making a class diagram and one your class uses function(s) of another one, that is the case to draw a use dependency connection.
As we know in OOP that interface provides a set of operations without implementation but
class is the opposite.
in Object oriented design ,we use uml the interface has a set of operations without implementation
and the class also has a set of operations without implementation(i know class has attributes in addition to its operations)?
so, what is the difference in UML?
As we know in OOP that interface provides a set of operations without implementation but class is the opposite.
Not quite true - abstract classes are classes that have one or more methods declared but not defined (in C++ and Java these are abstract methods). You can have a class defined with all its methods abstract - in which case there is close similarity with an interface.
One key idea in UML, though, is that an interface is a set of methods exposed to other classes or components. The purpose is to define a set of operations.
However, moving to programming, a method may be made abstract to aid development (e.g. by ensuring all subclasses have an implementation). This method might be purely internal to the class.
One last observation: the term interface and class in UML are not quite synonymous to interface and class in a language, say Java. For example, Java does not allow multiple class inheritance. Instead Java has the interface which allows a class to implement multiple types (not classes - a subtle difference)
EDIT
Quick note technical words:
Declare: Stating to the system that a variable or operation exists and its type or signature
Define: Same as declaring, but additionally providing a complete implementation of a variable or operation
Interface: A set of declarations of operations
Type: An object's interface(s) and other operations
Class: An object's class defines (not declares) how the object is implemented, including its internal state and the implementation of its operations
Define is to Declare as Class is to Type.
(see What is the difference between Type and Class?)
The purpose of interface is to define a set of operations but we are do the same for class also define a set of operations?
So the purpose of the interface is to declare (not define) a set of public operations that other objects want to use. A class (in UML) is the complete set of operations (public and private). A class (in Java, C++, etc.) additionally defines all non-abstract operations.
So the key is the intent: When other components of the system want to use a set of operations, use interface. When you're using UML to describe an implementation (of a component, algorithm, etc.) use class.
when I go to class that assumed to implement those operations I can't see any implementation for those operations as a diagram describe those operations or anything give a sign for implementation?
UML tool is for modelling and so deliberately avoids providing a place where you enter operation definitions - that is left for later. The idea is that you:
Define the model in UML
Use the UML tool to generate code in the target language
(And some allow you to import your code back into the tool to modify the model with any changes made during implementation. This is called "round-trip" modelling, something which the old TogetherJ product excelled at)
This deliberate gap (you might say deficiency) means that 'define' vs. 'declare' in UML is meaningless. Sorry.
Perhaps you've just seen models created for describing an overview, rather than modelling the system fully, but you can model the behaviour of a class's operations in most UML tools, and some tools also model the behaviour sufficiently that it can be executed .
The behaviour associated with an operation can be modelled using UML state machines, using UML action semantics or in several other ways. Quite often this is left out of the model - it is not always useful to go to that level of detail, so the implementations may just be hinted at in the documentation associated with the operation. But concrete classes in UML definitely have concrete behaviours associated with their operations, so the difference between UML and programming is that UML focuses on behaviour rather than implementation.
According to Wikipedia -
Unified Modeling Language (UML) is a standardized general-purpose
modeling language in the field of object-oriented software
engineering. The Unified Modeling Language includes a set of graphic
notation techniques to create visual models of object-oriented
software-intensive systems.
So, most important thing is UML is general-purpose and graphical. It is not only about classes and interfaces.
UML offers a standard way to visualize a system's architectural blueprints.
Software Construction Needs a Plan. Structure diagrams, Behavior diagrams, Interaction diagrams helps to Visualise In Multiple Dimensions and Levels of Detail which is
Appropriate For Both New and Legacy Systems.
Unified and Universal, Accommodates Parallel Development of Large Systems.
When I think of UML, one term which comes to mind is software quality. One thing that has plagued the software industry in recent year is poor software design. While the software industry has done fairly well for the last decade, the impact of globalization is changing the ways in which software is designed.
Are interfaces a layer between objects(different objects) and actions(different object types trying to perform same action)? and Interface checks what kind of object is it and how it can perform a particular action?
I'd say that it's better to think of an interface as a promise. In Java there is the interface construct that allows for inheritance of an API, but doesn't specify behavior. In general though, an interface is comprised of the methods an object presents for interacting with the object.
In duck-typed languages, if an object presents a particular set of methods (the interface) specific to a particular class, then that object is like the specifying class.
Enforcement of interface is complicated, since you need to specify some set of criteria for behavior. An interesting example would the design-by-contract ideas in Eiffel.
Are you asking about the term "interface" as used in a specific language (such as Java or Objective-C), or the generic meaning of the term?
If the latter, then an "interface" can be almost anything. Pour oil on water -- the line between them is an "interface". An interface is any point where two separate things meet and interact.
The term does not have a rigorous definition in computing, but refers to any place where two relatively distinct domains interact.
To understand interfaces in .net or Java, one must first recognize that inheritance combines two concepts:
Implementations of the derived type will include all fields (including private ones) of the base type, and can access any and all public or protected members of the base type as if it were its own.
Objects of the derived type may be freely used in place of objects of the base type.
Allowing objects to use members of more than one base type as their own is complicated. Some languages provide ways of doing so, but there can often be confusion as to which portion of which base object is being referred to, especially if one is inheriting from two classes which independently inherit from a third. Consequently, many frameworks only allow objects to inherit from one base object.
On the other hand, allowing objects to be substitutable for more than one other type of object does not create these difficulties. An object representing a database table may, for example, allow itself to be passed to a routine that wants a "thing that can enumerate contents, which are of type T (IEnumerable<T> in .net)", or a routine that wants a "thing that can have things of type T added to it" (ICollection<T> in .net), or a thing that wants a "thing that wants to know when it's no longer needed (IDisposable in .net)". Note that there are some things that want notification when they're no longer needed that do not represent enumerable collections, and there are other things that represent enumerable collections that can be abandoned without notification. Thus, neither type of object could inherit from the other, but if one uses an interface to represent "things which can enumerate their contents, which are of type T", or "things that want to know when they are no longer needed", then there's no problem having classes implement both interfaces.
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).