COMS W3156: Software Engineering, Fall 2001

1. COMS W3156:Software Engineering, Fall 2001 Lecture #8: RPIS, Rose Janak J Parekh janak@cs.columbia.edu

2. Administrativia • Still working on v0.6 of the requirements • We finally got Rational Rose (Friday), working on getting it installed for you guys • If things really back up, we’ll adjust the specification deadline accordingly

3. Next class • Classical specification model • Read Schach ch11 • You’ll be using some of the basic concepts from there as well • Service discovery • Begin LDAP

4. Today’s class • Continue requirements discussion • Finish discussing project’s XML schema • Talk about reusability, portability, interoperability, hint towards scalability

5. Review: XML schema • Review: should read http://www.w3.org/TR/xmlschema-0/ to understand XML schemas better: it’s not a hard read • XML schemas are XML themselves—their describe other XML layouts • You will not be writing XML schemas, just need to understand them to write the XML

6. Review: Map element • Contains information necessary to describe a complete game map or world, including graphics for client and scripts for AI • Basic subtypes: • Tiles • Objects • Bots • Actors (user players)

7. GameEvent element (I) • Message between components • AI’s and clients request moves • Server evaluates moves, sends “deltas” out to all connected clients and AI’s

8. Move and chat • Movement requests • Checked for validity and timing, and either granted or rejected • Start Chat/End Chat • Enter/leave conversation mode • Send Text/Received Text • Exchange chat text messages

9. Attacks and changes • Attacked • Gives result of an assault • (You never request an attack, just move) • ReplaceObject • Bot with corpse, chest with opened chest, etc. • ChangeStats • Flip status bit, give health, gold, etc. • StatusMessage • Get message from the server

10. Game entry/exit • Enter/quit game • Client requests • KickGame • You’ve been naughty, server kicks you • ExplicitSave • Client requests actor stats be sent to repository

11. Editor • Get data from client editor module • SendObject, LoadMap • We need to do some more work here

12. Data transfer • GetMapData • Client’s request to send absolute info • MapData • Server’s response with data • MapDelta • Changes since the last “delta” • Deltas have a sequence number to detect if help deltas are lost

13. Exception events • Server’s method of saying “huh” or “uh-oh” • ExMoveForbidden • ExNoConversation • ExKicked • ExNoPermission • ExUnknown

14. Reuse • Accidental vs. planned reuse • Basic reuse: • Libraries/packages • API’s • Objects • Not perfect, but better; “informational” cohesion, not just “functional cohesion” • More reuseable: JavaBeans and COM objects

15. Impediments for reuse • Trust (quality and integrity) • Logistics (how to organize components?) • Signed code • Cost (design, extra work) • Use (where appropriate?) • public class Kangaroo extends StingerMissileDetachment?

16. Reuse (I) • Idea: take tested designs from previous projects • Even if code can’t be reused, concept model • Design with libraries/packages in mind • Java API: “forced” reuse • GUI libraries (AWT)

17. Reuse (II) • Several ways to integrate: • Library/toolkit (pieces; left) • Framework (assembly; right) • Useful: tested high-level design • Application frameworks • gcc/compilers • ATM • Code framework • MFC • Pattern (separate slide) • Architecture (all of the above)

18. Design patterns • Set of solutions to common general design-level problems • Flexible, extensible, etc. from beginning • Concept by Christopher Alexander, 1977 • “Gang of four”: assembled first books on patterns (1995) • Object-oriented design patterns • Now everyone’s into it • Antipatterns: new trend—known bad ways

19. Portability • Writing software that deals with incompatibilities (and they will happen, and you have no choice) • Hardware • Numerics (precision) • Operating systems • Compilers

20. Techniques for portability • Portable system software • UNIX (Linux is a good example) • Portable application software • Write software in high-level languages • POSIX, GNU libc • Language portability: Java (code), C# (data) • Portable data • Various solutions; out of our scope • Mainframe  PC

21. Interoperability • Cooperation of different code • Lots of ways, including low-level shared memory, sockets, XML • Next-generation: service-level interoperability • Services are essentially “object-oriented”: object-level interoperability • COM: Microsoft’s solution • CORBA: OMG’s solution • We’ll talk about these in more detail later • Still evolving, often too complex

22. Scability • Not an issue with your project, but good designs make a big difference • Determine what your target scalability is • Example: Uni/multiprocessor • Low-level modules should be made more efficient: more well-defined tasks • Support efficient concurrency • Support multiple connections? • Threads are not always the answer, but work for smaller applications

23. Rational Rose (I) • Part of the “Rational Development Suite” • Ironically, poorly engineered program • Mediocre UI • Bloated software • We’re setting this up for you as we speak… • Microsoft Visio as backup plan, but probably not now • Why?

24. Rational Rose (II) • Automates a lot of the software engineering process • Code generation • Code re-engineering • UML diagrams throughout • Many other Rational products available • You’ll need to spend some time and play with this

25. What this means for you • We’re not expecting highly portable or scalable code, but: • Well-designed Java programs are automatically portable • We do expect interoperability: XML interchange of data between different client, server, and AI groups • Standardized diagramming with Rose • We don’t require you to use the other features

26. Demo time!