Task Code Mater Module

M3

Module Name

Software modeling and specification

Assignor

Feijs, Markopoulos, Hu, Qian

Task Completed

Yes

Competency Area(s) Developed

Integrating Technologies (Software modeling and specification)

Competency Area(s) Developed and Competency Levels Achieved

• You have learned different notations in UML and applied those techniques in designing an add-on for an instant messaging system.
• You have obtained basic understanding of object orientation.

Feedback on Competencies Developed and Levels Achieved

• You showed us you are capable of using UML to a certain extend, especially the use case diagram and the class diagram in the analysis phase and the early design phase in a software development project. What seemed difficult was deciding the scope of a use case. As the problem you worked on opened up the box (you were always aware of the system structure into client, server and add-on), it was difficult for you to distance yourselves and write use cases for user tasks. This would be easier if you try to apply use cases in a design project, where abstraction level and scope follow directly from a consideration of user tasks and without reference to systems structure. In all very good progress for the little time they had.
• The state machine diagram and the sequence diagram you presented lacked consistency, and a better understanding of how these diagrams should work was expected. However it was your first attempt to speak a new language, we did not expect you to be fluent.
• There was a gap between the design you presented using the UML diagrams and the implantation in Java. We understood that this was due to the limited time and you had to break the serial design-then-implementation to a parallel one.

Feedback on Deliverables

• The final presentation shows that you have achieved the basic goal of this module: understanding what a formal specification language can do and why it is needed.
• The emotion add-on for the instant messaging package worked, although it appeared to be buggy during the final presentation.
• It was very good that you presented your add-on together with the UML class diagrams. It showed that you had developed an object-oriented way of doing things – and that is exactly where the UML is designed for.

Feedback on Assignment Approach and Attitude

• You showed interests and attention to the lectures and actively participated in discussions.
• You liked to get hand-on experiences by working on given examples during lectures. Good.
• You have been very attentive, hard working and fun to work with. You got into the spirit of writing use cases and representing them with use case diagrams and activity diagrams.

Advice

• You need to practice UML more in other projects and modules whenever you need to express your idea to the users and the engineers. Do not invent a new language where there is already a common one with rich expressions. More specifically,
  • In requirement analysis, more attention should be paid on understanding of use cases. To do so, writing down textual use case description is a must. Using activity diagrams to describe dynamic behaviors is also needed (in the final presentation no activity diagram was demonstrated by students). Furthermore, try to be precise when using elements in diagrams.
  • In static domain modeling, you should be aware of design steps and design decisions. First classify words (nouns and verbs) in user requirements and define initial domain model and refine them thereafter. Try to follow the steps described in the handouts. Also, you should be conscious about your decision-makings and justify each design decision.
  • In dynamic behavior modeling, you should be aware of design steps and design decision as well. First, derive sequence diagrams from use case descriptions. Then, work out collaboration diagrams. Next, build and refine state diagrams. For details, please consult the handouts related to this topic.
• You can consider the UML as a communication tool for you to communicate with the user and software engineers. Your UML diagrams need not to be perfect and accurate – that’s a job for software designers, however, they do need to be communicative and understandable.