|OO and Function Points
The traditional view of software systems is as a composition. There is a collection of data that represents some information and a s set of procedures which manipulates the data. The data and procedural logic are separate components which comprise the overall software system.
In the object-oriented view of software systems there is a single entity called an object which represents both the data and the procedures. Like pieces of data, objects can be manipulated. However, like procedures, objects can describe manipulation as well.
An object is a collection of data (attributes and properties) and functional logic (methods). The data defines the state of the object and the methods define the behavior of the object. There are two kinds of methods. First, Interface methods which provide a means of communicating with the object. Second, internal methods which create object behavior but are not accessible from outside the object. The interface method provides a clear defined way of communicating with an object. The internal method need only be known to the designer of that object. Users of the object ONLY need to know about the interface methods.
Function Points measure software by quantifying its functionality delivered to the user based primarily on the logical design. Frequently the term end user or user is used without specifying what is meant. In this case, the user is a sophisticated user. Someone that would understand the system from a functional perspective --- more than likely someone that would provide requirements or does acceptance testing. Function Points make it possible to measure the size of the information systems according to what the user sees and interacts with. This definition is similar to the interface method described above.
All internal methods are done to support interface methods. Internal methods are not done as an end, but are done as a mechanism to assist the interface method in delivering information to the user.
Interface Services, Transactions or Message Passing
Objects communicate with another by passing messages. A message contains a name which identifies its destination, and may also contain some arguments or parameters. The message, when received, will cause the invocation of an appropriate method within the receiving object. In its simplest form, a message is the same as a function or procedure call in a traditional sense, since the net effect will be the same. The sending object is often referred to the server and the receiving the client. A message prepared and sent to the client will generally manifest itself as an External Output or a External Inquiry. A message prepared and sent from the client to the server is generally an External Input.
A message is a request for an object to carry out the sequence of actions in one or more of the methods of its calls. A method is a unit of functional logic contained within an object. According to IFPUG Standards, a transaction must have processing logic that is unique and represents the smallest unit of activity that is meaningful to the business user. Since a method is a unit of functional logic contained in an object, it is very similar to the definition of a transaction -- according to IFPUG Counting Rules.
With OO applications only persistent data is considered an Internal Logical File not transient data. Transient data is only valid inside a program or transaction and is lost when the program or transaction terminates. In traditional programming this would be similar to a temporary file. Persistent data is stored outside the program and survives program termination.
Persistent Data is stored in either Relational Database or OODBMS. Frequently, data contained in third normal form represent one internal logical file. Third normal form attempts to remove any dependencies between non-key attributes. To be considered an internal logical file (ILF) the file (or table), the data is a logical group, the data is maintained or modified through and elementary process (methods).
1. "Peer to Peer Communication" --- A unique message sent, received and responded to is a series of functions. Lets assume there are two applications A & B with peer to peer communications. Application A sends a message to application B --this message sent is an External Output for application A and an external input for application B. B processes the message based on some prescribed business rules and creates a message (External Output for Application B) that is sent back to application A (an External Input for Application A). So this series of communication would represent 2 External Inputs and 2 External Outputs. In reality there may be hundreds of unique messages sent between Application A and B.
2. Two Switches Communicating through polling is an example of an external inquiries.
3. If an application has heavy user interface and is OO, there will be many more inquiries (External Inquiries) than a traditional system. A screen my have several unique objects. For example, a customer inquiry object may display a list of current customers (first External Inquiry). After selecting a customer the screen populates all the fields about a customer, address, phone, city, state, tax status, so on and so forth (second External Inquiry). If all the fields can be modified then the final screen is an External Input. So this one screen has 2 External Inquiries followed by an External Input.
To reiterate, function points can be applied to OO environments. The proposed benefit of OO applications is faster, better, and cheaper applications. If this is not the case why bother! There must be some normalization factor to compare OO to traditional development. Function Points focus on what is delivered to the user and is independent of development methodology or language. What is delivered to a user in an OO or traditional application will be the same.
Object-Oriented Software Metrics by Mark Lorenz, Prentice - Hall, 1994
"Towards a metrics suite for object oriented design," by Chris Kermer, OOPSLA 91 Conference Proceedings, October 1991, pp 197-211.
Parametric estimation of programming effort by R. Jenson, Journal of Systems and Software, vol. 15, 1991 pp 107-14.
Metrics in Object-Orientated Design and Programming by Ralph Kolewe, Software Development, vol 1. No 4. October 1993, pp 53-62.
Software Size Estimation of Object Oriented Systems by L. Laranjeira, IEEE Transactions on Software Engineering, vol 1, no 5, May 1990, pp 510-22.
Questions or Comments? email