A component‐based development process for trustworthy systems

Abstract

This paper introduces a new process for a rigorous component-centered development of trustworthy systems. The rationale for our perspective of the process is two-fold. The activities prescribed in a conventional software engineering development process are neither suitable nor sufficient for developing component-based systems. Component-based development methods that are currently practised do not support the explicit specification of trustworthiness properties, and are not based on rigorous principles. Hence they are not suitable for developing trustworthy systems. Trustworthiness is regarded as a composite nonfunctional property comprising the four attributes safety, security, availability, and reliability. They must be rigorously defined for components and systems composed from them. It is essential that the process enforces a direct evidence of trustworthiness in the systems that are developed following the process. Consequently, the development process, in addition to being reuse-oriented, component-oriented, and rigorous in all phases of the system lifecycle, should maintain the chain of evidence that the trustworthiness properties are preserved in every activity of every phase of system development. The proposed process includes several parallel interrelated tracks including component development, component assessment, component reuse, and component-based system development and prescribes specific activities and tools for ensuring trustworthiness in all activities.Figure 5. TADL specification of the controller component.Type, Interface Type, Component Type, Security Policy, and Reliability, (2) element name such as Lock, StartCar, and IController, and (3) specification of the contents of the element. For example, the Unlock service definition includes the following elements: the request event (RequestUnlock) which triggers the service, the response event (UnlockDoor) which is executed in response to the request, a time constraint (UnlockOntime) which states that the response should be executed within one unit of time after receiving the request, and a security policy (UnlockDoorSecurity) which filters the requests and ensures that the response is executed only if the logical expression HasPrivilege(User, Unlock)∨HasRole(User, Driver) evaluates to true. A role-based access security specification defines sets of users, groups, roles and privileges along with associations of users to roles, users to groups, roles to users, roles to groups, and privileges to roles. Therefore, domain engineering yields an ontology representing the knowledge base of the domain. The domain architecture can be deduced from the ontology. It includes the applications and their relations. Then, an architecture is created for each application. This architecture is specified by idle Guard: HasPrivilege(User,StartCar) || HasRole(User,Driver) Sync: RequestStartCar? startCar lock unlock Restart Sync: StartTheCar! Guard: HasPrivilege(User,Lock) || HasRole(User. 24. Ibrahim N. Transforming architectural descriptions of component-based syste...

A Context-dependent Service Model

“…Towards this we used the formal component-based approach [36] in SCL to develop trustworthy services. The development cycle is based on the process model [37] introduced by Mohammad and Alagar. This is a goal-based model in which the dependability criteria is specified at domain level and the system is developed to satisfy the criteria.…”

An Industrial Standard to Assure Dependability in Software Reuse

“…To sum up, before reusing a software component, the context and domain it was built for should be carefully compared with the context and domain it is intended to be built in, including the hardware and physical and organizational aspects (Mohammad and Alagar, 2010). Figure 1 depicts the elements of the reuse process which is the subject of this paper.…”

Assuring Dependability of Software Reuse: An Industrial Standard

“…To sum up, before reusing a software component, the context and domain it was built for should be carefully compared with the context and domain it is intended to be built in, including the hardware and physical and organizational aspects [8]. Figure 1 depicts the elements of the reuse process which is the subject of this paper.…”