OCUP2I 01 Basic Structure

From Training Material
Jump to navigation Jump to search


<slideshow style="nobleprog" headingmark="⌘" incmark="…" scaled="false" font="Trebuchet MS" >

title
UML 2.5 Certification - OCUP 2 Intermediate Exam Preparation
author

Filip Stachecki (Filip@NobleProg.pl),presenter: Bernard Szlachta bs@nobleprog.co.uk

</slideshow>

Module 1. Basic Structure⌘

References⌘

UML 2.5 specification:

  • Chapter 6: Additional Information
    • BNF
  • Chapter 7: Common Structure
    • Namespaces
    • Types and Multiplicity
    • Constraints
    • Dependencies
  • Chapter 8: Values
    • Time
    • Intervals
  • Chapter 12: Packages
    • Packages
  • Chapter 20: Information Flows

BNF⌘

  • Backus-Naur Form (BNF) is a notation technique used to describe the syntax of languages like UML, programming languages, ...
  • BNF production rule:
 <symbol> ::= __expression__
  • The '::=' means that the symbol on the left must be replaced with the expression on the right.
  • __expression__ consists of one or more sequences of symbols
  • example:
 <name> ::= <first-name> <last-name>
  • Terminal symbols are elementary literal symbols of a language, like keywords
  • Non-terminal symbols are those symbols which can be defined/replaced.

BNF - sandbox⌘

<package-import> ::= ‘{import ’ <qualified-name> ‘}’ | ‘{access ’ <qualified-name> ‘}’

<stereotype> ::= “«” <label> [“,” <label>]* “»”
<label> ::= <keyword> | <stereotype-label>


<name> ::=[<attribute-name> ‘=’ ] [<collaboration-use> ‘.’] <interaction-name>
[‘(‘ <io-argument> [‘,’ <io-argument>]* ‘)’] [‘:’ <return-value>]
<io-argument> ::= <in-argument> | ‘out’ <out-argument>

<template-parameter> ::= <template-param-name> [‘:’ <parameter-kind> ] [‘=’ <default>]

<classifier-template-parameter> ::= <parameter-name> [ ‘:‘ <parameter-kind> ] [‘>’ <constraint>] [‘=’ <default>]
<constraint> ::= [‘{contract }’] <classifier-name>*
<default> ::= <classifier-name>

BNF in UML⌘

UML uses a variant of the BNF for textual notations to specify the legal formats:

  • All non-terminals are in italics and enclosed between angle brackets (e.g., <non-terminal>).
  • All terminals (keywords, strings, etc.), are enclosed between single quotes (e.g., ‘or’).
  • Non-terminal production rule definitions are signified with the ‘::=’ operator.
  • Repetition of an item is signified by an asterisk placed after that item: ‘*’.
  • Alternative choices in a production are separated by the ‘|’ symbol (e.g., <alternative-A> | <alternative-B>).
  • Items that are optional are enclosed in square brackets (e.g., [<item-x>]).
  • Where items need to be grouped they are enclosed in simple parenthesis; for example:
(<item-1> | <item-2>) *
  • signifies a sequence of one or more items, each of which is <item-1> or <item-2>.

BNF in UML examples⌘

<transition> ::== [<trigger> [‘,’ <trigger>]* 
                  [‘[‘ <guard>’]’] 
                  [‘/’ <behavior-expression>]]

Namespace⌘

  • Named Element represents an element that may have a name and a visibility
  • Namespace is a named element that can own other named elements
  • Each named element may be owned by at most one namespace
  • Namespace provides a container for named elements which are called its ownedMembers.
  • All the members of a namespace are distinguishable within it
  • A Namespace may also import NamedElements from other Namespaces which are members of the importing Namespace.

Distinguishability Rule⌘

  • Named Elements may appear within a Namespace according to rules that specify how one Named Element is distinguishable from another.
  • The default rule is that two members are distinguishable:
    • if they have different names or
    • if they have the same names, but their metaclasses are different and neither is a (direct or indirect) subclass of the other.
  • This rule may be overridden for particular cases, such as Operations that are distinguished by their signature.

