Evaluating Functions
问题描述 :
In the interior of the teleport machine you may find a special structure (as illustrated above). There are N cylinders of possibly different integer heights, and a special (yet unknown to you) value had been assigned to each of them in the following way:
Suppose the heights of the cylinders are recorded in the array H[] , the values assigned to them are recorded in the array value[] , and we are currently calculating the value for cylinder X (i.e., valuex . Before this process is executed, valuex will be set to zero, and we initialized a pointer, P , which should be pointing to X at the beginning)
0.
Let P = P – 1 . (i.e., modifies the pointer P so that it now points to the cylinder on the left side of the current cylinder P ). If there’s none (P = = NULL) , or Hp > Hx , then let P = X , and go to step 2; otherwise, proceed to the next step.
1.
Find the highest cylinder on the left side of the cylinder P , and let its height be H’ . If such cylinder exists, increase valuex by max{min{H’, Hx} – Hp, 0} , and go to step 0.
2.
Let P = P + 1 . (i.e., modifies the pointer P so that it now points to the cylinder on the right side of the current cylinder P ). If there’s none (P = = NULL) , or Hp > Hx , then terminate the process; otherwise, proceed to the next step.
3.
Find the highest cylinder on the right side of the current cylinder P , and let its height be H’ . If such cylinder exists, increase valuex by max{min{H’, Hx} – Hp, 0} , and go to step 2.
You have to enter two integers, the distance which you want to move the object, K , and the K -th largest value T among all N cylinders’ values. A serious malfunction will occur unless the numbers K and T are entered correctly. (It is easy to see that if we follow the process described above strictly, it takes O(N3) time to calculate all values; that is why the engineers can only use short-distance teleportation so far; however you wonder whether there exists a way to evaluate the function effectively so as to use the long-range transfer ability of this machine.)
Now you have to figure out what the value of T is, given the heights of all cylinders of the teleport machine and the distance you need to move the object. For example you find the machine has 5 cylinders, and the distance you want to move the object is 2. Their heights are 2 1 2 1 3 so your calculations (value ) are 2 0 2 0 2. After that the T which you should enter the second largest value is 2.
输入:
输出:
样例输入:
5 2 2 1 2 1 3 5 1 4 5 1 1 7 0 0
样例输出:
Case 1: 2 Case 2: 8
#include<stdio.h> #include<algorithm> #define N 200009 typedef long long LL; using namespace std; int n,m,a[N],b[N],c[N],L[N],R[N]; LL d[N],s1[N],s2[N],sum[N]; LL max(LL aa, LL bb) { if(aa > bb)return aa; return bb; } void make() { int i,j,k,l; for(i=1;i<=n;i++) { k = i-1; while(k > 0 && a[k] <= a[i])k = b[k]; b[i] = k; } for(i=n;i>0;i--) { k = i+1; while(k <= n && a[k] <= a[i])k = c[k]; c[i] = k; } } int main() { int i,j,k,l,cas=0; while(scanf("%d %d",&n,&m) != EOF) { if(n == 0 && m == 0)break; sum[0] = 0; for(i=1;i<=n;i++) { scanf("%d",&a[i]); sum[i] = sum[i-1] + a[i]; } make(); L[1] = a[1]; for(i=2;i<=n;i++) { L[i] = a[i]; if(L[i] < L[i-1])L[i] = L[i-1]; } R[n] = a[n]; for(i=n-1;i>0;i--) { R[i] = a[i]; if(R[i] < R[i+1])R[i] = R[i+1]; } s1[1] = 0; for(i=2;i<=n;i++) { s1[i] = s1[i-1] + max(L[i-1] - a[i], 0); } s2[n] = 0; for(i=n-1;i>0;i--) { s2[i] = s2[i+1] + max(R[i+1] - a[i], 0); } for(i=1;i<=n;i++) { d[i] = 0; k = b[i]; if(k < 1)d[i] += s1[i]; else { l = i-k-1; d[i] += (LL)l*a[i] - (sum[i-1]-sum[k]); } // printf("%d ",d[i]); k = c[i]; if(k > n)d[i] += s2[i]; else {//printf("%d %d %d\n",k,l*a[i], (sum[k-1]-sum[i])); l = k-i-1; d[i] += (LL)l*a[i] - (sum[k-1]-sum[i]); } // printf("%d\n",d[i]); } sort(d+1, d+1+n); printf("Case %d: %I64d\n",++cas,d[n-m+1]); } return 0; }
我是第一个？？
good !
程序是错的吧，明显没有判断不和该节点相邻的其他节点是否相互相邻
这个条件 “两个数的乘积最小”可以忽略
没错的，九度OJ也有此题
如果两个序列的最后字符不匹配（即X [M-1]！= Y [N-1]）
L（X [0 .. M-1]，Y [0 .. N-1]）= MAX（L（X [0 .. M-2]，Y [0 .. N-1]），L（X [0 .. M-1]，Y [0 .. N-1]）
这里写错了吧。
正是我要找的，适合新手
哇，算法有这么多呢！
这个方法是错的，不信你试试：
20 5
1 A:9
1 A:9
1 A:9
1 A:6
1 A:4
正确答案应该是19，这个答案是18
失误失误，转载错了。已经改正，抱歉。
对于第一题，我的直觉告诉我换不换都一样，求指教


The web
Web applications:Focus of this course.
Http:Protocol the web runs on.
Major pieces of the web http
user-->Computer+Browser-->Interwebs-->servers-->internet
Urls:How to refer to articles.
Html:Hypertext markup language.
The documents we see on the web.
About thirty billion pages exist.
Text content:What you see
Markup:What it looks like and how it is arranged.
References to other documents (Pictures and videos.Digital media.)
Links: To other pages.
Element: Made up of an opening tag, contents, and a closing tag.
Inline
<name> contents </name>
 contents  = Bold.
 contents  = Italics
 = Anchor.
Aristophenes

contents Kind of bold?

 No closing tag.
 Images. void tag

Block

 = paragraph
<form></form>
HTML Documents.
<!Doctype HTML> = Doctype. In html 5 it is easy to read.
 Doc code starts.
meta data - java-
<title> Title! </title> title on top of the web-browser.

Content
 Interesting stuff
 Doc code ends


| 0x02 [...]
| Unsigned integer, compose value from 7 bits of each following byte until leading 8th bit equals 0.
|
| 0x0201 == 00000010 00000001 == 1
|
| 0x027f == 00000010 01111111 == 127
|
| 0x028101 == 00000010 10000001 00000001 == 1 + (1 << 7) == 129
|
| 0x02a1b22a == 00000010 10100001 10110010 00101010 == 33 + (98 << 7) + (42 << 14) == 44052769
|
| 0x03 [length] [...]
| Container of [length] Booleans
|
| 0x05 [length] [...]
| String, a container of [length] bytes
|
| 0x09
| RGBA component
|
| 0x0B [...] 0x00
| String, usually NULL-terminated, i.e. read bytes until 0x00.
|
| 0x0f
| Pair (tuple of two objects)
|
| 0x10
| Triplet (tuple of three objects)
|
| 0x15 [length]
| Array of strings
|
| 0x16 [length]
| Container of objects
|
| 0x18
| Control state
|
| 0x1b [12 bytes]
| Unit
|
| 0x1e [length] [...]
| String (identical to 0x05)
|
| 0x1f [number]
| String reference
|
| 0x24 [36 bytes]
| UUID
|
| 0x64
| empty node
|
| 0x65
| empty string
|
| 0x66
| Number 0
|
| 0x67
| Boolean true
|
| 0x68
| Boolean false
|
| 0xff01
| ViewState preamble
|


