In this paper a reuse-oriented perspective is taken to designing and implementing configurable distributed applications. An application domain is defined as a family of systems that have some features in common and others that differentiate them. During domain engineering, reusable specifications, architectures and component types are developed, which capture the similarities and variations of the family of systems that compose the application domain. Target systems are generated by tailoring the reusable specification and architecture given the requirements of the target system, and configuring a target system based on the tailored architecture. The paper describes an automated approach for configuring distributed applications from a reusable architecture and library of predefined component types.
This paper presents a practical solution to a real-life industrial problem in the unmanned space flight software (FSW) domain using software product lines and software architectural design patterns. In the FSW domain, there exists a significant amount of variability in the required capabilities. For example, some FSW have a significant amount of hardware to control and operate in a nearly autonomous fashion. In contrast, other FSW have a small amount of hardware to control and rely heavily of commanding from the ground station to operate the spacecraft. The underlying architecture and component interactions needed for the different FSWs are quite different. This amount of architectural variability makes it difficult to develop a SPL architecture that covers the all possible variability in the FSW domain. Therefore, this paper presents a practical solution to this real world problem that leverages software product line concepts and software architectural design patterns.
The paper presents a novel application involving two important software engineering research areas: process modeling and software reuse. The Spiral Model is a risk-driven process model, which, depending on the specific risks associated with a given project, may be tailored to create a project-specific process model. The software reuse area is that of domain modeling of families of systems, which capture the similarities and variations among the members of the family. The domain modeling approach is used to create a domain model of a Spiral Process Model (SPM), thereby capturing the similarities and variations among a family of process models. The SPM domain model has been extended to capture the key process areas of the Software Engineering Institute's Capability Maturity Model (CMM). The domain model is used to generate project-specific process models. This approach allows managers to configure and reuse process models that manage the risks associated with new software development.
In many software development projects, performance requirements are not addressed until after the application is developed or deployed, resulting in costly changes to the software or the acquisition of expensive high-performance hardware. To remedy this, researchers have developed model-driven performance analysis techniques for assessing how well performance requirements are being satisfied early in the software lifecycle. In some cases, companies may not have the expertise to perform such analysis on their software; therefore they have an independent assessor perform the analysis. This paper describes an approach for conducting independent model-driven software performance assessments of UML 2.0 designs and illustrates this approach using a real-time signal generator as a case study
During analysis modeling, the problem is analyzed by breaking it down and studying it on a use case–by–use case basis. During design modeling, the solution is synthesized by designing a software architecture that defines the structural and behavioral properties of the software system. To successfully manage the inherent complexity of a large-scale software system, it is necessary to provide an approach for decomposing the system into subsystems and developing the overall software architecture of the system. After performing this decomposition, each subsystem can then be designed independently, as described in subsequent chapters.
'/%3e%3c/defs%3e%3cpath fill='%23012169' d='M0 0h10080v5040H0z'/%3e%3cpath stroke='%23fff' stroke-width='.6' d='m0 0 6 3m0-3L0 3' clip-path='url(%23b)' transform='scale(840)'/%3e%3cpath stroke='%23e4002b' stroke-width='.4' d='m0 0 6 3m0-3L0 3' clip-path='url(%23c)' transform='scale(840)'/%3e%3cpath stroke='%23fff' stroke-width='840' d='M2520 0v2520M0 1260h5040'/%3e%3cpath stroke='%23e4002b' stroke-width='504' d='M2520 0v2520M0 1260h5040'/%3e%3cg fill='%23fff'%3e%3cuse xlink:href='%23d' x='2520' y='3780'/%3e%3cuse xlink:href='%23a' x='7560' y='4200'/%3e%3cuse xlink:href='%23a' x='6300' y='2205'/%3e%3cuse xlink:href='%23a' x='7560' y='840'/%3e%3cuse xlink:href='%23a' x='8680' y='1869'/%3e%3cuse xlink:href='%23e' x='8064' y='2730'/%3e%3c/g%3e%3c/svg%3e)
