COMS W3156: Software Engineering, Fall 2001

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…