1. COMS W3156: Software Engineering, Fall 2001 Lecture #12: Design, Distributed Objects Janak J Parekh janak@cs.columbia.edu

2. 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

3. Next class Some more design, lead to implementation

4. Today’s class Design Distributed objects

5. 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

6. 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

7. Data Flow Analysis

8. Data Flow Analysis Example Determine modules, then refine stepwise

9. Data Flow Analysis Example (II)

10. 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*

11. Action-oriented design using Transactional Analysis Transaction = Operation Here, break into two pieces: analyzer and dispatcher

12. Bad example Too many modules do almost the same thing Needs reuse

13. 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

14. 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

15. Interaction diagrams Sequence or collaboration diagram We’re doing the former Can be used in specification, design, or both

16. Sequence diagrams

17. Collaboration diagrams

18. 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

19. Detailed class diagram (II)

20. Design product in terms of clients of objects

21. Detailed design Documentation Psuedocode How far should you go? Rose is your friend here…

22. Miscellany Formal design techniques –Correctness proving at a module level –Proof developed alongside with the detailed design Real-time design techniques –Distributed hardware –Synchronization

23. 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

24. 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

25. 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

26. Project How are you guys feeling about this thing? Dealing with deadbeat members of groups… New (hopefully last) modifications Prototype going up shortly

27. 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

28. 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

29. Distributed Object Mechanisms RMI: Remote Method Invocation: Sun “proprietary” –http://java.sun.com/j2se/1.3/docs/guide/rmi/index.htmlhttp://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.asphttp://www.microsoft.com/NTServer/techresources/app serv/COM/dcomtec.asp CORBA: Common Object Request Broker Architecture: standard –http://www.corba.org/http://www.corba.org/

30. 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.htmlhttp://java.sun.com/products/ejb/index.html http://java.sun.com/products/ejb/faq.html –CORBA Directory mechanisms, etc.

31. Other network programming models Event-based network programming –JMS –Siena –We’ll look at this in a later class, as well as recitation