11-08-2012, 03:48 PM
Formal Specification of UML Requirement Models
Formal Specification of UML Requirement Models.pdf (Size: 100.9 KB / Downloads: 26)
Introduction
Object-orientation is now a popular approach in software industries. The Unified Modeling
Language (UML) [BRJ99,RJB99,JBR99] is the de-facto standard modeling language
for the development of software with broad application ranges, covering the early
development stages of requirement analysis and with strong support for design and implementation.
[BRJ99,DW98]. One of the main advantages of UML is that different
modeling diagrams are used at different stages to represent the system from different
views at different levels of abstraction.
The main models for the requirement analysis of a system are a conceptual model
and a use-case model. The conceptual model represents the domain concepts as classes
and their relationships as associations. It determines the possible objects and relationships
between these objects. Requirement analysis is not usually concerned very much
about what an object does or how it behaves [Lar98,DW98,Liu00]. Therefore, a conceptual
model is mainly used as a static model of the structure of the application domain.
The use-case model is used to specify the required functional services that the system
is expected to provide for different kinds of users. A use-case model contains a
number of use cases. Each use case describes a pattern of interactions between some
users and the system.
Conceptual Model
One of the main artifacts to produce in an OO analysis is a conceptual class diagram.
Such a diagram captures the physical concepts and their relations of the system’s application
domain. In UML, a concept is represented by a class with a given name. An
instance of a concept is called an object of the corresponding class. A relation between
two concepts are denoted by an association. In addition to associations between concepts,
a concept may have some properties represented by attributes. For example, Account
has a balance as an attribute and Customer has a name as an attribute. There are
two approaches to deal with attributes. The first is to introduce types of pure data values
[BRJ99] and then to represent attributes as component fields of classes. Alternatively,
these types of pure data values can be treated as classes and attributes as associations
[LHL01,LLH01]. In this paper, we follow the former approach.
We must understand that at the requirement level, a class simply represents a set
of objects. A system requirement specification is concerned with what the system does
as a whole rather than what an individual object does, how an object behaves, or how
an attribute of an object is represented. The decision on the later issues will be made
during design. A use case is designed by decomposing its responsibilities and assigning
them to appropriate objects [Lar98,Liu00]. Use case decomposition and responsibility
assignment are carried out according to the knowledge that the objects maintain3. What
an object can do depends on what it knows, though an object does not have to do all
what it can do. What an object knows is determined by its attributes and associations
with other objects. Only when the responsibilities of the objects are decided in design,
can the directions of the associations (i.e. navigation and visibility) and the methods of
the classes be determined. This indicates that an association has no direction or equivalently
two directions and a class has no methods.
Use-Case Model
Given a conceptual model CM, an object diagram represents a snapshot of the system
at a moment of time. The execution of an atomic use case will change the system from
one state into another by creating new objects, deleting old objects; forming or breaking
links between objects; or modifying attributes of objects. Such an atomic use case is
called a system operation [Lar98,Liu00]. However, the system only executes an atomic
use when it is called by an actor. Therefore, we should also model actions performed
by the actors and the interaction between the actors and the system.
Conclusion & Discussion
We have provide a model to formally combine a conceptual models and a use-cases
model of UML to form a system specification. The model is the well-know notation of
transition systems [MP81,Bac88] for general reactive systems. This is well justified as
an object-orient system is in nature a concurrent and reactive system.
The advantage of using a well-establish model is that we do not have to develop
or study new semantics and tools for verification. Methods and tool for specification
and verification of transition system are well-established, e.g. [Lam91,MP91]. Furthermore,
this model is already extended to deal with real-time and fault-tolerance
[HMP91,AL92,LJ99]. The same methods can be used to deal with real-times requirements
on use cases. Also, the model of transition systems is isomorphic to that of the
statecharts which is a part of UML.