What is the best way to identify software classes

from use cases

Name:
1 Department One, Institution One, City One, Country One

E-mail: xxx@xxx.xx

Abstract
The transformation of user requirements into system requirements models can be achieved using the 4-Step Rule Set method.
This method transforms UML use case diagrams into system-level object diagrams. These diagrams represent the logical
architecture of the system . They also integrate the system-level entities, their responsibilities and relationships among them.
The logical architecture captures the system functional requirements and its non functional intentionalities. Although
contributing to the formalization of the design of software architectures, the 4SRS method needs to be extended in order to
support the design of the database subsystems that may be considered pertinent within the specified logical architecture. This
paper presents the methods of identifying software classes from use cases.

1.1 Related Work

1. Introduction
The most complex activity in the development of a software
system is the transformation of a requirements
specification(SRS) into an architectural design. The process of
designing software architectures is less formalised and often
is an intuitive ad-hoc activity based on engineering principles.
The 4-Step Rule Set also called 4SRS method employs
successive model transformations in order to obtain a logical
architecture that satisfies the previously signed off user
requirements. It is based on the mapping of UML use case
diagrams into their corresponding UML objects diagrams .
The usage of diagrammatic models and iterative nature help to
ensure that the obtained logical architecture reflects the client
requirements. Once the first logical architecture of the system
is generated, the design of class diagrams is needed for the
specification of the static characteristics of the software to be
produced. In this approach , a derivation technique is used to
obtain the class diagram, using not only the use case model
but also the logical architecture that results from the
application of the 4SRS method. Since the 4SRS method
supports a recursive approach to ensure that the system
functional requirements are present in the logical architecture
independently of the subsystem we may need to refine, the
approach proposed in this paper guarantees that the necessary
classes are able to be identified.
In SRS method the functional requirements of a software
system are captured and documented in use cases. Although
use case-driven approaches are widely used to identify system
classes, there is no proven technique for the transition from
use cases to class diagrams . In these approaches, the build
process may lead to missing classes because the use cases are
insufficient for deriving all necessary classes. The
identification of classes from the documented SRS is one of
the most important and difficult tasks during the analysis and
the design of object-oriented systems. Use cases describe
specific behaviour of the system and, therefore, the candidate
objects involved in those functionalities. In this approach, the
use cases are extracted from equirements, validated against
the functional specifications in each sentence so that classes
can be identified, and the previous use cases can be reused to
supply missing functional specifications that contain
participating classes. In this approach, ambiguity problems are
mitigated by imposing restrictions on the language that can be
used for writing requirements. The Liang method also follows
a use case-driven process in which classes are identified based
on the goals of use cases without descriptions. The proposed
approach identifies use case-entity diagrams as a vehicle for
deriving classes from use cases. Classes are identified from
use cases’ goals rather than use case descriptions. Classes are
the entities that participate in achieving the goals in the real
world. With this approach, the identification of too many
classes at one time is avoided
1.2 Synopsis
This 4SRS method derives logical architectures,
representing system requirements, from user requirements
models. It is organized mainly in the below steps to convert
use cases into system-level objects.
1. Object creation. It automatically transforms each
use case into three object types, interface, control
and data. Only objects exist as design entities from
this step. Use cases continue to be used in the next
steps allowing the introduction of the user
requirements into the object model.
2. Object elimination. For each object, it must be
decided what are the three type of objects that must
be maintained taking into consideration the whole
system . This is the most complex step of the 4SRS;
divided further in seven sub-steps.
Use case Classification: Uses cases clasified as data or
control , interface or combination of these to transform each
use case to objects.
a. Local Elimination : Identifies if each
object created makes sense to the problem
domain based on textual description.
b. Object Naming : The left over objects will
receive a name that reflects both their
corresponding use case and also the role
in the man functionality of the system.
c. Object Description: The objects are
described based on the textual description
in previous step thereby introducing
system requirements into object model.
d. Object Representation: The elimination
of redundancy in user requirements
happens at this step. It also identifies the
missing requirements.
e. Global elimination:Eliminates objects
represented by other ones
f. Object renaming: Renames the left over
objects not eliminated throughout the step.
3. Object packing and Aggregation: This step
supports the construction of a coherent object model
thereby adding an additional semantic layer at a
higher abstraction layer.
4. Object Association : This step supports the
introduction of associations in the object model
based on the information available in the use case
model . In the 4SRS terminology, this last version of
the object diagram is called raw object diagram. .
5. Class creation : This is a fully automatic step in
which a class is created for each one of the objects
present in the raw object diagram resulting from
above step . The associations among the classes are
also inherited from the raw object diagram. After the
execution of this step, the classes and the
relationships among them are dervived.
1.1.2 Discussion
Usually, object-oriented methodologies do not pay
attention to the object diagram, i.e., they are mostly class
driven. The class diagram is built firstly and only later the
object diagram is specified. The approach presented in this
paper reverses this order, in an object-driven perspective. It is
more important to have a good system level object model
(with logical architecture), because the system is composed of
objects and not by their classes. This is the main reason to first
identify the system level objects and classify them at a later
stage, that is, select the classes to which those objects belong.
The 4SRS method focuses on a model-driven development
approach, a technique that uses models during the software
development. It is executed by successively transforming
models into other refined models, until the final system design
is obtained.
REFERENCES
“Software Architectures by Recursive Model
Transformations”, Proc. of the 7th International Conference
on Product Focused Software Process Improvement -
PROFES’06. 2006. Amsterdam: Springer-Verlag. By R.J
Machado, J.M. Fernandes, P. Monteiro, and H. Rodrigues,
“Transformation of UML Models for Software
Architectures”, Proc. of the 12th IEEE International
Conference on the Engineering of Computer-Based Systems -
ECBS 2005. 2005. Maryland, U.S.A.: IEEE Computer Society
Press by R.J. Machado, J.M. Fernandes, P. Monteiro, and H.
Rodrigues,
B. Anda and D.I.K. Sjoberg, “ Role of Use Cases in the
Construction of Class Diagrams”, Empirical Software
Engineering, vol. 10, 2005, pp. 285-309.