Using TRADE to improve an Object-Oriented method - UPV

Using TRADE to improve an Object-Oriented method ∗

E. Insfr´an, †R. Wieringa, ∗O. Pastor

Abstract This paper introduces the use of the Toolkit for Requirements Engineering (TRADE) to improve OO-Method (an object-oriented method for conceptual modeling and automated code generation). TRADE is based on analysis of structured and object-oriented methods. This toolkit mainly distinguishes between external system interactions and internal components. In this work we show how external specification techniques used in TRADE can be useful to guide the internal decomposition techniques proposed in OO-Method. This will result in a full coherent specification including the external interaction and static and dynamic properties of the system under construction. In OO-Method techniques used to model the decomposition of the system are similar to those proposed by TRADE but with the semantic attached to its underlaying formal specification language (OASIS). Finally, a case study presents advantages of using this new approach showing the corresponding traceability links between external interactions and internal decomposition.

Contents 1 Introduction

2

2 TRADE 2.1 External Interaction . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 The Techniques in TRADE . . . . . . . . . . . . . . . . . . . . .

3 3 4 7

3 OO-Method 11 3.1 OASIS: an object-oriented formal model . . . . . . . . . . . . . . 11 3.2 Conceptual Modeling . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3 Execution Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 ∗ Department of Information Systems and Computation. Valencia University of Technology. Valencia, Spain. † Department of Computer Science. University of Twente. Enschede, the Netherlands

1

4 OO-Method with the TRADE approach 4.1 External Interaction . . . . . . . . . . . 4.1.1 Function Refinement Tree . . . . 4.1.2 Use cases . . . . . . . . . . . . . 4.2 Internal Decomposition . . . . . . . . . 4.2.1 Selecting problem-domain objects

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . from the Use Case model

5 Conclusions and further works

24

A Case Study: Point-of-Sale Terminal A.1 Introduction . . . . . . . . . . . . . . . A.2 External System Interactions . . . . . A.2.1 Mission statement . . . . . . . A.2.2 Function Refinement Tree . . . A.2.3 Use cases . . . . . . . . . . . . A.3 Internal Decomposition . . . . . . . . A.3.1 Searching for objects . . . . . . A.3.2 Function Decomposition Table A.3.3 Object Model . . . . . . . . . .

1

14 15 16 16 20 20

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

25 25 25 25 25 26 32 32 38 38

Introduction

A system is an assemblage of parts forming a complex or unitary whole that serves a useful purpose [Bla90]. In this wide sense, organizations, thermostats, cars and software products are examples of systems. It is crucial that the parts of a system interact in such a way that they cause the system as a whole to have a useful function for one or more entities in the environment of the system. Although the term ”system” has a wide meaning, here we restrict ourselves to systems, as a ”software products” that interacts with its environment. A system delivers a service to its environment by interacting with it. There are three relevant ways in which we can describe these interactions: functions, communications and behavior. Interactions can always be partitioned into pieces that are useful for the environment, called functions. Second, system interactions are by nature communications with one or more entities in the environment of the system. Third, the way in which functions are ordered in time is called the behavior of the system. Given a specification of external interactions it is possible to design a decomposition of the quoted system (by means of internal components) that would be optimal for this specification external properties, and that ignores the properties of underlying implementation layers. This is called essential decomposition of the software system. In this paper we introduce a software requirements engineering 1 approach 1 Software requirements engineering stands for the process to systematically decompose the high-level software requirements into a more detailed set of requirements for the software components of the system [Kot98].

2

that systematically guide analysts throughout the software life cycle. This approach provides a set of techniques and methods borrowed from TRADE to capture software requirements in terms of external interactions and a way to move these requirements into software components in a traceable and suitable way. These transition is based on rules and heuristics where the main goal centers on finding and allocating responsibilities into software components. These software components are will be specified following the OO-Method approach as we will show in next sections. This paper improves another works in the area ([Lar98], [Ben97] or [Jac92]) giving a much more structured way for capturing requirements. The use of TRADE’s techniques starting from a mission statement until obtaining a detailed specification of use cases, gives an incremental development strategy. The analyst knows at any time at what abstraction level is working on by moving in the Function Refinement Tree. The many times fuzzy task of building the use case diagrams is also reduced to pick the leaves up from the Functional Refinement Tree and specify their interactions with external entities. This avoid common problems trying to determine what is a use case and what is not. The structure of this work is the following: after this introduction, in section 2 we describe the main characteristics of TRADE and its techniques. In section 3 OO-Method main features are shown. In section 4 we present a software engineering approach. It starts with modeling the external interaction with TRADE techniques and then focus on the flowdown of functionality from the requirements into components from the conceptual model. For this flowdown four strategies are presented. Section 5 points out the conclusions and further work. We conclude with a case study on a Point-of-sale Terminal to show step by step our approach.

2

TRADE

The TRADE framework classifies the kinds of properties of software systems that a designer might want to specify. The two basic dimensions of the framework are those of external interactions and internal decomposition2 (Figure 1). Each system interacts with its external environment and is viewed as part of an aggregation hierarchy, in which higher–level systems are composed of lower– level systems. External interactions and internal decomposition are orthogonal in the sense that design decisions about these two dimensions of a system can be separated.

2.1

External Interaction

The external interactions of a system should be useful for at least some other systems in its external environment (people, hardware or software). This means that we should always be able to partition external interactions into chunks of 2 The terms ”composition” and ”decomposition” used in the paper do not refer to bottomup or top-down design processes but are used to refer to the internal structure of a system.

3

System

Interaction

Functions

Decomposition

Behavior Communication

Figure 1: A framework for systems

useful interactions that are called external functions. These chunks may be atomic from an external point of view (i.e. they are external transactions), or they may be complicated dialogs between the system and some external entities. They are not to be confused with mathematical functions or with functions written in a programming language. They are similar to Jacobson’s [Jac92] use cases: pieces of external behavior that have some use for an external agent. Of the many properties that external functions can have, two kinds are singled out: • the ordering of functions in time, called behavior, and • their ordering in “space”, called communication. Communication and behavior should be treated as orthogonal properties of functions. Communications are the way functions are ordered in space where behavior is the way functions are ordered in time. An external function is an external interaction, and each external interaction involves communication with one or more external entities. Moreover, external interactions are usually governed by rules of temporal precedence, which leads to the concept of behavior3 .

2.2

Decomposition

Taking a systems engineering view, we can represent the allocation and flowdown of external functions to components by means of a function decomposition table, also called a traceability table in systems engineering. In Figure 2, the top row lists all external functions of the system (at a certain level of refinement) and the leftmost column represents all components of the system (at a certain level of aggregation). An entry of the table represents the functions that a component must have in order to realize an external function. A column of the table represents all functions that act together to realize an external function. 3 The distinction between behavior and communication is the same as the classification of process operators in CCS into dynamic and static ones [Mil80].

4

function 1

...

function n

component 1 ... component m

Figure 2: Function Decomposition Table

