Models and architecture

Many analyst and UML practitioner use Use Cases as a “process model”. It is really bad idea. As we say “we use OOAD methods”, it means we use object paradigm. The fundatin of OOAD is hermetization, but ‘include’ and ‘extend’ dependencys break this rule.

A lots of time we see diagrams like this:

Uses Case models with include and extend stereotypes

A few citation (UML specification) :

A UseCase is a kind of Behaviored Classifier that represents a declaration of a set of offered Behaviors. Each UseCase specifies some behavior that a subject can perform in collaboration with one or more Actors. UseCases define the offered Behaviors of the subject without reference to its internal structure. These Behaviors, involving interactions between the Actors and the subject, may result in changes to the state of the subject and communications with its environment. A UseCase can include possible variations of its basic behavior, including exceptional behavior and error handling. (UML, 18.1.3.1 Use Cases and Actors)

Important sentence: without reference to its internal structure (see what encapsulation means below).

An Extend is a relationship from an extending UseCase (the extension) to an extended UseCase (the extendedCase) that specifies how and when the behavior defined in the extending UseCase can be inserted into the behavior defined in the extended UseCase. The extension takes place at one or more specific extension points defined in the extended UseCase. (UML, 18.1.3.2 Extends)

The Include relationship is intended to be used when there are common parts of the behavior of two or more UseCases. This common part is then extracted to a separate UseCase, to be included by all the base UseCases having this part in common. As the primary use of the Include relationship is for reuse of common parts, what is left in a base UseCase is usually not complete in itself but dependent on the included parts to be meaningful. (UML, 18.1.3.3 Includes).

Object oriented paradigm based on main concepts:

• object (part of system)
• encapsulation (objects hides their implementation)
• polymorphism (one operation could be implemented by more then one methods)
• cooperation (objects cooperate to achieve the particular goal)

In OOAD <<include>> and <<extend>> breaks encapsulation (we can’t use use diagram to modeling any internal application or component structure/architecture). , .

Need more arguments and explanation? Try my courses…

References