Component based software engineering has been perceived to have immense reuse potential. This area has evoked wide interest and has led to considerable investment in research and development efforts. Most of these investigations have explored internal characteristics of software components such as correctness, reliability, modularity, interoperability, understandability, maintainability, readability, portability and generality for promoting reuse. But experience over the past decade and a half has demonstrated that the usefulness of a component depends as much on the context into which it fits as it does on the internal characteristics of the component. Software architecture descriptions that take into account the requirements of the domain can be used to serve as this context. While the Perry, Wolf definition of software architecture has been widely acknowledged, a number of architectural description languages (ADL) have emerged that aim to capture various facets of a software, using varying degrees of formalism. There is currently no agreement towards a standard approach for documenting software architectures which would help define the vocabulary for architectural semantics. In spite of lack of any specification standards for components, Software Product Lines (SPL) and Commercial Off The Shelf (COTS) components do provide a rich supporting base for creating software architectures and promise significant improvements in the quality of software configurations that can be composed from pre-built components. However, further research is needed for evaluation of architectural merits of such component based configurations. In this research, we identify the key aspects of software that need to be specified to enable useful analysis at an architectural level. We also propose a set of metrics that enable objective evaluation of reusability potential. Architectural research has established that software architectural styles provide a way for achieving a desired coherence for component-based architectures. Different architectural styles enforce different quality attributes for a system. Thus, if the architectural style of an emergent system could be predicted, a person playing the role of a system integrator could make necessary changes to ensure that the quality attributes dictated by the system requirements were satisfied before the actual system is built and deployed, thus somewhat mitigating project risks. As part of this research, we propose a model for predicting architectural styles based on use cases that need to be satisfied by a system configuration and demonstrate how our approach can be used to determine stylistic conformance. We also propose objective methods for assessing architectural divergence, erosion and drift during system evolution and maintenance. / text

Thesis (MTech. degree in Software Development.)--Tshwane University of Technology, 2011 / With regards to extending component-based and service-oriented system development approaches and solving current problems related to enterprise systems, this study will explore the requirements and challenges of current enterprise systems, and define an SCSD (Service-oriented Component-based System Development) framework which would provide all-round service-oriented component-based support for a complex application environment. The purpose of this study is to create a novel SCSD framework which combines the features of both component-based and service-oriented paradigms, as well as avoid the weaknesses of the existing service and component combination approaches. The SCSD framework combines the re-usability of the component-based paradigm and the flexibility of the service-oriented paradigm. Reusable SCSD-based components and services can reduce costs, shorten development time, and improve service quality when implemented effectively. The SCSD framework offers an alternative to older system development approaches, while it also provides a new solution in order to establish relationships between services and components for current enterprise systems.

Software systems today face many challenges that were not even imagined decades prior. Challenges including the need to evolve at a very high rate, lifecycle phase drift or erosion, inability to prevent the butterfly effect where the slightest change causes unimaginable side effects throughout the system, lack of discipline to define metrics and use measurement to drive operations, and no "silver bullet" or single solution to solve all the problems of every domain, just to name a few. This is not to say that the issues stated above are the only problems. In fact, it would be impossible to list all possible problems--software itself is infinitely flexible bounded only by the human imagination. These are just a portion of the primary challenges today's software engineer faces. There have been attempts throughout the history of software to resolve each one of these challenges. There have been those who tried to tackle them individually, simultaneously, as well as various combinations of them at one time. One such method was to define and encapsulate the various phases within software, which has come to be called a software lifecycle or lifecycle model. Another area of recent research has lead to the hypothesis that many of these challenges can be resolved or at least facilitated through proper traceability methods. Virtually none of today's software components are completely derived from scratch. Rather, code reuse and software evolution become a large portion of the software engineer's duties. As Vance Hilderman at HighRely puts it, "Research has shown that proper traceability is vital. For high quality and safety-critical engineering development efforts however, traceability is a cornerstone not just for achieving success, but to proving it as well." So if software is not derived from scratch, having the traceability to know about its origination is invaluable. Given today's struggles, what is in store for the future software engineer? This paper is an attempt to quantify and answer (or at least project a possibility) that involves a new mindset and a new lifecycle model or structure change that may assist in tackling some of the above referenced issues. / text

Šiame dokumente nagrinėjama tyrimo sritis susijusi su „E-Portfolio“ tipo sistemų projektavimu ir galimų projektavimo metodų parinkimu. Analitinėje darbo dalyje pristatomos „E-Portfolio“ sistemos, jos vėliau palyginamos. Projektinėje dalyje pateikiama suprojektuotos tokios sistemos – „ePortfelis“, - architektūra. Tiriamojoje darbo dalyje apžvelgiami skirtingi projektavimo metodai ir jų tinkamumas „E-Portfolio“ sistemų projektavimui. / The main objective of this project was to design and develop an e-portfolio system „ePortfelis”. During this process the analysis of alternative e-portfolio systems was performed, as well as gathering of e-portfolio requirements. The design of developed system was carried according to RUP process. There were reviewed three different software design methods during the software design methods analysis part: SSADM, Booch method and JSP. It was determined that of those three above mentioned methods JSP was most unsuitable for designing e-portfolio systems.

