Toward Component Non-functional Interoperability Analysis: A UML-based and Goal-oriented Approach

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) Provided interface Server interface definition void addClasses(Classes c) Required interface Client and server may compile but will not interoperate during run-time

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 claim softgoal naming convention = Type [Topic] Type = Security Topic = WebsiteComm AND decomposition Propagate the check labels upward operationalizing softgoal (implementation alternative) positive contribution AND decomposition Select (check) alternatives that are desirable or give better trade-off negative contribution Side-effect toward other NFRs By-product toward other NFRs

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. Step 2: Identify capability mismatches • For each compatible interface • Compare NFR softgoals (definition) • For each compatible leaf NFR softgoal • Compare operationalizing softgoals (implementation) Mark the matched softgoals with common indicators Compare the NFR softgoals and their refinement Compare only the selected implementations Identify mismatches

15. Types of non-functional mismatches 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 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 Mismatches to be resolved

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

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!