Software Sue

Nested aggregation relationships form an aggregation hierarchy.

Attributes are used to model properties of simple types such as integers, characters, etc. These are the pre-defined types that are available in most programming languages.

In OO, a class can represent a domain. When an attribute belongs to a significant domain, it can be modelled instead as a relationship to the domain class. Any data format, validation rules, or even conversion routines can be defined within the domain class. The advantage of the OO approach is that it can be used for arbitrarily complex domains.

A word often used for domains in OO literature is 'type'.

Events - whether they are external or temporal - affect a class by causing it to move from one state to another. The set of object states and the allowed transitions between them are depicted in an OLCD for that class. The behaviour of each class is determined by how it responds to these events:

• How its attribute values change
• What it needs to do to process this event

Interactions between the classes and elementary processes in the business area are initially represented in a Class-to-Elementary Process association matrix. This provides a starting point for identifying the events that affect a class.

A behaviour model consists of:

• the set of business events
• the OLCDs for the affected classes
• the set of methods for these classes that affect these transitions

  During behaviour modelling:

• identify the events
• identify the classes they affect, and their effects on these classes
• identify the states and state transitions
• diagram these in an OLCD. OLCDs are drawn for classes with non-trivial behaviour. The number of distinct states and state transitions is a good indicator of the complexity of the class's behaviour
• identify and provide a high-level description of the methods that affect these transitions. A high-level description includes its name, an initial description of the processing involved, and the input and output parameters required..

Different problems require different levels of emphasis on modelling the behaviour of objects. There are problem domains where the behaviour of the classes is trivial. In such cases, behaviour modelling may be de-emphasised or even skipped for some of the classes. For example, batch systems often have complex processes, but simple behaviour, so their classes tend to have simple object life cycles.

Relationships to business area classes are also used to model class properties. If the property is sufficiently complex, or if it has distinct and identifiable behaviour, it can be modelled as a separate business area class. An association is created between this class and the original class. As shown below, the regional HQ of a particular video store may be better modelled as a separate class than as an attribute in the video store class. One reason for modelling the property as a separate class is to allow the property to have its own life cycle and existence independent of the original class.

It is important to note the differences between business area classes and event manager classes:

• Business area classes are persistent, event manager classes are not.
• Business area classes model real world concepts (tangible or intangible). They have a set of defined states and methods to manipulate their states. Event manager classes model an event. They usually have just one method whose only responsibility is to process the event. They have no state.

A business area class method exists to perform exactly one logical method on a business area class, independent of who invoked it and why it was invoked.

The object navigation diagram is a graphical way of specifying the business area class methods that an event manager class method can invoke.

• should implement a single logical operation, and the rules of nature that correspond to that operation. This operation can be a state change, or an algorithm that transforms one set of values to another. A rule of nature is one that is not likely to change. For example, an 'order line item' cannot exist without a parent 'order'. The operation 'delete order', therefore, should be responsible for invoking methods to first delete all dependent 'order line item' instances. The EMC method, or any other method, should not be responsible for enforcing that rule. Business rules which are not rules of nature should be externalised from fundamental methods. These rules can be described by a class (e.g. storing the table of stock reorder quantities from different stock numbers) for run-time reference, or can be built into the EMC.
• Should only contain logic used for all contexts. Each context corresponds to the invocation of the method, either directly or indirectly, in response to a particular business event.
• should not contain logic associated with a user interface. User interfaces tend to be specific to a particular context.
• should only have visibility to the classes directly related to it in the object model. In other words, class-to-class method invocations should traverse relationships in the object model one at a time. The principle of limiting the visibility of each method minimises the effect on methods of changes to the object model.
• should not make decisions based solely upon incoming message data (which would imply a context-dependency), set default values (which are usually dependent upon context), or explicitly handle exceptions (which overly complicate the method and move it away from having a single purpose).
• should recognise exceptions that are valid occurrences in the business area, and indicate in the completion status the fact that the exception was encountered.

See also 'Method Scope'

Note that a CRD is a simplified graphical representation of the semantics of the object model. Static rules that apply at object creation and deletion time are shown. Dynamic, time-dependent rules that govern how the classes behave cannot be shown in such a static representation. These are modelled as part of the class's behaviour or described as rules and constraints in the textual definition of the appropriate class.

Processes typically access and manipulate data defined in multiple classes. For example, the work performed to accept a returned video tape may be modelled as an EP. This EP effects data defined in the 'rental agreement', 'video tape' and 'rental agreement line' classes.

An EP to class matrix can be used to illustrate the effects of EPs on classes.

