Exercises finding generic software requirements

Topic example application: tic tac toe game

  • Topic example application is a Tic Tac Toe game.
  • Idea is that people can play this game over network with their local computers.
  • Game itself is quite short so it might be feasible that people can challenge each other into multiple games.
  • Also record about winning (and losing) history about games might be interesting.

Task: Find out what the software system should do

  • Take the Rational Rose. Use case view and create use case diagram in it.
  • The idea is to find out what is happening in the system, not how it is happening (that will be covered later in design part)
  • Model the actors in system. The major entities.
  • Model the game system major functionalities as example basis by creating use cases.
  • Think which actors participate to which use cases by associations.
  • So use case (functionality) might require other to be done first, model these situations by dependency
  • See if some use cases are common, try to generalize use cases. This might not to be necessary, but might simplify modelling.

Task: Document the results from the use case modeling

Note: This is now general software documentation (not specification yet)

1. Introduction

  • See created actors and use cases, think about them.
  • Write one paragraph introduction about the software system.
    • Goal for first paragraph introduction is that it gives reader fast information what the system is about.

2. Requirements

  • See created actors and use cases, think about them.
  • Make a list of requirements for the software system.
    • These requirements should be specified, designed, implemented and validated later.
  • Present requirements as table where there is requirement name (for later references) and short description about requirement.
  • Use cases are not directly requirements, they are starting points to specify requirements.

For example:

R03start Player can start a new game.

Appendix 1 Use Cases

  • Copy and paste use case diagram(s) here
  • Use case diagram works as guidance to more specific use case definitions.

Appendix 1.1 Use case: name

  • Start situation (and dependencies to other use cases if any)
  • Major steps in use case flow of events.
  • Exceptions
  • End situation

Appendix 1.2 Use case: another name

  • Start situation (and dependencies to other use cases if any)
  • Major steps in use case flow of events.
  • Exceptions
  • End situation

..

Communications specific use case

Task: Add Communication Use Cases into model

  • Take exe_02_requirements use case model.
    • Create new use case diagram.
    • Add (drag) existing actors and use cases into new diagram.
  • Think what happens in communication.
  • Add communication specific use cases and actors into model and build relationships with them and existing things.

Task: Find out initial objects with Collaboration diagram

  • For each Use Case in model:
    • Create new collaboration diagram (inside the use case)
    • Drag relevant actors into diagram.
    • Think the use case happening and the communication, try to find out things that are needed in use case.
    • Add things as objects into diagram and link relevant objects (and actors) together.

More

Exercise, Communication and initial classes

Task: Find out communication between initial objects

For each use case in model:

  • Create Sequence diagram. Add relavant actors and objects into sequence diagram.
    • You can used automated sequence diagram creation in rose: Browse ⇒ Create Sequence Diagram (when collaboration diagram is selected and open)
  • Think what happens in use case.
  • Model with object messages the communication between objects, so that use case functionality is covered.
    • The messages are forming steps (sequence) to complete the use case (ideal path)
    • Later messages are transforming into communication messages or into function implementations.

Task: find out initial classes

For each use case in model:

  • For each object in model:
    • Find proper class name (or existing class) to that object
    • Add the class into model (Use Case View)
    • In object specification set the class to object
    • To the class insert messages (that are incoming to object) as operations into class.

Exercise, Forming classes

Task: Design and Model Logical structure, classes and packages

  • This is checkpoint when to move from use case part to logical design part. So the model is good save as own result.
  • Form packages into Logical view. Think about classes and where they could belong and if they have some interaction, make packages for those classes.
  • Move classes and actors from use case view to logical view packages.
  • For each package:
    • Create class diagram
    • Add relevant classes into diagram.
    • Think about content of classes
      • Add of modify operations needed by the class. Add parameters to operations.
      • Think what information class should contain. Add information as attributes.
    • Think relationships between classes, add, where relevant:
      • Inheritance (generalization)
      • Association

Exercise, Structures, Interfaces & Messages

Task: Model Major Classes for Structure

  • Sketch out example system deployment with computers, processes (with roles) and connections. (process explanation)
  • Think about layered packages and structure inside the processes. (communications structure explanation)
  • Find out what are important classes. What have to exits at the begin of the process, to who connections are made, which player is using. Add classes if needed.

Task: Connections and interfaces between major classes

  • Think connections with major classes. Make them.
  • At the end of connections, think Interfaces. What operations or messages the class is going to receive. Model them (adapt the information from initial classes).

Task: Messages in Interfaces

  • Model messages used in system in logical form (peer packet messages later)
  • For each interface
    • For each operation in interface
      • Form a class from operation
      • Define information message carries (parameters from operation)
  • Think about possible generalization hierarchy of messages.

Communications activity modeling

Take the game model. From the model think about:

What are the processes in the run-time system (sample deployment). On client computers, on server computers etc. where the code implemented from the designed model is run.

Make new package “activity” into model logical part (this indeed would go to component of deployment diagrams, but support for them is poor in rational rose). Make class diagram, and identify found process to it. Specify also cardinality (possible number of processes) for processes. Mark process by «process» streotype.

For each process identity and associate activity end points. These describes different kind of access to external world the process has, eg. communications sockets, user interfaces, file or database access. Model the activity end point by class and make it by «activity» stereotype. If there is end points that has communication between associate it as well.

csa exercises 2008

Completing the design model

For each class:

  • Think does the class clear meaning why it exists in the model. Could the functionality moved to other classes.
  • Are the attributes and operations complete in classes.

For model:

  • Is there redundancy of the information in model.

View page as slide show

Introduction

Goal of Exercises and Project Work

  • Ensure that software components are inter-operable in communication (protocols)
  • Model (analyse and design) software and communications systems
  • Specify and describe communications system in documentation
    • No programming in this course (Communications Software Laboratory Works has that part)

Context & Problem

Modeling Software & Communications

  • Analyse of the problem domain
    • Finding functional requirements
    • Finding non-functional requirements
  • Design software systems
    • Building system architecture
    • Object structures
    • Object lifetimes
  • Design communications
    • Messages between peers
    • Messages between layers
    • Behaviour in exchange of the messages, state machines
  • Reverse engineering existing resources into used model
  • Separating system design and communications specification

Specification

  • Describes common rules between implementations
  • Works as reference in development of implementations
  • Specification is:
    • Complete
    • Exact
    • Minimal
    • Non-ambiguous
    • Non-optional (as much possible)
    • Agreeable
  • When specification is agreed by parties it becomes a standard (at different degrees)

Software developments processes

  • Analysis of problem domain and finding requirements
  • Design
  • Implementation – programming
  • Testing – finding errors
  • Validation – checking the system is correct

Tools

  • Unified Modeling Language, UML (version 1)
  • Rational Rose as UML tool
    • You can use other UML tools as well
  • Word processing tool – eg Word (for diagram copy and paste from rose)
  • Generic drawning tools

Packet Messages Encoding

  • Packet messages are horizontal messages exchanged over the network.
  • Network is provided by the transport layer service with certain style of service: eg. UDP - limited data block, TCP byte stream, SCTP - streamed messages.
  • Commonly interaction with transport is in form of sequence of bytes, therefore the encoding rules have to be defined how application messages are encoded into byte sequence and back.

To model:

  • Complete the IGame and IGameView related messages with information to be exchanges between them.
    • the name of attribute
    • the type of attribute
  • Specify also a message identification.

To word processor

More

CSA Project Work

Notes

  • About exercises and project work: topic on exercises is a game as well in project work, so there is similarities. Can you use exercises models in your work ? You should first think and model your topic, then if there is similarities on exercises you can use them. The project work model is your model and you should be able to explain it fully (“it was on exercises” is not acceptable explain). Note that exercise model is not completed or finalized yet (there even might be seeded errors in exercise model :).
  • When making the model think and design about it. You probably on first phase would get many modeling elements (classes objects etc). Think about each element, does it have purpose, is it's information contents or functionality relevant for that element or should it include to other element. Try simplify the model, to be complete and compact.

Assignment topics

Project work topics are different games. On project you model and design game as application. From design the communications specification is made.

In addition to the game specific inheritable requirements, following ideas should apply (are required):

  • Players are using networked system (internet).
  • Games are provided to players by some hosting (server).
  • On hosting players can play multiple games againts different players. (game sessions)
  • Hosting has information on online players.
  • Hosting has information about player history and other players might access it.
  • Events on hosting (game or player related) does not require any action from player (hosting is active part in communication as well).
  • Games are turn based, but time limit for each turn should be able to define.
  • .. maybe some more :)

Notes:

Chess

See wikipedia description http://en.wikipedia.org/wiki/Chess .

Battleship

Reversi

See wikipedia description http://en.wikipedia.org/wiki/Reversi .

Project work return & feedback time slot reservation list

  • Return in room 6614 (library) (moved from 6428)
  • Print your documents into paper.

10.12.2008

Last modified: 2013/07/01 14:42