This table represents the flowdown of functions to components. Objectoriented methods recognize only one kind of component: objects, which encapsulate the aspects of data stores, data processes, and control processes. This is represented by means of a Class-relationship diagram. This completes the sketch of the framework for techniques. Now, it is important to point out a number of especial features of the framework and show how it can be applied to software systems. First, observe that each component of a system is itself a system, that has an internal decomposition and interacts with other components and external entities of the system. In fact, each interaction of the entire system is realized by interactions of its components. In terms of specification techniques, this means that we can use the same technique to specify interaction of systems at different levels in the aggregation hierarchy. Next, it’s possible to specify a system’s external interactions at several levels of refinement, where higher levels of refinement correspond to more detail and less abstraction. Analysts can also specify system’s components, components of those components, etc. leading to an aggregation hierarchy. Some techniques are more suitable for partitioning components into this hierarchy. The orthogonality of external interaction and decomposition implies that interaction refinement and system decomposition are orthogonal. This is visualized in Figure 3, called the magic square by Harel and Pnueli [Har85]. Orthogonality means that decisions about interactions can be intertwined with decisions about decompositions in any way [Swa82]. There are many strategies to deal with these activities4 (top-down, bottom-up, incremental, etc.) but in whatever way this is done, the result of these decisions must be justifiable as if they were taken by means of a rational design process [Par86]. So far, it is important to remark that this framework does not refer to special properties of software systems and is therefore applicable to all kinds of design. In the case of software systems, there were added two features that will turn out to be useful to understand the use that is made of specification techniques. First, each software system interacts with its environment by exchanging symbol 4 An

explained example can be found in [Wie98].

5

Figure 3: The Magic Square

occurrences with its external entities. Now, a symbol occurrence is a physical item to which people have assigned a meaning. So for these people, it refers to part of the external world. The part of the world referred to by the external interactions of a software system is called the subject domain of the system (another term often used is Universe of Discourse). The subject domain is itself a system and may itself be under development by another design team. So the framework of Figure 1 is applicable to it. To understand how techniques are used in one method, it is important to understand what they are used for to specify the subject domain or to specify the software system. The second feature added to the framework is the identification of the essential level of aggregation in the specification of software systems. Given a specification of external functions, behavior and communications of a software system, it is possible to design a decomposition of this system that would be optimal for this specification of external properties, and that ignores the properties of underlying implementation layers. This is called the essential decomposition of the software system. The only decomposition criteria that can be used for the essential decomposition are derived from the external environment of the system, such as its external functionality, external communications, external behavior or its subject domain. The concept of essential decomposition arose with McMenamin and Palmer [McM84]. All other decomposition levels of a software system are designed by taking aspects of the underlying implementation environment into account. For example, in a distributed system, the essential decomposition must be allocated to processors in the network, and at each processor, essential components must be mapped to schedulable sequential processes. These decomposition levels are called implementation–oriented. To summarize the framework, we have a number of kinds of system properties that we can specify. The following list relates these to the function decomposition table of the system. • System functions. These are the useful pieces of behavior ordered to the environment of the system. This corresponds to items in the top row of the table. 6

• System behavior. This is the behavior of the system over time. This concerns the way in which the functions in the top row are, can or must be ordered in time. It thus concerns the entire top row. • System communication. This concerns the communication of the system with external entities in its environment. It does not correspond to an aspect of the function decomposition table of the system, but it would correspond to a column of the function decomposition table of the environment, of which the system is one component. • Essential decomposition. These are the essential components of the system, defined in terms of their meaning for the external environment. This corresponds to the items in the left-most column of the table. • Component functions. These are the useful pieces of behavior ordered by the components to their environment. Component functions correspond to entries in the table. • Component behavior. This is the way in which component functions are, can or must be ordered in time. This corresponds with a row in the function decomposition table. • Component communication. This is the way in which the components interact in order to realize the external functions. It corresponds to the columns of the function decomposition table. In each column, the component functions are listed that interact to realize the external function. There are of course other properties, often called “nonfunctional” such as security and user-friendliness, but these are not considered in this work.

2.3

The Techniques in TRADE

TRADE adopts a set of techniques (see Figure 4) that together, they cover the kind of properties that can be specified in a wide variety of structured and object-oriented methods [Wie98b]. For each dimension of the framework were chosen simple and useful techniques that can be used to represent system properties along that dimension, were ease of understanding is preferred above expressive power. This is the reason why, for example, extended Mealy machines rather than extended statecharts are chosen to represent behavior. Experience has taught that inexperienced people tend to produce unnecessarily complex models when using statecharts to represent behavior. Also, local variables gives us all the added expressive power that we need: state nesting and parallelism can be expressed by a set of communicating Mealy machines (the introduction of local variables in any STD technique allows us to avoid the complexities of data flow diagrams). Simplicity of techniques also makes it feasible to define the connections that must hold between different parts of a coherent specification in an understandable manner. Without going to details, if the techniques are used as indicated in Table 5, the links shown in Figure 6 must hold. 7

Function specification technique Mission statement

X

Function refi− nement tree

X

Event−response specification

X

Pre− postcondition specification

X

Extended mealy machine diagram

Behavior specification technique

Decomposition specification technique

X

Communication diagram Sequence diagram

Communication specification technique

X

X

X

Class diagram

X

Function Decom− position Table

X

Figure 4: The Techniques in TRADE

8

Subject domain

External system interactions

System decomposition

Component interactions

Mission statement

Mission

Function refi− nement tree

Mission refine− ment

Event−response specification

Elementary ex− ternal functions

Component functions

Pre− postcondition specification

Elementary ex− ternal functions

Component functions

Extended mealy machine dia− gram

Subject domain entity behavior

Component behavior

Communication diagram

Context diagram Use case diagram

Component interaction

Sequence diagram

External inte− raction sequen− ces

Component interaction sequences

Class diagram

Subject domain decomposition

Essential de− composition

Function decomposition table

Allocation and flowdown of functions

Figure 5: Use of techniques in TRADE

9

1 1.Mission statement 2. Function refinement tree

2 X

3

3. Event/response specification of external function

X

4. Pre−postcondition specification of external function

X

5. Context diagram 6. Use case diagram

4

5 X

X

6 X

7. Sequence diagram of external interaction

X

7 X

8

8. Class diagram of essential decomposition 9. Function decomposition table

9 X

X

10. Event/response specification of function of component

X

11. Pre−postcondition specification of function of component

X

12. Extended mealy diagram of behavior of component

X

13. Communication diagram of interactions of components

X

10 11

12

13

X

14. Sequence diagram of inte− ractions of components

X

X

Figure 6: Links between parts of a coherent specification

10

14

X

Entries of the table indicate the techniques between which there exist links. The table is symmetric around the diagonal, which is why only half of it is shown. A full explanation of the entries of the table can be found in [Wie98].

3

OO-Method

Following the OO-Method strategy [Pas97c], the software production process starts with the essential decomposition step where we have to collect the relevant system properties as components (classes and class relationships). Once we have an appropriate system description, a formal OO specification in OASIS [Pas95a] is automatically obtained. This specification is the source of a welldefined execution model which determines all the implementation-dependent features in terms of user interface, access control, service activation, etc. This execution model provides a well-structured framework that enables the building of an automatic code generator tool. It is important to note that the formal specification is hidden from the OO-Method user: the relevant system information is introduced in a graphical way, which is syntactically compliant with conventional OO models, but which is semantically designed to fill the class definition templates according to the underlying formal specification language.

3.1

OASIS: an object-oriented formal model

