F3 - Intersection Monitoring System
From SoftwarePractice.org
F3 Team Members
| Name | Student Number |
| Vi Chea | 02051136 |
| Timothy Cheung | 10307306 |
| Christopher McDermid | 10300768 |
| Diego Sing | 10454181 |
| Daniel Tran | 10303699 |
| Polikalepo Tuaileva | 10311227 |
Introduction
The Unified Process has in recent times become more widely accepted in industry as an effective approach to software engineering. It involves iterative prototyping whilst maintaining a document called the Software Architecture Document.
To aid in the study of Software Architecture, Group F3 have adopted the Unified Process approach to develop an Intersection Monitoring System. This project will involve two iterations and therefore two milestones; inception and elaboration.
The following is the Software Architecture Document for the second milestone (ellaboration). It explores and validates the execution architecture.
System Purpose
The purpose of the Intersection Monitoring System is to improve the safety at intersections where there is poor visibility. The system will be employed by the NSW RTA to continuously monitor traffic patterns throughout the day and record unusual events such as accidents, speeding and red light offences.
Recorded data can be downloaded and analysed by an operator working at a central point. The central point will be notified of unusual events through messages. The two primary functions of the system can be broken down into:
- Recording the frequency of vehicle types (so that road usage can be determined)
- Recording of ‘unusual’ events and notifying a central point via messaging.
System Overview
The delivery of the system will be done in two iterations. In the first iteration an analysis of the stakeholders will be completed in the form of personas and narratives, to be used to further refine the requirements of the system. A set of quality narratives will identify the two key quality attributes of the system. A conceptual architecture view is developed using software architecture techniques after identifying the conceptual components. The elaborate on this view stereotypes, component responsibilities, data models, run-time and life cycle events and use-case maps will be used. In addition to this an initial execution architecture will also be completed along with a user-interface.
System Scope
In order to determine the scope of the system an analysis of the initial requirements was carried out. The system must be designed so that it encompasses all of the customer's requirements, but the design of the system should not be restricted to only the customers needs but also incorporate the needs from all the key stakeholders of the system.
The initial requirements of the system are vague and would not be sufficient to create the system only from these requirements. Through the use of software architecture techniques a set of refined requirements were defined.
Stakeholder Analysis
Key Stakeholders
The following lists the key stakeholders for the Intersection Monitoring System.
- Clients
- Government (Local and State)
- RTA
- Emergency Services
- Suppliers and Vendors
- General Public
- Vehicle users
- Residents
- Development Team
- Project Manager
- Product Architect
- System Developers
- Independent testers
- System Operators
Stakeholder Needs and Expectations
| Stakeholder | Government and RTA |
| Identify |
|
| Characteristics |
|
| Nature of their interests |
|
| Benefits to the stakeholder |
|
| Stakeholder | Emergency Services |
| Identify |
|
| Characteristics |
|
| Nature of their interests |
|
| Benefits to the stakeholder |
|
| Stakeholder | Motorists |
| Identify |
|
| Characteristics |
|
| Nature of their interests |
|
| Benefits to the stakeholder |
|
| Stakeholder | Suppliers and Vendors |
| Identify |
|
| Characteristics |
|
| Nature of their interests |
|
| Benefits to the stakeholder |
|
| Stakeholder | System Operator |
| Identify |
|
| Characteristics |
|
| Nature of their interests |
|
| Benefits to the stakeholder |
|
| Stakeholder | Development Team |
| Identify |
|
| Characteristics |
|
| Nature of their interests |
|
| Benefits to the stakeholder |
|
| Stakeholder | Insurance |
| Identify |
|
| Characteristics |
|
| Nature of their interests |
|
| Benefits to the stakeholder |
|
| Stakeholder | Residents |
| Identify |
|
| Characteristics |
|
| Nature of their interests |
|
| Benefits to the stakeholder |
|
Stakeholder Ratings
Stakeholders are given a promote and impede rate between 0 and 5 where:
- 0 has no ability to promote or impede and
- 5 has a significant ability to promote or impede
| Stakeholder | Promote(0-5) | Impede(0-5) | Comment |
| Government and RTA | 5 | 5 | Significant stakeholder
Stakeholder requests must be satisfied as they can stop the project but the stakeholder also wants to ultimately give full support to the project. |
| Emergency Services | 5 | 0 | Gives full support to the project |
| Motorists | 2 | 2 | Stakeholder cannot significantly impede or promote the system, but are the key users of the project |
| Suppliers and Vendors | 3 | 3 | Stakeholder can affect the outcome of the project |
| System Operator | 4 | 3 | Important stakeholder, without this stakeholder the system can potentially fail |
| Development Team | 1 | 4 | Important stakeholder, as stakeholder can stop the project |
| Insurance | 5 | 0 | Gives full support to the project, but has no significant impact on the project |
| Residents | 5 | 1 | Gives full support to the project, but has no significant impact on the project as Residents have little impedance to the outcome of the project. |
Stakeholder Priorities
| Stakeholder | Availability | Modifiability | Performance | Testability | Security | Useability |
| Government and RTA | 5 | 0 | 5 | 0 | 0 | 0 |
| Emergency Services | 6 | 0 | 4 | 0 | 0 | 0 |
| Motorists | 9 | 0 | 0 | 0 | 1 | 0 |
| Suppliers and Vendors | 0 | 0 | 10 | 0 | 0 | 0 |
| System Operator | 0 | 0 | 5 | 0 | 0 | 5 |
| Development Team | 2 | 2 | 3 | 3 | 0 | 0 |
| Insurance | 10 | 0 | 0 | 0 | 0 | 0 |
| Residents | 10 | 0 | 0 | 0 | 0 | 0 |
| Total | 42 | 2 | 27 | 3 | 1 | 5 |
After evaluation of the usage narratives, team members rated the importance of the quality atributes to the stakeholders from 1-10. It was found that the key priorities of the stakeholders are Availability and Performance, these will form the two key quality attributes.
System Narrative
To improve the safety of some intersections, the NSW RTA trialled a new monitoring system on the corner of Crown Street and Oxford Street in Sydney. The intersection has been a black spot for some years due to the difficulty of seeing other traffic and casual pedestrians. To find out what was happening, cameras continuously recorded the traffic. The characteristic sounds of an accident triggered the system to preserve the last few seconds of recording. Periodically, the stored recordings were downloaded and analysed.
This project will plan the next generation of highway monitoring. What is required is an unobtrusive way to monitor traffic either at an intersection or on a stretch of road and monitor what happens. The system will recognise different types of vehicles and record the frequency of each type so that the pattern of road usage can be determined. The system will also record any unusual event, such as an accident, and send a message to a central point.
The requirements are:
- Monitor the road usage by vehicle type and time of day.
- Record and report unusual events – accidents, speeding, red light offences.
- Notify the central monitoring point of unusual events.
- Notify central monitoring of potential or actual system failures.
- Provide a means to query the system from a central station
Usage Narratives
The following are narratives and personas to assist in understanding the stakeholder’s needs and expectations. From these, we established that the two key quality attributes required are availability and performance.
RTA
John, who is working for the RTA, is responsible for improving safety for road users at the Crown st and Oxford st intersection. John starts off by logging into the Intersection Monitoring System. The Intersection Monitoring System presents John with an interface that allows him to retrieve and view data recorded by the system including road usage by vehicle type and time of day, and frequency of accidents, speeding and red light offences. The data is presented to John in a visual manner with pictures and videos, as well as statistical information in the form of graphs and charts, with an option to export the raw data collected by the system. John analyses the different data presented to him by the system, and notices that accidents occur more frequently during the night. John deduces that this is caused by poor lighting at the intersection and decides to investigate this further using the data as a basis for the investigation.
Emergency Services
An accident occurs involving Daniel driving a motorcycle colliding with Poli's Hummer at the intersection where the intersection monitoring system is installed. Realtime video is fed into the video processing and is fed into the unusual event monitor. The unusual event monitor identifies an accident has taken place by recognising characteristics of the video and sound. Number plates are recorded and vehicle type are recorded and the last ten seconds of video is stored in the unusual event database. The unusual event monitor also sends details of the accident to the emergency notifier, which contacts an emergency service.
Tim is an operator for the GUI of the system. Tim is notified there has been a recent accident at the intersection and is presented a report outlining information relevent to the accident. Video of the accident can be replayed from the GUI to the operator.
Speeding and Red-light Traffic Offences
A motorist is identified by the system to be speeding at the intersection but his speeding does not cause an accident and there are no other vehicles or road users within metres of his path. His speeding is classified as an usual event so it needs to be logged. The system identifies this as an unusual event and sends the audio/visual of this event to the database. The above narrative can also be adopted for redlight offences.
Independent Testers
Michael is a representative of the RTA Information Systems Division and will be part of the proposed team that will gather data from the Intersection Monitoring System (IMS). databases. He has been invited by the development team to be part of the black box testing phase as the RTA will be a primary user of the data. He has no knowledge of the inner workings of the system but he knows what sort of data he wants to see produced by the system. He will be accompanied by a member of the IMS Design team who will be able to translate his business concerns into more specific technical requirements that will be passed onto the IMS developers.
Project Manager
Shane is the project manager in charge of the Intersection Monitoring System (IMS). As a software project manager, Shane is responsible not only for implementing a successful development model but also for seeing that each phase is successful whilst working with alot of uncertainty. Shane will assess the reports from subordinates to ensure that the project in on task and on time. Upon completion Shane will test the system by using a privately owned road and have a number of test drivers go past the IMS. Numbers will be controlled to ensure that there is a predictable output from the system. Shane’s main role is to ensure that all the requirements of the system are met.
Vendors / Suppliers
Bianca is the Managing Director of CamCor Pty Ltd, a small proprietary limited company that specialises in the design and production of specialised physical monitoring systems. They have received a requirements specification relating to the Intersection Monitoring System (IMS), to basically design and supply, or produce if necessary a physical monitoring system for the IMS.
The monitoring system will consist of motion sensors, high definition digital cameras, red light cameras and speed cameras. Bianca as Managing Director is overseeing the project and decides to outsource the supplying of the red light and speed cameras from the RTA as they already have an infrastructure in place. The cost savings in relation to research and development, design and production will be huge. All other equipment is supplied in-house and as a result, CamCor Pty Ltd may only need to create a way to integrate all the different visual monitors into a single data stream ready for processing.
Development Team
Phil is a Product Architect and is part of a team of developers who have been assigned to design and develop the intersection monitoring system. As a part of Phil's job, he is required to communicate regularly with the project manager and liaise with other stakeholders of the system to refine the requirements of the system.
Today Phil accompanied by the Project Manager, Shane will be meeting with the RTA in order to discuss their needs of the system. Phil and Shane clearly understand the importance of satisfying the RTA’s needs, as they are one of the key stakeholders involved in this Project.
The meeting goes well, Phil and Shane have been given a list of requirements by the RTA, which they then proceed to define into functional, non-functional, behavioural and information requirements of the system. Throughout the elicitation process with the RTA and other clients, a system requirements specification and a system design specification is produced which is used to develop the foundation of the system.
The system is built in iterations, with subsequent iterations providing more functionality as well as refining the requirements of the system. When the project is complete it is handed over to the RTA/Government, and a few developers are hired to solve defects within the system.
Residents
Scott is concerned about the dangerous traffic flow in his area; he thinks the intersection near his home is a potential black-spot. Regularly, he sees and hears cars screeching to a halt. He thinks a traffic monitoring system would be beneficial, he understands that it will not prevent accidents in the short-run but it may provide enough evidentiary support to have changes made to the intersection.
Insurance Companies
The chief operations officer at ACME Insurance is concerned with the time taken to settle claims on traffic incidents where there is little evidence of what really happened. He would like claimers to provide evidence in order to substantiate their claim in the event the involved parties are disputing. This will allow the disputing parties’ insurance companies to resolve the claim in a timelier manner and also see which party was at fault.
Vehicle Users
Simon is concerned with the changing traffic volume on his daily route to and from work. Each month it is taking him longer to get to work because he is stuck in traffic. Other road users presumably feel the same, as he has also noted an increase in road rage on his route. He thinks that the Intersection Monitoring System (IMS). will assist in providing evidence to the government to take proactive action in town planning so as to accommodate for changing traffic flow volumes. He also believes that keeping a record of traffic accidents will also assist in resolving who’s to blame for accidents (even the ones caused due to frustration and road rage).
Quality Narratives
Availability
The system is required to be online and in production at all times to be able to produce accurate data and signal the Central Point Monitoring System in real-time
The Central Point Monitoring System is to be signalled at the occurance of an unusual event. Unusual events are not foreseeable therefore the system requires a contant stream of audio-visual to be produced and recieved in order to evaluate in realtime whether an unusual event has occurred. Thus, the availability of the Central Point Monitoring System and the components that produce, send and recieve the streaming audio-visual data is critical to the purpose of the IMS. Any downtime in the flow of data between these system components can potentially result in delays or a lack of personnel response to the incidence.
Similiarly, analysts require data that truly represents actual occurrences in order to formulate and evaluate patterns in road usage. This road usage data does not have to be produce in real-time but needs to be accurate; ideally it would enable analysts to create statistics with a 90-95% probability confidence interval. Accessability of archived data is also important but not as critical; it does not need to be available all the time but would be ideal if it were accessible during working hours.
Performance
The system should notify the Central Monitoring Point in real-time of an unusual event, archiving the data immediately, whilst road usage data should be archived on a same-day, same-hour basis.
The camera system will capture a constant stream of audio-visual, of a stretch of road or intersection within 20 meters of sight at the audio-visual capture points.
In the instance of an unusual event occurring within the 20 metre range, the system recognises an unusual event instantly and sends a message directly to the Central Monitoring Point which will receive the notification within 1 second of the unusual event ocurring. Any delay or data error in this process will cause a delay in personnel being able to respond to the event. The data related to the unusual event is to be stored in the database and made accessible within 2 seconds of recognition of the event.
This means that there is a critical path between receiving/processing audio-visual, recognition of an unusual event, signalling the Central Point and archiving all the involved data. If these processes do not ocurr seamlessly the system will no longer be fit for its purpose to recognise and notify a central point of unusual events as they ocurr.
Other non-critical data, such as traffic monitoring need not be processed real-time but processed and archived at minimum same day on the hour basis so that the system has up to date information for that hour.
If for any reason, any system component fails to perfom (or potentially will fail to perform) then the system will send a message to the Central Point to notify of this.
Key Contextual Factors
| Factor | Constraint | Enabler | Risk | Criticality |
| Technology | ||||
|---|---|---|---|---|
| Availability of external systems such as Speed and Red-light Cameras to assist in recognising unusual events. | Interfacing the IMS system with many external systems may prove to be difficult to manage. | This can be used as one of the flags for recognising unusual events in combination with audio/visual. This will enhance the detail of the messaging service. | Reliance on these external systems to give input may cause delays in recognising unusual events. | Medium |
| License plate recognition system | There are certain ranges for which the system will be able to successfully recognise a license plate with error, eg speeding will reduce success. | Technology is available to recognise vehicle license plates. This can be crossed referenced with the RTA’s database of vehicle registrations. | The license plate may be swapped illegally between vehicles so this can only be used as a cross-check. | Medium |
| RTA vehicle registration database | The RTA only operates in the state of NSW so any plates from other states will not be recognisable | A license plate can be used to query the database in order to retrieve vehicle information | It won’t work if the plates have been issued and be inaccurate if they have not been reported as stolen. | Low |
| Audio recognition | Audio is used to recognise an unusual event such as an accident. | There can be ranges and combinations of frequency and amplitude that will match up with types of events. | Other environmental factors at the time of recognition can cause incorrect diagnosis of an unusual event. | High |
| Environmental | ||||
| Weather conditions can affect the accuracy of the monitoring system | The operation of the system will operate within a tolerable level of accuracy pending weather conditions | Good weather conditions | Weather that visually impedes monitoring devices will decrease the accuracy of the system and potentially damage the equipment. | Medium |
| Legal/Government | ||||
| Information and privacy | Government regulations may prevent the system from collecting particular types of information that may become available through the system | Information gathered will enable statistical analysis which can lead to building safer roads and being proactive with town planning. | Access to this database needs to be restricted because the data can be intrusive and used for other (illegal) purposes. | High |
| Notification of unusual events to the Central Point | The system can alert the central point of recognised unusual events. If the system fails to identify the event then this will fail. | Other external systems/services can respond to an unusual event. This is particularly useful if there were no witnesses to the event. | Lives will be in jeopardy if the system fails and this is the primary factor in deciding the success or failure of the system | High |
| Organisational | ||||
| Interpretation of the unusual event by personnel at the central point. | The system will notify of factors involved that caused the unusual event will not actually describe the event. It is still reliant on human intervention to interpret the event. | Visual footage allows personnel to watch the unusual event | If a person cannot diagnose the unusual event from the message received then they will be unable to coordinate an appropriate response. | High |
Assumptions:
From the above listed factors, the following assumptions regarding the system, can be made.
Monitor traffic
Records will be kept of the road usage by vehicles in terms of vehicle type, frequency and time. The purpose of this is so that the data can be downloaded and analysed for patterns in use. This will assist in town planning. Therefore, traffic monitoring will occur non-stop.
Vehicle Recognition
The system is required to recognise the vehicle passing on the road or approaching the intersection. This recognition is acheieved by recognising the license plate on the vehicle and matching it with a license plate listing in the database given by the Roads and Traffic Authority (RTA). This database has information relating to the vehicle type of all registered vehicles.
As such, the system assumes that all vehicles contributing to the traffic monitorring database will be a registered vehicle.
Unusual Events
The classification of an unusual event is important as it will determine what records are kept on file. The system narrative suggests that audio characteristics are used to classify an unusual event. With the use of off-the-shelf components, the system may use other characteristics to determine an unusual event, such as speed cameras, red-light cameras, thermal recognition etc.
Messaging
The purpose of sending a message is to notify the central point that an unusual event has occurred. This notification is likely to be used for the purpose of dispatching emergency services.
If the characteristics of the unusual event denote that assistance is not required, then a message to alert the central point will not be required. Thus, the system should distinguish between unusual events where assistance is required and when it is not. For instance, passing through a red light without causing a traffic accident is an unusual event but may not require notification to the central point. If in doubt, the system should alert the central point.
GUI
The GUI is the central monitoring point described in the software system narrative. The graphical user interface will allow the user to access the databases used in the system and download this data. The GUI will provide notifications of any unusual event and potential or actual system failures.
Effect of Contextual Factors on Ongoing Development and Anticipated Issues
1. Vehicle type database
Maintainability of the database should be considered as there will undoubtedly be new vehicles on the road that do not fit a classification in the database. These will need to be added to the database which means that the database cannot be read-only. A user interface to this database may be ideal as it allows for easy maintainability.
Initial thoughts were to recongise a vehicle by audio/visual characteristics but this may be quite complicated to achieve. If a vehicle is recnogised by a license plate (ie the license plate is crossed referenced with data from the RTA) then consistency may be easily achieved in terms of classification of cars.
The system should be able flexible enough so that further integration of other recognition systems is an option later on.
2. Flexibility for road and intersection use
The monitoring system should be operable for a stretch of road and intersection however the classifications for ‘unusual events’ may differ in some respects between these two scenarios. Flexibility in the classication of unusual events needs to be incorporated in the system. Ideally, the system needs to integrate some sort of library of unusual event classifications so that it is flexible not only for both an intersection and stretch of road but different kinds of intersections and roads.
Peak hour traffic may significantly increase CPU load and may affect the communication buffers between components. Reiterating that the system needs to perform at all times.
3. Classification of Unusual Events
Similiar to above, unusual events are classified by sensors triggered that sends messages to the system for interpretation. The classification of an unusual event may require evaluation by personnel as unusual events differ from each intersection and each stretch of road (case by case basis). The system needs to be flexible to tailer the classifications as required.
The system is required to contact a central point in the event of an accident on the intersection/road. It would be best to recognise all potential accidents (better to be safe than sorry) and have personnel interpret whether or not there has been an accident from the video footage. This may however result in some unnecessary calls to the central point and waste of resources.
4. Processing of Traffic Monitoring Data
It is assumed that as a vehicle approaches the stretch of road or intersection, the vehicle type will be recognised and archived immediately however it is priority that unusual events are detected. This means that there are potentially two concurrent activities at all times.
Conceptual Architecture
Conceptual Architecture Diagram
The conceptual architecture diagram is the product of analysing:
- usage narratives of how the personas interact with the system
- systems functional requirements, and
- desired quality attributes.
Initial Conceptual Architecture
The diagram below is the initial conceptual architecture; it explains the essential flow of data from one component to another depending on their responsibilities. It can be seen that the traffic monitor is provided data from the video processing component and uses the data from the car type database to process it the inflow of data into information to be sent to the traffic database.
Final Conceptual Architecture - Inception Phase (Milestone 1)
Through iterations of analysis and clarification of each component's responsibilities, inputs and outputs and cross-checking with the systems functional requirements and narratives, the final conceptual architecture was produced.
A dashed line box encompasses the whole system, internal and external components, allowing the components to send status data directly to the system failure monitor.
Final Conceptual Architecture - Ellaboration Phase (Milestone 2)
Using some use-case maps, the conceptual architecture was refined resulting in some of the responsibilities being moved around between components, and discussions were had regarding merging/splitting components in order to avoid blobs and command clusters.
Component Descriptions and Justifications
Video Processing
The video processing component will process video, sensors for speed and traffic lights (and perhaps other sensors that can be incorporated into the system, and also license plate recognition. This processing will attach a timestamp to all video and data parcels.
The video processing component will send a package of data to the unusual event monitor that will include the video and all the data from all sensors. The unusual event monitor will establish whether or not an unusual event has occurred.
The video processing component is a real time system as it processes live video and sensor readings, which are fed into the component via the camera system. At no time will the data be stored.
Traffic Monitor
The traffic monitor’s main purpose is to establish vehicle patterns over time by identifying car types which cross the intersection at different periods in time. These patterns are stored in the traffic database, which can be viewed for later use from the GUI (internal) or web interface (external). The traffic monitor does not store any video received by the video processing component. This component is also a real time system as it continuously processes the received data from the video processing component.
Car Type Database
The car type database stores the various vehicle types and specifications related to the vehicle. This information is retreieved when traffic is logged and unusual events occur.
RTA database
The RTA database will store all the license plates of registered vehicles and the type of vehicle that corresponds to that license plate. The vehicle type will be found only if the car is registed with the RTA.
Traffic Database
The traffic database stores the patterns of vehicle types crossing the intersection. The vehicle type, quantity and time of day are recorded. These patterns can be queried and viewed from the GUI component. This component is a persistent storage device, thus remains stored even if the system crashes or is turned off. Data should be protected from external entities trying to access it. Only the GUI and the traffic monitor can access this database.
Unusual Event Monitor
The unusual event monitor identifies the three main types of unusual events in realtime. These are:
- accidents
- speeding and
- red light offences
Only an accident will be reported to the emergency notifier, but all three events will be recorded in the unusual events database in terms of time, vehical involved and type of unusual event.
Number plates and speed of vehicles are recieved from the video processing component.
Emergency Notifier
The emergency notifier is a real time component which receives a signal and data from the unusual event monitor, related to an accident event occuring.
Unusual Event Database
The unusual event database stores data pertaining to the unusual event including:
- video data
- number plates of car/s involved
- type of unusual event (speeding, redlight breach, accident)
This component is a persistent storage device, thus remains stored even if the system crashes or is turned off. Data is to be protected from external entities trying to access it. Only the GUI, web interface and the unusual event monitor can access this database.
GUI
The GUI component is the only user internal interface able to access the unusual event database and the traffic database. The GUI is able to transform data from these databases into viewable and readable material for the user to see. This component is a presentation component whereby is a means for users to access the system. Data can only be read from the GUI and not changed. This protects the data from corruption and tampering.
Web Interface
The web interface component is the only external user interface able to access the unusual event database and the traffic database. Similiar to the GUI however it is password protected so that only select users are able to access this data.
System Failure Monitor
The system failure monitor collects the status from all internal and external components in order to identify potential or actual system failures. Instead of drawing a communication line from every component to this entity, a dashed line box that encompassed the system as a whole would connect to the system failure monitor. This allows our diagram to be easily understandable and establishes the responsibilities of the system failure monitor. After identifying a potential failure, the component will notify the GUI of the details.
Camera System
The camera system is the collection of cameras, microphones and speed sensors. Also the status of the traffic lights are included in this external component. The camera system sends video, audio and speed sensor readings to the video processing component continuously.
Emergency Line
The emergency line is a connection to emergency services which operates all the time. If emergency services are needed by the system, a connection is established and details are sent.
Data models
This is a more detailed look at the data structures used in the various databases in the Intersection Monitoring System.
Traffic Monitoring Database
• Traffic Logs to catalogue each and every single vehicle that passes through the intersection
• Vehicle Logs to catalogue individual vehicles that pass through the intersection
Vehicle Types Database
• Basic Vehicle Type structure that contains common elements that will help distinguish between vehicle types
• The Vehicle types database has been simplified to put less pressure on the system to recognise actual vehicle types. Instead we will recognise licence plate numbers and query the RTA vehicle database to retrieve information that our system would otherwise get. We will use this data to determine the vehicle type from our database.
Unusual Events Database
• The Unusual Event Type data structure is set up to identify the different types of unusual events that will be recognised by the system
• The Unusual Event data structure holds the records of every unusual event that occurs including the time of the accident, video file location and the type of unusual event.
• The 3 remaining data structures (UERedLightID, UESpeedID and UEAccidentID) are are inherited by the other two structures that carry more detail of each record that is relevant to the event in question. e.g. UESpeedID contains the speed of the vehicle that triggered the event - something the relevant only to this event.
• The Accident data structure has been extended to improve accuracy of its recognition by the system. We will use three different variables to determine if an accident has occurred. These include Audio data, Temperature data and Visual data. They will all have certain ranges in which they will fall in order to register an incident as an accident.
Use Case Maps
Speeding and Red Light Traffic Offence
In this particular use case map, the system determines a path when a speeding or red light offence occurs. The Camera System is responsible for detecting a vehicle speeding or going past a red light thanks to the speed sensors. Once the camera has captured the footage, it gets sent to a Video Processing Component which is responsible for adding a timestamp to the footage and identifying the number plate. This number plate is matched up with records from the RTA car register database which is accessed externally. A vehicle type is retrieved and is sent to both the Traffic Monitor and Unusual Event Monitor along with other key data.
The Unusual Event Monitor determines what type of event it is, in this case a speeding or red light offence. Since the vehicle type that is retrieved from the RTA car registry database is an integer, the Unusual Event Monitor uses the car type database to relate a vehicle type name to that integer so it knows the type of vehicle committing the offence. The footage is then given a timestamp and is sent to the Unusual Event Database for storage. Details of the unusual event are also stored in the database depending on what type of event it is. For a red light event, the set of lights which were breached are stored. For a speeding event, the speed of the car is stored.
This data can be retrieved from the Unusual Event Database which is described in the "Request Unusual Events" use case map section.
Accident
The Camera system continually feeds live video into the video processor which adds a timestamp to the video and buffers it for a reasonable amount of time. Once a characteristic of an accident is identified by the Unusual Event Monitor (includes temperature, sounds or visual identification), the last ten seconds of video footage is stored to be previewed later by the central monitoring point or accessed securely through the web interface. Details of why the accident was classified as an accident and relevant data such as vehicle type and number plate are stored as well in the Unusual Event Database.
The system then sends the information to the Emergency Notifier Component which contacts an Emergency Line to report the accident, giving the time of the event as well as the vehicle types involved. This can be used to determine the severity of the accident by emergency services. A pop-up will also occur on the GUI and web interface screen when an accident occurs.
Record Traffic Patterns
The Video Processing component interprets video images from the Camera System and identifies vehicle number plates. The number plate is cross referenced with the RTA car registry database and returns an integer representing the vehicle type. This data is given to the Traffic monitor, which processes the vehicle type and increments the relevant vehicle type variable in its system. After fifteen minutes of accumulating data, the Traffic monitor saves these accumulations into the Traffic Database along with a timestamp. This data can be queried by the GUI or the Web Interface and this process is described in the “Query Traffic Patterns” use case map.
Query Traffic Patterns
In this use case map the Central Monitoring Operator uses GUI's functions to send a query to the Traffic Database to retrieve traffic patterns of vehicle type frequency. The Traffic Database then sends the requested data back to the Central Monitoring Operator and is displayed on the GUI. The Web Interface has the same functions as the GUI but is accessed via the web.
Request Unusual Events
A user at the Central Monitoring Point is able to use the GUI to retrieve data and video footage (read-only) for unusual events that have occurred, from the Unusual Event Database. The user will select from the filters available on the GUI, which will send a request for the data.
Similiarly, a user can access information and video footage about Unusual Events from a Web Interface. The purpose of hte web interface is so that external users to the system (eg emergency services) is able to access information on Unusual Events.
System Failure
When any part of the system is running, each component whether internal or external will send status packets to the system failure monitor. These status packets can include available amount of storage free, buffer overloads and component modes. The system failure monitor will analyse these packets and determine whether there is a potential for the system to fail or the system has actually failed. Any time that a component fails, an error log containing important key information is stored.
The example above shows a VideoProcessorError event, which sends a status packet to the system failure monitor. The system failure monitor notifies the central monitoring operator by sending the failure details to the GUI component. The failure is also sent to the Web Interface if logged in at the time. The dashed box establishes that it encompases the whole system including the external components included inside the box. This is relevant as all components have a chance at failing and the central monitoring operator needs to be notified when this happens.
Execution Architecture
The execution architecture describes how each software and hardware element communicates in runtime. The video processing component is constantly processing data from the video and sensor system and sending it in realtime to the traffic and unusual event monitor. It can be seen that there are two concurrent activities, the traffic monitor and the unusual event monitor, both awaiting data from the video processing component.
The unusual event monitor and the traffic monitor both use synchronous calls with the databases as they are constantly populating the databases with parcels of data in a specific order.
Asynchronous calls are used by the unusual event monitor to call the emergency notifier to notify emergency services when an accident occurs.
The emergency notifier, system failure monitor and the three databases are service activities, and are only used when they are needed.
The unusual event monitor, traffic monitor, emergency notifier and system failure monitor are all real-time portions of the system and are active components.
The GUI and Web Interface activities are user initiated activities, and thus represented using callbacks. The user uses this process to interact with the databases of the system and also the system failure monitor.
Behaviour
The below diagram shows the behaviour of the system. These closely correlate to the use case maps shown earlier in the Conceptual Architecture.
The DetectSpeeding event is generated whenever a vehicle is travelling over a defined speed limit. Video and sensor data is processed by the Video Processor to give key data out in known variable types, which provides for easier processing by the Traffic Monitor and the Unusual Event Monitor. This allows both the Traffic Monitor and Unusual Event Monitor to concentrate on analysing data rather than processing video and sensor data. For the DetectSpeeding event, the Unusual Event Monitor will see the speed the vehicle is travelling at, and if over the speed limit, will make a record of the event in the Unusual Event Database. This same use case map can be adapted for the DetectRedLight event, which occurs when a vehicle breaches a red light. Instead of speed, an integer will be stored identifying the set of lights breached.
A DectectAccident event is generated when certain characteristics of an accident occur. From the data sent by the Video Processor, sensor information such as temperature and sound, and also using a visual identification of an accident are processed by the Unusual Event Monitor. If any of these characteristics are present in the data, the last ten seconds of video will be recorded and saved along with the relevant characteristic data. Also for accidents, a pop up window will appear no the GUI or Web Interface if logged in at the time the accident happens, displaying the details of the accident. In addition, details of the accident are also sent to the emergency notifier which contacts emergency services in relation to the accident.
Both the GUI and the Web Interface can request unusual events by the event requestUnusualEvents, which retrieves data from the unusual event database and displays the details pertaining to an unusual event onscreen.
RecordTrafficPatterns called as each car drives through the intersection. The Video Processor gets the number plate of the vehicle and matches it with the RTA car registry database to retrieve a vehicle type. This vehicle type is then sent to the Traffic Monitor and increments that specific vehicle type. Over fifteen minutes the vehicle type numbers are accumulated, and stored in the Traffic Database at the end of the fifteen minutes.
A QueryTrafficPatterns event can be called by the GUI or the Web Interface to display the number of cars passing the intersection in fifteen minute intervals. This query will return the number of each vehicle type for each fifteen minute interval.
Lastly, the SystemFailure event occurs when a specific component or system fails, or has the potential to fail, detailing information specific to that component/system. This information is processed by the System Failure Monitor, which reports any oddities or failures in the system, and sends a pop-up window to the GUI and web interface if logged in. Also an error report will be saved by both the specific system and also the System Failure Monitor, which ensures that all important data can be stored.
Concurrent subsystems view
The concurrent subsystems view is used to show the similar threads in our system, that is the video/data capture, monitor traffic/events databases and GUI. These are the units of concurrency within the system that do not change with time. As the concurrent subsystems view is meant to represent the system from a high level it does not clearly show the number of processes or threads that may be executing on multiple nodes. The different subsystems within a cluster can be run on separate nodes if required.
From the diagram we can see that data is constantly being captured by the video processing component.
Then, this data is sent to be interpreted by the traffic and unusual event monitors.
Up until now, all calls have been asynchronous, but once the data is sent to the database, some of the data is verified – ie requiring a callback.
The data can then be achieved at any given time by a user using the GUI.
Deployment Based View
The system will essentially have two server side machines handling system processes. The application server will take care of regular system functions ie. processing video, powering the database system, while the second server's sole purpose is to monitor for system failure in the main server.
The system allows for multiple users to access the system at anyone time, with two means of doing so, the UI client and the web interface, and these will interact with the central application server.
Implementation Architecture
Implementation Architecture Diagram
Implementation Architecture Description
There are essentially two interfaces for users to access the system, a web based interface and a desktop interface. The web based interface will be implemented using the Freemarker template system and running on a Jetty powered web server. The desktop interface is implemented in Java using Swing.
The two interfaces then communicate with our central application components which are written in Java. HSQLDB databases will be used to store data for the system.
Also, the system makes use of the RTA's vehicle registry database as a off the shelf component. This is to help improve the accuracy of the systems vehicle recognition system by allowing the system to verify a car number plate with the information stored in the RTA's databases.
The camera system is another off the shelf component used in the system, which will provide video, audio, and speed data for the system to process
Critique of Architectural Design, Issues and Constraints
Introduction
In order to develop our prototype, we made use of Java code and we mainly made use of the Eclipse IDE to develop the required code. The Eclipse IDE was a very appropriate tool for the coding as it enabled us to combine different technologies such as add-ons and components which aided us on the development in a massive way. We used SQL scripts for the generation of our database tables and combined the two to produce our prototype. The use of Tortoise SVN for subversion purposes also allowed each member of the group to submit code and modifications to the prototype. This added a useful revision history and made it easy to submit development changes simultaneously while being careful to avoid conflicts or code overrides.
We also created a web interface for external users of the system. The web interface shows the data stored in the databases for relevant stakeholders such as emergency operators or the RTA to be able to view traffic patterns and unusual event information; information necessary to achieve the initial requirements of the Intersection Monitoring System.
Strong Points
Object Oriented Design
In regards to the architectural design, it is worth mentioning that we took an Object-Oriented approach to build the code in our system according to specifications and the chosen architectural design. This design enabled us to build a system with many classes and methods dedicated to single tasks showing independency and high cohesion. We followed our architectural design as closely as possible ensuring we had the databases specified storing the required data.
Since we have used Java code to develop our prototype, the system has been designed to have high portability meaning we are able to use it across different platforms such as Windows and Linux. This reduces compatibility issues and increases the possibility of us running the prototype in many different setups. Another strong point to mention is the large scalability of our program thanks to the high cohesion achieved as each method focuses on single functions due to each object being separated accordingly. This reduces stress load on the system as well as making it less probable for crashes to occur.
Weak Points
Business Logic
The feedback received implied the need to structure the code into different tiers such as data access, business logic and user interface. This separation would have ensured a more streamlined process as well as a more logical approach to coding the system. In order to achieve this architectural design, a separation of layers needed to be identified as well as the behaviour of each layer depending on their functions.
While this code separation into tiers may have created extra amount of work, especially during the design stage, this feedback was extremely valuable as changing the system to behave this way (separated into tiers) would decrease coupling or dependence and would make the implementation of any necessary extensions or upgrades easier.
Runtime and Redundancy Issues
Also during runtime, our prototype opens a new window whenever an accident occurs. While this may seem OK at first as not many accidents are likely to happen for an extended period of time, when multiple accidents occur in a very short timeframe or a large one such as a pile-up when the IMS is likely to detect each vehicle involved as an accident, it may create redundancy. Also during the presentation, a pop-up was occurring every few seconds. This was due to the way the prototype was coded and only to demonstrate that the function worked, but a similar situation can be expected when multiple accidents are detected which we would need to find a way to avoid.
Purpose of the Prototype
The prototype assisted in creating a system that monitors traffic and events occurring in an intersection. This system is responsible for storing traffic patterns, unusual events occurring such as accidents, speeding and red light offences. In order to make this possible, system access to databases was needed. The databases were created by SQL scripts which generated the necessary tables and fields. These databases include a User database which stores access user names and passwords for users to have access to the system, a Traffic database which stores details of vehicles going through the intersection and are used for the purpose of keeping traffic patterns and an Unusual Event database which stores information on accidents, red light and speeding offences.
Conclusion
The system seems to perform well within the quality objectives. The prototype shows a functional system that saves events and traffic patterns to the database as they occur. We found that we have built a solid foundation to a system that could be implemented into the given scenario of cameras monitoring a given intersection. We built this prototype having in mind that it needed to be designed for it to be implemented into an already existing monitoring system.
The system performs well and establishes a solid connection to the generated database tables. It is this kind of efficient real time communication that is needed when interacting with the databases in this kind of system, as traffic and events happening at an intersection can occur quickly at any given time so the system needs to be available at all times. This has been achieved as both the main Java interface as well as the web interface can be accessed at any time.
Following our architectural design was not a major issue when developing the prototype. We ensured every section of the implementation and execution architecture was covered in our prototype and can be clearly seen by the creation of different databases, and different classes representing each section of the system as can be seen in our implementation and execution architecture diagrams. The separation of the system into tiers would have been more appropriate for our business logic but was not implemented due to time constraints or inadequate planning.
Overall, we are quite satisfied with the outcome and have learned a lot from this project as we have approached it in a different way by starting from an architectural design perspective and translating that into a working prototype.
Presentation
Media: F3-presentation-M1-31278-48433-S08.zip Upload file toolbox would not let us upload it as a .ppt.
References
Rajagopal, P et al. 2005, A New Approach for Software Requirements Elicitation, IEEE
Reekie, J. and McAdam, R. 2006, A Software Architecture Primer, Angophora Press, Sydney.
Reflections
Vi Chea 02051136
Software Architecture is not like any other software development subject I had done before in terms of concepts and practice. Up until now I had never really made much use of software prototyping nor thought of using narratives for requirements analysis.
At first, it was quite challenging to see how some of the steps such as narratives and use-case maps, fit in with the overall picture. I later realised that creating use-case maps was all part of analysing the functional and non-functional requirements of the system. I found myself referring back to the use-case maps during the initial prototyping phase. I would even say that I would use use-case maps again as it is a more practical way of conceptualising the system - previously I would analyse what was required by simply brainstorming all the possibilities of input/output combinations.
Prior to this subject I had only really extensively used the waterfall model to develop software so it was difficult to get out of this mindset. In discussions with my team it was sometimes difficult for us all to stay focus on the initial prototype without jumping ahead and thinking of all the other “what-if” scenarios. For a while we had a number of discussions that probably could have been more productive but these discussions were essential as it lead us to our turning point – the blob.
We started with a ‘blob’ and slowly worked our way into command clusters. This paved the way for the rest of the project as we now all had a better understanding of the logic behind the system, and the responsibilities of the components. This was done well, and the end result prototype was good however we could have further improved by structuring using business logic (maybe next time).
Compiling work on Wiki and using Tortoise was also new to me. This was the first time I had used it to produce deliverables for a subject. This worked well as it made it easy for all team members to see how we are progressing. It also allowed us to manage our time individually better too. I quite liked using Eclipse for development (again also new to me) – much easier and sophisticated than BlueJ by far, makes programming a breeze.
I was quite happy with the execution architecture, it showed that we put quite a lot of thought into the conceptual architecture, reiterating the relevance of using use-case maps.
Overall, I thought the Software Architecture Document and the Executable Prototype was challenging but rewarding. I would definitely use use-case maps again and also conceptual and execution architecture diagrams. These tools made it easy to explain and understand relationships and forced us to justify our logic and understanding of the system.
Timothy Cheung 10307306
I learnt about Software Architecture and its importance in software development. Design processes and tools alone are not sufficient in building software that is scalable. Like constructing and building, the architecture must be correctly completed before even a foundation is put down. I learnt how to approach software architecture by describing the system as a whole, then breaking it down into components. After the components have been established, relationships are developed between the components to meet the requirements of the system.
To originally build the picture the use of narratives and personas was employed. This gave us an understanding of the expected outcomes of the system for different stakeholders, and the problems it would solve. Contextual factors were used to define the stakeholders and link their importance to the system. In the case of the Intersection Monitoring System (IMS) the key stakeholders were the governments and the RTA. Functional and non-functional requirements were established to determine the key quality attributes of the system. These attributes are constantly referred to throughout the architecture process. Use case maps are used in correlation to developing a conceptual architecture. The use case maps help us show the relationship between different components, and how they as a whole are used to execute different functions of the system. The different execution architecture views allow us to see concurrency within the system and establish its behaviour by again using use case maps. Finally a corresponding deployment view completes the execution architecture, it is a high level way to show how the different applications will be developed, such as Java, Html, HSQLDB.
Taking the execution architecture we had just developed, we started to build an executable prototype. For this project, we used eclipse, which is a powerful development tool if used correctly. Even after two milestones, I am still discovering neat little features in eclipse that makes development so much easier. The whole project is tied together in packages and projects for compilation. Paired with TortoiseSVN it made collaborating code much more efficient.
Having a solid architecture gave our design more purpose; there was more direction towards the objectives of the assignment. Usage narratives allowed us to establish the requirements of the system. Unfortunately for most of our project, especially in the first milestone there was little relation between the design architecture and the prototype, we misunderstood architecture as a whole, as indicated by Tom McBride.
We found use case maps one of the most useful architectural tools, for drawing relationships between components. We also found that the contextual factors were not really useful.
The only problem with our teamwork is that there was no key decision maker, but once decisions were made the team worked cohesively and there were no conflicts.
Overall I have been very pleased with this project, because there has been so many useful things to learn, which can be applied later in life.
Christopher McDermid 10300768
Software architecture has taught me that it is not an alternative process for software development, but is included in this process. Including software architecture in software development provides the means by which stakeholders are considered, contextual factors are researched and requirements (both functional and non-functional) are identified. This provides the system we are designing with a very solid foundation to begin with and ensures that all aspects of design issues are met.
I found stakeholder analysis very similar to the processes used in software engineering but were considered to a higher degree. This was because only a few vague requirements were given in the case study, where as the software engineering subject already had a requirements matrix to sort through. Non-functional requirements were also considered, the main ones being availability and performance, and ensured we accounted for these in all stages of the project. These would play a major role if designing a system in real life, as if these aren’t met, the client would be unhappy, your business would lose their reputation and you wouldn’t get paid.
I first considered this subject quite informal as we mainly brainstormed usage narratives and then transformed those into our conceptual architecture which made sense the more we progressed. By actually drawing use case maps on our conceptual architecture allowed our group to constantly refine our systems and add any that were missing. This process ensured our system took into account all the stakeholders’ needs and outlined the feasibility of the system.
Then, from transforming the conceptual architecture into execution architecture, I realised this provided more information on how these systems communicated with each other without actually having to do any coding or being implementation specific. This allowed our first prototype to be made with ease.
Designing the implementation architecture we were allowed to choose from any technologies we wanted. Starting from wild outlandish ideas, we soon realised we had to use these technologies to implement our system in real life, not just document it. These became more realistic and decided Java would be the best way to implement it since the labs were in Java and had everything we needed to complete the system.
Integrating hsqldb into our code was very time consuming. Heaps of run time errors occurred if not set up correctly and quite a bit of work had to be done to transform the already provided functions into usable code. Unfortunately, being short on time, quite a lot of quick fixes were made which affected the intrinsic documentation of our code and the integration of business logic into the design of the system failed miserably. On the other hand, due to careful structuring of our code, the system performed very well whilst testing using a traffic generator stub which generated heaps of traffic and events for the tutor to see.
Due to the fact most of our team worked quite often and each had busy lives, meeting up was very difficult. Most communication was by email and also had a badly setup Skype conference, where one team member communicated through a mobile phone speaker into another team members microphone to be a part of the meeting. This reflected upon the dedication of each team members’ willingness to participate in the project.
For next time, I wish if everyone could have more time to dedicate to the project, but that is a fact of life that everyone has other things to do and their own deadlines to meet. I only wish our tutorials were more productive instead of thinking about how vague or not we were supposed to be in our diagrams.
Overall I found the subject very interesting as it allowed me to experiment with different technologies I haven’t used before such as the “ant compile”, shell scripting and also hsqldb which may come in handy later in life. Also, designing the conceptual architecture using the usage narratives instead of formally creating a requirements and design specification was thought provoking and a fun method to use.
Diego Sing 10454181
This subject has expanded my point of view when it comes to software development in a big way. I am now more aware of what happens behind a software system other than code being compiled and executed. Coming from a software development background, I still had a somehow narrow view on the way software functions on the back end. I mainly focused on functional requirements when developing software but now I will be focusing more on the architecture and non-functional requirements. I will keep the architectural side in mind a lot more from now on when developing software.
This subject enabled me to understand technologies I had worked with before a little better such as Java programming in an object-oriented way, the development of SQL scripts and especially subversion to allow us all to submit our code and progress in the prototype in an easy and simple way. Subversion had many options to ensure there were no conflicts and inconsistencies when submitting our progress. Making use of a wiki was also a great tool and idea when developing our documentations as it gave the group a simple and effective way to submit our work at any time. I would probably rate the tools given to us in order to submit and work on our project as one of the main highlights of this subject. The only probable omission to all this is probably TeCTra which was really ignored by the whole group. Being an IT student I have used TeCTra extensively for other subjects but I found that being only optional for this subject really deterred us from using it. This was also due to the fact that submitting our work hours for this project was not possible and that issue never seemed to have been rectified.
Being the only IT student in the group I enjoyed participating and interacting with my group members as well as seeing things from an engineering perspective in certain occasions. Working with the team was a good experience as everyone was proficient and knew what we needed to do for every stage of the project. I do feel, however, that time constraints affected our progress a little at times and I must add that we tended to focus on the project a lot more towards the end of each deadline which I cannot put an excuse on rather than the need for group members to work on other subjects and some disorganisation. Our group meetings were mainly held on Thursdays, but we had the opportunity to get together on different days on some occasions especially when the work assigned was not very clear and we needed to sort some issues out as a group. It also helped with task allocations so no conflicts were created between members.
Lectures were short but clear and straight to the point. Each architectural view was explained in a good way with appropriate examples on each of their use and concept. Questions were also answered satisfactorily when asked. I did not find tutorial particularly useful in regards to teaching concepts about the subject as they seemed more like a meeting between the group in regards to the milestones, I would like to mention that a few doubts were cleared though. The labs were somehow useful in understanding how to use the technology that we required for the development of the prototype, but was still mainly used as a meeting period for the group to discuss the project delivery.
In regards to the delivery of the project, I found that I learned a lot on how to structure a final model for demonstration as well as the ability to present it in front of a group of people. The peer reviews were also quite useful as it allowed us to be evaluated from a student’s perspective which sometimes can tell you a lot more than a teacher’s perspective. This was not new to me, however, but increased some of my skills when evaluating my peers and delivering presentations as it felt somehow different.
Overall, I found the subject quite useful and as already mentioned, expanded my point of view when developing software. I will take these valuable learning with me in future subjects and for work and life situations.
Daniel Tran 10303699
This subject was different from previous subjects in that it was probably the first subject in which non-functional requirements were formally taken into actually taken into consideration. In the past non-functional requirements may have been something I have considered in my head, but not something that necessarily had to be addressed. Additionally, there were many different architectural views that needed to be developed for the system, and so I learnt how to the various diagrams to represent the views.
The process of creating the document involved meeting during the standard class times to discuss the main issues that needed to be addressed for the milestone. Outside of these times, contact was made through mainly email. I think that having meetings times outside of class times would have been beneficial to the group, but timetabling constraints in the group meant that it was hard to get everyone together in one place at the same time.
Tasks were therefore delegated during the meetings or through email, and it was up to the individuals to follow up to the tasks assigned. Task delegation didn’t really work as well as it could have though, as I guess there was a problem with accountability and organization. Tasks that were set were not necessarily completed on the agreed time, and in the end time management was an issue in both milestones, as 90% of the required work occurred during the last 2-3 days before the due date. In the end it comes down to the dynamics of the group and an reluctance by group members to take charge and lead the group, which I would assume to be because of the added workload one brings onto themselves when they do.
However, our meeting times in class were generally useful, and needed to clarify and smooth out any issues before jumping into work. Overall, the meetings moved through relatively smoothly, especially having a look at other groups in our class who seemed to be arguing over the smallest details, although there were times where there was some disagreement and confusion in regards to design decisions in the system.
During this project I felt that the use of a wiki was a great tool in helping the group collaborate on the assignment when it came to time to work on the documentation. I am sure that the wiki has saved us a lot of time in regards to this area.
TeCTra was ignored by most of the group members. As most of the members in our group we already had a pretty good idea of each other’s working habits, and as TeCTra was not compulsory, it was ignored. The hassle of updating TeCTra every week was just too high and for what seemed like minimal benefits.
Polikalepo Tuaileva 10311227
Software Architecture is a very ambiguous and challenging subject where I learned new ways to represent software design from a more detailed engineering perspective. It was challenging to learn the different methodologies of representing entities and different technologies (from web technologies to simple high level design).
Our group started off a little disorganised due to a mixup with the teams. We all agreed on the same project for various reasons, mine being that we were all familiar with traffic intersections from our everyday lives. Our disorganisation because, as usual we left things to the last minute and had difficulties implementing our design when it came time to code it.
I personally had to modify the threaded server program from lab one and integrate it into our system. This was the heart of the system. I had difficulty as I had to learn about things that were unfamiliar to me including threading, servers and sockets and their implementation in Java. However, with help from team mates we made a successful first prototype that matched our architectural design, to a degree. For milestone 2 we randomly generated data to simulate information being supplied from external databases, whereas we implemented internally our own databases using HSQLDB.
The technical part of the milestones helped me learn apart about how an overall system may be implemented in the real world, through the integration of databases and a back end system. In saying this, learning how to use the Eclipse IDE was somewhat simple in terms of understanding what we needed to do to implement our assignment. The most pleasant feature was Javadocs that showed us what a function or class does when the mouse pointer hovers over it. There are still a lot of features that are hidden from me, which is some thing that I will look forward to learning about in the future for other projects.
The majority of Milestone 1 and Milestone 2 focused heavily on the extensive documentation of our software architecture. The lectures were useful in introducing to us the new diagrams but we weren’t sure how much detail to go into with the architecture. We understood that it needed to be fairly high level however, how much we needed to break down the entities was unclear. These uncertainties in design would translate to our coding implementation.
Due to the fact that most of us were either working, had class or other commitments, it made it difficult for us to find a single time to meet where we could all be consistently available. Therefore we had to communicate mainly via email and allocate the work to each person either individually or in groups. We didn’t find Tectra to be a necessary component of our teamwork as we all had a notion of what had to be done.
