OOPS ABAP 2

UML notation:
The slide depicts two ways of representing classes. In the first, the class is represented by its name, attributes and methods, in the second, the name only is used. UML also offers you the option of omitting the either the attribute or the method part.

ABAP Objects events are not represented in class diagrams.


A class diagram describes the elements contained in the model and their various static relationships. There are two basic forms of static relationships:
­ Associations (for example, a flight customer books a flight)
­ Generalization/specialization (for example a cargo plane and a passenger plane are planes)

Classes can also be shown with their attributes and methods in the class diagrams.


An association describes a semantic relationship between classes. The specific relationship between objects in these classes is known as an object link. Object links are therefore the instances of an association.

An association is usually a relationship between different classes. However, an association can also be recursive; in this case, the class would have a relationship with itself. In most cases, recursive associations are used to links two different objects in one class.
The points below assume that the associations are binary.

Each association has two roles, one for each direction of the association (flight booking->customer, customer -> flight booking). Roles can have names (for example, the association flight->flight booking could be called reservations).
Each role has a cardinality that shows how many instances participate in this relationship. The multiplicity is the number of participating objects in one class that have a relationship to an object in the other class.

UML notation:
­ An association is represented by a line between the class symbols.
­ The cardinality of the relationship can be shown at each end of the line.
­ Associations can be given a name for ease of identification (a verb or a short text). This name is written in italics above the line and may have a arrow to show the direction. Both are optional.


Aggregation is a special kind of association. Aggregation describes one object that contains another or consists of other objects (whole-part). An airplane consists of wings. The relationship can be described by the words “consists of” or “is a part of”.

UML notation for aggregation:
An aggregation, like an association, is represented by a line between two classes, which then additionally has a small rhombus at one end. The rhombus is always at the aggregate end, that is, the whole object end. Otherwise the notation conventions are the same as for associations.

Composition is a special kind of aggregation. Composition describes the fact that the object contained cannot exist without the aggregate (for example, a flight booking cannot exist without the relevant flight).

Differences between composition and aggregation:
The cardinality on the aggregate side can only be one. Each part is only part of one composite object, otherwise the existence dependency would be contradictory. The lifetime of the individual parts is linked to the lifetime of the aggregate: parts are created either with or immediately after the aggregate, and they are destroyed either with or immediately before the aggregate.

UML notation for composition:
Like aggregation, composition is shown as a line between two classes and marked with a small rhombus on the aggregate side. However, in contrast to aggregation, the rhombus is filled in.


UML notation:
Generalization and specialization are denoted by triangular arrows that point from the subordinate class to the superclass.
Several arrows can be summarized into a tree.

Sequence diagrams, unlike class diagrams, show the dynamics between objects. They are used to represent a particular process or a particular situation.

Sequence diagrams focus on the time sequence of the information exchange:
­ Creating and deleting objects.
­ Message exchange between objects.

Sequence diagrams have no notation for representing static methods.

UML notation:
Objects are represented by squares. You can write the object name in these squares in various ways:

Object name

Object name:class name

class name

The object life line is represented by vertical dotted lines.

The control focus is shown as a vertical rectangle on the object life line. The control focus shows the object‘s “active” period:

­ An object is active when actions are executed
­ An object is indirectly active if it is waiting for a subordinate procedure to end.

Messages are shown as horizontal arrows between the object lines. The message is written over the arrow as Method (parameter). There are various options for representing the reply; in this example, the arrow is shown as a returning arrow.

You can also include a description of the process and add comments to the object life line as required.

RELATED POSTS

SAP SCRIPT CONTROLS 3

SAP CRM Organizational management
SAP CRM Territory Management
CRM Product manager
CRM Business Transactions 
CRM Activity Administration in SAP

No comments :

Post a Comment