The OO-Method was created on the formal basis of OASIS[Pas95a], an OO formal specification language for Information Systems. In fact, we can see the OO-Method as a graphical OASIS editor, that provides the conventional approach of using object, dynamic and functional models to make designers think that they are using a conventional OO method. The formalism is in this way hidden to them, avoiding the controversial attached to the use of formalisms in software development environments. Below, we give a quick overview of the characteristics of OASIS. From an intuitive point of view, an object can be viewed as a cell or capsule with a state and a set of services. The state is hidden to other objects and can be handled only by means of services. The set of services is the object’s interface, which allows other objects to access the state. Object evolution is characterized in terms of changes of states. Events represent atomic changes of state and can be grouped into transactions . When we build a system specification, we specify classes. Classes represent a collection of objects sharing the same template. The template must allow for the declaration of an identification mechanism, the signature of the class consists of attributes and methods, and finally a set of formulae of different kinds to cover the rest of the class properties: • integrity constraints (static and dynamic) which state conditions that must be satisfied. • valuations which state how attributes are changed by event occurrences. 11

• derivations which relate some attribute’s values to others. • preconditions which determine when an event can be activated. • triggers which cause internal system activity. Finally, as an object can be defined as an observable process [Ram93], a class definition should be enriched with the specification of the process attached to the class. This process will allow us to declare possible object lives as terms whose elements are events and transactions. OASIS deals with complexity by introducing aggregation and inheritance operators. A complete description of the OASIS language can be found in [Pas95a].

3.2

Conceptual Modeling

Conceptual modeling in OO-Method collects the Information System relevant properties using three complementary models: • Object Model: a graphical model where system classes including attributes, services and relationships (aggregation and inheritance) are defined. Additionally, agent relationships are introduced to specify who can activate each class service (client/server relationship). • Dynamic Model: another graphical model to specify valid object life cycles and interobject interaction. We use two kinds of diagrams: – State Transition Diagrams to describe correct behavior by establishing valid object life cycles for every class. By valid life, we mean a right sequence of states that characterizes the correct behavior of the objects. – Object Interaction Diagram represents interobject interactions. In this diagram we define two basic interactions: triggers, which are object services that are activated in an automated way when a condition is satisfied, and global interactions, which are transactions involving services of different objects. • Functional Model: is used to capture semantics attached to any change of an object state as a consequence of the occurrence an event. We specify declaratively how every event changes the object state depending on the involved event arguments (if any) and the object’s current state. We give a clear and simple strategy for dealing with the introduction of the necessary information. This is a contribution of this method. It allows us to generate a complete OASIS specification in an automated way. More detailed information can be found in [Pas95a]. From these three models, a corresponding formal and OO OASIS specification is obtained using a well-defined translation strategy. The resultant OASIS specification acts as a complete high-level system repository, where the relevant system information, coming from the conceptual modeling step, is captured. 12

3.3

Execution Model

Once all the relevant system information has been specified, we use an execution model to accurately state the implementation-dependent features associated with the selected object society machine representation. More precisely, we have to explain the pattern to be used to implement all the system properties in a logical three-tiered architecture for any target software development environment: • interface tier: classes that implement the interaction with end users presenting a visual representation of the application and giving users a way to access and control the object’s data and services. • application tier: classes that fully implement the behavior of the business classes specified in the conceptual modeling step enforcing the semantics of our underlying object model • persistence tier: classes that provide services allowing the business objects to interact with their specified permanent object repository. In order to easily implement and animate the specified system, we state a way in which users interact with system objects. We introduce a new way of interaction, close to what we could label as an OO virtual reality, in the sense that an active object immerses in the object society as a member and interacts with the other society objects. To achieve this behavior the system has to: 1. identify the user (an access control): logging the user into the system and providing an object system view determining the set of object attributes and services that it can see or activate. 2. allow service activation: finally, after the user is connected and has a clear object system view, the users can activate any available service in their worldview. Among these services, we will have system observations (object queries) or events and transactions served by other objects. The process of access control and the building of the system view (visible classes, services and attributes to the user) are implemented in the interface tier. The information to properly configure the system view is included in the system specification obtained in the conceptual modeling step. Any service activation has two steps: build the message and execute it (if possible). In order to build the message the user has to provide information to: 1. identify the object server: The object server existence is an implicit condition for executing any service, unless we are dealing with a new event. At this point, objects from the persistence tier retrieves the object server from the object repository used (usually a relational database).

13

2. introduce event arguments: The interface tier asks for the arguments of the event being activated (if necessary). Once the message is sent, the service execution is characterized by the occurrence of the following sequence of actions in the server object (the application tier): 1. check state transition: verification in the object State Transition Diagram (STD) that a valid transition exists for the selected service in the current object state. 2. precondition satisfaction: the precondition associated with the service must hold. If 1 and 2 don’t hold, an exception will arise and the message is ignored. 3. valuation fulfillment: the induced event modifications (specified in the Functional Model) take place in the involved object state. 4. integrity constraint checking in the new state: to assure that the service execution leads the object to a valid state, the integrity constraints (static and dynamic) are verified in the final state. If constraints don’t hold, an exception will arise and the previous change of state is ignored. 5. trigger relationships test: after a valid change of state, the set of condition-action rules that represents the internal system activity is verified. If any of them hold, the specified service will be triggered. The previous steps guide the implementation of any program to assure the functional equivalence between the object system specification collected in the conceptual model and its reification in a programming environment.

4

OO-Method with the TRADE approach

In this section, we show how to use TRADE in conjunction with OO-Method. This new approach gives us very useful method for building systems. This is achieved by the fusion of good properties of TRADE to deal with external interaction modeling plus a set of rules and heuristics that guide the flowdown of functionality into class components. Analysts are guided by rules and heuristics to build a draft conceptual model (based on external interactions) that will be used as the basis for the final and complete specification of the system under development. In this section we will give a motivation and explanations for selecting the techniques considered more relevant in order to be used in a pure object-oriented method as is OO-Method. TRADE classifies the kind of properties system of software system that software engineer might want to specify. The two basic dimensions of the framework are those of external interaction and internal decomposition. The blend between 14

TRADE and OO-Method will be directed by the external interaction modeling, and this will be the entry point for conceptual modeling. To make this useful it is necessary that the interconnection between external interactions and internal decomposition (this will be done following the OO-Method approach) will be clearly stated in order to produce a sound and powerful incremental and iterative development process. There are three relevant ways in which we can describe the external interaction. Interactions can always be partitioned into functions. Second, interactions are by nature always communications with one or more entities in the environment of the system. And, third, the way in which functions are ordered in time is called the behavior of the system. Functions specifications: functions specification techniques are used to specify external functions of the system. The selected techniques in TRADE are Function Refinement Trees, Event-response Specification and Pre-post condition specification. Behavior specification: there are several techniques to specify behavioral properties. Many of these techniques are too detailed to be used for a specification of external system behavior at the higher levels of aggregation but as we specify the requirements of lower-level components, they become increasingly useful. For this reason we are not using any technique at this level. The techniques suggested in TRADE include Extended Mealy Machine diagram and Sequence diagram. Communication specification: the proposed technique is the Use Case Diagram. An important point is that the use case specification is equivalent to the Event-response specification. An important goal that we follow in this work is not only to choose suitable techniques (within those proposed in TRADE) but also to specify requirements in a coherent and completed way. For these reasons we also want to have traceable rules and heuristics to make the best interconnection between those techniques. Selected techniques to be used in this work include: • Function refinement tree, to deal with external interaction partitioning. • Use Case model. This includes the Use Case Specification to specify the external interactions and the Use Case Diagram to show communication. Note that we do not include explicitly behavior specification because it is too detailed to be used for a specification of external system behavior at higher levels (however we will show later how sequence diagrams could be used).

4.1

External Interaction