SOFARPC provides a variety of calling types under the Bolt protocol to meet different scenarios.
Synchronous
In the synchronous calling type, after the client initiates a call, it will wait for the server to return the result and then perform subsequent operations. This is the default calling type of SOFARPC.
Asynchronous
In the asynchronous calling type, after the client initiates a call, it will not wait for the result from the server but continue to execute the subsequent business logic. The result returned by the server will be cached by SOFARPC. When the client needs the result, it can call the API to get the result. To set a service to be asynchronous, you can configure the type
attribute in the corresponding usage mode:
XML
In the XML mode, set the type
attribute of the <sofa:global-attrs>
tag to future
:
<sofa:reference interface="com.example.demo.SampleService" id="sampleService">
<sofa:binding.bolt>
<sofa:global-attrs type="future"/>
</sofa:binding.bolt>
</sofa:reference>
Annotation
In Annotation mode, set the invokeType
attribute of @SofaReferenceBinding
to future
:
@SofaReference(binding = @SofaReferenceBinding(bindingType = "bolt", invokeType = "future"))
private SampleService sampleService;
API in Spring environment
When using the API in Spring environment, you just need to set the type
attribute of BoltBindingParam
:
BoltBindingParam boltBindingParam = new BoltBindingParam();
boltBindingParam.setType("future");
API in non-Spring environment
When using the bare API of SOFARPC in a non-Spring environment, you just need to set the invokeType
attribute of ConsumerConfig
:
ConsumerConfig<SampleService> consumerConfig = new ConsumerConfig<SampleService>()
.setInterfaceId(SampleService.class.getName())
.setRegistry(registryConfig)
.setProtocol("bolt")
.setInvokeType("future");
Get the calling result
Currently, there are two ways to get the result of an asynchronous call:
Get result directly
You can directly get the result of an asynchronous call in the following way:
String result = (String)SofaResponseFuture.getResponse(0, true);
The first parameter is the timeout period for getting the result, and the second parameter indicates whether to clear the result in the thread context.
Get JDK native Future
You can get the JDK native Future object in the following way, and then call the Future object from anywhere to get the result:
Future future = SofaResponseFuture.getFuture(true);
The first parameter indicates whether to clear the result in the thread context.
Callback
By using the callback type of the SOFARPC Bolt protocol, SOFARPC doesn’t need to wait for the result after initiating a call. After the client receives the result returned from the server, it can automatically call back a callback interface implemented by the user.
To use the callback type of the SOFARPC Bolt protocol, you first need to implement a callback interface, and set the callback interface in the corresponding configuration, and then set the calling type to callback
.
Implement callback interface
SOFARPC provides a callback interface com.alipay.sofa.rpc.core.invoke.SofaResponseCallback
, which you needs to first implement in order to use the callback type of SOFARPC Bolt protocol.
Set the callback interface
After implementing the callback interface, you need to set the implementation class in the corresponding service reference configuration and set the calling type to callback.
SOFARPC provides two ways to set the callback interface, namely Callback Class
and Callback Ref
. Callback Class directly sets the class name of the callback, and SOFARPC generates an instance of the callback class by calling the default constructor of the callback class. While Callback Ref is to directly provide the instance of the callback class.
XML
If the service is referenced via XML, set the type
attribute of the <sofa:global-attrs>
tag to callback
and set the callback-ref
or callback-class
attribute:
<bean id="sampleCallback" class="com.example.demo.SampleCallback"/>
<sofa:reference interface="com.example.demo.SampleService" id="sampleService">
<sofa:binding.bolt>
<sofa:global-attrs type="callback" callback-ref="sampleCallback"/>
</sofa:binding.bolt>
</sofa:reference>
In the XML mode, the value of callback-ref
should be the bean name of the callback class.
Annotation
If the service is referenced via Annotation, set the invokeType
attribute of the @SofaReferenceBinding
annotation to callback
and set the callbackClass
or callbackRef
attribute:
@SofaReference(binding = @SofaReferenceBinding(bindingType = "bolt",
invokeType = "callback",
callbackRef = "sampleCallback"))
private SampleService sampleService;
In the Annotation mode, the value of the callbackRef
should be the bean name of the callback class.
API in Spring Environment
If you use the API in Spring or Spring Boot environment, set the type
attribute of BoltBindingParam
to callback
and set the callbackClass
or callbackRef
attribute:
BoltBindingParam boltBindingParam = new BoltBindingParam();
boltBindingParam.setType("callback");
boltBindingParam.setCallbackClass("com.example.demo.SampleCallback");
API in non-Spring environment
If you use SOFARPC bare API in non-Spring environment, call setInvokeType
to set the type to callback
and call setOnReturn
to set the callback class:
ConsumerConfig<SampleService> consumerConfig = new ConsumerConfig<SampleService>()
.setInterfaceId(SampleService.class.getName())
.setRegistry(registryConfig)
.setProtocol("bolt")
.setInvokeType("callback")
.setOnReturn(new SampleCallback());
Set the callback interface at call level
In addition to setting the callback interface at service level, you can also set the callback interface at call level, as follows:
RpcInvokeContext.getContext().setResponseCallback(new SampleCallback());
Oneway
When the client does not care about the result returned from the server after sending the request, it can use the oneway calling type. In this type, null is returned immediately after the call is initiated, and the client ignores the result returned from the server.
To use the oneway type, you only need to set the calling type to oneway
, which is the same as setting the calling type to future
or callback
. You can refer to the preceding settings.
Note: Since the oneway calling type returns immediately, all timeout settings are invalid in the case of oneway.


{{page.title}}
Sign In
{% include toc.html %}
{{content}}
This page is restricted. Please sign in to view.


The predicates described in this section store arbitrary terms in a per-module repository known as the “blackboard”. The main purpose of the blackboard was initially to provide a means for communication between branches executing in parallel, but the blackboard works equally well during sequential execution. The blackboard implements a mapping from keys to values. Keys are restricted to being atoms or small integers, whereas values are arbitrary terms. In contrast to the predicates described in the previous sections, a given key can map to at most a single term.
Each Prolog module maintains its own blackboard, so as to avoid name clashes if different modules happen to use the same keys. The “key” arguments of these predicates are subject to module name expansion, so the module name does not have to be explicitly given unless multiple Prolog modules are supposed to share a single blackboard.
The predicates below implement atomic blackboard actions.
bb_put(
:Key,
+Term)
bb_get(
:Key,
?Term)
bb_get/2
silently
fails.
bb_delete(
:Key,
?Term)
bb_delete/2
silently fails.
bb_update(
:Key,
?OldTerm,
?NewTerm)
bb_update/3
silently fails. This
predicate provides an atomic swap operation.
Please note:
If the term being stored contains attributed variables
(see lib-atts) or suspended goals (see ref-sem-sec),
those attributes are not stored. To retain the
attributes, you can use copy_term/3
(see ref-lte-cpt).
The following example illustrates how these primitives may be used to
implement a “maxof” predicate that finds the maximum value
computed by some nondeterminate goal. We use a single key max
.
We assume that Goal does not produce any “false” solutions that
would be eliminated by cuts in a sequential execution. Thus,
Goal may need to include redundant checks to ensure that its
solutions are valid, as discussed above.
maxof(Value, Goal, _) :- bb_put(max, -1), % initialize max-so-far call(Goal), update_max(Value), fail. maxof(_, _, Max) :- bb_delete(max, Max), Max > 1. update_max(New):- bb_get(max, Old), compare(C, Old, New), update_max(C, Old, New). update_max(<, Old, New) :- bb_update(max, Old, New). update_max(=, _, _). update_max(>, _, _).


Logistic managment of warehouse resources and flows
Date: 03-04.09.2015
Leadersphip at Peek and Cloppenburg
15-16.04.2014
Curriculum Vitae
Experience
I am passionate manager with over twelve years of professional experience.
Always eager to gain new experience and not afraid of hard work.
I am currently looking for new opportunities and development in IT field.
Deputy Warhouse Manager -
IzoBlok S.A.
05.2014 - present
optimization and cost reduction,
recruitment and managment of over 60 employess,
organization, control and responsibility of deliveries and warehouse stock,
implementation of deliveries according to the guidelines and expectations of the customers,
communication and cooperation with other departments in company, mostly with: logistic, production, quality,
HR, research and development.
Internal Logistic Manager -
Peek and Cloppenburg
05.2013 - 05.2014
comprehensive warehouse management and development of storage space,
analysis of the efficiency of warehouse and logistic processes,
responsibility for internal and external logistics in company,
internal transport management,
close cooperation with the sales department.
Floor Manager - TK Maxx
01.2011 - 05.2013
keeping high standards in terms of sales,
effective teamwork planning (over 40 employess),
preparing documentations and reports,
taking care of labor law and safety rules,
establishing optimal layout and visual presentation of the shop floor to ensure best financial result.
Store Manager - LPP S.A.
10.2005 - 12.2010
manage and direct own business in cooperation with the employer,
comprehensive salon management according to company standards,
realization of sales and loss goals,
take care of the positive image of the company and products,


Minimalism is a tool that can assist you in finding freedom. Freedom from fear. Freedom from worry. Freedom from overwhelm. Freedom from guilt. Freedom from depression.


Note: I have no monetary interest in any of the recommended apps, sites, and services below. Many of them I pay for and use myself.
There has been a substantial leak of credentials (email address and password combinations) on the internet this week (2019/01/18). A large collection of credential stuffing lists (combinations of email addresses and passwords used to hijack accounts on other services) was discovered being distributed on a popular hacking forum. The data contained almost 2.7 billion records including 773 million unique email addresses alongside passwords those addresses had used on other breached services.
As one of my old (thankfully retired) passwords and my email address was one of the leaks, I thought it would be a good time to share not just some information on good password management practices, but also some tools that I personally use to maintain good password security protocols.
Use cryptographically strong (read: hard to guess) passwords
There are a few popular methods out there for creating hard to guess passwords.
A good explanation of what has come to be called the “Correct Horse Battery Staple” method was explained in comic form by internet comic publisher Randall Monroe better than I can explain it!
In essence, a random selection of common words combined together can be easy to remember but hard for machines to break. In this way, we stop thinking about them as passwords and more passphrases. Long passphrases equal more entropy, which results in machines taking much longer to crack them while reducing the risk of somebody else also having the same password!
This method is especially useful for securing your “digital fortress”, for example your Google or Apple account or even your password vault itself.
The most secure password is one you can’t remember
The above method is great for one or two sites, but like me you have probably registered to hundreds or even thousands of sites over the years. How can you possibly remember all of them?
Answer: don’t!
There are many good options for generating cryptographically strong passwords and storing them in an easy to use way, that never exposes you to the guts of actually generating and storing a good password.
Many modern operating systems such as MacOS, iOS, and Android (chrome specific) ship with built-in support for generating and storing passwords for websites and applications. These passwords are securely shared across your devices and synced to a cloud storage location for backup.
-
iCloud Keychain (MacOS and iOS native functionality, works in browsers and apps)
-
Google password manager (Cross platform but Chrome specific and cloud synchronised)
-
Firefox (Cross platform but specific to the Firefox browser)
You’ll notice all of these are platform or browser specific (iCloud Keychain for example is locked to Apple products, which is a shame because in my opinion it’s by far the easiest to use), but thankfully there are other options.
My recommendation for providing secure password vaults in a cross-platform way is 1Password.
There are a few options available, a free solution that leaves the concern of backing up and device sharing to you, or a built-in cloud option for a couple of pounds/dollars a month. I personally recommend this option.
Generating a strong password with 1Password
Highlighted in blue above you’ll see an example of the strong passwords that are automatically generated for you, on a per-site or per-app basis. These passwords are hard to remember, hard to crack, and unique.
Where 1Password really shines is the integrations it has with browsers and operating systems.
Pairing this sort of method with the “Correct Horse Battery Staple” method gives a very strong password security protocol while only requiring you to remember one single password:
-
A single, strong, easy to remember password for your password vault
-
All other passwords generated and stored in your password vault
Further reading: The Only Secure Password Is One You Can’t Remember
Don’t re-use passwords across services
This goes without say, but each site you enter a password into is a potential risk for you later. If you re-use a password a lot or use a common password (Link 1 / Link 2) and one of the sites you are registered for is hacked or your common password shows up in a list, you are instantly vulnerable on all other sites that share that password and email combination.
Use two-factor authentication where possible
Two-factor authentication is an extra layer of security for your various accounts designed to ensure that you’re the only person who can access your account, even if someone knows your password.
In 2019, most sites that matter have some form of two-factor authentication and I strongly suggest you use wherever possible, especially on your email account, banking, or e-commerce sites such as Amazon.
This link outlines simply how Apple achieves two-factor authentication, but the principle is the same almost everywhere.
Most two-factor authentication systems use:
-
Text/phone calls with unique codes to trusted phone numbers
-
An app such as Google Authenticator or Authy to generate expiring tokens
While there is some discussion about the security of text/phone calls (specifically around the risk of cloned numbers/SIM cards), ultimately it doesn’t strictly matter how you are doing it, just that you should be doing it.
And if someone is trying to access your life by cloning your phone… you’ve probably got bigger concerns anyway.
As a top tip, if you are currently using Google Authenticator for anything (or get prompted to when you’re definitely following my advice and setting up two-factor auth for your accounts) I recommend swapping to Authy. It’s a drop-in replacement that doesn’t require resetting your accounts if you swap or lose your phone/device.
Be proactive, not reactive
When a breach happens, you cannot count on the mainstream media to report it or even for the company that was breached to tell you about it. Here is where I recommend taking matters into your own hands.
Thankfully, some security conscious and very smart people have set up an excellent website for tracking every single breach, not just the high-profile ones.
Have I Been Pwned
The number of accounts Have I Been Pwned tracks is now over 6 billion and growing every day. It has various tools for checking whether your account or specific passwords have been leaked:
Take it one step further, and sign up to be notified when your email is found in a new leak by clicking “Notify me” in the header and registering your email address. It’s free and completely secure – I have registered and I’ve been notified each time my email has appeared in a leak or password dump.
And for the ultimate in security, integrate Have I Been Pwned with 1Password and get notified on a per password basis if your password is compromised using a feature in 1Password called Watchtower.
More information about what makes that process secure is found at the above link.
–
Full details on the incident and more information on how to search the breached passwords are provided in the blog post The 773 Million Record “Collection #1” Data Breach.
For more information, please re-read this blog post.
© 1974 Scarfolk Council.
Mistakes? Inaccuracies? Typos?
Please let me know if you find anything factually incorrect in this blog post by submitting an issue.
Alternatively, amend the document directly and create a pull request with the necessary changes.


--- title: "Overview" type: docs menu: main: name: "Overview" identifier: "installation-gpu-quick" parent: "installation-gpu" weight: 10 aliases: - /tools/gpu.html ---
It’s highly recommended, although not strictly necessary, that you run deep-learning code on a modern NVIDIA GPU. Some applications – in particular, image processing with convolutional networks and sequence processing with recurrent neural networks – will be excruciatingly slow on CPU, even a fast multicore CPU. And even for applications that can realistically be run on CPU, you’ll generally see speed increase by a factor or 5 or 10 by using a modern GPU.
If your local workstation doesn’t already have a GPU that you can use for deep learning (a recent, high-end NVIDIA GPU), then running deep learning experiments in the cloud is a simple, low-cost way for you to get started without having to buy any additional hardware. See the documentation below for details on using both local and cloud GPUs.
| Local GPU |
For systems that have a recent, high-end NVIDIA® GPU, TensorFlow is available in a GPU version that takes advantage of the CUDA and cuDNN libraries to accelerate training performance. Note that the GPU version of TensorFlow is currently only supported on Windows and Linux (there is no GPU version available for Mac OS X since NVIDIA GPUs are not commonly available on that platform). |
| CloudML |
Google CloudML is a managed service that provides on-demand access to training on GPUs, including the new Tesla P100 GPUs from NVIDIA. CloudML also provides hyperparameter tuning to optmize key attributes of model architectures in order to maximize predictive accuracy. |
| Cloud Server |
Cloud server instances with GPUs are available from services like Amazon EC2 and Google Compute Engine. You can use RStudio Server on these instances, making the development experience nearly identical to working locally. |
| Cloud Desktop |
Virtual cloud desktops with GPUs are available from Paperspace. This provides an Ubuntu 16.04 desktop environment that you can access entirely within a web browser (note that this requires a reasonbly fast internet connection to be usable). |


December 27, 2015
Stop and smell the coding roses.
The full post title should really read: CURL: A Reminder to Look Stuff Up (Even if It’s Not Directly Pertinent to Your Immediate Objective).
I recently started a new job and was setting up my development environment on my new computer. I found myself using the curl command often to install various programs.
Side note: this post could also be titled The Benefits of a Calm and Organized Work Environment.
I took a moment to stop and read a little about exactly what the curl command did to refresh my memory (having briefly visited the topic when examining APIs in an earlier post).
Long story short, the curl command acts as a client sending an HTTP request that contains a method (like GET, POST, HEAD, etc.) to a server to retrieve info.
So, for example, when you type curl http://curl.haxx.se
into your command line, you will get all of the HTML for that particular page show up in your terminal.
Equally important, in my searches I came across a really great page providing for not only background info on curl but on HTTP scripting as well. A ton of great reading can be found on the curl.haxx.se site including:


In programming, you'll inevitably come across classes. Classes are a foundational solution for essentially any software. Let's look at an example of a class that we'll build, which we'll call Glasses.
We all know what glasses are--the ones you wear so you can see better. In programming we take real-life scenarios and model them with terminology. With classes there are things that we know and things we can do.
What do we know about glasses?
- The frames have a color.
- The lenses have a prescription.
The things we know about the class we usually let the user specify. We can store that information within variables in the class.
Let's look at how we would set this up and then explain what is happening in each line of code
In line 1 we define our class Glasses that essentially says everything in the next block will belong to our class. We could have named it anything that we liked, but since the objects that we will be building from this will model what we know as glasses, we'll keep the name this way.
Line 2 contains some important information. We specify what the user must input to initialize, or create, an instance of this object. We expect three arguments from the user--the frame color, the left eye prescription, and the right eye prescription. An example of what someone would input is below.
Notice that there are three arguments to match what we defined in our initialize component of our class.
Once we defined our class, we set instance variables. These instance variables are stored within the entire class of Glasses. You'll notice that we have @frame_color and frame_color. The variable @frame_color will be accessible in other methods in our class, whereas frame_color is only accessible within initialize. Since I may want to know each of those pieces of information later, I'm going to store them as instance variables so they will be accessible later. I also created an additional variable, days, which we will use to track how many days we have worn the glasses.
What can we do with glasses?
- Wear them.
- Clean them.
- Replace the lenses.
We can take each of these things and make instance methods to model these actions. Instance methods are methods that can be called on an instance of an object. Let's look at an example.
Below I've written the code for a few instance methods. Notice that for wear I increment the number of days it has been, for clean I reset it to 0, and replace we have the chance to change the values of our instance variables @left_eye and @right_eye.
If we go to our terminal and use the IRB, after inputing the method in, we can test our code. Notice in the terminal how we can see we are calling the instance methods on the object that we defined.
However, if we were to try to call that same method wear on something that is not an instance of our class Glasses, we will receive an error.
Thus these methods are only accessible to the class that we define, which makes sense since we don't wear the number 3.
This should cover the core components of defining a class, intializing a class, defining instance variables, and the instance methods within the class. Hopefully this makes sense!


5.6 APA Sections of the Paper
6. Abstract (APA style)
The abstract follows APA style and typically completed in the spring of the second semester. A draft of the abstract, without results and without concluding statements, might be drafted during PSYC 565 Research Practicum during the of the second year.
7. Introduction (APA style)
As noted in the section “Literature Review Timeline,” the introduction is drafted during the first semester of the first year in PSYC 564 and revised every semester of the year. The introduction is a comprehensive document that demonstrates the students’ expertise in the area under study.
8. Method (APA style)
As noted in the “Method Section Timeline,” portions of the Method section can be drafted during the spring semester and finalized during PSYC 565 in the fall of the second year. The method section defines the procedures of the study and is required for successful IRB approval at CLU. IRB is accomplished during PSYC 565 in the of the second year but students should review CLU IRB requirements as soon as possible. A link to the CLU IRB can be found here: https://www.callutheran.edu/research/irb/.
9. Data Analytic Method (APA style)
The data analytic plan can be developed during PSYC 562 in the spring of the first year and finalized during PSYC 565 in the of the second year. At CLU, we exclusively use the statistical program language called R. The data analytic section will include a power analysis as well a link to the study’s pre-registration of the data analysis.
10. Results (APA style)
The results are typically drafted during the spring of second year. PSYC 566 Thesis is an independent study unit and there are no class meetings. Instead, students meet with their thesis chair to review and write their analyses in the results section.
11. Discussion (APA style)
The discussion is a critical section of the research paper and is typically 10-pages minimum. In the discussion the student provide the following:
- A summary of the proposed hypotheses and rationale.
- A review of the results in narrative form without the presentation of any statistics.
- A discussion of the implications of the results for each hypothesis.
- A discussion of future steps for each hypothesis.
- A discussion of the limitations of the study in addressing each hypothesis.
The discussion section demonstrates the student’s ability to place their study in the context of the larger literature and think more philosophically. It is a space for creativity and ingenuity.
12. References (APA style)
13. Tables (APA style)
14. Figures (APA style)
15. Appendix 1 - Pre-Registration
16. Appendix 2 - IRB Approval
17. Appendix # - optional as needed


