Enterprise & Application Frameworks

SJSU – CmpE Fall 2002

Enterprise & Application Frameworks

Dr. M.E. Fayad, ProfessorComputer Engineering Department – RM#

College of Engineering

San José State University

One Washington Square

San José, CA 95192-0180

URL: http://www.cmpe.sjsu.edu/~fayad

Fall 2002 SJSU – CmpE M.E. Fayad L6-S2 Modeling

Roles The Role Object Pattern

http://www.riehle.org/papers/1997/plop-1997-role-object.pdf


Class Diagrams


Acknowledgements “Developing Software With UML:

Object Oriented Analysis and Design in Practice”

By: Bernd Oestereich

Using UML: Software Engineering with Objects and Components

By: Rob Pooley and Perdita Stevens


Classes Related terms: type, object factory Definition:

– A class is the definition of the attributes, the operations, and the semantics of a set of objects. All objects in a class correspond to that definition.


Classes Description:

– A class contains the description of structure and behavior of objects it generates or which can be generated using it. Objects are produced by classes and are the units that act in an application. The behavior of an object is described by the possible messages it is able to understand. For each message, the object needs the appropriate operations.


Classes Notation:

– Classes are represented by rectangles which either bear only the name of the class, or show attributes and operations as well. In the second case, the three sections, class name, attributes, and operations, are separated by a horizontal line. Class names begin with an upper case letter and are singular nouns.


Classes Attributes:

– Attributes are listed by their name, and may also contain specifications of their class, and initial value and potential tagged values and constraints.


Classes Operations:

– Operations are noted by their name, and also with their possible parameters, class and initial values of these parameters, and potential tagged values and constraints


Classes Example:

Circle

radius {radius>0}center: Point = (10,10)

display()remove()

setPosition(pos: Point)setRadius(newRadius)

Class Name

Attribute name

Attribute type

Operations

Constraint

Initial Value

Parameter(Name: Type=Initial Value)


Abstract Classes Related Terms: virtual class Definition:

– An abstract class is never used to generate object instances. It is intentionally incomplete, and thus forms the basis of further subclasses which can have instances.


Abstract Classes Description:

– Abstract classes often represent a general term, a generic term for a set of concrete terms. For instance, vehicle can be an abstract generic term for bicycle, car, truck, train and airplane. Real instances exist of the concrete terms bicycle, car and so in, but there is no such thing that would be simply a vehicle.


Abstract Classes Notation:

– An abstract class is represented in the same way as a normal class, but in addition, the tagged value abstract is written below the class name, or the class name is set in italics.


Abstract Classes Example:

Geomfigure

Circle RectangleTriangle

Abstract Class

Concrete Classes


Objects Related terms: instance Definition:

– An object is a unit which actually exists and acts in the current system. Each object is an instance of a class. An object contains information represented by the attributes whose structure is defined in the class. An object can receive the messages defined in the class, that is, it has appropriate operations for each message defined.


Objects Description:

– An alternative term for object is instance. A class contains the definition of objects, that is, their abstract description. The behavior of an object is described through the possible messages it can understand. For each message, the object needs appropriate operations.


Objects Notation

– Objects are represented by rectangles which either bear only their own name, or which in addition show the name of their class, or the values of specific or all attributes. If attribute values are indicated, the rectangle is divided into two sections, separated by a horizontal line. The name of the object is underlined, and usually begins with a lower case letter.


Objects Example:

aCircle: Circle

radius = 25center = (10,10)

Instance name

Attribute names

Class name

Attribute values


Attributes Related terms: data element, instance

variable, variable, member Definition:

– An attribute is a (data) element which is contained in the same way in each object of a class and is represented by each object with an individual value.


Description Each attribute is at least described by its name. In

addition, a data type or a class, plus an initial value and constraints may be defined.

Constraints can be used in addition to the type specification to further restrict the value range or value set of the attribute, or to make it dependent on other conditions.

Tagged values can be used to specify additional special properties. Thus, for example, the tagged value {readonly} indicates that an attribute may only be read.


Attributes Notation:

– Attribute names begin with lower-case characters and class names with upper-case one, while tagged values and constraints are enclosed in braces

• attribute : Package::Class =InitialValue {PropertyValue} {Constrant}


Attributes Examples:

– name: String = ‘Unknown’– invoiceDate : Date = today– birthDate : Date– color : {red, blue, green}– radius : Integer = 25 {readonly} {radius>0}


Operations, Methods Related terms: method, service procedure,

routine function, message Definitions:

– Operations are services which may be required from an object. They are described by their signature (operation name, parameters, and if needed, return type).

– A method implements an operation; it is a sequence of instructions.

– A message passes an object the information on the activity it is expected to carry out, thus requesting it to perform an operation.


Operations, Methods Description

– A message consists of a selector (a name) and a list of arguments, and is directed to exactly one receiver. The sender of a message is as a rule returned exactly one response object. Inside a class definition, an operation has a unique signature composed of the name of the operation, potential parameters, and a potential return value (function result).


Operations, Methods Description (continued)

– Operations may be provided with constraints which can describe the conditions to be met at the call or the values the arguments may have, among other things.

– Tagged values can be used to describe additional special features. Some tagged values are:

• {abstract} to indicate an abstract operation• {obsolete} to indicate that this operation exists only for

compatibility with previous versions.


Operations, Methods Notation

– The signature of an operation is given as follows:

• name(argument : ArgumentType = DefaultValue, …):

ReturnType {PropertyValues} {Constraints}

