Top PDF Towards a design-by-contract based approach for realizable connector-centric software architectures

Towards a design-by-contract based approach for realizable connector-centric software architectures

Towards a design-by-contract based approach for realizable connector-centric software architectures

Limited support for complex connectors Another problem with many ADLs (e.g., Darwin [Magee and Kramer, 1996], Rapide [Luckham, 1996], LEDA [Canal et al., 1999], and AADL [Feiler et al., 2006]), as well as with UML, is that they provide limited or no support for complex connectors, treating them in- stead as simple connections. Other ADLs, such as UniCon [Shaw et al., 1995], provide only partial sup- port through a limited number of basic connectors but do not allow designers to freely specify their own (complex) types. This is unfortunate because connec- tors represent the interaction patterns between com- ponents, i.e., the interaction protocols that are em- ployed to achieve the system goals using the sys- tem components, such as reliability. By instead of- fering support only for components, architects end up with two alternatives. One is to ignore protocols, which inhibits the analysis of crucial system proper- ties, such as deadlock-freedom, and also leads to ar- chitectural mismatch [Garlan et al., 1995], i.e., the in- ability to compose seemingly compatible components due to wrong assumptions these make about their in- teraction. The other is to incorporate the protocol behaviour inside the components themselves, which leads to complicated component behaviour that is nei- ther easy to understand nor to analyze and makes it difficult to reuse components with different pro- tocols, as well as to find errors in specific protocol instances. Incorporating protocol behaviour inside components is essentially following a reuse-by-copy approach, whereby each component has its own copy of the protocol constraints. On the other hand, support for protocols through first-class connectors promotes a reuse-by-call approach, whereby there is only one instance of the protocol constraints and these are sim- ply called wherever they are needed.
Show more

9 Read more

A Design-by-Contract based Approach for Architectural Modelling and Analysis

A Design-by-Contract based Approach for Architectural Modelling and Analysis

Another alternative method for specifying software architectures is the architec- ture description languages (ADLs), which have emerged in the nineties and become one of most active areas of software engineering [Vestal, 1993,Clements, 1996,Medvi- dovic and Taylor, 2000, Fuxman, 2000, Woods and Hilliard, 2005]. There are numer- ous ADLs developed so far, e.g., Darwin [Magee and Kramer, 1996], UniCon [Shaw et al., 1995], Wright [Allen and Garlan, 1997], Rapide [Luckham, 1996], C2 [Taylor et al., 1996], LEDA [Canal et al., 1999], AADL [Feiler et al., 2006], SOFA [Plasil and Visnovsky, 2002], RADL [Reussner et al., 2003], etc. Each ADL offers its own architectural notation, but, they share basic notions, e.g., components, interfaces, and connectors. Unlike UML, ADLs allow designers to specify the architectures of their systems precisely. Moreover, ADLs are offered with various features depending on their scope of interest. Some offer automatic code generation for facilitating the implementation of the specified systems. Some offer notations for specifying non- functional properties of systems (e.g., reliability and security), which can be com- municated among stakeholders and analysed via analysis tools. Some offer notations based on formal methods (e.g., process algebras [Bergstra, 2001]) for specifying the behaviours of architectural elements and formally verifying them using formal analysis tools, e.g., model checkers.
Show more

246 Read more

A contract-based approach to describe and deploy non-functional adaptations in software architectures

A contract-based approach to describe and deploy non-functional adaptations in software architectures