Thermostat Controls using ARIA Sliders
Change sliders to set values for setting a vertical temperature, fan speed and heat/air conditioning. The examples also use aria-valuetext
property.
Vertical Slider Example
Slider Examples using using aria-valuetext
Keyboard Support
| Key | Function |
|---|---|
| Right and Up Arrow | Increase slide value by increment value |
| Left and Down Arrow | Decrease slide value by increment value |
| Page Up Arrow (temperature slider only) |
Increase slide value by jump value |
| Page Down Arrow (temperature slider only) |
Decrease slide value by jump value |
| Home | Set slider to minimum value |
| End | Set slider to maximum value |
ARIA Roles, Properties and States
| Role | Property/State | Component | Usage |
|---|---|---|---|
| slider | thumb | Identify the widget as a slider | |
| aria-orientation | thumb | Indicates the orientation of the slider is "vertical" for the temperature slider or "horizontal" for the fan and temperature controls | |
| aria-valuemax | thumb | Maximum value of the slider | |
| aria-valuemin | thumb | Minimum value of the slider | |
| aria-valuenow | thumb | Current value of the slider | |
| aria-valuetext | thumb | The value of the temperature slider appended with the text "degrees" or one of the text values | |
| aria-labelledby | thumb | Reference to define a unique descriptive accessible name for each slider widget |
Source Code
Temperature Slider
- CSS: vertical-slider.css
- Javascript: vertical-slider.js
Fan/Heat Sliders
- CSS: text-slider.css
- Javascript: text-slider.js


This example shows how tokenization works when the form is completely
rendered by the host application and the host application just uses
the tokenization API. This is a good option for developers that want
fine grained control of the UX, but leaves merchants in SAQ A-EP PCI scope.


Enumerables for Noobs
Or, "OMFG, this exists??? YES YES YES YES YES!!!!!!!"
November 22, 2015
Ah, the Enumerable map method!
Erm, not exactly.
There we go!
When I first heard about the Enumerable class, I was frightened. The word was weird, it only kind of made sense...and then when I checked out the documentation there were words like "mix-ins" and exclamation points all over the place. I was completely disoriented and kept my distance.
Until Dev Bootcamp forced me to go back.
HOLY CRAP, you guys. Enumerables will enhance your life in ways you could not have imagined. I'm not saying they will fill up your gas tank or walk your dog, but these methods are built on the assumption of iteration across a data collection, and there is a wonderful diversity of methods to choose from that can meet many of your programming needs.
I chose to explain the .map method for this assignment, because it seems to be powerful and frequently used. I wanted to really understand it.
Here is the documentation for .map:
There is some great information here. Map, unlike other enumerable methods, will always return an array (that's what the --> array after the gibberish at the top means). This array will contain the same number of elements as the original object the method was passed to. (Scroll back up to see that picture with the rubber band--the original object had 4 elements, and the returned object also has 4. The objects are different, but they are still all present, and in their original order. They've each been manipulated in exactly the same way.)
Map will execute a given code block on each of the elements in the original object. So, in the rubber band graphic, each object is being "stretched", one after the other as map moves through the object. You can see that the returned object contains horizantally skewed versions of the original elements.
So, what's the difference between map and each? The answer lies in the return value of the two methods. Each returns the object that it is called on, in it's original form.
Here I've run each on my_array with the code block x.upcase. The return value of this method is the last line, after the =>. Even though .each *did* move through my_array and apply .upcase to each object, the ultimate return value of the method is my_array. Now look what happens when we use .map instead:
.map returned a new array, that contains all the original elements, in order, that were transformed by the code block. However, the original my_array still exists!
So, while each will temporarily transform each element of an object, it ultimately returns itself. Those changes aren't saved. Map will create a new array, and store all the transformed elements in there, in order. Map returns that array. This is handy for when you need to transform the elements an object and keep the results!
I hope this little explanation of map was helpful!


Antenna
Antennas are used to catch signal for wireless devices. There are different forms of antenna depends on whether it is for TV, radio, internet connection and etc.
Chanmyoung Park
Antennas are used to catch signal for wireless devices. There are different forms of antenna depends on whether it is for TV, radio, internet connection and etc.


OpenForTesting()
Annotate a class with OpenForTesting if you want it to be extendable in debug builds.


