Formal specification of non-functional properties in component software engineering - Research Paper Example

?Formal Specification of Non-Functional Properties in Component Software Engineering Insert Formal Specification of Non-Functional Properties in Component Software Engineering Introduction The latest software schemes are developing more complicated in technology than any other thing. This intricacy directs to risen time to promote or to broadened numbers of errors initiated into the software. It has thus turned out to be essential to counter the rise in intricacy and issue growing techniques that can assist in managing the intricacy. Component-based software engineering (CBSE) is observed as the best example of such technique (Chen, 2004). It assists in handling the intricacy through following a divide-and-conquer tactic, modularizing huge software schemes into smaller, reusable elements called (software) units. CBSE is believed to be chiefly effective in the background of what is referred to as unit markets, where units are established by autonomous third party establishers and purchased by application contractors to be organized into full applications. If the elements are to be bartered on component markets, they have to be escorted by a specific illustration of all of their pertinent properties (Lamanna, 2002). Element developers must articulate such an illustration without understanding the background in which their elements will be employed. Conversely, it has to be clear to the application contractors and has to be achievable for them to create specifications of distinct elements and rationalize about possessions of the ultimate system. For instance, application contractors need to acknowledge whether an application constructed from some set of elements (Bechhofer, 2005). These elements are organized on a system with reliable amount of present resources will accomplish the required execution goals, how much network bandwidths or memory will be devoured or whether data value will meet the needed benchmark. Thesis statement The ultimate aim of this report is to examine the concept of formal specification of non-functional properties in component software engineering. This entails reviewing the entire aspect of software development and looks at the specification languages that already exist as well as examining the component forms related to specification languages . The paper then examines the problems statement and the research plan then winds up with a conclusion. Literature Review General Concept of Software Development The following diagram (figure 1) provides an indication of the general software development procedure for non-functional characteristics. The main concept of approach is the division of measurement description usage meaning that precision of non-functional characteristics of applications using those gauges. A measurement refers to something that is practical to a system and produces quality value for the scheme being gauged (Chen, 2004). Examples of measurements are delay, response time et cetera. Measurements are mostly described in relation to a contextual model which defines the concepts of an application system that has to be recognized in order to develop the measurement value. Therefore, dimension can be described autonomously as a real practical system. To employ measurements to a practical system, a mapping between the component model of the practical scheme and the context model of the measurement must be illustrated. The descriptions of measurements can be sophisticated, but on the other hand, it will be developed only a single time. Thus, the roles of dimension designer and practical designer must be put apart in the development process. According to Heiko Ludwig 2004, their joint efforts directs to a precision of the system encompassing its non-functional characteristics (Bechhofer, 2005). The measurement modeler employs a graphical notation centered on the specification language CQML+ [2] and notions from [3] to identify measurements and their context designs (Zschaler, 2008). Ludwig adds on that designer can then described distinct context models representing distinct degrees of abstractions. Such context models are linked together via transformation precisions (Zschaler, 2008). The practical modeler concentrates with purification of the system model of the application under progress. He employs the gauges and transformations described by the measurement modeler. The graphical notation for QoS restraints which permit people to symbolize non-functional specifications in UML models. In that note, any component of the UML model can have attached a restraint over predefined measurements. Figure 1: overview of the development process for non-functional properties For functional designing, the main component element used is the component design element of UML 2.0 [4] widened with a stereotype for boundaries to be able to differentiate between operational and watercourse interfaces (Della-Libera et al., 2000). The outcomes of non-functional precision can be employed for a wider range of functions. Moreover, producing code for runtime watching of QoS limits, its key use rests in giving a foundation for supply reservation and QoS management in the functioning system (Chen, 2004). Consequently, the precision is initially changed from human understandable nature of CQML+ to a more compressed, XML-centered nature that is optimized for automaton usage. Resource-Layer QoS Specification Application-layer specifications only denotes the needs in a quite high-level, theoretical manner. The same requirements can be further translated at a later stage to a supplementary real resource demands. This means that illustrations like physical possessions will be required for that application, when they require apportion, the kind of mechanisms to be accepted and implemented, and the type of transport system to be employed, need to be given out (Burdett, 2006). The context also adopts two groups of granularity which are through coarse granularity that provides a metal-level precision and fine granularity that provides a real definition of required possessions. Coarse-Granularity Resource-Level QoS Specification 1. Characteristics: certain possession layer QoS precisions only specify possession requirements in a quite theoretical manner. For instance, they precise what (amount of) possession is needed, but they never concerned about how the possession need to be assigned, or what suit to assume if the possession requirement cannot be accomplished, or if numerous instances such as processors are available and which particular one to employ (Lamanna 2002). The languages that do not permit illustrations of fine-granularity possession requirements are known as the coarse-granularity languages. 2. Case Studies: two coarse granularity resource-layer QoS precision languages are evaluated; RSL and SPDF. RSL stands for Resource Specification Language and is established to by Globus scheme and is used to convey appeals for possessions between elements in a meta computing techniques (Bechhofer 2005). The novelists came up with a hierarchical possession management architecture containing numerous elements, namely, resource co-allocator, local resource controller, resource broker and a wide-ranging resource specification language – RSL. Originally, an application identifies its QoS need in RSL. This specification is of high-intensity since the needed items may be physically allocated in numerous areas and systems. This high-intensity precision is passed through resource brokers that converts it into real resource needs and positions the required possessions. This conversion creates a precision, which the authors referred to a ground request, whereby the positions of the needed resources are completely identified (Bechhofer, 2005). A co-allocator is then accountable for coordinating the distribution and management of resources at manifold sites through fracturing the multi-request (encompassing resources at manifold sites) into numerous requests and delivering them to the suitable local possession manager. The syntax of RSL is very straightforward and its built through joining uncomplicated stricture precisions and conditions with sensible operators &, and +. As a means of example, the multi-request below demonstrates how the executable program, myprog, requests 5 nodes with a minimum of 64 MB memory, or 10 nodes with at least 32 MB memory. &(executable=myprog) (|(&(count=5)(memory>=64))(&count=10)(memory>=32)) A basis request that occurs as a result of the conversion of brokers would supplementary identify information about which resource control will be taking care of the specific requirements in the multi-request, so that a co-allocator can decide to which resource control each element of the multi-request need to be surrendered (Partha 2007). The RSL is the best example of a resource description language but others in the same category include the SafeTel, QDL, Fuzzy Control and CQML among others. SPDF stands for Simple Perquisite Description Format and is also another straightforward illustration language. It was established as a part of the PhD theory of Kon for identifying perquisites of practical elements. An SPDF precision is divided into two parts: the temperament and capacity of the hardware possessions and the software services that an element needs (Della-Libera et al., 2000). A good example of SPDF precision is as shown in the figure below. The figure is self-explanatory. Note that both RSL and SPDF deals with timing of resource distribution or resource balancing or alteration. …hardware requirements Machine –type SPARC OS name Solaris OS version 2.7 Min-ram 5MB Cpu speed >300MHz …..software requirements File system CR:/sys/storage/DFS 1.0 TCP Networking CR:/sys/networking/BSD-sockets Figure 2: An Example of a SPDF Since multi media applications are very receptive to timing, and are alterative in the sense that possession requirements are normally supple instead of stiff, a coarse-granularity language never fits well for a multimedia application. Comparisons of Application-Layer QoS Specification Languages The qualities of service (QoS) languages are different from each other depending on different factors. These factors are expressiveness, independence, declarativity, reusability and extensibility. The most significant factor of all the above is reusability and it determines the quality of the language. The arrangement of the specification languages is mostly done in ascending order. This means that the oldest specification language is mostly at the top while the latest is at the bottom. The QML is one of the most recent and the best QoS language that is able to meet the requirements of several multimedia applications (Chen, 2004). The SafeTel language on the other hand is one of the oldest languages and is observed as the poorest in the sense that it was only useful during its days but due to the advancement of technology, it is now observed as insignificant in multimedia applications as compared to the other languages (Burdett 2006). SLAng on the other hand, is one of the best specification languages that works properly in multimedia systems since it is appropriate for automated rationalization of systems. Apart from QML, all the other specification languages have poor reusability. However, unlike QDL, CQML, CQML+ and QoS-A, the rest of the specification languages including QML have poor to fair expressiveness (Zschaler, 2008). Expressiveness is the ability of a language to flow and be understood well. This means that despite QML being the best specification language, it is complex and difficult to understand or follow its steps since it has a fair expressiveness. Fuzzy control is also one of the oldest languages in the market and is also a little bit complex and of poor quality in comparison to other latest specification languages. Expressiveness, declarative, independence, performance, extensibility, reliability and reusability are the best examples of non-functional properties that classify the specification languages. Note that QML is the most reliable specification language while SafeTel is the most undependable specification language (Zschaler, 2008). Similarities of Specification Languages To begin with, all the specification languages are software programs which are developed by software engineers (Della-Libera et al., 2000). Besides, the Quality Assurance Language is similar to XML in the sense that both of them are centered on the Time Stream Petri Network (TSPN) official model. This means that both of them depend on this network model in their operations. The TSPN model eases finest QoS mapping from appliance stage requirement to motivational communications service precisions. Xiaohui Gu el 2006, puts it clear in her book, An XML-based Quality of Service Enabling Language for the Web, that most of the specification languages apply to multimedia systems (Bechhofer, 2005). Some of them include XML, SLAng , XQoS, CQML and many others. In fact, SLAng has its origin in the E-business and web services, which means that it can apply well to a multimedia system. Moreover, just like XML, SLAng also issues a format for QoS cooperation and develops specification. It is also modeled to be suitable for automated rationalization of systems. In addition to that, all the specification languages are modifiable meaning that they can be modified anytime an advancement occurs. Advantages of specification languages One of the most important aspects about the specification languages is that they are efficient and modifiable in the sense that they can be updated when new technology is employed. This means that these languages are flexible and can be modified to suit other functions (Partha, 2007). For instance, CQML+ is a modification of CQML meaning that CQML is advanced and efficient than CQML. XQoS was advanced to create XML, which is very efficient and up to date. QML is also an advancement of DML. Xiaohui Gu el 2006, confirmed that XML is the most reliable specification language now because it can be reused repeatedly unlike the other specification languages. Moreover, other specification languages can replace most of the specification languages (Chen, 2004). For example, SafeTel is one of the oldest specification languages. Software engineers definitely replaced the language with another sophisticated language say, QML or CQML or any other advanced specification language. The machine will definitely continue to operate normally though more efficient than it was due to the installation of an advanced language (Burdett, 2006). Limitations of specification languages Just as mentioned, the properties of interest in the service swarm and the customer system are basically the same. They widely plunge into speed, operating system, software configuration, storage and dependability, which encompass reliability, availability, security and safety. It is a large limitation to the QoS at all these levels mentioned in the sense that all of them must be considered. The problem with this fact is that these levels interfere with the functioning of the specification languages (Bechhofer, 2005). For example, think of certain service operation that carries out computation and gives back the outcome to the customer. If the completion time is significant to the customer, then not only will the speed of the service operation be pertinent but also, it may be impossible to neglect the latency of network, error rate, jitter and bandwidth. What it means is that the QoS, which is associated to the specification, is not that reliable when entrusted to function on its on (Chen 2004). Moreover, apart from XML not all the other specification languages can be reused. This means that once their operational time is over, they become meaningless. Problem Statement The problem with most of the specification languages like the QML, CQML, CQML+, SLAng as well as modern software systems is the ever-increasing complexity and broadening of their sizes. As technology grows, so do these software systems and specification languages grow, both in size and complexity in the sense that they become more powerful and effective (Della-Libera et al,. 2000). Most applications are never constructed from monolithic styles from scrape, but are considerably joined from elements; this means they are pre-built units of software. In particular, the specification languages are very complex especially in noting their programs. For example, the executable program of RSL called myprog, requests 5 nodes with a minimum of 64 MB memory, or 10 nodes with at least 32 MB memory. The program is executed as shown; &(executable=myprog) (|(&(count=5)(memory>=64))(&count=10)(memory>=32)) Note that this is one of the simplest programs in specification languages because it lies under the older specification languages like the SafeTel (Burdett, 2006). The advanced specification languages like QML and CQML+ have very complicated programs that cannot be understood by any person who is not a programmer. This means that their software are more advanced than the last decade’s software systems and are much effective as well (Partha 2007). Scope of the Research The range of research in this context is between the definition of problem, which is already identified to the solution of the problem of increasing complexity and size of modern software systems as well as specification of formal framework. The ultimate solution to the problem identified is the component-based software engineering. The function of the component-centered software engineering is to specify clearly the properties of those software elements (Lamanna, 2002). This is very clear for functional properties but for the non-functional properties, there is still study being conducted. Specifically, basic methodologies that employ similar formalism for random non-functional properties and therefore minimize the cognitive load for practical developers are not yet acknowledged properly. Therefore, the research examines an official framework for a basic approach for identifying non-functional properties of component-based systems. The structure then is used to describe the semantics of a precision language and to identify analysis methodology for precise non-functional properties. Motivations The fundamental motivational factor for this research is the advanced knowledge in the software engineering field generated by innovations and modified technology. Professional scholars, who were curious to know what lied behind the specification languages and what made them to operate efficiently in different programs therefore, conducted the study. The other motivational factor was the availability of required materials and items to implement their projects. Technology played a very important role in the whole process especially in the identification of the program codes and operators which require high-intensity of knowledge and understanding. Proposed original Contribution The original contribution to this research was the researchers and software engineers who were interested in CBSE and non-functional properties. The contribution of researchers is the fact that they lead to the availability of increased appendix of certain sample specifications for real properties and applications. The software engineers developed the specification languages using the sample specifications established by the researchers (Chen, 2004). Therefore, both researchers and software engineers played a significant role in fostering the required outcomes of the study. Research Plan A semantic Framework for Specifying Non-Functional Properties This section begins by looking at the overview of high-intensity followed by an intensive discussion of the issue to stretch the main concepts to networks of elements and to precisions of more than a single non-functional property (Della-Libera et al., 2000). The most significant contest in describing the precision framework is to give adequate and suitable layers of a concepts allowing self-reliant specification of elements and the services they finally provide. To this far, five specification types to be discussed in precisions have been defined. The figure below (figure 3), provides a graphical analysis of these specifications and their associations. There are two major sides of establishing component-centered systems with described non-functional properties: 1. Component establishers must instigate in such a manner that they have decidable non-functional properties (Burdett, 2006). 2. Practical designers and the runtime scheme must employ these elements so that the non-functional properties needed from the application can be assured. Example 1: Implementation vs. Usage There is no any assurance about the memory utilization for a FIFO line up component which was realized using a linked catalog without any boundaries on its utmost size. Figure 3: System model conveyed as a UML diagram But even if the lineup was instigated with a fixed-size collection of 64 KB, the runtime scheme can still employ this instigation in such a manner that it uses up 256kB of memory: through developing for examples. The report assumes elements with determinable non-functional possessions to be present. Centered on this fact, semantic framework is issued out, which permits component developers to define the non-functional properties of the elements they have established, and application modelers to illustrate how these elements are employed to give assurance non-functional properties of a practical (Lamanna, 2002). The employment of models plays a vital role in determining how the QoS should be used in service-centric system. The intensity of adoption of service detection and SLAng compromise mechanisms are the basis of this. Opposition to the uptake of this advancement is probably, in fragment since individuals doubt them more than they doubt available human correspondents. If the highly lively practice situation is to occur, a QoS and SLAng specification language will be among the major modification basis. Study on quality of service-centered innovation, SLAng and thus measurement and supervising all depends on a victorious QoS/SLA specification language (Della-Libera et al. 2000). As par the dialogue in specification language sector and the inspection of available languages, it is likely to come up with the following surveillances concerning the requirements of a service-centric QoS specification language: 1. It has to be extensible: the concepts of concern may differ broadly between services. A workable QoS specification language is thus possible to become modular and extensible. It should not always try to describe a comprehensive record of limitations, metrics among other things but permit realm precise expansions to permit for accomplishment. 2. It should be XML centered: this would permit incorporation with the XML centered service structural design (encompassing available languages like BPEL, WSDL) and possess merits like customary and tool support for confirmation, conversion and searching. 3. It has to permit more complicated precisions than simple borders: in specific, it is mostly the instance that one constraint may be exchanged off for another or that is suitable for stages of service to humiliate in some ways. In order to involve these and other opportunities, it is suggested that a rational uncontaminated declarative is required (Burdett, 2006). 4. It has to encompass failure and non-fulfillment semantics: it is significant not only to be capable to come up with accord concerning what occurs under normal circumstances, but what occurs in outstanding circumstances. If it is significant that some QoS accords are achieved then the activities to adopt when they cannot or are not achieved are equally significant. 5. It cannot be available in segregation: the QoS precisions must be available within certain surrounding in order to posses a meaning. Consequently, as denoted above, how QoS is pertain in practice is a major component in determining what constructive language would consist of (Della-Libera et al., 2000). The language has therefore orient issues like prediction, measurement, compliance verification, monitoring, provision and compromise and has to incorporate customary and languages in these regions. WSLA already goes certain way to accomplishing all these decisive factors. Nevertheless, it may be over-steered, and it lingers to be observed whether it achieves extensive support. Heiko Ludwig, 2004 denotes that OWL-S requires additional augmentation to completely achieve the obligations, but given its broader abate of semantic illustration it is conceivably a satisfactory candidate for the task of QoS illustration too. The precision languages such as QML, CQML, CQML+, XML and SLAng among many other discussed in this context should update such an augmentation of the OWL-S ontology. Maybe the most clear way of all to distribute QoS abilities is by enlarging WSDL. According to Xiaohui Gu el 2006, splitting the operational interface illustration from the non-operational is significant as the operational border may be precised by certain third party such as standard organization although non-operational characters will still differ between performances. WS-rule is therefore, an attractive and interesting customary though it never provides solution to the QoS specification difficulty on its own (Bechhofer, 2005). Study into QoS-centered service unearthing is widely ensnared with that of QoS perquisites precisions: the initial difficulty is finding out what the finest forms are for QoS requirements and inquiries – which are necessarily of the same mode. Automatic SLAng conversation is a region broadly open for study (whether it come out to be broadly employed in another query). The procedure itself must be studied further well tuned (and the pertinent inputs from the two parties on how they resolve it (Lamanna 2002). The QoS specification language will illustrate parts of what are being discussed, other components of the complete SLAng specification language like third parties and costs will create the rest. Intermingling between the compromising go-between and the measurement and fulfillment supervision services is also important to issue significant accord which has to be stuck to. Examining the entire QoS depiction for service-centric scheme engineering, it is evident that all the way through the procedure, there is partly cover in the units stated at distinct stages. To enhance soft boundary between these levels, the most crucial thing is that the languages and procedures employed are regulated (Burdett 2006). To make sure there is an ordinary terms and an acknowledgement that adds on to a service ontology like that described by OWL-S. Conclusion The specification languages are compared in terms of the non-functional properties where they are gauged depending on distinct factors such as expesiveness, reusability, declarative, dependability, performance among others. According to the research conducted, QML is one of the recent and best QoS specification language. One of the most significant problems with non-functional properties of software engineering in specification languages is the ever-increasing complexity and broadening of their sizes. Component-based software engineering (CBSE) is observed as a chance to deal with the rising difficulty of modern-day software. The evaluation steps for software development include inception, requirements, design, construction, verification, deployment and project management. Therefore, the entire process of formal specification of non-functional properties in component software engineering is a complex process that can only be undertaken by scholarly researchers and software engineers since it involves a number of steps that are only recognized and encoded by them. Bibliography  Bechhofer Sean, 2005, OWL web ontology language reference. Retrieved from http://www.w3.org/TR/owl-ref/. Chen Zhou et al, 2004, Quality of Service Ontology. Harvard Univerisity press, print. USA. David Burdett, 2006, Collaboration-Protocol Profile and Agreement Specification. Washington D.C. retrieved from http://www.ebxml.org/specs/ebCCP.pdf. Giovanni Della-Libera et al, 2000, WS-SecurityPolicy. New York. Retrieved from http://www-106.ibm.com/developerworks/library/ws-secpol/. Heiko Ludwig et al, 2004, Web Service Level Agreements (WSLA) Project. Addison Wesley Longman, Inc. Jin, Jingwen & Nahrstedt, Klara, 2001, Specification Languages for Distributed Multimedia Appllications. Dept. of Computer Science University of Illinois at Urbana-Champaign. Available at http://cairo.cs.uiuc.edu/publications/papers/tr_qos_lang_jin.pdf  Lamanna, Dennis., 2002, SLAng: A Language for Defining Service Level Agreements. New York publication, Print. New York. Partha Pal, 2007, Using QDL to Specify QoS Aware Distributed (QuO) Application Configuration. Department of Computer Science University of Illinois at Urbana- Champaign,Urbana Xiaohui Guel, 2006, An XML-based Quality of Service Enabling Language for the Web. Rennes, France, IEEE Computer Society. Zschaler, Steffen, 2008. Formal Specification of Non-functional Properties of Component-Based Software Systems. Computing Department, Lancaster University, Lancaster, United Kingdom. Retrieved from http://www.steffen-zschaler.de/publications/sosym_phd_09.pdf Read More