In the contract negotiation phase, the middleware tries to establish the required profiles and the associ- ated support required for them. If the GCM concludes that the negotiation was successful the service can be established. The next step is to start the application’s functional components, in the context of the estab- lished support; this is performed using the services provided by the Configurator (described in Section 2). All the presented case studies were implemented in Java. The Java Media Framework was used to imple- ment the functional modules of the VoD application. Java objects were mapped to configurable components through the Configurator, which is implemented fol- lowing the Architecture Configurator design pattern described in [7]. In particular, the structure of CR- RIO’s connectors follows a standard pattern which im- plementation could be supported by a tool. Basically, at the invoker side, after being identified, each method invocation is serialized and, in the sequel, at the tar- get object side a dynamic invocation of the concerned method is performed. We have not put much effort in optimizing our connector’s implementation. How- ever, we made a set of measurements [26] that show a small overhead when compared to the cost associ- ated with the basic machinery required to perform dynamic method invocations in Java, which is con- siderably greater than the normal method invocation cost. The connector’s performance can be optimized either using precompiled stubs (loosing the dynamic context reflective capability - see section 2-b) or using a specialized JVM, e.g, [22] (though loosing portabil- ity).
Show more

16 Read more

Design-by-contract for reusable components and realizable architectures

Design-by-contract for reusable components and realizable architectures

Component-based Software Engineering helps develop software systems out of largely reusable components, thus reducing develop- ment time and cost, and leading to a higher system quality. Reusable components end up having fewer design and implementation errors, as these are identified and corrected through their use by different systems. Researchers in software architectures [36, 19] have iden- tified connectors as another important element for increasing mod- ularity and reusability even further. Connectors allow the specifica- tion of arbitrary interaction patterns, thus allowing such patterns to be reused. At the same time, components no longer need to specify instances of such patterns themselves, thus increasing component reusability too. Indeed, designers can more easily explore alter- native designs/protocols to meet the requirements of their specific system when components are separated from the possible interac- tion patterns (i.e., connectors) that they can be used with. This is similar to how we program in languages such as C++. We define a vector class (re-sizable array), specifying its basic operations and the minimal, local constraints on its use, e.g., that the vector should not be empty when retrieving an element. The vector does not spec- ify anything about reverse, sort, etc. to be more reusable. These are instead specified by independent algorithms, among which one se- lects the most appropriate to their context, e.g., bubble or merge sort. Keeping the two separate increases the code modularity and reusability. Our data-structures/classes stay independent of specific usage patterns, which are described separately as algorithms. In- deed, the reusability of the algorithms themselves increases as well, as they can usually be applied at different classes. Specifying com- ponent becomes harder without support for connectors and some- times specifiers avoid specifying the interaction patterns altogether, which leads to the architectural mismatch problem [17, 18].
Show more

11 Read more

An automated wrapper based approach to the design of dependable software

An automated wrapper based approach to the design of dependable software

Software wrapper technology has been investigated in many fields, including computer security, software engineering, database systems and software dependability. In the context of computer security, software wrappers have been used to enforce a specific security policies [16] and protect vulnerable assets [17]. It has also been shown that security wrappers deployed within an operating system kernel can be used to meet application specific security requirements [18]. Software wrappers have been widely applied in the inte- gration of legacy systems [19], where they act as connectors which allow independent systems to interact and the recon- ciliation of functionality [20] [21]. Examples of this can be found in the field of database systems, where software wrappers are used to encapsulate legacy databases [22] [23]. Software wrappers have been extensively investigated in the context of operating system dependability [24] [25], where emphasis is placed on wrapping device drivers and shared libraries [26] [27]. Software wrappers have also been used to address the more general problem of improving dependability in commercial-off-the-shelf software [28], as well as several more specific software dependability issues, such as the problem of non-atomic exception handling [14]. The proposed methodology is related to [29], where wrap- pers were used to detect contract violations in component- based systems. In contrast, the proposed methodology com- bines software wrappers that implement standard predi- cates and variable replication to enhance dependability. The variable-centric approach, facilitated by the metrics devel- oped in [15], also differentiates the proposed methodology.
Show more

9 Read more

Xcd - Modular, Realizable Software Architectures

Xcd - Modular, Realizable Software Architectures

