Sparx Systems Forum
		Enterprise Architect => General Board => Topic started by: EA_Nj on August 06, 2002, 11:38:03 am
		
			
			- 
				I was reading the 1.4 UML specification and found no mention of the "Inherit" relationship in the Use Case section.  However I did find mention of a "Generlize" relationship.
 
 Is it true that UML 1.4's "Generalize" relationship for Use Cases is really what EA refers to as Inherit relationship?
 
 
 Please clarify!
 
 Jamal
- 
				I hope I don't sound too pedantic, but inheritance is a consequence of generalization.
 
 Let me give you an example. My cat, Timoteo (Timmy) has common features with other felines, such as Tololo, the leopard that we were watching the other day in TV. Although Timmy is much smaller, he has the same general shape, the same types of teeth, paws, and so forth. An he not only shares components with leopards, lions, tigers (his alter ego, I suppose)... but shares many behavioural features as well. Whence came all these common features? According to a branch of biology called "cladistics", these features, most probably, were inherited from a common ancestor.
 
 So, the leopard's and Timmy's remote ancestor (or, more precisely, a female/male pair of ancestors) is "the most general case" of felines. General features shared by the ancestor's descendants are what is common ammong them.
 
 How did the leopard and Timmy get these features? By inheritance, of course. Cladistics (or, in object parlance, the rigorous logical operation called "generalization") helps us form the generalization tree: in the ancestor we get what is common to all descendants. Inheritance, on the other hand,  is a consequence of generalization, which enforces what general features are shared by descendants.
 
 Generalization and inheritance are logical operations we apply to what is known in UML as "classifiers" (classes, use cases, realizations...).
 
 I hope this helps clarify the issue.
 
 Jaime
- 
				Welcome!
 "Generalization" is a result of standing out among many classes, one class, which is generalization of them. It is a relation between general element and more detailed element.
 
 "Specialization" is an opposition of "generalization".
 
 "Inheritance" is implementation of "gen-spec" relation.
 
 Is it clear enough?
 
 Best regards,
 ro
- 
				Thanks for clarification. 
 
 I read my question again and realized that I had made that mistake.
 
 What I really wanted to know (and the answer to which I didn't find in any of the replies) is what is the difference between extending and inheriting in the UML parlance?
 It seems like a very subtle difference but I want to get it clarfieid from the experts.
 
 Thanks
- 
				Sorry about forgetting to welcome you (though, fortunately, ro did not forget proper manners in the last posting).  
 
 A "generalization" relationship has the blank arrowhead pointing to the "most general" class. In the example I was giving: the "domestic_cat" class, the "leopard" class, the "tiger" class, and so on... are connected to the "feline_ancestor" class, with the blank arrowheads pointing to the latter. The generalization tree that is created in this way can be read as "feline_ancestor contains the general attributes, components and behaviour  of domestic_cat, leopard, tiger..." It can also be read as " domestic_cat, leopard, tiger... inherit attributes, components and behaviour from feline_ancestor".
 
 Since use cases are classifiers (elements that can have attributes, components and behaviour), they can also be related via a generalization (or inheritance) relationship.
 
 The "extend" relationship is another matter and it applies to use cases and realizations (same symbol, with broken lines). You specify an "extend" when you want to diagram a situation in which a sequence of events should be inserted into a particular point of another use case. For example, you are executing the phone_call use case: pick up the phone, wait for dialing tone, dial... and so forth. But the most general use case, in which you will communicate with another person, is not always carried out, because you might get a "line is busy" tone. So, the line_is_busy use case (or, if you prefer, "sub-use case") is an extension of phone_call.
 
 So, the line_is_busy use case is connected to the phone_call use case with an «extend» relationship, with the arrow pointing towards phone_call. In this case, the "line is busy" sequence of events is inserted right after the "dial" event.
 
 As you can see, an «extend» sequence of events is not unconditionally carried out. It is important to have this in mind, since the «include» relationship is the one that is usually confused with «extend». «include» means that a behaviour is unconditionally inserted into a use case. Example: two use cases, add_new_user and update_user, share a validate_user_data sequence. You create a validate_user_data use case, and join the other two with an «include» (the arrow pointing to the included use case, which in this case is validate_user_data).
 
 Hope this helps!
 
 Jaime