154 research outputs found

    Validation of the Parlay API through prototyping

    Get PDF
    The desire within the telecommunications world for new and faster business growth has been a major drive towards the development of open network API. Over the past 7 years several (semi) standardization groups have announced work on network API, including TINA-C, JAIN, IEEE P1520, INforum, 3GPP, JAIN, Parlay. The Parlay group seems most successful in attracting industry awareness with their API, called the Parlay API. The rational behind the Parlay API is that it attracts innovation from third parties that are outside the network operator's domain to build and deploy new network-hosted applications. This also means that the public telecommunication network is opened for niche and short-lived applications as well as for applications that possibly integrate telephones with other terminals such as PC. The Parlay group has successfully passed the first two phases of success, namely publishing their API on the right moment in time and attracting a critical mass within the telecommunication industry with their results. Prototyping the API on a real network execution platform is the only way to show its technical feasibility. Such an exercise was executed internally within Lucent Technologies and raised a number of questions as well as recommendations on both the technical and the semantical behavior for systems that will be interconnected via the Parlay API. We share these results, showing the drawbacks and advantages as well as challenges for this AP

    Review of Requirement Engineering Approaches for Software Product Lines

    Full text link
    The Software Product Lines (SPL) paradigm is one of the most recent topics of interest for the software engineering community. On the one hand, the Software Product Lines is based on a reuse strategy with the aim to reduce the global time-to-market of the software product, to improve the software product quality, and to reduce the cost. On the other hand, traditional Requirement Engineering approaches could not be appropriated to deal with the new challenges that arises the SPL adoption. In the last years, several approaches have been proposed to cover this limitation. This technical report presents an analysis of specific approaches used in the development of SPL to provide solutions to model variability and to deal with the requirements engineering activities. The obtained results show that most of the research in this context is focused on the Domain Engineering, covering mainly the Feature Modeling and the Scenario Modeling. Among the studied approaches, only one of them supported the delta identification; this fact implies that new mechanisms to incorporate new deltas in the Domain specification are needed. Regarding the SPL adoption strategy, most of the approaches support a proactive strategy. However, this strategy is the most expensive and risk-prone. Finally, most of the approaches were based on modeling requirements with feature models giving less support to other important activities in the requirements engineering process such as elicitation, validation, or verification of requirements. The results of this study provide a wide view of the current state of research in requirements engineering for SPL and also highlight possible research gaps that may be of interest for researchers and practitioners.Blanes Domínguez, D.; Insfrán Pelozo, CE. (2011). Review of Requirement Engineering Approaches for Software Product Lines. http://hdl.handle.net/10251/1023

    USTOPIA REQUIREMENTS THOUGHTS ON A USER-FRIENDLY SYSTEM FOR TRANSFORMATION OF PROGRAMS IN ABSTRACTO

    Get PDF
    Transformational programming is a program development method which is usually applied using 'pen and paper'. Since this requires a lot of clerical work (copying expressions, con- sistent substitution) which is tiresome and prone to error, some form of machine support is desirable. In this paper a number of systems are described that have already been built to this aim. Some of their shortcomings and limitations are identified. Based on experience with program transformation and transformation systems, a long list of features is given that would be useful in an 'utopian' transformation system. This list is presented using an orthogonal division of the problem area. A number of problems with the realisation of some aspects of our 'utopian' system are identified, and some areas for further research are indicated

    A Programming Environment Evaluation Methodology for Object-Oriented Systems

    Get PDF
    The object-oriented design strategy as both a problem decomposition and system development paradigm has made impressive inroads into the various areas of the computing sciences. Substantial development productivity improvements have been demonstrated in areas ranging from artificial intelligence to user interface design. However, there has been very little progress in the formal characterization of these productivity improvements and in the identification of the underlying cognitive mechanisms. The development and validation of models and metrics of this sort require large amounts of systematically-gathered structural and productivity data. There has, however, been a notable lack of systematically-gathered information on these development environments. A large part of this problem is attributable to the lack of a systematic programming environment evaluation methodology that is appropriate to the evaluation of object-oriented systems

    A Kernel Specification Formalism with Higher-Order Parameterisation

    Get PDF
    A specification formalism with parameterisation of an arbitrary order is presented. It is given a denotational-style semantics, accompanied by an inference system for proving that an object satisfies a specification. The inference system incorporates, but is not limited to, a clearly identified type-checking component. Special effort is made to carefully distinguish between parameterised specifications, which denote functions yielding classes of objects, and specifications of parameterised objects, which denote classes of functions yielding objects. To deal with both of these in a uniform framework, it was convenient to view specifications, which specify objects, as objects themselves, and to introduce a notion of a specification of specifications. The formalism includes the basic specification-building operations of the ASL specification language. This choice, however, is orthogonal to the new ideas presented. The formalism is also institution-independent, although this iss..

    CoFI: The Common Framework Initiative for Algebraic Specification and Development

    Get PDF
    An open collaborative effort has been initiated: to design acommon framework for algebraic specification and development of software. The rationale behind this initiative is that the lack of such a common framework greatly hinders the dissemination and application of researchresults in algebraic specification. In particular, the proliferationof specification languages, some differing in only quite minor ways from each other, is a considerable obstacle for the use of algebraic methods in industrial contexts, making it difficult to exploit standard examples, case studies and training material. A common framework with widespread acceptancethroughout the research community is urgently needed.The aim is to base the common framework as much as possible on a critical selection of features that have already been explored in various contexts. The common framework will provide a family of specificationlanguages at different levels: a central, reasonably expressive language, called CASL, for specifying (requirements, design, and architecture of) conventional software; restrictions of CASL to simpler languages, for use primarily in connection with prototyping and verification tools; and extensionsof CASL, oriented towards particular programming paradigms,such as reactive systems and object-based systems. It should also be possibleto embed many existing algebraic specification languages in members of the CASL family. A tentative design for CASL has already been proposed. Task groupsare studying its formal semantics, tool support, methodology, and other aspects, in preparation for the finalization of the design
    corecore