A Challenge of Modeling How to Use an Architecture

Source: CiteSeer


ntrolled evolution of the software and increased amount of glue code used. As a result, less and less of the initial architecture is left or it is more difficult to find. By studying the software evolution in various case studies, Lehman et al. have noticed that adding new code typically causes increasing complexity, declining comprehendability, and increasing resistance to future changes [LPRTW97]. Designing a good architecture flexible for changes is a time consuming and challenging task. In addition, predicting future needs for changes is not easy if possible. Even though reusability and good software architecture is often desired, time-to-market usually counts. Recovering the architecture of a large software system, composed from various components (possibly distributed over the internet) is very difficult. Maintenance, reengineering, and reuse processes are often task-oriented. The re-engineer or (re)user typically wants to know how to use the archi

12 Reads
  • Source
    [Show abstract] [Hide abstract]
    ABSTRACT: It is becoming increasingly desirable to incorporate commercial-off-the-shelf (COTS) tools as software components into larger software systems. Due to their large user base, COTS tools tend to be cheap, reasonably reliable, and functionally powerful. Reusing them as components has the benefit of significantly reducing development cost and effort. Despite these advantages, developers encounter major obstacles in integrating most COTS tools because these tools have been constructed as stand-alone applications and make assumptions about their environment that do not hold when used as part of larger software systems. Most significantly, while they frequently contain programmatic interfaces that allow other components to obtain services from them on a direct call basis, they almost always lack the notification and data synchronicity facilities required for active integration. The authors present an integration framework for adding these notification and data synchronization facilities to COTS tools so that they can be integrated as active software components into larger systems. We illustrate our integration framework through tool suites we constructed around Mathworks' Matlab/Stateflow and Rational's Rose (two widely-used, large COTS tools). Our experience to date is that it is indeed possible to transform standalone COTS tools into software components.
    Automated Software Engineering, 2001. (ASE 2001). Proceedings. 16th Annual International Conference on; 12/2001
  • Source
    [Show abstract] [Hide abstract]
    ABSTRACT: The book is an introduction to the idea of design patterns in software engineering, and a catalog of twenty-three common patterns. The nice thing is, most experienced OOP designers will find out they've known about patterns all along. It's just that they've never considered them as such, or tried to centralize the idea behind a given pattern so that it will be easily reusable.
  • [Show abstract] [Hide abstract]
    ABSTRACT: Shimba is a reverse engineering environment to support the understanding of Java software systems. Shimba integrates the Rigi and SCED tools to analyze and visualize the static and dynamic aspects of a subject system. The static software artifacts and their dependencies are extracted from Java byte code and viewed as directed graphs using the Rigi reverse engineering environment. The run-time information is generated by running the target software under a customized SDK debugger. The generated information is viewed as sequence diagrams using the SCED tool. In SCED, statechart diagrams can be synthesized automatically from sequence diagrams, allowing the user to investigate the overall run-time behavior of objects in the target system.Shimba provides facilities to manage the different diagrams and to trace artifacts and relations across views. In Shimba, SCED sequence diagrams are used to slice the static dependency graphs produced by Rigi. In turn, Rigi graphs are used to guide the generation of SCED sequence diagrams and to raise their level of abstraction. We show how the information exchange among the views enables goal-driven reverse engineering tasks and aids the overall understanding of the target software system. The FUJABA software system serves as a case study to illustrate and validate the Shimba reverse engineering environment. Copyright © 2001 John Wiley & Sons, Ltd.
    Software Practice and Experience 04/2001; 31(4):371-394. DOI:10.1002/spe.386 · 0.90 Impact Factor


12 Reads
Available from