Architectural Models and Styles Component-Based Software Engineering ECE493-Topic 5 Winter 2007 Lecture 12 The Object Constraint Language (Part A)

Size: px

Start display at page:

Download "Architectural Models and Styles Component-Based Software Engineering ECE493-Topic 5 Winter 2007 Lecture 12 The Object Constraint Language (Part A)"

Clemence Lee
5 years ago
Views:

1 Component-Based Software Engineering ECE493-Topic 5 Winter 2007 Lecture 12 The Object Constraint Language (Part A) Ladan Tahvildari Assistant Professor Dept. of Elect. & Comp. Eng. University of Waterloo Architectural Models and Styles Architectural models are achieved in UML2 by: Component-and-connector diagrams, to define component relationships Interface descriptions, consisting of: method signatures (method names, input and output types) a semantics that tells us how methods work Architectural styles are defined in UML2 through: Explaining the kinds of components that are used in a style A semantics explaining how components and connections should behave Constraints telling us how the components are to be assembled 2 Informal Semantics and Constraints The semantics of architectures and architectural styles has been given informally (in English) Similarly, the constraints on component assembly for styles has also been given in English UML2 includes a range of languages for specifying aspects of semantics precisely: State-Charts Activity Graphs Swimlane Notation Object Constraint Language (OCL) Formal Semantics Advantages Informal English specifications can be ambiguous formal specifications leave less to interpretation The use of a standards such as UML means that formal specifications should eventually become commonly understood by any decent software development team Disadvantages English descriptions are easy to write and can be understood by any member of a development team who understands English English descriptions less cost for the software development process (it takes more time to define and comprehend formal semantics, and requires suitably qualified (more expensive) team members 3 4

2 The Object Constraint Language (OCL) OCL is used for adding important information to UML models A business modelling language used within the Syntropy (Booch method) in IBM until it was added to UML in 1997 OCL is used To add constraints, restrictions on values that formed part of an object-oriented model To state conditions on execution of a system To define business rules To define queries on the model so questions about a model can be answered automatically by executing an OCL query OCL2.0 is a new improved version. Building Better Models OCL is based on maths and first-order logic but is written like a programming language OCL expresses information that cannot be expressed well using other diagrams of UML Example1: Consider the UML class diagram below The association between class Flight and class Person indicates that a certain group of persons are passengers on a flight -- the association is (0..*) on the side of the Person class The diagram says that the number of passengers is unlimited In reality, the number of passengers will be restricted to the number of seats on the airplane that is associated with the flight OCL can be use to specify such a constraint OCL CONSTRAINT: Inequalities for defining constraints OO dot notation for navigating around a model Context Flight Inv: passengers->size() <= plane.numberofseats 5 6 Example 2 Any human reader of the model will undoubtedly assume that a number of rules must apply to this model. A person may have a mortgage on a house only if that house is owned by himor herself; one cannot obtain a mortgage on the house of one's neighbor or friend. The start date for any mortgage must be before the end date. The social security number of all persons must be unique. A new mortgage will be allowed only when the person's income is sufficient. Expression Syntax OCL Types Custom Defined by UML diagrams Predefined Integer, Real, String and Boolean Collection Sets, ordered sets, and sequences Similar operations on sets as those on collections in Java (that is, we can define iterator expressions like foreach) OCL expressions are logical expressions about elements of OCL types Boolean propositions (true or false values) 7 8

3 Boolean s Boolean Inequalities Implies or Notation (where a and b are Booleans) a implies b a or b Equals Not equals Notation (where a and b are strings, integers or reals) a = b a <> b and a and b Less than, less than or equal to a < b, a <= b exclusive or negation a xor b not a Greater than, greater than or equal to a > b, a >= b Example: Specifying part of a bank machine incorrect-password implies no-access and correct-password implies db-access 9 equals not equals a = b a <> b 10 Integers and Reals Strings Standard operations (-,+,-,*,/) Modulus a->mod(b) Absolute value a->abs() Maximum of a and b: a->max(b) Minimum of a and b: a->min(b) Examples: 12.max(33) = 33 is a true OCL expression 13.mod(2) = 1 is a true OCL expression Concatenation of a and b: a->concat(b) Size of a: a->size() a in lower case: a->tolower() b in upper case: b->toupper() Substring of a between i and j: a.substring(i,j) Examples: KCL.size() = 6 is a false OCL expression Computer.concat( Science ) = Computer Science is a true OCL expression 11 12

4 Set Collection Type s on Sets Needed to talk about groups of things in a model Syntax for declaring a set: Set { elt1, elt2, elt3, } Syntax for declaring a type set: Set(Type) Examples: Set { apple, orange, strawberry } is an element of type Set(String) Set {1, 2, 5, 88} is of type Set(Integer) Set {HotelRes, LoyaltyProgram, CreditCardBilling} is of type Set(Component) 13 s->size() s->intersection(t) s->union(t) s->count(o) s->includes(o) s->excludes(o) s->includesall(u) s->excludesall(u) s->isempty() s->notempty() Description Returns the number of elements in set s Returns the intersection of sets s and t Computers the union of s and t Number of times element o occurs in s True if o is an element of s True if o is not an element of s True if all elements of set u are in s True if all elements of set u are not in s True if s doesn t contain any elements True if s contains at least one element Examples - The followings are true OCL expressions about sets: Set{3,8,2,1}->size() = 4 Set{HotelRes,LoyaltyProgram}->excludes(CreditCardBill) Set{HotelRes,LoyaltyProgram}->union(Set{CreditCardBill}) = Set{HotelRes,LoyaltyProgram,CreditCardBill} 14 Iterators Some Important Iterators Over Sets Iterators are a powerful kind of OCL operation over collections used to perform operations repeatedly over each element of a collection of the form set->iterator(body) or set->iterator(variable body) each operation has an OCL expression as its parameter, called the body of the operation each operation also has an optional parameter, called an iterator variable used within the body s->any(expr) s->collect(expr) s->exists(expr) s->forall(expr) s->select(expr) s->reject(expr) Description expr is of the form variable body Returns a random element of set s for which expr is true Returns the set of objects that result from evaluating expr for each element in the source collection Returns true if there is at least one element in the source collection for which expr is true Returns true if expr is true for all elements in the source collection Returns a subset of s containing all elements for which expr is true Returns a subset of s containing all elements for which expr is false Iterators are not new an important programming concept that is borrowed by OCL Example - The followings are true OCL expressions: Set{4,24,2000,2005}->select(x:Integer x=>2000) = Set{2000,2005} Set{4,24,2000,2002}->forAll(x:Integer x.mod(2) = 0) Set{4,24,2000,2005}->exists(x.Integer x.mod(2) = 1) 15 16

5 Select Iterator Used when we are interested only in a special subset of a set The select operation allows us to specify a selection from the original set Example: Assume App.components consists of all components in an application architecture, and that s->isconnected(client) returns true if the component s is connected to the component client, then App.components->select (Client:Component IsConnected(C,Client)) Returns the subset of all components connected to Client forall operator The forall operation is used to specify that a certain condition must hold for all elements of a collection Example: if CarInsurance.customers is a list of customers of a car insurance company and c.age is the age of a customer c, then CarInsurance.customers-> forall(c:customer c.age <= 70) Specifies that all customers should be aged 70 or less Modelling with OCL Used for queries and constraints over UML2 models OCL syntax covers the following aspects of models: Initial values Contracts Constraints If you read the reference (the Warmer and Kleppe book from ), these aspects are detailed for class diagrams, not component diagrams; however the approach is similar To understand how OCL can be used to provide a formal semantics of components Context of OCL Expressions An OCL expression annotates a particular model entity (class, interface, datatype, component or entire application) this is called the context of the expression Annotation takes the following form: Context ModelEntity [init:/pre:/post: inv:] OCL expression about ModelEntity The context acts as a namespace for the OCL expressions The OCL expression can refer to aspects of the context: the attributes and methods of the class the provided interfaces of the component the required interfaces of the component 19 20

6 Types of Constraints An invariant is a constraint that states a condition that must always be met by all instances of the component, type, or interface. An invariant is described using an expression that evaluates to true if the invariant is met. Invariants must be true all the time. A precondition to an operation is a restriction that must be true at the moment that the operation is going to be executed. The obligations are specified by postconditions. A postcondition to an operation is a restriction that must be true at the moment that the operation has just ended its execution. Example 2 Any human reader of the model will undoubtedly assume that a number of rules must apply to this model. A person may have a mortgage on a house only if that house is owned by himor herself; one cannot obtain a mortgage on the house of one's neighbor or friend. The start date for any mortgage must be before the end date. The social security number of all persons must be unique. A new mortgage will be allowed only when the person's income is sufficient Example 2 Augmenting Model with OCL Expressions context Mortgage inv: security.owner = borrower context Mortgage inv: startdate < enddate context Person inv: Person::allInstances()- >isunique(socsecnr) context Person::getMortgage(sum : Money, security : House) pre: self.mortgages.monthlypayment- >sum() <= self.salary * 0.30 context Person::getMortgage(sum : Money, security : House) pre: security.value >= security.mortgages.principal->sum() 23

ECE750-Topic11: Component-Based Software Systems

ECE750-Topic11: Component-Based Software Systems Architectural Styles in CBSE Ladan Tahvildari, PEng Associate Professor Software Technologies Applied Research (STAR) Group Dept. of Elect. & Comp. Eng.