Connector Role Strategies for Control/Design Decisions A cleaner separation of functional and interaction behaviour aids in increasing the reusability of both compo- nents and connectors. However, one can go even further, e.g., as in BIP [8], and attempt to separate the control behaviour as well. X C D supports this through modular connec- tor role strategies, which are specified externally to connectors, and so can be replaced and modified easily. These are used to specify different design solutions for various is- sues that basic role specifications do not address (on purpose) so as to be as reusable as possible. In fact, such role strategies are already being used in good designs implicitly. Consider a simple call in C: foo(i, ++i), where i=1. According to the C language specification this call is undefined since the second parameter expression (++i) may potentially change the value of the first one (i). So we can obtain either foo(1,2) or foo(2,2). The C language specification does not specify a specific order for eval- uating parameters either in the caller or the callee role, instead under-specifying the procedure-call connector specification on purpose. If compilers have multiple cores at their disposal they are allowed to evaluate parameters in parallel, instead of having to evaluate each one in a specific sequential order. The C language specification allows compilers to apply different evaluation strategies on the caller role by delaying this de- sign decision until the optimal choice can be made, based on the call context and the implementation costs of the available strategies.
Show more

19 Read more

Interfacing User Centric Design of Human Computer Interaction in Quality of Software

Interfacing User Centric Design of Human Computer Interaction in Quality of Software

The study briefly illustrated an initial attempt to use an HCI design model together with SE issues. Our goal was to provide a common reference point for both HCI designers and software engineers to point out the quality currently existing issues. Now users are able to answer that what kind of design decisions are facilitated by presented approach, and what are the impacts (good and bad) in the HCI and SE processes effectively promotes collaboration between SE and HCI 21] [22].

6 Read more

Stimuli-SoS: a model-based approach to derive stimuli generators for simulations of systems-of-systems software architectures

Stimuli-SoS: a model-based approach to derive stimuli generators for simulations of systems-of-systems software architectures

However, even DEVS lacks important characteristics for expressing SoS software architectures, such as (i) the language only deals with the notion of ports; there is no notion of connections and gates separately that is a remarkable paradigm of software architectures (Com- ponents, Connections, and Values/Constraints define a software architecture [48, 55]) used by SoS modeling [56], (ii) in DEVS, every major entity of an architecture is rep- resented as the same type of model (called atomic model). As the single abstraction available, an atomic model pre- vents a complete characterization of the software archi- tecture with the diversity and typical heterogeneity of constituents that form a SoS, (iii) even though it supports environment modeling, its inherent syntax does not have any specific mechanism for representing the surround- ing environment, which is an important aspect of any software architecture, including software architectures of SoS [48], (iv) it does not offer a mechanism to automat- ically create stimuli generators, and finally, (v) since SoS architectures are dynamic, i.e., their constituents are not necessarily known at design time and they can join or leave the SoS at runtime, it lacks the notion of abstract architectures, i.e., a description of constituents and their potential connections with other constituents, and how they could be adapted at runtime. Even though DEVS supports dynamic reconfiguration, i.e., the modeling and simulation of architectures of SoS that adapt themselves at runtime, the language still lacks support for abstract archi- tectures, thus requiring all constituents that take part in the simulation to be known. Therefore, it is not allowed for a new constituent, i.e., a constituent that has not been predicted at design time, to join the coalition at runtime.
Show more

22 Read more

Towards a multidisciplinary user-centric design framework for context-aware applications

Towards a multidisciplinary user-centric design framework for context-aware applications

Once aggregated data have been abstracted or interpreted, the path through the matrix, along with the selected sensed data, is passed to the focal application service section, as shown in Figure 9. Focal services can take one of four forms: (a) task-specific information, either inferred by the application or requested by the user, is presented to the user via the user interface (e.g., the application meaningfully infers that the user is catching a train home and informs him or her of a delay); (b) information is not presented to the user, al- though the application executes a focal service as directed by the user (e.g., the user could augment, as shown in Figure 9, the environment at a precise lo- cation, informing friends of a good bookstore); (c) the application meaning- fully or incidentally infers a particular course of action without the user’s in- tervention (e.g., automatically calling the user’s doctor if he or she were to become ill); or (d) an application service is executed to facilitate other applica- tion services (e.g., the application downloads a software tool for obtaining football scores, in order to more accurately infer a user’s likely course of ac- tion—to the pub to celebrate!).
Show more

