Your SlideShare is downloading. ×
Unifying  SubjectivityDaniel Langone, Jorge Ressia    and Oscar Nierstrasz
Subjective:Based on or influenced by personalfeelings, tastes, or opinions.                                     d Dict iona...
Ben’s                                    Dave’s                        addAndRecord: 200.00      BankAccount              ...
PreviousApproaches
Perspectives           RolesContext-oriented   Subjective Method Programming           Behavior
Perspectives           RolesContext-oriented   Subjective Method Programming           Behavior
Perspectives           RolesContext-oriented   Subjective Method Programming           Behavior                           ...
)$5$*6$&7!"#$%   !&&(&)$*+%&,-.//0//   !"#$%1$%#2$*34$
!#)*+,"!#$%&&(#)   !--%#-.+&,-/0122322   !"!#$%&&(#)4+,56+&78+                                                         9!:...
Perspectives           RolesContext-oriented   Subjective Method Programming           Behavior
Perspectives           RolesContext-oriented   Subjective Method Programming           Behavior                           ...
Perspectives           RolesContext-oriented   Subjective Method Programming           Behavior
Perspectives           RolesContext-oriented   Subjective Method Programming           Behavior                           ...
aBankAccount     addAndRecord: rootLayer                addAndRecord: userLayer               addAndRecord: bankLayer
Perspectives           RolesContext-oriented   Subjective Method Programming           Behavior
Perspectives           RolesContext-oriented   Subjective Method Programming           Behavior                           ...
allowRecord                               balance := balance + aNumber  recordAllowed            Method Determinant       ...
Problems
Single point of view
Group programming
Group programming                      US                        Ungar 1996          Sm   it h and
Mail Delivery
Mail Delivery                            havior                e Met hod Be 04       Subjectiv nd Prieto 20        Dard er...
Modeling Context
Perspectives           RolesContext-oriented   Subjective Method Programming           Behavior
?Context-oriented Perspectives     Roles Programming
?Subjectopia Context-oriented  Perspectives      Roles  Programming
SubjectDecision             ContextualStrategy              Element
Subjects
Decision Strategies
addAndRecord: 200aUser                               aBankAccount                             aDecisionStrategy           ...
Contextual Elements
aUser                                        aBankAccount           aContextualElement        addAndRecord: 200           ...
Unified Subjectivity       Model
SubjectDecision             ContextualStrategy              Element
Model previous approaches
PerspectivesPerspectiveDecisionStrategy ContextualElement+decideOn:                 +decideOn:   «uses»                   ...
COP                           ContextualElement                           +decideOn:COPDecisionStrategy   «uses»     Layer...
Roles                            ContextualElement                            +decideOn:RoleDecisionStrategy   «uses»     ...
SMB              DecisionStrategy              +decideOn:ForceDeterminant           MethodDeterminant‐forceCondition‐trueD...
Examples
moosetechnology.org
Moose Groups  Elements
Entities                         Method    Class                             Parameter            Annotation            At...
Moose Groups                  MethodGroup    ClassGroup                      ParameterGroup         AnnotationGroup       ...
Subjective Menus
o mpl exityS     m Ccasse 2003  yste Du      Lanza,
!"##$%&#()**            !B%:3+%C:/#-**      $1$0%67#6)8%9301**                                                            ...
MooseModel                    ContextualElement‐models             FamixEntitiesForInterface             ‐famixEntities   ...
MooseModel                    ContextualElement‐models             FamixEntitiesForInterface             ‐famixEntities   ...
MooseModel                    ContextualElement‐models             FamixEntitiesForInterface             ‐famixEntities   ...
Implementation
Dynamic Adaptation
scg.unibe.ch/research/        bifrost
ClassObject
Class         Subject Meta-objectObject
Class          Subject Meta-objectSubject
Subjectopia                Subject     Decision             Contextual     Strategy              Elementscg.unibe.ch/resea...
Subjectopia tools2011
Subjectopia tools2011
Subjectopia tools2011
Subjectopia tools2011
Subjectopia tools2011
Subjectopia tools2011
Subjectopia tools2011
Subjectopia tools2011
Subjectopia tools2011
Subjectopia tools2011
Subjectopia tools2011
Subjectopia tools2011
Subjectopia tools2011
Subjectopia tools2011
Subjectopia tools2011
Subjectopia tools2011
Subjectopia tools2011
Subjectopia tools2011
Subjectopia tools2011
Upcoming SlideShare
Loading in...5
×

