Week5-2. Classes Design for Model

Finding objects

Both use case and activity diagrams should be used to determine the objects. Examine the nouns in use case and the activity diagram. Another good place to look is the functional scenarios in the Functional Requirements document. As you look at the nouns, some of them will be Actors, some of them will be objects, and some of them will be attributes of an object.

Model – View – Controller (MVC) concept considers the following categories of objects:

Model (from the group of Entity objects). These are objects that hold information. Most of them eventually map to the tables or fields in the database. As well they carry on core business functionality.

View (from the group of Boundary objects). These are objects that lie between the system and end users. They represent GUI. Other boundary objects may be needed to interact to other systems, for example to Credit Card validation system.

Controller (from the group of Control objects). These are objects that intercept end user’s events and transfer the signal to model or other control object. They are attached to views, one controller to one view. Apart those designated controller objects there can be other control objects that control the flow through the use case. Control objects do not carry out any business functionality themselves. Instead they coordinate other objects and control the overall logic flow.

Classes Design for Model

All the work takes place under Logical View.

It is recommended to grouping classes into packages for each type of classes. It is helpful to manage classes. Create Packages and assign classes to packages.

Class Specification window shall be used to specify a class:

Stereotype – entity, boundary or control

Visibility – Public, Protected or Private. Protected classes are visible only to subclasses or to the class itself. Private classes are visible only to itself. Visibility is important feature to define the way of classes interaction. It comes into consideration together with attributes visibility and state change notification methods in control objects. We’ll discuss this matter later.

Persistence. Define if it is to be stored in the database or exists only in the memory. Entity classes are usually persistent. Control and Boundary classes are usually transient.

Multiplicity. Set the number of instances we expect to participate in a relationship.

Concurrency. Is used to describe the class behaviour in the presence of multiple threads of control. Keep the default meaning Sequential – means that the next instance executing may happen only after the current one is finished.

Note: this is not the best from the performance standpoint, however this issue is out of course scope .

Operations

Operations define the methods. General notation is:

Operation (argument1, argument2): return type

Arguments and return type are optional. Not all the operations have them.

Constructor and Destructor operations always are included. Rational Rose generates them automatically.

Other operations are known as Access operations to provide the access to data. These operations are set and get.

Implementor operations implement some business functionality. Most of them could be found from the sequence diagram messages that are triggers for implementors (next week topic). Each implementor operation should be traced back to functional requirements. The trace: operation – message in the sequence diagram – use case action/activity – function in the functional scenario.

Attributes

Attributes are described through data type.

As well they have the visibility feature. Protected attributes are visible for the class and subclasses. Private attributes are not visible for any other class. Attributes are typically private or protected.

Initial value can be set to the attribute

Making the attribute static means that all the class instances will have the same value

Attribute containment: by value – contained within the class. By reference – is accessible via the pointer

Derived attribute – the value is created from other attributes values.

Classes Relationships

There are 3 main kinds of object relationships:

-Inheritance (“is a”)

-Aggregation (“has a”)

-Association (bidirectional or unidirectional)

Inheritance relationship. Attributes of a parent class are visible and accessible to a child class. Should be defined as “protected”.

Aggregation relationship results in the attributes of a “part” being created in a “whole”. If this is aggregation “by value” (composition) the whole simply contains the part. If it is aggregation “by reference” the attributes in the whole refers to the part.

Association relationships reproduce the objects interaction needs required to implement the business logic (workflow). Association relationship results in the attributes created in both classes for bidirectional association or in the client class only if it is unidirectional association. The attribute values are accessible by references.

Note. The difference between association and aggregation exists in regards to object construction and destruction, objects life cycle. Generally speaking association is less tough coupling than aggregation.

Class Diagram design for the Model requires the following basic tasks:

Discover classes (objects).
Look for nouns in functional requirements, use cases specifications, and activity diagrams
Determine classes’ responsibilities
Enforce the principle of “encapsulation”. Each class must carry on only “natural” responsibilities
Determine attributes and operations
Attributes are defined from nouns. Operations reflect a class responsibilities
Identify the needs in interaction, in other words, discover association relationships
That is the key point of object-oriented design since it represents the business logic workflow. Reliable model of interaction requirements can be obtained through the sequence diagrams development. At this early stage, just make some assumptions on the basis of functional description.
Determine the needs in aggregation
Discover the whole-part relationships
Determine the needs in inheritance
Discover the parent-child relationships

Resulting class diagram represents the conceptual model that later should be decomposed further in order to incorporate implementation solutions.