Claudie
From SoftwarePractice.org
Contents |
Personal Reflection
Software Architecture has been an intensive thoughtful subject, and also taught me ways to deal with issues in a profesional way, which was a way to adopt myself in different situation.
Our group consisted of five (5) members and in order to maintain communication was the hardest. Our initial design was implemented, but all target were not acheived and we were to fix these issues as the deadline approached. Dealing with project management is also an important aspect in a project such as this. Being able to manage each of the member's contribution, as well as the outcome are the main purposes in all of engineering projects. If, for instance, communication has "failed", the outcome will fail. As consequent, keeping in touch with each other with all means (i.e. Email, phone, wiki) is critical.
While studying the subject Real-Time Operating System and Information and Communication Technology Design (ICT D), this subject has also been helpful in understanding the basic architecture.
In this subject, I get to use a Wiki, which is a first for me. This allows all documents to be subversioned and simplified all documents versions. In parallel to the Wiki, we are to use SVN. This actually is another way for us to use the latest of our code for our prototype. Other than convenience, there are inconvenience: technical issues have arosed. For instance, one of our group member did not have access to the SVN server by the end of the semester, which he has to rely on emails to get/give us the latest version of his work contributed.
In an engineering point of view, Software Architecture is another subject that made me grown into a higher level engineer, with more experience.
06-11-08
- Presentation slides preparation and prepare final slides
Total: 3 hrs
05-11-08
- Presentation slides preparation
- Reflection
- Appropriate section on wiki
Total: 4 hrs
01-11-08
Tasks Descriotion for each of the group member:
As decided in our team meeting today - Here is the breakup of work
- The names across the topic heads indicates that you are responsible for the quality of work/ correctness and the formatting on the Wiki
- Everyone is to do their bit and put it up on the Wiki by 12 noon Wednesday.
1 System Overview - Tharsen
Outlines the overview of the system and gives a top-level view of the system and will lay the foundation for a more in-depth system architecture in the following sections.
1.1 System Narrative 1.2 Stakeholders 1.3 Quality Narrative 1.4 Product Qualities
2 Conceptual Architecture - Claudie
Provides domain-level responsibilities for the system. This section was derived from the System Narrative above and includes.
2.1 Use of Stereotypes 2.2 Discussion of Components and their Responsibilities - Claudie 2.3 Data Models - Troy 2.4 Run-time and Life-cycle Events - DJ 2.5 Behavior derived from Use-case Maps - Simon
3 Execution Architecture - DJ
The Execution Architecture will set out to define the system through "run-time" structures that makes up the system in focus.
3.1 Process View OR Concurrent Sub-systems View - Tharsen 3.2 Execution Architecture Design - Troy 3.3 Behavior - Simon 3.4 Deployment View based on either one of the above - Jason 3.5 Architecture Feasibility - DJ
4 Implementation Architecture - Jason
The Implementation Architecture will set out to define the system through "built-time" structures that makes up the system in focus.
4.1 Choice of Components that we used - DJ 4.2 Implementation Architecture Design - Jason 4.3 Behavior - Simon 4.4 Architecture Prototyping - Claudie
5 Contextual Factors and Issues
Everyone puts in their inputs based on the factors that they faced.
27-10-08
- Worked on Simulator GUI for Assignment 2 for demonstration
- Originally with buttons, then changed to checkboxes to allow multiple states and a "Generate Event" button to send these states. However, we all decided to change the chekboxes back to buttons, which simplify the process allowing only 1 event to occur at 1 certain time.
- Fixed the IOException issue occuring at the "ActionPerformed" class with "Try" and "Catch" functions.
Total: 15 hrs
11-10-08
- Finalised Event Simulator GUI and sent to Troy to continue on comms.
- Started the IMS interface GUI
Total: 3 hrs
09-10-08
Meeting Date: 09-10-08
Start Time: 19.00
End: 20.30
Attendance: Claudie, DJ, Jason Absent: Tharsen, Simon, Troy, Simon
Tasks
- Agreed to add another GUI for the Central Monitoring System and a GUI for the event simulator (on-site IMS).
- Simon, you will need to decide which file format to use (XML, Text files, etc..) that you will be using to send it to the storage database
Responsability Matrix
- Claudie: Design Event simulator GUI and refine CMS GUI
- Jason: Refine on the comms
- Tharsen and DJ: Written Report (due in 3 weeks)
- Simon: Report Data and Storage Database
- Troy: Incident Analysis System (work closely with Jason for comms), and code behind the the Simulator GUI to talk to CMS
Note
- The demo is due in 2 weeks, so please, let us know how everything is going and not leaving till the last minute...
Next Meeting
Please confirm a meeting this Saturday 11th Oct @ 12pm. Jason, Claudie and DJ confirmed!!
TOTAL: 1.5 hrs
25-09-08
Meeting Date: 25-09-08
Start Time: 18.10
End: 18.55
Attendance: Claudie, DJ Absent: Tharsen, Simon, Troy, Simon
Tasks
- Agreed on each 3 individual tasks: Data input, Data processing & Comms with Central Monitoring System.
- Update Data Model before resuming coding
- In our dummy program, there is NO AV Processing System. Only the images and sound are passed to the Incident Analysis System (the GUI will have 2 buttons to initiate NORMAL and CRASH sounds. If NORMAL button is pressed, nthg will happen. If CRASH button is pressed, the Incident Monitoring System will detect it, get the last 10sec and next 10sec of the AV data, flag it and send an alarm to the Central Moniroting System.)
Task Description
- Data Input: Get all images and sound to the Incident Analysis System
- Data Processing: Flag unusual events, report to Central Monitoring System and store data in database
- Comms: How the Central Monitoring System talks to the IMS
- Report:
Tasks Responsability Matrix
- DJ: Data Model, Executable program integration
- Claudie: GUI, Report
- Jason: Comms between Central Monitoring System and IMS (Threaded Server) - *Central Monitoring & Error Diagnostics
- Simon: Traffic Light, Time source, Report Data
- Tharsen: Report
- Troy: Incident Analysis System (work closely with Jason for comms)
TOTAL: 1 hrs
18-09-08
- Resume work on IMS GUI
- Added tabs in the main window, and buttons
TOTAL: 4 hrs
17-09-08
- Added features for the IMS GUI with Eclipse
TOTAL: 3 hrs
10-09-08
- Resume on PPT presentation slides
- Assigned to be presenting the Intro, System Overview, Contextual Factors and Issues.
Total: 3 hrs
07-09-08
- Started Presentation slides
TOTAL: 0.5 hr
04-09-08
- Updated the component diagrams
- Updated component description diagram
- Filled Narratives for the IMS
TOTAL: 1.5 hr