44 Read more

An Aspect-Oriented Approach for Supporting Autonomic Reconfiguration of Software Architectures

An Aspect-Oriented Approach for Supporting Autonomic Reconfiguration of Software Architectures

This paper has described an approach for supporting the autonomic reconfiguration of hierarchical software architectures. Instead of using a centralized self- management infrastructure to supervise the entire system and its subsystems, a hierarchical decentralized approach is proposed. Each subsystem (i.e. a composite component): (i) manages its internal reconfiguration independently of other subsystems, and (ii) provides reconfiguration events and goals to its upper level (i.e. the architecture within which it is used), to allow its integration and management. The upper level then: (i) uses these events to be informed about changes which may affect other elements, and (ii) according to the new situation, it reconfigures its architecture and/or changes the reconfiguration goals of components to fit the new needs. This approach can be recursively applied, because the same set of aspects is used at each level (i.e. Monitoring, Reconfiguration Coordination and Reconfiguration Effector aspects). Only the architecture- specific aspect (i.e. the Reconfiguration Analysis aspect) changes at each level, because the context to manage (i.e. the architecture) is different. Thus, this approach provides a software architecture with the following properties: (i) flexibility, due to the use of dynamic reconfiguration mechanisms; (ii) maintainability, because aspect-oriented techniques are used to separate reconfiguration concerns from other concerns, and (iii) scalability, because management is decentralized.
Show more

14 Read more

Finding secure compositions of software services: Towards a pattern based approach

Finding secure compositions of software services: Towards a pattern based approach

To exemplify our approach, in the rest of the paper we use a scenario where a composition of services needs to be built in order to replace a service S acting as a broker for car hire companies and providing quotes for hiring cars. S takes as input the profile of a driver (i.e., a parameter of type Person) and produces a personalized offer based on car hire companies that are within a given distance of the driver’s address. A security property regarding S is that the confidentiality of any input information passed to it must be preserved as it contains
Show more

6 Read more

A pattern language for evolution in component-based software architectures

A pattern language for evolution in component-based software architectures

Recently, we conducted a systematic literature reviews to classify and compare existing research and practices that a) enable architecture evolution [9] and b) facilitate architecture evolution reuse [10]. We observed that a critical challenge to tackle recurring evolution lies with a continuous (empirical) acquisition of evolution-centric knowledge and its application during evolution. In [10], we define evolution reuse-knowledge as: “[…] a collection and integrated representation (problem- solution map) of analytically discovered, generic and repeatable change implementation expertise that can be shared and reused as a solution to frequent (architecture) evolution problems”. Although reuse in existing solution is (pre-dominantly) achieved through change patterns and evolution styles to enable evolution, existing solutions for architectural maintenance and evolution fall short of exploiting knowledge-driven reuse. We believe that the potential beyond individual patterns and styles could only be maximised with a network of patterns that build on each other to enable an incremental and reuse-driven evolution in architectures [11, 12]. Therefore, we propose a language (PatEvol) as a formalism and collection of change patterns that support reusable solutions to recurring evolution problems. Pattern interconnections (a.k.a patterns network) allow possible relationships to exist among patterns (such as variants or related patterns) in the language. By exploiting the vocabulary and grammar of a language, individual patterns can be formalised and interconnected to support reusable, off-the-shelf evolution expertise. Our solution is fundamentally inspired by Alexander’s seminal theory [13] about pattern languages that integrate patterns as repeatable solution to build complex architectures. We identify the central research challenge as: How to foster an explicit evolution-centric knowledge that enables modeling and executing reuse of frequent evolution tasks in component-based software architectures? We now highlight challenges in pattern-based evolution and pattern languages to discuss proposed contributions.
Show more

15 Read more

‘Fit for Purpose’: a cohort-centric approach to MOOC design

‘Fit for Purpose’: a cohort-centric approach to MOOC design

