Scott A. Hendrickson’s research while affiliated with University of California, Irvine and other places

What is this page?


This page lists works of an author who doesn't have a ResearchGate profile or hasn't added the works to their profile yet. It is automatically generated from public (personal) data to further our legitimate goal of comprehensive and accurate scientific recordkeeping. If you are this author and want this page removed, please let us know.

Publications (12)


Figure 1. Extensional Model 
Figure 2. Change Sets and Relationships 
Figure 3. New Optional-Variant 
Figure 4. New Change Set 
Figure 5. New Optional Component 

+1

Modeling PLA Variation of Privacy-Enhancing Personalized Systems
  • Conference Paper
  • Full-text available

January 2009

·

57 Reads

·

3 Citations

Scott A. Hendrickson

·

Yang Wang

·

·

[...]

·

Privacy-enhancing personalized (PEP) systems address individual users' privacy preferences as well as privacy laws and regulations. Building such systems entails model- ing two different domains: (a) privacy constraints as man- dated by law, voluntary self-regulation, or users' individ- ual privacy preferences, and modeled by legal profession- als, and (b) software architectures as dictated by available software components and modeled by software architects. Both can evolve independently, e.g., as new laws go into effect or new components become available. In prior work, we proposed modeling PEP systems using a product line ar- chitecture (PLA). However, with an extensional PLA, these domain models became strongly entangled making it diffi- cult to modify one without inadvertently affecting the other. This paper evaluates an approach towards modeling both domains within an intensional PLA. We find evidence that this results in a clearer separation between the two domain models, making each easier to evolve and maintain.

Download

Multi-tiered design rationale for change set based product line architectures

May 2008

·

29 Reads

·

4 Citations

Knowledge of why some product line architecture (PLA) consists of the specific features and feature interactions that constitute its overall structure is an invaluable resource for an architect. However, most PLA modeling techniques do not model these concepts explicitly. This requires that the architect express rationale separately, which increases the likelihood that it diverges and slowly but surely loses its value. To address this, we present an approach to capturing rationale that relies on a particular form of PLA modeling, namely PLAs modeled using change sets and relationships. In so doing, we enable the architect to express rationale concerning the PLA at three different tiers, covering individual elements in the PLA, change sets and their raison d'être, and the relationships that govern how individual product architectures are composed.



