COMPONENT MODELS AND SOFTWARE ARCHITECTURE
Peter Taban
Department of Computer Science
MalardalenUniversity
ABSTRACT
The ability to merge detached reusable component to form a complete system is vital technique for effective reuse of software.
In this paper, 1 will discuss the Specification of Software Component, Architecting Component Based System, and a Component in Real-time System.
1. INTRODUCTION
Software system is experiencing a progressive expansion in business sec
t
ors, industry, administration, and research. The demand is highly increasing as many companies are adapting to the technology. However, increasing in the complexity of the system has lead to the introduction of CBSE as many look at the concept as a rescue in the software industry.
The term component specification has have been defined in many different ways depending how people understand the concept. The specification of the component is regarded as specification of interface which is expressed in terms of interface description language (IDL).
The component description language has been considered as the language which helps to express component concept in more understandable manner.
There are three ways by which component description language can be distinguished; these include syntactic, semantic, and protocol description [13].
Increase in demand for reuse of software, has lead to invention of new technique for architecture driven reuse. The concept Software architecture can be defined as the structure of the system which composed of components, connectors and externally visible character of those components, and the relationship between them [3]. The software architecture plays a vital role in CBD, as it depicts a constituent part of a component-based software system. Software architecture has been used for assessment and evaluation, configuration management and for dynamic software architecture [14].
Whereas in a real-time system, a component is subjected to meet timing constraints; the order of execution task and the behavior of their execution so as to hold the production cost low.
2.0 CURRENT COMPONENT SPECIFICATION
The inadequate in component specification in practical software development, has lead to the introduction of the concept syntactic specification. Syntactic specification is applied with the compliance of COM [7], the Object Management Group’s, Common Object Request Broker Architecture (CORBA) [8] and Sun JavaBeans [9].
COM is most prominent technology used with respect to syntactic specification unlike CORBA and JavaBeans.
The concept syntactic specification is used to explain the relationship between components, interface and the parameter types. The diagram in figure1 is extracted from a unified model language [9], which is used to demonstrate the applicability of syntactic specification.
The scenarios are depicted as follows, the rectangles boxes symbolize the components and interfaces, whereas the connectors relates to the relationship between them.
A component exposes either a set of named interface, or a set of types to its user. Every interface is composed of a number of named operations. In every operation, there is either zero or more input and output parameter of each type. In other specification technique, it is also possible for a component to expose interfaces to be used by other component, as well as implementing interfaces provided by other components.
The freedom interface attains from a component, represents characteristic of component specification methodology. For an operation to be part of different interfaces, it must favor the possibility of inheritance and sub tying between interfaces.
Object oriented specification is mostly used with respect to component specification as it does not direct to lose of generality, since procedure specification can be looked as an important case of object oriented specification.
The COM component presented bellow; it gives an overview of IDL file. The file offers inadequate information through its operation and the number of its parameters [7].
Interface ISpellCheck: IUnknown
{
HRESULT check ([in] BSTR *word, [out] bool *correct);
};
Interface ICustomSpellCheck: IUnknown
{
HRESULT check ([in] BSTR * word);
HRESULT check ([in] BSTR * word);
};
Library SpellCheckerLib
{
coclass SpellChecker
{
[default] interface ISpellCheck;
interface ICustomSpellCheck;
}
}
A vital aspect in interface specification is how they can be used in substitution and evolution of component. From syntactic perspective, a component can be substituted if the new component implements the same interface as the old one.
2.1 SPECIFYING THE SEMANTICS OF COMPONENTS
It is acknowledge that the semantic information of a component operation is vital for effective to a component as it provides, a number of operation value, an operation’s error codes, and restricts the manner an operation are invoked. There are several methods introduced for designing component based systems, these includes the Object Constraints Language (OCL) [11] and the Catalyses [12]
The diagram in figure 2 illustrates the concept of semantic specification as follows.
A component implements a number of interfaces that consist of a number of operations. A precondition is assumed to hold when an operation is called, and a postcondition is considered to function when an operation is invoked. The state of pre and postconditon will rely on components state.
Figure 3 bellow shows states models of the two interfaces A class that is marked with a stereotype notation <Comp spell> indicates that it’s a member of component specification.
An important aspect with a model depicted bellow is to illustrate collaboration of a model with interfaces.
Figure 3
2.2 SPECIFYING EXRAFUNCTION PROPERTIES OF COMPONENT
The specification of software architecture has raised a lot of questions within software architecture community as it is not well explained by the convention of software doctrines [14].
For successful use of architecture component, additional information is required such as extra functional properties and a family’s properties is required to state the relationship within similar connected components.
2.3 THE ROLE OF SOFTWARE ARCHITECTURE
The software architecture is being regarded as the backbone of a software system as it plays a vital role in development and evolution of CBSE.
There are three important roles in which software architecture posses, these includes, assessment and evaluation, configuration management, and dynamic software architecture [14].
2.3.1 ASSESSMENT AND EVALUATION
Capturing early design decision is a challenging factor and most expensive to change once the system is constructed. It is therefore vital idea to assess the software architecture so as to fulfill the functional requirement in the early phase. Due to this restriction, it has lead to the introduction of software architecture constraints known as a quality attributes, which used for estimating the correctness of software architecture when relating to quality requirement. Three assessments and evaluations used for estimating the correctness of software architecture are as follows, stakeholder-based evaluation, expert-based assessment, and quality attributes assessment requirement.
SAAM [15] is one of the examples that use stakeholder-based assessment methods, which has developed to documented architecture Trade-off Analysis Method (ATAM) [15].
In Expert-based assessment, designers and architectures assess a software architecture designed so as to fulfill functional and quality requirements.
A stakeholder assessment permits the stakeholder and architects to assess the mistakes in the architecture.
2.3.2 CONFIGURATION MANAGEMENT
Software architecture is used with respect to software product lines.
It is acknowledge that software becomes often used if a product is well configured.
2.3.3 DYNAMIC SOFTWARE ARCHITECTURE
Software architecture is considered as the first class entity of the system operation, because it facilitates change in system operation. A change is usually conducted by substituting the existing component with a new one so as to alter the architecture with respect to a system quality requirement.
3.0 ARCHITECTURE DESIGN PROCESS
An architecture design process is considered as a function that takes requirement specification as input parameter and produces architecture design as output. The concept is divided into different phases, these includes, functionality-based design, assessment of the quality attributes of software architecture with respect to quality attributes, and finally the evaluation of design so as to comply with quality attributes. Figure 3 bellow depicts architecture design process.
Figure 3
3.1.0 ARCHITECTURE STYLES
The structure in software architecture can considered as a component and the connectors and the pattern of interaction. Figure 4 bellow illustrate architecture transformation categories
Architecture style is considered useful in software architecture perspective as it offers exact semantics architecture diagram in the sense that styles signifies connectors, which symbolize relationship between components.
I will discuss three different architecture styles used with respect to CBSE. These includes; Pipe-Filter, Blackboard Architecture and the Object-Oriented Architecture
3.1.1 PIPE AND FILTER ARCHITECTURE
The Pipe and filter architecture style is composed a component and a connector, the filter depicts a component whereas a pipe represents a connector. The communication between them is restricted in such a way that a pipe acts as a communication links between two filters.
3.1.2 BLACKBOARD ARCHITECTURE
The component and the data processing components are usually regarded as a blackboard. Data process component communicates with repository (component) by reading input for specified the repository, and writing to repository when it’s necessary.
3.1.3 OBJECT–ORIENTED ARCHITECTURE
Object and connector are usually considered as object-oriented architecture. The connector synchronizes massage passing and the objects states the methods for manipulation
The system level attributes for an architecture style can be identified by observing style on the system architecture.
The degree of occurrence in architecture style can be used to decide the negative and positive relationship among architecture style and quality attributes.
Architecture / Performance / Maintainability / Reliability / Safety / SecurityPipes and Filter / + - / + - / - / - / +
Blackboard / + - / + / + - / - / + -
Object-Oriented / + - / + - / + - / + / + -
Table 4 Architectural Style and Their Affinity to Quality Attributes
3.2.0 ARCHITECTURE DRIVEN COMPONENT
The aim of embodiment phase in software architecture is to construct or choose components and connectors that attain the quality attributes ascertained during the architecture development phase. Three types of components used to associate embody architecture components are customs-build components, commercial components or reusable components.
3.2.1 CUSTOMS-BUILD COMPONENTS
Customs-build components are components build and authorized by the company for specific use.
3.2.2 COMMERCIAL COMPONENTS
These are components constructed with specific reason for sale.
3.2.3 REUSABLE COMPONENTS
These are components designed for specific function and not for reuse, and must be familiar to be integrated to a new system.
4.0.0 COMPONENT IN REAL-TIME SYSTEM
Real-time components are components subjected to meet timing constraints, maintain production cost law, and must complete within tight deadline. However real-time component do face composability problems which support communication, synchronization, and timing behavior for a component and the system in general.
4.1CHARCTERISTICS AND CHALLENGES OF REAL-TIME SYSTEMS
Real-time systems are systems in which the correctness of the system does not only depend on the computation performance, but the system must meet time constraints when executing a task [17].
Real-time systems are systems developed of coexisting programs called tasks A scheduling policy is an operation that a CPU defines to different tasks in conformance with predefined criteria. It is usually a parameter assigned to a task before activation begins.
A deadline is defined as a maximum time a task is allowed to execute an event. A real-time system is divided into hard and soft real-time. In hard real-time, deadline is allowed to be met as prescribed in system requirement, whereas in soft real-time system, deadline is considered seriously.
Applying CBSE methodology in real-time system, we should acknowledge the reusability of real-time components. However designing a reusable component is more complex than designing non reusable component [18], as component must cooperate to meet the deadline [19], maintain production cost down despite scarcity in embedded system resource function that work within tight deadline and finally it is difficult to predict a particular event to happen for in execution order, and the duration an event takes.
In the real-time system, the hardware is considered as a main course for complexity, as it requires a design of priority-driven system other than to focus on important task in system loading. It is also important to design real-time system so as handle exceptional problems.
In CBSE technology such as JavaBeans, CORBA, and COM are seldom use with respect to real-time system as they demand high processing and large memory requirement. Such technology posse’s unpredictable timing characteristic which is not considered in the real-time application.
It is also difficult to develop specific real-time component that can operate in various platforms since timing constrains will varies from one platform to another, therefore we need to carry out timing analysis for every platform if we are to consider such technology.
There are two ways in which timing analysis is conducted in real-time system, these includes, the task level and the system level
At the task level, the worst-case execution time (WCET) for every task is analyzed, then analysis then is done by either measurement or by static analysis for the given code, whereas for a system level, the analysis is carried out to ascertain if the system fulfills the timing requirement.
4.2REAL-TIME COMPONENT MODEL
The components infrastructure includes database, communication protocol, application specific component model, and user interface.
A database or an operating system is not considered practicable as such system is designed to increase output and do not assure temporal prediction ,and so, we have use COTS design for real time if we are to assure predictability.
4.3APPLICATION COMPONENT SPECIFICATION MODEL
It is of a benefit to posses a component library so that application developers can extract from when they are to develop applications.
The aim is to be familiar with component with well defined temporal character and resource demanding so as can easily constitute a system.
The IEC 61131-31 standard, is a standard used for programming industrial control and a component-based system for robot design.
The IEC61131-31 associates with tools such as debuggers, test tools and programming languages.
The model shown bellow illustrates a configuration in IEC 61131-31-3 which is used to encapsulate software’s to an application.
The dataflow is detailed in IEC 61131-31 function block shown in figure 5.It illustrates a simple function block diagram depicting a feedback controlled loop.
A real-time tasks are combined with a function blocks. Task is categorized by periodic of event driven.
The PBO approach is a used for evolution of domain specific components that increases usability, flexibility, predictability, and state temporal behavior. Independently task can not communicate directly to other component as they are loosely connected to facilitate reuse.
Figure 5 bellow shows the PBO diagram.
4.4DESIGN COMPONENT – BASED REAL-TIME SYSTEM
The component model applied is inherited from a PBO model. It comprise of temporal attributes such as release time, WCET, deadline, and synchronization constrains such as precedence relationship and mutual exclusion. The development procedure imposes in the system specification is attained by examining the customer’s requirement.
The development process begins with system specification, which is regarded as the top-level design.
In top-level the disintegration of the system into component is conducted to favor designers while making selection from available component. The diagram in figure 6 illustrates the design model for real-time components.
Adding new component should always be done into the component library. After the system has attained a specification requirement, the timing behavior of the system has to be tested on the platform to affirm that it coincides with the timing constraints specify in design.
4.4.1 TOP LEVEL DESIGN
The top level design is basically considered as the first stage of the development process whereby system is decomposed into manageable components. It is where the designer states the functional and the safety issue in every component.
4.4.2 DETAILED DESIGN
The components are chosen to be used in the candidate set, and a component is designated a time budget.
4.4.3 ARCHITECTURE ANALYSIS
In architecture analysis phase, the system is analyzed if is fulfill the maintainability, modifiability, reusability and testability. Several methods have been employed for conducting architecture analysis; these include simulation-based methods, and scenario–based methods.
4.4.4 SCHEDULING
It is a phase where designer verifies if temporal requirement of the system are fulfilled, However if it is not, reengineering of requirement or substituting components with those in the candidate set should be performed.
.
4.4.5 WCET VERIFICATION
WCET is conducted by static analysis of the source code or by dynamic verification. As static analyses are limited in the market, dynamic verification is most considered with respect to component. The WCET of a component is achieved by measuring the longest time it takes to execute the task.
4.4.6 IMPLEMENTATION OF THE NEW COMPONENTS
A new component is a component which does not exist in the library. The designers are therefore required to assign the component with a functional requirement and the time budget. A standard development procedure is introduced with exclusion of time budget.
4.4.7 SYSTEM BUILD AND TEST
The designers are required to attest acquired temporal and functional property of the system, incase the verification test declines, the designer have to rebound to important stages of the development process so as to faultless it.
4.4.8 COMPONENT LIBRARY
A component library is considered as a vital part of CBSE system, as it comprise of a coupled components and their descriptions. Choosing component from the library is done by inspecting the library attributes. A component library that is comprised of a real-time component should favor component identification, interface, functional description, test cases and component binary.
4.5 COMPOSITION OF COMPONENTS
A component is comprised of one or more tasks, whereas diverse components combine to form a complex system. This is attained by defining an interface for a given component and joining input and output ports of its structure. Figure 7 depicts the concept. The end-to end deadlines should be defined so that the system requirement is met and the time budget set. Virtual timing attributes such as release time, period and deadlines are used for calculating timing attributes of subcomponents. This facilitates timing specification attributes at appropriate abstraction level. The references to subcomponents are preferred rather than binary of component so as to favor procurement of actual set of binaries.