Unifying Subjectivity in Software Modeling
•
0 recomendaciones•674 vistas
This document proposes a unified model of subjectivity for programming called Subjectopia. It summarizes previous approaches that consider subjectivity through perspectives, roles, and context-oriented programming. The Subjectopia model represents subjectivity using three main elements: Subjects to represent programming entities, Decision Strategies to determine their behavior, and Contextual Elements that influence strategies. It illustrates how this model can represent prior work and provides examples of its implementation.
Recomendados
Recomendados
Más contenido relacionado
Similar a Unifying Subjectivity in Software Modeling
Similar a Unifying Subjectivity in Software Modeling (20)
Más de Jorge Ressia
Más de Jorge Ressia (12)
Último
Último (20)
Unifying Subjectivity in Software Modeling
- 1. Unifying Subjectivity Daniel Langone, Jorge Ressia and Oscar Nierstrasz
- 2. Subjective: Based on or influenced by personal feelings, tastes, or opinions. d Dict ionary Oxfor
- 10. Ben’s Dave’s addAndRecord: 200.00 BankAccount BankAccount transfer: 200.00 to: DavesBankAccount addAndRecord: 200.00 Ben Dave
- 12. Perspectives Roles Context-oriented Subjective Method Programming Behavior
- 13. Perspectives Roles Context-oriented Subjective Method Programming Behavior
- 14. Perspectives Roles Context-oriented Subjective Method Programming Behavior US Ungar 1996 Sm it h and
- 17. )$5$*6$&7 !"#$% !&&'(&)$*+%&,-.//0// !"#$%1$%#2$*34$
- 18. !#')*+,"!#$%&&'(#) !--%#-.+&',-/0122322 !"!#$%&&'(#)4+,56+&78+ 9!:!#&+0/;09!:!#&+0<0122322 !"!#$%&&'(#)
- 19. Perspectives Roles Context-oriented Subjective Method Programming Behavior
- 20. Perspectives Roles Context-oriented Subjective Method Programming Behavior Beta stensen 1995 Kri
- 22. Perspectives Roles Context-oriented Subjective Method Programming Behavior
- 23. Perspectives Roles Context-oriented Subjective Method Programming Behavior Con textL 2005 nd Hir schfeld ostanza a C
- 24. aBankAccount addAndRecord: rootLayer addAndRecord: userLayer addAndRecord: bankLayer
- 25. Perspectives Roles Context-oriented Subjective Method Programming Behavior
- 26. Perspectives Roles Context-oriented Subjective Method Programming Behavior Sm alltalk 2004 es and Prieto D arder
- 27. allowRecord balance := balance + aNumber recordAllowed Method Determinant Sender Identity Force Force Determinant denyRecord self error: ‘Rejected!’ Method Determinant
- 28. Problems
- 29. Single point of view
- 31. Group programming US Ungar 1996 Sm it h and
- 32. Mail Delivery
- 33. Mail Delivery havior e Met hod Be 04 Subjectiv nd Prieto 20 Dard eres a
- 34. Modeling Context
- 35. Perspectives Roles Context-oriented Subjective Method Programming Behavior
- 36. ? Context-oriented Perspectives Roles Programming
- 37. ? Subjectopia Context-oriented Perspectives Roles Programming
- 38. Subject Decision Contextual Strategy Element
- 39. Subjects
- 41. addAndRecord: 200 aUser aBankAccount aDecisionStrategy aDecisionStrategy Decision strategy for addAndRecord: aDecisionStrategy
- 43. aUser aBankAccount aContextualElement addAndRecord: 200 aDecisionStrategy aDecisionStrategy aContextualElement aDecisionStrategy
- 44. Unified Subjectivity Model
- 45. Subject Decision Contextual Strategy Element
- 47. Perspectives PerspectiveDecisionStrategy ContextualElement +decideOn: +decideOn: «uses» PerspectiveLayer Piece Perspective ‐pieces ‐forMessage ‐rootLayer ‐layerParent ‐forObject +decideOn: +decideOn: +decideOn:
- 48. COP ContextualElement +decideOn: COPDecisionStrategy «uses» Layer +decideOn: +decideOn:
- 49. Roles ContextualElement +decideOn: RoleDecisionStrategy «uses» Role +decideOn: +decideOn:
- 50. SMB DecisionStrategy +decideOn: ForceDeterminant MethodDeterminant ‐forceCondition ‐trueDeterminant +decideOn: ‐falseDeterminant +decideOn:
- 51. Examples
- 53. Moose Groups Elements
- 54. Entities Method Class Parameter Annotation Attribute Namespace Package
- 55. Moose Groups MethodGroup ClassGroup ParameterGroup AnnotationGroup AttributeGroup NamespaceGroup PackageGroup
- 57. Subjective Menus
- 60. o mpl exity S m Ccasse 2003 yste Du Lanza,
- 62. !"##$%&'#()** !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!/#-
- 64. MooseModel ContextualElement ‐models FamixEntitiesForInterface ‐famixEntities * 1 ModelBag ‐models ‐GUIInstance «uses»
- 65. MooseModel ContextualElement ‐models FamixEntitiesForInterface ‐famixEntities * 1 ModelBag ‐models ‐GUIInstance «uses»
- 68. MooseModel ContextualElement ‐models FamixEntitiesForInterface ‐famixEntities * 1 ModelBag ‐models ‐GUIInstance «uses»
- 71. Implementation
- 73. scg.unibe.ch/research/ bifrost
- 74. Class Object
- 75. Class Subject Meta-object Object
- 76. Class Subject Meta-object Subject
- 77. Subjectopia Subject Decision Contextual Strategy Element scg.unibe.ch/research/subjectopia
Notas del editor
- \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