Advice on consolidating thoughts.

[Mikey]

Hello all,

Ive done a mountain of reading and research, and id like to make sure i'm on the right track, all comments welcome.

Firstly, I started with "what makes quality" and what does quality mean. Ive come to the reasoning that Quality (in code) is Readability(~Understandability), Correctness and Maintainability.

There has been several methodologies and practices to achieve this. To name a few;

• "Composition over Inheritance"
• "Coupling and Cohesion"
  
• SOLID (Single Responsibility, Open/Closed, Liskov substitution, Interface segregation and Dependency inversion)
• GRASP Principles
• and Design Patterns

Would i be correct in saying that there are heavy parallels to these practices and DCI?

1. "Keeping the domains simple" would refer to Single Responsibility Principle. High Cohesion.
2. Interface Segregation/Program to interfaces/Dependency Inversion is given with RolePlayer requirements.
3. From what i can tell, the Behavioral "Design Patterns" may be redundant?
4. GRASP speaks of a Use Case Controller. From what i understand in DCI, The "Controller" (MVC) is not a role, but the "DCI Context" object holding the que-cards.

Some questions;

From what i can tell, a Context is a "Perspective" on objects by the client wishing to use them. "Looking" upon the objects differently. The strategy pattern talks about a context, and GRASP also talks of a context. Are the means of Context the same from these to DCI? If not, what are the differences?

Thankyou,

Mike Brown

[Mikey B]

The UseCaseController pattern discusses some interesting topics. implementing usecase inclusions and extensions. Generalizing usecases with inheritance and that the Controller can take two forms (facades and usecase scenario), which i feel confirms that there is two types, one which can be a roleplayer, and one which can not.

an link for those interested paginas.fe.up.pt/~aaguiar/as2003-2004/UseCaseCtrl-EuroPLoP2001.pdf

mike brown

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To view this discussion on the web visit https://groups.google.com/d/msg/object-composition/-/vExY2enyDfIJ.
To post to this group, send email to object-co...@googlegroups.com.
To unsubscribe from this group, send email to object-composit...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/object-composition?hl=en.

[Mikey]

Ive found some more references to the UseCaseController Pattern.

I am positive that a DCI Context = UseCaseController. 

One thing i did learn from GRASP is that the MVC Controller's responsibilities are not the same as the Context. They are separate objects. A Controller typically calls a use-case. 

UseCaseController's contain only one use-case, and so are named as the use-case (e.g. PlaceOrderUseCase), and have the "execute" method, and not use-case que-cards. If this is the correct definition for a DCI Context. Then it is impossible to have a Context be a RolePlayer.

This nesting business has been a bugbear for a long time for me. I hope I can convince people here that its time to let go of this idea.

Mike Brown.

To post to this group, send email to object-composition@googlegroups.com.
To unsubscribe from this group, send email to object-composition+unsub...@googlegroups.com.

[rune funch]

Den 27/06/2012 kl. 20.54 skrev Mikey <mike...@gmail.com>:

> This nesting business has been a bugbear for a long time for me. I hope I can convince people here that its time to let go of this idea

Have you written any code or at least read and understood the examples
on fullOO.info? Context CAN be nested I've written several examples of
that and it's in the heart of DCI. DCI implements OO as OO was
originally defined a system consisting of a network of connected
systems. Each system is represented by a context, so by definition
they can be nested. Saying otherwise is like saying an object can can
only have members of primitive (non object) types which is of course
not true

-Rune

[Mikey B]

A system(/subsystem) is represented by a facade controller. A context represents a single system operation. OO definition is still upheld.

The responsibility of a facade controller is to ease/simplify interfacing a group of objects. The same as a subsystem.

The responsibility of a context(and UseCaseController) is to set up role bindings and manage the control flow of a usecase/operation.

Mike Brown.

> -Rune

>
> --
> You received this message because you are subscribed to the Google Groups "object-composition" group.

> To post to this group, send email to object-co...@googlegroups.com.
> To unsubscribe from this group, send email to object-composit...@googlegroups.com.

[James O Coplien]

