Lösungsvorschlag Software Architecture FS08

Aus VISki
Version vom 22. Mai 2009, 07:06 Uhr von Legacy-Puddi (Diskussion | Beiträge) (Design by Contract (12 points))

Wechseln zu: Navigation, Suche

Modularity, ADT, Designy by Contract and Concurrency (8 points)

b

d

f: true, since the visitor needs to know implementation details of the objects it visits

b: true because class invariants are 'and'-ed, hence stronger assertions can be introduced

c

Design by Contract (12 points)

<eiffel> class

 BANK_ACCOUNT

feature withdraw(v: INTEGER) is

 require TRUE

do end

feature balance: INTEGER

end

class STUDENT_ACCOUNT inherit BANK_ACCOUNT redefine withdraw end

feature withdraw(v: INTEGER) is require else balance >= v do

 balance := balance - v

ensure

 balance_altered: balance = old balance - v

end

end

class B_A_NORMAL inherit BANK_ACCOUNT redefine withdraw end

feature withdraw(v: INTEGER) is require else balance > v + fee do

 balance := balance -v

ensure

 balance_altered: balance = old balance - v

end

feature

 fee: INTEGER

end

class B_A_BUSINESS inherit BANK_ACCOUNT redefine withdraw end

feature withdraw(v: INTEGER) is require else balance + credit >= v do

 balance := balance -v

ensure

 balance_altered: balance = balance - v

end

feature

 credit: INTEGER

end </eiffel>

Abstract Data Types (16 points)

Writing and ADT for CREDIT_CARD (7 points)

TYPES

CREDIT_CARD

FUNCTIONS

Creators:

new_card: INTEGER x INTEGER --|--> CREDIT_CARD

Queries:

limit: CREDIT_CARD ----> INTEGER

balance: CREDIT_CARD ----> INTEGER

Commands:

settle: CREDIT_CARD ----> CREDIT_CARD

charge: CREDIT_CARD x INTEGER --|--> CREDIT_CARD

PRECONDITIONS

P1 new_card (limit: INTEGER) require limit > 0

P2 charge (c: CREDIT_CARD; amount: INTEGER) require amount + balance(c) <= limit(c) and amount > 0

AXIOMS

A1 limit(new_card(l: INTEGER)) = l

A2 balance(new_card(l: INTEGER)) = 0

A3 limit(settle(c: CREDIT_CARD)) = limit(c)

A4 balance(settle(c: CREDIT_CARD)) = 0

A5 limit(charge(c: CREDIT_CARD; a: INTEGER)) = limit(c: CREDIT_CARD)

A6 balance(charge(c: CREDIT_CARD; a: INTEGER)) = balance(c: CREDIT_CARD) + a

Proof of balance properties (6 points)

Prove that balance(c) >= 0:

Base case: using A2, new_card(l)

Induction assumption: is a correct expression of type CREDIT_CARD of length , i.e.

Induction step:

using A4

using A6, induction assumption for , and P2 for


Prove that

Base case:

new_card(l: INTEGER)

using A2

using A1

Hence: using P1 for the last inequality

Induction assumption:

is a correct expression of type CREDIT_CARD and length , that is:

and

Induction step (reuse inequalities found for balance above):

(see above) and using A3 and induction assumption, hence


using P2

using A5

since above we could show that a stronger statement was true


Proof of sufficient completeness (3 points)

We need to show that calling both query functions on any valid CREDIT_CARD expression will either return a value (different from a CREDIT_CARD), or a CREDIT_CARD expression which is one element shorter than the original one.


limit(new_card(l)) = l, using A1

balance(new_card(l)) = 0, using A2


Let be a valid expression of type CREDIT_CARD and length n, then:

limit(charge(c_n, a)) = limit(c_n) using A5

balance(charge(c_n,a)) = balance(c_n) + a using A6

limit(settle(c_n)) = limit(c_n) using A3

balance(settle(c_n)) = 0 using A4


Design Patterns I (26 points)

Identify patterns (12 points)

Bridge

CAR_FACTORY is the abstraction and CAR_FACTORY_IMP the implementation.

This is a structural pattern.

The bridge pattern observes separate abstraction and implementation inheritance trees. An abstraction has-a implementation object, and this client-supplier relation is referred to as the bridge. All methods in the deferred abstraction class are implemented in terms of the deferred implementation (the deferred classes being the topmost super classes in the corresponding hierarchies). Subtypes of the abstraction super class implement their methods in terms of the methods provided by said abstraction super class.

Abstract Factory

APPLICATION receives a factory object and CAR_FACTORY is the corresponding factory which makes the products desired by APPLICATION.

This is a creational pattern.

The deferred class CAR_FACTORY, or CAR_FACTORY_IMP provides an interface for the production of a complex product consisting of a number of other products (i.e. a car consists of wheels, the body, and an engine). Each of these subproducts (wheels, body, engine) come in different concrete implementation forms. The abstract factory pattern is used to implement specific versions of the interface provided by the deferred or abstract factory, where concrete versions of the abstract factory chose a specific concrete subproduct to be produced.

Builder

BMW_FACTORY_IMP has a concrete builder object and CAR_BUILDER is a generic class which implements the builder.

This is a creational pattern.

Just like the abstract factory pattern, the builder pattern is concerned with assembling complex products from a number of subproducts, and making specific decisions about the corresponding concrete (implemented) subproducts. Contrary to the abstract factory pattern, the builder pattern does not return the final complex product immediately. Instead, as a last step, the client of the builder (BMW_FACTORY_IMP in this case) will call the feature last_car on the corresponding builder in order to obtain the final product.