– Example:• setPosition(x : Integer = 1, y : Integer =1):

Boolean {abstract} {(x > 0) and (y > 0)}


Operations, Methods Naming Conventions

– Be extremely careful with the naming of operations. You should be conscious of what the operation is supposed to do and for which outcomes it is responsible.

– Always try to use active verbs, be careful with adjectives, and be precise!


Stereotypes Related terms: usage context, constraint Definition:

– Stereotypes are project-, enterprise-, or method-specific extensions of pre-existing model elements of the UML metamodel. According to the semantics defined with the extension, the model element to which the stereotype is applied are semantically directly affected.

– In practice, stereotypes mainly specify possible usage contexts of a class, a relationship, or a package.


Stereotypes Description:

– A stereotype is UML’s way of attaching extra classifications to model items; it is one of the ways that UML is made extensible. The stereotype describes a model element, and is placed close to the affected element on a diagram, giving extra information about that element

– Some stereotypes are predefined in UML; they are automatically available and cannot be redefined. <<interface>>, <<type>>, and <<implementation class>> are examples.


Stereotypes Description: (continued)

– Stereotypes can be defied to express whatever extra classification may be deemed useful. For example, if an application had persistent classes, the stereotype <<persistent>> could be defined to show which classes are persistent.


Stereotypes Notation:

– The stereotype is placed before or above the element name and enclosed in French quotes (<<>>)

– Alternatively, special symbols may be used (decorative stereotypes). These can be seen in Rational Rose. Some of the elements that are represented in this manner are: <<actor>>, <<control>>, <<entity>>, and <<boundary>>.


Stereotypes Examples:

– Stereotypes can, for example, be used to indicate the meaning of a class in the application architecture, such as:

• <<presentation>>, <<process>>, <<domain class>>.

– Further examples:• <<model>>, <<view>>, <<controller>>, <<exception>>,

<<primitive>>, <<enumeration>>, <<signal>>, <<complete>>, <<incomplete>>, <<implements>>, <<uses>>, <<extends>>


Interfaces, Interface Classes Definition:

– Interfaces describe a selected part of the externally visible behavior of model elements (mostly of classes and components).

– Interface classes are abstract classes which define abstract operations, exclusively.


Interfaces, Interface Classes Description:

– Interfaces are specifications of the external behavior of classes and contain a set of signatures for operations that classes wishing to provide this interface need to implement. Operations in an interface need not be explicitly marked as {abstract}, because this is mandatory.

– Common classes that wish to implement an interface need to provide all the operations defined in the corresponding interface class.


Interfaces, Interface Classes Notation:

– Interface classes are noted in the same way as common classes, except that they bear the stereotype <<interface>>. They do not need a compartment for attributes, as they contain only operations. Operations in interface classes define only signatures; they are abstract and should therefore be set in italics.


Interfaces, Interface Classes Example:

String

isEqual(String):BooleanisGreater(String):Boolean

Length():Integer

<<interface>>Sortable

isEqual(Object):BooleanisGreater(Object):Boolean

Realization Relationship


Constraints Related terms: restriction, integrity rule,

condition, tagged value, stereotype, not dependency, invariant, assertion.

Definition:– A constraint is an expression which

restricts the possible contents, states or the semantics of a model element and which must always be satisfied.


Constraints Description:

– A constraint describes a condition or integrity rule.

Notation:– Constraints are enclosed in braces:

• { Constraint }


Tagged Values Related terms: property string, feature,

characteristic, constraint. Definition:

– Tagged values are user-defined, language and tool specific keyword/value pairs which extend the semantics of individual model elements with specific characteristic properties.


Tagged Values Description:

– Tagged values add specific additional properties to existing model elements. They detail the semantics of a model element and can influence code generation.

Notation:– Tagged values consist of a keyword and a

value, and are enclosed in braces.


Tagged Values Examples:

– {abstract}– {readonly}– {private}– {obsolete}– {version=2.1}

GeomFigure{abstract Version=1.3}

visible : Boolean {readonly}

display() {abstract}remove() {abstract}getPosition(): PointsetPosition(p: Point)

setPos(x,y) {obsolete}


Packages Related terms: category, subsystem Definition:

– Packages are collections of model elements of arbitrary types which are used to structure the entire model into smaller clearly visible units. A package defines a namespace, that is , the names of the elements within a package must be unique. Each model element can be referenced in other packages, but it belongs to exactly a single (home) package. The package can in turn contain packages. The top package includes the entire system.


Packages Description:

– Packages my contain different model elements, for example, classes and use cases. They may be hierarchically structured, with packages inside packages.

– Packages are built on the basis of logical or physical relationships.



– A model element can be contained in several packages, but each element has its home package. In all other packages, it can only be quoted in the form:

• PackageName::ClassName

– This creates dependencies between the packages: one package uses classes of another package.



– A good architecture leads to few dependencies between packages.

– Packages are also suitable working entities for project management and organization.


Packages Notation

– A package is represented as a folder. Inside this symbol, the name of the package is noted.

– The dependencies between packages are noted by a dashed arrow which points toward the independent package.

– It is also possible to represent generalization relations between packages if the model elements contained in the packages are generalizations or specializations of elements contained in other packages.


Packages Example ProductProduct

Online Tariffing

Online Tariffing

Tariffing Life

Tariffing Life

LifeLife

Contents&PL

Contents&PL

PartnerPartnerTariffing Contents

Tariffing Contents


Questions?

Documents

Enterprise & Application Frameworks