Main menu

My ongoing research project, “Standardised design process”, is focusing on enhancement of the project design process at Moelven Byggmodul, the industrial housing company that I collaborate with.

The aim of the research project is to halve the time consumed in the design phase of a building project.

To achieve this, standardisation of both procedures and the company’s building standard is necessary, as well as implementation of Lean production tools for an increased control over the process.

Currently no comprehensive descriptions of the project design process is available, whereby this Phd-course assignment was considered to be a good opportunity to explore the suitability of using diagrams derived from UML literature to create such descriptions.

The main objective with this assignment was to investigate the applicability of UML diagrams in terms of establishing a comprehensive overview of the entire project design process.

Starting off in the course literature, (UML 2.0 in a nutshell), the authors initial warning about inexperienced UML-users tending to include all to much information in one diagram really made me think twice before adding information in the diagrams. As the authors “rules of thumb” says:

“…Show only what helps clarify the message you are trying to convey, and leave out what you don’t need… …use what is familiar to your audience…”

Little efforts has been made in trying to write “flawless UML-code”, since the purpose of this assignment has been to produce material that is usable within the research project and possible to communicate to the company representatives.

Therefore has the authors recommendations of most suitable ways of displaying a process been taken into account. The diagrams that appeared most useful were all found within the behavioural model section, and are for that reason the ones that have been focused in this assignment.

In this section follows a brief description of the how applicable the different diagram types from the behavioural section were considered to be.

The Use Case diagrams display the system functionality and requirements rather than revealing how the system actually operates. All use case must be initiated by someone or something outside the range of the use case it self, called an actor.

It was very intuitive and easy to start off creating the first Use Case diagram. Diagram 1, is a simplified representation of the entire project design process and the different actors involved.

The diagram is considered to be a very helpful tool when communicating a systems structure to persons having little or limited knowledge about the system.

The Activity diagram on the other hand is entirely focused on implementation and flow of the systems behaviour rather than how it is constructed. Therefore is the Activity diagram especially easy to apply to many different areas.

The first Activity diagram, (diagram 2) was very straightforward to create. It appears as if even limited familiarity with a system can be sufficient to create a simple, low-detailed Activity diagram. Diagram 2 is, (as also seen in Diagram 1), is a basic illustration of the entire project design process. To enrich the model, existing preconditions to two of the activities were added.

As a demonstration of how activities can be extensively described, diagram 3 was also created. It focuses on the activity “exterior wall”, (highlighted in yellow in Diagram 2). In the same manner, all activities can be further described in a higher resolution.

Another application of Activity diagrams that appeared valuable was the Activity Partitions. This extra feature allows indication of responsibilities for the actions included in an Activity diagram. To experience the usage of this type of diagram, Diagram 4 was generated.

Diagram 4 is a schematic representation of responsibilities within a project design. Please, notice that the action “HVAC Drafting” is labelled “«external»” to indicate an action not being performed internally.

Next diagram type out to have its applicability tested was the State chart diagrams. This type of diagram is most functional when the behaviour of a software system are to be displayed, but can also service as a handy tool when modelling communications within a system.

It was considered to be a little awkward to find a natural utilisation for this diagram type, but the one attempt made resulted in Diagram 5. In Diagram 5 can a State chart diagram regarding the available choices of action when the client examines the proposed project design be found.

The Sequence diagram one of many interaction diagrams that is used to emphasise the communication between different objects and especially how this communication results in functionality.

This type of diagrams appeared to be best suited for mapping communication between different software systems. In an attempt to utilise the techniques described in the making of a Sequence diagram, a description of the creation of a new project folder was modelled. (See Diagram 6.)

Another type of interaction diagram described in the course literature is the Communication diagrams. Here is focus placed on the involved elements rather than the flow control in the previous Sequence diagrams.

The same scenario as proposed in the Sequence diagram was also used in Diagram 7, so please do compare the two similar results.

Both these two types of behavioural diagrams were considered to be too distant from the scope of the research project and there was not any obvious way of utilising them for description of the project design process.

• UML diagrams can be useful when describing a system or a process.

• Difficulty in the use of the diagrams involves finding a sound abstraction level.

• Extensive knowledge about “UML-code” is required to fully take advantage of the diagrams tested in this assignment.

All throughout this assignment my ambition has been to produce material that could be utilised within the research project. Creating a clear, although detailed mapping of the current project design process at Moelven was the most obvious choice of action. Even if the diagrams produced in this assignment currently are low in detail, they still can serve as a useful tool when communicating about the system.

At first the biggest concerns regarded not having sufficient knowledge about the process to create a substantial model of the process. In the end it instead turned out to be the exact opposite. The real difficulties involved finding a proper level of abstraction, neither being too abstract and vague nor too rich in detail and thereby hard to overlook. This can be obtained by using several different types of diagrams in order to enable different views of one system.

Although this assignment just has served as a brief introduction to UML, it is still obvious that to benefit fully from all the possibilities, one must learn much more than possible in the limited time of a PhD-course. It is especially the possibility to explore the current state in a higher abstraction level that appears as appealing.

The diagrams that was considered being most useful when describing a process was the different types of Activity diagrams. It is actually very likely that Activity diagrams will be utilised in future work within the research project. Also the Use Case diagrams were easy to use and are believed to be very helpful in initial stages of describing a process.

One alternative way of performing this assignment would have been to choose the “most suitable” type of diagram and instead developed them in detail. That would probably have resulted in extensive knowledge and higher quality of the produced diagrams, but the with the experience of now knowing which diagrams suitable and not, is the chosen strategy considered to med justified.

Pilone, D., UML 2.0 in a nutshell : A Desktop Quick Reference. 2005, Sebastopol: O'Reilly.