Trying to understand role modeling via an example

[Marius - Adrian Francu]

Hi all. For a long time I try not to write here about this subject because I wanted to be sure that I tried everything I could to make a sense and not just to find an easy answer and that's it.

I try to expose here an example which I have encountered in my life 3 times in different forms. It was interesting for me to see it from the perspective of DCI, especially for this thread the role modeling. 

Premises

- I know the code is important, but before code, I think, is very important to understand what I have to put in code. I like a lot what my current PO told me: "I want you to think as much as you can, not to just write code"

- see if I understood a little bit the role modeling thing;

- I like a lot/love the book "Working with objects The OOram Software Engineering Method". After reading the first 2 chapters, I understood how ignorant of OOP I was for 15 years :( 

Context

The core of the application is about approving certain requests. For example: absences, new employee, training,.... As you can see the requests are different. These requests will be approved by different positions in the company:

-absence(employee, starts the request - >team lead, first approver - > agency director, last approved) 

-new employee(chief department, starts the request  - >hr manager, first approver, in the sense that all needed papers are ok;

 -> IT manager, in the sense that all it stuff are done like account, badge,..) 

-training (team lead, starts the request on behalf of employee - > quality, first approve to see if the firm providing the training is ok; - > financial department, second approval level to make the payment, among other things) 

As you can see from the examples above, for a specific request there are specific positions in chain which will make the approval. 

A position can appear in multiple requests approvals. 

Also each request will contain the approvals done and by whom, from that specific position. 

UI perspective:

The Requester will have a left side menu with all requests he/she can make

The Approver can have different positions. Those positions will appear as menu at the top of the window. For example, when she/he will click Team Lead position he/she will see all the requests that it can approve as a Team Lead, no matter the request type. 

Patterns observed:

There is a Requester, the person who initiates the request. 

There is the Approver, the one who will approve at a certain level

There is a final state of the request, after Last Approver has approved. 

Diagrams:

I would have liked to represent graphically the patterns observed in one diagram like in the OOram book. (see image below). But is not possible and it makes sense. I should build 2 or 3.

Note: For me this graphic was the trigger point in understanding the things, well in thinking that I understood the things. 

Conclusion

The employee positions like team lead, director agency, at runtime will be able to play the role of Requester or Approver.

Questions

- Did I spot ok the object roles played? 

- How should I represent for each type of request the flow of approval? I imagine that in Context I will need to see, based on a schema probably, what kind of Approver is the person currently seeing the request. Does it make sense to have a small graph to represent the flows of approval for a certain type of request? 

- Am I missing something? 

Any feedback is highly appreciated.

Thank you,

Marius

[Trygve Reenskaug]

Hi Marius,
I apologize for the late answer; I have been very busy with the printers. 

You are on the right track.
Your questions:

- Did I spot ok the object roles played?

Yes.
Your roles(Requestor, Approver, and a possible 2nd Approver) are very reasonable roles. A role model is about objects and interfaces. The nature of the objects is irrelevant so the Requestor role could be played by an object that represents an employee, IT manager, team lead, etc . The only requirement is that the object responds to the required messages. Similarly for the Approver role. 

- How should I represent for each type of request the flow of approval? I imagine that in Context I will need to see, based on a schema probably, what kind of Approver is the person currently seeing the request.

A role player is not a person, but an object that represents a person. All that's required of that object is that is understands (respond to)  the required messages. Role modeling says nothing about the important mapping between role and object. (In the Data, Context, Interaction (DCI) programming paradigm, code for this mapping is an essential part of the Context code. Also, the mapping of all the roles in a context is done simultaneously to ensure consistency).

Does it make sense to have a small graph to represent the flows of approval for a certain type of request?

Yes, very much so. I use a UML sequence diagram for the purpose with one lifeline for each role.
https://en.wikipedia.org/wiki/Sequence_diagram
You may be interested in this position paper:
http://folk.uio.no/trygver/1999/GoalMeans/GoalMeans.pdf

- Am I missing something?

Possibly, but not likely,  the important distinction between something and an object that represents selected properties of that something.
For example, an IT manager with all their faults and merits can be represented by an object with a very simple interface.

Does  this answer your questions?
--Trygve

--

The essence of object orientation is that objects collaborate  to achieve a goal.
Trygve Reenskaug      mailto: try...@ifi.uio.no
Morgedalsvn. 5A       http://folk.uio.no/trygver/
N-0378 Oslo             http://fullOO.info
Norway                     Tel: (+47) 468 58 625

[Marius - Adrian Francu]

Hi Trygve,

Thx a lot for taking the time to help me out.

"Does this answer your questions?" of course.

The next step, for me, is to come up with a simple code. I try to come with an example asap. It will be a good occasion to see if I misinterpreted some things. I'll try to make the code clean so it can be read.
Thx a lot Trygve.
--Marius