A column represents the effects of a single EP on the classes. A row represents the effects of all EPs on a single class. The intersection represents the effect of an EP on a class, which is usually implemented as a class method. Therefore, a method name at a column/row intersection indicates the effect (s) that an EP has on that class. This effect typically is a transition in state. Note that the same method may appear in more than one cell in a row, indicating that the same method is called (i.e. the same state transition is effected) by more than one EP

The set of methods for a class (methods along a row) characterise the class's behaviour and are shown on the OLCD. The set of methods invoked by an EP (methods down a column) is the primary logic for the EP. The set of methods invoked, and the order in which they are invoked, are represented in the object navigation diagram.

However, the complete specification for an EP is more than just the set of class methods it invokes. It also needs to include event-specific or context-sensitive processing that needs to be modelled outside any of the individual business area classes. Global consistency checks, input validation, error handling, etc., are examples of this. Such logic is defined in the event manager class method..

Each class defines a public and a private part. The data and methods that reside in the public part of a class definition can be freely accessed from the outside. The private part, however, cannot. Hence, the public part of a class is usually referred to as its interface (or its specification) and its private part as its implementation. This clear distinction between the interface and its implementation is called encapsulation.

Encapsulation and abstraction are complementary. Encapsulation prevents the clients of that object from seeing the inside of that object, where its behaviour is implemented.

This allows us to change the implementation of a particular method or modify the representation of an object, we can do so without changing the interface. Encapsulation allows us to maintain fine-grained control over the visibility of a class's internals.

• business events, both external and temporal
• internal system events, such as those generated from an event-driven GUI.

It is important to distinguish between these event types. Business events are real world events. They initiate processing that involves a subset of the business area classes. System events, on the other hand, are lower-level events initiated, for example, during a user's interaction with the system. Moving a mouse on a screen or clicking on a button in a window generates system events. It is important during analysis to focus on business events, rather than system events.

A business event represents a message from outside the business area that must be recognised and processed by something within the business area. an event manager class encapsulates the processing required to process such an event. An event manager class is defined for each business event. Each event manager class has exactly one public method. This method receives the incoming event and is responsible for processing it (see Event manager class methods below).

Event manager class objects exist only for the duration of processing the event; they are not persistent. Each time a business event occurs, an object of the corresponding event manager class is instantiated. This object's only responsibility is to process the event. This involves validating the event data, invoking appropriate methods on business area classes, and responding to the source of the business event. Once this is done, the event manager class object is destroyed.

It is important to note the differences between business area classes and event manager classes:

• Business area classes are persistent, event manager classes are not.

• Business area classes model real world concepts (tangible or intangible). They have a set of defined states and methods to manipulate their states. Event manager classes model an event. They usually have just one method whose only responsibility is to process the event. They have no state.

Event Manager Class Methods

An event manager class has one primary method to specify the event handling logic. This method differs in purpose from business area class methods. A business area class method exists to perform exactly one logical method on a business area class, independent of who invoked it and why it was invoked. An event manager class method, on the other hand, models event-dependent and context-sensitive logic. It is responsible for invoking methods in other classes and for performing work based on how the event was invoked, and how the other methods have done their work. The processing performed by an event manager class method can be categorised as follows:

• Pre-processing. Incoming event data and constraints upon the processing of the event are validated. Pre-processing can include method invocations for data access against business area classes.
• Event processing. Business area class methods are invoked. After each invocation, completion status is checked, and any event-specific design logic necessary to determine the next processing path is executed.
• Post Processing. Output parameters, including completion status and error messages, are set.

The object navigation diagram is a graphical way of specifying the business area class methods that an event manager class method can invoke.

• should contain only policy logic: accessing BACs to determine the context of the event being processed, making context-dependent decisions about what methods to invoke, performing user I/O, setting defaults, and handling exceptions.
• should not contain algorithms or state-change logic.

See also 'Method Scope'

Inheritance is the mechanism by which a class's data and behaviour are available to its subclasses. The superclasses usually define the more generalised attributes, relationships and methods. The subclasses inherit them and are free to use them as is, or specialise them. These subclasses can be parent classes of other classes. Classes are then said to be in an inheritance hierarchy. )or a generalisation/specialisation hierarchy).

A class may have any number of subclasses. If a class is only allowed to have one direct superclass, this is called single inheritance. If a class can inherit more than one parent class, this is called multiple inheritance.

A method has a specification and a body. The specification includes the name of the method and its input and output parameters, which are specified by name, type and order. The body is the fragment of process logic or code that implements the method. There may be several methods that represent different implementations of the same logical operation, to be used in different cases. It is not necessary for a calling program to know the class of the target object when the message is sent. The correct method is selected based upon the class of the target object.

