1 / 31

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.

anaya
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 #11: Requirements, Networking II Janak J Parekh janak@cs.columbia.edu

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

  3. Next class • Begin design document • Distributed objects

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  26. 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 • }

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

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

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

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

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

More Related