In next paragraphs we present each one of the techniques used in the external interaction and the rules and heuristics detected to make a traceable and complete the specification .

15

4.1.1

Function Refinement Tree

External interactions always can be partitioned in functions. It is very useful (for analysts and users) to organize these functions in a refinement hierarchy such that the root of the hierarchy is the overall system function (the mission statement), and the leaves are the elementary functions. The intermediate nodes are groups of elementary functions and usually represent a kind of activity or a business area where the system is under development. It is not a trivial task to distinguish between intermediate and leaves nodes for the function refinement tree. Some analysts tend to specify only groups of hidden elementary functions as leaves, that is an underspecification of functions. Other analysts tend to introduce too detailed functionality (steps to realize a function), that is an overspecification of functions. We will use the TRADE conception of function, as is mentioned in [Wie98]: ”...a function is regard as elementary if it is triggered by an event sent by an user of the system (actor) or by an internal component”. In this way, we follow the Information Engineering approach where the function refinement tree is used to represent a hierarchical decomposition of business functions of an organization independently from the actual organization structure. The resultant tree is merely an organization of external functions and does not say anything about internal decomposition of the system. An example of the function refinement tree is shown in Figure 7 in the POST case study in the appendix A. 4.1.2

Use cases

Use cases have been introduced in OOSE [Jac92] to represent external system functionality and have been adopted since then by several other methods and notations. A use case is an interaction between the system and an external entity that has a use for that external functionality. The interaction needs not to be atomic. Use cases can be described by a narrative text (use case specification), or more formally by a specification of pre-postconditions of the use case. An overview of the uses cases can be given by a Use Case Diagram, which shows for each use case which external entities are involved in it. Because we are combining use case specifications with the function refinement tree, each one of the use case specifications will correspond to one node of the function refinement tree, specifically we will create a use case specification for each one of to the leaves. The Figure 2 presented in chapter 2, represents the flowdown of functions to components (in our case components are classes that represent elements from the problem domain). This flowdown is done assigning each use case specification to an specific class (the class who has the responsibility to realize that functionality). Depending on the complexity of the use case it may also correspond to a service (or services) offered by a class (an event or transaction5 ). 5 In

OO-Method a transaction is a molecular process unit composed of atomic events or

16

This is a responsibility assignment activity and is a fundamental step to realize the conceptual decomposition of the problem under development in a traceable way. Finally, it is important to remark that there are many ways to capture and model external interactions of a system. We have proposed two techniques from TRADE: function refinement tree and use cases, in such a way that the final result of the former is the input for the later. In this context, we want to point out that use cases are widely used by analysts in brainstorming sessions with users and while reviewing existing requirement documents. In this case, analysts tend to identify only use cases with their relationships with actors, in a first stage. Further refinements will lead us to complete use case specifications. One method used to identify use cases is actor-based. Using this method, first we identify actors related to the system under development or organization. Second, for each actor, identify the processes they initiate or participate in. Another method to identify Uses Cases is event-based. In this case, first we identify external events that the system under development must respond to, and second, we relate the events to actors and use cases. Note that our proposal is similar to the event-based use case model construction but with two important differences: first, with the function refinement tree external interactions are partitioned and organized in a refinement hierarchy, and second, we abstract the system’s actors until a second step of the iterative process is reached (the use case modeling). At this moment (in our point of view) analysts have a clearer view of the system external functionality and would be easier to them to model the message flow between actors and use cases . In the following paragraphs we define the use case specification structure to be used in our approach. Use Case specification structure The top section (summary) of the use case specification is a summary information. This gives information about: 1. the use case name, 2. participating actors (external agents) indicating who initiates the use case (we put a star after the name), 3. cross reference with a leaf node of the function refinement tree (this is an important link between these techniques for traceability), 4. an overview of the use case purpose. another transactions.

17

Use case: Actors: Cross reference: Description: Steps or transactions 1. This use case begins when... 2. xx Alternative Line 2: if ...



The middle section (typical steps) contains the steps or transactions that occur during the use case. The transactions should cover all the steps of the use case from the triggering event through to the accomplishment of the goal. They are numbered paragraphs. The final section (alternative), describes important alternatives or exceptions that may arise respect to the typical course of events described in the middle section (typical steps section). They refer to a specific number in the middle section where the exception may arise. In practice, use cases may be expressed with varying degrees of detail. A basic (and common) division is: • High-level: describes an external function very briefly, usually in two or more sentences (only includes the summary section) [Jac92], [Lar98]. It is often used during the initial requirements and project scoping in such a way analysts could quickly understand the degree of complexity and functionality of the system. • Expanded: describes the process in more detail including the typical steps and alternatives section [Jac92], [Wir90], [Con97]. During first iterations in the requirements phase, it is useful to write the most important and influential use cases in the expanded format, but less important ones can be deferred until the development cycle starts the Conceptual Model construction. Managing complexity Complexity is inherent to medium-large size projects. Use cases (graphically represented as Use Case Diagram or textually in a specification) are flat artifacts (they don’t have nested use cases). For dealing with complexity, there may be refinement relations between use case specifications, as is described in [Jac92], [Boo97], or we can create subsections inside the textual specification. A use case may contain decision points. If one of these decision paths represents the overwhelming typical case, and the other alternatives are rare, unusual or exceptional, then that typical case should be the only one written about in the middle section, and the alternatives should be written in the alternative section (final section). 18

However, sometimes the decision points represents alternatives that are all relatively equal and normal in their likelihood. In this case in the typical steps section indicate the branches to subsections and write a subsection for each branch, starting in the typical steps section and the event numbering in one for each section. Of course, each section can have again alternative sections and subsections following the same schema. Usually an actor, which his (or her) first-occurrence is in these subsections, is explicitly cited in the top section of the use case specification. When the alternatives get complex may be expanded into their own use cases, and in this case we have to relate these use cases. But the question is: when should a major step or branching activity in a use case be written as a subsection branch or as a discrete use case? To answer this question two guidelines are proposed: • When they are duplicated in other use cases • When they are complex and long, and separating them helps factor the use case into manageable comprehensible units. Useful relationships for structuring use cases are: • Uses: which allows one use case to be defined in terms of another. Thus raising the abstraction level. This is like a procedure call, thus a use case may be used by many different use cases, • Extends: which allows variants of a simple or ideal use case to be defined by specifying the change delta. Thus permits the incremental description of complex use cases. ”A extends B” means the use case that is obtained by modifying B by the ”change delta” A. In a use case model diagram ”A extends B” denotes two use cases, viz. B and B modified by A. Note that the A is not fully fledged use case and may not appear in its own right. In particular ”A” has to stay whereabouts in ”B” it is to be inserted. • Include: this relationship can for simplicity be thought of as a reversed extend relationship that provides explicit and unconditioned extensions to a use case. Moreover, when including a use case, the behavior sequence and attributes of the included use case are encapsulated and cannot be changed or accessed -only the result of the included use case can be exploited (this is a difference as compared to using the uses relationship). Note: in some cases would be useful to illustrate a use case specification by an scenario diagram (showing the behavior). A scenario conventionally shows a use case instance not a class, and represents the flow of events between agents and the system. The value of scenario diagrams is that it is intuitive and thus is good for showing to customers. The disadvantage is that the scenario may prematurely make decisions that are better to left later. That is the reason because it was not explicitly included in this work, but could be used as an explanatory added document for use case specifications. 19

4.2

Internal Decomposition

