9 research outputs found

    Building a Systematic Legacy System Modernization Approach

    Full text link
    A systematic legacy system modernizing approach represents a new approach for modernizing legacy systems. Systematic legacy system modernization has software reuse as an integral part of modernization. We have developed a modernization approach which uses software architecture reconstruction to find reusable components within the legacy system. The practice of software development and modernization continues to shift towards the reuse of components from legacy systems to handle the complexities of software development. Modernization of a legacy system requires reuse of software artefacts from legacy system to conserve the business rules and improve the system’s quality attributes. Software reuse is an integral part of our systematic legacy modernization approach. Software should be considered as an asset and reuse of these assets is essential to increase the return on the development costs. Software reuse ranges from reuse of ideas to algorithms to any documents that are created during the software development life cycle. Software reuse has many potential benefits which include increased software quality, and decreased software development cost and time. Demands for lower software production and maintenance costs, faster delivery of systems and increased quality can only be met by widespread and systematic software reuse. In spite of all these benefits software reuse adoption is not widespread in the software development communities. Software reuse cannot possibly become an engineering discipline so long as issues and concerns have not been clearly understood and dealt with. We have conducted two surveys to understand the issues and concerns of software reuse in the Conventional Software Engineering (CSE) Community and the Software Product Line (SPL) Community where reuse is an integral part of the product development. The quantitative and qualitative analysis of our surveys identified the critical factors which affect and inhibit software engineers and developers adopting software reuse. Software reuse has been talked about in generic terms in software product lines. Though software reuse is a core concept in SPL it has however failed to become a standardized practice. The survey conducted on the SPL Community investigates how software reuse is adopted in SPL so as to provide the necessary degree of support for engineering software product line applications and to identify some of the issues and concerns in software reuse. The identified issues and concerns have helped us to understand the difference between software reuse in the CSE and SPL Communities. It has also given us an indication of how both communities can learn good software reuse practices from each other in order to develop a common software reuse process. Based on the outcome of our surveys we have developed a systematic software reuse process, called the Knowledge Based Software Reuse (KBSR) Process, which incorporates a Repository of reusable software assets to build a systematic legacy system modernization approach. Being able to reuse software artefacts, be it software requirement specification, design, or code, would greatly enhance software productivity and reliability. All of these software artefacts can go in the Knowledge Based Software Reuse Repository and be candidates for reuse

    Post-Tenure Review 2011

    Get PDF
    Compilation of scholarly output, teacher evaluations, course materials, and other material representative of academic performance.CONTENTS Self-Evaluation p.1 Appendix A – Representative course syllabi p.11 Appendix B – Results of Student Opinion of Instruction surveys p.73 Appendix C – Reprints of peer-review articles published p.105 Appendix D – Herbarium related consultations and services p.371 Appendix E – Annual evaluations p.385 Appendix F – Curriculum vitae p.40

    The Whitworthian 2007-2008

    Get PDF
    The Whitworthian student newspaper, September 2007-April 2008.https://digitalcommons.whitworth.edu/whitworthian/1092/thumbnail.jp

    The Whitworthian 2006-2007

    Get PDF
    The Whitworthian student newspaper, September 2006-May 2007.https://digitalcommons.whitworth.edu/whitworthian/1091/thumbnail.jp

    The Whitworthian 2004-2005

    Get PDF
    The Whitworthian student newspaper, September 2004-May 2005.https://digitalcommons.whitworth.edu/whitworthian/1088/thumbnail.jp

    Status of the freshwater fishes of the Philippines

    Get PDF

    Diversity of brain size in fishes: preliminary analysis of a database including 1174 species in 45 orders

    Get PDF
    Absolule and relative values of brain weight are now available for 1174 species of fishes, representing 45 taxonomic orders. The original FishBase "Brains" data was assembled by the research team of Bauchot and colleagues, to which the present report adds data for species representing several additional major taxonomic groups. This database is part of the FíshBase 97 package which provides researchers with a tool to explore lhe functional meaning of absolute and relative brain size díversily, in comparison with phylogenetic position, life history mode, locomotion, habitat, and other behavioral parameters. Several results are provided as an example of the use of these data. Galeomorph sharks and batoid rays possess the largest brains among fishes. and elongate forms with anguilliform locomotion (e.g.. hagfishes. lampreys, lrue eels, carapids, zoarcids) possess the smallest relative brain sizes. Among teleost fishes, Osteoglossomorphs possess the largest relative brain sizes. Brain size correlations with oxygen consumption suggest that larger brains consume proportionately more oxygen, or that active fish with higher metabolic rates have larger brain

    Using software abstraction to develop an agent based system.

    Get PDF
    The main contribution of the thesis is to present a systematic process to develop an agent-based system that assists a system developer to construct the required system, through a series of modelling activities, employing several levels of abstraction to show the milestones and produce intermediate deliverables. Current practice emphasises "downstream activities" such as implementation at the expense of "upstream activities" such as "modelling". The research has found that the development process for an agent system consists of three phases: agent system development, agent environment development and agent system deployment. The first and second phases represent an intertwined spiral model. All three phases themselves consist of three stages. Each phase employs different development techniques and each stage uses appropriate models and tools such as problem domain model, agent use cases, scenarios, agent system architecture, plan model and individual agent model.The proposed agent development method is applied to two case studies: a Filtering Agent System and Diabetic Consultation System. Both systems have been implemented and tested. Three distinct ways were used to evaluate the proposed method. First, comparing with the criteria of a methodology. Second, comparing it with the current agent-oriented methodologies. Third, informal observations from a potential user community.In conclusion, the research has demonstrated an effective synthesising process to build a set of agent concepts, development life-cycle and modelling to show a systematic process for developing agent systems. Moreover, by employing a whole host of software abstraction tools and techniques in the process, two benefits accrue: the introduction of more 'up stream' activities as well as placing modelling at the heart of the process. Illustratively, we could say that the modelling presented here does for agent systems what data flow diagram and data entity diagram have done for structured methodologies, i.e. raise the level of abstraction employed
    corecore