1 / 34

COMS W3156: Software Engineering, Fall 2001

COMS W3156: Software Engineering, Fall 2001. Lecture #9: Classical specification, service discovery Janak J Parekh janak@cs.columbia.edu. Administrativia. v0.9 of the requirements out – we’ll talk about it shortly New specification document – better? Rose will be installed by Friday

hedy
Download Presentation

COMS W3156: Software Engineering, Fall 2001

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. COMS W3156:Software Engineering, Fall 2001 Lecture #9: Classical specification, service discovery Janak J Parekh janak@cs.columbia.edu

  2. Administrativia • v0.9 of the requirements out – we’ll talk about it shortly • New specification document – better? • Rose will be installed by Friday • Homework 1 submission instructions up • Webboard – use it! • http://groups.yahoo.com – private webboards • On asymmetric groups…

  3. Next class • Planning and Estimation • Read Schach 9, second part of MMM • HW2 will probably include a little of MMM • MS Project • Amazingly useful little program

  4. Today’s class • Talk a little about classical specifications • Informal techniques • Semiformal techniques • Formal techniques • Talk about service discovery, especially LDAP • Continue project discussion

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

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

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

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

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

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

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

  12. 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…

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

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

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

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

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

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

  19. 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)

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

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

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

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

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

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

  26. 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 = ?

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

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

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

  30. Project update • “v0.9” of requirements out • XML schema near-finalized • examples now available • actual document still being worked on • Not really use cases in there… don’t copy them! • Almost done with v0.99 • Schema changes…

  31. Schema changes • Reduced number of update messages, combined them into the MapDelta • Instances can have different ImageURL’s: custom “avatars” for players • Talking and attacking are separate now • Attacked gives result of an assault • ReplaceObject, ChangeStats, StatusMessage are gone: now embedded in MapDelta

  32. Frequently asked questions (I) • Objects • All have a unique ID: text followed by integer • World-specific, but see example • Have default URL for image • Clients may cache or request them all on startup • Components • All talk to LDAP • Talk XML (should I cover JDOM?) • Talk over network (sockets) • Will be multithreaded (design issue)

  33. FAQ’s (II) • GameEvent: turn-to-turn data • Clients/AI’s request moves • Server processes them, sends MapDeltas back • MapDelta sequence numbers • Yes, the full map does have “last sequence number” as part of it

  34. Let’s look at the examples

More Related