Taking a systems engineering view, we can represent the allocation and flowdown of external functions to classes by means of a function decomposition table, also called traceability table in systems engineering [Dav93], [DSMC90]. It was showed in Figure 2. In this table, the top row lists all external functions of the system and the leftmost column represents all classes of the system. An object-oriented conceptual model partitions (decompose) problem domain space into meaningful technology-neutral concepts called classes. In OOMethod these classes are specified in three different but complementary models: Object Model, Dynamic Model and Functional Model. The Object Model is the heart of the conceptual model, and the place where the classes are identified and where their static properties stated. This model also aids in clarifying the terminology or vocabulary of the problem domain. It can be view as a model that communicates (to interested parties such as developers and users) what the important terms are, and how they are related. One of the early major activities within a development cycle is the creation of an Object Model based on use cases identified in the current cycle. Its creation is dependent on having well specified use cases from which objects can be identified. There are several proposed strategies to identify these concepts exploring the problem domain [Abb83], [Coa97], [Lar98]. In this work we point out some rules and heuristics to find out these concept objects and how to assign them responsibilities based on the external interactions modeled. 4.2.1

Selecting problem-domain objects from the Use Case model

In this subsection we will stated some rules and heuristics to build an Object Model exploring the previously built use case model. The use case model will be the source to explore for problem-domain objects. We will apply four strategies6 to look for problem-domain objects and to assign responsibilities to these objects, analyzing use case specifications. These strategies focus on: • actors • things – transactions as things – tangible things – descriptive things • places • responsibility assignment 6 In [Coa97] three strategies were proposed to guide interviews with the domain expert to find objects. Here we propose four strategies to look for objects but inside a Use Case model in a innovative way.

20

Looking for actors The use case’s actors are listed in the use case specification summary section. We have to analyze how each actor participate in ways that might be of interest to the system under consideration. Actors which initiate a use case are potentially objects7 to be taking into account for the object model. They could be actors for services offered by classes (agents relationship8 in OO-Method). But this is not always true, often use case actors represent entities (people, organizations, systems,...) that exist in the real world but not in the computational system that we are modeling. For example, the actor Customer from our Point-of-Sale case study. A Customer initiates the Sale Items use case (in the problem domain) however inside the computational system9 the Cashier is responsible to initiate this process. From our case study the list of actors is the following: Customer* Cashier Supervisor cashier* Supplier Accounts Receivable/ToPay System • Customer: this actor initiates some use cases (Sale items,...), however in this problem domain modeling is not considered because participates anonymously in the system. We are not aware of Customer’s personal information. • Cashier: this actor doesn’t initiate any use case, however in this problem domain modeling he (or she) will be responsible to initiate services offered by the system (Cashiers will be system users). Also, we have to maintain information on Cashiers (name, address, etc.). We must include Cashier as an object in our Object Model. • Supervisor Cashier: this actor initiates several use cases (Create item,...) and also he (or she) will be responsible to initiate services offered by the system (Supervisor Cashiers will be system users). We must include Supervisor cashier as an object in our Object Model. • Supplier: this actor doesn’t initiate any use case, they are only real-world anonymous participants (provides information to the system). We are not aware of Supplier’s information in this case study. • Accounts Receivable/ToPay System: this actor doesn’t initiate any use case. This is another system inside the organization that we have to 7 We have to remember that with OO-Method we construct conceptual models to represent object societies. In this context actors are society members that communicate with others to accomplish specific activities. 8 In OO-Method we model objects with two perspectives: client or actor, when they request services to the society; and server, when they offer services to the society. 9 In this case study every Customer comes into the store, participates anonymously, and leaves again. Another problem domain could maintain information on Customers for a better service. For example, the store could issue cards with machine-readable codes. The cashier (or even the shopper) could run the card through a scanner and starts a Sale operation.

21

communicate with10 . We have not to include this system as an object in our Object Model. Looking for things Another possibility to find problem-domain objects is to look for things. At this point we have three possibilities: • Transactions as things A transaction, in a business or commercial context, is a recording or logging of any event of significance. A ”transaction object” knows about a significant event, knows who the players are in that event, and calculates things pertaining to that event. A transaction is a moment in time (for example, a sale) or an interval of time (for example, a rental). Nearly all transactions additionally consist of a number of transaction line items. In [Jac92] a use case is defined as ”...a narrative document that describes a sequence of events of an actor (an external agent) using a system to complete a process”. Following this definition a use case by itself may represent a transaction. For example, the use case Sale items is a description of a sequence of events to complete a process (the sale of items) and we have to record this occurrence. We must include this use case as an object in our Object Model. The use case Return purchased items is another one with same characteristics and should be considered as a transaction object. The other use cases (Create item, Maintain item price,...) are not considered as ”transaction object”. They look like services offered by a class (we have to assign them as a responsibility of an appropriate class) but we will see this in the next section. Another possibility is to find transactions inside a use case specification. We have to analyze each one of the steps in the typical steps section of the specification. This usually happens when we find subsections (or when we create explicitly a use case for a Subsection). For example, in the Sale items use case we have three subsections (Pay by cash, Pay by credit and Pay by check ). Each one of these subsections is an embedded transaction (a significant event) inside a greater transaction Sale (previously detected). Note that these embedded transactions (or any of them) can be: ”transaction objects” or services offered by a class (we have to assign them as a responsibility of an appropriate class) but we will see this in the next section. 10 Communication

between systems we won’t cover in this work. Previous not published works dealed with that problem. Technological solutions mainly focus in two approaches: giving a system access privileges to retrieve information from the other system’s database or communicating processes between the involved systems.

22

• Tangible things Look for tangible objects, ones used in the problem domain. Exploring use case specifications we find things like: items, register, cash drawer,... The analyst has to decide if they are inside or outside of the system scope. • Descriptive things Look for descriptive objects with values that apply to some number of specific items and actions that apply across those specific items. Typical examples are: tax tables (a tax category item and the specific item), price tables (a price category item and the specific item), item description (an item description and the items),... Looking for places Look for places where things come to rest, places that contain other objects. For example a store, a library or a shelf. The store is a container of many things, including cashiers, registers and items for sale. They would be candidate objects. The analyst should determine if they are inside or outside of the system scope. Responsibility assignment for problem-domain objects Every object in an object model has specific responsibilities. An object does things by itself or in collaboration with others. In a typical steps section of a Use case specification (and in its subsections, if any) we document all the steps to achieve a process. Our task at this point is to attach to a class or to a set of related classes responsibilities derived from the use case specification. These responsibilities (in OO-Method terminology) could be events (atomic execution units) or transactions (molecular execution units). A use case specification describes a sequence of (ordered) actions. The use case can be by itself an object (when represents a business transaction which must be recorded) or in other cases it represents a set of responsibilities (maybe one per step in the specification) that must be allocated into the corresponding objects. The process starts ”walking through” the use case specification (step by step) identifying the corresponding responsibility (induced by the step) and assigning it to an appropriate object class. Not every step in the use case specification is an event or an object. Some of them are very important to give the reader the context where the use case occurs but they have no representation in the conceptual model (for example the first step in the use case Sale items: ”This use case begins when a Customer arrives at a POST checkout with items to purchase”). Another steps are useful to determine what kind of computations or user interfaces are necessary (”The System calculates and presents the sale total”). The later is a subject for further works. Finally, the alternative section in the use case specification represents alternative or exceptional course of events. These could correspond to integrity 23