UseCaseController (http://www.cs.sjsu.edu/~pearce/modules/courses/cs251a/reading/Aguiar_al_2001_ART_Use_Case_Controller.pdf) has almost nothing to do with DCI.

The pattern encapsulates the objects of a use case. Those objects variably use different interface components: different views and controllers. As far as I can see, the pattern is a very minor tweak on MVC — not DCI.

The control in UseCaseController is usually distributed across a number of functions global to the Use Case class. The normal strategy is exactly the opposite of DCI: that "control is placed separately from both interface and entity objects". The Use Case is described as a set of procedural steps from which actor association has been dissociated:

public class PlaceOrderUseCase extends UseCaseController {

   …

   public void start() { displayForm(); }

   public void finish() { … }

   public void displayForm() { … }

   public void setCustomerInfo(String name, String address) { … }

   public void newItem() { … }

   public void saveItem(String item) { … }

   public void deleteItem() { … }

   public void setPaymentInfo(String paymentType) { … }

   public void submitOrder() { … }

   public void cancelOrder() { … }

}

I see absolutely no notion of roles here, let alone role binding.

On Jun 28, 2012, at 10:20 , Mikey B wrote:

A system(/subsystem) is represented by a facade controller. A context represents a single system operation. OO definition is still upheld.

The responsibility of a facade controller is to ease/simplify interfacing a group of objects. The same as a subsystem.

What is a "facade controller"? The pattern mentions view facades and model facades.

The responsibility of a context(and UseCaseController) is to set up role bindings and manage the control flow of a usecase/operation.

No.

I see no roles or role bindings in UseCaseController.

A Context does not manage control flow of a use case. The role methods do.

[rune funch]

Den 28/06/2012 kl. 10.20 skrev Mikey B <mike...@gmail.com>:
So the answer is no? You didn't write code nor investigate the Examples?
A context (which is an object) represents the (execution) of a system
operation. The life time of that object is the same as the time it
takes to complete the operation. The type of the context object might
be used for contexts that execute different system operations (it
might have more 'execute' methods)

[Mikey B]

Hi James,

On 28 June 2012 09:43, James O Coplien <jcop...@gmail.com> wrote:

UseCaseController (http://www.cs.sjsu.edu/~pearce/modules/courses/cs251a/reading/Aguiar_al_2001_ART_Use_Case_Controller.pdf) has almost nothing to do with DCI.

The pattern encapsulates the objects of a use case. Those objects variably use different interface components: different views and controllers. As far as I can see, the pattern is a very minor tweak on MVC — not DCI.

"The Use-Case Controller pattern deals with the problem of mapping

use case specifications to an implementation"

"... Use case maps are another alternative that combines behaviour and structure

in one view and shows the allocation of scenario responsibilities to system components"

"When a use case is started, one instance of the corresponding use-case controller is created to control the flow of the interactions involved."

The control in UseCaseController is usually distributed across a number of functions global to the Use Case class. The normal strategy is exactly the opposite of DCI: that "control is placed separately from both interface and entity objects". The Use Case is described as a set of procedural steps from which actor association has been dissociated:

public class PlaceOrderUseCase extends UseCaseController {

   …

   public void start() { displayForm(); }

   public void finish() { … }

   public void displayForm() { … }

   public void setCustomerInfo(String name, String address) { … }

   public void newItem() { … }

   public void saveItem(String item) { … }

   public void deleteItem() { … }

   public void setPaymentInfo(String paymentType) { … }

   public void submitOrder() { … }

   public void cancelOrder() { … }

}

Above the code is; "The following guidelines are suggested to implement this pattern."

"behaviour must then be distributed to the interacting objects."

"Different strategies can be used to allocate the functionality to entity

objects, interface objects and control objects [7][8]. The strategy to

choose must be decided from application to application. In most

cases, the balanced strategy, where control is placed separately from

both interface and entity objects, is the one that reaches higher 

locality in changes of the functionality."

 

I see absolutely no notion of roles here, let alone role binding.

On Jun 28, 2012, at 10:20 , Mikey B wrote:

A system(/subsystem) is represented by a facade controller. A context represents a single system operation. OO definition is still upheld.

The responsibility of a facade controller is to ease/simplify interfacing a group of objects. The same as a subsystem.

What is a "facade controller"? The pattern mentions view facades and model facades.

"The Use-Case Controller pattern defines five types of participants: UseCaseController, View, Model, Extension and Inclusion."

"All participating classes can be divided at least in two groups: a model,

aggregating all entity objects; and views, which aggregate interface

objects"

Views and Models are considered categories of types of "facades". view facades and model facades are interfaces to Entity objects and Interface Objects, and only exist for the lifetime of the use-case.

 

The responsibility of a context(and UseCaseController) is to set up role bindings and manage the control flow of a usecase/operation.

No. 

I see no roles or role bindings in UseCaseController.

A Context does not manage control flow of a use case. The role methods do.

"The Use-Case Controller pattern provides the following benefits:

• Localization of business rules and policies.

• Easy replacement of user interfaces and system components. 

• Visibility of the originating use case model in the implementation code."

 

All of the quotes above are from the document in your reply. Here is an updated version: http://paginas.fe.up.pt/~aaguiar/as2003-2004/UseCaseCtrl-EuroPLoP2001.pdf

Mike Brown

[Mikey B]

Hi Rune,

On 28 June 2012 13:30, rune funch <funchs...@gmail.com> wrote:

Den 28/06/2012 kl. 10.20 skrev Mikey B <mike...@gmail.com>:
So the answer is no? You didn't write code nor investigate the Examples?
A context (which is an object) represents the (execution) of a system
operation. The life time of that object is the same as the time it
takes to complete the operation.

Agreed, But the context will never represent a Domain Object. Domain Objects play roles within a Context. 

 

The type of the context object might
be used for contexts that execute different system operations (it
might have more 'execute' methods)

Quote from Artima:

"Nested Contexts

One can imagine building rich Context objects that define whole subgraphs of self-contained role relationships: relationships so stable that they constitute a kind of domain in their own right. If these Context objects have a small number of public methods they can behave like domain objects."

Context Nesting hinges on this definition which I disagree with. It is an exception, not the rule, to have more than one "execute" methods. A context represents one (execution) of a system operation. Domain Objects are always represented by a class, which in turn calls the Use-Case.

The UseCaseController document in this thread discusses inclusions (another use-case is called), extensions (hooks are provided by the use-case), and generalisations (inheritance).

Mike Brown

[James O Coplien]

On Jun 29, 2012, at 12:43 , Mikey B wrote:

Hi James,

On 28 June 2012 09:43, James O Coplien <jcop...@gmail.com> wrote:

UseCaseController (http://www.cs.sjsu.edu/~pearce/modules/courses/cs251a/reading/Aguiar_al_2001_ART_Use_Case_Controller.pdf) has almost nothing to do with DCI.

The pattern encapsulates the objects of a use case. Those objects variably use different interface components: different views and controllers. As far as I can see, the pattern is a very minor tweak on MVC — not DCI.

"The Use-Case Controller pattern deals with the problem of mapping

use case specifications to an implementation"

"... Use case maps are another alternative that combines behaviour and structure

in one view and shows the allocation of scenario responsibilities to system components"

"When a use case is started, one instance of the corresponding use-case controller is created to control the flow of the interactions involved."

Yes, so what? Patterns are about form. If you look at the form described by the pattern, the Use Case is one big, undifferentiated lump. There is no structure inside of it. (DCI is about the structure *inside* the use case). The form of the pattern is about its connection to the MVC constituent parts. Yes: there are use cases in there, but they don't figure in any serious way in the overall form of the pattern.

The control in UseCaseController is usually distributed across a number of functions global to the Use Case class. The normal strategy is exactly the opposite of DCI: that "control is placed separately from both interface and entity objects". The Use Case is described as a set of procedural steps from which actor association has been dissociated:

public class PlaceOrderUseCase extends UseCaseController {

   …

   public void start() { displayForm(); }

   public void finish() { … }

   public void displayForm() { … }

   public void setCustomerInfo(String name, String address) { … }

   public void newItem() { … }

   public void saveItem(String item) { … }

   public void deleteItem() { … }

   public void setPaymentInfo(String paymentType) { … }

   public void submitOrder() { … }

   public void cancelOrder() { … }

}

Above the code is; "The following guidelines are suggested to implement this pattern."

"behaviour must then be distributed to the interacting objects."

Right: through the classes that implement them. There is no discussion of roles or anything like it.

"Different strategies can be used to allocate the functionality to entity

objects, interface objects and control objects [7][8]. The strategy to

choose must be decided from application to application. In most

cases, the balanced strategy, where control is placed separately from

both interface and entity objects, is the one that reaches higher 

locality in changes of the functionality."

Read: "In most cases", functionality goes into domain classes.

[James O Coplien]

On Jun 29, 2012, at 12:55 , Mikey B wrote:

But the context will never represent a Domain Object

Sure it does, all the time (for some strange definition of "domain object" — I'm not sure what you mean). A SavingsAccount can, for example, be represented as a Context: a collection of scenarios. Can't its instance be a domain object that in fact can play the role of, say, a SourceAccount, in another Context like MoneyTransfer?

[James O Coplien]

On Jun 29, 2012, at 12:55 , Mikey B wrote:

The UseCaseController document in this thread discusses inclusions (another use-case is called), extensions (hooks are provided by the use-case), and generalisations (inheritance).

Both DCI and UseCaseController chain use cases. That both a cat and a horse have four legs doesn't make a cat a horse.

[rune funch]

Den 29/06/2012 kl. 12.55 skrev Mikey B <mike...@gmail.com>:

> context will never represent a Domain Object

To be able to even discus that we would have to agree on a definition
of "Domain object" or are we talking a data object?

my definition is:
either a simple type or a collection of simple types.
The domain object is responsible for ensuring it's own invariants and
have no behaviour aside from this

Where 'simple type' is defined a primitive for the chosen platform. Ie
usually numbers, strings and booleans.

If that's the definition the I surely agree that by definition a
context can't represent such an object and that such an object would
by definition always be represented by data.

Accepting that definition you will see nested contexts in a lot more
places than you might expect because then you will see a context
anywhere two objects interact and you will end up with a system that
is the perfect realisation of Kay's recursive definition of OO systems

[Mikey B]

Hi James and Rune,

Ive put your replies together;

Domain object is the term used in the Artima article, and is in the quote in the previous message. I believe it means Data Object.

No, I do not believe a SavingsAccount is a Context. 

On 29 June 2012 12:40, rune funch <funchs...@gmail.com> wrote:

Den 29/06/2012 kl. 12.55 skrev Mikey B <mike...@gmail.com>:

> context will never represent a Domain Object

To be able to even discus that we would have to agree on a definition
of "Domain object" or are we talking a data object?

my definition is:
either a simple type or a collection of simple types.
The domain object is responsible for ensuring it's own invariants and
have no behaviour aside from this

Where 'simple type' is defined a primitive for the chosen platform. Ie
usually numbers, strings and booleans.

If that's the definition the I surely agree that by definition a
context can't represent such an object and that such an object would
by definition always be represented by data.

The underline reason for this thread is to point out that there is value to be had from GRASP and the UseCaseController Pattern.

The term 'Data Object' maybe too vague;

The UseCaseController Pattern describes 3 categories of Objects that can interact in a Use Case. Beside them is the Use Case stereotype name.

Interface Objects - «boundary» - Communication with Actors

Entity Objects -  «entity» - Persistent Data

Control Objects - «control»

These are all defined as classes. They are able to play roles within a use-case. There are only three categories of roles in a use-case; Model Role, View Role and Controller Role.

I suspect a Control Object represents a System / Subsystem in your design. 

 

Accepting that definition you will see nested contexts in a lot more
places than you might expect because then you will see a context
anywhere two objects interact and you will end up with a system that
is the perfect realisation of Kay's recursive definition of OO systems

The devil is in the detail, and I can only reference the definition of a Nested Context as quoted from Artima.

If a Control Object represents a subsystem, and a Nested Context represents a "subgraph", It should be clear that in order for Nesting to be possible, The Context object is taking on responsibilities of the Control Object.

The whole point of DCI is clearer and understandable code.

Having multiple Use-Cases in one Context produces code smells; My code begins to differ from its design, producing a barrier to reviewers. It stops (or inheritance has been substituted by "multiple use-case contexts") the possibility of Context Inheritance which represents a Use-Case Generalisation. 

Another quote from Artima, "The Controller creates Views and coordinates Views and Models".

If the Context is taking on the responsibilities of the Control Object. There is an issue here. How do you create a View? Who looks after its address/pointer? A context only lives until the end of its execution. A context should not take on the responsibilities of a Control Object. It therefore can not play a "Controller Role" (or "Model" or "View" role). It therefore can not be a Role Player.

The definition(by the artima article) of a "Nested Context" is that a Context can be a Role Player. 

Lets use the terms that use-case's use, and model them accurately in our code. Naming of a Context becomes trivial, its just the name of the Use-Case.

(Use-Case) Generalisations - via Inheritance.

(Use-Case) Extensions and (Use-Case) Inclusions - via hooks.

Thankyou for your time,

Mike Brown

[James O Coplien]

On Jun 30, 2012, at 11:52 , Mikey B wrote:

No, I do not believe a SavingsAccount is a Context.

It certainly is. The common misperception, promulgated by undergraduate CS professors everywhere, that SavingsAccount is a class that encapsulates a data item called a "balance," is at odds with most real banking systems. A SavingsAccount balance is a computation over a series of transaction log items — a use case. Doing a Deposit is a database transaction with an elaborate set of steps — a different trigger function on the account.

Context-ness is in the eyes of the beholder. If you are a simple CS Professor, then it's not. If you program for a living, then it is.

[Mikey B]

Hi James,

On 30 June 2012 11:30, James O Coplien <jcop...@gmail.com> wrote:

On Jun 30, 2012, at 11:52 , Mikey B wrote:

No, I do not believe a SavingsAccount is a Context.

It certainly is. The common misperception, promulgated by undergraduate CS professors everywhere, that SavingsAccount is a class that encapsulates a data item called a "balance," is at odds with most real banking systems. A SavingsAccount balance is a computation over a series of transaction log items — a use case. Doing a Deposit is a database transaction with an elaborate set of steps — a different trigger function on the account.

A SavingsAccount is not a Context, The reasons why are listed in the previous post.

A SavingsAccount is a Control Object, created by a class.

For your example of a balance, The SavingsAccount would execute the context (CalculateBalance), 

class SavingsAccount

  balance: () ->

    tmp = new CalculateBalance(..roleplayers..)

    Result = tmp.execute(...params...)

    delete tmp

    return Result

context CalculateBalance

   ... Contents of CalculateBalance use-case.

Your mixing the responsibilities of a Controller with a Context.

Mike Brown.

 

Context-ness is in the eyes of the beholder. If you are a simple CS Professor, then it's not. If you program for a living, then it is.

--

[James O Coplien]

On Jun 30, 2012, at 1:22 , Mikey B wrote:

A SavingsAccount is not a Context, The reasons why are listed in the previous post.

I found your reasons ill-grounded.

A SavingsAccount is a Control Object, created by a class.

Huh?

There is no notion of Model View Controller here so I'm not sure why you're bringing up Control Object.

Classes do not create objects.

For your example of a balance, The SavingsAccount would execute the context (CalculateBalance), 

class SavingsAccount

  balance: () ->

    tmp = new CalculateBalance(..roleplayers..)

    Result = tmp.execute(...params...)

    delete tmp

    return Result

context CalculateBalance

   ... Contents of CalculateBalance use-case.

All that does is to add another level of function nesting. There is no advantage for encapsulating change. There is no advantage to this abstraction layer. It is merely a blind, pro-forma walk along the path of old-style object-orientation — off a cliff.

What are the roles of CalculateBalance? And what objects play those roles? List them. Sounds like a SavingsAccount to me.

Your mixing the responsibilities of a Controller with a Context.

First, I'm not. There are no Contexts in the UseCasePattern.

Second, the job of a Controller is to create an coordinate Views and, together with the View, handle selection. None of my description of a SavingsAccount had anything to do with selection of MVC.

Third, even if I were, why shouldn't I? These are two different spaces.

[Mikey B]

Hi James,

On 30 June 2012 13:09, James O Coplien <jcop...@gmail.com> wrote:

On Jun 30, 2012, at 1:22 , Mikey B wrote:

A SavingsAccount is not a Context, The reasons why are listed in the previous post.

I found your reasons ill-grounded.

A SavingsAccount is a Control Object, created by a class.

Huh?

There is no notion of Model View Controller here so I'm not sure why you're bringing up Control Object.

A "Control" object is a Use-Case Stereotype, classifying the object.

 

Classes do not create objects.

For your example of a balance, The SavingsAccount would execute the context (CalculateBalance), 

class SavingsAccount

  balance: () ->

    tmp = new CalculateBalance(..roleplayers..)

    Result = tmp.execute(...params...)

    delete tmp

    return Result

context CalculateBalance

   ... Contents of CalculateBalance use-case.

All that does is to add another level of function nesting. There is no advantage for encapsulating change. There is no advantage to this abstraction layer. It is merely a blind, pro-forma walk along the path of old-style object-orientation — off a cliff.

The advantage is that the code now mirrors my design, System operations are not entangled together, both promoting clarity.

The only relevance with MVC is understanding that the (use-case stereotype)Control object is the keeper of the Interface objects(Objects which communicate with an Actor). (MVC)"Controller" is a role, and can not have state, The (Use-case stereotype)Control object holds this state.

What are the roles of CalculateBalance? And what objects play those roles? List them. Sounds like a SavingsAccount to me.

Your mixing the responsibilities of a Controller with a Context.

First, I'm not. There are no Contexts in the UseCasePattern.

Second, the job of a Controller is to create an coordinate Views and, together with the View, handle selection. None of my description of a SavingsAccount had anything to do with selection of MVC. 

Third, even if I were, why shouldn't I? These are two different spaces.

You said in the previous section of this post that im just "adding another level". This is the layer that you are combining into your Contexts, Combining the responsibilities of your (use-case stereotype)Control object with your Context.

While a SavingsAccount does not require Interface objects and "View" roles, separation of the responsibilities is always worth upholding.

A (Use-Case Stereotype)Control object represents the System(/subsystem). A Context represents a system operation. They should not be mixed.

Mike Brown

[rune funch]

> The advantage is that the code now mirrors my design, System operations are not entangled together, both promoting clarity

it's not the goal to mirror the design but to mirror the users mental
model of the _problem_ domain which your design does not. Therefor
it's implicitly the goal not to mirror the design because the design
it self fails to meet the stated goal of mirroring the users mental
model

[rune funch]

Den 30/06/2012 kl. 11.52 skrev Mikey B <mike...@gmail.com>:

> Domain object is the term used in the Artima article

The term is however not defined in said article so for us to be able
to debate we'd still need to agree on a definition if we do not
already agree on the one I proposed

[James O Coplien]

On Jun 30, 2012, at 2:54 , Mikey B wrote:

A "Control" object is a Use-Case Stereotype, classifying the object.

Classes do not create objects.

For your example of a balance, The SavingsAccount would execute the context (CalculateBalance), 

class SavingsAccount

  balance: () ->

    tmp = new CalculateBalance(..roleplayers..)

    Result = tmp.execute(...params...)

    delete tmp

    return Result

context CalculateBalance

   ... Contents of CalculateBalance use-case.

All that does is to add another level of function nesting. There is no advantage for encapsulating change. There is no advantage to this abstraction layer. It is merely a blind, pro-forma walk along the path of old-style object-orientation — off a cliff.

The advantage is that the code now mirrors my design, System operations are not entangled together, both promoting clarity.

You would have the same by removing one level of calling. Furthermore, you'd have all the stuff for one use case in one place. You risk splitting it across SavingsAccounts and a Context.

The only relevance with MVC is understanding that the (use-case stereotype)Control object is the keeper of the Interface objects(Objects which communicate with an Actor). (MVC)"Controller" is a role, and can not have state, The (Use-case stereotype)Control object holds this state.

What are the roles of CalculateBalance? And what objects play those roles? List them. Sounds like a SavingsAccount to me.

Your mixing the responsibilities of a Controller with a Context.

First, I'm not. There are no Contexts in the UseCasePattern.

Second, the job of a Controller is to create an coordinate Views and, together with the View, handle selection. None of my description of a SavingsAccount had anything to do with selection of MVC. 

Third, even if I were, why shouldn't I? These are two different spaces.

You said in the previous section of this post that im just "adding another level". This is the layer that you are combining into your Contexts, Combining the responsibilities of your (use-case stereotype)Control object with your Context.

No, your example clarifies nothing about any interaction with a View or other MVC entity. It is just a superfluous instantiation, assignment, invocation and deallocation that add no clarity to the semantics. They obfuscate functionality by burying it in unnecessary boilerplate. I can't see that the code accomplishes no constructive separation of concerns.

Can you point concretely to the code and tell me what concerns you separate between the class and the Context? It seems that instead of separating them you have made them hopelessly coupled.

 

While a SavingsAccount does not require Interface objects and "View" roles, separation of the responsibilities is always worth upholding.

Why didn't you mention the file system, the keyboard, the hardware diagnostics and the RS232 driver? You're dragging stuff into this that is way out of scope and then patting yourself on the back for separating it back out again.

A (Use-Case Stereotype)Control object represents the System(/subsystem). A Context represents a system operation. They should not be mixed.

And why not?

They need not be the same but I see no reason that they could not be the same.

Mike Brown

[Mikey B]

Hi rune,

It maybe the goal of DCI to mirror users mental model, but it is an advantage if I provide a model that mirrors my use-cases.

Use-cases speak of Generalisations, Inclusions, Extensions, Control Objects, Entity Objects, Interface Objects etc. This means my model should as-well.

[Mikey B]

Hi Rune,

Im happy to debate; - Your definition is close, but I feel it should note that there exists two other types of objects. The terms Control, Entity, and Interface are part of the UML definitions and are Jacobsons terms.

[James O Coplien]

On Jun 30, 2012, at 6:46 , Mikey B wrote:

Use-cases speak of Generalisations, Inclusions, Extensions, Control Objects, Entity Objects, Interface Objects etc. This means my model should as-well.

No. No. Those are not part of the end user mental model. They are administrative formalisms designed to force-fit mental models of procedural behavior into an class-based subtyping model. It kind of goes against everything that DCI stands for.

These original provisions of use cases, from Ivar Jacobsson, tried to create a formal object model for scenarios. In the end no one really understood it (except maybe the students of Jacobsson who invented it) and I haven't seen anyone use it. Almost everyone who uses use cases uses either the Cockburn variant or the Wirfs-Brock variant.

This stuff with generalizations, inclusions, extensions and so forth just doesn't work, and I've never heard it brought up in any discussion of DCI — until now.

The omission is with good reason.

[Mikey B]

Hi james,

On 30 June 2012 18:03, James O Coplien <jcop...@gmail.com> wrote:

On Jun 30, 2012, at 6:46 , Mikey B wrote:

Use-cases speak of Generalisations, Inclusions, Extensions, Control Objects, Entity Objects, Interface Objects etc. This means my model should as-well.

No.

If you would like to debate with Me and Rune on the definition of Domain object, then by all means. You did write after all.

 

No. Those are not part of the end user mental model. They are administrative formalisms designed to force-fit mental models of procedural behavior into an class-based subtyping model. It kind of goes against everything that DCI stands for.

These original provisions of use cases, from Ivar Jacobsson, tried to create a formal object model for scenarios. In the end no one really understood it (except maybe the students of Jacobsson who invented it) and I haven't seen anyone use it. Almost everyone who uses use cases uses either the Cockburn variant or the Wirfs-Brock variant.

This stuff with generalizations, inclusions, extensions and so forth just doesn't work, and I've never heard it brought up in any discussion of DCI — until now.

That's not true, Im certainly not the first to bring up the possibility of inheritance with Contexts.

If your personal experience of generalizations, inclusions, and extensions is poor then so be it. You are free to code in what ever way you want, but you are teaching people. These things are discussed in Use-Case books, People learn and use these things, you can not assume they wont from your personal preference.

 

The omission is with good reason.

--

[James O Coplien]

On Jun 30, 2012, at 7:35 , Mikey B wrote:

Hi james,

On 30 June 2012 18:03, James O Coplien <jcop...@gmail.com> wrote:

On Jun 30, 2012, at 6:46 , Mikey B wrote:

Use-cases speak of Generalisations, Inclusions, Extensions, Control Objects, Entity Objects, Interface Objects etc. This means my model should as-well.

No.

If you would like to debate with Me and Rune on the definition of Domain object, then by all means. You did write after all.

I'm with Rune here. Can you clarify why you disagree with him?

No. Those are not part of the end user mental model. They are administrative formalisms designed to force-fit mental models of procedural behavior into an class-based subtyping model. It kind of goes against everything that DCI stands for.

These original provisions of use cases, from Ivar Jacobsson, tried to create a formal object model for scenarios. In the end no one really understood it (except maybe the students of Jacobsson who invented it) and I haven't seen anyone use it. Almost everyone who uses use cases uses either the Cockburn variant or the Wirfs-Brock variant.

This stuff with generalizations, inclusions, extensions and so forth just doesn't work, and I've never heard it brought up in any discussion of DCI — until now.

That's not true, Im certainly not the first to bring up the possibility of inheritance with Contexts.

Inheritance of Contexts (probably a bad idea) is neither sufficient nor necessary for any of the Jacobsson use case relationships.

None of the Jacobsson use case relationships are either sufficient nor necessary to use case inheritance.

If your personal experience of generalizations, inclusions, and extensions is poor then so be it. You are free to code in what ever way you want, but you are teaching people. These things are discussed in Use-Case books, People learn and use these things, you can not assume they wont from your personal preference.

Show me one use case book other than Jacobsson that discusses them. I can show you two that don't (Wirfs-Brock's and Alistair's).

I work with dozens of organizations and can tell you that I have yet to see anyone using the Jacobsson variant. One organization claimed to, but they were so lost that they actually weren't.

My wife Gertrud is an expert on use cases and has worked in that area for more than ten years, and she is of the same mind.

Again: The omission is with good reason.

[Mikey B]

On 30 June 2012 18:41, James O Coplien <jcop...@gmail.com> wrote:

On Jun 30, 2012, at 7:35 , Mikey B wrote:

Hi james,

On 30 June 2012 18:03, James O Coplien <jcop...@gmail.com> wrote:

On Jun 30, 2012, at 6:46 , Mikey B wrote:

Use-cases speak of Generalisations, Inclusions, Extensions, Control Objects, Entity Objects, Interface Objects etc. This means my model should as-well.

No.

If you would like to debate with Me and Rune on the definition of Domain object, then by all means. You did write after all.

I'm with Rune here. Can you clarify why you disagree with him?

 

No. Those are not part of the end user mental model. They are administrative formalisms designed to force-fit mental models of procedural behavior into an class-based subtyping model. It kind of goes against everything that DCI stands for.

These original provisions of use cases, from Ivar Jacobsson, tried to create a formal object model for scenarios. In the end no one really understood it (except maybe the students of Jacobsson who invented it) and I haven't seen anyone use it. Almost everyone who uses use cases uses either the Cockburn variant or the Wirfs-Brock variant.

This stuff with generalizations, inclusions, extensions and so forth just doesn't work, and I've never heard it brought up in any discussion of DCI — until now.

That's not true, Im certainly not the first to bring up the possibility of inheritance with Contexts.

Inheritance of Contexts (probably a bad idea) is neither sufficient nor necessary for any of the Jacobsson use case relationships.

None of the Jacobsson use case relationships are either sufficient nor necessary to use case inheritance.

You do know that inheritance represents the "Generalisation Relationship" right? Which, yes, is one of the relationships use-cases can have.

 

If your personal experience of generalizations, inclusions, and extensions is poor then so be it. You are free to code in what ever way you want, but you are teaching people. These things are discussed in Use-Case books, People learn and use these things, you can not assume they wont from your personal preference.

Show me one use case book other than Jacobsson that discusses them. I can show you two that don't (Wirfs-Brock's and Alistair's).

Writing Effective Use Cases - Alistair Cockburn, (Page 233-241) has a whole section on Includes, Extends, and Generalisations.

I suspect you can't even have the Extends relationship when placing Use-Cases together in one Context. The hook bindings must be set up by the Control object.

 

I work with dozens of organizations and can tell you that I have yet to see anyone using the Jacobsson variant. One organization claimed to, but they were so lost that they actually weren't.

My wife Gertrud is an expert on use cases and has worked in that area for more than ten years, and she is of the same mind.

Again: The omission is with good reason.

Your experience of never using "Extends" or "Generalisation" relationships between Use-Cases does not mean no-one uses them.

[James O Coplien]

On Jun 30, 2012, at 8:50 , Mikey B wrote:

You do know that inheritance represents the "Generalisation Relationship" right? Which, yes, is one of the relationships use-cases can have.

No, again. Inheritance is neither sufficient nor necessary for generalization. Generalization is neither sufficient nor necessary for inheritance.

See Meyer ("Object-Oriented Software Construction," Second Edition 1997), Sec. 24.5, p 822, where he lists 10 different semantics of inheritance: Subtyping, view, restriction (the flip side of generalization), extension, functional variation, type variation, reification, structure, implementation, and facility. That one uses inheritance does not imply generalization.

On the other hand consider the generalized C++ is_less_than function:

template <class T>

void *is_less_than(const T&a, const T&b) {

       return a < b;

}

Thus one expresses generalization of function in C++. Note that there is no inheritance.

Generalization can also be achieved through reflection. DCI generalizes use cases through a weak form of reflection based on deferred binding of objects to roles. There is no inheritance there.

Generalization can also be implemented through delegation, with the delegate representing the specialization. Jim Gay writes elegantly about the use of delegation in his Clean Ruby book.

And here is an interesting use of inheritance in C++:

template <class T>

class List {

public:

void push_tail(const T& element);

void push_head(const T& element);

void *has(const T& element);

void remove(const T& element);

. . . .

};

template <class T>

class Set: private List<T> {

public:

void add(const T&element) {

if (!has(element)) push_tail(element);

}

using List<T>::has;

using List<T>::remove;

};

Would you deduce, on the basis of your claim above, that Lists are a generalization of Sets?

Mike, I think you are missing a much larger context here and I'm not sure how to get it to you through Email. Most of these concepts are familiar to CS undergraduates. Perhaps you're an autodidact programmer who can code and who has picked up some concepts but who never had the grounding in the underlying theory. I don't know. But I am concerned that many of the stake-in-the-ground claims you make here can't be substantiated in the basic OO canon. And I don't think we can do a full undergraduate course in Computer Science through this group.

I have been trying to help you in a Socratic way, posing clarifying questions, but you seem to avoid answering them rather than rising to the challenge. Let's start with these:

On Jun 30, 2012, at 7:41 , James O Coplien wrote:

If you would like to debate with Me and Rune on the definition of Domain object, then by all means. You did write after all.

I'm with Rune here. Can you clarify why you disagree with him?

On Jun 30, 2012, at 5:37 , James O Coplien wrote:

Can you point concretely to the code and tell me what concerns you separate between the class and the Context? It seems that instead of separating them you have made them hopelessly coupled.

On Jun 30, 2012, at 5:37 , James O Coplien wrote:

While a SavingsAccount does not require Interface objects and "View" roles, separation of the responsibilities is always worth upholding.

Why didn't you mention the file system, the keyboard, the hardware diagnostics and the RS232 driver? You're dragging stuff into this that is way out of scope and then patting yourself on the back for separating it back out again.

On Jun 30, 2012, at 5:37 , James O Coplien wrote:

A (Use-Case Stereotype)Control object represents the System(/subsystem). A Context represents a system operation. They should not be mixed.

And why not?

On Jun 30, 2012, at 2:09 , James O Coplien wrote:

What are the roles of CalculateBalance? And what objects play those roles? List them. Sounds like a SavingsAccount to me.

If you would like a "discussion" about definitions or anything else, it would help me if you did the courtesy of engaging in dialog instead of taking the conversation in the direction of some new point on every exchange. You have not addressed yourself to any of the following questions but have, at each turn, made another stake-in-the-ground claim of truth — each one of which has been easy to deconstruct.

I appreciate that you used at least one code example and that you are starting to cite references. But I find most of the argumentation to be based not in these citations but in the unsubstantiated claims — the citations tend to substantiate issues peripheral to the discussion. Let me suggest that you try to either back your core arguments from the literature or at least develop a strong argument for your points. Just saying that "inheritance represents the Generalization Relationship" isn't going to do it for me. Please use crisp words ("system" and "subsystem" can mean anything) or use some other rhetorical device to precisely contextualize your expression.

And — focus. Stick with the thread and please try to thoughtfully respond. There are a lot of people here taking a lot of their time to help you understand. Please honor their contribution and effort by thoughtfully engaging in the dialog. Too often it feels like I'm in a parallel monologue, in spite of best efforts to precisely address your points.

[rune funch]

Den 30/06/2012 kl. 19.04 skrev Mikey B <mike...@gmail.com>:

> Your definition is close, but I feel it should note that there exists two other types of objects.

There's a plethora of other types of objects but I don't see how they
are relevant to the definition of a specific type of objects

[rune funch]

Den 30/06/2012 kl. 18.46 skrev Mikey B <mike...@gmail.com>:

> It maybe the goal of DCI to mirror users mental model, but it is an advantage if I provide a model that mirrors my use-cases.

If your USE cases do not mirror your users mental model you have a
sever requirement specification issue. Use cases belong in the problem
domain. They are not a design tool but input to the design phase.
Making the common error of mixing the solution domain and problem
domain when writing use cases will constrain the design process to a
point where it can impact the quality of the product let alone lead to
expensive errors and rework when the assumption the solution was based
on fall a part.
I do workshops on this for my customers so it could easily turn into a
use case discussion instead but that's not what this list is for so
let's stick with the DCI aspects. DCI tries to mirror the users mental
model in the code and an underlying assumption is that the
documentation of the users mental model (eg requirements and more) is
present and that this information is carried through from requirements
to code and not altered nor permutated in the design phase.

[rune funch]

Den 30/06/2012 kl. 14.55 skrev Mikey B <mike...@gmail.com>:

> A Context represents a system operation

More than that it represents the network of objects and how they
interact to perform a system operation. And as such it represents a
system and performs the operation for said system

[rune funch]

Den 30/06/2012 kl. 11.52 skrev Mikey B <mike...@gmail.com>:

> No, I do not believe a SavingsAccount is a Context.

Then please look at the Marvin version of the MoneyTransfer example,
specifically look at the Account class and tell me what principles
that class violates so that objects of that type do not represent a
network of connected objects (ledger entries) and the interactions
they are part of so that they can perform a system operation
(withdrawal, deposit or balance).

-Rune

[david Rozenberg]

I think that we need to stop using the MoneyTransfer example as the means of illustrating DCI principles. I am personally not comfortable with it from the very first time it was brought to life in the posting at www.artima.com. And the reason is now obvious for me. It does not fit into my mental model for this specific interaction.

My mental model is to some extent service oriented (as for most people). Yes, it uses the context to select a role player (i.e. a bank for money transfer), but as soon as the role player is selected, why should I really care how the service is implemented? I believe it is the common way most people deal with their everyday needs. So, why do we need a different approach? Why do we need to sneak into how the service is implemented by the service provider we choose?

I think that all debates and strong words in them over the past couple weeks or so are exactly the result of the differences in what the actual mental model is and what is suggested as the one.

It seems to me that we may need to find a better example to make sure that it fits not in what we claim is the user mental model, but what it is for most of people.

Thanks,

---

From: rune funch <funchs...@gmail.com>
To: "object-co...@googlegroups.com" <object-co...@googlegroups.com>
Sent: Sunday, July 1, 2012 2:26 AM
Subject: Re: Advice on consolidating thoughts.

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To post to this group, send email to object-co...@googlegroups.com.

To unsubscribe from this group, send email to object-composition+unsub...@googlegroups.com.

[James O Coplien]

On Jul 1, 2012, at 1:25 , david Rozenberg wrote:

It seems to me that we may need to find a better example to make sure that it fits not in what we claim is the user mental model, but what it is for most of people.

We await your example and its code.

[rune funch]

I'd love to have an even better example but have yet not stumbled upon one.

An application is in general nothing but a promise of performing a service for the user, does that then mean we should only implement services and force the user to think of services?

I think most people they have a model of banking involving accounts and operations in relation to those accounts. I like at least one aspect of the money transfer example which is it's ability to show how to service multiple user mental model. Towards average Joe I can talk about accounts and operations in relation to accounts but since that's just one view on the data I can at the same time, with no additional work talk about ledger entries when I'm dealing with the audit side of the business.

What I've gotten from this and other discussion of examples and especially when talking about nested contexts is a lack of realisation. Going from class oriented to DCI requires two mental leaps each of which are rather challenging. Firstly we need to realise that the earth is a sphere and not a pancake and then realise what that implies on how we have been perceiving everything around us. When learning DCI we at some point have to leap into object oriented from class oriented and once we accept the earth is a sphere we need to realise that everything we thought we knew might have suddenly and inadvertently changed. 

An object is a model and as every model it's an abstraction of the real thing. No model is perfect and the best suited model changes depending upon the context in which we need the model.

In class oriented and DDD we try to create the perfect model and then apply magic on top to match the current situation.

In DCI we start with what does not change depending on the context of usage, namely the data and we model the "real thing" based on the context. So if the use case is auditing the transactions within a bank we model ledger entries where as if the use case is showing the balance we model the account. The data is the same in both but the object we talk about are different objects. A third model upon the same data is used for the trading floor guys. They need to know how much they can invested which is in part determine by the balance of every account in the bank.

Each of these models might serve as a building block for another model and the second leap from object oriented to DCI is realising that each model in a user model does not need to be on the same level of abstraction

-Rune

To unsubscribe from this group, send email to object-composit...@googlegroups.com.

[James O Coplien]

Right. There is no "single right example" for bank accounts. You need to look at it from the perspective of the end user and the psychometric studies or analyses that support the model — not from CS taxonomies.

It is even possible that the model for transfer will differ when interacting with a live teller than with an ATM. I don't know — I haven't done the research. But such research is important, as HCI people know — and, unfortunately, most of us OO people don't know.

[Mikey B]

Hi david, rune, james and anyone else interested.

I think the bank account example is good enough to illustrate my point, so lets take the mental model given of the interactions from artima as a common starting point and lets do a small thought exercise;

You, the programmer will seperate the concerns using MVC. This provides you with three types of roles; Model Roles, View Roles, and Controller roles. (and also states how each role is wired to eachother).

Your bank account is represented as a Context; Which type of role can a bank account play? State which you think and why.

--

Model - the object playing a model role requires persistance, it must atleast hold the pointers to other objects with state. A context only exists for the duration of its execution.

Controller - Also requires state, to hold pointers to Views

View - a bank account does not represent communications with actors.

Mike Brown

[rune funch]

Let's start with answering the questions already part of this thread I have posted several questions to you (as have James) one recent one was :

"Then please look at the Marvin version of the MoneyTransfer example,
specifically look at the Account class and tell me what principles
that class violates so that objects of that type do not represent a
network of connected objects (ledger entries) and the interactions
they are part of so that they can perform a system operation
(withdrawal, deposit or balance)."

You've stated that class like the mentioned is an obvious violation of DCI so it should be a small task to ask of you and it will help me understand your line of thinking. If you can't find any violations you have already answered your own question at which point we can conclude the discussion.

-Rune

2012/7/2 Mikey B <mike...@gmail.com>

--

[Mikey B]

alright rune, ill post the exercise in another thread and will continue later with answering outstanding questions.

[James O Coplien]

On Jul 2, 2012, at 11:22 , Mikey B wrote:

Your bank account is represented as a Context; Which type of role can a bank account play? State which you think and why.

A Model — it represents the state of the system with respect to the end user's interest.

Model - the object playing a model role requires persistance,

Absolutely not. It only needs to report a value on demand. It can make it up. It can calculate it. It can go to other objects to get the information. Or (and this is the most likely) it goes to another API which has state and interacts with that object to manage the representation of the account state.

it must atleast hold the pointers to other objects with state.

Pointers are a very low-level implementation of name binding. There are other ways to represent bindings: database associations, named references, and a host of others.

A context only exists for the duration of its execution.

But this is tautologically absurd. If we take the simpleton's view that objects mirror nature, and that nature persists forever and that a Windows machine can't run more than a month without re-booting, then your argument suggests that OO is impossible.

--

Controller - Also requires state, to hold pointers to Views

View - a bank account does not represent communications with actors.

The interactions go in the controller.

[Greg Young]

+1 to killing it. It's ridiculous for people that have actually implemented a banking system. The use case is a long running fsm.

To unsubscribe from this group, send email to object-composit...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/object-composition?hl=en.

--
Le doute n'est pas une condition agréable, mais la certitude est absurde.

[Mikey B]

hi james,

On Jul 2, 2012 10:50 AM, "James O Coplien" <jcop...@gmail.com> wrote:
>
> On Jul 2, 2012, at 11:22 , Mikey B wrote:
>
>> Your bank account is represented as a Context; Which type of role can a bank account play? State which you think and why.
>
> A Model — it represents the state of the system with respect to the end user's interest.
>
>
>> Model - the object playing a model role requires persistance,
>
>
> Absolutely not. It only needs to report a value on demand. It can make it up. It can calculate it. It can go to other objects to get the information. Or (and this is the most likely) it goes to another API which has state and interacts with that object to manage the representation of the account state.
>
>
>> it must atleast hold the pointers to other objects with state.
>
>
>
> Pointers are a very low-level implementation of name binding. There are other ways to represent bindings: database associations, named references, and a host of others.
>
>
>> A context only exists for the duration of its execution.
>
>
> But this is tautologically absurd. If we take the simpleton's view that objects mirror nature, and that nature persists forever and that a Windows machine can't run more than a month without re-booting, then your argument suggests that OO is impossible.

im sorry james, a context only exists for the duration of its execution;

You picked model, if the context can not hold its name bindings, something else does.

The correct answer is 'none', a context can not play any role.

>
>> --
>>
>> Controller - Also requires state, to hold pointers to Views
>>
>> View - a bank account does not represent communications with actors.
>
> The interactions go in the controller.
>

[rune funch]

The use case can't be a fsm, since a use case is in the problem domain and the fsm is in the solution domain :)
Would it be so that the account model actually holds for most users? Most regular users concern them self with something they call an account. The operations I as average Joe can perform in relation to my account are important to me and I associate them to this thing I call an account. That my accountant, the banker or someone else aren't that worried about what I call an account is irrelevant to how I use the system.

That I worry about something I call an account is irrelevant to those concern with internal audits at a bank and their way of using the system is irrelevant to me. Neither are irrelevant to implementation of the system.

If the system can't cater for both it will be incomplete and we would have to have a system for each group of users.

Which simply bring us back to the definition of OO as a network of connected systems.

That the simplistic implementation of an account doesn't meet reality is to me simply an example of the strength of nested contexts. What to some might seem like simple data is in fact an entire system of it's own right. Sure we could extend the implementation of MT so that the Account wouldn't be so simplistic but implement the full context and include all the nitty gritty parts that actually make up the system the account represents, thereby showing the complex system it abstracts upon. Would that help the example in conveying what DCI is? I don't know but if the answer is yes I wouldn't mind to help DCI'ify the code

-Rune

2012/7/2 Greg Young <gregor...@gmail.com>

[rune funch]

2012/7/2 Mikey B <mike...@gmail.com>

sorry james, a context only exists for the duration of its execution;

You picked model, if the context can not hold its name bindings, something else does.

The correct answer is 'none', a context can not play any role.

All objects only exist in the duration of the execution (of the program) are you trying to suggest that programming is impossible?

[James O Coplien]

On Jul 2, 2012, at 11:55 , Greg Young wrote:

+1 to killing it. It's ridiculous for people that have actually implemented a banking system.

I don't think you can speak for all of them, and I can connect you with some who would disagree.

That said, we badly need a better example. The way you vote for killing an old example is by creating a new one.

The use case is a long running fsm.

As I recall, there are quite a few other computer programs that are also reducible to FSMs...

[James O Coplien]

On Jul 2, 2012, at 12:01 , Mikey B wrote:

The correct answer is 'none', a context can not play any role.

We have concrete counter-examples, and you have yet to give any evidence of having dutifully considered them.

I would usually say, "I disagree" but in this case can stand my ground and say "You are wrong."

I had hoped that you came to learn. I for one will refrain from further interaction with you in this forum. It leads nowhere.

I leave you with your theories.

[Greg Young]

You can connect me with people who view the processing of an account transfer as a single step atomic operation? 

--

You received this message because you are subscribed to the Google Groups "object-composition" group.
To post to this group, send email to object-co...@googlegroups.com.
To unsubscribe from this group, send email to object-composit...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/object-composition?hl=en.

[Mikey B]

hi rune,

some good thoughts; ill try and answer some.

On Jul 2, 2012 11:40 AM, "rune funch" <funchs...@gmail.com> wrote:
>
> The use case can't be a fsm, since a use case is in the problem domain and the fsm is in the solution domain :)

Would calling a context a 'system operation' bring it into the solution domain for you?

> Would it be so that the account model actually holds for most users? Most regular users concern them self with something they call an account. The operations I as average Joe can perform in relation to my account are important to me and I associate them to this thing I call an account. That my accountant, the banker or someone else aren't that worried about what I call an account is irrelevant to how I use the system.

'Joe' (the customer) and the Accountant are Actors (uml 2 definition).

There are objects which play the View role which comunicate to these actors.

These two actors use different systems, systems which share data objects.

> That I worry about something I call an account is irrelevant to those concern with internal audits at a bank and their way of using the system is irrelevant to me. Neither are irrelevant to implementation of the system.
> If the system can't cater for both it will be incomplete and we would have to have a system for each group of users.

why do you feel it would be incomplete if they are seperate?

Take the three systems, ATM, Website, and TellerPOS.

Why would an accountant actor use the atm? or website? and similarly, why would a customer use the POS system? they simply share data objects :)

The view roleplaying objects and controller playing objects would be very different in each system.

[James O Coplien]

I think that equating a DCI system operation with atomicity exhibits a serious misunderstanding of DCI.

[rune funch]

I once again to answer the difficult questions then we can see if any of the below is still worth exploring. I think they stem from the same misconceptions

-Rune

2012/7/2 Mikey B <mike...@gmail.com>

hi rune,

[Greg Young]

I am equating the example to that assumption not dci. 

[James O Coplien]

On Jul 2, 2012, at 1:38 , Greg Young wrote:

I am equating the example to that assumption not dci. 

O.K. Show me the transaction in the code for the example.

[Mikey B]

On Jul 2, 2012 12:27 PM, "rune funch" <funchs...@gmail.com> wrote:
>
> I once again to answer the difficult questions then we can see if any of the below is still worth exploring. I think they stem from the same misconceptions
>

i think your right rune, the biggest one is How long does a context exist for?

The documents say it exists on the stack and exists only for the duration of its execution. I guess only trygver can clarify this question.

Mike Brown

[Greg Young]

There is only a single step modeled in the example whether or not it's transactional misses my point. In a system it's not a single step it's possibly dozens. 

On Monday, July 2, 2012, James O Coplien wrote:

--

You received this message because you are subscribed to the Google Groups "object-composition" group.
To post to this group, send email to object-co...@googlegroups.com.
To unsubscribe from this group, send email to object-composit...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/object-composition?hl=en.

[James O Coplien]

Why is it so hard for people to understand the notion of "end-user mental models"?

That's what we're modeling at the DCI level. The database transactions are hidden behind another abstraction boundary. (Trygve is working on a document that more precisely describes our use of "abstraction boundaries" in the DCI formalism, but you get the idea.)

Any level of database smashing can be implemented in the data classes. You can have transactions to your heart's content there. We could develop those in the example, but it really doesn't clarify DCI to the reader.

I have in fact developed a first cut of a database (data / domain) class whose instance can be used by an Account Context object. I had been holding off developing it further because I have been waiting for what someone (I think it was you) had said they were working on a couple of years ago. If you'd like, we can collaborate. But, remember, this logic is of a secondary concern to a DCI audience.

[david Rozenberg]

I think it is not hard. The hard part is to buy what you call the "end-user mental model". As I indicated in my original message, the money transfer example is correct as the end-user mental model" up to the point when the Context decides which actor of the use case plays which role (role player in DCI terms). After that we need to go to another level and analyze another context and another level use case and so on, until we say stop, we are at the level sufficient for the implementation.

It is exactly as when you need somebody (maybe, yourself) to play a role of a plumber to fix something in your home. You choose the one to do this job using multiple criteria (this is exactly what DCI calls role binding). Do you care which tools the selected individual will use to perform the task? No, you don't. The only your concern is that individual does not destroy your home while doing his job. This is what is called a service. And any role player in any circumstances is providing a service within the specific context.

I just remind that some time ago when this group started we were talking about the fact that the same person performs different roles in different contexts.

Even though it seemed that the money transfer is a good example to illustrate the DCI concepts and approach, it did not serve well this purpose because of the above.

Regards,

---

From: James O Coplien <jcop...@gmail.com>
To: object-co...@googlegroups.com
Sent: Monday, July 2, 2012 7:51 AM

Subject: Re: Advice on consolidating thoughts.

[James O Coplien]

On Jul 2, 2012, at 10:31 , david Rozenberg wrote:

Even though it seemed that the money transfer is a good example to illustrate the DCI concepts and approach, it did not serve well this purpose because of the above.

1. It's had some bumps but it seems to have worked well to lead a lot of people into misunderstanding.

2. Few peoples' misunderstandings of DCI can be traced to the example. In today's case at hand it looked like that, but in fact the issue was deeper.

3. We can do better. We can always do better. If you feel it did not serve its purpose, you get to vote with something that better serves the purpose. I had some disappointments in the Account example, and so I've already worked up a better example: the Dijkstra example. We all await yours.

[rune funch]

Den 02/07/2012 kl. 22.31 skrev david Rozenberg <dr_20...@yahoo.com>:

> As I indicated in my original message, the money transfer example is correct as the end-user mental model" up to the point when the Context decides which actor of the use case plays which role (role player in DCI terms). After that we need to go to another level and analyze another context and another level use case and so on, until we say stop, we are at the level sufficient for the implementation

I fully agree and when we reach that level we can realise that. The
way we realise those boundaries in DCI is with a context. In the money
transfer example, as Greg pointed out, one of those are the account.
The (average) user mental model of an account is way to simplistic but
still from the outside we can have it the simplistic way the user sees
it while when we dive one level deeper we get to implement all the
nitty gritty detail required by those concerned with this level. It's
a lot like one of the guidelines of Uncle Bobs "clean code". The
guideline is to keep each part of a method at the same abstraction
level, we can extend that to the context satisfying a mental model at
a time

-Rune

[Mikey B]

hi david, james

i can have a good guess as to why its hard for people to understand the notion of an "end user mental model". The term 'User' from trygve's original papers has dated.

He speaks of software as a service, and i guess at the time of writing the 'User' was the customer paying for the project, The person using the services provided by the software.. and they also happened to also be the domain expert.

User in todays world is similar, someone who uses a service. but with the internet and public services, it no longer means domain expert. (my mum is a user of facebook, but is no domain expert)

also in todays world, the 'customer' purchasing the software, may not necessarily be the domain expert any more.

The information from usecases having to satisfy many stakeholders may not have been clear during writing of the original documents. But we now know that the person with the clearest image of what happens in a system operation comes from the domain expert.

it should read "Domain experts mental model".

[Mikey B]

hi david, james

i can have a good guess as to why its hard for people to understand the notion of an "end user mental model". The term 'User' from trygvers original papers has dated.

He speaks of software as a service, and i guess at the time of writing the 'User' was the customer paying for the project, The person using the services provided by the software.. and they also happened to also be the domain expert.

User in todays world is similar, someone who uses a service. but with the internet and public services, it no longer means domain expert. (my mum is a user of facebook, but is no domain expert)

also in todays world, the 'customer' purchasing the software, may not necessarily be the domain expert any more.

The information from usecases having to satisfy many stakeholders may not have been clear during writing of the original documents. But we now know that the person with the clearest image of what happens in a system operation comes from the domain expert.

it should read "Domain experts mental model".

On Jul 3, 2012 6:35 AM, "rune funch" <funchs...@gmail.com> wrote:

[rune funch]

2012/7/3 Mikey B <mike...@gmail.com>

it should read "Domain experts mental model".

only if we only want our domain experts to be our users. If we won't non-domain experts to use our systems we should work closely with the domain experts to understand the nitty gritty details at the lower levels in the network of connected systems and work closely with the users (or representatives for the users) to understand the nittye gritty details of the upper levels of the network of connected systems.
Historically our business has been far better at working with the domain experts than the users, probably because the domain experts are often in the same domain as the developers, Ie. the solution domain and they are easier to understand and the value of their contributiions, they help solving problems. In contrast the users they very often make it _harder_ to solve the problems because they provide more details and often more constraints and/or variations. However they are the users and we want them to be able to use our applications. Not long ago I read an article that foresaw the demise of facebook because they did not understand the users on new platforms such as phones and tablets. People don't won't to be come domain experts to use an application they won't applications where they don't have to change there ways and preferrably where they don't have to think. So to be highly succesfull we create applications where users only have to click once (amazon) to by a product (though it takes A LOT of effort from the domain experts and developers) we stream music (Spotify) instead of requiring the user to buy each number, which the domain experts tried to cling to for years. We create weather reports with set numbers for expected rain volume and temperatures even though the domain experts they work with ranges and probabilities. I've had the fun experience of 1) working with a domain expert in the latter field and seeing an average user (my girlfriend) being exposed to just a subset of how the domain experts view weather forecasting. Though she's above average in IQ and works within agriculture (Ie her work depends heavily upon the weather) she had a hard time using the system that was modelled upon how the domain experts view the domain. Netresult: she chose another application, an application that valued the users mental model over the domain experts mental model.

-Rune

[Mikey B]

hi rune,

The user in the sense of your girlfriend, and 'users' of facebook are Actors, their needs are dealt with by MVC. The artima article is pretty good at describing MVC and the barrier of understanding the information.

Mike Brown

[rune funch]

I'm generally a very patient teacher, something that most of people I've ever taught will attest to. They can all also attest to the fact that I require one thing from them The will to learn and progress.

Reluctant as I generally my be to throw the towl into the ring, this is the breaking point. You will either have to face the demons of change or I see no reason to spent time trying to teach someone that do not want to learn.

I've tried to give to the "ah ha experience" through questions, but you have avoided them

I've tried to show you examples of why your arguments are incorrect but you shove them aside with misconceptions

To your latest misconception (quoted below): How on earth can MVC give the user a pleasant experience if the Model is based on a view of the world that the user does not understand. In the weather example the data the user is looking for is not even a part of how the domain expert views the world. How can a view present something to the user when it's not even there? 

2012/7/3 Mikey B <mike...@gmail.com>

hi rune,

The user in the sense of your girlfriend, and 'users' of facebook are Actors, their needs are dealt with by MVC. The artima article is pretty good at describing MVC and the barrier of understanding the information.

James, Trygve and I might not all agree on the details of DCI. DCI is after all evolving but rest assured the disagreements you are having in this discussion with Jim and myself on DCI and MVC iare not founded in the disagreements I've had with Trygve or Jim, nor because we haven't read/understood the artima article (or other articles on the subjects).

-Rune

 

[Mikey B]

On Jul 3, 2012 11:05 AM, "rune funch" <funchs...@gmail.com> wrote:
>
> I'm generally a very patient teacher, something that most of people I've ever taught will attest to. They can all also attest to the fact that I require one thing from them The will to learn and progress.
>
> Reluctant as I generally my be to throw the towl into the ring, this is the breaking point. You will either have to face the demons of change or I see no reason to spent time trying to teach someone that do not want to learn.
>

i dont want you and james to give up. your both important driving forces here.

> I've tried to give to the "ah ha experience" through questions, but you have avoided them
> I've tried to show you examples of why your arguments are incorrect but you shove them aside with misconceptions
>
> To your latest misconception (quoted below): How on earth can MVC give the user a pleasant experience if the Model is based on a view of the world that the user does not understand. In the weather example the data the user is looking for is not even a part of how the domain expert views the world. How can a view present something to the user when it's not even there? 
>

I understand my comments are met with skeptisism; And im sure the only person that can help you is trygve. I will be deeply surprised if he agrees with your thoughts of MVC stated above.

Mike Brown

>
> 2012/7/3 Mikey B <mike...@gmail.com>
>>
>> hi rune,
>>
>> The user in the sense of your girlfriend, and 'users' of facebook are Actors, their needs are dealt with by MVC. The artima article is pretty good at describing MVC and the barrier of understanding the information.
>
> James, Trygve and I might not all agree on the details of DCI. DCI is after all evolving but rest assured the disagreements you are having in this discussion with Jim and myself on DCI and MVC iare not founded in the disagreements I've had with Trygve or Jim, nor because we haven't read/understood the artima article (or other articles on the subjects).
>
> -Rune
>  
>

[James O Coplien]

On Jul 3, 2012, at 12:43 , Mikey B wrote:

i dont want you and james to give up. your both important driving forces here.

Let me say it bluntly: Mikey is past the point of becoming a destructive force here.

> I've tried to give to the "ah ha experience" through questions, but you have avoided them
> I've tried to show you examples of why your arguments are incorrect but you shove them aside with misconceptions
>
> To your latest misconception (quoted below): How on earth can MVC give the user a pleasant experience if the Model is based on a view of the world that the user does not understand. In the weather example the data the user is looking for is not even a part of how the domain expert views the world. How can a view present something to the user when it's not even there? 
>
I understand my comments are met with skeptisism; And im sure the only person that can help you is trygve. I will be deeply surprised if he agrees with your thoughts of MVC stated above.

First, I find Rune's characterization to be in character with all I have read about MVC. I for one don't care if our characterization of MVC exactly meets Trygve's here in the context, though I'm sure it will. First, this list is not about understanding MVC in spite of Mikey's attempt to equate DCI with MVC, so it's out of scope. Second, this is not about Mikey repeatedly trying to prove himself right, let alone proving himself right by such unqualified assertions and claims in the vein of the domain model driving behavior, and then propping himself up with condescending comments directed at Rune.

Maybe the only person who can help us is Trygve, but I think we have concluded that there is no one who can help Mikey. I would invite Mikey to cease being a disruption to this group by doing us the service of taking his discussions elsewhere.

[Mikey B]

James, im not after some kind of moral victory here.

Contexts can only live for the duration of its execution - This is something fundamental to DCI.

This means if a context is to play a model role, all of the addresses to the state objects are stored elsewhere (ive no idea where you suggest?) because the bindings to these objects are lost when the execution stops.

All i want is the lesson of a context object playing a role to be omitted, as it confuses/contradicts a DCI fundamental.

Mike Brown

[Trygve Reenskaug]

Mikey,
I have been following the discussions on this thread and am amazed at the patience with which several people have been trying to explain important concepts to you and the stubbornness with which you have resisted being taught. Your ability to change the subject whenever somebody tries to make you actually use your brain, is truly amazing. 

Example: Rune: "Let's start with answering the questions already part of this thread I have posted several questions to you (as have James) one recent one was :-----"
Your answer: "alright rune, ill post the exercise in another thread and will continue later with answering outstanding questions."
My comment: Why later?

I gave up communicating with you very long ago since communication requires  active participation from all parties. Your comments are not met with skepticism. Your comments are uniformly based on misconceptions and you appear to refuse to learn. I agree with James Coplien: Please cease being a disruption to this group and do us the service of taking your discussions elsewhere.

--Trygve

--

Trygve Reenskaug       mailto: try...@ifi.uio.no

Morgedalsvn. 5A         http://folk.uio.no/trygver/

N-0378 Oslo               Tel: (+47) 22 49 57 27

Norway

[Mikey B]

Hello Trygve,

On Jul 3, 2012 3:55 PM, "Trygve Reenskaug" <try...@ifi.uio.no> wrote:
>
> Mikey,
> I have been following the discussions on this thread and am amazed at the patience with which several people have been trying to explain important concepts to you and the stubbornness with which you have resisted being taught. Your ability to change the subject whenever somebody tries to make you actually use your brain, is truly amazing. 
>
> Example: Rune: "Let's start with answering the questions already part of this thread I have posted several questions to you (as have James) one recent one was :-----"
> Your answer: "alright rune, ill post the exercise in another thread and will continue later with answering outstanding questions."
> My comment: Why later?
>

james asked for references to back up my thoughts, something i was unable to do at the time. Would it be pointless in answering these outstanding questions now or still answer them?

> I gave up communicating with you very long ago since communication requires  active participation from all parties. Your comments are not met with skepticism. Your comments are uniformly based on misconceptions and you appear to refuse to learn. I agree with James Coplien: Please cease being a disruption to this group and do us the service of taking your discussions elsewhere.
>

I respect your opinion, and will leave. I would be grateful to know which points im miss understanding, but will understand if you dont reply.

Thankyou for your time,
Mike Brown.

[david Rozenberg]

My understanding is that an account is not any context, but data. Please show me where you see any context in an account.

Thanks,

---

From: rune funch <funchs...@gmail.com>
To: "object-co...@googlegroups.com" <object-co...@googlegroups.com>

Sent: Tuesday, July 3, 2012 1:35 AM

Subject: Re: Advice on consolidating thoughts.

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To post to this group, send email to object-co...@googlegroups.com.

To unsubscribe from this group, send email to object-composition+unsub...@googlegroups.com.

[david Rozenberg]

I think you are wrong. The user existed in Trygve's original works on MVC. There it was called the thing if I am not mistakensome bank .

As to the last portion of your statement. You do not need to be a domain expert to use a piece of software nowadays.

I wonder how we can marry DCI with some contemporary trends in software development and use like cloud computing, for example. From that kind of software, the use case ends exactly at the facade of the cloud with which users interact. The facade decides which server will serve the user and the user have no idea which one and how implements the service.

Another point is that we use libraries in software development for at least 50-60 years and we never questioned how those libraries were and are implemented. So, why do we need to question the implementation of money transfer? We use it as is. We are interested in the result of this operation, not in the details of it. I understand that from the OO standpoint it involves interactions of several objects, not just source and destination accounts, but more than that. But the end user does not interact with them, but with some facade which represents some GUI. The rest is implemented by a different object or objects, not that simple as in the example.It is really a network of interacting objects. So, why do we pull anything from what is somewhere in the middle and maybe not what actually interacts directly?

Thanks,

---

From: Mikey B <mike...@gmail.com>
To: object-co...@googlegroups.com
Sent: Tuesday, July 3, 2012 4:52 AM

Subject: Re: Advice on consolidating thoughts.

[Trygve Reenskaug]

On 2012.07.03 22:36, david Rozenberg wrote:

I think you are wrong. The user existed in Trygve's original works on MVC. There it was called the thing if I am not mistaken----

I made the a first implementation and wrote the original MVC reports while I was a visiting scientist at Xerox Palo Alto Research Center (PARC) in
1978/79. MVC was created as an obvious solution to the general problem of giving users control over their information as seen from multiple perspectives. (The example problem was to enable a user to work meaningfully with an activity plan for the construction of a ship, actually a supertanker. I brought with me a tape with such a plan. It had some 190 activities AFAICR. It was said that this was the first real industry data to ever enter the halls of PARC. The value of real data was that I couldn't fake the data to suit my solutions.

I don't think the user was explicitly mentioned in the original reports since the user's importance was understood by everyone. Jim thought otherwise, and renamed MVC to MVC-U to make the user an explicit element in the pattern.

I'll give a short story to clarify the meaning of the MVC terms.

Thing.
Consider my dog 'Fido'. Fido exists in the real world and eats and plays and grows old and does whatever dogs do. Fido is a thing in the meaning of my first PARC report. Not considered worth its own letter since there is always a real world outside the program. (TMVC? The 'T' is surely superfluous.)

Model.
I've opened the hood of my computer and can assure you that there are no dogs there. What is there is a description of Fido represented as bits within the components of my computer. All of Fido can never be represented, but the description can cover all interesting aspects: A video clip of Fido as a puppy, a snapshot of Fido as a 5-year old dog, his name and sex, his age, color, and weight, etc. I'm not the only person interested in Fido; the vet is interested in his illnesses, his medication history, his x-rays, etc. All these data items  are representations of the real things; they make up the Model.

View.
We could imagine that I had a special probe that permitted me to inspect and toggle the individual bits that make up the data of the Model. Not very user friendly, IMO. So we have a program that transforms the model data into a form that I can see with my eyes, understand, and manipulate with my hands. This program is a View. It displays a field that holds Fido's weight,  15kg. I realize that I have given Fido too much food lately, so I select the '16' and type '19' over it to signify that Fido is getting fat. The model is changed. A View is both input and output. I'm not interested in  everything about Fido; the View is also a filter showing the interesting parts only. The vet's view will be different because his interests are different.

Controller.
May be the vet wants to see two views at the same time; one showing name, sex, age, weight, etc. Another showing his specialties such as illnesses, medication, etc. He needs two views on the screen. They are tightly related since they describe the same dog. The Controller sets up and coordinates one or more Views.

User.
The ultimate master of it all is the user. I did not consider it worth its own letter since there is always a user at the top of the importance hierarchy. MVCU? I considered the 'U' as superfluous as the 'T'. Jim thought otherwise. Apparently, there are people who are so fascinated by programming that the programs are their whole world. They don't remember that a program is without value before it is used by an end user for something valuable. So, regrettably, the 'U' is needed and Jim's MVC-U is the better name.

[rune funch]

Den 03/07/2012 kl. 22.21 skrev david Rozenberg <dr_20...@yahoo.com>:

My understanding is that an account is not any context, but data.

What are the attributes of said data?

Please show me where you see any context in an account.

Thanks,

See the Marvin example of MT at fullOO.info

-Rune

To unsubscribe from this group, send email to object-composit...@googlegroups.com.

[david Rozenberg]

It looks like we are trying to bite each other instead of finding the common ground for moving forward with DCI. Data (account) is represented by the following attributes, if you wish; user id, user password, an account number, and the reference to the transaction log for this account (if you do not want to keep the actual number and wish to calculate the amount on the account on every access to it). Usually the first two attributes are stored elsewhere - in the authentication portion of the database, for example. So, merely the account consists of its id (account number) and the amount. And that is pure data. Nothing but accessor methods are needed for it. Everything else is done outside of this object and on this object. If you think that this is not what the account is, we have different mental models and probably cannot get any mutual agreement on the subject of this example.

From: rune funch <funchs...@gmail.com>
To: "object-co...@googlegroups.com" <object-co...@googlegroups.com>
Sent: Wednesday, July 4, 2012 6:40 AM
Subject: Re: Advice on consolidating thoughts.

Den 03/07/2012 kl. 22.21 skrev david Rozenberg <dr_20...@yahoo.com>:

My understanding is that an account is not any context, but data.

What are the attributes of said data?

Please show me where you see any context in an account.

Thanks,

See the Marvin example of MT at fullOO.info

-Rune

[James O Coplien]

Hi, David,

DCI supports human mental models. These include end user mental models and programmer mental models.

If you can think of an internal use case (in terms of transactions and audit logs) then DCI can handle it. That is one set of mental models, one Context. It is likely at a lower level than an account. I think that is what you describe below.

Another context — which I would refer to as an Account — reflects the end user mental model of an account.

Your description below talks only of data. I see no use cases. In DCI, a Context object is a collection of use cases that we can talk about in terms of roles. They know more have data than Shakespear's script for Hamlet contains the bodies of living human beings. Thinking of an Account as a Context is to think in terms of these use cases, these interactions between roles, apart from the data that implement them. That is a much better description of an account: in terms of its operations rather than its data.

To take this a step deeper, describe to me what a Complex number is. I can give you two complex numbers and you can add them. You can do that without me ever saying whether the representation of the Complex number is in terms of radius and angle, or real part and imaginary part. You use two different implementations, but the external use case of adding two Complex numbers remains the same. I see your argument in danger of mixing the representation of the information with its interpretation and use. Contexts are about interpretation and use — and that suffices for Accounts, just as it suffices for Complex numbers.

This smacks square in the face of many peoples' understanding of object-oriented programming as being about smart data. It's not. The smartness and the data cut across each other in complex ways. And there are strong hints that Kay originally envisioned OO in this way, too. In the original Dynabook paper (Kay, Alan. A personal computer for children of all ages. http://history-computer.com/Library/Kay72.pdf, August 1972) we find:

The first is that knowledge, particularly in the young child, is retained as a series of operational models, each of which is somewhat ad hoc and need not be logically consistent with the others. (They are essentially algorithms and strategies rather than logical axioms, predicates and theorems.)

Programming is the art of tapping into human mental models of action, of adults and children of all ages, and capturing those in the code, ibid:

We feel that a child is a "verb" rather than a "noun", an actor rather than an object; he is not a scaled-up pigeon or rat; he is trying to acquire a model of his surrounding environment in order to deal with it; his theories are "practical" notions of how to get from idea A to idea B rather than "consistent" branches of formal logic, etc. We would like to hook into his current modes of thought in order to influence him rather than just trying to replace his model with one of our own.    

Don't try to replace the child's mental models with transactions, databases, and the locus of storage of passwords. I have done the experiment many times of eliciting the end user mental model of a financial transfer; most of the current DCI implementations reflect that elicited model. The model initially underwent some of the discipline of grounded theory development and has more recently been "textured" (the last step in grounded theory) by more informal dialogue. The model is sound in light of research — though it is probably not sound in the eyes of a nerd trying to force a computer science world model onto it.

I know this is placing DCI even further outside your realm of familiarity with old OO than we've maybe ever done in this mailing list before. It took me a while to get my mind around it as well. But looking at DCI this way is instructive, at least to me, and helps many things fit together much better than if you come at this from any perspective of objects being "smart data." They are, but not in the way that most people think about them. I think the reply below fits into this latter category. It's perhaps not even technically wrong, but it ends being misleading with respect to the goals and application of DCI. It certainly ended up being wrong in its conclusion about Accounts.

[Eric Steen]

I just want to express my gratitude for the effort put forth by this group in expounding (confounding?) upon this fantastic new direction for OOAD.  

Thank you for the new neural pathways being forged in the fantastic voyage onto the bleeding edge. 

Viewing a user as a verb and not a noun helps me take the leap from data centric to behavior centric, given that the BDD mindset fits DCI very well.

Sent from my iPhone

[James O Coplien]

On Jul 4, 2012, at 7:14 , Eric Steen wrote:

given that the BDD mindset fits DCI very well.

+1

[Don Womick]

I have to second Eric here. Jim Coplien's last post was worth the
whole thread, and deserves to be preserved and expanded on, if it
hasn't been already.

God made us to love him. It takes two to love. It takes liberty. It
takes the right to reject. If there were no hell, we would be like
animals. No hell, no dignity.--Flannery O'Connor

[James O Coplien]

Help me out here, guys. Give me some ideas that expand on this. Let's put together an OOPSLA keynote.

[david Rozenberg]

Hi, James,

I think that your point with the complex numbers is slightly inaccurate. Definitely we can have different ways of presenting those. So, the use case for adding (and for subtracting, etc.) those should have several variations or deviations (in your book terms) taking into account that those can be represented differently. By simple analysis it looks like there are actually four variations of the same 'add' operation.

I appreciate your time spent on summarizing the views and concepts. That was missing previously and may help newbies with understanding DCI.

Still I would like to get your or anybody else view on how to use DCI concepts within the cloud computing environment, where the end user mental model ends, if it does, or how it reflects the way computing or use cases map to the cloud.

Thanks,

---

From: James O Coplien <jcop...@gmail.com>

To: object-co...@googlegroups.com
Sent: Wednesday, July 4, 2012 12:07 PM

[James O Coplien]

On Jul 6, 2012, at 9:41, david Rozenberg wrote:

So, the use case for adding (and for subtracting, etc.) those should have several variations or deviations (in your book terms) taking into account that those can be represented differently. 

No. Mathematicians got along just fine without computer scientists for several years, being able to talk about the complex plane independent of reducing any of its points to expression solely in Cartesian or polar coordinates. The art of thinking in the user domain is in large part about separating yourself from the implementation.

During the solution of a formula you may translate back and forth between the representations several times, as a matter of convenience, just as a for loop is convenient in one place and a do-while loop is more convenient in another. At the level of a computational conceptual model they are the same. To delve deeper into implementation is to risk sensitivity to changes in the representation, technology, programming language, or other artefacts incidental to the end user mental model. Part of the power of DCI, to me, is the ability to express logic squarely in that end user framework with a nice separation from the way we represent its low levels in the computer.

where the end user mental model ends, if it does, or how it reflects the way computing or use cases map to the cloud.

I feel that only a software person or someone similarly disconnected from the urgent business needs of the problem domain would bring up the cloud here. That's a good example of what I'm talking about. I think we'll have a better vocabulary and grounding to discuss these things when Trygve finishes his paper on Full OO.

[Mircea Samoila]

T and U are essential... this tiny discussion has put everything in perspective.

If you'd be so kind, can you add the "D", "C"  and "I" in this flow?

What i figure the main "direction" is this

Thing - [ Model - Controller - View(s) ] - User

The [] separates the real world...

real world [ computer world ] real world

[Trygve Reenskaug]

Dear Mircea Samoila,

First, a repetition of he MVC architecture:

• Thing - something in the real world, outside the computer and of interest to the end user. E.g., a bank account, an employee, a product, ... you name it. (NOT the end user)
  
• Model - a representation of a Thing as bits within a computer.
• View - a part of a computer program that translates between the data bits in the Model and something that can be perceived by a human user. (Both input and output).
  
• Controller - a part of a computer program that sets up and coordinates Views.
• User - the person interacting with the View.
  

(The definition of the words vary, but the above parts are essential regardless of what you call them).

Second, the DCI paradigm.
DCI and MVC are independent paradigms. Where MVC is about the path between the human brain and the bits in the computer representations, DCI is about system state and system behavior in a computer. System state is found in the Data part. System behavior is found in the Context and Interaction parts.

MVC and DCI have the importance of the end user in common. With MVC, human input/output is explicitly in focus. With DCI, the correspondence between the human intuitive mental model and the implementation of system state and system behavior are more indirect goals. So the two paradigms are independent but related since the user is essential to both of them. There is no simple flow that unites them because they belong on different levels of abstraction. In one application example I have written, the system architecture follows MVC. DCI is used to implement both the MVC Model itself and other details of the program such as refreshing aView.

I hope this helps
Cheers
--Trygve

--

[rune funch]

Den 28/08/2012 kl. 17.10 skrev Trygve Reenskaug <try...@ifi.uio.no>:

> If you'd be so kind, can you add the "D", "C" and "I" in this flow?

It's important to remember that DCI is not another architectural
pattern it's a paradigm as is OO or FP (Functional) so the above is
akin to asking 'if you'd be so kind. Can you add the "O" and the "O"
in this flow' .
The answer to that is more obvious to most because it's a paradigm
we're all used to. You say something like "They are all objects".
Trygve gave the same kind of answer for DCI.
If the answerr feels unfamiliar or misguided it's only for trying to
understand it as a pattern in OO.

The church had a hard time understanding (and accepting) the paradigm
shift Galileo proposed because they were not ready to reshape their
thinking. Paradigm shifts are hard because you will have to question
all you know. After all whether or not the earth is the center of the
univers (or whether or not the Higs boson exist) has implications on
the entire framework of thought.
Is a light a particle or a wave? It's can be both. That question
pretty much changed physics.
Is an object state or a operation? The answer is the same and the
result of that should change the way we think. A [M]odel might be
simple data or it might be a context. It will never be both at the
same time and it might be state to one viewer and an operation to
another.
E.g. The account might be viewed as a model with a balance property
when looking at the source role of a transfer context however the
implementation of the object might not have a simple balance property
but a method that can calculate the balance when requested.

[david Rozenberg]

I think your schema at the end is not correct: the Thing and the User are the same one actor (in the original Trygve's report or article).

---

From: rune funch <funchs...@gmail.com>
To: "object-co...@googlegroups.com" <object-co...@googlegroups.com>

Sent: Tuesday, August 28, 2012 12:17 PM

Subject: Re: Advice on consolidating thoughts.

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To post to this group, send email to object-co...@googlegroups.com.

To unsubscribe from this group, send email to object-composition+unsub...@googlegroups.com.

[Risto Välimäki]

I guess you did miss Trygve's above message. Essential part quoted below:

"Thing - something in the real world, outside the computer and of interest to the end user. E.g., a bank account, an employee, a product, ... you name it. (NOT the end user)"

Thing is not the User, but also User can be, in a way, a Thing in real world. Or at least the person that User also represents. Eg. in money transfer example, User "David" can also be account holder "David". 

But for example in a drawing software User is not necessarily a Thing that should be Modeled in source code.

-Risto

2012/8/28 david Rozenberg <dr_20...@yahoo.com>

To unsubscribe from this group, send email to object-composit...@googlegroups.com.

[david Rozenberg]

Risto,

I may be wrong, but to me there is no two different entities (thing and user). If they are different entities, then it is not clear what MVC actually represents.

---

From: Risto Välimäki <risto.v...@gmail.com>
To: object-co...@googlegroups.com
Sent: Wednesday, August 29, 2012 3:55 AM

[Risto Välimäki]

If you can't read what Trygve just wrote some hours ago on this mailing list, just read following description for a thing called "Thing" from 1979 MVC paper:

"THING

DESCRIPTION OF TERM

Something that is of interest to the user. It could be concrete, like a house or an integrated

circuit. It could be abstract, like a new idea or opinions about a paper. It could be a whole,

like a computer, or a part, like a circuit element."

(emphasis mine)

No, Thing is not the User, but Thing is something that is of interest to the User. 

Total nerd could say that Thing represents in real world what Model is in source code ;-)

-Risto

2012/8/29 david Rozenberg <dr_20...@yahoo.com>

[Trygve Reenskaug]

Hi David,
The User is not a Thing. I've reread the MVC notes but have not found the source of the misunderstanding. In the 12 May note, THING is defined as "Something that is of interest to the user.".

The MVC notes were internal for the Learning Research Group (LRG) at Xerox PARC. This group was dedicated to Alan Kay's vision of the Dynabook; a portable computer that should contain all data of interest to its owner/user. Very importantly, these data included the programs the owner used to manipulate them. The owner/user should be able to understand and write the programs, thus gaining ascendancy over the computer.

The MVC notes should be read on this background. The user was the czar; everything done at LRG was done to support him. An earlier paper adds some background for MVC:
    Trygve Reenskaug: A note on DynaBook requirements. A partial scan can be downloaded from
                         http://folk.uio.no/trygver/1979/sysreq/SysReq.pdf
I hope this clarifies your misunderstanding
--Trygve

On 2012.08.28 18:58, david Rozenberg wrote:

I think your schema at the end is not correct: the Thing and the User are the same one actor (in the original Trygve's report or article).

To unsubscribe from this group, send email to object-composit...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/object-composition?hl=en.

[david Rozenberg]

Hi Trygve,

I may have misinterpreted what I read several years ago.

Thank you for the update,

david

---

From: Trygve Reenskaug <try...@ifi.uio.no>
To: object-co...@googlegroups.com
Sent: Friday, August 31, 2012 9:42 AM