eva trosborgslide no.: 1elaboration iteration 2 object oriented design and more patterns fall 2005...

Eva Trosborg Slide no.: 1Elaboration Iteration 2

Object Oriented design and more patterns

Fall 2005

UML Tools and UML as Blueprint (chapter 22, p 397)Guidelines p 404Iteration 2 – More Patterns (chapter 24, p 407)GRASP: More Objects with Responsibilities (chapter 25, p 413) Applying GoF Design Patterns (chapter 26, p 435)

by

Eva Trosborg


Sources to this lesson

• Supported by Larman Chapter 22 - 26


Ways to apply UML

• UML as sketch

• UML as blueprint

• UML as programming language

What is the current status?

Which problems / challenges can you see ?


Forward, Reverse, and Round-Trip Engineering

• Forward engineering– Generating code from diagrams

• Reverse engineering– Generating diagrams from code

• Round-trip engineering– Generating in either direction and can

synchronize between UML diagrams and code

• Status ? Still long way to go


Report on Valuable UML tool features?

• “get in the way” more than help ?

• Reverse engineering as a Visualization learning aid to understand existing code.

• Future ?

SW tools are fast-changing

www.objectsbydesign.com/tools/umltools_byCompany.html


Any sufficiently advanced bug is indistinguishable from a feature – Rich Kulawiec

Generalization• Is the activity of identifying commonality

among concepts and defining superclass (general concept) and subclass (specialized concept) relationships

Guideline

Create a conceptual subclass of a superclass when:

1. The subclass has additional attributes of interest

2. The subclass has additional associations of interest

3. The subclass concept is operated on, handled, reacted to, or manupulated differently than the superclass or other superclasses, in noteworthy ways


Fig. 32.1 Generalization-specialization hierarchy

CashPayment

CreditPayment

CheckPayment

Paymentsuperclass - more general concept

subclass - more specialized concept

these are conceptual classes, not software classes


Fig. 32.6 Legal conceptual class partition, but is it useful ?

MaleCustomer

FemaleCustomer

Customer Correct subclasses.

But useful?


Fig. 2.4 Evolutionary analysis and design – the majority in early iterations

Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5

20%

2%

requ

irem

ent

s

soft

war

e

30%

5%re

quire

me

nts

soft

war

e

50%

8%

90% 90%

20%10%

requirements workshops

Imagine this will ultimately be a 20-iteration project.

In evolutionary iterative development, the requirements evolve over a set of the early iterations, through a series of requirements workshops (for example). Perhaps after four iterations and workshops, 90% of the requirements are defined and refined. Nevertheless, only 10% of the software is built.

1 2 3 4 5 ... 20

week 1

M T W Th F

week 2

M T W Th F

week 3

M T W Th F

kickoff meeting clarifying iteration goals with the team. 1 hour

team agile modeling & design, UML whiteboard sketching.5 hours

start coding & testing

a 3-week iteration

de-scope iteration goals if too much work

final check-in and code-freeze for the iteration baseline

demo and 2-day requirements workshop

next iteration planning meeting;2 hours

Most OOA/D and applying UML during this period

Use-case modeling during the workshop


From Iteration 1 -> 2

• When iteration-1 ends– All SW has been tested: unit, acceptance, load, usability … (UP idea is to

do early, realistic, and continuous verification of quality and correctness)– Customers engaged in evaluating the partial system to obtain feedback for

adaptation and clarification of requirement and see early visible progress– The system has been completely integrated and stabilized as a base lined

internal release– An iteration planning meeting to resolve questions and identify major

tasks in the next iteration– Reverse engineering diagrams from code– Usability analysis and engineering for the UI (outside scope)– Database modeling– 2 days requirement workshop (near the end of iteration-1 and again near

the end of iteration-2)

Use of patterns to create a solid design


The Agile Principles

• Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan


Principles behind the Agile Manifesto

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

• Business people and developers must work together daily throughout the project. • Build projects around motivated individuals. Give them the environment and support they

need, and trust them to get the job done. • The most efficient and effective method of conveying information to and within a

development team is face-to-face conversation. • Working software is the primary measure of progress. • Agile processes promote sustainable development. The sponsors, developers, and users

should be able to maintain a constant pace indefinitely. • Continuous attention to technical excellence and good design enhances agility. • Simplicity - the art of maximizing the amount of work not done - is essential. • The best architectures, requirements, and designs emerge from self-organizing teams. • At regular intervals, the team reflects on how to become more effective, then tunes and

adjusts its behavior accordingly.


Iteration 2 – More Patterns

• As from the figures in Larman


Design Patterns• How to choose (or construct) objects to be

responsible to carry out operations?– What rational principles can be methodically applied to

guide the design of responsibilities and object interactions?

– “It seems right” or “it’s natural” is not good enough!!! Especially for novices

• Design Pattern– Principles or idioms of design codified in a structured

format describing the problem it solves and a solution for the problem


Gang of Four

• The GoF book– Gamma, E., Helm, R., Johnson, R., and

Vlissides, J., Design Patterns, Addison-Wesley, 1995.

• A Related Book on Analysis Patterns– Fowler, M., 1996, Analysis Patterns: Reusable

Object Models, Addison-Wesley, 1996.


Singleton• (Many) classes need

access to a single object– Could pass the object as

a parameter through (possibly) many messages

– Alternatively, globally reference the one object

Store

addressname+ $instance : Store

$instance()

aCreditPayment:"Credit Payment"

theStore:Store

Store

: authorizec(c)

2: cas := getCreditAuthorizationService(c)

1: theStore := instance()

A class,not an object


Singleton• Problem

– Exactly one instance of a class is allow; it is a “singleton”. – Many objects need to access the singleton

• Solution– In the singleton class, define a method that returns the one singleton

class instance• In languages that do not provide for class methods, instead use a global

function

– Other objects can request the singleton from the class

• Motivation– Class (type definitions) are generally global in scope for most

languages• with the exception of import/export

– Asking the class for its instance does not increase coupling


Remote Proxy• Problem

– How to represent non-local components?• E.g., Credit Card Authorization Service, Database, etc.

• Solution– Create a class that “stands in” for the remote class

aCreditPayment:"Credit Payment" cas:AuthorizationService

theStore:Store

Store 3: authorize(c)

: authorizec(c)

2: cas := getCreditAuthorizationService(c)

1: theStore := instance()


Remote Proxy

• Problem– The system must communicate with a component in another address

space (e.g., on another machine). Who should be responsible for contacting the component?

• Solution– Make a local class the represents the remote component. (Local

objects should think of it as actually being the component.) This local proxy for the remote object handles all interaction with the actual component.

• Motivation– Localize remote access behavior (which is likely to change)


Proxy

• Problem– Direct access to a component is not desired or possible.

• Solution– Make a local class the represents the component. (Local objects should

think of it as actually being the component.) This local proxy for the remote object handles all interaction with the actual component.

• Motivation– Localize access behavior (which is likely to change)


Facade & Device Proxy

• Problem– How can object-oriented system be cleanly connected to non-object-

oriented (legacy) systems?– How can hardware devices or operating system functions be

represented?

• Solution– Create a class that encapsulates the behavior of the legacy system or

device

aCAS:CreditAuthorizationService aModem:Modem1: dial(phoneNumber)

Modem

dial()

persistent


Facade & Device Proxy

• Facade Proxy– Problem

• How can a common interface to a variety of functions or interface (such a provided by a legacy system) be provide within an object-oriented system?

– Solution• Define a single class that encapsulates the behavior of all the functions

• Device Proxy– Problem

• How can an interface to a hardware device be provided within an object-oriented system?

– Solution• Define a single class that encapsulates the behavior of the device

eva trosborgslide no.: 1elaboration iteration 2 object oriented design and more patterns fall 2005...

Documents

elaboration iteration

eva trosborgslide

end of iteration

eva trosborg slide

uml uml

iteration planning meeting

uml diagrams

solid design slide