20 Kasım 2009 Cuma
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.
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...
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.
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 :)
13 Kasım 2009 Cuma
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 :)
12 Kasım 2009 Perşembe
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.
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.
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.
6 Kasım 2009 Cuma
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.
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
5 Kasım 2009 Perşembe
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.