Project topics and materials
Get Complete Project Material File(s) Now! »
APPROACHES TO MANAGE COMPLEXITY IN THE DESIGN
In the context of managing complexity, Software Architectures [SG96] are used to organize the structure of the design of complex systems. Software Architecture is “a level of design that involves the description of elements from which systems are built, interactions among those elements, patterns that guide their composition, and constraints on these patterns” [SG96, MT00].
In addition to the data structures and algorithms, the software architectures rely on structural issues including: protocols of communication; data access; assignment of func-tionality to design elements; the composition of design elements; physical distributions; and selection among the design alternatives. This makes it possible to cover the different concepts of a system design according to both the logical and physical views. Software architectures enable the designer to describe the system in different levels of abstraction and to separate the description of requirements between functional and non-functional and to connect between them through different types of relationships. In order to describe the architecture of a complex system and specially when the software development is an ar-chitecture based process (e.g., TOGAF [TOG], KAOS [vL01b], etc.), many Architectural Description Languages (ADL)s [MT00, Hus13] were proposed in the 2000’s. ADLs can en-able the developers to control [Hus13] the development process from the beginning to the end. These issues decompose the system to represent it in different ways: (1) hardware/-software decomposition; (2) domain-specificity and abstraction layering; (3) Activity and Objective decomposition (e.g., Requirements, Design, Verification, etc.). Generally, ADLs mainly differ from each other in the application domains, the frameworks and activities that they support. According to [MT00], ADLs should be able to address the following areas of concern:
1. representation to model hierarchal compositions;
2. design process support;
3. static and dynamic analysis;
4. specification-time and execution-time evolution;
5. refinement;
6. traceability;
7. simulation/execution.
The design process support is directly mentioned through the previous concerns, this process is our scope in this thesis. Additionally, Simulation provides a proper approach to verify the design at an earlier stage (cf. chapter 4). There is a clear intersection between our research questions (cf section. 1.3) and the aforementioned concerns of ADLs when considering the design and error detection activities. We find that our interest is in the following concerns:
1. design process support: We focus on the design/specification and verification activities of the service creation lifecycle published in [BPM94], and ADLs provide support to the design process. This support can be provided by frameworks and tools which help to improve the development time and reduce the errors that can be made by the designers. This can be achieved through graphical modeling tools and by bridging the gap between the different technologies in the system architecture;
2. traceability [MT00]: it is important to trace the changes across the different levels of architectural refinement. This concern becomes a major issue for ADLs because of the large technical gap between the design diagrams and the programming languages that represent the design architecture;
3. simulation/execution: this concern is important as we focus on the verification ac-tivity in this thesis. Simulation (cf. chapter 4) provides valuable feedbacks that can be analyzed in order to determine the satisfaction of functional and non-functional requirements without need for additional costs of hardware installations.
According to [SG96] and [MT00], ADLs should consider seven levels of architecture specification capability: (1) capturing architectural information; (2) construction of an instance; (3) composition of multiple instances; (4) selection among design or implemen-tation alternatives; (5) verifying adherence of an implementation to specification; (6) analysis; (7) automation. As the other design languages, ADLs are composed of abstract, concrete syntaxes (e.g., components and their reusable types with graphical representa-tions) and semantics (high-level model of a component’s behavior). Frameworks provide to the ADL the modeling and execution/verification abilities of the design (e.g., petri nets, finite state machines) where the major characteristics of frameworks are: extensibility and modifiability [MT00].
We have presented so far the concept of Software Architectures and Architecture De-scription Languages (ADL)s. ADLs are used to design systems through design envi-ronments during different activities that precede the implementation phase. There are different interesting concerns of using the ADLs which intersect with the interests of the service creation environments presented in [Ada09, APP02], thus ADLs are considered as useful to support the service creation process. In the following, we present some of these design environments as we will link them to the concept of Service Creation Environments (SCE)s in the domain of telecommunication service construction.
SERVICE CREATION ENVIRONMENTS (SCE)S
The Service Creation Environment (SCE) is “a collection of software tools (together with a reuse infrastructure) used according to the service development methodology with the aim to assist the service developer(s) when applying the service development method-ology by automating and simplifying as much as possible the service creation process, and facilitating consistency and verification checks” [APP02].
This SCE considers two types of complexity that are related to: (1) the actors and their roles, concerns and skills; (2) the technical nature of the tasks involved.
The main motivation behind SCEs is to manage the complexity and to facilitate check-ing that the resulting telecom services are as planned and required by customers and service providers. In order to support the service development methodology and make it applica-ble, service creation environments are proposed supported by tools and frameworks.
Requirements of the Service Creation Environments
The objective of this section is to present the different requirements that a Service Creation Environment (SCE) should satisfy.
SCEs are focused on the domain of telecommunications where telecom services have specific requirements and nature that needs a specific development framework that suits the creation process. These requirements were identified in [APP02] in order to satisfy the requirements of telecom service engineering process and to face the improvement of time to market, cost and quality competition factors. We limit ourselves to some of these re-quirements2 as we concentrate on specific phase which is the design and early verification (as an extension). These requirements are (Fig. 2.1): (R1) the reduction of complex-ity and increase of efficiency. This requirement intersects directly with our challenges; (R2) the efficient automation of the service creation process. This requirement meets the improvement of time to market challenge; (R3) the development of a rich variety of telecommunication services. This helps the service provider to produce larger number of telecom services using the same underlying platform and design tools; (R4) reusability at different abstraction levels. This requirement makes it possible to use the same design that is highly abstract with different underlying platforms or middlewares; (R5) the accommo-dation of legacy telecommunications services and systems. This requirement supports the reuse of widely used telecom services that are tested before as components of new ones; (R6) the interoperability of services. This requirement supports the ability of integrating the new service with other existing ones in order to provide certain functions to the end-user; (R7) the accommodation of the relevant standards. Thus, it is so useful to rely on standards such as 3GPP or standard platforms such as the IMS; (R8) we add the following requirement as important to manage complexity: support for sharing the viewpoints of the different stakeholders in the design; (R9) The representation of hardware and software elements. This requirement is important for both design and early verification processes. In the case of performance non-functional requirements, there are many metrics (e.g., CPU usage, queues, etc.) that need hardware identification (e.g., server type) in order to map the design accurately to the simulation scenario; (R10) using external and trusted tools during the verification of the design. We have added this requirement as we find it important to reduce the cost of the development process and to provide a certain level of trust to the feedbacks of the verification process to the designer.
ADLs are proper languages to be used in the SCEs as they have requirements that intersect with those of SCEs. ADLs are languages that are useful to describe architec-tures and systems which are related to define concepts (e.g., roles, actors, application classes, networking nodes, communication paths, etc.), while design environments are re-lated to activities (e.g., simulation, model checking, design, implementation, etc.) which is directly connected to roles, actors and tools. They can serve in the following activities [MR97]: (1) representation; (2) design process support; (3) static and dynamic analysis;
(4) specific-time and execution-time evolution; (5) refinement; (6) traceability; (7) simula-tion/executability. Additionally and according to [SG96], ADLs support: (8) automation during the different activities of the development process; (9) the verification of the system from implementation to the specification.
Service Creation Environments and Value-Added Services
Different approaches focused on designing TSs from a higher level of abstraction to hide the complexity of the systems from the designer. Different telecommunication platforms (e.g., OSA-Parlay [ERI02] [BJ02, GP02, GKDM03], Jain [BJ02]) were developed by the indus-try to abstract the telecommunication functions and their complexity from the designer. The objective from that is to improve the portability between these telecommunication platforms and the new VASs. This reuse issue needs a platform independent approach to describe the behaviors of each new service at a very high abstract level regardless to the hardware and physical network representations. Different approaches contributed to this domain by defining domain-specific languages (e.g., CPL SCML [BJ02], graphical interface [GP02]) and other components to help and manage the creation of the VASs through frameworks and SCEs [GKDM03].
All of the aforementioned contributions do not consider the error detection during or right after the design phase and they do not rely on simulation before the implementation phase. This point is raised as a research question in this thesis as mentioned in the introduction 1.
In [BJ02], the presented XML-based scripting languages facilitate the creation of VASs as they provide reusable means (answers to the requirements: R4) to describe the service functions in a way that uses the APIs that are provided by the underlying platform (e.g., JAIN, Parlay). This answers to the requirement (R5 and R7). This way of creating VASs provides an abstract method but on the same level of the predefined APIs using scripting languages which does not fully support the requirement (R1) unlike the proposal in [GP02, GKDM03]. In this last proposal, graphical user interface was proposed which relies on a domain-specific language. This makes the last approach advances in the requirement (R1) in addition to the other requirements that are answered by [BJ02]. Additionally, scripts are automatically generated by the design tool to describe the service structure and functions which makes the approach in [GP02, GKDM03] answers to the requirement (R2). Both of the approaches in [BJ02, GKDM03] do not provide automated means to facilitate the early verification process before the implementation phase. The above mentioned approach does not allow the configuration of the hardware parameters or even accessing the network level as it is hidden by the platform interfaces that offer APIs only. This point does not answer to the requirement (R9) that is important to the verification of the design before the implementation phase.
Table of contents :
Contents
Abstract
Résumé
Contexte
Service de Création ICT
Les environnements de conception pour des systèmes IT
Objectifs et motivations
Questions de recherche
Contributions et approches
List of Figures xxi
1 Introduction
Introduction
1.1 Context
1.1.1 ICT Service Creation
1.1.2 Design Environments for IT systems
1.2 Objective and Challenges
1.3 Research Questions
1.4 Approach and Contributions
1.5 Manuscript Organization
Introduction 1
I State of the Art
2 ICT Service Creation
2.1 Preamble
2.2 Chapter Organization
2.3 Telecom Services and Distributed Systems
2.3.1 Complexity issues
2.3.2 Impacts on the design phase
2.4 Approaches to Manage Complexity in the Design
2.4.1 Software Architectures
2.5 Service Creation Environments (SCE)s
2.5.1 Requirements of the Service Creation Environments
2.5.2 Service Creation Environments and Value-Added Services
2.5.3 TINA-C
2.5.4 SCEs and IMS
2.5.5 User-Centric SCEs
2.5.6 Service-Centric SCEs
2.6 Comparison
2.6.1 Comparison of SCE approaches
2.7 Discussion
3 Model Driven Engineering and Enterprise Architecture
3.1 Preamble
3.1.1 Framing
3.1.2 Chapter Organization
3.2 Modeling Languages and Tools
3.2.1 Architecture and Analysis Design Language (AADL)
3.2.2 Service Oriented Petri Net modeling language (SOPN)
3.2.3 Enterprise Modeling
3.2.4 Requirement and Goal Modeling
3.2.5 Business Process Modeling
3.2.6 SysML
3.2.7 Application Modeling
3.2.8 Platform Specific Modeling
3.3 Model Driven Engineering
3.3.1 Domain Specific Modeling Languages
3.3.2 Model Driven Approaches
3.3.3 Model Transformations taxonomy
3.3.4 XPAND Eclipse IDE
3.4 Discussion
4 Design Verification Approaches
4.1 Preamble
4.2 Design Verification
4.2.1 Design Verification relying on formal methods
4.3 Simulation Approach and Tools
4.3.1 Preamble
4.3.2 Simulation to verify complex designs against Performance NFR .
4.4 Discussion
II Contributions
5 A Framework Approach to Support TS design: the DeVerTeS Framework
5.1 Preamble
5.2 DeVerTeS framework
5.2.1 Linking Activity
5.2.2 Model Adaptation Activity
5.2.3 Measurement Analysis Activity
5.3 Discussion
6 Macro Activities of the DeVerTeS
6.1 Preamble
6.2 Linking Verification, Design and Motivation Elements
6.2.1 IMS architecture
6.2.2 SIP Protocol
6.2.3 Supporting the Design Activity
6.2.4 Supporting the verification Activity
6.3 The generic structure of the Domain-Specific Model Compiler
6.4 Code Generation using Eclipse-XPAND
6.4.1 Mapping of behavioral and structural concepts
6.5 Tool Selection Method
6.6 Transforming the multi-viewpoint architecture of the design to the simulation program
6.6.1 Discussion
6.7 Error Checking Procedures
6.7.1 Active Checking Procedure
6.7.2 Passive Checking Procedure
6.7.3 Linking TCP socket events to highly abstract behaviors
6.8 Discussion
7 Implementation and Validation
7.1 Preamble
7.2 Telecommunication Service
7.3 Underwater Complex Systems
7.4 Complex Service examples
7.4.1 Conference Service
7.4.2 Modeling the video conference service
7.4.3 Compiling the models of Video Conference Service
7.5 Object Localization for Marine Observatories
7.5.1 Underwater Object Localization Service relying on multi-sensor data fusion
7.5.2 An extension to ArchiMate for MOs Applications
7.5.3 Business Model
7.5.4 Application Model
7.5.5 Technology Model
7.5.6 Discussion
7.6 Testing Error Detection Rules
7.6.1 Active Error detection
7.6.2 Passive Error detection
7.6.3 Linking Socket-Events to highly abstract Behaviors
7.6.4 Discussion
7.7 Discussion
III Conclusion and Perspectives
8 Conclusion and Perspectives
8.1 Conclusion of Thesis
8.2 Perspectives
