The project can be divided into two main parts:
The user defined rules for the game are stored entirely in the Model, while the Controller and View are constant for every game iteration. This ensures that the View and Model have no dependency and updates to one of them would only require implementation of new features to them selves or at most the Controller.
The DSL provides a Domain Specific Language to enable the user to define a card game using domain terminology.
The game being defined is then created using the Engine and run, allowing the user to play the card game.
The DSL uses a builder pattern to create a model that is then passed to the controller, which starts the game.
High level UML diagram of the dsl architecture.
High level UML diagram of the game engine architecture.
The Model defines the data rappresentation for every main concept in the game.
It is queried by the Controller when data is needed and it is updated to reflect changes to the data requested by the Controller.
The View defines the GUI that displays the model contents to the user and allowes the players to interact with the game.
A tecnology must be choosen during detailed design for the GUI implementation.
The Controller is an intermidiary between the Model and the View.
It defines the flow of the game extracting the rules defined by the user from the Model and using the View to display the current game state.