167,056 research outputs found
Automatic architectural enforcement
Automatic architectural enforcement would be very beneficial especially in product line development using open source practices where there is very limited or no access to the architects and the architecture is of paramount importance. However, current techniques for modelling software architecture do not support the modelling of architectural design rules which means that architectural enforcement is achieved by manual reviews. This paper addresses this problem by proposing how architectural design rules could be expressed in UML in a meta-model for the system model
FPLA: a modeling framework for describing flexible software product line architecture
Nowadays, Software Product Line (SPL) engineering [1] has been widely-adopted in software development due to the significant improvements that has provided, such as reducing cost and time-to-market and providing flexibility to respond to planned changes [2]. SPL takes advantage of common features among the products of a family through the systematic reuse of the core-assets and the effective management of variabilities across the products. SPL features are realized at the architectural level in product-line architecture (PLA) models. Therefore, suitable modeling and specification techniques are required to model variability. In fact, architectural variability modeling has become a challenge for SPLE due to the fact that PLA modeling requires not only modeling variability at the level of the external architecture configuration (see [3,4] literature reviews), but also at the level of internal specification of components [5]. In addition, PLA modeling requires preserving the traceability between features and PLAs. Finally, it is important to take into account that PLA modeling should guide architects in modeling the PLA core assets and variability, and in deriving the customized products. To deal with these needs, we present in this demonstration the FPLA Modeling Framework
Developing Product Lines with Third-Party Components
AbstractThe trends toward product line development and toward adopting more third-party software are hard to combine. The reason is that product lines demand fine control over the software (e.g., for diversity management), while third-party software (almost by definition) provides only little or no control.A growing use of third-party software may therefore lead to less control over the product development process or, vice-versa, requiring large control over the software may limit the ability to use third-party components. Since both are means to reduce costs and to shorten time to market, the question is whether they can be combined effectively.In this paper, we describe our solution to this problem which combines the Koala component model developed within Philips with the concept of build-level components. We show that by lifting component granularity of Koala components from individual C files to build-level components, both trends can be united. The Koala architectural description language is used to orchestrate product composition and to manage diversity, while build-level components form the unit of third-party component composition
A Comparative Study on Model-Driven Requirements Engineering for Software Product Lines
[EN] Model-Driven Engineering (MDE) and Software Product Lines (SPL) are two software development paradigms that emphasize reusing. The former reuse domain knowledge is represented as models and model transformations for product development, and the latter reuse domain knowledge is represented as core assets to produce a family of products in a given domain. The adequate
combination of both paradigms can bring together important advantages to the software development community. However, how to manage requirements during a model-driven product line development remains an open challenge. In particular, the Requirements Engineering (RE) activity must deal with specific
properties such as variability and commonality for a whole family of products. This paper presents a comparative study of eleven approaches that perform a MDE strategy in the RE activity for SPL, with the aim of identify ing current practices and research gaps. In summary, most of the approaches are focused on the Domain Engineering phase of the SPL development, giving less attention to the Application Engineering phase. Moreover there is a lack of
coverage of the Scoping activity, which defines the SPL boundaries. Several approaches apply some model transformations to obtain architectural and application requirements artifacts. Regarding the tool support for requirements specification and management, we found that most of the approaches use only academic prototypes. Regarding the validation of the approaches, the use of Case Studies as a proof of concept was the most commonly used method; however, there is a lack of well-defined case studies and empirical studies to
improve the proposals.This research is part of the MULTIPLE project (with ref. TIN2009-13838).Blanes DomĂnguez, D.; Insfrán Pelozo, CE. (2012). A Comparative Study on Model-Driven Requirements Engineering for Software Product Lines. Revista de Sistemas e Computação. 2(1):3-13. http://hdl.handle.net/10251/43841S3132
Architectural Evolution of a Software Product Line: an experience report
Abstract-This work presents an experience report on the architectural decisions taken in the evolution of a Software Product Line (SPL) of Model-based Testing tools (PLeTs). This SPL was partially designed and developed with the intention of minimizing effort and time-to-market during the development of a family of performance testing tools. With the evolution of our research and the addition of new features to the SPL, we identified limitations in the initial architectural design of PLeTs' components, which led us to redesign its Software Product Line Architecture (SPLA). In this paper, we discuss the main issues that led to changes in our SPLA, as well as present the design decisions that facilitate its evolution in the context of an industrial environment. We will also report our experiences on architecture modifications in the evolution of our SPL with the intention of allowing easier maintenance in a volatile development environment
The Feature-Architecture Mapping Method for Feature-Oriented Development of Software Product Lines
Software Produktlinien sind die Antwort von Software Engineering auf die
zu-nehmende Komplexität und kürzerenProdukteinführungszeiten von heutigen
Softwaresystemen. Nichtsdestotrotz erfordern Software Produktlinien
einefortgeschrittene Wartbarkeit und hohe Flexibilität. Das kann durch die
angemessene Trennung der Belange erreicht werden.Merkmale stellen die
Hauptbelange im Kontext von Software Produktlinien dar. Demzufolge sollte
ein Merkmal idealerweise ingenau einer Architekturkomponente implementiert
werden. In der Praxis ist das jedoch nicht immer machbar. Deshalb
solltezumindest ein starkes Mapping zwischen Merkmalen und der Architektur
bestehen. Die Methoden zur Entwicklung von SoftwareProduktlinien, die dem
Stand der Technik entsprechen, fĂĽhren zu bedeutender Verstreutheit und
Vermischung von Merkmalen. Indieser Arbeit wird die Feature-Architecture
Mapping (FArM) Methode entwickelt, um ein stärkeres Mapping zwischen
Merkmalenund der Produktlinien-Architektur zu erzielen. Der Input fĂĽr FArM
besteht in einem initialen Merkmalmodell, das anhand einerMethode zur
Domänenanalyse erstellt wurde. Dieses initiale Merkmalmodell wird einer
Serie von Transformationen unterzogen.Die Transformationen streben danach,
ein Gleichgewicht zwischen der Sichtweise von Kunden und
Softwarearchitekteneinzustellen. Die Merkmalinteraktionen werden während
der Transformationen ausdrĂĽcklich optimiert. Von jedem Merkmal
destransformierten Merkmalmodells wird eine Architekturkomponente
abgeleitet. Die Architekturkomponenten implementieren dieApplikationslogik
der entsprechenden Merkmale. Die Kommunikation zwischen den Komponenten
spiegelt die Interaktion zwischenden Merkmalen wider. Dieser Ansatz fĂĽhrt
im Vergleich zu den Produktlinien-Entwicklungsmethoden des Stands der
Technik zueinem stärkeren Mapping zwischen Merkmalen und der Architektur
und zu einer höheren Variabilität auf Merkmalebene. DieseEigenschaften
haben eine bessere Wartbarkeit und eine vereinfachte generative
Produktinstanzierung zur Folge, was wiederumdie Flexibilität der
Produktlinien steigert. FArM wurde durch ihre Anwendung in einigen Domänen
evaluiert, z.B. in denDomänen von Mobiltelefonen und Integrierten
Entwicklungsumgebungen (IDEs). Diese Arbeit wird FArM anhand einer
Fallstudie inder Domäne von Künstlichen Neuronalen Netzwerken präsentieren.Software product lines are the answer of software engineering to the
increasing complexity and shorter time-to-market ofcontemporary software
systems. Nonetheless, software product lines demand for advanced
maintainability and high flexibility.The latter can be achieved through the
proper separation of concerns. Features pose the main concerns in the
context ofsoftware product lines. Consequently, one feature should ideally
be implemented into exactly one architectural component. Inpractice, this
is not always feasible. Therefore, at least a strong mapping between
features and the architecture mustexist. The state of the art product line
development methodologies introduce significant scattering and tangling
offeatures. In this work, the Feature-Architecture Mapping (FArM) method is
developed, to provide a stronger mapping betweenfeatures and the product
line architecture. FArM receives as input an initial feature model created
by a domain analysismethod. The initial feature model undergoes a series of
transformations. The transformations strive to achieve a balancebetween the
customer and architectural perspectives. Feature interaction is explicitly
optimized during the feature modeltransformations. For each feature of the
transformed feature model, one architectural component is derived.
Thearchitectural components implement the application logic of the
respective features. The component communication reflectsthe feature
interaction. This approach, compared to the state of the art product line
methodologies, allows a strongerfeature-architecture mapping and for higher
variability on the feature level. These attributes provide
highermaintainability and an improved generative approach to product
instantiation, which in turn enhances product lineflexibility. FArM has
been evaluated through its application in a number of domains, e.g in the
mobile phone domain and theIntegrated Development Environment (IDE) domain.
This work will present FArM on the basis of a case study in the domain
ofartificial Neural Networks
Supporting the automated generation of modular product line safety cases
Abstract The effective reuse of design assets in safety-critical Software Product Lines (SPL) would require the reuse of safety analyses of those assets in the variant contexts of certification of products derived from the SPL. This in turn requires the traceability of SPL variation across design, including variation in safety analysis and safety cases. In this paper, we propose a method and tool to support the automatic generation of modular SPL safety case architectures from the information provided by SPL feature modeling and model-based safety analysis. The Goal Structuring Notation (GSN) safety case modeling notation and its modular extensions supported by the D-Case Editor were used to implement the method in an automated tool support. The tool was used to generate a modular safety case for an automotive Hybrid Braking System SPL
- …