First, our team put up a short introduction of the usage and applications of our project E-Sing targeted on the tourist upon arrival in Singapore. We did in a different way this time round without using Powerpoint for our presentation but with the knowledge I have gained while working in Motorola by using their emulator of the Mobile phone to present the software that represent part of our application to the class.
This emulator actually behaves just like our mobile handsets that able us to run and test our application software written in Java programming language. And thats how we are able to present to the class how actually this BuSmart application which is a mobile Bus Directory of the Singapore Bus system that can be run in a mobile handset environment.
Anyone interested in this Motorola emulator application and wants to learn more on how to design their own mobile application to run on their mobile handsets can sign up as a menber and learn more about it in MotoDev website. This is a mobile application developer club set up by Motorola Electronics to encourage more mobile application developers to come together to share and learn more about mobile applications development. Here is the link:
http://developer.motorola.com/
However, team Visionaries once again caught my attention with their Creative and Interactive application user interface design with the help of Flash media. I thought their application is rather innovative with the use of sound and visual effects to enhance the user experince and catches user attention. Just like Prof Gilbert had mention, initially it's not very clear of what is to be expected on the menu bar. But once you start to interact with the application, it started to attract your attention and ultimately makes you want to find out more about it.
And this leads to the day seminar topic on "Interactive Designs".
We touched on the Critical Design Trends that an application designer should look into while trying to work on his/her application development. Prof Gilbert move on to play a very simple game with us to illustrate to us the most important factor to take note of while designing our application for the users. This game required the two players to each take turn to choose a number for a set of numbers between 1 to 9 till either side got a total of 15 from the addition of the numbers each pick. The class take quite awhile to figure out how this game should be played and this caused quite a number of confusion among us. Prof Gilbert then came back to explain to us the concept of the same game could be made easier to understand with the introduction of simple symbols like X and O that we are more familiar with the game Tic-Tac-Toe. And this illustration of effective design concept makes all sense to me how much a different it can be when you are able to present your design in an Interactive yet Simple and Attractive to the users.
We also discussed briefly on the Used Case designing concept that can help in the process of system designs. Software Engineering is the key to the effective software system design process. And here is some addition information I have found out about Use Case study to shared with you guys.
An important part of the Unified Modeling Language (UML) is the facilities for drawing use case diagrams.
Use cases are used during the analysis phase of a project to identify and partition system functionality. They separate the system into actors and use cases.
Actors represent roles that can are played by users of the system. Those users can be humans, other computers, pieces of hardware, or even other software systems. The only criterion is that they must be external to the part of the system being partitioned into use cases. They must supply stimuli to that part of the system, and the must receive outputs from it.
Use cases describe the behavior of the system when one of these actors sends one particular stimulus. This behavior is described textually. It describes the nature of the stimulus that triggers the use case; the inputs from and outputs to other actors, and the behaviors that convert the inputs to the outputs. The text of the use case also usually describes everything that can go wrong during the course of the specified behavior, and what remedial action the system will take.
Use Case Diagrams have low information content.
Use case diagrams don’t tell you very much. They convey the structure of the use cases, but tell you very little about the text within them. As such, they are not particularly interesting documents when they are separated from their textual descriptions. At best the diagrams provide a nice roadmap of relationships so that readers can reconstruct the whole text of a given scenario by tracing through the «uses» and «extends» relationships inserting the text of the former, and modifying the text according to the latter.
Use cases are powerful tools for analysts to use when partitioning the functionality of a system. Use case relationships and the corresponding diagrams help analysts to structure use cases such that their textual descriptions contain a minimum of redundant information; thus making the whole text document much easier to maintain. But use cases are not design tools. They do not specify the structure of the eventual software, nor do they imply the existence of any classes or objects. They are purely functional descriptions written in a formalism that is completely separate from software design.
For more information and details why not check out these sites:
http://pigseye.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/use_case.htm
http://www.agilemodeling.com/artifacts/useCaseDiagram.htm
That's All for this week Folks...
http://developer.motorola.com/
However, team Visionaries once again caught my attention with their Creative and Interactive application user interface design with the help of Flash media. I thought their application is rather innovative with the use of sound and visual effects to enhance the user experince and catches user attention. Just like Prof Gilbert had mention, initially it's not very clear of what is to be expected on the menu bar. But once you start to interact with the application, it started to attract your attention and ultimately makes you want to find out more about it.
And this leads to the day seminar topic on "Interactive Designs".
We touched on the Critical Design Trends that an application designer should look into while trying to work on his/her application development. Prof Gilbert move on to play a very simple game with us to illustrate to us the most important factor to take note of while designing our application for the users. This game required the two players to each take turn to choose a number for a set of numbers between 1 to 9 till either side got a total of 15 from the addition of the numbers each pick. The class take quite awhile to figure out how this game should be played and this caused quite a number of confusion among us. Prof Gilbert then came back to explain to us the concept of the same game could be made easier to understand with the introduction of simple symbols like X and O that we are more familiar with the game Tic-Tac-Toe. And this illustration of effective design concept makes all sense to me how much a different it can be when you are able to present your design in an Interactive yet Simple and Attractive to the users.
We also discussed briefly on the Used Case designing concept that can help in the process of system designs. Software Engineering is the key to the effective software system design process. And here is some addition information I have found out about Use Case study to shared with you guys.
An important part of the Unified Modeling Language (UML) is the facilities for drawing use case diagrams.
Use cases are used during the analysis phase of a project to identify and partition system functionality. They separate the system into actors and use cases.
Actors represent roles that can are played by users of the system. Those users can be humans, other computers, pieces of hardware, or even other software systems. The only criterion is that they must be external to the part of the system being partitioned into use cases. They must supply stimuli to that part of the system, and the must receive outputs from it.
Use cases describe the behavior of the system when one of these actors sends one particular stimulus. This behavior is described textually. It describes the nature of the stimulus that triggers the use case; the inputs from and outputs to other actors, and the behaviors that convert the inputs to the outputs. The text of the use case also usually describes everything that can go wrong during the course of the specified behavior, and what remedial action the system will take.
Use Case Diagrams have low information content.
Use case diagrams don’t tell you very much. They convey the structure of the use cases, but tell you very little about the text within them. As such, they are not particularly interesting documents when they are separated from their textual descriptions. At best the diagrams provide a nice roadmap of relationships so that readers can reconstruct the whole text of a given scenario by tracing through the «uses» and «extends» relationships inserting the text of the former, and modifying the text according to the latter.
Use cases are powerful tools for analysts to use when partitioning the functionality of a system. Use case relationships and the corresponding diagrams help analysts to structure use cases such that their textual descriptions contain a minimum of redundant information; thus making the whole text document much easier to maintain. But use cases are not design tools. They do not specify the structure of the eventual software, nor do they imply the existence of any classes or objects. They are purely functional descriptions written in a formalism that is completely separate from software design.
For more information and details why not check out these sites:
http://pigseye.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/use_case.htm
http://www.agilemodeling.com/artifacts/useCaseDiagram.htm
That's All for this week Folks...
2 comments:
Hope you enjoy creating your blog, as I enjoy reading it!
I thought of stop writing my blog with the heavy workload ahead and your good comments last week in class that I could stop. However, I guess I am getting Hook to posting my 2-cents worth of information as well as enjoying my friends reading my blog. I do enjoy writing whenever I am free to do so. Cheers!
Post a Comment