Software Engineering 3156

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

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

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 3

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

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

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 6

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 7

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

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 9

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

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 11

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 C3I applications by the air force 12

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

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

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) 15

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 16

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!) 17

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 18

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 19

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 20

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) 21

22. Others (I) • SIP: Session Initiation Protocol: Invented Here!* • 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 22

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 23

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 24

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 25

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 26

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

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 = ? 28

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 29

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 30

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 31