Architecture on Software Design (Questions and Elaborations)
Posted: Mon Apr 05, 2010 4:27 pm
Hey again guys, I have been going through with learning a bit about Software Engineering and such, and I have to say it's been a tremendous help so far on seeing better ways to actually set up system architectures and ways to design my code better, however some of it's still a bit unclear and I was hoping that those with a bit more experience can elaborate on this 
.
This is also taken from the book "Software Engineering 7th ed".
When I began coding I seemed to always have trouble finding ways to have objects interact with eachother/ or setting up a design that will allow such behavior, I mean of course this was implemented but it was always very random and kind of "made up" ways of doing it. This book is helping to bring everything together.
So I have gotten to the section in the book on design, and he discusses a few ways to organise your System Architecture using 3 different models to startout/get ideas with.
1. "The Repository Model"
In this model he demonstrates how all data is stored in central database that can be accessed by all sub-systems, while each sub-system maintains it's own database, and data is interchanged with other sub-systems by passing messages to them. However there are disadvantages to this model that can effect performance and evolution of the model.
2. "Client/Server Model"
This model is pretty well understood, basically showing how your clients interact with the servers and in the use of networked systems.
3. "The Layered Model"
This model looked pretty interesting because it consists of 4 layers that can be constructed independently of eachother, making cross platform viable however, this can also come at a cost of performance issues if you needed to access layers from others that are not adjacent to them, and possibly several layers ahead/beneath.
1. Configuration management system layer
2. Object management system layer
3. Database system layer
4. Operating system layer
So when I take these 3 examples as a foundation on setting up an architecture in which a game is to be designed, I am asking from those experienced, what to look for/ are there ways in which the Architecture organization of your game should be coded that are commonly used that don't fit into the criteria of these 3 examples, or perhaps slightly with modifications? or is it really left up the programmer's innovation to only define it based on needs of the system in question? The concepts I learn here I just try to find better ways to apply them to game development in general. Well I hope to hear your guy's thoughts and ideas on it, thanks everyone!
.This is also taken from the book "Software Engineering 7th ed".
When I began coding I seemed to always have trouble finding ways to have objects interact with eachother/ or setting up a design that will allow such behavior, I mean of course this was implemented but it was always very random and kind of "made up" ways of doing it. This book is helping to bring everything together.
So I have gotten to the section in the book on design, and he discusses a few ways to organise your System Architecture using 3 different models to startout/get ideas with.
1. "The Repository Model"
In this model he demonstrates how all data is stored in central database that can be accessed by all sub-systems, while each sub-system maintains it's own database, and data is interchanged with other sub-systems by passing messages to them. However there are disadvantages to this model that can effect performance and evolution of the model.
2. "Client/Server Model"
This model is pretty well understood, basically showing how your clients interact with the servers and in the use of networked systems.
3. "The Layered Model"
This model looked pretty interesting because it consists of 4 layers that can be constructed independently of eachother, making cross platform viable however, this can also come at a cost of performance issues if you needed to access layers from others that are not adjacent to them, and possibly several layers ahead/beneath.
1. Configuration management system layer
2. Object management system layer
3. Database system layer
4. Operating system layer
So when I take these 3 examples as a foundation on setting up an architecture in which a game is to be designed, I am asking from those experienced, what to look for/ are there ways in which the Architecture organization of your game should be coded that are commonly used that don't fit into the criteria of these 3 examples, or perhaps slightly with modifications? or is it really left up the programmer's innovation to only define it based on needs of the system in question? The concepts I learn here I just try to find better ways to apply them to game development in general. Well I hope to hear your guy's thoughts and ideas on it, thanks everyone!