1. Software Engineering 3156 8-Oct-01 #10: Classical Specs & Service Discovery Phil Gross

2. 2 Administrivia Version 1.0 up Keep the webboard stuff going TAs

3. 3 A Bit on Chapter 9 Size/cost estimation is painful Obviously necessary in the real world We’re punting Take 4156 to learn details

4. 4 Metrics LOC – Programming language dependent – Comments? – Tools/throwaway? – Generated code? – How do you estimate LOC?

5. 5 Other Metrics Functions points – Data processing oriented – Input, output, and master files – Degrees of influence, Technical Complexity Factors…

6. 6 Actual Estimation COCOMO and COCOMO II Based on statistics gathered from real projects Awful, but the best we’ve got Aimed at huge software projects

7. 7 Specification document Contract between client and developer Acceptance criteria – Solution strategy – Keep track of which solutions are kept and those discarded for later justification Cost-benefit analysis

8. 8 Informal specifications Xhosa!? Mostly prose Easy to screw up and make ambiguous: English sucks My MTA example from second class

9. 9 Structured systems analysis Start with Data Flow Diagrams (DFD’s) Show what happens, not how Use stepwise refinement: start with high-level DFD and work down from there UML state diagram generalization of this

10. 10 DFD After several iterations, quite detailed, but customer can still understand Less data-hiding than object-oriented mechanisms Still useful for formalized contracts

11. 11 Remaining structured systems analysis steps Decide, from DFD, what to computerize Determine details of data flows Define process logic Define data stores Define physical resources (files, organization, storage medium, etc.) Determine I/O specs Determine sizing (CPU, size) Determine hardware requirements

12. 12 Other semiformal techniques PSL (problem statement language) and PSA (problem statement analyzer) – computer-aided SADT (box-and-arrow-based structural analysis and design technique): more refinement than DFD SREM (Software Requirements Engineering Method, pronounced “shrem”): specify conditions for actions to occur; based on finite state machines; has been used for C 3 I applications by the air force

13. 13 Entity-relationship modeling (ERM) Looks like a class diagram, no? Predecessor, in a sense

14. 14 Finite state machines Precursor of UML state diagrams Still used in many low-level specification areas Notion of states and transitions formally specified Useful in menu-driven UI’s, system design Above refers to 3-position combo lock Huge example in Schach for elevators Comp Org…

15. 15 Petri nets Problem: state machines are weak at handling timing issues Can use state charts (or state diagrams) Petri nets are state-based, but have tokens in states to allow multiple transitions to happen at the same time (concurrency modeling)

16. 16 Z Zed, not zee! Rather formalized specification language Difficulty outside the scope of this class – Utilizes set theory, functions, and first-order logic We’re not covering this, but take a peek in the book

17. 17 Other formal techniques Event-based specification: Communicating Sequential Processes [Hoare, 1985] – A little too complex for us – Nevertheless, we want to consider event models; they’ve become very common Many others (Anna, Gist, VDM) Active theoretical research (woohoo!)

18. 18 Miscellany Testing – Walkthroughs – Inspection against checklist – Correctness-proving for formal specifications Metrics – Size of DFD, data dictionary, etc. Challenge – Find something that the customer understands yet is good enough for a contract – Sometimes this is impossible: need technical people at customer

19. 19 Service Discovery It’s no longer just the web anymore Abstraction of service from network node (or computer) Goal: find a service without hardcoding where it is Use DNS, LDAP, others

20. 20 DNS: Domain Name Service Primary purpose: “discover” machines – “Address record”: for example, www.cs.columbia.edu = 128.59.16.149 – Equivalent to an address book Secondary purpose: advertise mail servers – “Mail server”, or MX record: cs.columbia.edu’s mail is primarily handled by ober.cs.columbia.edu

21. 21 DNS (II) More recent: user-definable services, using SRV records – Domain controllers – Telephony servers – Generally done on a domain basis: “here’s the service provider for domain X” Tools for DNS – nslookup – host – numerous API’s (resolver built into sockets)

22. 22 Others (I) SIP: Session Initiation Protocol: Invented Here!* – http://www.cs.columbia.edu/~hgs/sip http://www.cs.columbia.edu/~hgs/sip – Basic idea: how to find someone to communicate with – Primarily for telephony applications (Caller-ID, Call- Forwarding, etc.) Jini: distributed object-level service discovery – Appliance-aware services: embedded Java

23. 23 Others (II) SLP (Service Location Protocol) – IETF attempt, generalized SIP – Less successful so far: maybe IPv6? NIS (Network Information Service) – Primarily user authentication, but can generalize – “Mirror” /etc files

24. 24 Challenges for service discovery Running out of IP addresses to host these services on – IPv6 Lack of a standardized mechanism – Each service discovery mechanism has its own target applications Mobile services – Wireless technology: “find” the service physically

25. 25 LDAP: Lightweight Directory Access Protocol One popular solution to general discovery requirements Very generalized white-pages mechanism – User-definable “schemas” – Common applications are network nodes and users Based on DAP, X.500 Extremely popular – ldap.columbia.edu: try it out… – Lookups are very fast

26. 26 LDAP (II) We will be using LDAP for several purposes – Discovering server and AI programs on the network – Keeping track of basic user authentication and information LDAP server already set up on softe.cs.columbia.edu – Code examples will be covered in next week’s recitation – Don’t need the code for specification document

27. 27 LDAP 4 U We have three schemas (directories) in our LDAP setup: – Services – Actors – Actor-world state settings

28. 28 Services Allow servers and AI’s to be discovered Fields – Map ref: string – unique identifier, based on group # – World name: string – Server IP: string – Server port: integer – Extensions field: string – Server type: char 0 = world, 1 = AI, 2 = ?

29. 29 Actors Only game servers can read/write (special password) Fields – ActorRef: string – user ID – ImageURL: string – HP: integer – XP: integer – Gold: integer – Encrypted password: string

30. 30 Actor states per world Separate table/schema: multiple entries per actor – Fake relational database Servers read/write on entry/exit Fields – ActorRef: string – WorldRef: string – LocationX: int – LocationY: int – Status: long – WorldInstance: long – unique timestamp

31. 31 What does this mean for you? Basic understanding of what “contacting LDAP server” means – Looking up data from and writing data to a table You’re not doing much of any of the classical specification models – Be aware of them, however: still part of curriculum