Enterprise & Application Frameworks

  • View
    18

  • Download
    0

Embed Size (px)

DESCRIPTION

Enterprise & Application Frameworks. Dr. M.E. Fayad, Professor Computer 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. Roles. The Role Object Pattern - PowerPoint PPT Presentation

Text of Enterprise & Application Frameworks

  • Enterprise & Application FrameworksDr. M.E. Fayad, ProfessorComputer Engineering Department RM#College of EngineeringSan Jos State UniversityOne Washington SquareSan Jos, CA 95192-0180 URL: http://www.cmpe.sjsu.edu/~fayad

    L6-S*Modeling

    RolesThe Role Object Patternhttp://www.riehle.org/papers/1997/plop-1997-role-object.pdf

    L6-S*Modeling

    Class Diagrams

    L6-S*Modeling

    AcknowledgementsDeveloping Software With UML:Object Oriented Analysis and Design in PracticeBy: Bernd OestereichUsing UML: Software Engineering with Objects and ComponentsBy: Rob Pooley and Perdita Stevens

    L6-S*Modeling

    ClassesRelated terms: type, object factoryDefinition: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.

    L6-S*Modeling

    ClassesDescription: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.

    L6-S*Modeling

    ClassesNotation: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.

    L6-S*Modeling

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

    L6-S*Modeling

    ClassesOperations: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

    L6-S*Modeling

    ClassesExample:

    Circleradius {radius>0}center: Point = (10,10)display()remove()setPosition(pos: Point)setRadius(newRadius)Class NameAttribute nameAttribute typeOperationsConstraintInitial ValueParameter(Name: Type=Initial Value)

    L6-S*Modeling

    Abstract ClassesRelated Terms: virtual classDefinition: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.

    L6-S*Modeling

    Abstract ClassesDescription: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.

    L6-S*Modeling

    Abstract ClassesNotation: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.

    L6-S*Modeling

    Abstract ClassesExample:

    GeomfigureCircleRectangleTriangleAbstract ClassConcrete Classes

    L6-S*Modeling

    ObjectsRelated terms: instanceDefinition: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.

    L6-S*Modeling

    ObjectsDescription: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.

    L6-S*Modeling

    ObjectsNotationObjects 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.

    L6-S*Modeling

    ObjectsExample:

    aCircle: Circleradius = 25center = (10,10)Instance nameAttribute namesClass nameAttribute values

    L6-S*Modeling

    AttributesRelated terms: data element, instance variable, variable, memberDefinition: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.

    L6-S*Modeling

    DescriptionEach 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.

    L6-S*Modeling

    AttributesNotation:Attribute names begin with lower-case characters and class names with upper-case one, while tagged values and constraints are enclosed in bracesattribute : Package::Class =InitialValue {PropertyValue} {Constrant}

    L6-S*Modeling

    AttributesExamples:name: String = UnknowninvoiceDate : Date = todaybirthDate : Datecolor : {red, blue, green}radius : Integer = 25 {readonly} {radius>0}

    L6-S*Modeling

    Operations, MethodsRelated terms: method, service procedure, routine function, messageDefinitions: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.

    L6-S*Modeling

    Operations, MethodsDescriptionA 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).

    L6-S*Modeling

    Operations, MethodsDescription (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.

    L6-S*Modeling

    Operations, MethodsNotationThe 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)}

    L6-S*Modeling

    Operations, MethodsNaming ConventionsBe 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!

    L6-S*Modeling

    StereotypesRelated terms: usage context, constraintDefinition: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.

    L6-S*Modeling

    StereotypesDescription:A stereotype is UMLs 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 elementSome stereotypes are predefined in UML; they are automatically available and cannot be redefined. , , and are examples.

    L6-S*Modeling

    StereotypesDescription: (continued)Stereotypes can be defied to express whatever extra classification may be deemed useful. For example, if an application had persistent classes, the stereotype could be defined to show which classes are persistent.

    L6-S*Modeling

    StereotypesNotation: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: , , , and .

    L6-S*Modeling

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

    L6-S*Modeling

    Interfaces, Interface ClassesDefinition: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.

    L6-S*Modeling

    Interfaces, Interface ClassesDescription: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 i