1 / 25

COMS W3156: Software Engineering, Fall 2001

COMS W3156: Software Engineering, Fall 2001. Lecture #6: Objects I Janak J Parekh janak@cs.columbia.edu. Administrativia. Requirements and specification assignment out Start reading and parsing it We’ve given you 3 weeks for the specification for a reason

liko
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 #6: Objects I Janak J Parekh janak@cs.columbia.edu

  2. Administrativia • Requirements and specification assignment out • Start reading and parsing it • We’ve given you 3 weeks for the specification for a reason • We’ll continue to add to requirements • Anyone planning to use C++? • Homework 1 going out tonight • 5 written, one small programming • Groups (almost fully) formed • Some minor changes might happen

  3. Next class • We go object-oriented in a big way • Read UML chapters 3-5, Schach chapter 12 • Object-oriented specification using UML technologies: what you will be doing for the next milestone • We’re skipping around to prepare for milestones • Might want to consider reading chapters 1-2 of UML: pretty short, useful intro

  4. Today’s class • Quick object review • Begin OOA • Begin UML • Talk about project • Yet more interactivity…

  5. Objects (I) • NB: Discussion will be Java-esque • Classes • Methods • Fields • Final modifier • Static vs. dynamic • Default, private, protected, public • Objects • Packages

  6. Objects (II) • Inheritance • Extend • Superclass, base class, subclass • Overriding/overloading • Containers • Is-a versus has-a • Polymorphism • Abstract base class • Interfaces • … and more. There are books on this stuff…

  7. OOA • Object-oriented version of specification document • Three steps • Use-case modeling • Class modeling • Dynamic modeling • Elevator problem: interesting, but large

  8. Use-case modeling • Use cases explain functionality of the product to be implemented • Generic description leads to scenarios • Steps in scenarios are like a walkthrough • Sigh, use-case diagrams • In reality, more interested in textual use cases • You’re welcome to use either diagrams, text, or both

  9. Use-case diagram

  10. Use-case descriptions • Scenario: user uses client • User logs into client, authenticates against server • User interacts with world by navigating (moving around) and by fighting bots (combat) • Scenario: AI interfaces with client • AI moves around and fights • Need to refine this

  11. Use-case descriptions (II) • Scenario: user logs in • User starts client application • User enters username and password • The client checks authenticity against LDAP server • If username and password is correct, client downloads list of worlds and presents it to user • User selects a world and enters it • Client connects to server, downloads map • Focus on actual experience: address requirement • Not a precise science • Need to identify the use cases: “observe” users

  12. Class modeling (I) • Fowler: what exactly are you using this for? • Specification-level class diagrams, not design-level • Focus on general methodologies and entities, not actual low-level classes and methods • We don’t need to see “Client calls the connect() method of object java.net.Socket” • On the other hand, should provide good idea of how to determine classes in system

  13. Class modeling (II) • Schach: noun extraction, CRC cards • Noun extraction useful for “candidate classes” • Define problem • Informal strategy • Formalize the strategy and draw the class diagram – noun extraction happens here, based on text of informal strategy

  14. Class modeling (III) • Example: a rather simplified one • “The server, when started up, starts listening for client connections. Once a client is connected, it is placed on a map stored on the server. This map consists of many tiles, some of which are impassable mountains and others which are passable land. Objects may exist on the latter tiles: either actors or items.” • Should actually take requirements document and start developing informal strategy from there • Nouns, anyone?

  15. Class diagram • Gives immediate ideaof software’s structure • Can provide basis foractual design • Arrow with open head:“subclass of” • * implies many • Line implies association

  16. Class modeling (IV) • CRC cards are also a useful way of laying out objects and rearranging them • Primarily intended for large teams: don’t have to erase diagrams as frequently • Class-responsibility-collaboration • Responsibility is the high-level description of the purpose of a class • Collaboration represents other classes needed to work with (high-level links) • We won’t be using these, but Fowler has a decent discussion on them

  17. Sequence diagrams • Demonstrates how the objects from a class diagram actually collaborate • Again, base on use cases • Alternative is to use collaboration diagram: class-based as opposed to timeline-based • Subset of the joining example from previous slides…

  18. Sequence diagrams (II)

  19. State diagrams • Similar to “finite state machines” • Basic idea: program is enumerated as a set of states, and transitions between them • Will go into more detail next class (UML ch 8) • Particularly useful for AI’s and such

  20. So, what will you do? • Understand what the heck the project is • Detail the use cases • Draw each of these diagrams in greater detail • Probably will utilize multiple diagrams

  21. How will you draw these? • Choice of several tools • Visio • Rose • We have the former, hope to have the latter • Rose actually lets you take the diagrams and use it to build interfaces for code • More detail on this next week

  22. And what will we do? • Expand requirements specification • More documentation on XML • More detailed requirements on world properties, especially for client editor • Some of this encroaches on specifications • Hand you LDAP code • What we will not do • Actually design each component • We’re focusing on base rules, functionality, and interactions

  23. Speaking of which… • The requirements document, v0.5, is out • We’ll take a look in a moment • It is big, but that’s the point • Again, implementation isn’t do-or-die: proper specification design will help • Next version going out tomorrow

  24. Sidebar: Event Models • Will cover in greater detail later in the course, but some basic points • Publishers vs. subscribers • Usually asynchronous • Think AWT event model • Popular for network programming

  25. On with the show…

More Related