COMS W3156: Software Engineering, Fall 2001 Lecture #9: Classical specification, service discovery...
-
date post
20-Dec-2015 -
Category
Documents
-
view
228 -
download
1
Transcript of COMS W3156: Software Engineering, Fall 2001 Lecture #9: Classical specification, service discovery...
COMS W3156:Software Engineering, Fall 2001
Lecture #9: Classical specification,
service discovery
Janak J Parekh
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…
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
Today’s class
• Talk a little about classical specifications– Informal techniques– Semiformal techniques– Formal techniques
• Talk about service discovery, especially LDAP
• Continue project discussion
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
Informal specifications
• Xhosa!?
• Mostly prose
• Easy to screw up and make ambiguous: English sucks
• My MTA example from second class
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
DFD
• After several iterations, quite detailed, but customer can still understand
• Less data-hiding than object-oriented mechanisms
• Still useful for formalized contracts
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
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
Entity-relationship modeling (ERM)
• Looks like a class diagram, no?
• Predecessor, in a sense
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…
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)
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
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!)
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
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
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
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)
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
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
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
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
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
LDAP 4 U
• We have three schemas (directories) in our LDAP setup:– Services– Actors– Actor-world state settings
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 = ?
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
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
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
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…
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
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)
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
Let’s look at the examples