Package⌘

  • Package is used to group elements, and provides a namespace for the grouped elements.
  • A Packageable Element is a Named Element that may be owned directly by a Package.
  • The visibility of a packagedElement may be indicated by preceding the name by a visibility symbol (‘+’ for public and ‘-’ for private).
  • Default Packageable Element visibility is public.
  • qualified name:
package name::element name
Package URI⌘

  • The URI can be specified to provide a unique identifier for a Package.
  • The URI should be unique and unchanged once assigned.
  • There is no requirement that the URI be dereferenceable.
Package nesting⌘

Package Import, Access⌘

A package import is defined as a directed relationship that identifies a package whose members are to be imported by a namespace.

Two types:

  • «import» for a public package import
    • transitive: if A imports B and B imports C then A indirectly imports C
  • «access» for a private package import
    • intransitive
Package Import, Access Example⌘

  • elements in Types are imported to ShoppingCart, and then further imported to WebShop
  • elements of Auxiliary are only accessed from ShoppingCart, and cannot be referenced from WebShop
Import, Access Example⌘

  • Elements in the Package Program to refer by name to the DataType Time in Types without qualification.
Import with aliasing⌘

  • Element Import combined with aliasing, meaning that the DataType Types::Real will be referred to by name as Double in the package Shapes.
Textual syntax for an Import⌘
  • It is possible to show a Package Import or Element Import by having a text that uniquely identifies the imported Package or Element within curly brackets either below or after the name of the Namespace, as an alternative to the dashed arrow.
<element-import> ::= ‘{element import ’ <qualified-name> ‘}’ | 
     ‘{element access ’ <qualified-name> ‘}’

<element-import> ::= ‘{element import ’ 
    <qualified-name> ‘ as ’ <alias> ‘}’ | 
    ‘{element access ’ <qualified-name> ‘as’ <alias> ‘}’
Textual syntax example⌘

Shapes::Circle {element import Types::Real}
Shapes::Circle {element access Types::Real}
Shapes::Circle {element import Types::Real as Double}
Shapes::Circle {element access Types::Real as Double}

Types and Multiplicity⌘


Types and Typed Elements⌘

  • A Type specifies a set of allowed values known as the instances of the Type.
  • A TypedElement is a NamedElement that may have a type.
  • Depending on the kind of Type, instances of the Type may be created or destroyed over time.

Multiplicities⌘

  • A MultiplicityElement is an Element that may be instantiated in some way to represent a collection of values.

Multiplicity syntax⌘

<multiplicity> ::= <multiplicity-range> [ [ ‘{‘ <order-designator> 
   [‘,’ <uniqueness-designator> ] ‘}’ ] |
   [ ‘{‘ <uniqueness-designator> [‘,’ <order-designator> ] ‘}’ ] ]

<multiplicity-range> ::= [ <lower> ‘..’ ] <upper>

<lower> ::= <value-specification>

<upper> ::= <value-specification>

<order-designator> ::= ‘ordered’ | ‘unordered’

<uniqueness-designator> ::= ‘unique’ | ‘nonunique’

Collection types for Multiplicity⌘

isOrdered and isUnique properties can be used to specify that the collection of values in an instantiation of a MultiplicityElement is of one of four types.

Constraints⌘

  • A Constraint is an assertion that indicates a restriction that must be satisfied by any valid realization of the model containing the Constraint.
  • If the constraint specification evaluates to true, then the Constraint is satisfied at that time.
  • If the specification evaluates to false, then the Constraint is not satisfied, and the realization of the model in which the evaluation occurs is not valid.
<constraint> ::= ‘{‘ [ <name> ‘:’ ] <boolean-expression> ‘ }’

Dependencies⌘

  • A Dependency signifies a supplier/client relationship between model elements where the modification of a supplier may impact the client model elements.
  • A Dependency is shown as a dashed arrow between two model Elements.
  • The model Element at the tail of the arrow (the client) depends on the model Element at the arrowhead (the supplier). The arrow may be labeled with an optional keyword or stereotype and an optional name.

Dependency kind⌘

