David S. Wile

University of Southern California, Los Angeles, CA, United States

Are you David S. Wile?

Claim your profile

Publications (50)7.85 Total impact

  • [Show abstract] [Hide abstract]
    ABSTRACT: We outline our approach to developing, a distributed capability to achieve shared situation awareness of mission status and trust relationships, anticipate and diagnose cyber threats, and respond strategically and tactically to those threats.
    Self-Adaptive and Self-Organizing Systems Workshops (SASOW), 2012 IEEE Sixth International Conference on; 01/2012
  • Source
    Conference Paper: Adapting COTS products
    [Show abstract] [Hide abstract]
    ABSTRACT: COTS products can play various architectural roles in software systems: as interfaces to problem-specific functionality, as components that provide such functionality itself, and as intermediary connectors and components in more complex systems. In doing so, COTS products impose their own, unique constraints on organization and functionality. Over the last ten years, we have gained considerable experience with adopting, adapting, and living with the limitations of COTS products. Our goal was to adapt the COTS product to make it fit the application rather than adapting the application needs to make them fit the COTS product - thus, in essence, adapting the COTS product without access to its source code or documentation (a unique form of maintenance). We report on a large set of experiences involving eight COTS products and a wide range of COTS-Based Software Systems - most of which were done with and for industrial partners or government agencies. This experience report attempts to both give a feeling for how applications can be augmented with such COTS interfaces and also tries to tease out the specific architectural issues that anyone adapting COTS products is certain to face.
    Software Maintenance (ICSM), 2010 IEEE International Conference on; 10/2010
  • [Show abstract] [Hide abstract]
    ABSTRACT: We have gained considerable experience with adapting COTS products to act variously as interfaces to problem-specific functionality and to provide such functionality itself. Several experimental implementations were based on a tool called the Briefing Associate that augmented Microsoft's PowerPoint to support the authoring of semantically grounded applications. Others were based on other Microsoft Office products, such as Access and Excel, and yet others were based on modeling tools such as IBM Rational Rose or Mathwork's MatLab. This report both gives a feeling for how applications can be augmented with such COTS interfaces and also discusses some of the problems that anyone adapting COTS tools is certain to face.
    Incorporating COTS Software into Software Systems: Tools and Techniques, 2007. IWICSS '07. Second International Workshop on; 06/2007
  • SASO; 01/2007
  • Source
    A. Egyed, D.S. Wile
    [Show abstract] [Hide abstract]
    ABSTRACT: The desirability of maintaining multiple stakeholders' interests during the software design process argues for leaving choices undecided as long as possible. Yet, any form of underspecification, either missing information or undecided choices, must be resolved before automated analysis tools can be used. This paper demonstrates how constraint satisfaction problem solution techniques (CSTs) can be used to automatically reduce the space of choices for ambiguities by incorporating the local effects of constraints, ultimately with more global consequences. As constraints typical of those encountered during the software design process, we use UML consistency and well-formedness rules. It is somewhat surprising that CSTs are suitable for the software modeling domain since the constraints may relate many ambiguities during their evaluation, encountering a well-known problem with CSTs called the k-consistency problem. This paper demonstrates that our CST-based approach is computationally scalable and effective-as evidenced by empirical experiments based on dozens of industrial models.
    IEEE Transactions on Software Engineering 06/2006; 32(5):299- 314. · 2.59 Impact Factor
  • Source
    [Show abstract] [Hide abstract]
    ABSTRACT: This document is the final report for AWDRAT, an effort in the DARPA funded Self-Regenerative System (SRS) program conducted by MIT and Teknolwedge. AWDRAT stands for Architectural Differencing, Wrappers, Diagnosis, Recovery, Adaptivity, and Trust Management. AWDRAT is a framework that provides survivability services to legacy (or new) applications, It does so by modeling the intended behavior of the application, using wrappers to instrument the application system and using the information derived from the wrappers to detect deviations from the expected behavior. When the application failed to behave as expected, AWDRAT invokes diagnostic services to determine what resources might have been compromised and then updates its trust model to reflect the probabilities of compromised resources. Recovery efforts are guided by the trust model, steering the system away from possibly comprised resources. AWDRAT was shown in both Red-Team and internal experiments to detect and correct failures at a level exceeding the goals of the SRS program.
    05/2006;
  • Source
    [Show abstract] [Hide abstract]
    ABSTRACT: This document is the final report for PMOP, a project of the DARPA/IPTO Self-Regenerative Systems (SRS) program performed by MIT and Teknowledge. Insiders are distinguished by the fact that they have been granted access to the system being defended, have been granted privileges on that system, and know how it operates. This means that traditional security mechanisms are ineffective against insiders. PMOP assumes that the insider has all the access needed for an attack, and focuses on detecting malicious behavior. Detection is based on unique sensors that monitor application-level user actions and an analyzer of the application-level user history relative to a role-based model of expected behavior that identifies both the types of behavior expected in a situation and the means for assessing the appropriateness of the behavior observed. The analyzer detects both intentional and accidental actions that harm the system. A suspicious behavior detector differentiates the two by inferring user goals and identifying plans consistent with that behavior. A level of suspicion is established by the relative degree to which the user's actions fit the role-based plans to the exclusion of the attack plans. The effects of suspected insider attacks are contained to protect the system.
    02/2006;
  • Source
    Robert M. Balzer, David S. Wile
    [Show abstract] [Hide abstract]
    ABSTRACT: The goals of the En-gauging Architectures project were (1) to provide community infrastructure that allows programmers to dynamically place probes and gauges into running systems, and (2) to provide dynamic architecture modeling support, specifically for architecture gauges and reconfiguration. In support of (1), our approach was to abstract the experience gained from the Instrumented Connector technology, which allows complex COTS systems running on the Windows platform to be probed, to identify a common run-time infrastructure for a variety of such probe technologies and the facilities needed for those probes to provide inputs to a broad set of gauges. Several DASADA contractors tested the viability of that design by implementing it for their own probe technologies. In support of (2), we developed a COTS infrastructure for analyzing and manipulating architecture models expressed in the Acme architecture description language. We used PowerPoint as an Acme Design Editor that monitors the actual run-time architecture of a system, reifies it into an Acme architecture model, and animates its dynamic behavior through architecture gauges reflected on the screen as a PowerPoint presentation.
    09/2004;
  • Source
    D.S. Wile, A. Egyed
    [Show abstract] [Hide abstract]
    ABSTRACT: Software architecture descriptions can play a wide variety of roles in the software lifecycle, from requirements specification, to logical design, to implementation architectures. In addition, execution architectures can be used both to constrain and enhance the functionality of running systems, e.g. security architectures and debugging architectures. Along with others from DARPA's DASADA program we proposed an execution infrastructure for so-called self-healing, self-adaptive systems - systems that maintain a particular level of healthiness or quality of service (QoS). This externalized infrastructure does not entail any modification of the target system - whose health is to be maintained. It is driven by a reflective model of the target system's operation to determine what aspects can be changed to effect repair. We present that infrastructure along with an example implemented in accord with it.
    Software Architecture, 2004. WICSA 2004. Proceedings. Fourth Working IEEE/IFIP Conference on; 07/2004
  • Source
    David S. Wile
    [Show abstract] [Hide abstract]
    ABSTRACT: Over the years, our group, led by Bob Balzer, designed and implemented three domain-specific languages for use in real applications. Each was invented to “showcase” DSL language design and implementation technology that was the focus of our then-current research. Each of these was actually a prototype for what would have taken more time to engineer and polish before putting into practice. Although each effort was essentially successful, none of the languages was ever followed up with the subsequent engineering efforts that we expected or at least hoped for. Herein I elaborate where these language efforts succeeded and where they failed, gleaning lessons for others who take the somewhat risky step of committing to develop a DSL for a particular user community.
    Science of Computer Programming 06/2004; 51:265-290. · 0.57 Impact Factor
  • Source
    David S. Wile
    [Show abstract] [Hide abstract]
    ABSTRACT: Although each application of self-management techniques encounters problems and solutions unique to the application domain, there are several cross-cutting "patterns of self-management" that can be discerned. Much like programming patterns, these patterns can occur in a variety of different guises, but having a fundamental set of such patterns can be useful for designers beginning to design a self-managed system or to those adapting a system not previously capable of managing itself. Herein I sketch some of these patterns using an "architectural style" designed to express common element types used for self-management, such as probes, gauges, and "effectors."
    Proceedings of the 1st ACM SIGSOFT Workshop on Self-Managed Systems, WOSS 2004, Newport Beach, California, USA, October 31 - November 1, 2004; 01/2004
  • Source
    David S. Wile
    [Show abstract] [Hide abstract]
    ABSTRACT: • Abstract Syntax – an intermediate representation capturing the essential concepts of the domain • Semantics Specification Mechanisms,and Issues o,Attribute Grammars, o,Transformations – within a language o,Translations – between languages o,(Other) Homomorphisms,– into algebraically similar structures o,Establishing transformation validity • Traversal Mechanisms o,Metaprogramming,Calculi – programs as data o,Strategies – heuristics for transformation o,Visitor patterns – a calculus for OO representations of AST transformations • Debugging Aids – errors related to source specifications and data structures • Re-engineering aids (inverses for each semantics specification mechanism) • Design recording aids o,Historical Development,– keeping track of a design history o,Pedagogical Development – when can a design history be replayed? o,Requirements-based Development – why are things as they are?
    01/2004;
  • D.S. Wile
    [Show abstract] [Hide abstract]
    ABSTRACT: Engineers wield various "calculi" to help determine solutions to their problems, calculation tools varying in power from tensile strength tables to the differential calculus. A calculus is normally based on induction over an algebraic structure. Here the author explores how architecture styles can be used to describe such structures. An example calculus based on an "integration" style is presented, which is intended for use as a substyle of other architecture styles. Calculation rules in terms of the architectural elements can be used to compute non-functional attributes of artifacts described in such styles. Naturally, computerized support for calculi will help to automate the tasks of software engineers.
    Automated Software Engineering, 2003. Proceedings. 18th IEEE International Conference on; 11/2003
  • David S. Wile
    [Show abstract] [Hide abstract]
    ABSTRACT: An underlying assumption in even using the phrase “component certification and system prediction” is that an understanding of individual components’ properties will lead to an understanding of a system’s properties by some form of compositional reasoning. Unfortunately, standard analytical composition techniques suffer from two problems: (1) they require that the internal structure of components be revealed in order to reason about them and (2) they deal clumsily with properties that require analysis of patterns of interaction. Here, based on the observation that a formal software architecture description itself is a constructive composition mechanism, I illustrate how the use of software architecture styles can sometimes alleviate the first problem and solve the latter.
    Journal of Systems and Software. 01/2003;
  • David S. Wile
    [Show abstract] [Hide abstract]
    ABSTRACT: Self-healing systems generally require reflective models of their own operation to determine what aspects of themselves they can change to effect repair. Architecture models are examples of rather simple models to which health information can be attached and reasoned about, e.g. attaching system state to a process or tracking events across connectors. These models are especially useful when the architecture of the system varies while the system is running, in so-called "dynamic architectures."DARPA's DASADA program is developing an architecture-based infrastructure for self-healing, self-adapting systems. Herein several protocols for dynamic architecture change notification from that program are examined in search of a community standard for such a protocol. Desirable properties of such protocols are suggested based in part on how much constraint checking will be used to proscribe dynamic architecture building activity. Points for discussion are raised.
    Proceedings of the First Workshop on Self-Healing Systems, WOSS 2002, Charleston, South Carolina, USA, November 18-19, 2002; 01/2002
  • Source
    David S. Wile
    [Show abstract] [Hide abstract]
    ABSTRACT: The use of domain-specific languages and development tools, such as those found in product-line development kits, have been shown to reduce programming and debugging costs considerably. At the same time, general-purpose Commercial, Off-The-Shelf (COTS) tools are improving rapidly. Moreover, providing security, privacy, reliability, and other Quality of Service (QoS) properties normally has little to do with the specific problem domains in which they are applied. Here, based on the observation that an architecture itself is a composition mechanism, I advocate the use of software architecture styles to provide a composition mechanism that retains the benefits of both domain-specific and general-purpose approaches.
    05/2001;
  • D.S. Wile
    [Show abstract] [Hide abstract]
    ABSTRACT: Monitoring running systems is a useful technique available to requirements engineers, to ensure that systems meet their requirements and in some cases to ensure that they obey the assumptions under which they were created. This report studies relationships between the original requirements and the monitoring infrastructure. It postulates that the monitored requirements are in fact just compilations of original requirements, called residual requirements. Dynamic architectural models have become important tools for expressing requirements on modem distributed systems. Monitoring residual requirements will be seen to involve architectural residues, skeletal run-time images of the original logical architecture. An example sales support system is used to illustrate the issues involved, employing modest extensions to the Acme architecture description language to reason about architectural dynamism
    Requirements Engineering, 2001. Proceedings. Fifth IEEE International Symposium on; 02/2001
  • Source
    A. Egyed, D. Wile
    [Show abstract] [Hide abstract]
    ABSTRACT: Software development is a constant endeavor to optimize qualities like performance and robustness while ensuring functional correctness. Architecture Description Languages (ADLs) form a foundation for modeling and analyzing functional and non-functional properties of software systems, but, short of programming, only the simulation of those models can ensure certain desired qualities and functionalities. The paper presents an adaptation to statechart simulation, as pioneered by D. Harel (1987). This extension supports architectural dynamism: the creation, replacement, and destruction of components. We distinguish between design-time dynamism, where system dynamics are statically proscribed (e.g., creation of a predefined component class in response to a trigger), and run-time dynamism, where the system is modified while it is running (e.g., replacement of a faulty component without shutting down the system). Our enhanced simulation language, with over 100 commands, is tool-supported
    Software Architecture, 2001. Proceedings. Working IEEE/IFIP Conference on; 02/2001
  • Source
    David S. Wile
    [Show abstract] [Hide abstract]
    ABSTRACT: A language tailored to the problem domain can focus on its idioms and jargon, avoiding clumsy, overly general constructs needed to support general-purpose language. The leverage provided by DSLs over conventional programming languages is often extreme; application engineers may specify as little as 2% of the code that one would need to program the same thing in a conventional programming language! But commitment to a DSL approach can be rather expensive. It is often difficult to know when to invest in exactly how much infrastructure support for a product or product family. All of the concerns that are germane to generalpurpose programming language design and support may become important in the support of a specific DSL. At the same time, there is a wide spectrum of approaches to providing DSL support. This paper relates the various DSL design approaches to alternatives for tool support, providing a kind of “DSL tool support selection framework,” indicating where one might expect to need to invest heavily to obtain adequate support and illustrating the spectrum of tradeoffs and situations in which each is appropriate.
    Journal of Computing and Information Technology (cit@srce.hr); Vol.9 No.4. 01/2001;
  • David S. Wile
    [Show abstract] [Hide abstract]
    ABSTRACT: The language AML was designed to specify the semantics of architecture description languages, ADLs, especially ADLs describing architectures wherein the architecture itself evolves over time. Dynamic evolution concerns arise with considerable variation in time scale. One may constrain how a system may evolve by monitoring its development lifecycle. Another approach to such concerns involves limiting systems' construction primitives to those from appropriate styles. One may wish to constrain what implementations are appropriate; concerns for interface compatibility are then germane. And finally, one may want to constrain the ability of the architecture to be modified as it is running. AML attempts to circumscribe architectures in such a way that one may express all of these constraints without committing to which time scale will be used to enforce them. Example AML specifications of the C2 style and Acme are presented.
    Automated Software Engineering 01/2001; 8:63-88. · 1.40 Impact Factor