This week, we started to see something concrete about project's future and what we will realize about the project. We searched about game engines, terrain models, object models, domain information.
As my friends already mentioned, we wrote software requirements specifications document. Of course there are some missing points in it. Because of lots of homeworks, midterms in this week we could not cover in detail all of the subjects in detail. As I mentioned in the documents in some requirements, we will cover them in further cycles of spiral model of TRASTRAPS.
All we four prepared the srs document. So, I think it is pointless to write same things.
Suat Gonul
20 Kasım 2009 Cuma
Writing SRS
It was a very exhaustive week because of the Requirements Specification Reports. We were very tired but when we look behind, we are proud of writing a professional, technical and satisfactory report. Each passing day relationship between Virtual Impact members getting stronger and requirements Specification Report was the last but most intesifier factor for this relationship.
In the report, we indicated all the initial steps of our project which involves, research conducted so far, the process flow that we planned, requirements we gathered and etc. Putting all together was a hard job, because it was our first huge report and it had to be well-organized and planned. Therefore we spent a lot of time together to plan each word and as a result a good report is written.
The most exciting part of the initial process was looking for 3D engines. As we found tools, we got self confident, and were glad to know what we can do with these great tools. Here is an example of a such tool we can make use of:
We should admit that forming the use cases and class diagrams was a hard job, but drawing them with "creately" was very enjoyable and easy. It seems we are going to use it a lot in this semester :)
During this period we did not just concentrate on the requirements, we also imagined all the final parts of the simulation, we believe it was the best part our meetings. It means we have a good dream of creating a great visual simulation and we will work very hard for that.
As a result, our Reqirements Analysis Report is not just a report, it represents what Virtual Impact can (and will) do. It is just the beginning and the visible part of the iceberg...
Şenan
In the report, we indicated all the initial steps of our project which involves, research conducted so far, the process flow that we planned, requirements we gathered and etc. Putting all together was a hard job, because it was our first huge report and it had to be well-organized and planned. Therefore we spent a lot of time together to plan each word and as a result a good report is written.
The most exciting part of the initial process was looking for 3D engines. As we found tools, we got self confident, and were glad to know what we can do with these great tools. Here is an example of a such tool we can make use of:
We should admit that forming the use cases and class diagrams was a hard job, but drawing them with "creately" was very enjoyable and easy. It seems we are going to use it a lot in this semester :)
During this period we did not just concentrate on the requirements, we also imagined all the final parts of the simulation, we believe it was the best part our meetings. It means we have a good dream of creating a great visual simulation and we will work very hard for that.
As a result, our Reqirements Analysis Report is not just a report, it represents what Virtual Impact can (and will) do. It is just the beginning and the visible part of the iceberg...
Şenan
Step by step to the end
This week, we gathered and talk about the future of our project. We defined our specifications and wrote a great Requirement Analysis report. All of us worked together and did a great job about Requirement Analysis Report.
First, we had to decide our 3D Graphics Engine and 3D Audio Engine. I did research about them. There are lots of engines available and ready to use but the problem is which one to use. They are classified as Graphics API, Programming Language Bindings, some libraries etc. The one we need has to have available support. Since we are new at this area, we need some documentations, manuals and tutorials to implement them. I found some great engines but they are not appropriate for us because of the lack of support. After some more research, we are agreed on one 3D Graphics engine and 3D Audio engine that have enough documentation and appropriate for our project.
After we decided on there critical points of the project, we can now imagine how the result will be approximately. I think imagining is something important in a project. Once we imagine the product of the project, the implementation will be easy for a group like us. We also agreed on the name of the product. It is TRASTRAPS. It means Training and Strategical Planning Simulation.
I believe we did a great job in such a busy week. We are getting closer to end week by week, so we need to work harder in order to achieve what we seek.
--
Serkan Olgun
First, we had to decide our 3D Graphics Engine and 3D Audio Engine. I did research about them. There are lots of engines available and ready to use but the problem is which one to use. They are classified as Graphics API, Programming Language Bindings, some libraries etc. The one we need has to have available support. Since we are new at this area, we need some documentations, manuals and tutorials to implement them. I found some great engines but they are not appropriate for us because of the lack of support. After some more research, we are agreed on one 3D Graphics engine and 3D Audio engine that have enough documentation and appropriate for our project.
After we decided on there critical points of the project, we can now imagine how the result will be approximately. I think imagining is something important in a project. Once we imagine the product of the project, the implementation will be easy for a group like us. We also agreed on the name of the product. It is TRASTRAPS. It means Training and Strategical Planning Simulation.
I believe we did a great job in such a busy week. We are getting closer to end week by week, so we need to work harder in order to achieve what we seek.
--
Serkan Olgun
Requirements and Initial Steps
This week was all about specifying requirements about the project. Our requirement analysis report can be downloaded from our website, which will be available as soon as the domain is provided as I said last week.
We have reflected the research we have done till now to the requirements analysis report, as well as determining the tools to be used. The most difficult part was coupling the project, which requires exact specifications. Nevertheless, this week we have put all of our work together and created a huge initial step to our project.
All of the report is written together, there was no individual work or subgroup study. Every decision is made by contribution of everyone, since we have decided the team model to be democratically decentralized. Of course we shared only the 'writing and drawing' part, to work parallel, but after deciding what to write or draw. I can say that my biggest 'solo' part was translating everything into LaTeX, since we pay attention to format of our report in addition to content. The design and cover of our report was my work too, where I used absolutely LaTeX :) Another design requiring issue was drawing of diagrams, where some use cases and a little part of class diagram was realized by me too. However, gantt chart was drawn by other team members, again compromising altogether on the timeline.
Related to content, every single aspect was discussed in the team but briefly what I have reduced to writing were;
- introduction chapter,
- process model and team model,
- major constraints,
- sponsor meeting overview,
- logging requirements and
- risk management issues.
In addition to these, we have decided on the design of our GUI menus which will be presented on the weekly meetings before sharing them with you :)
So what we have done in this week can be inspected from our requirements analysis report. We are willing to meet with you at this point next week, thanks :)
Ilke
We have reflected the research we have done till now to the requirements analysis report, as well as determining the tools to be used. The most difficult part was coupling the project, which requires exact specifications. Nevertheless, this week we have put all of our work together and created a huge initial step to our project.
All of the report is written together, there was no individual work or subgroup study. Every decision is made by contribution of everyone, since we have decided the team model to be democratically decentralized. Of course we shared only the 'writing and drawing' part, to work parallel, but after deciding what to write or draw. I can say that my biggest 'solo' part was translating everything into LaTeX, since we pay attention to format of our report in addition to content. The design and cover of our report was my work too, where I used absolutely LaTeX :) Another design requiring issue was drawing of diagrams, where some use cases and a little part of class diagram was realized by me too. However, gantt chart was drawn by other team members, again compromising altogether on the timeline.
Related to content, every single aspect was discussed in the team but briefly what I have reduced to writing were;
- introduction chapter,
- process model and team model,
- major constraints,
- sponsor meeting overview,
- logging requirements and
- risk management issues.
In addition to these, we have decided on the design of our GUI menus which will be presented on the weekly meetings before sharing them with you :)
So what we have done in this week can be inspected from our requirements analysis report. We are willing to meet with you at this point next week, thanks :)
Ilke
13 Kasım 2009 Cuma
Virtual impact is ready to strike!
As my friends already said that we tried write our software specification requirements, did some research about HLA-RTI implementation, decompose our system into modules, did some brainstorming roles of those modules within the whole system and started out to build our website in this week.
Some of the subjects are already explained by Senan and Ilke, nevertheless I want to make some additions about our efforts.
First of all, we thought that if we want to start immediately produce concrete application, we have to search and decide which HLA-RTI implementation to use. After making some investigation, we found tens of implementations but most of them do not suit us. Some of them are commercial, some of them are not completed and even have not a proper documentation or are not totally compatible with standards. The best choice which is the Portico Project glared at us. Because, it has a comprehensive documentation including beginning to Portico part. Actually, to start with this component is the most important for us. Also, it has Java and C++ support which is again most suitable for us. Here is a link of documentation part of it about Java: http://porticoproject.org/index.php?title=Getting_Started_With_Portico_Java. Furthermore, Portico project is compatible with 1.3, IEEE 1516 standards totally. It would be better for us to use such self completed open source implementations, otherwise we may have to make contribution to RTI implementation itself rather than dealing with our own project.
Last topic, I want to say something about is decomposing of our system into modules and roles of the modules. We decided to divide our system into 5 main parts: Federation, database management system, database itself, 3D model and graphic engine. I want to talk about them separately from a higher perspective.
Federation is composed of federates which are parts of simulation system such as soldier, helicopters etc. Those federates within federation communicate each other via RTI. Though, here are also some subcomponents of RTI for example RTI ambassador which serves services for communication, details will be included in our formal reports e.g software specification requirements.
Database management system will be the component that will be in relation with federates and 3D models to acquire related information from database thanks to methods that is harbored in it.
Database is the noncommercial off-the-shelf product. We may use a restricted version of Oracle or maybe MYSQL database. We have not decided on it yet.
3D models as understood will contain information about entities of simulation. But, the information does not have to be visual only. For example, it can be missile capacity of a plane.
Graphic engine will be the part that will visualize the simulation. Details of graphic engine has not been determined yet. We are still making some search about it discussing specifications about it.
That's all for me for this week. Have a nice day :)
Suat Gonul
Some of the subjects are already explained by Senan and Ilke, nevertheless I want to make some additions about our efforts.
First of all, we thought that if we want to start immediately produce concrete application, we have to search and decide which HLA-RTI implementation to use. After making some investigation, we found tens of implementations but most of them do not suit us. Some of them are commercial, some of them are not completed and even have not a proper documentation or are not totally compatible with standards. The best choice which is the Portico Project glared at us. Because, it has a comprehensive documentation including beginning to Portico part. Actually, to start with this component is the most important for us. Also, it has Java and C++ support which is again most suitable for us. Here is a link of documentation part of it about Java: http://porticoproject.org/index.php?title=Getting_Started_With_Portico_Java. Furthermore, Portico project is compatible with 1.3, IEEE 1516 standards totally. It would be better for us to use such self completed open source implementations, otherwise we may have to make contribution to RTI implementation itself rather than dealing with our own project.
Last topic, I want to say something about is decomposing of our system into modules and roles of the modules. We decided to divide our system into 5 main parts: Federation, database management system, database itself, 3D model and graphic engine. I want to talk about them separately from a higher perspective.
Federation is composed of federates which are parts of simulation system such as soldier, helicopters etc. Those federates within federation communicate each other via RTI. Though, here are also some subcomponents of RTI for example RTI ambassador which serves services for communication, details will be included in our formal reports e.g software specification requirements.
Database management system will be the component that will be in relation with federates and 3D models to acquire related information from database thanks to methods that is harbored in it.
Database is the noncommercial off-the-shelf product. We may use a restricted version of Oracle or maybe MYSQL database. We have not decided on it yet.
3D models as understood will contain information about entities of simulation. But, the information does not have to be visual only. For example, it can be missile capacity of a plane.
Graphic engine will be the part that will visualize the simulation. Details of graphic engine has not been determined yet. We are still making some search about it discussing specifications about it.
That's all for me for this week. Have a nice day :)
Suat Gonul
12 Kasım 2009 Perşembe
SRS and UML Tool
As we are passing one more week, We are more confident about our project because we know much more as compared to last week. We made a great progress about our project.
First we started to write our Software Requirements Specifications report. I first read the IEEE Std. 830-1998 paper which is a guideline for SRS reports. IEEE Std. 830-1998 is not a SRS template but a paper which can make you understand what SRS is about and can help to write it. After I finished reading, I tried to find some SRS samples about warfare simulations. I did that because I wanted to know what can be included and how it can be written in a warfare simulation SRS. However, I could not find what I want exactly but I found some great samples of SRS reports.
After I examined them I was ready to write our own SRS report.
As we started to write the report, we had to decide what UML tool to use. Our most important concern was that the tool has to be cross-platform. The reason for that is Ilke uses a Mac Book Pro and rest of us use Intel and AMD based computers with Windows and Ubuntu operating systems. After some research I found a UML tool named as "Creately". Creately is a web-based diagramming and design application which is built on Adobe Flex (in our opinion). I can say that because 4 of us are familiar with Adobe Flex. Since it is web-based, our concern about cross-platform is taken care of. It can be used to create informational diagrams, flowcharts, organizational charts, UML designs, mind-maps and many other diagram types. The best part of it is collaboration capabilities. In public license, Max. 5 Collaborators can work. It has a 10MB limit but it is quite enough for us. We can export our designs to jpg-png image formats or pdf document format. That tool is really what we are looking for. We created our first diagram about system interface with Creately. There is a video about that tool:
That's all about from me for this week.
Serkan Olgun.
First we started to write our Software Requirements Specifications report. I first read the IEEE Std. 830-1998 paper which is a guideline for SRS reports. IEEE Std. 830-1998 is not a SRS template but a paper which can make you understand what SRS is about and can help to write it. After I finished reading, I tried to find some SRS samples about warfare simulations. I did that because I wanted to know what can be included and how it can be written in a warfare simulation SRS. However, I could not find what I want exactly but I found some great samples of SRS reports.
After I examined them I was ready to write our own SRS report.
As we started to write the report, we had to decide what UML tool to use. Our most important concern was that the tool has to be cross-platform. The reason for that is Ilke uses a Mac Book Pro and rest of us use Intel and AMD based computers with Windows and Ubuntu operating systems. After some research I found a UML tool named as "Creately". Creately is a web-based diagramming and design application which is built on Adobe Flex (in our opinion). I can say that because 4 of us are familiar with Adobe Flex. Since it is web-based, our concern about cross-platform is taken care of. It can be used to create informational diagrams, flowcharts, organizational charts, UML designs, mind-maps and many other diagram types. The best part of it is collaboration capabilities. In public license, Max. 5 Collaborators can work. It has a 10MB limit but it is quite enough for us. We can export our designs to jpg-png image formats or pdf document format. That tool is really what we are looking for. We created our first diagram about system interface with Creately. There is a video about that tool:
That's all about from me for this week.
Serkan Olgun.
On preperation of writing SRS
This week I spent most of my time to pre-dedign and modulerize our term project to write a Software Requirements Specification (SRS). Also, it was very useful to read guidelines about writing good SRS. According to guidelines I have read so far, the project should be well-designed and all the requirements must be gathered before writing SRS. The most useful guideline was IEEE's and we decided to use it.
The requirements of the project may include each module's hardware dependencies, user interfaces, system interfaces etc. As we are going to implement a warfare simulator, user interfaces and graphical models are very important to implement. In addition, I thought and suggest my friends that, we can add RTI middleware system, it's usages, database management interfaces, graphics engine interfaces to our SRS as system interface.
Last but not least, I went on making research on HLA and RTI concepts to gain enough experience and knowledge before our inital design and it seems we should make more research on the concepts.
Şenan Postacı
The requirements of the project may include each module's hardware dependencies, user interfaces, system interfaces etc. As we are going to implement a warfare simulator, user interfaces and graphical models are very important to implement. In addition, I thought and suggest my friends that, we can add RTI middleware system, it's usages, database management interfaces, graphics engine interfaces to our SRS as system interface.
Last but not least, I went on making research on HLA and RTI concepts to gain enough experience and knowledge before our inital design and it seems we should make more research on the concepts.
Şenan Postacı
Our Website Is On The Way! Behind The SRS Report :)
This week was a busy week in regard of the progress we have made about the project. Actually the study and research is done by whole group, but we will inform you in different subjects.
The part, actually the news, I will explain is a little bit more enjoyable :) Our web site is coming soon! I have been working on it for two weeks, and finally there exists a working draft from now on! We will share the address with you as soon as our department provides a domain for us, and from then, you can catch up with us from our website too. By means of an RSS feed of this blog I added and weekly reports (more formal formatted versions of what we tell here) we will be writing, you can have more information about the project. Moreover, the project definition, our contact information and lots of additional things are ready for you to be read. Just a little more time, we hope you will like :)
Other things we have done throughout this week is deciding on specifications of our project. Since our sponsors believe in us and our motivation, they are relaxed on specifications and we are absolutely free to implement everything we want, everything that we are to know we can do! With this conditions, we are our customer, our boss, our software team and our inspector. In this case, determining specifications and writing SRS report is our job too. Thus we have started writing down the whole SRS report by following the guideline of IEEE. Also while preparing, I needed an UML tool for Mac OS X, as a Mac user, for this reason we searched for a couple of UML and designing tools. In addition to plug-ins to Netbeans, Eclipse and other developing platforms; there are many tools like ArgoUML, Umbrella, Omnigraffle, Magic Draw, Visual Paradigm, Gliffy, etc. Trying each by ourselves, the best one in both practicality and license point of view, was definitely Creately, which Serkan will explain how to use a little bit.
So that's all by me for this week, other corporate studies that we have been working on will be told by other team members.
Ilke :)
6 Kasım 2009 Cuma
Initial Learning About Term Project Components: HLA, RTI, Agents
HLA (High Level Architecture) has become a familiar subject for me after my first summer practice. At that time, I got a little information which is HLA is a standard and it provides some standards enabling communication between different parts of a simulation system like computers, joysticks, simulation cabins, etc. As far as I read in the previous week, I acquired some additional information on this subject.
Firstly, I understood that my old information was a little missing that HLA provides communication between simulation components. It is the middle-ware named RTI (Run Time Infrastructure) having services that are described by HLA Interface Specification. HLA also describes federates which are parts of as reusable software units and federates communicate with each other through the services of RTI. Implementation of services of RTI are not obligated to be the same of each other, in other words there are several RTI implementations which can be chosen with respect to different kinds of needs. So, it is necessary to all federates within a federation to use the RTI same implementation.
Lastly, I had no information about agents of computer science. After a little investigation, I found out that agents are classes having ability of learning or decision making. They usually have the characteristics of autonomy, social ability, reactivity, pro-activeness, etc. So, they do their jobs without intervention of a human or some other trigger, they can interact with other agents, even they show goal directed behaviours in addition to act in response manner.
Suat Gonul
Firstly, I understood that my old information was a little missing that HLA provides communication between simulation components. It is the middle-ware named RTI (Run Time Infrastructure) having services that are described by HLA Interface Specification. HLA also describes federates which are parts of as reusable software units and federates communicate with each other through the services of RTI. Implementation of services of RTI are not obligated to be the same of each other, in other words there are several RTI implementations which can be chosen with respect to different kinds of needs. So, it is necessary to all federates within a federation to use the RTI same implementation.
Lastly, I had no information about agents of computer science. After a little investigation, I found out that agents are classes having ability of learning or decision making. They usually have the characteristics of autonomy, social ability, reactivity, pro-activeness, etc. So, they do their jobs without intervention of a human or some other trigger, they can interact with other agents, even they show goal directed behaviours in addition to act in response manner.
Suat Gonul
For starters, HLA and RTI
Since this is the first week, I did some research on what we'll use for out project. So, I did some research on HLA (High Level Architecture) and RTI (Run Time Interface).
After some Google-ing, I found very useful information. First, I found out that HLA is an architecture which was first introduced by U.S. DMSO (Defense Modeling and Simulation Office) but it is an IEEE standart now (IEEE 1516). I figured that HLA is simply an architecture for distributed computer simulation systems which allows computer simulations to communicate to other computer simlations. However, HLA is not enough for computer simulations by itself. RTI (Run Time Interface) is needed to manage those communication. RTI is the main component of HLA. HLA also has 2 other components (i.e., Object Model Template (OMT) and HLA Rules).
After some research about these issues, I tried to discover some RTI implementations. First, I checked out Chronos RTI by Magnetar Games. It uses IEEE 1516 standart and C++ .NET. Since it is a licensed product, I downloaded trial version of it. It allows you to use it for 10 minutes. I tried to figure how it works. I read some parts of its manual and now tried to figure how to implement.
After that, I found a really good paper entitled as "Selecting a HLA Run-Time Infrastructure" by Michael Imbrogno, Wayne Robbins and Gerard Pieris (Ottowa-Canada). It really helped me have an idea about HLA and RTI. I am sure that I'll use that paper for my future needs about the project
Serkan Olgun.
After some Google-ing, I found very useful information. First, I found out that HLA is an architecture which was first introduced by U.S. DMSO (Defense Modeling and Simulation Office) but it is an IEEE standart now (IEEE 1516). I figured that HLA is simply an architecture for distributed computer simulation systems which allows computer simulations to communicate to other computer simlations. However, HLA is not enough for computer simulations by itself. RTI (Run Time Interface) is needed to manage those communication. RTI is the main component of HLA. HLA also has 2 other components (i.e., Object Model Template (OMT) and HLA Rules).
After some research about these issues, I tried to discover some RTI implementations. First, I checked out Chronos RTI by Magnetar Games. It uses IEEE 1516 standart and C++ .NET. Since it is a licensed product, I downloaded trial version of it. It allows you to use it for 10 minutes. I tried to figure how it works. I read some parts of its manual and now tried to figure how to implement.
After that, I found a really good paper entitled as "Selecting a HLA Run-Time Infrastructure" by Michael Imbrogno, Wayne Robbins and Gerard Pieris (Ottowa-Canada). It really helped me have an idea about HLA and RTI. I am sure that I'll use that paper for my future needs about the project
Serkan Olgun.
5 Kasım 2009 Perşembe
Hello World, Hello HLA RTI!
For the first week of our project, I have inspected some sources related to HLA based RTI implementations, done some market search and looked for intelligent agents a little bit. Of course most of our effort is given to brainstorming during this process, because "what" to implement is still a larger question than "how" to implement, before giving out an SRS.
I see no need to explain concepts like what HLA standard stands for, for which purpose RTI is used, etc., but I want to share some useful sources that we (or you, if you are interested in similar topics) can use in future development steps. The first one is Portico, a fully supported, open source, cross-platform HLA RTI implementation. You can get more info from http://porticoproject.org/ . It is well documented and open source, however it is better to keep in mind that, to use a tool that is more preferred and suggested by sponsors may be well-integrated and ease our work.
Also for RTI implementations, the evaluation and comparison of them are briefly summarized in a paper we found at http://www.scs.org/confernc/hsc/hsc02/hsc/papers/hsc017.pdf . And the last source we have examined about HLA based simulating is http://dss.ll.mit.edu/dss.web/96.14.103.RTI.Introduction.html where every step is explicitly told.
Considering HLA terminology, agents (intelligent objects) are creatures(!) that we are not so familiar with. To have some idea about how artificial intelligent is dealt with in such simulations, Distributed Artificial Intelligence And The HLA: Bridging The Gap is an invaluable article we can consult.
So that's all from my research part, next week we will have started to take a step to implementation and design decisions, I hope.
Ilke :)
A mini-research on HLA an RTI
At the very initial step of our term project, I made some research about very important topics such as HLA (High Level Architecture), RTI (Run-time Infrastructure) to get familier with them. HLA is a distributed architecture for computer simulation systems. In HLA each unit is called a federate and each federate can communicate through a middleware also known as RTI which is the fundemental component of HLA. Federates can cooperate with each other thanks to the services that are provided by RTI. These services allow federates to exchange data and communicate in run time.
An interface specification of HLA defines how HLA simulator can communicate with RTI and these specifications are object-oriented. As one can guess many vendors develop their RTI implementations using JAVA and C++ languages.
There are several RTI implementations and it is worth to note that, RTI vendors may follow different design patterns to develop their RTI implementations. In addition, it is not necessary to implement each federation by the same RTI implementation, a different but suitable one can be used. However, using different RTI implementations may lead to interoperability issues, so vendors’ interoperability specifications about different versions or products of other vendors should be read.
Şenan
Kaydol:
Kayıtlar (Atom)
Kayıtlar