In order to evaluate the MOOC from the perspective of ‘fit for purpose’, we ensured that research tools were embedded into the course design to measure its effectiveness in relation to institutional, educational and educational research goals. Our intent was to generate a comprehensive data set which would form the basis of a research program in its own right. Data included: demographics of the MOOC participants (provided on registration), a Dementia Knowledge Assessment Tool (Toye, Popescus, Drake & Lester,2013) that was administered pre- and post-exposure to content, comments on discussion forums, ‘thought tree’ (a novel discussion activity; Kelder et al., 2013) contributions and participants’ reflective notes. A background survey was designed to assess motivations for registering to participate; feedback comments were invited from those who chose to exit early, and those who finished the course completed a final survey (broader research project of the Wicking Centre), which particularly strengthened our understanding of the educational needs of the cohort and their capacity to translate their learning into practice.
Show more

14 Read more

Analysis of Software Architectures

Analysis of Software Architectures

Component- and connector-level Subsystem- and system-level Data exchange Concern Structural Behavioral Interaction Non-functional Models Formal Type Dynamic Scenario-based Automati[r]

45 Read more

MDA based approach towards Design of Database for Banking System

MDA based approach towards Design of Database for Banking System

The process of software development usually involves a database design. Traditionally, during database design three different models of database are built: conceptual, logical and physical. Conceptual model represents a modeled domain with additional constraints that expressed static and dynamic integrity demands. Logical model also represents the modeled domain but in terms of a chosen data model. In the paper the relational data model is assumed. [2] says that physical model is a data model tailored to a given database system and all the models may be expressed in terms of UML language. MDA involves a collection of models, where every subsequent model is developed on the basis on its preceding model. There are many similarities between traditional process of database design and MDA, so it means that MDA may be applicable for that purpose [2].
Show more

6 Read more

An Argument-based Collaborative Negotiation Approach to Support Software Design Collaboration

An Argument-based Collaborative Negotiation Approach to Support Software Design Collaboration

Practicing collaborative design and negotiation dialogue have been found to be positively linked with argument development and critical thinking skills. The work of Buckingham and his colleagues argue that standardizing an argument's structure facilitates its subsequent communication since important meta-information and relationships can be more easily perceived and analyzed by others [1]. Stephen E. Toulmin’s 1958 work [10] has become commonplace in structuring arguments - Toulmin acknowledges as much in the preface to his 1984 text [11]. For example, Houp, Pearsall and Teheaux’s textbook, Reporting Technical Information, introduces Toulmin logic as providing “a way of checking your own arguments for those overlooked flaws. It can also help you arrange your argument” [6]. The goal of developing arguments in negotiation is to persuade or convince others that one's reasoning is more valid or appropriate. Toulmin's structure of argument provides the language symbols and data structures that support the argumentation process. Toulmin’s structure is procedural and the layout of this structure focuses on the movement of accepted data to the claim through a warrant. Toulmin also recognizes three secondary elements that may be present in an argument: backing, qualifier, and rebuttal. Backing is the authority for a warrant, provides credibility for the warrant, and may be introduced when the audience is unwilling to accept the warrant. A qualifier indicates the degree of force or certainty that a claim possesses. Finally, rebuttal represents certain condition or exception under which the claim will fail and hence anticipates objections that might be advanced against the argument to refute the claim [10]. As such, Toulmin’s argument structure becomes a popular mechanism for structuring arguments between negotiating stakeholders. It aims to clarify the reasoning process by encouraging parties to make explicit important assumptions, distinctions, and relationships as they construct and rationalize ideas [1]. C. Synthesis between the Objective Hierarchy and the
Show more

6 Read more

Towards the practical design of performance-aware resilient wireless NoC architectures

Towards the practical design of performance-aware resilient wireless NoC architectures