In general, there are 5 kinds of methods.: constructors, Destructors, modifiers (or writers), accessors (or readers) and iterators. The first 4 correspond to Create, Read, Update and Delete (CRUD) operations respectively.

In order to maximise the potential for reusability, extensibility and maintainability, it is important to carefully consider method scope boundaries. Method scope refers to the total functionality that a method provides, including any processing achieved by invoking other methods. The object navigation diagram provides a good vehicle for initial analysis of method scope boundaries, because the scope of a method is significantly reflected by the methods it invokes.

All rules concerning method scope for event manager classes and business area classes should be considered during creation or analysis of the OND. In addition, the pattern of method invocations should be analysed to remove dependencies of a particular method upon any context of invocation.

The figure above depicts 2 possible ONDs for the same elementary process. The difference between the 2 is in the interpretation of what decision logic should be built into each method. In the first OND, the event manager class simply initiates the processing. The subsequently invoked methods make all further decisions about what processing to perform. In the second OND the EMC method participates in the decision process about the invocation of method C. In order for this second diagram to be correct, the decision logic in the EMC method must be dependent upon a context of which method B has no knowledge. In this case, the logic is dependent upon something about the initiating event, since the logic is in the EMC method.

It is important to realise that logic that does not invoke methods must be analysed for proper placement through detailed analysis of individual methods, rather than through analysis of the OND. Therefore, analysis of the OND is not a complete check of the proper scoping of methods. However, when developing or refining the OND, it is important to keep in mind the rules governing the appropriate scope of a method.

When describing methods during analysis, assume that the following are formally covered in the object model:

• setting mandatory attributes for an object when an object is created

• establishing mandatory relationships
• validating that an attribute's value conforms to the rules in the attribute or domain class description
• determining the value of any derived attribute

When a conflict between the scope rules for the BAC and EMC is identified, consider the following solutions:

• re-partition the method logic between existing methods, either between business area methods, or between an EMC method and a BAC method.
• split the method and create 2 methods that are independently invoked.
• split the method and move 1 of the methods to a class lower or higher in the class hierarchy.
• split the method and move 1 of the methods to a related class.

In all cases, try to determine with what class and method the logic is always and fundamentally associated.

If an employee of the bank is allowed to hold an account in that bank, this person can be modelled by an Employee Account Holder class that is a subclass of both the Bank employee and Account Holder classes.

Multiple inheritance is difficult to implement because properties and methods can be inherited from all parent classes. If Bank Employee and Account Holder have different definitions of a certain attribute or a method, the correct definition to use must be resolved at runtime or explicitly by the user. A more subtle problem arises when similar properties/methods are inherited under different names from the different parent classes. This leads to conceptual redundancy.

It is usually possible to model without using multiple inheritance. Even this example could be modelled differently to use only single inheritance. Avoid using multiple inheritance without considering single inheritance alternatives.

If a subclass can inherit something from more than one parent class, it has to explicitly decide the source. As C++ is strongly typed, this determination has to be made at compile time. With weakly-typed, dynamically-bound languages, this determination is made at runtime.

State transitions may be caused by a business event (an external event or a temporal event), or an internal event generated by another object. However, business events drive the modelling process during analysis because internal events (messages) between objects are indirectly caused by business events.

Each business event typically initiates one state transition on each affected class. Each transition is effected by a method. to model this, the arcs representing the transitions in an OLCD are annotated with the name of the method that affects the transition. In the above figure, a video tape has 2 distinct states: 'for rent' and 'rented'. The method 'rent video' effects the state change from 'for rent' to 'rented'.

An object can have an infinite number of physical states as defined by the different possible values of its attributes. However, it is impossible to exhaustively model all possible values of all attributes of an object, and all possible states may not be relevant. For example, in modelling the membership state of a video store member, the analyst may discover that processing is conditionally dependent on whether the account is active or not. Another process may need to know if the balance is positive or negative. If there are no processes or rules that depend on the exact amount of the positive or negative balance, then it is sufficient to model just 2 states, positive-balance and negative-balance, even though every different value of the balance attribute is potentially a different state. States identified during analysis are those to which significant and relevant behaviour is related.

If the number of possible states and allowable transitions gets too high to represent in one (flat) OLCD, nested life cycle diagrams may be used. Here, the diagram is partitioned and may be viewed and constructed at different levels of abstraction and detail. A state at one level is a metastate (or composite state) representing a set of states and transitions that are individually represented in a lower-level OLCD.

