Terms Object vs Class

Before explaining Class Categories we have to know what a Class means.

The term is best explained by an example.

For example two Sales order exist in the database. One Sales order with Sales order number 100001 and to other with Sales order number 100002. Those are two Objects of the same Object type “Sales Order”. An Object type is called a Class.

So based on the Class “Sales Order” I can instantiate a “Sales Order” object. Instantiation is the most important concept of object oriented programming.

The Sales Order object with Sales order number 100001 contains all the data of that object like the net value, gross value, sales order items, tax lines and so on. This data part can only be accessed by methods. This is called data hiding. For example the data can be updated by a method called update(). Sales Order Class can also contain objects like a Sales Order PDF document. So the class can also have actions like createDocument(). These methods are the action part of the object. See this concept visually supported by the picture below.

Main Class Categories for Business Applications

Class Categories is a way of grouping Classes by their responsibilities.

The Class Categories mentioned below are for Business Applications. Business Applications are focused on Business Objects.

Class Categories Graphical overview

Below you see the Software layers and in the Software layers the main Class Categories.

Class Categories and Responsibilities overview

• Presentation layer
  • APP = Application
    • This is the starting point of an application. An application can be a SAP Transaction, Batch program or any other program.
  • CTL = Controller
    • Handling the screen flow
    • Transporting data to views and model
    • Handling screen actions
    • Can contain controllers
  • VW = View
    • Is a screen.
    • A view contain screen controls and views.
      Views contain views becomes a hierarchy of views.
    • Triggering screen actions
  • MDL = Model
    • Logic for data transport between Client proxy and Controller
    • Handling screen actions
  • Others
    • FMT = Formatter
      • Formatting values. For example for amounts converting from decimal point to decimal comma and add thousand separator.
• Interface layer
  • PRX = Client proxy
    • Calls the server proxy to send and receive data to the backend.
  • SRV = Server proxy
    • Handles the call from the client proxy by calling classes in the Business layer.
• Business layer
  • BO = Business Object
    • Business Objects are data representations of objects like Sales Orders, Purchase Orders, Customers, Suppliers, Materials, Projects and so on.
  • DAO = Data Access Object
    • Persisting and reading an Entity (for Business Object and other persisted objects)
  • DP = Data provider
    • Read data from the database via the Data Access.
  • PRC = Processing class
    • For example for mass actions like mass updates or mass sending emails and so on.
  • Others
    • BO_FT = Business Object Factory
      • Class for instantiating and persisting a Business Object.
    • BOC = Business Object Composite Child 
      • for example a Sales order item.
        
    • OBJ = Non-Business Object
      • For example a a Adobe Document, a File, an Email and so on.
    • WF = Workflow
    • CVT = Converter
• Persistence layer
  • DA = Data Access
    • ABAP does not use a Data Access class.
    • It uses the statements SELECT, INSERT, UPDATE, MODIFY, DELETE and COMMIT.
    • With RAP statements READ ENTITY, READ ENTITIES, and more.
• Data layer (These are not classes)
  • QRY = Database query
  • TBL = Database table

Reasons for fine grained class design

The reasons for moving from a coarse grained division to a fine grained division design are…

• It makes the possibility for reuse higher.
  • Reusing software makes the code more robust, because the reused code is already tested.
  • Reusing generic designed software leads to a uniform way of working.
• It makes expanding the functionality easier and clearer.
• It makes automated unit testing of smaller pieces possible.
• And probably more…

Proceed…

Now that we have gained knowledge of Class Categories we can map the Design Actions of the previous blog post to classes and create a first version of the class diagram. This will be done in the next blog post.