Abstract: Text with(bad spacing)and[brackets ].

Abstract: System builders have historically used informal software architecture models to understand options, make choices, and communicate with others. Research into software architecture over the past fifteen years has indicated that more precise architecture models may be beneficial. At a large financial firm, we applied precise software architecture techniques on four software projects and this experience has revealed a number of practical issues. We made the following observations across the projects: 1) Architecture models can be used to bridge gaps between business requirements and technology, 2) A small collection of techniques and a detail knob are practical and useful in a variety of projects, 3) Architecture modeling techniques amplify the skills of the architects, 4) A model of domain concepts and relationships is helpful when building architecture models, and 5) It is difficult to know when to stop adding detail to your architecture model. We believe that these observations motivate future research and can help practitioners make software architecture more effective in practice.

Abstract: Modern software engineering environments provide programmers with contextual information on methods and classes in their software system. However, programmers increasingly encounter frameworks such as Microsoft Foundation Classes or Enterprise Java Beans whose required plug-in mechanisms cannot be adequately described with method or class documentation. The needs of programmers using frameworks are different from the needs when using libraries. Software engineering environments should be augmented with tools to aid programmers in understanding the demands of using frameworks.

Abstract: A large financial company, struggling with legacy systems that did not interoperate, performed a pilot project to teach software architecture to an enthusiastic application development team. Experienced mentors, including the author, worked with the application team for seven months who completed their engineering goal successfully. However, the mentors were unsuccessful in their attempt to train any of the six members of application team to create architecture models on their own, though they were able to create them collaboratively with the mentors. This surprising result is due to the application team's strong preference for concrete artifacts over abstract ones. Even more surprising, an application developer from a different project, 'Developer X', read the architecture modeling documentation on an internal website and, without mentoring, created good architecture models within a few days. In light of this failure to teach software architecture, two short-term strategies are suggested for the use of software architecture in companies and long-term strategies are discussed.

Abstract: Frameworks are a valuable way to share designs and implementations on a large scale. Client programmers, however, have difficulty using frameworks. They find it difficult to understand non-local client-framework interactions, design solutions when they do not own the architectural skeleton, gain confidence that they have engaged with the framework correctly, represent their successful engagement with the framework in a way that can be shared with others, ensure their design intent is expressed in their source code, and connect with external files. A design fragment is a specification of how a client program can use framework resources to accomplish a goal. From the framework, it identifies the minimal set of classes, interfaces, and methods that should be employed. For the client program, it specifies the client-framework interactions that must be implemented. The structure of the client program is specified as roles, where the roles can be filled by an actual client program¡Çs classes, fields, and methods. A design fragment exists separately from client programs, and can be bound to the client program via annotations in their source code. These annotations express design intent; specifically, that it is the intention of the client programs to interact with the framework as specified by the design fragment. The thesis of this dissertation is: We can provide pragmatic help for programmers to use frameworks by providing a form of specification, called a design fragment, to describe how a client program can correctly employ a framework and by providing tools to assure conformance between the client program and the design fragments. We built tools into an IDE to demonstrate how design fragments could alleviate the difficulties experienced by client programmers. We performed two case studies on commercial Java frameworks, using demo client programs from the framework authors, and client programs we found on the internet. The first case study, on the Applet framework, yielded a complete catalog of twelve design fragments based on our analysis of fifty-six Applets. The second case study, on the larger Eclipse framework, yielded a partial catalog of fourteen design fragments based on our analysis of more than fifty client programs. This work provides three primary contributions to software engineering. First, it provides a new technique to help programmers use frameworks. Second, it provides a systematic way to increase code quality. Design fragments provide a means to communicate known-good designs to programmers, and, unlike simple copying of examples, a means of influencing the uses of that design so that revisions can be propagated. Third, it provides an empirically-based understanding of how clients use frameworks, which aids researchers in choosing research directions and aids framework authors in delivery of new frameworks.