constraints (for example, if Customer doesn’t have sufficient cash. Cancel sale!) or control conditions for evaluations or a trigger specification (an event that must be activated if a condition holds).

5

Conclusions and further works

We have presented an approach for software development based in two proposals TRADE and OO-Method. This approach is based on fusioning good properties of TRADE to deal with external interaction modeling plus a set of strategies that guide the flowdown of functionality into class components. At this point we use the OO-Method approach to finish the conceptual model refinement and to build the application. A complete example can be found in appendix A. We believe the work in this approach is an important advance enhancing traceability from requirements through to code. Further works are oriented to capture more information at the requirements level in order have a more accurate conceptual model. Some information related to class relationships (inheritance and aggregation) and user interfaces could also be extracted.

24

A

Case Study: Point-of-Sale Terminal

A.1

Introduction

This case study is about a point-of-sale terminal (POST) system11 . A point-ofsale terminal is a computerized system used to record sales and handle payments; it is typically used in a retail store. It includes hardware components such us a computer and bar code scanner, and software to run the system.

A.2

External System Interactions

The three relevant aspects of external system interactions are external functions, communication and behavior. External interactions are partitioned into useful portions called functions. Functions can be partitioned in a refinement hierarchy such that the root of the hierarchy is the overall system function (the mission statement), and the leaves are the elementary functions. A.2.1

Mission statement

The purpose of this project is to create a software system to record sales and handle payments in a retail store. A.2.2

Function Refinement Tree

The following system functions for the point-of-sale terminal application are identified. They are structured in three main areas according to the problemdomain functionality. We give a graphical and a textual notation for system functions.

Point-of-sale Functions 1. Sales (a) Sale items (b) Return purchased items 2. Items (a) Create item (based on UPC-Universal Product Code) (b) Maintain item price (c) Maintain item stock 3. Management 11 This

is a problem also explored in [Lar98] and [Coa97].

25

POST System

Management Sales

Sale items F1.a

Return purchased items F1.b Items Create item F2.a

Create Create cashier supervisor cashier F3.a F3.c Maintain Maintain supervisor cashier info cashier info F3.b F3.d Maintain item price F2.b

Maintain item stock F2.c

Figure 7: Function Refinement Tree

(a) Create cashier (assigning an ID and password) (b) Maintain cashier information (c) Create supervisor cashier (assigning an ID and password) (d) Maintain supervisor cashier information

A.2.3

Use cases

The following Use Cases represent nodes of the function refinement tree. We create a Use Case specification for each leaf in the corresponding tree.

Use Case descriptions Use case:

Sale items Customer*, Cashier, Actors: Accounts Receivable/ToPay System Cross Reference: F1.a Description: A Customer arrives at a checkout with items to purchase. The Cashier records the purchase items and collects payment. On completation, the Customer leaves with the items. Steps or transactions 1. This Use Case begins when a Customer arrives at a POST checkout with items to purchase. 2. The Cashier records the identifier of each item. 3. The System determines the item price and description and adds information to the current sales transaction. 4. On completation of item entry, the Cashier indicates to the POST that item entry is complete. 26

5. The System calculates and presents the sale total. 6. The Cashier tells the customer the total. 7. The Customer chooses payment type: (a) If cash payment, see section Pay by Cash (b) If credit payment, see section Pay by Credit (c) If check payment, see section Pay by Check 8. The System logs the completed sale. 9. The System prints a receipt. 10. The Cashier gives the receipt to the Customer. 11. The Customer leaves with the items purchased. Alternative • Line 2. If there is more than one of the same item, the Cashier can enter the quantity as well. The subtotal of these items is shown. • Line 2. Invalid identifier entered. Indicate error. • Line 7. Customer didn’t have enough money. Cancel sales transaction.

Section: Pay by Cash Steps or transactions 1. The Customer gives a cash payment - the ”cash tendered” - possibly greater than the sale total. 2. The Cashier records the cash tendered. 3. The System shows the balance due back to Customer. 4. The Cashier deposits the cash received and extracts the balance owning. The Cashier gives the balance owning to the Customer. Alternative • Line 4. Insufficient cash in drawer to pay balance. Ask for cash from Supervisor Cashier, or ask Customer for a payment closer to sale total.

Section: Pay by Credit Steps or transactions 1. The Customer communicates their credit information for the credit payment. 27

2. The System generates a credit payment request and sends it to an external Credit Authorization Service (CAS). 3. Credit Authorization Service authorizes the payment. 4. The System receives a credit approval reply from the Credit Authorization Service . 5. The System posts (records) the credit payment and approval reply information to the Accounts Receivable/ToPay System. (The CAS owes money to the Store, hence A/R must track it). 6. The System displays authorization success message. Alternative • Line 3. Credit request denied by Credit Authorization Service. Suggest a different payment method.

Section: Pay by Check Steps or transactions 1. The Customer writes a check and identifies itself. 2. The Cashier records identification information and request check payment authorization. 3. The System generates a check payment request and sends it to an external Check Authorization Service. 4. The Check Authorization Service authorizes the payment. 5. The System receives a check approval reply from the Credit Authorization Service . 6. The System displays authorization success message. Alternative • Line 4. Check request denied by Check Authorization Service. Suggest different payment method. ======================================= Use case: Return purchased items Actors: Customer*, Cashier Cross Reference: F1.b Description: A Customer arrives at a checkout with purchased items to return. The Cashier records the returned items. On completation, the Cashier refunds the Customer the total money. Steps or transactions 28

1. This Use Case begins when a Customer arrives at a POST checkout with items to return. 2. The Cashier records the identifier of each item. 3. The System determines the item price and description and adds information to the current return transaction. 4. On completation of item entry, the Cashier indicates to the POST that item entry is complete. 5. The System calculates and presents the refund total. 6. The Cashier gives the customer the money back. 7. The System logs the completed return. Alternative • Line 2. If there is more than one of the same item, the Cashier can enter the quantity as well. The subtotal of these items is shown. • Line 2. Invalid identifier entered. Indicate error. • Line 6. Insufficient cash in drawer to pay total. Ask for cash from Supervisor Cashier. ======================================= Use case: Create item Actors: Supervisor Cashier* Cross Reference: F2.a Description: The Supervisor Cashier creates the information about a new item in the store. Steps or transactions 1. This Use Case begins when the Supervisor Cashier introduces new items in the Store. 2. The Supervisor Cashier creates a record for of each new item. 3. The Supervisor Cashier assigns the item a Universal Code Product (UPC) for identification, a sale prince and initial stock. 4. The System registers the new item. ======================================= Use case: Maintain item price Actors: Supervisor Cashier* Cross Reference: F2.b Description: The Supervisor Cashier updates the item price. Steps or transactions 29

1. This Use Case begins when the Supervisor Cashier will update an item price in the store. 2. The Supervisor Cashier selects an item introducing the identification from a bar code scanner, or manual entry. 3. The Supervisor Cashier introduces the item price. 4. The System updates the item information. Alternative • Line 2. Invalid identifier entered. Indicate error. ======================================= Use case: Maintain item stock Supervisor Cashier*, Supplier, Actors: Accounts Receivable/ToPay System Cross Reference: F2.c Description: The Supervisor Cashier receives items from a Supplier and updates the stock of the item. Steps or transactions 1. This Use Case begins when the Supervisor Cashier will update the stock of an item in the store. 2. The Supervisor Cashier selects an item introducing the identification from a bar code scanner, or manual entry. 3. The Supervisor Cashier receives from the Supplier the items with the corresponding invoice. 4. The Supervisor Cashier posts (records) the invoice information to the Accounts Receivable/ToPay System 5. The Supervisor Cashier introduces the number to increment the item stock. 6. The System updates the item information. 7. The Supervisor Cashier puts the new items in their corresponding shelf. Alternative • Line 2. Invalid identifier entered. Indicate error. • Line 3 and 4. If the Supervisor Cashier does this process because of an inventory control these steps are ignored. • Line 5. If the Supervisor Cashier does this process because of an inventory control the quantity introduced is the new stock. 30

