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 idea of software’s structure Can provide basis for actual 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 outout 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…