1. Toward Component Non-functional Interoperability Analysis: A UML- based and Goal-oriented Approach Sam Supakkul and Lawrence Chung The University of Texas at Dallas ssupakkul@ieee.org, chung@utdallas.edu

2. Component interoperability: current focus Functional interoperability Syntactic interoperability e.g. interface signature compatibility Semantic interoperability e.g. the meaning of “ID” used by the client and server

3. Functional interoperability: syntactic compatibility Client interface definition void addClasses(String[] c) Server interface definition void addClasses(Classes c) Client and server may compile but will not interoperate during run-time Required interface Provided interface

4. Non-functional interoperability question  The client expects secure interface.  The server claims it provides secure interface.  Can we conclude that the security expectation is met?

5. Non-functional mismatch – different NFR definition Client does not want the communication to be seen by third parties Server wants to make sure only valid client is using the interface

6. Non-functional mismatch – different NFR implementation

7. Non-functional interoperability: definition Definition compatibility Implementation compatibility

8. Non-functional interoperability analysis issues How to represent the opposing NFRs NFR definition NFR implementation How to compare the NFRs How to resolve non-functional mismatches

9. Non-functional interoperability analysis process and techniques UML component diagram  component  interface The NFR Framework  a goal-oriented method  NFR definition  NFR implementation

10. The NFR Framework: a review NFR softgoal naming convention = Type [Topic] Type = Security Topic = WebsiteComm operationalizing softgoal (implementation alternative) AND decomposition claim softgoal positive contribution negative contribution Select (check) alternatives that are desirable or give better trade-off Side-effect toward other NFRs By-product toward other NFRs AND decomposition Propagate the check labels upward

11. Step 1: Model component capabilities Functional components interfaces Non-functional NFRs definitions implementations

12. Step 1: Model component capabilities Login interface represents the realization of the operationalizing softgoal

13. Step 2: Identify capability mismatches

14. Mark the matched softgoals with common indicators Compare only the selected implementations Identify mismatches Compare the NFR softgoals and their refinement For each compatible interface Compare NFR softgoals (definition) For each compatible leaf NFR softgoal Compare operationalizing softgoals (implementation)

15. Types of non-functional mismatches Unsupported NFR Unneeded NFR Unsupported implementation Unneeded implementation Defined only by client Defined only by server NFR definition NFR implementation

16. Step3: Resolve non-functional mismatches 3.1 Replace server components to meet client’s expected NFRs 3.2 Negotiate for more attainable NFRs to adjust client’s expected NFRs if server’s NFRs are acceptable 3.3 Use adapter components to meet client’s expected NFRs without affecting server to satisfy server imposed restrictions without affecting client

17. Tactic 1: Replace server components Consider server components that provide the same functional interoperability Compare the NFR definition and implementation as normal

18. Tactic 2: Negotiate for more attainable NFRs For unsupported definitions and implementations (expected by client) Can they be removed or postponed? Are impacts (cost, security) acceptable or mitigated? If yes, remove them from the client’s NFR goal graph For unneeded definitions and implementations (imposed by server) Are they acceptable or desirable? Are impacts (cost, usability) acceptable or mitigated? If yes, add them to the client’s NFR goal graph

19. Tactic 3: Use adapter components - strategy Mismatches to be resolved Adaptation strategy For unsupported definitions and implementations (expected by client) Adapter supports the required definitions or implementations For unneeded definitions and implementations (imposed by server) Adapter uses the imposed implementation

20. Tactic 3: Use adapter components - result Use login/password as required by the client Use fixed smartcard ID to satisfy the server The adapter satisfies both the client and server Use SSL as required by the client

21. Observation Adapter circumventing stronger security measures Some security measures are not desirable e.g. smartcard for web applications Common in practice e.g. database connection manager component Opportunities for other non-functional interoperability analysis By claims and justifications By side-effects and by-products (correlations)

22. Conclusion Contributions Explicit representation of NFRs in the UML component diagram to depict both NFR expectations and contracts A process for non-functional interoperability analysis 3 tactics for resolving non-functional mismatches Future work Non-functional semantic matching e.g. JavaSecureLib=OpenSSLLib Interoperability analysis between the system-level NFRs and the integrated components Tool support

23. Toward Component Non-functional Interoperability Analysis: A UML- based and Goal-oriented Approach Sam Supakkul and Lawrence Chung The University of Texas at Dallas ssupakkul@ieee.org, chung@utdallas.edu Thank you!