======================================= Use case: Create cashier Actors: Supervisor Cashier* Cross Reference: F3.a Description: The Supervisor Cashier creates a new Cashier for the Store. Steps or transactions 1. This Use Case begins when the Supervisor Cashier will create a new Cashier in the store. 2. The Supervisor Cashier creates a record for the new Cashier with his (her) personal information. 3. The Supervisor Cashier assigns the Cashier an ID and password to log in the System. 4. The System registers the new Cashier. ======================================= Use case: Maintain cashier Actors: Supervisor Cashier* Cross Reference: F3.b Description: The Supervisor Cashier updates a Cashier information. Steps or transactions 1. This Use Case begins when the Supervisor Cashier wants to update a Cashier information. 2. The Supervisor Cashier selects a Cashier introducing a Cashier ID. 3. The Supervisor Cashier introduces the new Cashier information. 4. The System updates the Cashier information. Alternative • Line 2. Invalid Cashier ID entered. Indicate error. ======================================= Use case: Actors: Cross Reference: Description:

Create Supervisor Cashier Supervisor Cashier* F3.c The Supervisor Cashier creates a new Supervisor Cashier for the Store. Steps or transactions 1. This Use Case begins when a Supervisor Cashier will create a new Supervisor Cashier in the store. 31

2. The Supervisor Cashier creates a record for the new Supervisor Cashier with his (her) personal information. 3. The Supervisor Cashier assigns the Cashier an ID and password to log in the System. 4. The System registers the new Supervisor Cashier. ======================================= Use case: Maintain Supervisor Cashier Actors: Supervisor Cashier* Cross Reference: F3.d Description: The Supervisor Cashier updates a Cashier information. Steps or transactions 1. This Use Case begins when the Supervisor Cashier wants to update the Cashier information. 2. The Supervisor Cashier selects a Supervisor Cashier introducing a Supervisor Cashier ID. 3. The Supervisor Cashier introduces the new Supervisor Cashier information. 4. The System updates the Supervisor Cashier information. Alternative • Line 2. Invalid Supervisor Cashier ID entered. Indicate error.

Use Case Diagram The Use Case diagram is a graphical way to show the communication between the system and the external entities (actors). In Figure 8 we show all the use cases from the POST System and their corresponding relationships between their actors.

Use Case Diagram with uses relationships The processes related to different forms of payments in the POST System may be expressed as separate use cases and related to others. The Figure 9 shows these additional use cases, and their relationships. This is an alternative way to structure requirements to obtain more modularity, and usually this splitting of use cases is done when you finish the requirements gathering. In this way these use cases can be used in other use cases for example: Exchange items or Buy Items from Supplier.

A.3 A.3.1

Internal Decomposition Searching for objects

At this subsection we have to apply systematically the strategies to find out the objects inside the use case specifications. 32

Figure 8: Use Case Diagram for the POST System.

33

Figure 9: Use Case diagram with uses relationships

Applying strategy #1: Looking for actors of actors is the following: Customer* Cashier Supervisor cashier* Supplier Accounts Receivable/ToPay System

From our case study the list

• Customer: this Use Case actor initiates some Use Cases (Sale items,...), however in this problem domain modeling is not considered because participates anonymously in the system. We are not aware of Customer’s personal information. • Cashier: this Use Case actor doesn’t initiate any Use Case, however in this problem domain modeling he (or she) will be responsible to initiate services offered by the system (Cashiers will be system users). Also, we have to maintain information on Cashiers (name, address, etc.). We must include Cashier as an object in our Object Model. • Supervisor Cashier: this Use Case actor initiates several Use Cases (Create item,...) and also he (or she) will be responsible to initiate services offered by the system (Supervisor Cashiers will be system users). We must include Supervisor cashier as an object in our Object Model.

34

• Supplier: this Use Case actor doesn’t initiates any Use Case, they are only real-world anonymous participants (provides information to the system). We are not aware of Supplier’s information in this case study. • Accounts Receivable/ToPay System: this Use Case actor doesn’t initiates any Use Case. This is another system inside the organization that we have to communicate with12 . We have not to include this system as an object in our Object Model. Applying strategy #2: Looking for things We have three possibilities looking for things: transactions as things, tangible or descriptive things. Looking for transactions as things we examine each use case as a possible ”thing” (or object) to record information about it. • Sale items is a description of a sequence of events to complete a process (the sale of items). This is a moment in time, something that happens in the world and about the system has to be record information (items, prices, etc.). We must include this Use Case as an object in our Object Model (class Sale). • Return purchased items. It is also a description of a sequence of events to complete a process (the returning of items). This is a moment in time, something that happens in the world and about the system has to be record information (items, prices, etc.). We must include this Use Case as an object in our Object Model (class Return). • Create item, Create cashier and Create supervisor cashier are not considered as ”transaction objects”. Although every time we use these use cases we have to record new information, they look like creation services offered by a class (we have to assign them as a responsibility of an appropriate class - strategy number 4). • Maintain item price, Maintain item stock, Maintain cashier and Maintain supervisor cashier are not transactions objects neither. They only update some state of the system. When we are looking for transactions objects it’s not enough to consider each one of the use cases as a candidate object class. It’s possible to find transactions objects inside a use case specification. This usually happens when we have subsections (or generalization relationships). Each one of these subsections is an embedded transaction (a significant event) inside a greater transaction Sale (previously detected). For this reason we have to manage them (when we are looking for objects) as different use cases (they can be ”transaction objects” or services offered by a class). 12 Communication between systems we won’t cover in this work. Previous not published works deal with that problem. Technological solutions mainly focus in two approaches: giving a system access privileges to retrieve information from the other system’s database or communicating processes between the involved systems.

35

In this case study the only use case specification with subsections is Sale Item and they are: Pay by cash, Pay by credit and Pay by check. They look like creation services offered by a class (we have to assign them as a responsibility of an appropriate class - strategy number 4). Looking for tangible things we examine inside each use case specification. The goal of this process is to find Subject Domain Entities that are relevant for the system. The candidate tangible things are: items, register, cash drawer, etc. The analyst has to decide from this list which ”things” are the relevant ones for the system. In this case study we don’t find relevant things to record information about their properties (we won’t store the properties of each item, only general information about them: price, quantities, etc.). Looking for descriptive things we also examine inside each use case specification. We search for objects with values that apply to some number of specific items and actions that apply across those specific items. In this case study we find the Item Description (named just Item for the conceptual model) because we store general information about each kind of items13 . Applying strategy #3 Looking for places we examine inside each use case specification. We look for places where things come to rest, places that contain other objects. Exploring our use case specifications we find two places: store and shelf. The store is a container of many things, including cashiers, registers and shelves. A shelf is a container of items for sale. In this case study we don’t include these candidate objects in the conceptual model. Applying strategy #4 We have to read the use case specification (step by step) identifying the corresponding responsibility (induced by the step) and assigning it to an appropriate object class. The analysis of uses cases is: • Sale Items Step 2: The Cashier records the identifier of each item. It’s necessary to register information about each sold item. This step corresponds to an object creation to manage this information. We call this object class SaleLineItem. An special treatment it’s necessary for subsections. We have three subsections: Pay by cash, Pay by credit and Pay by check. Each one of these subsections is an embedded transaction (a significant event) inside the greater transaction Sale. These embedded transactions can be: ”transaction objects” or services offered by a class. 13 If we store information about each one of the items and also a description for each kind of items (for example price and quantity) we would have a descriptive thing (the item description) and a tangible thing (the item).

