2

In his book "Aspect-Oriented Software Development with Use Cases" Ivar Jacobson introduces "use case slices". It seems that DCI and use case slices are based on the same (or at least similar) idea.

What are the differences between DCI and use case slices?

Cristian Ciupitu
  • 20,270
  • 7
  • 50
  • 76
Stefan Papp
  • 2,199
  • 1
  • 28
  • 54
  • I have similar impression - I think Jacobson was trying to do DCI since beginning of the use cases, but I think use cases are useful in a quite different way... – Gabriel Ščerbák May 01 '11 at 00:15

1 Answers1

1

It seems to me they both derive from Feature Oriented Programming. The idea behind is to arrange the design of a system architecture in a set of views each one defining the way the system address a function.

In use case slices this is done at the M1 level of the OMG MDA Stack. It defines a UML profile to model the way aspects extend system classes to add properties and operations aimed at realizing specific use cases.

In DCI this is done at M0 (code) basically by means of OO techniques (not aspects as far as I understand).

Anyway it is a good question, years ago I had the same concern about Context Oriented Programming and Aspect Oriented Programming. I am still a bit convinced the former is a specific application of the latter.

Andrea Sindico
  • 7,358
  • 6
  • 47
  • 84
  • So, you say that DCI is architecture reflecting use cases and use case slices are a modeling technique for use cases, unrelated to architecture, right? That is the way I understand it. – Gabriel Ščerbák May 01 '11 at 00:18
  • They are both an architectural reflection of use cases. I guess they just exploit different technologies in different level of abstractions. Use case slices define a modeling approach to design architecture of objects and aspects satisfying use cases. Hence they are related to architecture as well. – Andrea Sindico May 01 '11 at 20:42
  • They first taught us how important was encapsulation and now the want us to break it be means of aspects or other crosscutting constructs :) – Andrea Sindico May 01 '11 at 20:45
  • So you say use case slices are ment to be visible in code? Can you give reference to that? I read only in Jacobsons summary they should be a modeling concept... – Gabriel Ščerbák May 01 '11 at 22:57
  • btw. imho aspects in architecture make sense, I am not sure about the code:)... I don't think encapsulation is the worst loss, dependency on structure is much worse... – Gabriel Ščerbák May 01 '11 at 22:59
  • I have never said use cases are ment to be visible in code. They are a UML construct and they are supposed to be used at M1 (that is what i have also said in my answer). However they could be visible in code as well since code is just another model you could generate from UML by means of proper transformation; and, also, because of the fact at code you have the same constructs use case slices consists of (i.e. classes and aspects). I also believe aspects are good things, and that is why I am so interested on AOP. ... – Andrea Sindico May 02 '11 at 05:04
  • However they are good if they are used properly. Otherwise they risk to be as dangerous as templates in C++ where many fanatics of generic programming eventually come out with very intricate architectures they are the only that can understand. Aspects are good when they simplify things but they are also so powerful that one could be tempt to use them everywhere: i.e. as means to fix bugs, add functionalities, etc. That is possible because of the fact they are not only a means to encapsulate crosscutting concerns but also to violate an already existing architecture and change things. – Andrea Sindico May 02 '11 at 05:12
  • I am repeating myself, because what you write reads as if I am right - use case slices are primarily a modeling concept and DCI is architecture - visible in code:)... – Gabriel Ščerbák May 02 '11 at 07:42
  • DCI is a stronger form of encapsulation than regular OO (also called restrictedOO). It partens what the system is from what the system does encapsulating each in seperate entitties of code. Each of those entities can encapsulate as well as any restrictedOO entity of code but the restrictedOO does not encapsulate what the system does from what the system is and since what the system does usually revolve faster than what it is, seperating the two should be a concern to the architects – Rune FS Mar 05 '12 at 10:51