Specifying Components with Use Cases: Analyzing Support for Behavior Assembly and Composition in UML 2.0

Designing components and composing them into an architecture inherently involves describing their behavior. The classical software engineering approach to specifying requirements for large-scale components is to start with use cases. However, employing use cases to component architectures triggers the need of (i) assembling the behavior specified by several use cases, (ii) composing the behavior of communicating entities, and (iii) reasoning on consistency of the composed behavior. Applying a modeling language, such as UML, while dealing with these issues is desirable. Based on the composite structures framework, the emerging standard UML 2.0 defines a hierarchical component model; here, behavior of components may be specified with use cases. UML 2.0 provides four behavior specification mechanisms. The key goal of this paper is to evaluate whether and how these behavior specification mechanisms address the issues above. We show that only Interactions implicitly allow for addressing all of them.

[1]  Frantisek Plasil,et al.  Behavior Protocols Capturing Errors and Updates , 2004 .

[2]  Perdita Stevens,et al.  Modelling Recursive Calls with UML State Diagrams , 2003, FASE.

[3]  Vladimir Mencl.  Specifying Component Behavior with Port State Machines , 2004, Electron. Notes Theor. Comput. Sci..

[4]  Juan Llorens Morillo,et al.  Digging into Use Case Relationships , 2002, UML.

[5]  Alan O'Callaghan,et al.  Object-Oriented Methods: Principles and Practice , 2000 .

[6]  Frantisek Plasil,et al.  Getting 'whole Picture' Behavior in a Use Case Model , 2003, Trans. SDPS.

[7]  Perdita Stevens.  On Use Cases and Their Relationships in the Unified Modelling Language , 2001, FASE.

[8]  Jeff Magee,et al.  Dynamic structure in software architectures , 1996, SIGSOFT '96.

[9]  Frantisek Plasil,et al.  Behavior Protocols for Software Components , 2002, IEEE Trans. Software Eng..

[10]  Daniel Amyot,et al.  On the Extension of UML with Use Case Maps Concepts , 2000, UML.

[11]  Craig Larman,et al.  Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process , 2001 .

[12]  Sadahiro Isoda,et al.  A Critique of UML's Definition of the Use-Case Class , 2003, UML.

[13]  Ivar Jacobson,et al.  Object-oriented software engineering - a use case driven approach , 1993, TOOLS.

[14]  Reiko Heckel,et al.  Detection of conflicting functional requirements in a use case-driven approach , 2002, Proceedings of the 24th International Conference on Software Engineering. ICSE 2002.

[15]  Martin Mach,et al.  Addressing State Explosion in Behavior Protocol Verification , 2004, SNPD.

[16]  David Harel,et al.  Statecharts: A Visual Formalism for Complex Systems , 1987, Sci. Comput. Program..

[17]  Nikolai Tillmann,et al.  Testable use cases in the Abstract State Machine Language , 2001, Proceedings Second Asia-Pacific Conference on Quality Software.

[18]  Frantisek Plasil,et al.  SOFA/DCUP: architecture for component trading and dynamic updating , 1998, Proceedings. Fourth International Conference on Configurable Distributed Systems (Cat. No.98EX159).

[19]  Rob van Glabbeek,et al.  Handbook of Process Algebra , 2001 .

[20]  Russell R. Hurlbut.  A Survey of Approaches For Describing and Formalizing Use Cases , 1998 .

[21]  Geri Schneider,et al.  Applying Use Cases: A Practical Guide , 1998 .

[22]  Albert Zündorf.  From use cases to code---rigorous software development with UML , 2001, ESEC/FSE-9.