Usage ⌘

  • A Usage is a Dependency in which one NamedElement requires another NamedElement (or set of NamedElements) for its full implementation or operation.
  • The Usage does not specify how the client uses the supplier other than the fact that the supplier is used by the definition or implementation of the client.

Instantiate ⌘

  • A usage dependency among classifiers indicating that operations on the client create instances of the supplier.

Abstraction ⌘

  • An Abstraction is a Dependency that relates two NamedElements or sets of NamedElements that represent the same concept at different levels of abstraction or from different viewpoints.
  • Depending on the specific stereotype of Abstraction, the mapping may be formal or informal, and it may be unidirectional or bidirectional.
  • Abstraction has predefined stereotypes (such as «Derive», «Refine», and «Trace») that are defined in the Standard Profile.

Manifestation⌘

  • An Artifact may embody, or manifest, a number of model elements.
  • Manifestation represents implementation of one or more model elements by an artifact.

Derive ⌘

  • Specifies a derivation relationship among model elements that are usually, but not necessarily, of the same type.
  • A derived dependency specifies that the client may be computed from the supplier.
  • The client may be implemented for design reasons, such as efficiency, even though it is logically redundant.

Refine ⌘

  • Specifies a refinement relationship between model elements at different semantic levels, such as analysis and design.
  • The mapping specifies the relationship between the two elements or sets of elements.
  • The mapping may be unidirectional or bidirectional.
  • Refinement can be used to model transformations from analysis to design and other such changes.

Trace ⌘

  • Specifies a trace relationship between model elements or sets of model elements that represent the same concept in different models.
  • Traces are mainly used for tracking requirements and changes across models.
  • As model changes can occur in both directions, the directionality of the dependency can often be ignored.
  • The mapping specifies the relationship between the two, and is usually informal.

Time⌘

  • UML uses simple model of time for situations in which the more complex aspects of time and time measurement can safely be ignored.
  • An event is a specification of something that may occur at a specific point in time.
  • Time is simply a coordinate that orders the occurrence of events. Every event occurrence can be given a time coordinate value and, based on this, can be said to be before, after or at the same time as another event occurrence.
  • A duration is the period of time between two event occurrences, computed as the difference of the time coordinates of those events.
  • An Observation denotes the observation of events that may occur relative to some other part of a model.
  • There are two kinds of Observations, TimeObservations and DurationObservations.

Intervals⌘

  • An Interval is a range between two values, primarily for use in Constraints that assert that some other Element has a value in the given range.
  • Intervals can be defined for any type of value, but they are especially useful for time and duration values as part of corresponding TimeConstraints and DurationConstraints.
<interval> ::= <min-value> ‘ ..’ <max-value>

Duration/Time Constraints on Sequence diagram⌘

A TimeConstraint of a single constrainedElement may be shown as a small line between the graphical representation of the constrainedElement and the textual representation of the TimeInterval of TimeConstraint.

Duration/Time Constraints on Timing diagram⌘

A DurationConstraint may also be shown using a graphical notation relating its constrainedElements. However, the notation used is specific to the diagram type on which the DurationConstraint appears.

Information Flows⌘

  • The InformationFlows package supports exchange of information between system entities at high levels of abstraction.
  • Information Flows describe circulation of information through a system in a general manner. They do not specify the nature of the information, mechanisms by which it is conveyed, sequences of exchange, or any control conditions.
  • Information moving along the information channel may be represented by abstract InformationItems and by concrete Classifiers.

Information Flow notation⌘

Attached to the dashed «flow» lines of an InformationFlow, with name displayed close to the appropriate «flow» line.

Attached to a realization of an InformationFlow’s information channel, a black-filled isosceles triangle on the information channel indicates the direction of information flow. When representing several InformationItems having the same direction, only one triangle is shown, with a nearby list of InformationItem names separated by commas.

When displayed independently of their InformationFlows, InformationItems may be represented as names inside rectangles. The rectangle is adorned with the «information» keyword or with a solid, black-filled isosceles triangle.

Retrieved from "https://training-course-material.com/index.php?title=OCUP2I_01_Basic_Structure&oldid=58156"