Many software systems eventually undergo changes to their basic architectural structure. Such changes may be prompted by new feature requests, new quality attribute requirements, changing technology, or other reasons. Whatever the causes, architecture evolution is commonplace in real-world software projects. Today’s software architects, however, have few techniques to help them plan such evolution. In particular, they have little assistance in planning alternatives, making trade-offs among these different alternatives, or applying best practices for particular domains. To address this, we have developed an approach for assisting architects in planning and reasoning about software architecture evolution. Our approach is based on modeling and analyzing potential evolution paths that represent different ways of evolving the system. We represent an evolution path as a sequence of transitional architectural states leading from the initial architecture to the target architecture, along with evolution operators that characterize the transitions among these states. We support analysis of evolution paths through the definition and application of constraints that express rules governing the evolution of the systemand evaluation functions that assess path quality. Finally, a set of these modeling elements may be grouped together into an evolution style that encapsulates a body of knowledge relevant to a particular domain of architecture evolution. We evaluate this approach in three ways. First, we evaluate its applicability to real-world architecture evolution projects. This is accomplished through case studies of two very different software organizations. Second, we undertake a formal evaluation of the computational complexity of verifying evolution constraints. Finally, we evaluate the implementability of the approach based on our experiences developing prototype tools for software architecture evolution.

This dissertation addresses the confidentiality aspect of the information security problem from the viewpoint of the software architecture. It presents a new approach to secure system design in which the desired security properties, in particular, confidentiality, of the system are proven to hold at the architectural level. The architecture description language Wright is extended so that confidentiality authorizations can be specified. An architectural description in Wright/c, the extended language, assigns clearance to the ports of the components and treats security labels as a part of data type information. The security labels are declared along with clearance assignments in an access control lattice model, also expressed in Wright/c. This enables the static analysis of data flow over the architecture subject to confidentiality requirements as per Bell-LaPadula principles. An algorithm takes the Wright/c description and the lattice model as inputs, and checks if there is a potential violation of the Bell-LaPadula principles. The algorithm also detects excess privileges. A software tool, which features an XML-based front-end to the algorithm is constructed. Finally, the algorithm is analyzed for its soundness, completeness and computational complexity.

Architecting e-business applications is a complex design activity. This is mainly due to the numerous architectural decisions to be made, including the selection of alternative technologies, software components, design strategies, patterns, standards, protocols, platforms, etc. Further complexities arise due to the fact that these alternatives often vary considerably in their support for different quality attributes. Moreover, there are often different groups of stakeholders involved, with each having their own quality goals and criteria. Furthermore, different architectural decisions often include interdependent alternatives, where the selection of one alternative for one particular decision impacts the selections to be made for alternatives from other different decisions. There have been several research efforts aiming at providing sufficient mechanisms and tools for facilitating the architectural evaluation and design process. These approaches, however, address architectural decisions in isolation, where they focus on evaluating a limited set of alternatives belonging to one architectural decision. This has been the primary motivation behind the development of the Architectural DEcision-Making Support (ADEMS) framework, which basically aims at supporting stakeholders and architects during the architectural decision-making process by helping them determining a suitable combination of architectural alternatives. ADEMS framework is an iterative process that leverages rigorous quantitative decision-making techniques available in the literature of Management Science, particularly Multiple Attribute Decision-Making (MADM) methods and Integer Programming (IP). Furthermore, due to the number of architectural decisions involved as well as the variety of available alternatives, the architecture design space is expected to be huge. For this purpose, a query language has been developed, known as the Architecture Query Language (AQL), to aid architects in exploring and analyzing the design space in further depth, and also in examining different ???what-if??? architectural scenarios. In addition, in order to support leveraging ADEMS framework, a support tool has been implemented for carrying out the sophisticated set of mathematical computations and comparisons of the large number of architectural combinations, which might otherwise be hard to conduct using manual techniques. The primary contribution of the tool is in its help to identify, evaluate, and rank all potential combinations of alternatives based on their satisfaction to quality preferences provided by the different stakeholders. Finally, to assess the feasibility of ADEMS, three different case studies have been conducted relating to the architectural evaluation of different e-business and enterprise applications. Results obtained for the three case studies were quite positive as they showed an acceptable accuracy level for the decisions recommended by ADEMS, and at a reasonable time and effort costs for the different system stakeholders.

Thesis (Ph. D.)--University of New South Wales, 2005. / Also available online.

Thesis (Ph. D.)--University of Alabama at Birmingham, 2007. / Additional advisors: Marjan Mernik, Jeffrey G. Gray, Alan P. Sprague, Elliot J. Lefkowitz. Description based on contents viewed May 29, 2008; title from title screen. Includes bibliographical references (p. 140-152).

Thesis (Ed. D.)--Illinois State University, 2004. / Title from title page screen, viewed Jan. 21, 2005. Dissertation Committee: Dent M. Rhodes (chair), Temba C. Bassoppo-Moyo, Kenneth F. Jerich, W. Max Rexroad. Includes bibliographical references (leaves 143-149) and abstract. Also available in print.