Academic literature on the topic 'Component architecture'

Software architectures promote development focused on modular functional building blocks (components), their interconnections (configurations), and their interactions (connectors). Since architecture-level components often contain complex functionality, it is reasonable to expect that their interactions will be complex as well. Middleware technologies such as CORBA, COM, and RMI provide a set of predefined services for enabling component composition and interaction. However, the potential role of such services in the implementations of software architectures is not well understood. In practice, middleware can resolve various types of component heterogeneity — across platform and language boundaries, for instance — but also can induce unwanted architectural constraints on application development. We present an approach in which components communicate through architecture-level software connectors that are implemented using middleware. This approach preserves the properties of the architecture-level connectors while leveraging the beneficial capabilities of the underlying middleware. We have implemented this approach in the context of a component- and message-based architectural style called C2 and demonstrated its utility in the context of several diverse applications. We argue that our approach provides a systematic and reasonable way to bridge the gap between architecture-level connectors and implementation-level middleware packages.

In the last three decades, the concept and implementation of component-based architectures have been promoted in software systems creation. Increasingly complex demands are placed on the software component systems, in particular relating to the dynamic properties. The emergence of such requirements has been gradually enforced by the practice of development and implementation of these systems, especially for information systems software.Just the information systems (robust IS) of different types require that target software meets their requirements. Among other things, we mean primarily the adaptive processes of different domains, high distributives due to the possibilities of the Internet 2.0, acceptance of high integrity of life domains (process, data and communications integrity), scalability, and flexible adaptation to process changes, a good context for external devices and transparent structure of the sub-process modules and architectural units.Of course, the target software of required qualities and the type robust cannot be a monolith. As commonly known, development of design toward information systems software has clearly come to the need for the software composition of completely autonomous, but cooperating architectural units that communicate with each other using messages of prescribed formats.Although for such units there were often used the so called subsystems and modules, see (Jac, Boo, Rumbo, 1998) and (Arlo, Neus, 2007), their abstraction being gradually enacted as the term component. In other words, the subsystems and modules are specific types of components.In (Král, Žeml, 2000) and (Král, Žeml, 2003) there are considered two types of target software of information systems. The first type – there are SWC (Software Components), composed of permanently available components, which are thought as services – Confederate software. The second type – SWA (Software Alliance), called semi Confederate, formed during the run-time of the software system and referred to as software alliance.In both of these mentioned publications there is delivered ​​deep philosophy of relevant issues relating to SWC / SWA as creating copies of components (cloning), the establishment and destruction of components at software run-time (dynamic reconfiguration), cooperation of autonomous components, programmable management of components interface in depending on internal components functionality and customer requirements (functionality, security, versioning).Nevertheless, even today we can meet numerous cases of SWC / SWA existence, with a highly developed architecture that is accepting vast majority of these requests. On the other hand, in the development practice of component-based systems with a dynamic architecture (i.e. architecture with dynamic reconfiguration), and finally with a mobile architecture (i.e. architecture with dynamic component mobility) confirms the inadequacy of the design methods contained in UML 2.0. It proves especially the dissertation thesis (Rych, Weis, 2008). Software Engineering currently has two different approaches to systems SWC / SWA. The first approach is known as component-oriented software development CBD (Component based Development). According to (Szyper, 2002) that is a collection of CBD methodologies that are heavily focused on the setting up and software components re-usability within the architecture. Although CBD does not show high theoretical approach, nevertheless, it is classified under the general evolution of SDP (Software Development Process), see (Sommer, 2010) as one of its two dominant directions.From a structural point of view, a software system consists of self-contained, interoperable architectural units – components based on well-defined interfaces. Classical procedural object-oriented methodologies significantly do not use the component meta-models, based on which the target component systems are formed, then. Component meta-models describe the syntax, semantics of components. They are a system of rules for components, connectors and configuration. Component meta-models for dynamic and mobile architectures also describe the concept of rules for configuration changes (rules for reconfiguration). As well-known meta-models are now considered: Wright for static architecture, SOFA and Darvin for dynamic architecture and SOFA 2.0 for mobile architecture, see (Rych, Weis, 2008).The CBD approach verbally defines the basic terms as component (primitive / composite), interface, component system, configuration, reconfiguration, logical (structural) view, process view (behavioral), static component architecture, dynamic architecture, mobile architecture (fully dynamic architecture), see (IEEE Report, 2000) and (Crnk, Chaud, 2006).The CBD approach also presents several ​​ADL languages (Architecture Description Languages) which are able to describe software architecture. The known languages ​​are integration ACME and UML (Unified Modeling Language), see (Garl, Mon, Wil, 2000) and (UNIFEM, 2005).The second approach to SWC / SWA systems is formed on SOA, but this article does not deal with it consistently.SOA is a philosophy of architecture. SOA is not a methodology for the comprehensive development of the target software. Nevertheless, SOA successfully filled the role of software design philosophy and on the other hand, also gave an important concept linking software components and their architectural units – business services. SOA understands any software as a Component System of a business service and solved life components in it. The physical implementation of components is given by a Web services platform. A certain lack of SOA is its weak link to the business processes that are a universally recognized platform for business activities and the source for the creation of enterprise services.This paper deals with a specific activity in the CBD, i.e. the integration of the concept of component-based system into an advanced procedural, object-oriented methodology (Arlo, Neust, 2007), (Kan, Müller, 2005), (​​Krutch, 2003) for problem domains with double-layer process logic. There is indicated an integration method, based on a certain meta-model (Applying of the Component system Development in object Methodology) and leading to the component system formation. The mentioned meta-model is divided into partial workflows that are located in different stages of a classic object process-based methodology. Into account there are taken the consistency of the input and output artifacts in working practices of the meta-model and mentioned object methodology. This paper focuses on static component systems that are starting to explore dynamic and mobile component systems.In addition, in the contribution the component system is understood as a specific system, for its system properties and basic terms notation being used a set and graph and system algebra.

