Software architecture critics in the Argo design environment

Robbins, Jason E.; Redmiles, David

doi:10.1016/s0950-7051(98)00055-0

Cited by 47 publications

(36 citation statements)

References 37 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…As we discuss below, however, EASEL does inform the designer of compositions that violate relationships. Thus, relationships act as design critics [14] rather than hard constraints. Without allowing invalid designs, exploring new design alternatives would be difficult.…”

Section: Easelmentioning

confidence: 99%

See 1 more Smart Citation

Layered Class Diagrams: Supporting the Design Process

Hendrickson

Jett

Hoek

2006

Model Driven Engineering Languages and Systems

View full text Add to dashboard Cite

Abstract. Class diagrams model a system's classes, their inter-relationships, operations, and attributes and are used for a variety of purposes including exploratory design, communication, and evaluation. However, traditional diagrams, and the tools used to create them, focus on capturing a single configuration -the product of the design process -rather than supporting the explorative design process itself that is used to create and evolve a design over time. This process involves iteration over multiple alternatives and evaluation of those alternatives. We present a layered approach and environment that encourages this process by capturing a design and its alternatives using layers. Layers may be combined with other layers to compose and explore new design alternatives for evaluation. Our tool provides mechanisms for creating, composing, and visualizing layers as well as detecting dependencies and conflicts among layers and managing semantic relationships among layers.

show abstract

Section: Easelmentioning

confidence: 99%

“…These relationships serve as critics [14] and disappear when particular dependencies or conflicts no longer exist. Hence, automatically detected relationships assist a designer during the design process, as they inform them of the fact that their current design is exhibiting some relationships that may or may not have been intended.…”

Section: R8mentioning

confidence: 99%

Layered Class Diagrams: Supporting the Design Process

Hendrickson

Jett

Hoek

2006

Model Driven Engineering Languages and Systems

View full text Add to dashboard Cite

show abstract

“…It enables user to enter CCL expressions, and it integrates the verification of these CCL expressions into the Design Critiques ( [32]) mechanism of ArgoUML. This mechanism continuously runs as a background process in ArgoUML.…”

Section: Proof Of Concept Toolmentioning

confidence: 99%

Keeping track of crosscutting requirements in UML models via context-based constraints

Bübl

2006

Companion to the 21st ACM SIGPLAN Symposium on Object-Oriented Programming Systems, Languages, and Applications

View full text Add to dashboard Cite

One crosscutting requirement (also called aspect) affects several parts of a software system. Handling aspects is well understood at source-code level or at runtime. However, only a few aspectoriented approaches handle other software artefact types, like UML models, configuration files, or database schema definitions. Instead of re-writing the same aspect newly for each artefact type, this paper suggests to write down aspects independent of artefact types.But, wait a minute: Where do we weave in an aspect if its pointcut doesn't refer to artefact details? Which places does such an aspect affect? This paper suggests expressing aspects via ContextBased Constraints (CoCons). They select their constrained system elements according to the element's context. For instance, CoCons affect all system elements used in a certain department, workflow, or location. CoCons are easy to grasp for users and customers because they express business requirements without referring to technical details. This paper focuses on how to express crosscutting requirements in UML models via CoCons and compares CoCons to the Object Constraint Language OCL.

show abstract

“…Bosch (2000) presents a case study on the possibilities for organizing software product lines, but discusses only little about the varying rationales in architecture design and description. Robbins and Redmiles (1998) consider the idea of diverse knowledge and the theory of reflection-in-action (SchOn 1983), but focus on the design work of a single architect leaving other interests untouched. Kruchten (1999) draws on consulting experience, illustrating the diversity of architects' role, and recommends how architecture teams should be built and operated.…”

mentioning

confidence: 99%