142 research outputs found

    Comparison of method chunks and method fragments for situational method engineering

    Full text link
    Two main candidates for the atomic element to be used in Situational Method Engineering (SME) have been proposed: the “method fragment ” and the “method chunk”. These are examined here in terms of their conceptual integrity and in terms of how they may be used in method construction. Also, parallels are drawn between the two approaches. Secondly, the idea of differentiating an interface from a body has been proposed for method chunks (but not for method fragments). This idea is examined and mappings are constructed between the interface and body concepts of method chunks and the concepts used to describe method fragments. The new ISO/IEC 24744 standard metamodel is used as a conceptual framework to perform these mappings

    Systematic method for UML model to model transformation : development and verification in alloy

    Get PDF
    Dissertação de mestrado em Engenharia InformáticaThe Unified Modeling Language (UML) is nowadays the industry standard notation for modelling software systems using an object-oriented approach. The Object Management Group (OMG) manages this standardization. UML combines several modelling techniques and its models have visual representations through UML diagrams. Despite being widely accepted, used and also recommended by software development processes like Rational Unified Process (RUP) and Agile, two major UML weaknesses are recognized by the overall software community: it is a notation with no underlying method; it is only semi-formal. Trying to narrow this gap, this work presents a method for the systematic transformation of UML models. Furthermore, and tackling another vulnerability of UML, its informality, we also propose a verification mechanism for checking the correctness of said transformations using the Alloy formal modelling notation. The proposed diagram transformation method follows the RUP use case orientation and encompasses three UML diagrams: use case, sequence, and interaction overview diagrams. We have developed the action step and action block constructs, which will be the basis for a more precise and standardized structure for the textual specification of use cases. Using these constructs, and without loss of expressive power, a canonical form for use cases was devised which will be the source and the anchor for the other steps of the systematic transformation method. Starting from the use cases already in the canonical form, we have created a set of steps and rules that will conduct the transformation of these use cases into sequence and interaction overview diagrams in a systematic way. With Alloy, we are able to assess the diagrams’ well-formedness and verify the correction of the transformations.A Unified Modeling Language (UML) é hoje em dia a notação standard da indústria para a modelação de sistemas de software usando uma abordagem orientada aos objectos. O Object Management Group (OMG) gere esta standardização. A UML combina várias técnicas de modelação e os seus modelos têm representações visuais através de diagramas. Apesar de ser amplamente aceite, usada e também recomendada por processos de software como o Rational Unified Process (RUP) e Agile, duas fragilidades são reconhecidas à UML pela comunidade de software em geral: é uma notação sem método subjacente; é apenas semi-formal. Tentando estreitar esta lacuna, este trabalho apresenta um método para a transformação sistemática de modelos UML. Para além disso, e abordando outra vulnerabilidade da UML, a informalidade, propomos também um mecanismo de verificação da correcção das referidas transformações usando a notação de modelação formal Alloy. O método de transformação de diagramas proposto segue a orientação aos casos de uso do RUP e abarca três diagramas UML: diagramas de casos de uso, de sequência, e de supervisão de interação. Desenvolvemos as construções passos de ação e blocos de ações, as quais serão a base para uma estrutura mais precisa e standardizada das especificações dos casos de uso. Usando estas construções, e sem perda de poder expressivo, foi concebida uma forma canónica para os casos de uso que será a origem e a âncora para os outros passos do método sistemático de transfomação. Partindo dos casos de uso já na forma canónica, criamos um conjunto de passos e regras que conduzirão a transformação destes casos de uso para diagramas de sequência e de supervisão de interação de um modo sistemático. Através do Alloy, somos capazes de aferir a boa-formação dos diagramas e verificar a correção das transformações

    Toward Refactoring of DMARF and GIPSY Case Studies – a Team 3 SOEN6471-S14 Project Report

    Get PDF
    The software architecture of a system is an illustration of the system which supports the understanding of the behaviour of the system. The architecture aids as the blueprint of the system, defining the work obligations which must be conceded by design and implementation teams. It is an artifact for early enquiry to make sure that a design methodology will produce a standard system. This paper depicts the software architecture and design of two frameworks DMARF and GIPSY. Primarily it inaugurates a comprehensive understanding of the frameworks and their applications. DMARF is high-volume processing of recorded audio, textual, or imagery data for pattern recognition and biometric forensic analysis, whereas GIPSY system provides a platform for a distributed multi-tier demand driven evaluation of heterogeneous programs. Secondly, the paper illustrates the use of several tools for the code analysis for both platforms and provides the outcome of the analysis. Thirdly, it establishes the architecture and design of the systems. Fourthly, it fuses the architecture for both the systems into one. The paper ends with depicting properties like code smells and refactoring to improve code quality for the frameworks

    Software architecture visualisation

    Get PDF
    Tracing the history of software engineering reveals a series of abstractions. In early days, software engineers would construct software using machine code. As time progressed, software engineers and computer scientists developed higher levels of abstraction in order to provide tools to assist in building larger software systems. This has resulted in high-level languages, modelling languages, design patterns, and software architecture. Software architecture has been recognised as an important tool for designing and building software. Some research takes the view that the success or failure of a software development project depends heavily on the quality of the software architecture. For any software system, there are a number of individuals who have some interest in the architecture. These stakeholders have differing requirements of the software architecture depending on the role that they take. Stakeholders include the architects, designers, developers and also the sales, services and support teams and even the customer for the software. Communication and understanding of the architecture is essential in ensuring that each stakeholder can play their role during the design, development and deployment of that software system. Software visualisation has traditionally been focused on aiding the understanding of software systems by those who perform development and maintenance tasks on that software. In supporting developers and maintainers, software visualisation has been largely concerned with representing static and dynamic aspects of software at the code level. Typically, a software visualisation will represent control flow, classes, objects, import relations and other such low level abstractions of the software. This research identifies the fundamental issues concerning software architecture visualisation. It does this by identifying the practical use of software architecture in the real world, and considers the application of software visualisation techniques to the visualisation of software architecture. The aim of this research is to explore the ways in which software architecture visualisation can assist in the tasks undertaken by the differing stakeholders in a software system and its architecture. A prototype tool, named ArchVis, has been developed to enable the exploration of some of the fundamental issues in software architecture visualisation. ArchVis is a new approach to software architecture visualisation that is capable of utilising multiple sources and representations of architecture in order to generate multiple views of software architecture. The mechanism by which views are generated means that they can be more relevant to a wider collection of stakeholders in that architecture. During evaluation ArchVis demonstrates the capability of utilising a number of data sources in order to produce architecture visualisations. Arch Vis' view model is capable of generating the necessary views for architecture stakeholders and those stakeholders can navigate through the views and data in order to obtain relevant information. The results of evaluating ArchVis using a framework and scenarios demonstrate that the majority of the objectives of this research have been achieved

    A theory and model for the evolution of software services

    Get PDF
    Software services are subject to constant change and variation. To control service development, a service developer needs to know why a change was made, what are its implications and whether the change is complete. Typically, service clients do not perceive the upgraded service immediately. As a consequence, service-based applications may fail on the service client side due to changes carried out during a provider service upgrade. In order to manage changes in a meaningful and effective manner service clients must therefore be considered when service changes are introduced at the service provider's side. Otherwise such changes will most certainly result in severe application disruption. Eliminating spurious results and inconsistencies that may occur due to uncontrolled changes is therefore a necessary condition for the ability of services to evolve gracefully, ensure service stability, and handle variability in their behavior. Towards this goal, this work presents a model and a theoretical framework for the compatible evolution of services based on well-founded theories and techniques from a number of disparate fields.
    corecore