Automating the Composition of Middleware Configurations

A method is presented for the automatic construction of all possible valid compositions of different middleware software architectures. This allows reusing the latter in order to create systems providing a set of different non-functional properties. These compositions are constructed by using only the structural information of the architectures, i.e. their configurations. Yet, they provide a valuable insight on the different properties of the class of systems that can be constructed when a particular set of non-functional properties is required

SPIN-ning Software Architectures: A Method for Exploring Complex Systems

When designing complex software systems that provide multiple non-functional properties, it is usual to try to reuse (and finally compose) simpler existing designs, which deal with each of these properties in solitude. The paper describes a method for automatically and quickly identifying all the different ways one can compose such designs, with the aid of a model checke

Green Computing using Perl and Python

Green computing or clean computing is necessary for Software Engineering. Perl and Python are important programming languages for green computing. Perl is regular language. Perl is mainly used for server-side programming because it is a regular language. It a portable and green programming language. It can be used as object-oriented (OO) or non objectoriented (Non-O-O) programming language. Python is preprocessor. It is a portable language for software engineering. It has an import feature for Green computing

Securing against fraud in mobile communications : system design and development in 3G mobile networks

Thesis (S.M.)--Massachusetts Institute of Technology, Engineering Systems Division, Technology and Policy Program, 2006.Includes bibliographical references (leaves 120-124).Network security ensures the consistency, integrity, and reliability of telecommunications systems. Authorized network access prevents fraudulent communications and maintains the availability of the systems. However, limited development time, cost reduction pressure and requirement for high reliability in software development have forced mobile carriers to implement the insufficient and inflexible authentication mechanisms. Technical specifications including network architecture, network protocols, and security algorithm are widely available to the public. In addition, both secured and unsecured networks are interconnected by global roaming services. The inadequate system design will make the mobile systems vulnerable to unauthorized access to mobile communications. Compared with GSM mobile systems, 3G mobile systems are equipped with more robust and flexible security mechanisms. The official position taken by mobile carriers, such as NTT DoCoMo, KDDI, and Vodafone, is that fraudulent communications, usually in the form of cloned mobile phones, are impossible with their 3G mobile systems. Examining the NTT DoCoMo's case, however, we find that this statement is based on weak security assumptions.(cont.) In order to avoid potential threats and to secure the 3G mobile systems, this thesis (1) explores the security architecture and mechanisms in 3G systems, (2) analyzes the current platform architecture and platform innovations of the network software, and (3) suggests a secure system design and development.by Yujiro Mochizuki.S.M

Case Study of Feature-Oriented Requirements Modelling, Applied to an Online Trading System

The Feature-Oriented Requirements Modelling (FORM) combines the requirement engineering style structuring of requirements documents with the feature-orientation of the Feature Oriented Software Development, resulting in a feature-oriented model of the functional requirements of a system-under-development (SUD). A feature is a distinguishable unit of added value to the SUD. The objectives of FORM are to model features as independent modules, to allow the addition of new features with minimal changes to the existing features, and to enable automatic generation and checking of properties like correctness, consistency, and non-determinism. FORM structures requirements into three models: a domain model, a collection of behavioural models, and a collection of functional models. A feature is modelled by a distinct behavioural model. This dissertation evaluates FORM by applying it to a new application that can be thought of in terms of features, namely an online trading system (OTS) that receives requests from customers about buying or selling securities on a stock market. The OTS offers variability in terms of the types of orders that customers can request, (e.g. market order, limit order and stop order). The case study revealed six deficiencies of the FORM notation, three of which were easily overcome. The dissertation presents the results of the case study, resolutions to three of the six deficiencies, and an outline of an approach to resolve the other three deficiencies

A Feature-Oriented Modelling Language and a Feature-Interaction Taxonomy for Product-Line Requirements

Many organizations specialize in the development of families of software systems, called software product lines (SPLs), for one or more domains (e.g., automotive, telephony, health care). SPLs are commonly developed as a shared set of assets representing the common and variable aspects of an SPL, and individual products are constructed by assembling the right combinations of assets. The feature-oriented software development (FOSD) paradigm advocates the use of system features as the primary unit of commonality and variability among the products of an SPL. A feature represents a coherent and identifiable bundle of system functionality, such as call waiting in telephony and cruise control in an automobile. Furthermore, FOSD aims at feature-oriented artifacts (FOAs); that is, software-development artifacts that explicate features, so that a clear mapping is established between a feature and its representation in different artifacts. The thesis first identifies the problem of developing a suitable language for expressing feature-oriented models of the functional requirements of an SPL, and then presents the feature-oriented requirements modelling language (FORML) as a solution to this problem. FORML's notation is based on standard software-engineering notations (e.g., UML class and state-machine models, feature models) to ease adoption by practitioners, and has a precise syntax and semantics to enable analysis. The novelty of FORML is in adding feature-orientation to state-of-the-art requirements modelling approaches (e.g., KAOS), and in the systematic treatment of modelling evolutions of an SPL via enhancements to existing features. An existing feature can be enhanced by extending or modifying its requirements. Enhancements that modify a feature's requirements are called intended feature interactions. For example, the call waiting feature in telephony intentionally overrides the basic call service feature's treatment of incoming calls when the subscriber is already involved in a call. FORML prescribes different constructs for specifying different types of enhancements in state-machine models of requirements. Furthermore, unlike some prominent approaches (e.g., AHEAD, DFC), FORML's constructs for modelling intended feature interactions do not depend on the order in which features are composed; this can lead to savings in analysis costs, since only one rather than (possibly) multiple composition orders need to be analyzed. A well-known challenge in FOSD is managing feature interactions, which, informally defined, are ways in which different features can influence one another in defining the overall properties and behaviours of their combination. Some feature interactions are intended, as described above, while other feature interactions are unintended: for example, the cruise control and anti-lock braking system features of an automobile may have incompatible affects on the automobile's acceleration, which would make their combination inconsistent. Unintended feature interactions should be detected and resolved. To detect unintended interactions in models of feature behaviour, we must first define a taxonomy of feature interactions for the modelling language: that is, we must understand the different ways that feature interactions can manifest among features expressed in the language. The thesis presents a taxonomy of feature interactions for FORML that is an adaptation of existing taxonomies for operational models of feature behaviour. The novelty of the proposed taxonomy is that it presents a definition of behaviour modification that generalizes special cases found in the literature; and it enables feature-interaction analyses that report only unintended interactions, by excluding interactions caused by FORML's constructs for modelling intended feature interactions