ComputeReturnDate(booktype: Category): Date
AverageGrade(grades:listofgrades): numeric{ 2 decimals}
OutstandingOrders(startdate:Date, enddate: Date): integer
TotalPrice(unitprice:Dollar, discount: numeric): Dollar 

Try not to get sidetracked by assigning operations to your classes just yet, that is a detailed design activity.
If you spend time doing that now, you will probably just need to redo it later.
If you leave the behavior implied on the robustness diagram and in the use case, it never gets done on the sequence diagram, and (if you are allocating operations to classes by working through the use cases) it just sort of falls through the cracks to be dealt with in coding-land. The more stuff that falls through those cracks, the less useful the models are, and the less the team will model with enthusiasm.

For example, the elements of an interface are operations, in UML terms. An operation is an abstraction, not an implementation. By contrast, a method (in the UML) is an implementation of an operation. A UML operation has a signature (name and parameters), and also an operation specification, which describes the effects produced by executing the operation; that is, the postconditions. The UML operation specification format is flexible, and does not have be the contract format shown in this chapter. However, the UML documents give as examples the contract style with pre- and postconditions, as this is the most well-known approach to formal operation specifications. To summarize: The UML defines operation specifications, which are specifiable in the pre- and post-condition contract style. Note that, as emphasized in this module, a UML operation specification may not show an algorithm or solution, but only the state changes or effects of the operation. In addition to using contracts to specify public operations of the entire System (system operations), contracts can be applied to operations at any level of granularity: the public operations (or interface) of a subsystem, an abstract class, and so forth.
The operations discussed in this module belong to a System class. In the UML operations belong to classes. Furthermore, in the UML, "subsystems" are modeled as classes (and simultaneously also as packages). In the UML, the overall "system" is the top-level subsystem, and modeled as a class named System (actually, any name is legal) with public operations and specifications.