Models and architecture

Many ana­lyst and UML prac­ti­tion­er use Use Cases as a “pro­cess mod­el”. It is really bad idea. As we say “we use OOAD meth­ods”, it means we use object paradigm. The fund­at­in of OOAD is her­met­iz­a­tion, but «include» and «extend» depend­encys break this rule.

A lots of time we see dia­grams like this:

Uses Case mod­els with include and extend stereotypes 

A few cita­tion (UML spe­cific­a­tion) :

A UseCase is a kind of Beha­viored Clas­si­fi­er that rep­res­ents a declar­a­tion of a set of offered Beha­vi­ors. Each UseCase spe­cifies some beha­vi­or that a sub­ject can per­form in col­lab­or­a­tion with one or more Act­ors. UseCases define the offered Beha­vi­ors of the sub­ject without ref­er­ence to its intern­al struc­ture. These Beha­vi­ors, involving inter­ac­tions between the Act­ors and the sub­ject, may res­ult in changes to the state of the sub­ject and com­mu­nic­a­tions with its envir­on­ment. A UseCase can include pos­sible vari­ations of its basic beha­vi­or, includ­ing excep­tion­al beha­vi­or and error hand­ling. (UML, 18.1.3.1 Use Cases and Actors) 

Import­ant sen­tence: without ref­er­ence to its intern­al struc­ture (see what encap­su­la­tion means below).

An Extend is a rela­tion­ship from an extend­ing UseCase (the exten­sion) to an exten­ded UseCase (the exten­ded­Case) that spe­cifies how and when the beha­vi­or defined in the extend­ing UseCase can be inser­ted into the beha­vi­or defined in the exten­ded UseCase. The exten­sion takes place at one or more spe­cif­ic exten­sion points defined in the exten­ded UseCase. (UML, 18.1.3.2 Extends) 

The Include rela­tion­ship is inten­ded to be used when there are com­mon parts of the beha­vi­or of two or more UseCases. This com­mon part is then extrac­ted to a sep­ar­ate UseCase, to be included by all the base UseCases hav­ing this part in com­mon. As the primary use of the Include rela­tion­ship is for reuse of com­mon parts, what is left in a base UseCase is usu­ally not com­plete in itself but depend­ent on the included parts to be mean­ing­ful. (UML, 18.1.3.3 Includes). 

Object ori­ented paradigm based on main concepts: 

• object (part of system) 
• encap­su­la­tion (objects hides their implementation) 
• poly­morph­ism (one oper­a­tion could be imple­men­ted by more then one methods) 
• coöper­a­tion (objects coöper­ate to achieve the par­tic­u­lar goal) 

In OOAD «include» and «extend» breaks encap­su­la­tion (we can­’t use use dia­gram to mod­el­ing any intern­al applic­a­tion or com­pon­ent structure/architecture). , .

Need more argu­ments and explan­a­tion? Try my courses… 

References