1 / 41

Software Engineering 3156

Software Engineering 3156. 17-Sep-01 Class #4: Tools and Networking Phil Gross. Administrivia. Recitations M: 5:30-6:30 CEPSR 415 T: 2:30-3:30 CEPSR 415 Except next Monday, 24 September 6:15-7:15 IAB 410 Looking at early Friday afternoon. More Admin Stuff. Groups

hashim-lucas
Download Presentation

Software Engineering 3156

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. Software Engineering 3156 17-Sep-01 Class #4: Tools and Networking Phil Gross

  2. Administrivia • Recitations • M: 5:30-6:30 CEPSR 415 • T: 2:30-3:30 CEPSR 415 • Except next Monday, 24 September • 6:15-7:15 IAB 410 • Looking at early Friday afternoon 2

  3. More Admin Stuff • Groups • You all submitted, right? • More on projects • Each group doing complete component • AI fun 3

  4. Review • CMM – Five levels • ISO 9000 / SPICE • Lifecycles – all basically variations on waterfall • XML 4

  5. XML • Structured form of communication • How components will communicate • Freeform HTML • Grammar and validation • DOM and SAX 5

  6. History • First came SGML • Then HTML • HTML became hugely successful • XML is an attempt to recapture most of the power of SGML, without all the hassle 6

  7. Example XML Message • Note: lots of examples from either http://www.w3schools.com or http://www.w3.org <?xml version="1.0"?> <note> <to>Tove</to> <from>Jani</from> <heading>Reminder</heading> <body>Don't forget me this weekend!</body> </note> 7

  8. Differences From HTML • Stricter • All tags closed • Tags are case sensitive • All attributes must be quoted • Avoid attributes, except for • IDs • True tag modifiers 8

  9. Grammar Specification • DTD • Schema • We’re using schemas • Much nicer • Consistent: XML themselves • Grammars explain structure to developers • Can also be used for automated validation • Sloooooow 9

  10. XML Tools • Many • Apache tools among the most popular • Open source • C++ and Java versions available • Xerces • DOM: suck into memory, give back tree structure • SAX: parse sequentially, return events 10

  11. More XML • JDOM • XSLT • SOAP • http://xml.apache.org/ • http://www.jdom.org • http://www.megginson.com/SAX/ 11

  12. Tool time! • Two kinds of tools: • Analytical tools/techniques • CASE tools, e.g., real products • We’ll be discussing these throughout the course, and we’ll be adding our own 12

  13. Analytical tools • Three in particular discussed here • Stepwise refinement: identify basic tasks, and refine the steps involved iteratively • Good general concept useful in many different engineering phases • Cost-benefit analysis • Metrics (next slide) • We’ll go into these more next class 13

  14. CASE tools (I) • Computer-Aided Software Engineering • Quite a few categories; we’ll be dealing with several over the course of the semester • Scope: tool/workbench/environment • Not everything fitsprecisely into thisscoping 14

  15. CASE tools (II): Schachisms • upperCASE: front-end; lowerCASE: back-end • Workbenches • Data dictionary: keep track of data in product; consistency checker • Report and screen generators • Environments • Full software process • Generally used mostly in large companies/projects 15

  16. CASE scope • Programming-in-the-small is what you’ve done: code-compile-run-repeat • Better way? • Programming-in-the-large: module-level • Programming-in-the-many: team-oriented (both large and small) • Source editors that can do syntax checking: structure editor • Automation tools to build: make • Source-level debugging, tracing: gdb, jdb • Versioning and configuration control… 16

  17. Versioning control • Versioning: deal with many people and many versions of code • People work on their local computers, yet code needs to be shared amongst all • Versioning software allows for code to coexist without overwriting people’s work • Automated: cp, tar, zip doesn’t quite cut it • cvs: we’re getting to this shortly 17

  18. Configuration control • Even when versioning is done, a product may be run in many configurations • Schach defines this as a “set of versions” on files • Set up a “stable” baseline against which variations are tested • Freeze code to be altered • Also actual software configuration 18

  19. CVS • Concurrent Versions System • www.cvshome.org has the lowdown • Supported on Win32, UNIX and other platforms: primarily command-line but GUI tools available • Based on RCS, a single file-versioning tool—store “diffs” of each old version • Each file has a unique version number 19

  20. Before you use CVS • Need to understand basic UNIX skills (mkdir, ls, chmod, chgrp) • Set up a repository • Set up a group under UNIX and set permissions on a directory • “set CVSROOT” or “export CVSROOT” to that dir • “cvs init” • Set up personal workspaces • “set CVSROOT” or “export CVSROOT” • cvs checkout 20

  21. CVS (II) • Versioned files are organized into “modules” (top-level directories) • Centralized “repository” of files • Work in local workspace, checkout and commit files from/to repository • Does not lock files when you checkout: worry about conflicts when you commit 21

  22. CVS example Janak’s workspace Phil’s workspace CVSROOT 22

  23. CVS • First, a word on race conditions • Two threads within one program • Both want to increment a variable • Both read • One writes • The other writes • Result: one increment, value clobbered 23

  24. More On CVS • The same can happen with your coding process • Two people working on same piece of code • RCS: simple system for versioning and locking • CVS: fancier, networkable system for checking out entire dev snapshots • And then selectively committing changes 24

  25. CVS, Continued • No locking • Conflicts are marked inside the code • You’ll also be notified if checking in a wrong version 25

  26. Networking • Communication among systems • Continues to explode • Through wires or wireless 26

  27. TCP/IP History • ARPA project • Packet-based network • Resulted in ARPANet in the 70s and 80s • Eventually made public • Widespread adoption of TCP/IP caused internet to explode 27

  28. Layers • Levels of abstraction • Physical: electrical impulses • Transport: moving data • Protocol: reliability • Application: specific use 28

  29. Ethernet • Most common physical layer for short ranges • Truly trivial model • Shout • If someone else is shouting, wait a random amount of time • Try again • 10, 100, or 1000 million bits / sec • Others: V.90, X.25, SONET 29

  30. IP • The Internet Protocol • Very simple mechanism • Break data into packets • Every packet has a header with • Source IP • Dest IP • Checksum • Length • Other stuff 30

  31. IP Addressing • IP version 4 address is 4 bytes • Often written as four numbers in the 0-255 range • First “part” is network ID, second “part” is specific system ID • IP just cares about getting it to the right network 31

  32. Subnets • How is it split into parts? • Multiple models • Plus explicit “subnet masks” • Helpful for breaking up 32

  33. IP Routing and BGP • What happens when a packet comes in? • If it’s for me, deal with it • If it’s not for me and I can forward, • Look for host match • Look for network match • Send it onward if match found, otherwise drop 33

  34. traceroute / tracert • Watch your packets fly • Packets have a time-to-live field • Fire off packet with ttl 1, then with ttl 2, etc. 34

  35. TCP • One of the protocols on top of IP • Quite popular, but not popular enough to call the whole shebang TCP/IP • Packets will be delivered reliably, once, in order • Will request retransmissions if packets are dropped • Supports multiple recipients per machine with idea of “port” 35

  36. UDP • Alias datagrams • Adds ports to IP, but nothing else • I.e. totally unreliable, packets may be delivered out of order, not at all, multiply, etc. • Used for real-time data 36

  37. Services Listening On Ports • Servers have programs running in the background, waiting for connections on a particluar port • Telnet on 23 • FTP on 21 • Mail (SMTP) on 25 • HTTP on 80 • Many more 37

  38. RFCs • Define entire structure of Internet • Collection of publicly available documents • www.faqs.org/rfcs 38

  39. DNS / nslookup • IP only understands 4-byte address • Has no understanding of www.columbia.edu • DNS (Domain Name System) is an amazing distributed database • Translates names to numbers, globally 39

  40. Socket Programming • Basic client • http://java.sun.com/docs/books/tutorial/networking/sockets/readingWriting.html 40

  41. Socket Programming II • Basic Server • http://java.sun.com/docs/books/tutorial/networking/sockets/clientServer.html 41

More Related