Subjectopia tools2011

590

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
590
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Perspective-layer-piece\n
  • Perspective-layer-piece\n
  • Perspective-layer-piece\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Although formally the approaches are equivalent in expressive power, they are not equally suitable in all circumstances. Each of these approaches imposes a particular modeling paradigm which may be appropriate for certain problem domains, but not for others.\n
  • Consider the use case where a user wants to send an email using a mobile device [4]. If the network is available the email should be sent immediately, otherwise the email should be saved and sent when possible. Modeling the network with either roles or perspectives does not make sense. This subjective problem is not about roles of networks or emails, or about perspectives through which they may be seen, but rather about whether the network is available in the current context. Whereas COP or SMB might be more appropriate for modeling subjectivity in this domain, perspectives or roles would be more suitable to model behavior that varies with respect to the sender of a message.\n\ngroup programming - yes: perspective, not SMB\nWhere is the decision is also important.\nmail delivery: yes SMB, not COP, list of influencers not layers\n
  • Smith and Ungar A Simple and Unifying Approach to Subjective Objects\n
  • Great for SMB but not good for Roles, or COP\n
  • Modeling context is really hard because is subjective to the problem domain.\nWe end up with collections.\nWe are modeling the subjectivity of subjectivity.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • not all approaches solves all problems.\n
  • delegated to the decision strategy with decideOn: anObject\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • that it is a cool, large and open source platform for data and software analysis that is being increasingly used in industrial projects\n
  • We model the decision of what to do in each visualization in the decision strategy.\n
  • \n
  • \n
  • \n
  • \n
  • The problem is that some visualizations may require contextual information\nnot retrievable from the objects and subjects involved in the communication. Let us consider that we select a group of classes and that we want to view them as highlighted on the overall system complexity. This can be achieved by sending the message viewAsSelectionOnSystemComplexity to the group. This behavior also requires all other FamixClass entities of the model to create this visualization. However, in different analysis contexts we want to see only a sub- set of all classes as a basis for the visualization. Thus, the simple action of viewAsSelectionOnSystemComplexity requires both the receiving group and the reference group. Moose currently uses model-wise global variables to store this information. The problem is that each new instance of the graphical user inter- face of Moose can override the value of that global variable and this results in unwanted side effects.\n
  • width: attributes\nheight: methods\ncolor: lines of code\n
  • \n
  • \n
  • \n
  • Our solution uses contextual elements to model the additional, contextsensitive information. The context influencing the behavior of the selected FamixClass group is all FamixClass entities of that model. Therefore, each model creates and maintains its own set of contextual elements holding all of its FamixClass entities for each user interface. We use a decision strategy modeling the behavior for the message viewAsSelectionOnSystemComplexity. The decision strategy has access to the contextual elements of its model, i.e., all FamixClass entities of the model. The decision strategy determines, using the meta-information of the message, which interface has sent the message and accordingly uses that contextual element.\n
  • Our solution uses contextual elements to model the additional, contextsensitive information. The context influencing the behavior of the selected FamixClass group is all FamixClass entities of that model. Therefore, each model creates and maintains its own set of contextual elements holding all of its FamixClass entities for each user interface. We use a decision strategy modeling the behavior for the message viewAsSelectionOnSystemComplexity. The decision strategy has access to the contextual elements of its model, i.e., all FamixClass entities of the model. The decision strategy determines, using the meta-information of the message, which interface has sent the message and accordingly uses that contextual element.\n
  • The problem is that some visualizations may require contextual information\nnot retrievable from the objects and subjects involved in the communication. Let us consider that we select a group of classes and that we want to view them as highlighted on the overall system complexity. This can be achieved by sending the message viewAsSelectionOnSystemComplexity to the group. This behavior also requires all other FamixClass entities of the model to create this visualization. However, in different analysis contexts we want to see only a sub- set of all classes as a basis for the visualization. Thus, the simple action of viewAsSelectionOnSystemComplexity requires both the receiving group and the reference group. Moose currently uses model-wise global variables to store this information. The problem is that each new instance of the graphical user inter- face of Moose can override the value of that global variable and this results in unwanted side effects.\n
  • \n
  • Our solution uses contextual elements to model the additional, contextsensitive information. The context influencing the behavior of the selected FamixClass group is all FamixClass entities of that model. Therefore, each model creates and maintains its own set of contextual elements holding all of its FamixClass entities for each user interface. We use a decision strategy modeling the behavior for the message viewAsSelectionOnSystemComplexity. The decision strategy has access to the contextual elements of its model, i.e., all FamixClass entities of the model. The decision strategy determines, using the meta-information of the message, which interface has sent the message and accordingly uses that contextual element.\n
  • The problem is that some visualizations may require contextual information\nnot retrievable from the objects and subjects involved in the communication. Let us consider that we select a group of classes and that we want to view them as highlighted on the overall system complexity. This can be achieved by sending the message viewAsSelectionOnSystemComplexity to the group. This behavior also requires all other FamixClass entities of the model to create this visualization. However, in different analysis contexts we want to see only a sub- set of all classes as a basis for the visualization. Thus, the simple action of viewAsSelectionOnSystemComplexity requires both the receiving group and the reference group. Moose currently uses model-wise global variables to store this information. The problem is that each new instance of the graphical user inter- face of Moose can override the value of that global variable and this results in unwanted side effects.\n
  • The problem is that some visualizations may require contextual information\nnot retrievable from the objects and subjects involved in the communication. Let us consider that we select a group of classes and that we want to view them as highlighted on the overall system complexity. This can be achieved by sending the message viewAsSelectionOnSystemComplexity to the group. This behavior also requires all other FamixClass entities of the model to create this visualization. However, in different analysis contexts we want to see only a sub- set of all classes as a basis for the visualization. Thus, the simple action of viewAsSelectionOnSystemComplexity requires both the receiving group and the reference group. Moose currently uses model-wise global variables to store this information. The problem is that each new instance of the graphical user inter- face of Moose can override the value of that global variable and this results in unwanted side effects.\n
  • \n
  • \n
  • applies meta-objects to add the required behavior to the object that should be subjective, add decision strategy and so on.\n
  • \n
  • \n
  • \n
  • Transcript of "Subjectopia tools2011"

    1. 1. Unifying SubjectivityDaniel Langone, Jorge Ressia and Oscar Nierstrasz
    2. 2. Subjective:Based on or influenced by personalfeelings, tastes, or opinions. d Dict ionary Oxfor
    3. 3. Ben’s Dave’s addAndRecord: 200.00 BankAccount BankAccounttransfer: 200.00 to:DavesBankAccount addAndRecord: 200.00 Ben Dave
    4. 4. PreviousApproaches
    5. 5. Perspectives RolesContext-oriented Subjective Method Programming Behavior
    6. 6. Perspectives RolesContext-oriented Subjective Method Programming Behavior
    7. 7. Perspectives RolesContext-oriented Subjective Method Programming Behavior US Ungar 1996 Sm it h and
    8. 8. )$5$*6$&7!"#$% !&&(&)$*+%&,-.//0// !"#$%1$%#2$*34$
    9. 9. !#)*+,"!#$%&&(#) !--%#-.+&,-/0122322 !"!#$%&&(#)4+,56+&78+ 9!:!#&+0/;09!:!#&+0<0122322 !"!#$%&&(#)
    10. 10. Perspectives RolesContext-oriented Subjective Method Programming Behavior
    11. 11. Perspectives RolesContext-oriented Subjective Method Programming Behavior Beta stensen 1995 Kri
    12. 12. Perspectives RolesContext-oriented Subjective Method Programming Behavior
    13. 13. Perspectives RolesContext-oriented Subjective Method Programming Behavior Con textL 2005 nd Hir schfeld ostanza a C
    14. 14. aBankAccount addAndRecord: rootLayer addAndRecord: userLayer addAndRecord: bankLayer
    15. 15. Perspectives RolesContext-oriented Subjective Method Programming Behavior
    16. 16. Perspectives RolesContext-oriented Subjective Method Programming Behavior Sm alltalk 2004 es and Prieto D arder
    17. 17. allowRecord balance := balance + aNumber recordAllowed Method Determinant Sender Identity ForceForce Determinant denyRecord self error: ‘Rejected!’ Method Determinant
    18. 18. Problems
    19. 19. Single point of view
    20. 20. Group programming
    21. 21. Group programming US Ungar 1996 Sm it h and
    22. 22. Mail Delivery
    23. 23. Mail Delivery havior e Met hod Be 04 Subjectiv nd Prieto 20 Dard eres a
    24. 24. Modeling Context
    25. 25. Perspectives RolesContext-oriented Subjective Method Programming Behavior
    26. 26. ?Context-oriented Perspectives Roles Programming
    27. 27. ?Subjectopia Context-oriented Perspectives Roles Programming
    28. 28. SubjectDecision ContextualStrategy Element
    29. 29. Subjects
    30. 30. Decision Strategies
    31. 31. addAndRecord: 200aUser aBankAccount aDecisionStrategy aDecisionStrategy Decision strategy for addAndRecord: aDecisionStrategy
    32. 32. Contextual Elements
    33. 33. aUser aBankAccount aContextualElement addAndRecord: 200 aDecisionStrategy aDecisionStrategy aContextualElement aDecisionStrategy
    34. 34. Unified Subjectivity Model
    35. 35. SubjectDecision ContextualStrategy Element
    36. 36. Model previous approaches
    37. 37. PerspectivesPerspectiveDecisionStrategy ContextualElement+decideOn: +decideOn: «uses» PerspectiveLayer Piece Perspective ‐pieces ‐forMessage ‐rootLayer ‐layerParent ‐forObject +decideOn: +decideOn: +decideOn:
    38. 38. COP ContextualElement +decideOn:COPDecisionStrategy «uses» Layer+decideOn: +decideOn:
    39. 39. Roles ContextualElement +decideOn:RoleDecisionStrategy «uses» Role+decideOn: +decideOn:
    40. 40. SMB DecisionStrategy +decideOn:ForceDeterminant MethodDeterminant‐forceCondition‐trueDeterminant +decideOn:‐falseDeterminant+decideOn:
    41. 41. Examples
    42. 42. moosetechnology.org
    43. 43. Moose Groups Elements
    44. 44. Entities Method Class Parameter Annotation AttributeNamespace Package
    45. 45. Moose Groups MethodGroup ClassGroup ParameterGroup AnnotationGroup AttributeGroupNamespaceGroup PackageGroup
    46. 46. Subjective Menus
    47. 47. o mpl exityS m Ccasse 2003 yste Du Lanza,
    48. 48. !"##$%&#()** !B%:3+%C:/#-** $1$0%67#6)8%9301** +% "##$%&#() B%:3$3#-50!0%<1 B%:3$3#-50!0%<1!++*,!-.-/01 ()+!0% ? 23%451$0%6 7#6)8%9301 @ 23%451$0%6 A 7#6)8%9301 +%:3+%;-*, !"%$$!<%5%-+=->#6!/#-
    49. 49. MooseModel ContextualElement‐models FamixEntitiesForInterface ‐famixEntities * 1 ModelBag ‐models ‐GUIInstance «uses»
    50. 50. MooseModel ContextualElement‐models FamixEntitiesForInterface ‐famixEntities * 1 ModelBag ‐models ‐GUIInstance «uses»
    51. 51. MooseModel ContextualElement‐models FamixEntitiesForInterface ‐famixEntities * 1 ModelBag ‐models ‐GUIInstance «uses»
    52. 52. Implementation
    53. 53. Dynamic Adaptation
    54. 54. scg.unibe.ch/research/ bifrost
    55. 55. ClassObject
    56. 56. Class Subject Meta-objectObject
    57. 57. Class Subject Meta-objectSubject
    58. 58. Subjectopia Subject Decision Contextual Strategy Elementscg.unibe.ch/research/subjectopia

    ×