Software Engineering for Smart Data Analytics & Smart Data Analytics for Software Engineering

User Tools

Site Tools


This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
teaching:lectures:oosc:2011:assignment_9 [2011/06/24 09:33]
teaching:lectures:oosc:2011:assignment_9 [2018/05/09 01:59] (current)
Line 1: Line 1:
 +====== Assignment 9: Object Design & OCL  ======
 +<​html><​font color=darkred></​html>​**Release date: Monday, 20.06.11 - Due date: Sunday, 26.06.11, 23:​59**<​html></​font></​html>​
 +===== Task 1: Mediator Pattern and Abstractness-Stability-Diagram =====
 +^**4 points**^
 +In this task you will learn how to use the Abstractness-Stability-Diagram to decide whether a certain design pattern is appropriate or not. As the pattern wasn't covered in the lecture we quickly introduce it here:
 +==== The Mediator Pattern ====
 +|{{  :​teaching:​lectures:​oosc:​2009:​mediatorpattern.jpg?​600 ​ |}}|
 +^  Class Diagram for the Mediator Pattern ​ ^
 +    * The Mediator pattern is a behavioural pattern.
 +    * Interaction between different colleague objects gets encapsulated in a mediator object.
 +    * The Mediator defines all possible interactions between the colleagues.
 +    * A ConcreteMediator then implements these interactions between the ConcreteColleagues.
 +    * If a ConcreteCollegue wants to communicate with another ConcreteCollegue they will not communicate directly, but through the ConcreteMediator.
 +    * So there is no coupling in between the ConcreteColleagues but only between the ConcreteColleagues and the ConcreteMediator.
 +==== Your Task ====
 +  -   Draw an **Abstractness-Stability-Diagram**((See design pattern slides.)) for the mediator pattern.
 +      * Is the position of every class unambiguous?​
 +      * Which assumptions do you have to make?
 +  -   Find an **example** where the usage of the mediator pattern **is useful**.
 +      * Draw a **class diagram** that shows which part of your example corresponds to the classes of the pattern shown above.
 +===== Task 2: OCL =====
 +^3 points^
 +Consider the //Queue// interface in the //​java.util//​ package. Write pre- and postconditions in OCL for the following operations:
 +  - //E remove()//: Retrieves and removes the head of this queue
 +  - //boolean offer(E o)//: Inserts the specified element into this queue if possible
 +  - //E peek()//: Retrieves but does not remove the head of this queue, returning null if this queue is empty
 +===== Task 3: OCL =====
 +^4 points^
 +Lets assume the bike rental outlets should also support motorbike renting. ​
 +We updated the analysis model accordingly,​ here is an excerpt:
 +{{:​teaching:​lectures:​oosc:​2011:​a09t03-ocl.png?​600| }}
 +  - Present and discuss the three core principles of "​Design by Contract"​.
 +  - The class Bikes is a list that only contains bikes. It is used to present vehicles rentable by all users. Write the two conditions with OCL. \\ **Hint**: The boolean function oclIsTypeOf(TypeName) checks if an instance is of type TypeName or not.
 +  - Discuss if the constraints of above subtask follow //contract inheritance//​.
 +  - Lets assume you want to use the Vehicles class for all logged-in users. So you restrict the use of the Vehicles::​add(Vehicle) method with the following precondition:​ \\ "if the vehicle is a motor bike the user must be older than 18 years and own a drivers license"​. Write this constraint as an OCL constraint.
teaching/lectures/oosc/2011/assignment_9.txt · Last modified: 2018/05/09 01:59 (external edit)

SEWiki, © 2019