During the Business Area Requirements Analysis Stage, the OLCDs represent a purely logical view of the life cycle of objects belonging to each class. During Conceptual System Design, the OLCDs need to be reviewed. The conversion of business events and elementary processes into business transactions and procedures may result in additional object states that need to be reflected in the object life cycle models. For example, if organisational and geographic constraints cause 2 groups of people working on the same business product to be physically separated, you may have to design various states of the product representing hand-off points between groups. Since each of these states is likely to have associated business rules, they should be represented in the object life cycle.

An OND specifies the method invocations required to process a business event. It also:

• Helps to ensure that all methods required to respond to a business event have been identified
• Establishes a partial specification of each depicted method, since it shows the allowed method invocations from each method.

Each rounded box in the diagram represents a method. Each arrow represents a message (method invocation). The naming convention for each method consists of a class name, followed by a colon, followed by a method name. The focal point of this diagram is the event manager class method which is responsible for invoking other business area class methods required to respond to the event. In this example, the event manager class is 'return video'. (The event manager class is also named 'return video'). It invokes 2 other methods directly: 'close line item' on class 'rental agreement line item' , and 'credit account' on class 'member account'. The arrow indicates the direction of method invocation,; a return message is implied in each case.

The lower example shows an expanded version of the same OND showing both the direct and indirect method invocations. The 'close line item' method may invoke 'close rental agreement', which in turn may invoke 'debit account'.

The decisions of how many levels of indirect method invocations should be included on the diagram is influenced by the following guidelines:

• include all required methods that create, update or delete stored data.
• include other methods if they have algorithmically complex processing.
• if a method is being used from a tested class library, or if it has been specified and baselined as part of the current project, include the method, but do not expand it on the diagram by including its method invocations.

The following set of rules apply when ONDs are drawn:

• all processing starts and ends with the event manager class method; the processing depicted by an OND represents a complete logical unit-of-work.
• arrows show the direction of method invocation from the invoking method, to the invoked method.
• even though arrows are unidirectional, a return message is implied, providing at least a completion status.
• each method has visibility only to those methods that it directly invokes.
• the class indicated for each method is the highest class in the class hierarchy to which the method applies.
• the invoking method must have an identifier for the target object. It must either know the object ID, or know specific values for one or more properties of the target object's class that will allow identification and access of the object.
• the method of invocations diagrammed on the OND constitute significant decisions about the scope of each method. All guidelines for the proper scope of event manager class methods and business area class methods should be adhered to while defining method invocations on the OND.
• the event manager class method has the option of aborting the entire unit of work at any time, while business area class methods do not.

An OND is, essentially, a diagrammatic way of representing method logic. It could, therefore, be used to represent the logic for any business area class method, not just event manager class methods. However, since the system is scoped in terms of the events to which the business area will respond, producing a diagram for the event manager methods ensures scope coverage. There may be cases, however, where the logic for a particular business area class method is sufficiently complex to warrant detailed analysis using an OND.

The diagram's syntax appears to assume that the invoking method must know the invoked method's class. This is not true; in an object model, a method needs only to know the target object ID and a method name. The class names are shown only to provide a context for the method name, to help the analyst relate the diagram to the object model. The fact that a subclass may override a particular method is not depicted on this diagram.

This definition of state is necessary because:

• it is impossible to exhaustively model all possible values of all attributes of an object
• it is not always important to know the new value exactly; just being able to determine that its value has changed may be sufficient.
• it may sometimes be necessary to access only the current value of an attribute (e.g. current key), and its history may be irrelevant.
• it may sometimes be necessary to be able to determine both the new and old values.
• all changes of value in an attribute may not necessarily result in a meaningful change in state (e.g. if balance remains positive, the interest calculation method does not change).

Polymorphism can be misused. If the 2 methods are not logically equivalent, problems can occur when developers who are not aware of that fact attempt to use the method, e.g. if one 'close account' deletes the record, but the other only changes a state variable.

Relationships to domain classes are used to model more complex types of properties. For example, a member's age may be modelled by a relationship from Class Member to domain class for Age. A fundamental advantage of this option (over modelling it as an attribute) is that the domain class can be re-used. By re-using it, we get the validation logic inherent in the definition of the domain class. In this example, if the valid range of a member's age is defined to be 21 - 100, every time a member object is created, the value of the member's age property is checked to ensure that it falls in this range. In addition to re-use, a domain class allows us to localise and encapsulate the specification of validation logic for this property.

Relationships to business area classes are also used to model class properties. If the property is sufficiently complex, or if it has distinct and identifiable behaviour, it can be modelled as a separate business area class. An association is created between this class and the original class. As shown below, the regional HQ of a particular video store may be better modelled as a separate class than as an attribute in the video store class. One reason for modelling the property as a separate class is to allow the property to have its own life cycle and existence independent of the original class.

The interface, or public part, of a class (see 'encapsulation').