An association is represented with an undirected solid line. To give a meaning to the association, a name and name direction can be provided. The name is in the form of an active verb and the name direction is represented by a triangle that points in the direction one needs to read. Association with a name and name direction is illustrated in Figure 5. In Figure 6 (removed) an example of association is illustrated. The example is a fragment of the process-data diagram of the requirements analysis in the Unified Process. Because both concepts are not expanded any further, although several sub concepts exist, the concepts are illustrated as closed concepts. The figure reads as “SURVEY DESCRIPTION describes USE CASE MODEL”. Except name and name direction, an association can have more characteristics. With multiplicity one can state how many objects of a certain concept can be connected across an instance of an association. Multiplicity is visualized by using the following expressions: (1) for exactly one, (0..1) for one or zero, (0..*) for zero or more, (1..*) for one or more, or for example (5) for an exact number. In Figure 7 association with multiplicity is illustrated. An example of multiplicity is represented in Figure 8. It is the same example as in Figure 6, only the multiplicity values are added. The figure reads as ‘exactly one SURVEY DESCRIPTION describes exactly one USE CASE MODEL’. This implies that a SURVEY DESCRIPTION cannot describe zero or more than one USE CASE MODEL and a USE CASE MODEL cannot be described by zero or more than one SURVEY DESCRIPTIONS. A special type of association is aggregation. Aggregation represents the relation between a concept (as a whole) containing other concepts (as parts). It can also be described as a ‘has-a’ relationship. In Figure 9 an aggregation relationship between OPEN CONCEPT and STANDARD CONCEPT is illustrated. An OPEN CONCEPT consists of one or more STANDARD CONCEPTS and a STANDARD CONCEPT is part of zero or more OPEN CONCEPT. In Figure 10 aggregation is exemplified by a fragment of the requirements capture workflow in UML-Based Web Engineering. A USE CASE MODEL consists of one or more ACTORS and USE CASES. Sometimes the needs exist to assign properties to concepts. Properties are written in lower case, under the concept name, as is illustrated in Figure 11.