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

• 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