Wednesday, July 18, 2007

Modeling a Class

The rules in the class diagram are used to generate code. The code generates objects.

A repository is a shared dictionary.

A change made to a class on one diagram is also made to the class definition in the repository, and is reflected in all diagrams that include that class.

To support definitions for identity, attributes, and operations, a UML class definition provides an icon with three predefined compartments.

The name always resides in the topmost compartment. A class name must be unique within a package. The format for a fully qualified class name is Package_Name::Class_Name.

Stereotype

Identify how a class is used in a design.
1. An entity element describes objects that are part of the subject matter.
2. Control elements typically represent specialized pieces of software that manage the behavior of some part of the application. knows about resources that it needs to manipulate or direct.
3. Utility stereotype represents a named collection of static attributes and operations. There is only one copy and everyone references that one copy. It hold common functionality used throughtout the system.
4. Enumeration stereotype is a user-defined datatype that defines a set of values that don't change(constants).


A class stereotype is not part of the class name and does not generate any code for the class. It bring consistency to the treatment of common elements in UML diagrams.

The stereotype may be applied in either of two forms: the stereotype name in
guillemets («»),

or graphical symbol.
a. entity stereotype represented as a circle on a straight line.
b. control stereotype by a circle "arrow".



Figure 5-9: Four ways to model classes with stereotypes.


Properties
Simple pieces of information about the class. ex.author, development status of the class, last worked, version etc. It specified below the name inside the name compartment. It expressed as a tag-definition/tagged-value pair ex. {author="Tom", Last_updated="09-18-02",Approved}



UML 2.0
Infrastructure is divided into four packages
Abstractions
Basic
Constructs
PrimitiveTypes
The Superstructure relies on the essential concepts defined by the infrastructure to build the concepts for constructing UML diagrams.

The Superstructure is divided into packages
structural
behavioral
supplemental

Port
A port is a class gateway to the outside world. One object coded in Java and the other in C++ should not matter. A port can become part of a class definition.


Modeling Visibility

private scope - within a class
package scope - within the same package
public scope - within a system
protected scope - within an inheritance tree

Private -
Package ~
Public +
Protected #


Private visibility -It limits access to objects of the same class.

Package visibility - allows access by other objects in the same package, regardless of the class they belong to.

Public visibility - allows access by objects of all other classes in the defined namespace anywhere in the system.

protected visibility - allows access by subclasses. This is true whether or not the subclasses reside in the same package.



Modeling Multiplicity

Multiplicity specifies the number of values that may be associated with a model element.
a lower value of zero indicates that the item is optional.

Range of values
[6..9] or 6..9 means 6 through 9 incluvely.

specific value
[2]

Range without limit
[1..*] - one or more
[0..*] or [*] - zero or more

set of discrete values
[2,4,7]

Ordering
{isOrdered}

{isUnique} attribute is new in UML 2.0



Modeling an Attribute

Contains definitions for all the information that an object owns.

A UML attribute definiotion includes the following elements.
-Visibility
-Derived(true/false)
-name
-data type
-muliplicity
-default value
-property string
-class-level versus instance level designation

Attribute notation
These attribute definition elements are commonly expressed in a single text string using the following syntax:

[visibility] [/] name [: type] [multiplicity] [=default]
[{property-string}]


Derived - A slash(/) in front of an attribute name identifies the attributes as containing a derived value. The absence of the slash indicates a base value.

Name - The attribute name is required. the name must be unique within the class.

Data type - explains kind of information that can be stored in the attribute.

Property string - express the rules required to guarantee the integrity of the attribute value whenever another object attempt to change it.



Class-level attribute
it also referred as static attributes. Every object of the class may access the value.


Modeling the operation


Operations define behaviors, the services that an object can provide.
It is valid to use stereotypes to label groups of operations according to their usage. The stereotype applies to all operations below it in the list until another stereotype appears or until you reach the end of the compartment.

Operation notation
The UML operation notation defines the elements of a class behavior modeled using the syntax:

[visibility] name ([parameter-list]) ':' [return-result] [{properties}]


Visibility
private(-) Only objects of the same class may call a private operation.
package(~) Only objects owned by the same package may call a package-level operation
public(+) Any object may call a public operation

Name
The combination of the name, parametar list, and return result, often called the signature, must be unique within the class.

Properties
allows to add any additional information about the operation that does not fit into one of the other predefined elements. The property text describes the constraints on the performance of the operation.

Class-level operation
It refers to an operation that is accessible within the class rather than within an object of the class. Class-level operations are also referred to as static operations in some languages. Every object of the class may access the operation. Objects of other classes may access the operation without referring to an instance of the class.

Exceptions
One way to handle exceptions is to return a value to the calling object and let it interpret that value to decide how to respond to success or failure. The most common appreoach is to throw an exception.

Preconditions
Define the terms that the invoking object must meet before the operation is obligated to perform its behavior.

Postconditions
specifies something that must be true after the behavior finishs.

No comments: