COMS W3156:Software Engineering, Fall 2001

Lecture #12: Design, Distributed Objects

Janak J Parekh

janak@cs.columbia.edu

Administrativia• Specifications handed in (right?)• Design due in two weeks from about now• I was sick

– Late slides– JNDI/LDAP: starting later this week

• Requirements update– Post to webboard, will refine requirements in next 24

hours– Reinstate some dropped items

• Attacked in MapDelta• SendMap• Deltas now immediate, Go just makes you appear

Next class

• Some more design, lead to implementation

Today’s class

• Design

• Distributed objects

Design

• Three activities– Architectural design: high-level

• Action, Data, OO

– Detailed design: individual modules– Design testing

• Input: description of what the product will do

• Output: how the product will do it

Action-oriented design using Data Flow Analysis

• Data flow analysis: technique for determining modular decomposition with high cohesion

• Use data flow diagram and draw abstraction boundaries– Highest point of abstraction of input and output

• Not easily OOA-translatable

Data Flow Analysis

Data Flow Analysis Example

• Determine modules, then refine stepwise

Data Flow Analysis Example (II)

A note on module determination

• Cohesion: degree of interaction within a module

• Coupling: degree of interaction between two modules

• Informational cohesion: OOD helps with this

• Eventual goal: maximize cohesion, minimize coupling*

Action-oriented design using Transactional Analysis

• Transaction = Operation• Here, break into two pieces: analyzer and

dispatcher

Bad example

• Too many modules do almost the same thing

• Needs reuse

Data-Oriented Design

• Design product according to structure of data to be used

• Each procedure has same structure of data

• Less popular then action-oriented design

Object-Oriented Design

• Hybrid of action and data, as always

• Schach’s approach:– Interaction diagrams for each scenario– Detailed class diagram– Design product in terms of “clients of objects”– Proceed to detailed design

Interaction diagrams

• Sequence or collaboration diagram

• We’re doing the former

• Can be used in specification, design, or both

Sequence diagrams

Collaboration diagrams

Detailed class diagram

• Include all the “actions” methods– Where do they go?

• In the class itself• Client that sends a message to the class (Client =

Caller of the object• Responsibility-driven design

• State variables– Information hiding

• Elevator example, again

Detailed class diagram (II)

Design product in terms of clients of objects

Detailed design

• Documentation• Psuedocode• How far should you

go?• Rose is your friend

here…

Miscellany

• Formal design techniques– Correctness proving at a module level– Proof developed alongside with the detailed

design

• Real-time design techniques– Distributed hardware– Synchronization

Testing and tools

• Testing– Verify specifications are accurately and completely

incorporated into design

• CASE tools– lowerCASE and upperCASE again

– Rose Studio

• Metrics– Complexity of modules (cyclomatic complexity)

– Fan-in, fan-out

Challenges

• Doing too much– Coding the actual module

– Defeats the purpose: you want to focus on the functionality, not the precise mechanics

• Doing too little– Let programmers do detailed design

– Need to ensure interface correctness

• Brooks: lack of “great designers”: need to grow

What does this mean for you?

• Let’s look at the design assignment

• You’ll be doing a subset of a full OOD– Only two weeks…– Don’t need collaboration diagrams– Client call sequence less necessary here

Project

• How are you guys feeling about this thing?

• Dealing with deadbeat members of groups…

• New (hopefully last) modifications

• Prototype going up shortly

Distributed Objects

• We use XML, but wouldn’t it be nice to be able to actually call another object as if it were local?– Be it another program on same machine or over

a network

• Yes, you can do this: numerous ways• Original idea: RPC, or remote procedure

call

Distributed Objects (II)

• Two semantics: transfer the object/data across and use it, or transfer a proxy (stub/skeleton) across and have the computation done remotely

• Remote objects deal with the latter; XML/Serialization are the former

Distributed Object Mechanisms

• RMI: Remote Method Invocation: Sun “proprietary”– http://java.sun.com/j2se/1.3/docs/guide/rmi/index.html

• DCOM: Distributed Component Object Model: Microsoft “proprietary”– http://www.microsoft.com/NTServer/techresources/app

serv/COM/dcomtec.asp

• CORBA: Common Object Request Broker Architecture: standard– http://www.corba.org/

Implications

• Notion of “object server”: just a bunch of components ready to do your bidding

• Ultimate reuse mechanism• Object = service?

– Notion of services to the next generation

– Enterprise JavaBeans• http://java.sun.com/products/ejb/index.html,

http://java.sun.com/products/ejb/faq.html

– CORBA Directory mechanisms, etc.

Other network programming models

• Event-based network programming– JMS– Siena– We’ll look at this in a later class, as well as

recitation