Figure 2. New Basic audio player version. 
Table 2 . Audio player PLA change sets.
Figure 3. EASEL. Relationships are Labeled R1 to R9 for Reference. specifying PLAs and a variability spreadsheet for man- sheet), annotating the CD Reader / Writer component, aging change sets and relationships. its interfaces, and its links with a “ + ” to show that these If none of the special features of EASEL are used, elements are added, and the CD Reader component, its the drawing canvas of EASEL operates similarly to interface, and its link with an “ × ” to show that these ArchStudio [12] or AcmeStudio [33], allowing an ar- elements are removed. Elements that are not a part of chitect to define single architectures. But, the drawing the final result, but that are changed by a selected canvas has additional behaviors that bring it into the change set, are drawn using lighter, transparent colors. realm of PLA modeling by implementing the concepts Selecting multiple change sets results in annotations discussed in Section 4. First, it is actually a “layered that would result from logically combining them. canvas,” with each layer representing a change set. The The third and final additional behavior lies in how visible architecture, then, is constructed from the an architect populates the contents of change set. In change sets selected by the first column of the variabil- EASEL, modifications are incorporated into the change ity spreadsheet. For example, the architecture shown in set currently selected for editing. In Figure 3, any addi- Figure 3 is a result of the Pro , Baseline , Record Sup- tion or removal made by an architect at this time would port , CD Writer , and MP3 Encoder change sets. be incorporated into the Baseline change set, as high- To realize our approach, EASEL stores change sets, lighted. This allows an architect to revisit and update a relationships, and the resulting architecture internally change set as easily as creating a new one. using XML. Thus, changes can be consistently re- The variability spreadsheet shown on the right hand corded and reapplied using the XML element ID’s and side of Figure 3 provides an architect with a graphical property names, which are globally unique and remain representation through which they manage relation- constant. It would be difficult to use textual diffs for ships. Rows represent change sets and the columns this purpose, since they use adjacent lines of text to relationships. The following symbols are used: determine where a change is to be applied, and these • A circle is a source of an or relationship (e.g., A in can potentially be modified by other change sets. Still, “if A or B are included, then C must be also”). and even with the specialized merging process, con- • A square is a source of an and relationship (e.g., A flicts may occur when change sets modify the exact in “if A and B are included, then C must be also”). same element in an incompatible way, i.e., two change sets that each rename a component, but to a different • A slash superimposed over a circle or square repre- name. In such cases, the order in which change sets are sents a source negation (e.g., B in “if A is included listed is used to resolve the conflict. and B is not included, then C must be included”). The second additional behavior is that each of the • A plus is a change set implied by a relationship (e.g., elements on the drawing canvas may be annotated to C in “if A is included, then C must be included ”). explicitly illustrate what specific changes are recorded. • An X is a change set excluded by a relationship (e.g., In Figure 3, the CD Writer change set is selected as C in “if A is included, then C must be excluded ”). such (see second column of the variability spread- 
Figure 3. EASEL. Relationships are Labeled R1 to R9 for Reference.
Table 3 . Modeling compactness.
Modeling Product Line Architectures through Change Sets and Relationships

June 2007

·

97 Reads

·

58 Citations

Proceedings - International Conference on Software Engineering

The essence of any modeling approach for product line architectures lies in its ability to express variability. Existing approaches do so by explicitly specifying variation points inside the architectural specification of the entire product line, usually with optional and alternative elements of some form. This, however, leads to a sizable mismatch between conceptual variability (i.e., the features through which architects logically view and interpret differences in product architectures) and actual variability (i.e., the modeling constructs through which the logical differences must be expressed). We contribute a new product line architecture modeling approach that unites the two. Our approach uses change sets to group related architectural differences and relationships to govern which change set combinations are valid when composed into a particular product architecture. The result lifts modeling of variability out of modeling architectural structure, consolidates related variation points, and explicitly and separately manages their compatibilities.


Fig. 1. Alternative designs for a hypothetical graph data model 
Fig. 2. Screen shot of EASEL. The relationships are labeled R1 through R8 for reference 
Layered Class Diagrams: Supporting the Design Process

October 2006

·

288 Reads

·

5 Citations

Lecture Notes in Computer Science

Class diagrams model a system's classes, their inter-relationships, op- erations, and attributes and are used for a variety of purposes including explora- tory 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 seman- tic relationships among layers.


Figure 1. The chat system architecture 
Table 2 . Behavior modifiers for our example system
Figure 3. Steps involved in weaving the Authentication behavior modifier into the Basic Client statechart before the Idle state.
Towards Supporting the Architecture Design Process Through Evaluation of Design Alternatives

July 2006

·

2,030 Reads

·

10 Citations

This paper addresses issues involved when an architect explore alternative designs including non-functional requirements; in our approach, non-functional requirements are expressed as state- charts. Non-functional requirements greatly impact the resulting design of a system because they naturally conflict with each other, crosscut the system at multiple points, and may be satisfied in a number of different ways. This makes correctly designing them early in the software lifecycle critical, since correcting them later can be extremely costly. Our approach supports an architect generating and evaluating many different design alternatives. This explorative process is not well supported by current techniques, which focus on documenting the result of this process, but not on assisting the designer during this process. We present an architec- ture-based approach that supports exploration of non-functional requirements expressed as statecharts. Our approach captures design alternatives of non-functional requirements separately, composes different system designs from these alternatives using a novel weaving technique, and analyzes the resulting design for specific qualities using simulation.


Solid state thermochemical decomposition of neat 1,3,5,5-tetranitrohexahydropyrimidine (DNNC) and its DNNC-d 6 perdeuterio-labeled analogue

January 2006

·

12 Reads

·

4 Citations

Thermochimica Acta

The solid state thermochemical decomposition kinetics and activation energy of neat 1,3,5,5-tetranitrohexahydropyrimidine (DNNC) and its DNNC-d6 deuterium labeled analogue were obtained by isothermal differential scanning calorimetry (IDSC) at 142, 145, and 148°C. Global rate constants and kinetic deuterium isotope effect (KDIE) data from the exothermic decomposition process suggest that homolytic CH bond rupture, in one or both types of chemically non-equivalent methylene (CH2) groups of the DNNC ring structure, constitutes the exothermic rate-controlling step. A DNNC-d6 energy of activation equal to 115kJ/mol was determined for this initial autocatalytic exothermic energy release from which a 106kJ/mol activation energy was calculated for unlabeled DNNC. This exothermic autocatalytic decomposition process follows an extended endothermic induction period for DNNC which shows a higher 128kJ/mol activation energy during which a catalytic initiating species may form by a rate-controlling step different from CH bond rupture.


Fig. 1. ArchEvol Overview.  
Fig. 2. ArchEvol Subversion Directory Structure.  
Fig. 3. ArchEvol Editing Process.  
ArchEvol: Versioning architectural-implementation relationships

September 2005

·

81 Reads

·

25 Citations

Previous research eorts into creating links between software architecture and its implementations have not explicitly addressed ver- sioning. These earlier eorts have either ignored versioning entirely, cre- ated overly constraining couplings between architecture and implemen- tation, or disregarded the need for versioning upon deployment. This situation calls for an explicit approach to versioning the architecture- implementation relationship capable of being used throughout design, implementation, and deployment. We present ArchEvol, a set of xADL 2.0 extensions, ArchStudio and Eclipse plug-ins, and Subversion guide- lines for managing the architectural-implementation relationship through- out the entire software life cycle.


An (Architecture-centric) approach for tracing, organizing, and understanding events in event-based software architectures

June 2005

·

43 Reads

·

10 Citations

Applications built in a strongly decoupled, event-based interaction style have many commendable characteristics, including ease of dynamic configuration, accommodation of platform heterogeneity, and ease of distribution over a network. It is not always easy, however, to humanly grasp the dynamic behavior of such applications, since many threads are active and events are asynchronously (and profusely) transmitted. This paper presents a novel, complete approach that aids in the understanding, debugging, and visualization of the behaviors of event-based applications. It applies to real, implemented systems, without requiring the presence of component source code, and supports partial or incomplete, heuristic behavior specifications. A prototype implementation of our approach was applied to two systems, including the prototype itself, indicating that our approach is feasible, scalable, and shows promising results in terms of increasing the understandability of these types of systems.


PACE: An architectural style for trust management in decentralized applications

July 2004

·

122 Reads

·

27 Citations

Distributed applications that lack a central, trustworthy authority for control and validation are properly termed decentralized. Multiple, independent agencies, or "partners", cooperate to achieve their separate goals. Issues of trust are paramount for designers of such partners. While the research literature has produced a variety of trust technology building blocks, few have attempted to articulate how these various technologies can regularly be composed to meet trust goals. This paper presents a particular, event-based, architectural style, PACE, that shows where and how to incorporate various types of trust-related technologies within a partner, positions the technologies with respect to the rest of the application, allows variation in the underlying network model, and works in a dynamic setting. Initial experiments with variants of two sample decentralized applications developed in the PACE style reveal the virtues of dealing with all aspects of application structure and trust in a comprehensive fashion.


Citations (12)


... Crystal structure of DNNC was studied by Oyumi et al. [9]. Thermo chemical decomposition studies of DNNC have been published by Shackelford and Goldman [10][11][12]. The heat of fusion for DNNC and its DNNC-d 6 analogue compound have been determined using differential scanning calorimetry analysis. ...

Reference:

Some Isomers of DNNC and Radicals from Them - A DFT Treatment
Solid state thermochemical decomposition of neat 1,3,5,5-tetranitrohexahydropyrimidine (DNNC) and its DNNC-d 6 perdeuterio-labeled analogue
  • Citing Article
  • January 2006

Thermochimica Acta

... Asynchronous systems are concurrent systems that read and respond messages as schedules permit. There is no assumption of a global clock or ordering of execution among any two components (the sender and the receiver) [56]. This means that a component may send a message at any time, and may receive a message at any time, and also that a message that arrives to a component would have to wait an undefined period of time to be processed. ...

An Approach for Tracing and Understanding Asynchronous Systems
  • Citing Article
  • December 2002

... However, we will not deal with this topic further, as it is out of the scope of this article, and it will be considered for future work. Of course, all of this reasoning should not be confused with decisions about relationships or connectors in the target architecture, which are also described in, e.g. [31]; obviously, these are just described using regular DDs and do not affect the topic. ...

Multi-tiered design rationale for change set based product line architectures

... At the other extreme, we may have projections that include all elements from another projection plus specific ones. In our example, Projection 4 of Fig. 3 is an illustration of this case by completing Projection 1. 3 Building projections on top of others could be interesting to follow or reconstruct an incremental modeling process as proposed in [29,43]. ...

Layered Class Diagrams: Supporting the Design Process

Lecture Notes in Computer Science

... There are at least five areas of traceability that belong to horizontal traceability. These can be explained as horizontal traceability between requirement artifact and coding artifacts [10], requirement artifact and testing artifacts [11], requirement artifact and design artifacts [12], requirement artifact and defect reports [13] and design artifact and coding artifacts [14]. ...

ArchEvol: Versioning architectural-implementation relationships

... Tim pengabdian mempresentasikan beberapa alternatif rancangan. Menurut Xu et al. (2006), alternatif rancangan digunakan untuk mengevaluasi dan menggali lebih dalam lagi mengenai preferensi dan gagasan desain yang diterima klien dalam hal ini adalah masyarakat. Hal ini juga akan mendorong partisipasi masyarakat dalam proses rancangan sehingga dapat meningkatkan rasa memiliki warga terhadap bangunan balai RW nantinya. ...

Towards Supporting the Architecture Design Process Through Evaluation of Design Alternatives

... The first rationale (Figure 1) is variation in the user and usage needs: some users prefer or require a different level of quality than others. Such a rationale may stem from different user, physical, social and business contexts [27], different geographical market segments [20], " high-end " and " low-end " segments [23, 24, 26], different privacy legislations and users' preferences [38, 15], dynamic usage changes, like user's hands becoming busy with other things [14], and even evolution of the data volumes and load over time [16]. The second rationale (Figure 1) is variation in hardware,Figure 1: Rationale and possible strategies resources, or functionality that directly affect the product quality attributes. ...

Modeling PLA Variation of Privacy-Enhancing Personalized Systems

... ADLARS [5], an architecture description language, captures variability information from feature models and links them to architecture structure using keyword descriptions. ArchStudio4 [16] is an open-source tool that implements an environment of integrated tools for modeling, visualizing, analyzing, and implementing software and systems architectures. For variability management, ArchStudio has a tool called product line selector with a user interface that enables graphically invoking the Selector, Pruner, and Version Pruner components. ...

ArchStudio 4: An Architecture-Based Meta-Modeling Environment
  • Citing Conference Paper
  • June 2007

Proceedings - International Conference on Software Engineering

... Figure 3B shows EASEL and its tool and graphic interface support. It is divided in two separate areas including a drawing PLA area and a spreadsheet with configuration support where it is possible to manage change sets and relationships among each component (Hendrickson and Hoek 2007). representing this information in a hierarchical vertical tree view where variants can be selected at configuration time with tool support. ...

Modeling Product Line Architectures through Change Sets and Relationships

Proceedings - International Conference on Software Engineering

... Other researchers have placed different types of artifacts at the center of the traceability process. For example, Hendrickson et al. [27] focus traces around architectural concerns instead of requirements. In practice, traces can originate from and be traced to any artifact in either direction. ...

An (Architecture-centric) approach for tracing, organizing, and understanding events in event-based software architectures
  • Citing Conference Paper
  • June 2005