Formal Software Specification (UML Modelling)

May, 2006

Contents

  1. Module Description
  2. Schedule
  3. Project
    1. Format
    2. Zoo of Tamagotchi animals
  4. Modelling tools
  5. Feedback to and from the teams

1. Module Description

A product with sensors, actuators and network connections can offer an interesting, useful, or playful behaviour to its users and to the other products, systems and services to which it is connected. The ID Master takes responsibility for the creation of this behaviour. If the product isn’t stand-alone, neither is the designer. Whenever product behaviour is realised through computer software and protocols, the designer takes advantage of being an excellent communicator in these matters. In present-day software engineering, the Universal Modelling Language UML has become widely accepted. It contains “activity diagrams”, “use case diagrams”, “class diagrams”, “state charts” and “message sequence charts”. The knowledge and skills that students get by participating in this module will help them to express the structure and behaviour of the software components in their design in a way that is understood by third parties. Starting from elementary programming skills, which are a prerequisite, the student will develop an understanding and appreciation of what it means to master complexity. The scope is widened from small programs to real complex software systems. Although developing and maintaining such systems usually involves computer scientists as well, the ID Master will be well equipped to use UML and thus specify system structure and desired behaviour.

Jun Hu, Yuechen Qian, and Loe Feijs will work together to provide background information, explain UML and create a learning experience in which reading UML, writing UML, and creating software come together.

Philip Ross is invited to give a lecture on the mothodolgy of acting out and his experiences in applying this method in designing products.

2. Schedule

3. Project

3.1. Format

Students are divided into teams. Every team gets the same task: Designing a system called Zoo of Tamagochi Animals:

Don't worry. No Java. No C++. No programming at all.

We are not going to do real software implementations. We will implement the system by acting the specification out to show how the system should work according to the specification. Students can play the objects, showing their behaviors and the communication in between. Stage tools can also be used to represent objects, interfaces, and events etc. We will need some imagination and creativity.

3.2. Zoo of Tamagotchi animals

A preliminary description of the requirement:

4. Modelling tools

5. Feedback to and from the teams

You have learnt the knowledge and skills that help to express the structure and behavior of the software components in their design in a way that is understood by involved parties. You have developed an understanding and appreciation of what it means to master complexity and to communicate it with engineers.

We appreciate that all the teams did their best to actively follow the lectures and practice with the exercises. The method of acting out the UML diagrams instead of implementing them using programming worked remarkably well, thanks to the efforts that all of you have put in the module.

Note that in one week of time, it is impossible to grasp every detail of UML and to make the diagrams perfect. Hence we are not going to give feedback on your diagrams here, except the comments that were given during your presentations. Again we would emphasize that there is no diagram that is absolutely right or wrong. A UML diagram is a good diagram if it helps to express what is in your mind. More accurate is better. More consistent is better. Whether it is a good design is yet another issue - but as all of you have found, the formal specifications of the zoo you made did help you to clarify the concepts and to find the design flaws.

As we have already pointed out, this model tries to give you some taste of a formal specification language (UML) and its use in a design process. The focus was not on the diagrams themselves. But we did not mean that you should not continue to explore object-oriented design and formal specification methods. As we all found out, combining formal specifications and acting out in design cycles (even small cycles in spiral design or agile design) can be a good method in a design process. To put this method into your collection of design gadgets (or in your designer's words, to get this method into your portfolio), you still need to learn more and practice more. Come back to us if you need any further help.

Your reflections on this module are published here. Read the comments you have got from the users of your diagrams – the team that acted out your diagrams. Read carefully what the others thought about your specifications:

JunHu: UmlMasterModule/0605 (last edited 2012-05-25 12:44:42 by JunHu)