36

We consider them as transactions objects because we want to store new information about each time one of them occurs (if their occurrence only modify the state of the system they should be services of some object). We call these object classes: PayCash, PayCredit and PayCheck. The reader has to note that the external functionality is the Sale creation (with the Cashier as actor) and not the Payment creation. This embedded functionality only will be viewed to their defined actors during the Sale creation transaction (Sale Items). Note that sections by itself are (embedded) uses cases and must be analyzed searching for objects and responsibilities too. In this case all of them describe the payment behavior an have no additional services or objects. • Return purchased item This use case was previously considered as a transaction object an has no additional responsibilities. • Step 2: The Cashier records the identifier of each item. It’s necessary to register information about each returned item. This step corresponds to an object creation to manage this information. We call this object class ReturnLineItem. • Create item Every time we use this use case we have to record new information about an item. This is a should be the creation service offered by a class Item. • Maintain item price This use case represents a change of state of an Item. This behavior should be provided by the class Item thus we create a service named maintain price. • Maintain item stock This use case represents a change of state of an Item. This behavior should be provided by the class Item thus we create a service named maintain stock. • Create cashier Every time we use this use case we have to record new information about a cashier. This is a should be the creation service offered by a class Cashier. • Maintain cashier This use case represents a change of state of a Cashier. This behavior should be provided by the class Cashier thus we create a service named maintain cashier.

37

• Create supervisor cashier Every time we use this use case we have to record new information about a supervisor cashier. This is a should be the creation service offered by a class SupervisorCashier. • Maintain supervisor cashier This use case represents a change of state of a SupervisorCashier. This behavior should be provided by the class SupervisorCashier thus we create a service named maintain supervisorcashier. A.3.2

Function Decomposition Table

In the Function Decomposition Table we represent the flowdown of functions into components. We start building the Function Decomposition Table with the top row. In this row we add a column for each use case from the use case model. The leftmost column represents identified software components during the internal decomposition process. An entry of the table represents an external function that a class is responsible to realize. A column of the table represents all the classes that act together to realize an external function (only as a server not as an actor). And a row represents all the external functionalities in which the class participate or collaborate. This Function Decomposition Table is also called Traceability Table and is shown in Figure 10. A.3.3

Object Model

We create the Object Model using the information obtained from the Function Decomposition Table. In Figure 11 we show the result of the first step. This step consists on creating a class diagram with as many classes as are shown in the Function Decomposition Table. Building an object model is an iterative and incremental process. In Figure ?? we have added aggregation and inheritance relationships between the identified classes. A refined version of the object model is shown in Figure 13. At this level we have made a better classification of the payment methods and restructuring the employee hierarchy.

References [Abb83]

Abbott R. Program design by informal english descriptions. Communications of the ACM, 26(11), 1983.

[Ben97]

Bennet D. Designing Hard Software: The essential tasks. Manning Publications, 1997.

[Bla90]

Blanchard B. and Fabrycky W. Systems Engineering and Analysis. Prentice Hall, 1990. 38

Sale Items

Return purcha− sed items

Create item

Maintain item price

Maintain item stock

Item

X

X

X

X

X

Sale

X

SaleLine Item

X

Pay by cash

X

Pay by check

X

Pay by credit

X

Cashier Return

X

Return LineItem

X

Superv. cashier

Create cashier

Maintain cashier

X

X

Create superv. cashier

Maintain superv. cashier

X

X

Figure 10: Function Decomposition Table for the POST System

[Boo97]

Booch G., Rumbaugh J., and Jacobson I. UML v1.1. Technical report, Rational Software Co., 1997.

[Coa97]

Coad P., North D., and Mayfield M. Object Models: Strategies, Patterns and Applications. Yourdon Press Computing Series. PrenticeHall, 1997.

[Con97]

Constantine L. The case for essential use cases. Object Magazine, May 1997.

[DSMC90] Defense Systems Management College. Systems engineering management guide. Technical report, January 1990. [Dav93]

Davis A.M. Software Requirements: Objetcs, Functions, States. Prentice-Hall, 1993.

[Har85]

Harel D. and Pnueli A. On the development of reactive systems. In Apt K., editor, Logic and Models of Concurrent Systems, pages 477–498. NATO ASI Series, Springer, 1985.

[Jac92]

Jacobson I., Christerson M., Jonsson P., and Overgaard G. Object Oriented Software Engineering, a Use Case Driven Approach. Addison -Wesley. Reading, Massachusetts, 1992. 39

Figure 11: Object Model for the POST System (first iteration)

[Kot98]

Kontoya G. and Sommerville I. Requirements Engineering: Processes and Techniques. John Wiley and Sons, 1998.

[Lar98]

Larman C. Applying UML and Patterns. Prentice-Hall, 1998.

[McM84]

McMenamin S.M. and Palmer J.F. Yourdon Press. Prentice Hall, 1984.

[Mil80]

Milner R. A Calculus of Communicating Systems. Springer, 1980.

[Par86]

Parnas D.L. and Clemens P.C. A rational design process: How and why to fake it. IEEE Transactions on Software Engineering, 12:251– 257, 1986.

[Pas95a]

Pastor O. and Ramos I. OASIS version 2 (2.2): A Class-Definition Language to Model Information Systems. Servicio de Publicaciones Universidad Polit´ecnica de Valencia, Valencia, Espa˜ na, 1995. SPUPV-95.788.

[Pas97c]

Pastor O., Insfr´ an E., Pelechano V., Romero J., and Merseguer J. OO-Method: An oo software production environment combining conventional and formal methods. In 9th Conference on Advanced Information Systems Engineering (CAiSE’97), pages 145– 159, Barcelona, Spain, June 1997. Springer-Verlag. LNCS (1250). ISBN: 3-540-63107-0.

[Ram93]

Ramos I., Pastor O., Cuevas J., and Devesa J. Objects as observable processes. In Actas del 3rd. Workshop on the Deductive Approach to Information System Design, Costa Brava, Catalu˜ na, 1993.

40

Essential Systems Analysis.

Figure 12: Object Model with class relationships

Figure 13: Refined Object model for the POST System

41

[Swa82]

Swartout W. and Balzer R. On the inevitable intertwining of specification and implementation. Communications of the ACM, 25:438– 440, 1982.

[Wie98]

Wieringa R.J. Postmodern software design with NYAM: Not Yet Another Method. Requirements Targeting Software and Systems Engineering, pages 69–94, 1998.

[Wie98b]

Wieringa R.J. A survey of structured and object-oriented software specification methods and techniques. ACM Computing Surveys, 30(4):459–527, 1998.

[Wir90]

Wirfs-Brock R., Wilkerson B., and Wiener L. Designing object oriented software. Englewood Cliffs, Nj. Prentice-Hall, 1990.

42