Algorithmic Sets
Aus apemap-wiki
				
								
				(Unterschied zwischen Versionen)
				
																
				
				
								
				Mkurz  (Diskussion | Beiträge)  (Die Seite wurde neu angelegt: „== Definition Algorithmic Set == * We want to define an algorithms set via a Predicate deciding if an element is part of the set.“)  | 
		Mkurz  (Diskussion | Beiträge)   (→Decision explanation)  | 
		||
| (21 dazwischenliegende Versionen von einem Benutzer werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
== Definition Algorithmic Set ==  | == Definition Algorithmic Set ==  | ||
| − | * We want to define an   | + | * We want to define an algorithmic set via a Predicate deciding if an element is part of the set or not.  | 
| + | * In java we could use the functional interface Predicate<T>  | ||
| + | <pre>  | ||
| + | public interface Predicate<T>{  | ||
| + |        // If test returns true, we consider the element be part of the algorithmic set.  | ||
| + |        boolean test(T element);  | ||
| + | }  | ||
| + | |||
| + | </pre>  | ||
| + | * Such a simple definition allows a polymorphic approach for defining set predicates.  | ||
| + | * So if a new predicate is needed only a new implementation of Predicate<T> needs to be implemented.  | ||
| + | * These Predicate<T> implementations can introduce configurable properties, for a more flexible solution.  | ||
| + | * <b>An algorithmic set is defined by its predicate instance.</b>  | ||
| + | |||
| + | == Performance considerations ==  | ||
| + | * This approach is only reasonable if all tested elements are in memory, querying them from a database would be at least suboptimal.  | ||
| + | |||
| + | == Logical Groups ==  | ||
| + | * For predicate aggregation we could simply implement PredicateCollections.  | ||
| + | * PredicateCollectionOr<T>  | ||
| + | * PredicateCollectionAnd<T>  | ||
| + | |||
| + | == Algorithmic sets and Notifications ==  | ||
| + | * <b>We want to define the receivers of a notification with an algorithmic set.</b>  | ||
| + | * This means every Notification has an algorithmic set of receivers attached to it.  | ||
| + | * How this algorithmic set of receivers is attached is not part of this article.  | ||
| + | * For identifying a receiver, we introduce a ConnectedClientTupel of the form:  | ||
| + | <pre>  | ||
| + | public class ConnectedClientTupel{  | ||
| + |     public Computer getComputer(); // Including the Platz.  | ||
| + |     public User getUser(); // Including the role.  | ||
| + |     ... // Will grow in the future.  | ||
| + | }  | ||
| + | </pre>  | ||
| + | * Practically the above tupel, will be part of the session, but it seems reasonable not to use the session directly for a cleaner interface.   | ||
| + | * So the Predicate for Notification receivers would have the form:  | ||
| + | <pre>  | ||
| + | public interface NotificationReceiverPredicate extends Predicate<ConnectedClientTupel>  | ||
| + | {  | ||
| + | }  | ||
| + | </pre>  | ||
| + | * Every connected client queries its notifications via a REST interface.  | ||
| + | * <b>All notifications should be grouped by their NotificationReceiverPredicate instances</b>.  | ||
| + | * So instead of testing the predicate for every notification we only need to test every predicate instance once.  | ||
| + | * The amount of different predicate instances is relatively low, so we should be capable of delivering the notifications to a client reasonable fast.  | ||
| + | |||
| + | == Named Notifications Recipient Groups ==  | ||
| + | * The software consultants (SWC) should be able to define named recipient groups.  | ||
| + | * The SWCs should be able to test such a recipient group.  | ||
| + | |||
| + | |||
| + | == Decision explanation ==  | ||
| + | * It is required to give information to the SWC about the decision process.  | ||
| + | * To allow this we should introduce an extended Predicate<T> interface with an optional decisision explanation parameter.  | ||
Aktuelle Version vom 8. November 2014, 11:17 Uhr
Inhaltsverzeichnis | 
Definition Algorithmic Set
- We want to define an algorithmic set via a Predicate deciding if an element is part of the set or not.
 - In java we could use the functional interface Predicate<T>
 
public interface Predicate<T>{
       // If test returns true, we consider the element be part of the algorithmic set.
       boolean test(T element);
}
- Such a simple definition allows a polymorphic approach for defining set predicates.
 - So if a new predicate is needed only a new implementation of Predicate<T> needs to be implemented.
 - These Predicate<T> implementations can introduce configurable properties, for a more flexible solution.
 - An algorithmic set is defined by its predicate instance.
 
Performance considerations
- This approach is only reasonable if all tested elements are in memory, querying them from a database would be at least suboptimal.
 
Logical Groups
- For predicate aggregation we could simply implement PredicateCollections.
 - PredicateCollectionOr<T>
 - PredicateCollectionAnd<T>
 
Algorithmic sets and Notifications
- We want to define the receivers of a notification with an algorithmic set.
 - This means every Notification has an algorithmic set of receivers attached to it.
 - How this algorithmic set of receivers is attached is not part of this article.
 - For identifying a receiver, we introduce a ConnectedClientTupel of the form:
 
public class ConnectedClientTupel{
    public Computer getComputer(); // Including the Platz.
    public User getUser(); // Including the role.
    ... // Will grow in the future.
}
- Practically the above tupel, will be part of the session, but it seems reasonable not to use the session directly for a cleaner interface.
 - So the Predicate for Notification receivers would have the form:
 
public interface NotificationReceiverPredicate extends Predicate<ConnectedClientTupel>
{
}
- Every connected client queries its notifications via a REST interface.
 - All notifications should be grouped by their NotificationReceiverPredicate instances.
 - So instead of testing the predicate for every notification we only need to test every predicate instance once.
 - The amount of different predicate instances is relatively low, so we should be capable of delivering the notifications to a client reasonable fast.
 
Named Notifications Recipient Groups
- The software consultants (SWC) should be able to define named recipient groups.
 - The SWCs should be able to test such a recipient group.
 
Decision explanation
- It is required to give information to the SWC about the decision process.
 - To allow this we should introduce an extended Predicate<T> interface with an optional decisision explanation parameter.