Building software architectures from a set of requirements has been an area of research where programmers, architects and software engineers spend a lot of time using their expertise in resolving peculiar problems of mapping requirements to architectures. Some of these problems are directly associated with the ambiguity, incompleteness and inconsistency of requirements which draw a wide gap between the informal and formal specification of these requirements. The main objective here is to reconcile the mismatch in-between these domains by providing a systematic mapping technique. This paper presents a tool from which requirements are read from user in natural language or file and generated into words whereby the user makes some selections and maps the selected words directly to components architecture. Based on the design of this tool, human heuristic is used in the selection of the words. Unlike components, connectors are set as static. Partial architecture of requirements is drawn incrementally until complete system architecture is constructed

The component-based software engineering (CBSE) ensue the procedure of reconfiguration and reusability of components to reap the higher productivity. The context-aware structures are portion of CBSE, which observes the functionality of the system and adopt automatically according to the execution context. In this paper, we are focusing on the aware context guidelines that automatically adapt to the given context given by the customers and remodel the software architecture based totally on the requirements. The component repository turned into added, in which it carries the wide variety of reusable components. The fuzzy logic becomes carried out to the component evaluation in the component repository. The Particle Swarm Optimization (PSO) algorithm applied, to optimize component architecture. The Hospital management system is used to test the adaptability of the system.

The objective of this work is to examine the feasibility of, as well as to learn about, a process of developing software architecture that prevents the possibility of mismatch between homogeneous components implemented according to the architectural specification. This paper shows how the architecture can be organized, which restrictions it can use and, provided that they are used, how elaborate it should be in order to ensure that independently-developed artifacts are structurally compatible. Two components are deemed structurally compatible as long as they have appropriate code to avoid mismatch. Since the focus of the paper is on the structural forms of mismatch, the results are derived under the assumption that no run-time environment can prevent a component from executing any path in its code. The paper develops a formal model of architecture that provides a minimal set of concepts in terms of which the designers can reason about incompatibility of components. The model is used to identify the causes of structural mismatch and examine alternative ways of eliminating these causes. Following that, the paper adopts a set of architectural restrictions and shows how these restrictions can be applied in the design of software architectures to prevent the possibility of structural mismatch.

To achieve a precise goal of components on different platforms that are presented the some components in order to co-operate with one another over a communication network. The component should be able to access services provided through remote, location transparent service in vocations.The major role of component-based method is represent an ideal framework for component-driven in client/server computing. One of the good implementation examples of broker architecture is Common Object Request Broker Architecture (CORBA). The component based technologies discuss the proposal of distributed object of CORBA which is the Object Management Group’s (OMG).This paper proposes the broker architecture as CORBA has distributed system that can be demonstrated by client-server architecture which practices the base for multi-tier architecture.