Extensibility. As much as possible, the system should be built to adapt to varying needs, diverse audiences, changing requirements based on the users’ profile. This will be particularly important for the customizations of the software products, as one should aim at developing reusable and adaptable features rather than one-time development for a specific project. Capacity for internationalization and multi-language support are essential to the success of the solution. In this regard, the Grantee acknowledges and understands that the Fund’s intention is for the software to be deployed in various countries. The Grantee will have due regard to this goal in providing the Programme Deliverables and will, wherever possible and feasible, ensure that customization of any software is transferable and can be applied in other country contexts. In this regard, the Grantee 3 DRAFTING NOTE: Delete those which are not relevant/applicable. will continuously consult with the Fund regarding the possibility and feasibility of transferability of different functions of the customization.
Extensibility. The CFI specification supports extensibility for future device characteristics through the vendor-specific extended Query table(s). Anything not defined in the common CFI Query database is to be defined in the vendor extended tables, with the detailed structure of such tables defined by the major and minor vendor revision numbers and the associated vendor-supplied Command Set and Control Interface specification.
Extensibility. micro-ROS should be extensible with new packages the same fashion as ROS2 does. Users should be able to add new topic types.
Extensibility. A solution is easy to extend, if new types of products and new types of cus- tomers can be included without the need of modifying existing types and existing method implementations. To evaluate this criterion, we will consider the e ects of introducing a new type of product, MAINTENANCE-AGRMT, and a new type of cus- tomer, ASIAN-CUSTOMER (see: Figure 1) Ease of maintenance: A solution is easy to maintain, if a later revision of the pricing policy causes only minor and simple changes. To evaluate this criterion, we will consider the following revision of the pricing policy:
Extensibility. The solution is hard to extend. Introducing a new type of product, however, is much easier than introducing a new type of customer. To introduce a new type of product, MAINTENANCE-AGRMT, one big nested case-statement has to be added. If a new type of customer, ASIAN-CUSTOMER, is added, the new type of customer must be considered in every outer case-statement of the method \shippingCharge". In both situations, existing code has to be xxxx xx and recompiled. 1This statement is needed to resolve the con ict between the previous two ones. object type PRICE-CALCULATION properties default: Integer; methods shippingCharge(p: PRODUCT, c: CUSTOMER) returns Integer f case p isInstanceOf: HARDWARE: f case c isInstanceOf: DOMESTIC-CUSTOMER: return([p weight()]*70); EUROPEAN-CUSTOMER: return([p weight()]*300); US-CUSTOMER: return([p weight()]*700); end caseg; SOFTWARE: f case c isInstanceOf: DOMESTIC-CUSTOMER: return(default); EUROPEAN-CUSTOMER: return(150); US-CUSTOMER: return(150); end caseg; TRAINING-MATERIAL:f case c isInstanceOf: DOMESTIC-CUSTOMER: return(default); EUROPEAN-CUSTOMER: return(default); US-CUSTOMER: return(default); end caseg; end caseg;
Extensibility. The simple object-oriented solution can be hard to extend. Adding a new type of product, e.g. MAINTENANCE-AGRMT, is easy. The method \shippingChargeFor" is reimplemented at object type MAINTENANCE-AGRMT and no existing method needs to be xxxx xx. But, if a new type of customer, e.g., ASIAN-CUSTOMER, is introduced, the implementation of the method \shippingChargeFor" must be xxxx xx at every leave node of the type hierarchy of product.2 An additional label, ASIAN-CUSTOMER, must be introduced in their case-statements. Ease of maintenance: The simple object-oriented solution can be hard to maintain. It is relatively easy to consider a new default shipping for maintenance agreements. The method \shippingChargeFor" must be reimplemented at object type MAINTENANCE- AGRMT taking several labels in the case-statement into account. But it is much harder to consider a new default shipping charge which applies to all foreign customers. The implementation of the method \shippingChargeFor" has to be xxxx xx at every leave node of the type hierarchy of products. Furthermore, in each implementation several labels in the case-statement, i.e., EUROPEAN-CUSTOMER, US-CUSTOMER, and ASIAN-CUSTOMER, must be considered for possible modi cations. 2For simplicity, we assume that only leave nodes of the type hierarchy have direct instances.
Extensibility. The sophisticated object-oriented solution is relatively easy to extend. If a new type of product or a new type of customer is introduced, no existing implementa- tions of methods need to be changed. Inherited methods need to be reimplemented at subtypes, and sometimes, new methods need to be introduced. If a new type of prod- uct, e.g. MAINTENANCE-AGRMT (MA), is added, a method \MA-shippingCharge(p: MAINTENANCE-AGRMT) returns Integer" has to be introduced at object type CUS- TOMER, and the method \shippingChargeFor" of object type MAINTENANCE-AGRMT is reimplemented such that it invokes the method \MA-shippingCharge". If a new type of customer, e.g., ASIAN-CUSTOMER is introduced the methods \X-shippingCharge" (where X is a leave node in the type hierarchy of products) must be reimplemented for the case that a di erent shipping charge applies to asian customers than to foreign customers in general. 3Only some implementations of the method \HW-shippingCharge" make actually use of the input- parameter p. To design for reusability, all other methods take a product p as input parameter, although it is not really needed to implement the current pricing policy. object type HARDWARE subtypeOf PRODUCT methods weight(): Integer; shippingChargeFor(c: CUSTOMER) returns Integer freturn([c HW-shippingCharge(self)])g;
Extensibility. The cooperation contract solution is easy to extend. If a new type of product, e.g., MAINTENANCE-AGRMT, or a new type of customer, e.g., ASIAN-CUSTOMER, is added, no existing implementations of methods need to be xxxx xx and no additional types of methods need to be introduced (such as \typeOfProduct-shippingCharge" in the sophisticated object-oriented solution). Default shipping charges apply to the new product and the new type of customer immediately. Because of inheritance, direct in- stances of MAINTENANCE-AGRMT are subject to all cooperation contracts in which the supertype of MAINTENANCE-AGRMT, object type PRODUCT, is a partner type.6 Similarly, direct instances of ASIAN-CUSTOMER are subject to all cooperation con- tracts in which a direct or indirect supertype of ASIAN-CUSTOMER is partner type.7 If for a new type of product or a new type of customer special shipping charges apply, new cooperation contracts reimplementing the cooperative method \shippingCharge" are de xxx. This is a special form of maintenance and can be handled easily as it is shown in the next paragraph.
Extensibility. Later iterations of the XXX must allow more complicated use cases (for example to implement WFR.03.19 – Semantic data enrichment) and must perform the actual data publication via Push to and/or Pull from Europeana and other aggregators. While these further requirements will not be implemented at this stage it is important that they are considered in the overall architecture, design and implementation so that other parts of the system are not implemented in such a way that they prevent their implementation.
Extensibility. Vendor will provide the following future information: Pending features Frequency of updates, roadmap of future enhancements Timelines Anticipation of high availability (up time) Hardware replacement and time frames (check with Xxxx) Vendor response:
