4+1 Architectural Model

CyanWorlds.com Engine Project Management
User avatar
rarified
Member
Posts: 786
Joined: Tue Dec 16, 2008 10:48 pm
Location: Colorado, US

Re: 4+1 Architectural Model

Post by rarified » Tue Feb 21, 2012 3:42 am

Jon,

Just a quick note ... CSR was services for "customer service representatives", I.e. Cyan support.

_R
One of the OpenUru toolsmiths... a bookbinder.

Jons
Member
Posts: 11
Joined: Sun Jan 29, 2012 1:48 pm

UruLauncher Use Case Description

Post by Jons » Tue Feb 28, 2012 4:49 pm

Bonjour,

Thank you rarified for the precision about CSR. That explain why it is not implemented in MOSS.

I have slightly changed my approach about CWE documentation. I originally thought I would do high level global documentation then drill down to more detailed one. But there was too much things that I couldn't understand to write any high level documentation without going into all the details. I can't eat that elephant in only one bite! The new approach I try is to break the game process in manageable pieces and do detailed documentation about them, one by one. For that, I use the best reference I have, the source code itself.

The first piece I did look at is UruLauncher. I read through the code and came with the following Use Case Description:
SpoilerShow
Use case decription: CWE UruLauncher

Main actor: CWE ( UruLauncher.exe )
Secondary actor: GateKeeperServer, FileServer, WebServer
Objectives: Ensure that CWE is up to date before launching it.
Pre conditions : CWE is installed. The computer is connected to internet. GateKeeperServer, FileServer, WebServer are working and reachable.
Post conditions : CWE is up to date and UruExplorer.exe launched.

Nominal scenario:
  • 1.The patcher check if it is a new patcher or the "real" one (with the normal filename).
    2.Check if it works under CIDER (for MacIntosh port)
    3.Check the command line for the arguments: AuthSrv, FileSrv, GateKeeperSrv, BuildId . Initialize corresponding vrariable if found.
    4.Create the updater dialog box.
    5.Retreive the server status from the WebServer. (hardcoded WebServer address found in main.cpp)
    6.Retreive GateKeeperServer IP address. (passed as parameter or hardcoded in pnNbSrvs.cpp)
    7.Request the FileServer IP address from the GateKeeperServer.
    8.Download InternalPatcher manifest from the FileServer.
    9.Do MD5 check (compare the MD5 in the manifest with the current patcher's file one)
    10.Retreive GateKeeperServer IP address. (passed as parameter or hardcoded in pnNbSrvs.cpp)
    11.Request the FileServer IP address from the GateKeeperServer.
    12.Download ThinInternal manifest from the FileServer.
    13.Read an entry in the ThinInternal manifest file.
    14.Download the Internal manifest specified in that entry.
    15.Do MD5 check (compare the MD5 in the Internal manifest with the one of the corresponding file)
    16.Repeat step 13 to 15 for all the ThinInternal manifest entry.
    17.Launch the Uru game (UruExplorer.exe)
    End of scenario
Exception scenarios:

E1: The patcher is a new patcher.
This senario start after the nominal scenario step 2.
  • 3.The new patcher file is copied over the "real" one.
    4.Launch the new "real" patcher.
This scenario continue at the nominal scenario step 1.

E2: NoSelfPatch command line argument used.
This senario start after the nominal scenario step 5.
This senario continue after the nominal scenario step 9.

E3: MD5 Check failed on the patcher
This scenario start after the nominal scenario step 9.
  • 10.Download the new patcher from the FileServer.
    11.Launch the new downloaded patcher.
This scenario continue at the nominal scenario step 1.

E4: MD5 Check failed on some ThinInternal manifest entry.
This scenario start after the nominal scenario step 16.
  • 17.Download file (witch MD5 failed on) from the FileServer.
    18.Decompress .ogg to .wav into the streamingCache folder if apply.
    19.Repeat step 17 and 18 for all ThinInternal manifest entry that failed the MD5 check.
This scenario continue at the nominal scenario step 17.

E5: User press the Cancel dialog button.
This scenario can append anywhere between nominal scenario step 4 to 16.
End of scenario

Additional specification:
  • The nominal scenario start in plUruLauncher C++ project in Main.cpp at WinMain function.
  • The first five steps of the nominal scenario setup the patcher dialog box. At the step from 6 to 9, the patcher patch itself (SelfPatcher.cpp). At the step from 10 to 16, the client is patched (plClientPatcher C++ project).
  • The patcher dialog box status and progress bar is updated while patching .
  • Threading is used so the user can abort and exit the patcher process if he press Cancel button .
  • Cwd command line argument is used to override the Current Working Directory. (So you can patch elsewhere I suppose.)
Now that the Scenario View is done for that piece. I will go ahead with the 4 others. The next piece I'm thinking about is the login process. I hope all this will be useful.

Thank's for reading.
Jons

User avatar
JWPlatt
Member
Posts: 1097
Joined: Sun Dec 07, 2008 7:32 pm
Location: Everywhere, all at once

Re: 4+1 Architectural Model

Post by JWPlatt » Tue Feb 28, 2012 5:12 pm

If I'm reading this correctly, You and Lyrositor might have some common purpose, especially regarding Doxygen and learning the code in general.

viewtopic.php?p=5860#p5860

Do you think you'd like to try some collaboration?
Perfect speed is being there.

User avatar
Lyrositor
Member
Posts: 156
Joined: Sun Feb 05, 2012 10:58 pm
Contact:

Re: 4+1 Architectural Model

Post by Lyrositor » Tue Feb 28, 2012 9:34 pm

I would very much like to collaborate on such a project. The UDC does need some work, and I'd love to learn about MO:UL and CWE. Only thing is, I might not have the same computer-related skills you might have, Jons.

P.S. : Seriez-vous Français, par hasard ?
Lyrositor
Explorer #16601888
To D'ni, or not to D'ni. There is no question.
Image

Post Reply

Return to “Management”

Who is online

Users browsing this forum: No registered users and 1 guest