Unified Modelling Language (UML) is a standard notation language used to specify, construct, represent and document models of complex software and other non-software systems, that help to structure, analysis and design their requirements (Pooley and Wilcox, 2004). According to Bennet et al. (2010) developing software has become a very complicated process because of various aspects such as advancement in technology, different requirements of end users and the size of projects. Because of an increase in the level of knowledge among users, the requirements of software have become more and more sophisticated (Bennet et al., 2010). In addition to that the
41
UML used as a solution to the software and business problems, it also enhance and improve the communication between the people who engaged to solve and analyse these problems (Pooley and Wilcox, 2004). This is required in the present study as techniques used by the agile teams (will be seen in chapter 4) when considering security requirements and negotiate to prioritise their requirements. Agile teams should know how to use UML and apply its diagrams in order to be able to understand and show the potential links between different diagrams. This can be achieved through choosing a suitable process of modelling, for example, which diagrams are helpful to address their problem (Pooley and Wilcox, 2004).
As a response object oriented (OO) analysis and design are usually aligned or based on different tools such as class templates/diagram, object diagrams and object state diagrams. Most of the class diagrams/templates usually offer vital information that is related to major concepts in the problem domain and their connectivity. Object diagrams aid in creating interfaces between the various class diagrams. According to Daniel (1995) an object state diagram is used in creating dynamic behaviour. It also helps in describing any possible state of an object. An integrative approach is usually used in summarising the use of Object-oriented analysis and design. Based on this approach, the output of one stage is usually taken as the input of the next stage; this is a refinement process that continues in a progressive manner. The initial step in an object state diagram is to evaluate and formalise each object`s life cycle. The next step involves definition of class relationships. In other words, each service offered by a class is supposed by definition. The final step involves completion of class and object diagrams along with the class templates. Agile teams can use object state diagrams iteriatively because the product dynamically changes due to changing customer requirements.
42
According to Bennet et al. (2010) in order to have a complete picture of the system, the models are usually put in position in order to visualize a specific element of the entire system. Below is a breakdown of various diagram types. Some of them are detailed as integration parts for agile teams when using UML for modelling (chapter 4, section 4.9.1.1).
Behaviour diagrams which are essential in evaluating various behavioural aspects of a system.
They include state machine, activity, the four interaction diagrams, and the case diagrams.
Interaction diagrams which are mainly used in the modelling process of object interaction. They
include a subgroup of diagrams aligned to the behaviour of the system such as interaction overview, communication, timing, and sequence diagrams.
Structure diagrams which are mainly used in the modelling process of the system, especially on
the aspect of its structure. They include class, object, composite structure, deployment, component, and package diagrams.
Many concepts and views have been given related to what artefacts would constitute a model, especially one that is based on both object oriented analysis and design processes. According to the assumption of Bennet et al. (2010), a model is usually an idea of a system or a sub-system from a specific viewpoint.
43
2.4.1 Use Cases
Use-case analysis is a useful method that is used to document different requirements and has helped to enhance shared understanding between the developer and the stakeholder about requirements, and helps non-technical stakeholders to understand the resulting documentation unlike other approaches such as the educator approach (Kanyaru and Phalp, 2009).
Use-cases are essential, especially in documentation of various system functional requirements which can be described in terms of actors and use cases (Gomma and Olimpiew, 2005).
Nevertheless, there are certain issues related to use-case approaches in the engineering of requirements. These include that it does not allow for a clear definition of system boundaries because it does not establish the scope of the system, for example, a system could be a computer system, and application, a component or an entire business enterprise, thus the actors and use cases for one system boundary may not be applicable to another system boundary (Lilly, 1999). Moreover, although use cases are useful for eliciting functional requirements, an issue that is usually of concern is that they do not offer sufficient support for non-functional attributes of a system, such as security requirements (Jonstone, 2011).
According to Bennet et al. (2010) there are different notations used to show the link between different use-cases and they all represent high level user goals that every system must accomplish. Based on a use-case diagram, one can identify different information such as what the system must do based on the perspective of all users, how the system must or should behave from the standpoint of different users, and finally the functional requirements among other information.
44
Use-case diagrams are not only used in representing specific analysis of output in an object- oriented system, but is also used in a variety of other elements attributed to system analysis. For instance, it is used in the process of business modelling among other areas as described by Barn (2007). Barn’s (2007) discussion is based on a meta - model that is aligned to a business process model. He has also offered various aspects of mapping between use-case modelling and business process modelling. Dijkman and Joosten (2002) have also offered a good introduction to business use-case and vital information on use-case modelling used in business process modelling. Both Barn (2007) and Dijkman and Joosten (2002) have used the idea of activity diagrams in representing business processes. This helps in modelling all decisions related to information in different steps. Use cases are used for eliciting requirements and as show in section 2.4 UML is a tool for modelling requirements. In the following section an extension of UML, UMLsec is presented which focusses on modelling security requirements.