In this paper, an efficient router with reduced low-load la- tency is proposed to improve the performance of surface wave- enabled WiNoC. The proposed router architecture has a cost- effective dual datapath design that is able to minimize packet delay under both low-loads and high loads. Particularly, the proposed router employes a fast bypass datapath to reduce the long packet delays due to multi-hops along the long horizontal wires. Furthermore, a deadlock-free adaptive routing algorithm is proposed to avoid congested paths when the NoC is heavily loaded with traffic. Cycle-accurate simulation is conducted to evaluate the performance effect of replacing conventional wired routers with the proposed router architecture in WiNoCs. The simulation results reveal significant improvement in terms of average packet delay compared to existing surface wave- enabled WiNoC even when efficient adaptive routing is used. Future work includes a practical implementation of SW com- munication fabric at the on-chip (nanotechnology) level.
Show more

6 Read more

Assurance Driven Software Design using Assurance Case Based Approach

Assurance Driven Software Design using Assurance Case Based Approach

In [1] Peter, Robin and Sofia have described in detail the goal based Assurance Case and its structure. The authors have also stated the possible issues associated with safety case approach. Authors have highlighted how to structure safety case by separating claims about the system from claims about safety case. This differentiation can assist in distinguishing system quality and quality of arguments and evidence which support the safety case. In [3] Luke and Sofia have described the software Tool ASCE (The Assurance and Safety Case Environment) which is a graphical hypertext software system that can be used to develop, review and maintain assurance and safety cases and relevant technical documentation in structured fashion. Authors have also claimed that the ASCE software tool can be configured to support in software certification process. In [6] Patrick, John and Elisabeth in their paper have explained the Assurance Based Development (ABD) model for development of critical computing system. This approach has used Assurance Case as backbone for constructing and verifying the system goals and evidences and thus providing of justified confidence that the system will work as per the requirements without any issues in given circumstances. Authors also provided details on how they have used ABD approach to develop part of a research prototype for a software system meant for alerting pilots to runway incursions at airports. Authors pointed out that ABD approach facilitates them having various system development choices to choose from and evaluate to ensure having an assurance that the system shall meet its dependability goals. In [7] Nguyen, Greenwell and Hecht discussed a specific industrial application of Assurance Case for transitioning from a legacy global positioning system to its replacement a new AEP
Show more

7 Read more

Performance Evaluation of Software Architectures

Performance Evaluation of Software Architectures

Most diagrams really serve as documentation of architecture and design decisions and do not support making those decisions. We need notations, with tool support, that provide decision support as well as documentation. (Use Case scenarios are an exception to this, which may account for their rapid acceptance and current popularity). In particular, both the process view and the physical view contain facts that are best produced from performance studies (e.g., the assignment of objects to processes and assignment of processes to processing components). Current diagrams for these views are rather complex and it doesn’t make sense to create them before the SPE study is executed, because labor-intensive changes may be required. We envision a tool that would display processes and processing components and give the user a direct-manipulation interface to drag and drop processes to processors (and objects- methods to processes in the logical view), automatically create and solve performance models, give users quantitative feedback on each alternative, then produce process- view and physical-view diagrams as output once the user has picked the mapping they desire.
Show more

24 Read more

6 3 1 Modular Design Approach for Development of Electrical, Electronic, and Software System Architectures for Multiple Product Platforms

6 3 1 Modular Design Approach for Development of Electrical, Electronic, and Software System Architectures for Multiple Product Platforms

Gary Rushton has over 18 years of commercial and military electrical/electronic systems engineering experience. He has an MS in Automotive Systems Engineering from the University of Michigan. He is currently working as an electrical/electronic/software systems engineer specialist with Visteon Corporation. As an engineer with Visteon Corporation, he has worked on audio software, subsystem product development/design, diagnostics, vehicle system architectures, and cockpit system design. Previously, with General Dynamics, he worked on avionics systems for the F-16 and vetronics systems for the Abrams M1A2 tank. He has published several papers in journals sponsored by IEEE, INCOSE, and SAE. He also holds several patents. (grushton@visteon.com).
Show more

11 Read more

Show all 10000 documents...