Notes
Definitely more of a philosophical discourse on the role of design, but it’s separation between categories and placements appear strongly related to our distinction between a process model and design model. According to the paper, design thinking is expressly broken down into 4 areas symbols (“signs”), material objects (“things”), actions, and complex systems or environments (“thoughts” – seemed a weird characterization). While this breakdown in and of itself seems rather tangential, these are described as intricately interconnected, with no inherent ordering. The author goes on to argue that the “conceptual repositioning” of problems across areas drives innovation in design, illuminating in a systematic pattern that underlies all of twentieth century design thinking: a distinction between categories and placements.
Understanding the difference between a category and a placement is essential if design thinking is to be regarded as more than a series of creative accidents. Categories have fixed meanings that are accepted within the framework of a theory or a philosophy, and serve as the basis for analyzing what already exists. Placements have boundaries to shape and constrain meaning, but are not rigidly fixed and determinate.The boundary of a placement gives a context or orientation to thinking, but the application to a specific situation can generate a new perception of that situation and, hence, a new possibility to be tested. Therefore, placements are sources of new ideas and possibilities when applied to problems in concrete circumstances (p.12–13).
It seems to me our general conception of a design model could be characterized according to this idea of placement boundaries. A “design model” provides context to any particular design decision, but that context necessarily changes depending on the specific situation (e.g. the set of both upstream and downstream assumptions). New perceptions of the situation surrounding a design decision lead us to test new possibilities (i.e. modify the model, create new blocks).
Additionally, this category vs. placement distinction appears to explicate the very conceptual issues that are raised when a design model is treated as a process model.
However, when a designer’s conceptual placements become categories of thinking, the result can be mannered imitations of an earlier invention that are no longer relevant to the discovery of specific possibilities in a new situation. Ideas are then forced onto a situation rather than discovered in the particularities and novel possibilities of that situation (p. 13).
The idea of wicked problems was created as alternative non-linear description of the design process and more closely resembles our conception of a process model rather than a design model. While the discussion of why design problems are “indeterminate” or “wicked” is certainly interesting, it did not seem directly applicable. The concept of placements is really the driving theory behind and critical takeaway from this particular paper.
Link(s)
Bibtex
@article{PSQ3:Buchanan:1992:Wicked,
Author = {Buchanan, Richard},
Copyright = {Copyright {\copyright} 1992 The MIT Press},
Issn = {07479360},
Journal = {Design Issues},
Language = {English},
Number = {2},
Pages = {pp. 5-21},
Publisher = {The MIT Press},
Title = {Wicked Problems in Design Thinking},
Volume = {8},
Year = {1992},
Bdsk-Url-1 = {http://www.jstor.org/stable/1511637},
Bdsk-Url-2 = {http://dx.doi.org/10.2307/1511637}
}
Notes
The relevant portions are buried in Chapters 5 and 6; the rest of the book, while fairly interesting is not particularly relevant.
Simon really drives at the idea that design is going to be hierarchical, based on the more general notion that complexity can be represented in hierarchical systems. He asserts that the level of complexity that must be addressed by design surpasses our ability to efficiently compute the optimal solution to a problem, leading to a bounded rationality approach to design – we search for a satisficing condition, a good enough solution. We are not seeking the best solution, despite constantly making design decisions according to views of paths being better or worse.
Our conceptions of the nested model very much follow a hierarchical framework (the nesting of levels, subdivisions into blocks and guidelines, etc.). Moreover we explicitly code relationships between different design decisions as acceptable vs. unacceptable, better, worse in an attempt to lead users to satisficing designs, because the incomplete nature of design space (the ability to create new blocks) will prevent for ever determining optimality. Very relevant ideas.
He lists some (possibly related) work on hierarchical design systems
There are also other ideas key to the nested model buried in his discussion
Integrating feedback mechanisms into the design process to handle the uncertainties present in the design space
Bibtex
@book{PSQ3:Simon:1996:Sciences,
author = {Simon, Herbert A.},
title = {The Sciences of the Artificial},
edition = "Third",
year = {1996},
isbn = {0-262-69191-4},
publisher = {MIT Press},
address = {Cambridge, MA, USA},
language = { English },
}
Notes
The goal of this paper was to create an explicit representation of the design decisions embedded in software architectures
Currently, almost all the knowledge and information regarding the design decisions on which the architecture is based on (e.g. results of domain analysis, architectural styles used, trade-offs made etc.) are implicitly embedded in the architecture, but lack a first class representation.
The authors attempt to do this by coming up with a design decision model for software architectrue. Now, a design decision model is defined as a special kind of knowledge system that attempts to capture the rationale behind each particular design decision. This means that the nested model is not quite a design decision model
In design, the main concern is which design decision to make. In development, it is important to know which and why certain design decisions have been taken.
The rationale referred to above falls into the latter category, the “which and why of certain design decisions. The authors do specify that ”some general design decision models [18] do facilitate the description of abstract elements of an architectural design decision model," suggesting some subset of design decision models will be more relevant for us. Even so, there is enough parallel in terms of the underlying model outlined in this particular paper to warrant further discussion.
Figure 1 presents our conceptual model for architectural design decisions. At the heart of the model is the Problem element, which together with the Motivation and Cause elements describes the problem, a Motivation why the problem is a problem, and the Causes of this problem. The Problem is the goal the architectural design decision wants to solve. The solutions element contains the Solutions that have been proposed to solve the problem at hand. A Decision is made, which solution should be used, resulting in an Architectural modification changing the Context.
Now we have to be a little careful here, the problem and corresponding design decision are a little different in scope than the nested model. The problem characterization is going to change for each design decision here, whereas multiple design decisions are guided by the same problem characterization and abstraction in the nested model. Still the breakdown similarity to the nested model at an abstract level is certainly striking .
Additionally, solution elements define, among other things, design rules and design constraints (i.e., specifications to which the realization of one or more architectural entities has to conform), as well as a concept of consequences, pros, and cons. This certainly isn’t a dead ringer for blocks and guidelines, but it seems like one could certainly project these solution elements into a space of blocks and guidelines.
The paper goes on to discuss a meta-model for software architecture that delves into a level of detail that appears to becomes fairly meaningless to us, but which represents the bulk of the author’s stated contribution.
As such, the usefulness of this paper seem primarily limited to conceptual model discussed above.
As a notable aside, however, design patterns are also mentioned but not described in detail enough for me to assess their relevance. The following quote suggest that I probably want to track down this source though: [note: the second quote actually comes first in the paper, and the first is an over-simplification from later in the paper; but this ordering seemed more relevant to this summary]
A design pattern is a special type of design decision. Design patterns [9] are sets of predefined design decisions with known functionality and behavior .
Design patterns [9] are often seen as predefined design decisions, which is not completely true. They define predefined parts of design solutions, which can be reused
Now I have quoted the relevant portion of this paper pretty heavily already, but I think the parallels strongly suggest a detailed read and consequent group discussion of this particular paper.
Link(s)
Bibtex
inproceedings{Jansen:2005,
Author = {Anton Jansen and Jan Bosch},
Booktitle = {Software Architecture, 2005. WICSA 2005. 5th Working IEEE/IFIP Conference on},
Pages = {109-120},
Title = {Software Architecture as a Set of Architectural Design Decisions},
Year = {2005},
Bdsk-Url-1 = {http://dx.doi.org/10.1109/WICSA.2005.61}
}
Notes
So this was the major cited source for design decision model from the Jansen and Bosch paper (though that particular term never actually showed up within this paper).
The paper is focused primarily on system that deal with design rationale systems, i.e. tracking the “why” of a particular design decision. This survey touches on applications from a number of different application domains, but none of them really exhibit the strong parallels to the nested model like the conceptual model for Archium described by Jansen and Bosch. The main purpose of design rationale systems is to explicate the reasoning behind design decisions, but for the purpose of communication in collaborative environments, rather than to reveal hidden assumptions. The systems surveyed for this paper deal primarily with how of design rationale collection which is not particularly relevant to us.
That said, design rationale systems still seems to be some similar high goals similar to those of the nested model, making them worth mentioning. A design rationale system still “intends to let designers think and discuss design within a certain knowledge representation framework,” even if the low level goals are slightly different.
There are different approaches to building design rationale systems. Process-oriented approaches emphasize a history of the design process, while a feature oriented approach “starts from the design space of an artifact,” considering the rules and knowledge of the domain in the decision making process. More over a feature oriented system is “usually developed in a task specific context using an emperical study.”
In a feature-oriented design rationale system, existing knowledge-bases usually support the generation of decision rationale, so representations of design rationale are usually more formal than in process oriented systems. In some systems, the design rationale is represented with links to the existing knowledge-base. The retrieval and reuse of design rationale is very natural in the design process of later artifacts.
Particularly with feature oriented approaches, design rationale systems are usually included in the design systems themselves, providing designers with active support to design / re-design processes such as the evaluation of design decisions and conflict resolution. The author’s assert that feature oriented approaches have a limitation insofar as only the requirements portion of the design rationale system can be handled in active design support; and that a hybrid combination of feature oriented and process approaches offers a more optimal logical structure.
Unfortunately the abstraction seems more relevant than any of the particular design rational systems. Part of the reason for this may be the fact that the different “representational schemas” described are geared toward the specific design requirements of areas other than visualization. The biggest problem prevent direct comparisons of any of these design rationale systems to the nested model, however, is that the nested model does not explicate rationale at the level sought by these models. The rationale for design decisions in the nested model depends on the current context (upstream and downstream assumptions) and relevant guidelines drawn from the body of visualization knowledge; but the rationale behind a particular design decision is not captured or tracked explicitly in the model. Well, I’m not entirely sure I can say that; rationale can certainly be inferred from the upstream network of blocks and guidelines within a particular nested model diagram. Still, none of the rationale representations described in the paper seem to offer a salient comparison.
The discussions of design rational capture and retrieval really aren’t relevant to us.
There is, however, a significant amount of discussion of design rationale systems supporting research in different application domains; i.e., design rationale being integrated in CAD tools, collaborative environments, artificial intelligence problem representation, conceptual design in chemical engineering, even machine learning applications. I can’t tell if it’s going to be useful to dig into the references or not; nothing jumped out at me reading though.
Despite the significant amount of work that has been done on design rationale systems, none of the existing systems have been adopted for widespread industrial use; “despite claims of the ‘great potential’ of design rationale systems, demonstrated successes are rare”. The authors posit that this is due to the fact that none of the existing systems are end-to-end solutions, supporting the generation, storage, and retrieval of design rationale information in a way that associates that information with the designed artifact. The authors conclude by outlining what they see as the future challenges for design rationale systems. Given the broad applications, the author’s final characterization of design rationale as a subproblem in knowledge management seems apt.
This subject is undoubtably related to the nested model, but I’m not entirely sure how to characterize that relationship at this point; it is probably a point we want to discuss as a group.
Link(s)
Bibtex
@article{Regli:2000,
Author = {Regli, William C. and Hu, Xiaochun and Atwood, Michael and Sun, Wei},
Issn = {0177-0667},
Journal = {Engineering with Computers},
Language = {English},
Number = {3-4},
Pages = {209-235},
Publisher = {Springer-Verlag London Limited},
Title = {A Survey of Design Rationale Systems: Approaches, Representation, Capture and Retrieval},
Volume = {16},
Year = {2000},
Bdsk-Url-1 = {http://dx.doi.org/10.1007/PL00013715},
Bdsk-Url-1 = {http://gicl.cs.drexel.edu/wiki-data/images/7/78/Eng-w-Computers2000-DesignRationale.pdf}
}
Notes
Surprising that the origins of wicked problems was so heavily focused on social studies and public policy; definitely not what I would have imagined based on descriptions of this work in Buchanan’s summarization, for example. As such certain properties of wicked problems have meanings very different from what I initially thought, and may not be as applicable to visualization design. The idea that “every solution to a wicked problem is a ‘one-shot operation’”, for example, specifically refers to the cases where every implemented solution is consequential.
It leaves “traces” that cannot be undone. One cannot build a freeway to see how it works, and then easily correct it after unsatisfactory performance. Large public-works are effectively irreversible, and the consequences they generate have long half-lives (p 163)
The sorts of design problems required for visualization are clearly not “irreversible” with “long term consequences”; they do not exhibit this property, at least not in the way originally intended by Rittel. Rather, we allow and expect designers to learn by trial and error at some level.
I hesitate to characterize wicked problems as a model (process, design, or otherwise)… It is a characterization of a problem type, but offers no concrete idea of how to attack or solve those problems. The paper offers a set of considerations, a list of the complexities faced by planners or designers: that context is key, that decisions don’t happen in a vacuum, etc.; but offers no guidance in understanding or formulating the context required for a particular decision. The nested model, on the other hand, actually provides a way to dig into the context surrounding a particular design decision during visualization design.
There is some applicability insofar as the same general issues faced by individuals trying to solve “wicked problems” must also be faced by those using the nested model – e.g. a lack of immediate validation.
The general takeaway, though, is that the concept of wicked problems simply provides a set of considerations; not an actual model for comparison.
Link(s)
Bibtex
@article{PSQ3:Rittel:1973:Dilemmas,
Author = {Rittel, Horst W. J. and Webber, Melvin M.},
Issn = {0032-2687},
Journal = {Policy Sciences},
Language = {English},
Number = {2},
Pages = {155-169},
Publisher = {Kluwer Academic Publishers},
Title = {Dilemmas in a general theory of planning},
Volume = {4},
Year = {1973},
Bdsk-Url-1 = {http://dx.doi.org/10.1007/BF01405730}
}
Notes
Provides a solid overview of the fragmented views of the design community regarding research through design. It is quite clear that there is a major problem regarding definitions within the design community. Everyone has their own opinions on where the lines get drawn between research through design, design research, and design practice. Like the Koskinen paper, Frayling’s distinction between research about, though, and for design is cited as the core classification for different types of design research, yet there appear to be significant differences between the definitions currently used by the community and those originally put forth by Frayling.
The relevant part of this article however has to do with the discussion of how design research leads to design theory.
[Design] theory takes several forms: conceptual frameworks, which often take the form of applying knowledge from the human science disciplines and applying it to design; guiding philosophies, which take the form of sensitizing concepts to help direct designers and researchers in solving design problems; implications for design that result from inquiry into wicked problems; and design implications arising from the analysis of designed artifacts… (p 313)
The discussions of conceptual framework and guiding philosophies are too brief for me to assess any direct relevance. Design implications on the other hand are effectively guidelines within the nested model.
Research through design is still relatively new; both the process itself and the theory it generates remain fairly unestablished. This paper seems to suggest that the theoretical frameworks or guiding philosophies are where any really relevant tidbits will be found, if they exist; but the references mentioned don’t really look helpful. It seems like further digging is warranted at this point, but we’re going to need a more guidance.
Link(s)
Bibtex
@inproceedings{Zimmerman:2010,
Address = {New York, NY, USA},
Author = {Zimmerman, John and Stolterman, Erik and Forlizzi, Jodi},
Booktitle = {Proceedings of the 8th ACM Conference on Designing Interactive Systems},
Isbn = {978-1-4503-0103-9},
Location = {Aarhus, Denmark},
Numpages = {10},
Pages = {310--319},
Publisher = {ACM},
Series = {DIS '10},
Title = {An analysis and critique of Research through Design: towards a formalization of a research approach},
Year = {2010},
Bdsk-Url-1 = {http://doi.acm.org/10.1145/1858171.1858228},
Bdsk-Url-2 = {http://dx.doi.org/10.1145/1858171.1858228}
}
Notes
I was really hoping this was going to turn out to be more useful than it did. The abstract was a little misleading; the better summary comes from the conclusion:
We present Promote, a taxonomy for process models based on six main axes: cycle, collaboration, artifacts, recommended use, maturity and flexibility, which are, in turn, divided into 34 sub- axes in order to evaluate each single characteristic of process mod- els. We prove the applicability of Promote through its axes description in classifying: XP, RAD and the Spiral Model. These illustrations highlight the differences and the similarities of these process models, and thus confirm that such a taxonomy is useful for understanding recommendations specific to a method and for comparing a process model to another. These examples illustrations also show how Promote supports discovery of methods as well as elicitation of their strengths, weaknesses and originalities. Finally, we presented a web site dedicated to Promote and reports the taxonomy evaluation conducted with two groups of students.
For a large part the taxonomy focuses in on the software development process (rather than the design process) at a level of specificity we don’t really care about: collaboration, project size, risks, etc…
There are a few models are mentioned with general characteristics like problem identification, that is invariably a classification for a set of techniques like “Cut and Try” or “Field Interview”… This gives us a hierarchical concept similar to model levels and blocks; but I’ll need to dig into those papers specifically
Other characteristics that may be relevant to guiding further exploration
Approach: Top-down (successively dividing into solvable sub-problems) vs. Bottom-Up (attempting to build a solution out of known components) approaches to design – nested model seems like it’s going to be some combination
Focus: process models can be activity, product, decision, context or goal oriented – nested model seems primarily context oriented (where context is considered “the combination of a situation and a decision”)
The Usage Centering discussion also includes this promising reference…
Ferreira et al. [86] study the main models of usage-centered design. According to them, the three core models are: the role model, that describes the relationships between users and the system, the task model, representing the structure of tasks that users will accomplish, and the content model, that abstracts the tools and materials to be supplied by the user interface. The use of these models constitutes an indication to evaluate if a process model is usage-centered.
All in all, my hesitation about this paper comes from the fact that we really want to be a level of abstraction above many of the systems being discussed (i.e. a design model, not a process model). When discussing process model flexibility and situational methods that compose method fragments, the authors explicitly caution:
But in fact, situational methods are not design methods: they are meta-methods leading to the construction of a method. The variants they offer are not selected by designers but by method engineers, who are sensed to take into consideration designers’ needs and requirements. Design and development choices are made at a high level of abstraction in an early stage of the project.
If the authors themselves are distinguishing the process methods they are using in classification from other design methods, that isn’t particularly encouraging. I’m going to guess that if there is something akin to the Nested Model in software engineering, this paper isn’t going to lead us to it. I’ll plan to dig into the references just to be sure though.
Link(s)
Bibtex
@article{Ceret:2013,
Author = {Eric Céret and Sophie Dupuy-Chessa and Gaëlle Calvary and Agnès Front and Dominique Rieu},
Issn = {0950-5849},
Journal = {Information and Software Technology},
Number = {5},
Pages = {795 - 821},
Title = {A taxonomy of design methods process models},
Volume = {55},
Year = {2013},
Bdsk-Url-1 = {http://www.sciencedirect.com/science/article/pii/S0950584912002285},
Bdsk-Url-2 = {http://dx.doi.org/10.1016/j.infsof.2012.11.002}
}
Notes
This is the origin paper for the heavily referenced sequential design model known as the Waterfall model.
When introducing collaborators to the nested model, they kept attempting to draw a direct comparison to the waterfall model; and as it is considered a stalwart model for software design processes, I figured it was worth investigating.
Unfortunately, the only meaningful comparisons come from understanding how it is not like the nested model. The model is primarily concerned with the software development process, glossing over the sorts of design decisions the nested model tries to make explicit. The model progresses through a set of stages:
One does not move on to the next stage until the current phase is completed and perfected. There are feedback loops between successive stages, but they exist to minimize the expensive rework involved in feedback across multiple stages. The emphasis of the model is to prevent late stage design requirement changes that costly software design changes.
(As a side note, they paper also includes the idea of a “build it twice” parallel prototyping step in the model; apparently one of the earlier references to this idea – interesting but not really relevant)
We can draw some general parallel between the emphasis on a proper understanding of requirements to a proper problem characterization / abstraction and the idea that a bad understanding of requirements will come back to bite you down the line. The reasoning behind the respective emphases, however, is quite different. Even looking at only its first 3 stages, the waterfall model is concerned with optimizing the workflow so that work isn’t done twice. The nested model, on the other hand, is concerned with creating a better product, encouraging a reexamination of earlier assumptions as understanding changes.
The waterfall model might provide a nice explicit comparative case for why attempting to use the nested model as a process doesn’t work (a big criticism of the nested model is the argument that it impossible for any non-trivial project to completely finish one phase before moving on to the next – discussed in Spiral Model), but that is probably about the extent of its usefulness at this time.
Link(s)
Bibtex
@inproceedings{PSQ3:Royce:1987:Managing,
Address = {Los Alamitos, CA, USA},
Author = {Royce, Walker W.},
Booktitle = {Proceedings of the 9th International Conference on Software Engineering},
Isbn = {0-89791-216-0},
Location = {Monterey, California, USA},
Numpages = {11},
Pages = {328 - 338},
Publisher = {IEEE Computer Society Press},
Series = {ICSE '87},
Title = {Managing the development of large software systems: concepts and techniques},
Year = {1987},
Bdsk-Url-1 = {http://dl.acm.org/citation.cfm?id=41765.41801},
Bdsk-Url-2 = {http://dx.doi.org/10.1145/41765.41801}
}
Notes
Good article (i.e. generally a recommended read), but not really relevant to our current endeavour. Talks about how scientific research, at it’s core, is very similar to doing design.
Introduces foundational concepts of:
Link(s)
Bibtex
%% not sure if this is should be cited as an article or tech-paper...
%% tech papers generally don't have volumes and numbers
@article{PSQ3:Frayling:1993:Research,
Address = {London},
Author = {Christopher Frayling},
Institution = {Royal College of Art},
Number = {1},
Pages = {1-5},
Publisher = {Royal College of Art Research Papers},
Title = {Research in Art and Design},
Volume = {1},
Year = {1993},
Bdsk-Url-1 = {http://researchonline.rca.ac.uk/384/}}
Notes Primarily concerned with establishing a concept of what design research should be; not really relevant to the nested model.
This article should not be read without reading the original Frayling article.
Despite beginning the paper by referencing Frayling, they either never actually read Frayling’s 5 page article to completion or they simply chose to attribute a completely different meaning to the term research through design than was originally specified by Frayling. The divisions outlined in this paper loosely follow Frayling’s distinction between research into, through, and for design, but manage to entirely lose sight of the general principles that made that distinction meaningful in the first place.
The authors explicitly try to throw away the philosophical underpinnings that were the basis of the foundational ideas that they cite. They do so in an attempt to distinguish design research from all other forms of research by eschewing the standards of other disciplines in terms of validation. The goal of “enriching the design field without making claims of reducing design to merely a branch of some existing science,” while laudable in a sense, is based on the notion that research through design and design research are synonymous; a notion I would assert is entirely unfounded given Frayling’s original definition of the term.
[Edit: In hindsight, that was probably a little harsh… see the Zimmerman summary for a more tempered discussion]
Link(s)
Bibtex
@article{PSQ3:Koskinen:2008:Lab,
Author = {Koskinen, Ilpo and Binder, Thomas and Redstr{\"o}m, Johan},
Journal = {Artifact},
Number = {1},
Pages = {46-57},
Title = {Lab, Field, Gallery, and Beyond},
Volume = {2},
Year = {2008},
Bdsk-Url-1 = {http://www.tandfonline.com/doi/abs/10.1080/17493460802303333},
Bdsk-Url-2 = {http://dx.doi.org/10.1080/17493460802303333}
}
Notes
Like the Waterfall model, the Spiral model is primarily deals with attempting “to determine the order of the stages involved in software development and evolution and to establish the transition criteria for progressing from one stage to the next.” It’s all about the software development process as opposed to explicating design decisions.
The paper outlines the upsides and downsides of various current models like the Waterfall model and other contemporaries (specifically, the Evolutionary Design model and Transform model – there are good summaries in the paper, but the emphasis on process means they’re similarly not very useful to us). The Spiral Model was designed in an attempt to integrate the strengths from all these models, while fixing their respective “weaknesses”. The major contribution in this area seems to come from the incorporation of a risk-driven design specification to “establish the traceability between itemized software requirements specifications, design elements, code elements, and test cases.” This specification is combined with rapid prototyping to attempt to minimize progression of the design down wrong paths through a combination of quick exploration and back-tracking.
As with the Waterfall model, the largest concern is being able to handle a requirement change gracefully, without having to rewrite all the code (i.e. preventing a bad problem characterization or abstraction); but there really no new relevant tidbits in this paper beyond those outlined in the Waterfall model discussion. The paper does, however, present us with a singular reference to dismiss a couple of contemporary process models as irrelevant as well, which may make a nice single sentence citation.
Link(s)
Bibtex
@article{PSQ3:Boehm:1988:Spiral,
Author = {Boehm, Barry W.},
Issn = {0018-9162},
Journal = {Computer},
Number = {5},
Pages = {61-72},
Title = {A spiral model of software development and enhancement},
Volume = {21},
Year = {1988},
Bdsk-Url-1 = {http://dx.doi.org/10.1109/2.59}
}
Notes
This paper has many of the right keywords; but in terms of content, turns out not to be particularly relevant.
The core idea behind Electronic Tool Integration (ETI) is to allow users to forego the installing software locally and instead provide an users with an interface for the remote execution of tools in a way that allows users to combine functionalities from different tools to achieve functionality they wouldn’t otherwise be able to obtain. Tools are added by providers, abstracted down to sets of data formats (types) and functionalities (activities). Activities are transformational entities individually represented as triples (input-type, activity-name, output-type); the take a component of type T_1 and output a component of type T_2. Analysis, simulation, validation and verification tools and algorithms are all modeled as input-output transformers so that they can be combined in various ways, “possibly with the help of translators (mediators) that act as format transformers”.
Activities and types are classified in separate taxonomies. Taxonomies are represented by DAGs with edges representing relationships between activities / types. Users specify what they want to achieve and the system figures out how to make the proper connections and data transformations to achieve that functionality. “This goal-oriented approach characterizes the difference between ETI’s coordination facility and other coordination approaches like UNIX piped commands, scripting languages”.
The similarity between this system and the Nested Model Blocks and Guidelines really ends at the fact that both are represented by DAGs of components decomposed from existing workflows. The data types and activities here are not at all concerned with abstraction in the sense we intend it. They’re based on task insofar as the choices are guided by some user’s definition of what functionalities they want to link; but that is a problem characterization based on what that user thinks they want, not necessarily what they need.
The focus and stated contribution of particular paper, moreover, lies in a revamping of the backend (i.e., the automatic linking of functionalities is retooled to work based on web protocols to create a distributed system to improve scalability, linking and allow a seamless orchestration of locally installed activities and remote activities). There’s really nothing relevant there.
We could mention this paper in passing as a structural comparison (decomposition of larger components into sets of relationships that get integrated into a single DAG), but that is as far as I’d go. The relationships defined and the context of uses between the respective DAGs is too divergent to draw further comparison.
Link(s)
Bibtex
@article{PSQ3:Margaria:2005:Web,
year={2005},
issn={1619-1366},
journal={Software & Systems Modeling},
volume={4},
number={2},
doi={10.1007/s10270-004-0072-z},
title={Web services-based tool-integration in the ETI platform},
Bdsk-Url-1={http://dx.doi.org/10.1007/s10270-004-0072-z},
publisher={Springer-Verlag},
pages={141-156},
language={English}
}