You are here: Work Web>UrnPatternsBookChapter2006>CaseStudy (28 Mar 2006)
GRL Graphs: Feedback Control System Goal Feedback Goal Error Calculation Goal Feedforward Goal Measurements Old Versions

Note [da]: I asked Jean-François to improve jUCMNav to enable/disable colours, numerical satisfactions, GRL-like satisfactions, etc. for GRL. Should be available for the final version of the paper, if accepted.

UCM: Feedback Control System Overview

  • the actor diagrams use different styles. please let me know which one you prefer.
  • the degrees of contributions i have added have to be reviewed (i just added some figures to make sure the machinery works)
  • ucm descriptions of each of the pattern combinations still need to be done
  • attached jucm file to this page (mw: which version are you using?) (gM: the latest build from today - mar22)
  • mw: Gotta love Wiki!
  • gM: read through mw's comments:
    • i will remove measurements from the diagrams (it will make everything a lot easier to read). essentially, the sensors are out of scope and we can assume that we have measurements coming from the plant (which i will rename to controlled system)
    • i have already covered most of the high-level nfrs but will expand on the interactions between them as mentioned by mw
    • i will create one big grl graph that shows all patterns, all combinations, and all actors - it will be huge but we can always reduce it by removing some elements (which is easy: copy file and delete). the advantage is that we can reason about the big picture.
    • i will focus on the individual actors instead of Feedback Control System Dependencies (i don't clearly understand what role Feedback Control System Dependencies will play in the paper - is it necessary?)

  • version 2 (attached jucm file: urn patterns v4.jucm)
  • version 3 (attached jucm file: urn patterns v5.jucm)
  • version 6 (attached jucm file: urn patterns v6.jucm)
    • now added UCM to show major scenarios based on figure 11-13 in the book (POAD)
    • had to readd measurements to the goal model
    • there is an issue now with the evalution of the model: since the selection of individual patterns is global, different patterns cannot be selected for each of the subgoals (measurements, feedback, feedforward, error calculation); workaround: different strategies for each subgoal allow me to show the impact of the chosen patterns on the subgoal but don't allow me to reason about the impact on the overall system. to show the impact on the overall system, one would need to create different pattern tasks for each subgoal (e.g. prefix with subgoal) - then different patterns can be selected for each subgoal but that involves a lot of work in creating the model as each subgoal page has to be created from scratch
  • version 7 (attached jucm file: urn patterns v7.jucm)

Not sure if either of you had a chance to look at the case studies in the POAD book yet. I favor the feedback control example from chapter 11. Despite the fact that only three patterns (Strategy, Observer, and Blackboard) are being used in the end, there are many design ambiguities that need to be resolved first. The description in the book is also somewhat imprecise, and not entirely consistent, which allows us to improve on the solution presented.

gM: i agree with chapter 11. i looked at the case study on waiting queue simulations in chapter 12. only three patterns are used: composite (2x), reactor, and templatemethod. the only alternative mentioned is strategy for templatemethod but no reasons are given on why to choose templatemethod or any of the other patterns.

The first thing to note is that the pattern selection is not as clear-cut as suggested by the book. I would probably not argue about the Strategy pattern (seems an appropriate choice), but both for Observer, and the pattern they refer to as Blackboard there are alternative choices, or pattern variations, respectively. We also don't learn enough about the example to come up with just THE solution, but would benefit from modeling the design space with the rationale for each choice.

Background

[TODO: some background on the example, definition of basic feedback control concepts. --MW]

Strategy

Since our design should provide flexibility in the choice of control strategy, it is a good idea to decouple strategy use from strategy definition. This is best achieved by the dependency inversion principle as embodied in the Strategy pattern. It can be applied to both feedforward and feedback strategies.

The use of Strategy can be modeled nicely in a UCM model as a dynamic stub.

Observer

We want the processing stages (feedforward, measurement, feedback, and error calculation) to be decoupled from one another. This suggests the use of indirection, as embodied in the Indirect Invocation architectural pattern (Zdun, 2005). However, it is less clear that this requires the full machinery (and overhead) of the Observer pattern (also known as Publisher-Subscriber). Observer is good if there can be several observers (a 1:m relationship). Yet, here the relationship is more likely only 1:1. This suggests the Producer-Consumer variant (Buschmann, 1996) of the Observer pattern. The alternative to using Producer-Consumer is to invoke stages that need to be notified directly, as described by Explicit Invocation (Zdun, 2005).

gM: i am not sure but i think the observer may be appropriate. at the high level, there may be only one plant providing measurements to one feedback component which provides data to one error calculator which forwards data to one feedforward component. however, we are most likely dealing with many measurements coming from the plant, anyone of which may need to be acted on by potentially many feedback elements. then, the measurements may turn into many errors which will trigger many control algorithms to the plant. in special cases, there may be only a 1:1 relationship but in general i think the relationship will be 1:m. in any case, all patterns mentioned in the paragraph above are excellent candidates to be shown in a goal model.

In the UCM we could try to model the Subject and Observer of the Observer pattern as stubs. The idea would be to apply patterns in sequence essentially by selecting appropriate plug-ins (eg plug-in another instance of Observer into the Observer stub that represents the feedback component in the UCM for the measurement component). However, this may not always work as nicely. (Just an idea to play with, no must for the paper.)

Blackboard

This is used in the definition of (Shaw, 1996), in the sense of the Blackboard architectural style. To avoid any confusion with the Blackboard pattern (Buschmann, 1996), (Zdun, 2005) refers to this as Active Repository. First of all, it is not clear whether the repository needs to be active here, or whether Shared Repository is sufficient. Also, we may or may not need the data (measurement, feedback, and error) to be persistent. However, if the feedforward control is more complex it may very well make use of historical data, thus motivating the need for persistence. As an example, consider a differentiating controller which bases its response on the difference between the last and the last to last measurement.

The book does not fully exploit the repository. In particular, the code example ignores it altogether. Also, when we opt for an Active Repository, we effectively move responsibility for notifying the next processing stage into the repository, and we no longer need any form of Observer. So unlike what the book does, we could suggest to use an Active Repository to meet both persistence and decoupling needs.

References

  • (Buschmann, 1996), Buschmann, F., et al, Pattern-Oriented Software Architecture, Wiley, 1996
  • (Chung, 2003), Chung, L., Supakkul, S., and Yu, A., Good Software Architecting: Goals, Objects, and Patterns, Information, Computing & Communication Technology Symposium (ICCT- 2002), UKC'02, Seoul, Korea, July 2002.
  • (Shaw, 1996) Shaw, M., et al, Software Architecture, Addison-Wesley, 1996 (also see they 2005 book in the SEI series)
  • (Zdun, 2005), Avgeriou, P, and Zdun, U., Architectural Patterns Revisited -- A Pattern Language, Euro Plop?, 2005

-- Michael Weiss? - 21 Mar 2006

Topic attachments
I Attachment Action Size Date Who Comment
elsejucm urnpatterns.jucm manage 74.7 K 22 Mar 2006 - 16:03 Gunter Mussbacher  
elsejucm urnpatternsv4.jucm manage 46.2 K 23 Mar 2006 - 18:55 Gunter Mussbacher  
elsejucm urnpatternsv5.jucm manage 70.9 K 24 Mar 2006 - 12:39 Gunter Mussbacher  
elsejucm urnpatternsv6.jucm manage 98.4 K 24 Mar 2006 - 14:19 Gunter Mussbacher  
elsejucm urnpatternsv7.jucm manage 127.5 K 27 Mar 2006 - 00:11 Gunter Mussbacher  
Topic revision: r10 - 28 Mar 2006 - 08:36:51 - Daniel Amyot
 
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback