1 / 48

Enterprise & Application Frameworks

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

tola
Download Presentation

Enterprise & Application Frameworks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 SJSU – CmpE

  2. Roles • The Role Object Pattern http://www.riehle.org/papers/1997/plop-1997-role-object.pdf SJSU – CmpE M.E. Fayad

  3. Class Diagrams SJSU – CmpE M.E. Fayad

  4. 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 SJSU – CmpE M.E. Fayad

  5. 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. SJSU – CmpE M.E. Fayad

  6. 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. SJSU – CmpE M.E. Fayad

  7. 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. SJSU – CmpE M.E. Fayad

  8. 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. SJSU – CmpE M.E. Fayad

  9. 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 SJSU – CmpE M.E. Fayad

  10. Classes • Example: Class Name Constraint Circle radius {radius>0} center: Point = (10,10) Initial Value Attribute name display() remove() setPosition(pos: Point) setRadius(newRadius) Attribute type Parameter (Name: Type=Initial Value) Operations SJSU – CmpE M.E. Fayad

  11. 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. SJSU – CmpE M.E. Fayad

  12. 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. SJSU – CmpE M.E. Fayad

  13. 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. SJSU – CmpE M.E. Fayad

  14. Abstract Classes • Example: Geomfigure Abstract Class Triangle Circle Rectangle Concrete Classes SJSU – CmpE M.E. Fayad

  15. 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. SJSU – CmpE M.E. Fayad

  16. 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. SJSU – CmpE M.E. Fayad

  17. 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. SJSU – CmpE M.E. Fayad

  18. Objects • Example: aCircle: Circle Class name Instance name radius = 25 center = (10,10) Attribute values Attribute names SJSU – CmpE M.E. Fayad

  19. 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. SJSU – CmpE M.E. Fayad

  20. 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. SJSU – CmpE M.E. Fayad

  21. 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} SJSU – CmpE M.E. Fayad

  22. Attributes • Examples: • name: String = ‘Unknown’ • invoiceDate : Date = today • birthDate : Date • color : {red, blue, green} • radius : Integer = 25 {readonly} {radius>0} SJSU – CmpE M.E. Fayad

  23. 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. SJSU – CmpE M.E. Fayad

  24. 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). SJSU – CmpE M.E. Fayad

  25. 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. SJSU – CmpE M.E. Fayad

  26. 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)} SJSU – CmpE M.E. Fayad

  27. 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! SJSU – CmpE M.E. Fayad

  28. 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. SJSU – CmpE M.E. Fayad

  29. 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. SJSU – CmpE M.E. Fayad

  30. 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. SJSU – CmpE M.E. Fayad

  31. 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>>. SJSU – CmpE M.E. Fayad

  32. 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>> SJSU – CmpE M.E. Fayad

  33. 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. SJSU – CmpE M.E. Fayad

  34. 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. SJSU – CmpE M.E. Fayad

  35. 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. SJSU – CmpE M.E. Fayad

  36. Interfaces, Interface Classes • Example: Realization Relationship String <<interface>> Sortable isEqual(Object):Boolean isGreater(Object):Boolean isEqual(String):Boolean isGreater(String):Boolean Length():Integer SJSU – CmpE M.E. Fayad

  37. 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. SJSU – CmpE M.E. Fayad

  38. Constraints • Description: • A constraint describes a condition or integrity rule. • Notation: • Constraints are enclosed in braces: • { Constraint } SJSU – CmpE M.E. Fayad

  39. 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. SJSU – CmpE M.E. Fayad

  40. 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. SJSU – CmpE M.E. Fayad

  41. Tagged Values • Examples: • {abstract} • {readonly} • {private} • {obsolete} • {version=2.1} GeomFigure {abstract Version=1.3} visible : Boolean {readonly} display() {abstract} remove() {abstract} getPosition(): Point setPosition(p: Point) setPos(x,y) {obsolete} SJSU – CmpE M.E. Fayad

  42. 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. SJSU – CmpE M.E. Fayad

  43. 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. SJSU – CmpE M.E. Fayad

  44. Packages • Description: • 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. SJSU – CmpE M.E. Fayad

  45. Packages • Description: • A good architecture leads to few dependencies between packages. • Packages are also suitable working entities for project management and organization. SJSU – CmpE M.E. Fayad

  46. 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. SJSU – CmpE M.E. Fayad

  47. Packages • Example Product Online Tariffing Contents&PL Tariffing Contents Partner Tariffing Life Life SJSU – CmpE M.E. Fayad

  48. Questions? SJSU – CmpE M.E. Fayad

More Related