This week was pretty frustrating. I spent all of it trying to get pagination to work, to no avail. I switched libraries several times and tried every possible combination of the jQuery UI Dialog/Bootstrap popover with "Sweet Pages"/Bootstrap pagination.
There were multiple problems with each solution I attempted. I liked the look of Sweet Pages, and it was one of the few pagination solutions I could find online that you didn't have to hack to make it paginate within a div. However, trying to integrate it with a dialog/popover completely trashed it because the different panels wouldn't line up right and the special CSS it needed messed up everything (and I don't have the CSS skills to fix it). After going back and forth with different libraries, I ended up deciding to do an all-Bootstrap solution, which still doesn't work completely but I'm sticking with it.
The current iteration of my solution uses a pagination script based on this example. Right now Tianyi is working on helping me debug it; the problem is that the script doesn't recognize when the buttons are clicked, so a pagination-button click just defaults to sending the user to the top of the page.
Update: We've just discovered that the script is not being injected correctly into the page, so it only runs once and then it doesn't run again, which is why it doesn't register mouse-clicks. So now I need to rework how I'm injecting the script into the StackOverflow page.
Tianyi has been really helpful with this issue in more ways than one. I was feeling frustrated with my solutions not working, but he reminded me in an email that finding that something isn't working is progress -- and part of research. So I've been learning through this episode to take issues like this in stride and not to get too stressed about feeling "held back" when it takes awhile to find a working solution for a problem. I've also been learning a lot about Chrome extension development!
I'm taking this coming week off to go to Texas for my friend's wedding, but when I get back I'll work on fixing this pagination problem and move on. Our next step is to have the extension read test data and create popups based on that, I think. I'll be discussing it in more detail with Tianyi when I get back, so more on that next week! For now, here is the current look of the extension using the Bootstrap popover instead of the jQuery UI Dialog (and Bootstrap pagination without nice CSS -- I'll fix that):


#include <stDFTree.h>
Public Types | |
| typedef stDFLogicNode< ObjectType, EvaluatorType > | tLogicNode |
| typedef stDFMSTSplitter< ObjectType, EvaluatorType > | tMSTSplitter |
Public Member Functions | |
| void | FindGlobalRep (tLogicNode *logicNode, tMSTSplitter *MSTSplitter, stCount center1, stCount center2, stCount numObject) |
| stDFGlobalRep (stCount nFocus, stDistance pThreshold, EvaluatorType *metricEvaluator) | |
| bool | FirstSplit () |
| void | SetFirstSplit () |
| void | SetFieldDistance (stDFLeafNode *node, stCount idx, ObjectType *object) |
| void | SetFieldDistance (stDFIndexNode *node, stCount idx, ObjectType *object) |
| void | BuildFieldDistance (ObjectType *object, stDistance *fieldDistance) |
| bool | PruneByGlobalRep (stDistance *objGRCoord, stDistance radius, stDistance *distQueryFocus, stDistance queryRadius) |
| void | CheckUpdate (stPageManager *pageman, stPageID rootPageID, stDistance *fieldDistance) |
| void | GetCandidates (stPageManager *pageman, stPageID pageID, vector< ObjectType * > &candidateSet) |
| void | UpdateGR (vector< ObjectType * > candidateSet) |
| void | UpdateFieldDistance (stPageManager *pageman, stPageID pageID) |
Public Attributes | |
| stCount | NumFocus |
Joselene Marques<EMAIL_ADDRESS>Definition at line 1612 of file stDFTree.h.
|
|
This type defines the logic node for this class. Definition at line 1619 of file stDFTree.h. |
|
|
This type defines the MST splitter for this class. Definition at line 1624 of file stDFTree.h. |
|
|
Builds a new instance of this class.
|
|
|
Calculate the GR Distances of a given object.
|
|
|
Detect when to update de GR and update the accumulated number of new uncircumbscribed objects(Uncircumbscribed)
|
|
|
Find the GR.
|
|
|
Definition at line 1666 of file stDFTree.h. |
|
|
Executed when the CheckUpdate triggers, add uncircumscribed objects to Candidade Set of new Focus
|
|
|
Defines if the subtree must be pruned by GR
|
|
|
Calculate the GR Distances of a given index node.
|
|
|
Calculate the GR Distances of a given Leaf node.
|
|
|
Definition at line 1673 of file stDFTree.h. |
|
|
Update the GR Distances to all objects
|
|
|
Executed when the CheckUpdate triggers, find new GR.
|
|
|
Number of focus. Definition at line 1629 of file stDFTree.h. |


Sheet1
Supply,Latest Price in KMD,HODL 10%,Value in KMD,24 HODL,KMD value
BOTS,1000000,1.27,100000,127000,0.3048,17.76677
REVS,1300000,0.48,130000,62400,0.14976
MSHARK,1400000,5.02,140000,702800,1.68672
DEX,1000000,9.07,100000,907000,2.1768
CRYPTO,1000000,8.49,100000,849000,...


To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set.
Set the "Secure" flag on all sensitive cookies to protect the contents of the sensitive cookies from eavesdropping attacks. Setting the "Secure" flag on sensitive cookies ensures they are only transferred over connections that are secured by TLS. The "HTTPOnly" flag prevents the contents of the marked cookie from being accessed by client-side script - this measure helps reduce the potential damage of Cross-Site Scripting attacks.
To set the "Secure" and "HTTPOnly" flags on all sensitive cookies:
Verify that TLS is available. The "Secure" flag forces cookies to be sent over TLS. TLS has to be available for this to work.
Identify sensitive cookies. Session cookies should always be considered sensitive. Enumerate all cookies used by the application. Make a list of cookies that may contain sensitive information.
Identify code that creates sensitive cookies. For each sensitive cookie in the list, find the code that creates that cookie.
Set the "Secure" and "HTTPOnly" flags for each sensitive cookie. For each piece of code that creates a sensitive cookie, add code that sets the "Secure" and "HTTPOnly" flags for the cookie. Make sure, that when the Secure attribute is set for a cookie, it is in response to a request that was made over HTTPS and not HTTP.
Configure the platform. Many platform have configuration options that allow setting the "Secure" and "HTTPOnly" flags for session cookies. Please refer to your platform's documentation for information about whether this functionality is available and how to use it.


Learn how to code with HTML.
Css code can be transferred into HTML using various types of coding, such as changing the colour of the text that is placed in, changing the header size, or the font of the text itself.
Read MoreInternal CSS using HTML code can quickly determine the general styling of the page, it does this by style element in the head section, it is usually used as to keep the styling of the page the same.
Read MoreThe Picture above (Will be added in later on) is an exampel of how someone might lay out a box model, they are usually spread out into 4 different segments. Margin - This clears up the area around the box, so that nothing crashes into it. Border - It protects the padding and the content. Padding - Similar to the Margin, accept it clears an area around the content to avoid it clashing into the border. Content - The main content of the box, where the images and text will appear on a website.
Javascript is one of the scripting languages that can interact with the HTML code of a website, because it is so common, all browsers together support Javascript because it used in almost all websites. It is even useful for even fixing issues within the CSS and prevent page reloads and build highly responsive user interfaces.


# Beyond Hindley Milner with Bidirectional Type Theories
## Motivation - Why look at type theories
## What is Hindley Milner - Type system behind ML family - All synthesis - Annotations act like tests or comments - Algorithm W
## Specific features - 'Principal types' - GADTs - Parametric polymorphism - Pattern matching
## Example ``` data List x = Cons x (List x) | Nil map (Cons x y) f = Cons (f x) (map y f) map Nil f = Nil ```
## Equivalently ``` data List x = Cons x (List x) | Nil map list f = match list of case (Cons x y) → Cons (f x) (map y f) case Nil → Nil ```
## Synthesised ``` map: ∀x.∀y. List x → (x → y) → List y ```
## Elegant - Very few rules required - Very few syntactic forms required - Only one context required - Linear time
## Issues - Quantifiers in Type Schemes, not in Types - Prenex polymorphism - Monomorphization - Let polymorphism
## More Issues - Modules - Have to add on modules in add hoc ways - Then get types as values in even more ad hoc ways - Relatedly, treatment of Existentials - Functors should just be functions
## More Issues - Higher kinded types - Higher sorted kinds - Universes
## More More issues - Dependant Types - Linear Types, Graded Modal Types... - Not extendable without exploding
## Bidirectional Type Theory - Broadly - 'Both directions' - Two (or more) kinds of judgements: checking and synthesis - Introductions vs Eliminations - Have to introduce more rules - Also have to introduce some kind of output context or stack
## Local reasoning - implicitly - Local Type Inference, Pierce and Turner 2000 - Use a constraint solver locally - Introduction forms for literal need no additional annotation
## Local reasoning - explicitly - Extra layer of annotation of Elimination and Introduction forms - Introducing 'goals'
## 'Locality' - Smallness - Detemining mode is Syntactic - Change of direction - Non-immediate introduction forms
## A way around 'principal types' - Intersection types - From nondeterministic ∧Elimx "The whole point of an intersection type discipline is to allow ascribing many types to the same term." - Bidirectional Typing, Joshua Dunfield and Neel Krishnaswami 2019
## Direction - 'Mode' from logic programming - Syntax directed - Boxy Types - Interleaving - Eager vs Lazy vs Greedy (with subtyping) - Subsumption rule - direction change for subtyping
## Complexity - Intersection and union types - Requiring Introduction forms to be annotated - No types can come 'out of nowhere'
## Extensions from core - Are more tractable - Rules naturally more modular - Introduce more modes - Limit interactions by confining direction, locality
## Functional modules ``` map: ∀container: (type→type). ∀x. ∀y. (container x) → (x → y) → (container y). ```
## Functional modules ``` map: ∀container: (type→type) and container is mappable. ∀x. ∀y. (container x) → (x → y) → (container y). ```
## Functional modules ``` map: ∀container:(type→type). ∃mapFn∋mappable container. mapFn. map {mapFn} = mapFn data List x = Cons x (List x) | Nil mapList (Cons x y) f = Cons (f x) (map y f) mapList Nil f = Nil mappable: ∀container:(type→type). ∀x.∀y.∃map∋((container x) → (x → y) → (container y)). container → map mappable {map} container = map implicit mappableList = mappable {mapList} List ```
## Extension - For example, adding linear function space - Add a mode: Application - Add Introduction rules for ⊸ - Stack effect


---
layout: default
title: Douglas Duhaime | Data Mining + Visualization
---
{{ site.name }}
Full Stack Developer in Yale University's Digital Humanities Lab.
{% assign posts = site.records | sort: 'date' | reverse %}
{% for post in posts %}
{% if post.categories contains 'posts' and post.thumbnail and post.displayed != false %}


Another post
March 13, 2017
This is just another post. See how to include data inside your posts:
Beatles Discography
-
{% for album in site.data.beatles %}
- {{ album.Name }} (released on {{ album.Released }}) {% endfor %}
March 13, 2017
This is just another post. See how to include data inside your posts:


Copyright © 2013 W3C® (MIT, ERCIM, Keio, Beihang), All Rights Reserved. W3C liability, trademark and document use rules apply.
This is an introduction to Model-Based User Interfaces covering the benefits and shortcomings of the model-based approach, a collection of use cases, and terminology.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document was published by the MBUI working group and is being published to complement the specifications on Task Models and Abstract User Interfaces, which seek to define a basis for interoperable interchange of user interface designs between different tools at design-time and at run-time. If you wish to make comments regarding this document, please send them to<EMAIL_ADDRESS>(subscribe, archives). All comments are welcome.
Publication as a Working Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
The development of user interfaces (UIs), ranging from early requirements to software obsolescence, has become a time-consuming and costly process. Typically, the graphical user interface (GUI) of an interactive system represents about 48% of the source code, requires about 45% of the development time and 50% of the implementation time, and covers 37% of the maintenance time (Myers and Rosson, 1992). These figures, evaluated in the early nineties, are increasing dramatically with the spread of new interaction techniques such as vocal and gestural modalities, resulting in additional requirements (Petrasch, 2007).
Figure 1. Distribution of UI development effort in a waterfall development life cycle.
Today, developers of UI for interactive systems have to address multiple sources of heterogeneity:
Model-Based User Interface Development (MBUID) is one approach that aims at coping with the above mentioned challenges and at decreasing the effort needed to develop UIs while ensuring UI quality. The purpose of Model-Based Design is to identify high-level models that allow designers to specify and analyse interactive software applications from a more semantic oriented level rather than starting immediately to address the implementation level. This allows them to concentrate on more important aspects without being immediately confused by many implementation details and then to have tools which update the implementation in order to be consistent with high-level choices.
For a comprehensive overview of the history and evolution of MBUID, we refer to (Meixner, Paternó, and Vanderdonckt, 2011). Different frameworks have been developed to conceptually capture the important aspects of a MBUID process. As early as 1996, Szekely introduced a generic architecture for MBUID (Szekely, 1996). In 2000, Da Silva described an architecture for UI development using a MBUID approach (Da Silva, 2000). The first version of a reference framework for multiple contexts of use UIs in history using a model-based approach, appeared in (Calvary et al., 2001). This version was then extended with additional relationships and definitions to give rise to a revised reference framework published for the first time in July 2002 (Calvary et al., 2002) and in (Calvary et al., 2003). It was then named the Cameleon Reference Framework (CRF) when accepted as a new deliverable of the EU-funded FP 5 CAMELEON project, published in September 2002 (Calvary et al., 2002b). CRF has now become widely accepted in the HCI Engineering community as a reference for structuring and classifying model-based development processes of UIs that support multiple contexts of use. CRF covers both the design time and run time phases. In (Calvary et al., 2003) metamodels and the use of models at runtime are proposed for supporting UI plasticity.
Figure 2. A simplified version of the Cameleon Reference Framework (CRF). Mappings and transformations between levels of abstraction depend on the context of use.
As depicted in Figure 2, the CRF makes explicit a set of UI models (e.g., Tasks, Abstract UI, Concrete UI, Final UI) and their relationships, to serve as a common vocabulary within the HCI Engineering community to discuss and express different perspectives on a UI.
The relationships between the CRF models include (Bouillon and Vanderdonckt, 2002): concretization, abstraction, translation, and reflexion.
The aforementioned relationships always preserve some dimension, either vertically (i.e., concretization and abstraction) or horizontally (i.e., translation, reflexion). In order to address non-horizontal/vertical transformations, Cross-cutting (Limbourg and Vanderdonckt, 2009) is a transformation of a model into another one at a different level of abstraction (higher or lower), while changing the context of use.
Orthogonal to the Task-Domain, AUI, CUI and FUI models, CRF makes explicit the context of use that may have an impact on the nature of the transformations used in the transformation process. The term “context of use” denotes an information space structured into three main models (see right side of Figure 2):
Although context of use is mainly defined based on information about users, platforms, and environments, there are also other dimensions that can be relevant to characterize context and to properly adapt an interactive system. The application domain, for instance, can also add relevant information that complete the characteristics of the context of use. For example, in a safety critical environment, knowing that the interactive system supports air traffic control or a nuclear power plant provides useful information about the level of attention that is required from end users.
Unlike the process initiated in the 1980s, which contained one entry point only at a high level of abstraction, CRF enables entry and exit points at any level of abstraction from which any combination of horizontal and vertical bottom-up and top-down transformations can be applied. This theoretical flexibility means that the stakeholders involved in the development of an interactive system can use the development process (e.g., human-centered development processes according to ISO 9241-210) that best suits their practice or the case at hand. Even when using a top down approach, developers can explore multiple development paths in parallel as illustrated in Figure 3. However, due to this high flexibility, developers have to ensure that models are not manipulated “by hand” after a transformation has been done. If so, developers have to ensure model consistency by e.g., using reverse transformations from a more concrete level to a more abstract level.
Figure 3. One example of possible transformations across the levels of CRF according to different contexts of use, starting from a unique Task and Domain Model.
This section provides a list of potential benefits that are usually discussed for model-based development and Model-Driven Engineering (MDE) in general. Each potential benefit is then refined in the context of UI development. General MDE benefits are reported in (Hutchinson et al., 2011).
1. Benefits resulting from the existence of a step-wise development life cycle:
2. Benefits resulting from the use of explicit abstract models:
3. Benefits from exploring alternative designs:
4. Benefits resulting from code generation: the benefits associated with this appear when the method is enacted.
5. Benefits from using models at runtime:
6. Benefits for supporting method engineering:
7. Maintenance of modeling language and transformations:
This section provides a list of implemented use cases to illustrate different CRF-compliant development processes. Table 1 provides a synthetic view of the differentiating characteristics of these exemplars where lines refer to the level of abstraction used as the entry point from which transformations are performed, and where columns indicate whether these transformations are performed at design time or at run time. The document Complementary List of Use Cases provides additional examples.
|
Entry Point / Software Life Cycle Phase |
Design Time |
Run Time |
|---|---|---|
|
Task & Domain |
UC1 - Car Rental UC2 - Digital Home |
UC3 - Minimalistic UIs |
|
Abstract UI |
UC4 Story Editor |
UC5 - Post WIMP Widgets |
|
Concrete UI |
UC6 - Automotive Industry (Infotainment system design) |
UC7- Photo-Browser |
|
Final UI |
UC8 - Tourism Web Site (TWS) |
Responsible:
The car rental example consists of a scenario in which the interactive system permits users to rent a car. In this sense, various contextual information can be used to adapt application aspects, and to properly display the list of cars to rent, enabling users to make choices and to accomplish the main task.
The key functional requirements to support this task include the capacity to:
Two contexts of use are targeted:
1) Context 1: Physical environment is that of a home, platform is a Desktop PC, and the user is an English speaker who does not know the city where the car has to be rented.
2) Context 2: Physical environment is a busy street, platform is a smartphone, and the user is walking fast (busy eyes).
Figures UC1.1 and UC1.2 show screenshots for the two targeted contexts of use.
Figure UC1.1. A Concrete User Interface for Context1 “Home, PC, English speaker familiar with the location”.
Figure UC1.2. A Concrete User Interface for Context2 “Noisy street, SmartPhone, English speaker walking fast, not familiar with the location”.
Figure UC1.3 illustrates how a MBUI approach can be applied using successive concretization transformations starting from a single Task and Domain Model to different Abstract User Interfaces (each one corresponding to a specific context of use) and iteratively down to Final User Interfaces.
Figure UC1.3. Models involved in the car rental use case and the process.
Figure UC1.4. Task models for the two targeted contexts of use.
Responsible:
Digital home refers to a residence with devices that are connected through a computer network. A digital home has a network of consumer electronics, mobile, and PC devices that cooperate transparently. All computing devices and home appliances conform to a set of interoperable standards so that everything can be controlled by means of an interactive system. Different electronic services can be offered by a digital home system, including but not limited to e.g., manage, synchronize and store personal content, family calendars and files; upload, play and show music, videos and pictures on a home screen (e.g., a TV) using a mobile phone as a remote control; use a mobile phone as a remote control for the other devices, for example a thermostat.
These functionalities are made available through context sensitive user interfaces. In fact, such UIs are capable of adapting to different computing platforms (touch-based devices, web, mobile, TV, PDA, DECT handset, voice portal …), users (children, teenagers, adults, elderly, disabled people, …) and environments or situations (at home, away, at night, while music is playing, …). The final aim is to provide a seamless and unified user experience, which is critical in the digital home domain. To this regard, different automatic UI adaptations can be possible: e.g., zooming the UI if the user has visual problems; enabling multimodal interactions (ex. voice interaction) because the user is doing another task at the same time.
The key functional requirements for this application are the following:
This application may be used in different contexts of use:
1) Context 1: Physical environment is that of a home, platform is a Desktop PC, and the user controls the home devices without accessing directly the physical controls.
2) Context 2: Physical environment is a street, and the user is moving. The user controls the home devices remotely, in order to e.g. start heating the home before coming back.
In this use case, the context dimension considered is limited to the platform aspect.
Figures UC2.1 and UC2.2 show screenshots of the Digital Home for two targeted contexts of use.
Figure UC2.1: The desktop version of the Digital Home application.
Figure UC2.2: The mobile version of the Digital Home application.
2.2 Diagram and Discussion
The models involved in the Digital Home use case as well as the process involving them are depicted in Figure UC2.3.
Figure UC2.3. Models involved in the Digital Home use case and the process.
The use case considered in the Digital Home exemplar (Mori et al., 2008) starts from the task model shown in Figure UC2.4. Because we consider the platform as the only dimension of the context of use, the other context aspects have been greyed out in Figure UC2.3. From the task model, it is possible to derive an Abstract UI for each targeted context of use. Let’s consider a desktop PC. On the one hand, this AUI will be expressed using a modality and platform -independent vocabulary (also shared by other AUIs addressing different computing platforms), on the other hand, this AUI will include only the abstract interaction units that make sense in that considered computing platform (a desktop PC). From this AUI, it is possible to obtain a Concrete UI and then a Final UI in a specific implementation language suitable for that computing platform. A similar process is followed to obtain a Final UI for a different platform (e.g., the mobile one). From the filtered CTT task model, an Abstract UI is derived and then a CUI and finally an implemented UI expressed in a language supported by the mobile platform is built.
Figure UC2.4. The Task Model for the Digital Home.
Responsible:
The SmartFactoryKL (see Figure UC3.1) is an arbitrarily modifiable and expandable (flexible) intelligent production environment, connecting components from multiple manufacturers (networked), enabling its components to perform context-related tasks autonomously (self-organizing), and emphasizing user-friendliness (user-oriented). The SmartFactoryKL is the first ambient intelligent production environment for demonstration and development purposes worldwide. Development of user interfaces is a secondary field in the production industry, but the impact of user interface quality is increasingly independent of the application domain, which is a significant factor of success for the entire product. After three years of research, a first prototype has been finished that allows for controlling the production line using a single universal interaction device able to adapt to varying field devices according to the actual context of use, in a complex, model-based approach. To handle the resulting diversity of user interfaces, we developed a universal interaction device – the SmartMote – which is capable of providing control over various devices in these environments. Depending on the context of use, the visualization of the SmartMote is generated and adapted during run-time in order to provide a homogeneous intra-device user experience.
Figure UC3.1. The SmartFactoryKL
The key functional requirements for this application are the following:
The SmartMote may be used in one context
1) Context 1: Physical environment is that of a production environment (industrial factory), platform is a tablet PC (+ modules or field devices from different vendors), one single user
Figure UC3.2. Screenshot of a rendered (final) UI with the SmartMote (Seissler, 2013)
For the specification of the context-sensitive UI a model-based architecture has been developed that consists of two core models (AUI-model and CUI-model). The AUI-model is specified using the “Useware Dialog Modeling” Language (useDM) that enables the abstract, modality-independent specification of the user interface. This model is refined via a CUI-model that uses the User Interface Markup Language (UIML) 4.0 for the platform-independent description of the graphical user interface. Adaptation rules are further used to specify the adaptation that can be applied on those models at run-time. To generate the final user interface (FUI) a java-based Renderer – SmartMote – has been developed.
Figure UC3.2. Models involved in the Minimalist-UI use case and the process.
Responsible:
The production of e-learning tools for deaf people meets with several difficulties, connected to the need to resort only to the visual channel, without saturating it, and to the adoption of different cognitive strategies developed within the community. From a field study conducted with deaf people in the context of a national project involving cognitive scientists, linguists, and computer scientists, we adopted the metaphor of a learning story as the basis for organising different types of learning material: videos, pictures, texts, accompanied by translation in the Italian Sign Language. We report on the use of a user interface abstract model in the development of the interactive story editor, to be used by tutors and teachers to organise the course material and path, and which generates interactive pages for the students.
The key functional requirements to support developers of course include:
The context of use is that of the generation of a course by a teacher, possibly involving in the process tutors who will then have to assist the learners. Learners and tutors will then interact with the generated web pages (Bottoni et al., 2012).
The development relies on an abstract model of the learning domain, in which stories are seen as workflows: (learning) processes in which tasks are assigned to actors (e.g., students and tutors). Stories can be recursively composed by sub-stories, paths define sequences or alternatives for exploration of stories, with transitions connecting sub-stories, and tasks either are defined as simple stories to be explored individually or in a laboratory, or require the exploration of sub-stories. Each story has a single entry point and a single exit point, signalling completion by the student.
Stories are classified with respect to the exploration strategy and associated with abstract patterns. For example, in a star topology tasks can be performed in any order. For each type, the story editor provides a specialised form of interaction, guiding the teacher to define the story according to that type, and a template is used to generate the appropriate main page for the story accordingly. Figure UC4.1 (left) presents the workflow for a story with three sub-stories organised in a star topology. Figure UC4.1 (right) shows the generated page for a story with star topology providing access to five sub-stories. The lateral bars are generated according to a general template.
Figure UC4.1: The workflow for a star-story (left) and a generated page for a star-story (right).
The models involved in the Digital Home use case as well as the process involving them are depicted in Figure UC4.2.
The design of the interaction with the Story Editor and of the templates for the generated pages derives from the representation of tasks in the form of patterns composed by specific task trees. For each pattern, the story editor will constrain the interaction to create instances of that pattern, and will generate the specific workflow to be followed while interacting with the generated page. Moreover a corresponding pattern of interaction elements to be included in the generated page is provided as an abstract user interface model.
The target platform is that of Web pages with associated JavaScript components for the interaction with the specific learning content.
Figure UC4.2. Models involved in the Story Editor use case and the process.
As shown in Figure UC4.3, a StoryContainer will present several individual components, providing context for the interaction, and a PresentationContainer, composed of several different “page contents” in a mutual emphasis relation so that they cannot be shown together). The specific composition of the presentation container will depend on the type of story to be presented, as prescribed by the Task Model, where either an individual component or a container is associated with each task.
Figure UC4.3: The overall abstract structure of story containers.
Responsible:
With the introduction of technologies like HTML5, CSS3, and SVG, the way people can interact with the web has been fundamentally enhanced. Designers are no longer required to use a predefined set of basic widgets. Instead, interaction can nowadays be driven by self-designed widgets specifically targeted at some specific user needs or specific application requirements. These Post-WIMP widgets are designed to support different combinations of modes and media and can guarantee a certain quality-in-use upon context changes. Based on ubiquitous availability of browsers and corresponding standardized W3C technologies Post-WIMP widgets can be easily designed and manipulated (e.g. SCXML, ECMA), instantly reflect continuous context changes (e.g. by WebSockets) and consider different multimodal setups (e.g. XHTML+Voice, SMIL, and the MMI-Architecture).
The fact that the control and appearance of Post-WIMP widgets is designed with a high degree of freedom has an impact on MBUID approaches: the toolkit and therefore the target of a model transformation can no longer been assumed as static (a fixed set of widgets). The same models (task model, AUI model, CUI model) known from MBUID can be applied to design individual Post-WIMP interactors. Additionally, a statechart-based behavior description captures the enhanced interaction capabilities of a Post-WIMP interactor. As an example we consider two use-cases of Post-WIMP interactors running inside a web application: A mixed reality furniture online shop that can be controlled by gestures and supports inter-reality migration of interactors and an interactive music sheet that can be controlled by head movements.
In the web furniture shop, a customer can choose between different furniture and fill up a shopping cart. By a drag-and-drop gesture using both hands one can drag furniture interactors virtually out of the monitor displaying the web shop and drop them into an augmented reality to see if the furniture really matches in space and color to the user’s environment. An augmented reality frame that surrounds the shopping cart allows to seamlessly switch between realities while crossing it during the drag and drop gesture.
Figure UC5.1: Shopping cart web application with reality frame.
Figure UC5.1 shows the actual shopping cart that is part of a typical online shop and has been enhanced by a Reality Frame. To enable a reality crossing Drag-and-Drop, the Reality Frame needs to be activated, which triggers a calibration of the system that identifies the monitor’s physical location in the environment of the user using a camera and a visual marker.
Figures UC5.2a(left) and UC5.2b (right): Two handed gesture to pick and drop furniture.
Figures UC5.2a and UC5.2b depict a user dragging furniture using the left hand for pointing and the right hand for picking up an object in the browser. After the users has crossed the reality frame of the shopping cart in the browser, the web page changes to the augmented scene enabling her to position the furniture in her own environment.
Figure UC5.3: Using a mouse to drag and drop furniture into the environment of the user.
Figure UC5.3 shows an adaptation of the interactors that support the same interaction using a classical mouse and keyboard setup.
The key functional requirements for support the user of the online furniture shop include:
Three contexts of use are targeted:
When learning to play a musical instrument, or when playing one, a music sheet is used to give guidance as to how to perform the musical piece. However, as songs become longer and more intricate they may span across several sheets, forcing the player to stop playing to turn the page. Although this may become easier as one becomes more experienced with the instrument, it is a barrier for inexperienced players that can be tackled easily using a different mode to turn the pages other than your hand.
Figure UC5.4 (left): Music sheet control setup Figure UC5.5 (right): Music sheet web application
We propose a UI to turn music sheets with simple head movements that can be captured by a basic VGA webcam, a common part of modern notebooks. The considered setup is shown in Figure UC5.4 and a screenshot of the web browser displaying the music sheet is depicted in Figure UC5.5.
Figure UC5.6: Head Tracking Interactor
A head movement mode interactor supports detecting tilting the head to the side, right and left, as the controller to pass to the next page or return to the previous page, respectively. Figure UC5.6 shows a screenshot of the head tracker. The left side of the figure shows the debugging user interface in that a moving arrow represents the direction of the head movement (mirrored).
The key functional requirements for support the user of the online furniture shop include:
Three contexts of use are targeted:
The process starts at the final user interface and identifies interface elements (widgets) that should be enhanced to be controllable via various modalities, e.g., gestures or body movements. For each FUI element, a mapping is then defined that identifies the abstract Interface interactor (from a pre-existing abstract interactor model - http://www.multi-access.de/mint/aim) that matches best the behavior of the FUI element. Then, concrete user interface interactors are specified that represent the FUI element’s behavior as a model (by a state chart). Finally, the modeled behavior is precisely mapped to the Final UI element (http://www.multi-access.de/mint/mim).
Further control modes or interactor representing media that have been derived from the same AUI interactor and for that already CUI model interactors have been defined can then be used as an additional control mode or representation for the new FUI element (http://www.multi-access.de/mint/irm) (Feuerstack, 2012a).
Different to the other approaches the main intention of the process is to identify and specify interactors on the abstract, concrete and final user interface level to form an interactor repository of re-usable interface elements that synchronize themselves over various control modes and media representations (http://www.multi-access.de/mint-2012-framework/) (Feuerstack2012b)
Figure UC5.7. Models used for the Post-WIMP widgets use case, and the process.
Responsible:
Car infotainment systems are currently developed using huge textual specifications that are refined iteratively while parallel being implemented. This approach is characterized by diverging specifications and implementation versions, change request negotiations and very late prototyping with cost-intensive bug fixing. Number and variety of involved actors and roles lead to a huge gap between what the designers and ergonomists envision as the final version, what they describe in the system specification and how the specification is understood and implemented by the developers.
Model-based user interface development could speed up the iterative implementation while reducing implementation efforts due to automatic generation of prototype interfaces. Different models could be used to establish a formal and efficient communication between designers, functionality specialists (e.g. Navigation, Telephone and Media), developers and other stakeholders. The resulting reduction of development time would make car infotainment systems more competitive and would narrow the gap to innovation cycles in the field of consumer electronics.
Another large aspect of modern car infotainment systems is the quality assurance that is performed by the vendors. The complexity of modern infotainment systems (more than 1000 different screens and different modalities) requires large efforts to develop formal test models on the basis of the system specification. The test models are then used by the vendor to test the implementation coming from the supplier. This procedure results in another time and cost-intensive gap that could be bridged by performing consistency checks on the models used to generate the infotainment system instead of testing the implementation.
Moreover, vehicles and their infotainment systems have to be accessible. Even though model-based user interface development could speed up the iterative implementation, a further step is needed to enforce the accessibility of the cars: the description of the user. If user-interface description languages can also describe the user efficiently, including elderly and people with disabilities, then the two definitions (UI & user) could be used in frameworks performing automatic/simulated accessibility evaluation of the prototype interfaces of a car.
The key functional requirements to support UI development in the automotive industry include the capacity to:
Two contexts of use are targeted:
1) Context 1: Physical environment is that of an automotive company office, platform is a desktop PC and user is a developer.

The models involved in the automotive industry scenario, as well as the process involving them, are depicted in Figure UC6.1.
Figure UC6.1. Models used in the Automotive Industry use case, and the process
In the automotive industry UIs are developed starting at the CUI level. Normally developers start with sketches, mock-ups or paper prototypes and iterate. On the basis of mock-ups interaction and graphical designers refine the mock-ups to wireframes and finally develop the graphical design e.g., with Adobe Photoshop. In the end the prototypes are manually transferred into a final UI for a specific infotainment system. The project automotiveHMI (http://www.automotive-hmi.org/) is developing a process and a UIDL to integrate the working artifacts of the involved developers to generate the FUI automatically.
Contributors:
Photo-Browser supports photo browsing in a centralized or distributing way depending on the availability of a dynamic set of interactive devices (http://iihm.imag.fr/demo/photobrowser/). These include a multi-touch interactive table, a projected display on a wall, an Android SmartPhone, and a kinect to track gestures. As shown in Figure UC7.1, the UI of Photo-Browser is dynamically composed of the following components: a Tcl-Tk component running on the multipoint interactive surface (Fig. UC7.1d), a component that transforms an HTLM-like CUI into HTML code to serve as input to a Web browser (this code supports the task “sequential navigation through the image portfolio”) (Fig. UC7.1c), a Java component that provides a list of the photo names (Fig. UC7.1b), and a Java component running on the SmartPhone to navigate through the photos sequentially using the Next and Previous buttons.
Figure UC7.1. Photo-browser: a dynamic composition of executable and transformable components managed by a dynamic set of interconnected factories (a) running on different platforms (Windows, MacOS X, and Android).
When the user, say Alice, enters the room, the interactive table starts automatically and shows Bob’s last opened photo portfolio. By performing a “wipe” gesture from the table to the wall, the current selected photo of the table is replicated on the wall. As Alice brings her SmartPhone in contact with the table, the phone can be used as a remote controller (Figure UC7.2). Using a wipe gesture over the table provokes the table to shut down. Alice can carry on her task using the wall as a large display and the SmartPhone as a remote controller. Here, a meta-UI has (Coutaz, 2006) been developed to support two classes of functions: (a) Dynamic software deployment in the ambient interactive space, and (b) UI redistribution across interactive devices including on-the-fly generation from a CUI HTML-like to native HTML code.
The key functional requirements to support UI migration for photo-browser include the capacity to:
Four contexts of use are targeted:
1) Context 1: Physical environment is that of an office, platform is an interactive table PC, one single user.
2) Context 2: Physical environment unchanged, platform is composed of an interactive table and of a PC equipped with a beamer, one single user.
3) Context 3: Physical environment unchanged, platform is composed of an interactive table, a PC equipped with a beamer, and a SmartPhone, and a single user
4) Context 4: Physical environment unchanged, platform is composed of a PC equipped with a beamer, and a SmartPhone, and a single user.
Figure UC7.2. (Left) Connecting a SmartPhone to the interactive space by laying it down on the interactive table. (Right) Using the SmartPhone as a remote-controller to browse photos displayed by the HTML-based UI component of Figure UC7.1c and video-projected on the wall.
In this scenario, “Alice entering the room” corresponds to a situation that the Context Manager is able to recognize: “it is User Alice and Alice has entered Room Ambient Space”. The action that the Context Manager must perform has been specified earlier by Alice using an end-user development tool (or has been learnt automatically by the ambient space and confirmed by Alice). For example, using a pseudo-natural language programming language, Alice has instructed the context manager that “when I enter Room Ambient Space, please start the table with my last opened photo roll”. This sentence is then translated into an Architectural Description Language (ADL) whose interpretation by a middleware at runtime automatically deploys or stops the appropriate software components.
The UI of the meta-UI includes the recognition of three gestures: (1) a “wipe” gesture that allows the user to command the migration of the current selected photo from the table to the wall, (2) a “wipe” gesture that commands the system to shut down the table, and (3) the contact of the SmartPhone with the interactive table.
The diagram of Figure UC7.3 makes explicit the use of models at runtime: full coverage of the context of use, and remolding performed by on-the-fly transformation of one single component: that of the HTML-like CUI to the native HTML code of the target browser running on the PC. The other components are not transformed but are meta-described and dynamically recruited as resources of the platform.
Figure UC7.3. Models used in the Photo-Browser use case, and the process.
Contributors:
The Tourist Web Site (TWS) provides tourists with information for visiting and sojourning in the Sedan-Bouillon area, including a selection of hotels, camping, and restaurants. The UI of TWS is centralized when used from a PC workstation. Preparing a trip for vacation is an exciting experience when shared by a group of people (Figure UC8.1-left). However, one single PC screen does not necessarily favor collaborative exploration. By dynamically logging to the same website with a SmartPhone, users are informed on the SmartPhone that they can distribute the UI components of the site across the interaction resources currently available. Using a form, the user asks for the following configuration: the title of Web pages must appear on the SmartPhone as well as on the PC (the title slots are ticked for the two browsers available), whereas the content should stay on the PC whose screen is projected on the wall, and the navigation bar should migrate to the SmartPhone (Figure UC8.1-right). This form, which allow users to reconfigure the UI of TWS is the user interface of the meta-UI of the system (Coutaz, 2006).
The key functional requirements to support UI migration for TWS include the capacity to:
Two contexts of use are targeted:
1) Context 1: Physical environment is that of a home, platform is a Desktop PC, one family member as a single user.
2) Context 2: Physical environment is that of a home, platform is composed of a Desktop PC and of a SmartPhone, family members as users.
Figure UC8.1. The TWS web site. UI centralized on a PC screen (left). The control panel of the meta-UI to distribute the presentation units across the resources of the interactive ambient space (right). The lines of the matrix correspond to the pieces of content that can be redistributed, and the columns denote the browsers currently used by the same user.
At any time, the user can ask for a reconfiguration of the UI by selecting the “meta-UI” link in the navigation bar (Figure UC8.2). The UI will be reconfigured accordingly. In this example, the function supported by the meta-UI is UI redistribution using a typical form-based interaction technique.
Figure UC8.2. The TWS web site when distributed across the resources of the ambient interactive space. The MetaUI link allows users to return to the configuration panel shown on the right of Figure UC8.1.
As shown in Figure UC8.3 for the TWS example, the Final UI is abstracted away at run time up to the AUI level. In turn, this AUI serves as input for retargeting and redistribution using a combination of the user’s request produced by the way of the meta-UI and of the platform model maintained in the context of use. The diagram shows the transformation process going from the PC centralized version to the distributed version. The reverse process holds when moving from distributed to centralized use.
Figure UC8.3. Models used in the TWS use case, and the process.
This section presents a list of non-functional requirements that must drive the process of producing various models defined at different abstraction levels found in the CRF and that are applicable to any meta-modelling approach. They were identified based on the aforementioned use cases. These requirements are not assumed to be exhaustive, but rather are intended to be constructive in order to ensure the quality of meta-models and models produced according to these meta-models. Each respective meta-model may refine any generic requirement into a specific requirement that precises how to address each requirement in each specific case.
Refers to the ability of a (meta-)model to abstract all real world aspects of interest via appropriate concepts, attributes, and relationships. In theory, completeness is aimed at producing a (meta-)model that covers all real world aspects of interest. In practice however, it may turn out that not all aspects of interested could be captured in a (meta-)model. For this reason, completeness is sometimes reduced to expressiveness, which refers to the ability of a (meta-)model models to abstract a significant subset of real world aspects of interest that is considered enough for the purpose of its usage. A sub-property of completeness, respectively expressiveness, is the graphical completeness, respectively graphical expressiveness. Both refer to the ability of a (meta-)model to represent abstractions relevant for this (meta-)model through appropriate graphical representations of the concepts, attributes, and relationships. Note that it is not necessary that all the concepts, attributes, and relationships of a (meta-)model should be represented graphically. Therefore, graphical completeness is often substituted by graphical expressiveness.
Consistency is often decomposed into two sub-properties: external consistency and internal consistency. External consistency refers to the ability of a (meta-)model to produce abstractions of the real world that reproduce the behaviours of the real world aspects of interest in the same way and that preserves this behaviour throughout any manipulation of the (meta-)model. Internal consistency refers to the ability of two or more (meta-)models to produce abstractions according to the same methodological approach. This includes: define a common vocabulary (e.g., the glossary), use this vocabulary in a systematic way in every (meta-)modelling activity so as to produce abstractions in the same way, avoid non-unique names. Rules for ensuring internal consistency could be defined in this way.
Refers to the ability of a (meta-)model to abstract any real world aspect of interest into one single abstraction belonging to one single (meta-)model with as little overlapping as possible with other abstractions belonging to other (meta-)models.
Refers to the ability of a (meta-)model to extend the definition of existing abstractions for more specific purposes without affecting the stability of the overall definition.
Refers to the ability of a (meta-)model to produce abstractions of real-world aspects of interest in a way that is as compact as possible with respect to the real-world. A related principle to concision is the Don’t repeat yourself (DRY) principle, which refers to the ability of a (meta-)model to produce abstractions of real-world aspects of interest in a single, unambiguous, and authoritative representation.
Refers to the ability of one or more (meta-)models to establish relationships between themselves in order to represent a real-world aspect of interest. Therefore, correlability is often decomposed into internal versus external correlability depending on the type of relationship involved (intra-model versus inter-model). There are several ways to establish relationships within a (meta-)model or across (meta-)models such as, but not limited to: mapping, transformation, mathematical relationships.
A number of model-based UI tools are available for download. Although most of them adhere to the principles of the Cameleon framework, none of them, so far, implements the MBUID standard.Table 2 below present these tools in a synthetic manner. The interested reader can access a detailed description of the tool from its URL.
Table 2. Examples of tools
|
Name |
Authors |
URL |
CRF Levels coverage |
Design time/ Run time tool |
Implementation |
|---|---|---|---|---|---|
|
ConcurTaskTrees Environment (CTTE) |
CNR-ISTI, HIIS Laboratory |
Task |
Design time |
Java application |
|
|
Model-based lAnguage foR Interactive Applications Environment (MARIAE) |
CNR-ISTI, HIIS Laboratory |
Task, AUI, CUI, FUI |
Design time |
Java application |
Table 2. Examples of tools (continued).
|
Name |
Functional coverage - Specific features |
|---|---|
|
ConcurTaskTrees Environment (CTTE) |
Modelling and analysis of single-user and cooperative CTT task models. In detail: - Visualise/Edit task models; - Interactively simulate task models; - Automatic check the validity/completeness of task models; - Save task models in various formats; - Support the use of informal descriptions for task modelling; - Filter nomadic task models according to platform; - Support multiple interactive views of CTT task model specification; - Support the generation of CTT task models from WSDL; - Support the generation of Maria AUIs from CTT task models; - Support the generation of Maria CUIs for various platforms (e.g., desktop, mobile, vocal, multimodal,..); - Support the generation of Maria FUIs for various implementation languages (e.g. Desktop HTML, Mobile HTML, X+V Desktop, X+V Mobile,..) |
|
Model-based lAnguage foR Interactive Applications Environment (MARIAE) |
Modelling and analysis of various types of UI models. In detail: - Visualise/Edit Task/AUI/CUI models; - Edit and apply model transformations; - Support Web Service -based development of interactive applications; - Support the simulation of CTT task models; - Support the generation of Maria AUIs from CTT task models; - Support the generation of Maria CUIs for various platforms (desktop, mobile, vocal, multimodal,..); - Support the generation of Maria FUIs for various implementation languages (e.g. Desktop HTML, Mobile HTML, X+V Desktop, X+V Mobile,..) |
A separate glossary of terms for the Model-Based User Interface domain has been provided. It contains informal, commonly agreed definitions of relevant terms and explanatory resources (examples, links etc.)
In addition to the editors, the following people contributed to this specification: