COMS W3156: Software Engineering, Fall 2001

COMS W3156:Software Engineering, Fall 2001 Lecture #11: Requirements, Networking II Janak J Parekh janak@cs.columbia.edu

Administrativia • HW2 out • Specifications due on Sunday – will post submission instructions today • Sorry for late slides • About specifications grading…

Next class • Begin design document • Distributed objects

Today’s class • Requirements • Networking, continued (including concurrency) • Project (of course)

Requirements • In reality, this is not what we did: you’re not clients • Goal: elicit requirements from client and document them appropriately • What the client needs, not what they want

Requirements elicitation • Familiarity with application domain • Terminology  glossary • Interviews* • Difficult: clients busy/clueless • Structured vs. unstructured • Scenarios • Use-cases, but even more primitive • Storyboards

Requirements elicitation (II) • Questionnaires • Examine existing forms* • Video cameras

Requirements analysis • Determine functional vs. nonfunctional requirements • Traceability of statements • Priority setting • Refinement

Rapid prototype • Schach likes this: a lot • So much so that he omits much else after this point • Focus on “front-end”; store little or no data, stub away stuff • “Constructing models”

Rapid prototype (II) • Should be built for change • 4GL’s, Java useful • HTML, Visio • Determine human factor issues • User-friendliness • Domain specificity • Per-user tailoring • HCI: Human-to-Computer Interface

Dangers of rapid prototypes • Rapid prototype as specification technique • Written specifications ambiguous? • Legality as contract • Maintenance issues • Reusing rapid prototype: no specification, design, nuthin’ • “Homework model” • Fundamental problem: architecture of prototype sucks for maintenance (also, performance) • Excepting CASE-based situations

Rapid prototype implications • Feature-bloat • “Ooh, I want this, and this, and this”… • “You can do this, right? For free?” • Not necessarily the best requirements • Rapid prototype of our game: useful, but not nearly as complete • Management implications

Miscellany • Testing: make sure clients have been contacted, completeness • Metrics • Volatility: now and later • Usage of the rapid prototype • Object-oriented requirements • Not really any such thing, except rapid prototype • Air Gourmet: somewhat complicated example

Challenges • Users’ fear: job replacement, computers • Sabotage! • Negotiating: scale down the job • Extra additions later on • Lack of time • Flexibility and objectivity*

Networking II • Protocols • Tools • telnet • tcpdump • HTTP detail • Overview of some other protocols • Continue discussion on multithreading/multiprocessing • Networking and the project

Protocols • Difference between network and transport-layer protocols and application-layer protocols • IP, TCP • HTTP, SMB, XML • Telnet • “No” high-level protocol

Telnet • Client: can connect to telnet server, but it’s a basic terminal emulator • Server: basically serves up a shell • Not a protocol! • telnet www.columbia.edu 80 • etc.

Tcpdump • Misnomer: generic IP packet dumper • Extraordinarily powerful tool • Specify source, target, protocol type, etc. • You probably won’t need this, but should know that packet sniffing is important

HTTP • Hypertext Transfer Protocol, not to be confused with Hypertext Markup Language • Simple, convenient method for transferring files between one server and another • Text-based protocol: many are • Request-and-response based • Version history

HTTP request • One of several different commands • GET • PUT • POST • Associated URL or data

HTTP response • Status message • 200 • 404 • 500 • Other headers • Content-Type: MIME types • Content-Length • Data

HTTP miscellany • Traditionally one file per connection • HTTP/1.1 allows for better • Runs over TCP • Not just for the web • Microsoft: Instant Messaging in Exchange • RVP • Your project! • Questions?

Other protocols • SMTP: Simple Mail Transfer protocol • Also text-based • Example • FTP: File Transfer protocol • Actually a bit convoluted

Threads, redux • “Lightweight process” • Allows for information sharing in a program • In Java, always being used • Useful for blocking I/O • Two ways to create a thread in Java: • extend Thread; • implement Runnable.

Created, runnable, not runnable, or dead Not runnable: sleeping, suspended, condition-waiting, blocked on I/O Lifecycle of a thread

Synchronization • Deal with overwrite issues • Way of guaranteeing that only one thread will have access to something at a time • Can synchronize methods or blocks of code • Former just a tool of the latter (uses “this”) • synchronize(Map) { • do stuff to it • }

Other thread maintenance • Putting a thread to sleep • Useful if the thread has nothing to do • Much better than a while(i<1000000) loop • Thread.currentThread().sleep(ms) • Can interrupt sleep • Object can also wait • Similar effect, but on object, instead of thread • Can notify object

Timers • Very handy construct, new in JDK 1.3, adopted from Unix • Can tell a thread to run at predefined time intervals, or after a delay • java.util.Timer – check it out • Can you say “clock”?

Multithreaded server • Take a look at the example from the Java tutorial • Doing one for your homework

What does this mean for you? • Won’t be doing requirements, but understand some of the issues • HTTP very important in near-term • Threads important in medium-term

Project • Grading: how well are you answering the requirements? • May be putting out a rubric tomorrow; we’re not sure • Doesn’t have to be 40 pages • Anything else?

COMS W3156: Software Engineering, Fall 2001