Subjectopia tools2011

645
-1

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
645
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
  • 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

    ×