Email
Like
Liked ×
Save
Private Content
Embed
Loading embed code…
We have emailed the verification/download link to "".
Login to your email and click the link to download the file directly.

To request the link at a different email address, update it here. Close
Validation messages. Success message. Fail message.

Check your bulk/spam folders if you can't find our mail.
Loading

+ Follow

Subjectopia tools2011

by Jorge Ressia

486 views

Accessibility

View text version

Upload Details

Uploaded via SlideShare as Apple Keynote

Usage Rights

File a copyright complaint

4 Embeds 153

http://scg.unibe.ch	150
http://www.slideshare.net	1
http://paper.li	1
url_unknown	1

Statistics

Likes: 0
Downloads: 0
Comments: 0
Embed Views: 153
Views on SlideShare: 333
Total Views: 486

\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 Presentation Transcript

Unifying SubjectivityDaniel Langone, Jorge Ressia and Oscar Nierstrasz
Subjective:Based on or inﬂuenced by personalfeelings, tastes, or opinions. d Dict ionary Oxfor
Ben’s Dave’s addAndRecord: 200.00 BankAccount BankAccounttransfer: 200.00 to:DavesBankAccount addAndRecord: 200.00 Ben Dave
PreviousApproaches
Perspectives RolesContext-oriented Subjective Method Programming Behavior
Perspectives RolesContext-oriented Subjective Method Programming Behavior
Perspectives RolesContext-oriented Subjective Method Programming Behavior US Ungar 1996 Sm it h and
)$5$*6$&7!"#$% !&&(&)$*+%&,-.//0// !"#$%1$%#2$*34$
!#)*+,"!#$%&&(#) !--%#-.+&,-/0122322 !"!#$%&&(#)4+,56+&78+ 9!:!#&+0/;09!:!#&+0<0122322 !"!#$%&&(#)
Perspectives RolesContext-oriented Subjective Method Programming Behavior
Perspectives RolesContext-oriented Subjective Method Programming Behavior Beta stensen 1995 Kri
Perspectives RolesContext-oriented Subjective Method Programming Behavior
Perspectives RolesContext-oriented Subjective Method Programming Behavior Con textL 2005 nd Hir schfeld ostanza a C
aBankAccount addAndRecord: rootLayer addAndRecord: userLayer addAndRecord: bankLayer
Perspectives RolesContext-oriented Subjective Method Programming Behavior
Perspectives RolesContext-oriented Subjective Method Programming Behavior Sm alltalk 2004 es and Prieto D arder
allowRecord balance := balance + aNumber recordAllowed Method Determinant Sender Identity ForceForce Determinant denyRecord self error: ‘Rejected!’ 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 eres a
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 aDecisionStrategy Decision strategy for addAndRecord: aDecisionStrategy
Contextual Elements
aUser aBankAccount aContextualElement addAndRecord: 200 aDecisionStrategy aDecisionStrategy aContextualElement aDecisionStrategy
Unified Subjectivity Model
SubjectDecision ContextualStrategy Element
Model previous approaches
PerspectivesPerspectiveDecisionStrategy ContextualElement+decideOn: +decideOn: «uses» PerspectiveLayer Piece Perspective ‐pieces ‐forMessage ‐rootLayer ‐layerParent ‐forObject +decideOn: +decideOn: +decideOn:
COP ContextualElement +decideOn:COPDecisionStrategy «uses» Layer+decideOn: +decideOn:
Roles ContextualElement +decideOn:RoleDecisionStrategy «uses» Role+decideOn: +decideOn:
SMB DecisionStrategy +decideOn:ForceDeterminant MethodDeterminant‐forceCondition‐trueDeterminant +decideOn:‐falseDeterminant+decideOn:
Examples
moosetechnology.org
Moose Groups Elements
Entities Method Class Parameter Annotation AttributeNamespace Package
Moose Groups MethodGroup ClassGroup ParameterGroup AnnotationGroup AttributeGroupNamespaceGroup PackageGroup
Subjective Menus
o mpl exityS m Ccasse 2003 yste Du Lanza,
!"##$%&#()** !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!/#-
MooseModel ContextualElement‐models FamixEntitiesForInterface ‐famixEntities * 1 ModelBag ‐models ‐GUIInstance «uses»
MooseModel ContextualElement‐models FamixEntitiesForInterface ‐famixEntities * 1 ModelBag ‐models ‐GUIInstance «uses»
MooseModel ContextualElement‐models FamixEntitiesForInterface ‐famixEntities * 1 ModelBag ‐models ‐GUIInstance «uses»
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/research/subjectopia

Subjectopia tools2011

by Jorge Ressia

Accessibility

Categories

Upload Details

Usage Rights

4 Embeds 153

Statistics

Subjectopia tools2011 Presentation Transcript

Let LinkedIn power your SlideShare experience

Let LinkedIn power your SlideShare experience

Customize SlideShare content based on your interests

Keep up to date when your LinkedIn contacts post on SlideShare