1 / 26

COMS W3156: Software Engineering, Fall 2001

COMS W3156: Software Engineering, Fall 2001. Lecture #8: RPIS, Rose Janak J Parekh janak@cs.columbia.edu. Administrativia. Still working on v0.6 of the requirements We finally got Rational Rose (Friday), working on getting it installed for you guys

willow
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 #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!

More Related