Embed Size (px)
Citation preview
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
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
Today’s class
• Quick object review
• Begin OOA
• Begin UML
• Talk about project
• Yet more interactivity…
Objects (I)
• NB: Discussion will be Java-esque• Classes
– Methods– Fields
• Final modifier
– Static vs. dynamic– Default, private, protected, public
• Objects• Packages
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…
OOA
• Object-oriented version of specification document
• Three steps– Use-case modeling– Class modeling– Dynamic modeling
• Elevator problem: interesting, but large
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
End-user
Client
Authenticate andlogin
*
*
Interact with world
*
*
«extends»
Navigate Combat
«extends»
AI
*
*
Use-case diagram
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
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
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
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
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?
Class diagram-ListeningPort-ConnectedClients
Server control
+LoadMap()+PlaceClient()
Server world controller
-filename : string(idl)-width : int-height : int
Server map store
+placeObject()+removeObject()
Map tile
1
*
-passability : int = false
Mountain tile
-passability : bool = true
Land tile
Object
-hitPoints : int = 100-gold : int = 0
Actor
-precondition-action
Item
• Gives immediate ideaof software’s structure
• Can provide basis foractual design
• Arrow with open head:“subclass of”
• * implies many• Line implies association
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
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…
Sequence diagrams (II)
Server Control Server world controller Server m ap store
PlaceC lient()
LocateEm ptySpace()
T ile
IsEm pty()
A boolean
Em pty space or nullSuccess boolean
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
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
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
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
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
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
On with the show…
