Soft Systems and Use-case Modelling: Mutually Supportive or Mutually Exclusive?

Transcription

1 Soft Systems and Use-case Modelling: Mutually Supportive or Mutually Exclusive? D.W. Bustard, Z. He and F.G. Wilkie School of Information and Software Engineering, University of Ulster Coleraine, BT52 1SA, United Kingdom. Abstract Checkland s Soft Systems Methodology (SSM) can be used to support strategic planning for business improvement. This involves the development of system models to identify the activities that an organisation must perform to meet its goals. Jacobson s Use-case modelling in the Unified Modelling Language (UML) is a requirements engineering technique that similarly leads to the identification of system activities, but driven by the needs of the system s users, rather than those of the system itself. This paper considers the potential gain from using these techniques in combination, examining each through the same car-park example. It is concluded that SSM is a better starting point for the analysis of a business. It can therefore be used to enhance UML, but requires careful integration of the techniques and associated models involved. 1. Introduction Improving a business starts with a vision of what the business should, could or might be. Checkland s Soft System Methodology (SSM) [1-6] offers one systematic approach to the development of such a vision. It involves the modelling of activities necessary for a business to meet its current or potential goals. The models are usually produced by an analyst in collaboration with the owner of a business and those who operate it, the actors. Recommendations for business improvement are derived from the models, and will typically include suggestions for the introduction or enhancement of supporting computer systems. Jacobson s Use-case analysis [7, 8] is similarly concerned with defining system behaviour, but is driven by the needs of users rather than any inherent goals of the business. In Use-case modelling, a system is defined by a set of Use-cases, each describing a system transaction, or function. Actors in this context are the agents (human or otherwise) who trigger the functions of the system. The Use-case approach has been included in the Unified Modelling Language (UML), which combines a number of popular object-oriented analysis techniques [9]. Usecase modelling is one of five standard views in UML, the other four being the Logical view; the Component view; the Concurrency view and the Deployment view. This paper examines the relationship between SSM and Use-case modelling to identify to what extent the two techniques might be used together, in a mutually beneficial way. Earlier research explored various aspects of integrating SSM and requirements engineering, using both a structured [10] and object-oriented approach [11]. This included the evaluation of system models through their formalisation in the specification notation LOTOS [12], and an investigation of the use of risk management to refine models and determine how change should be implemented [13]. The initial motivation for the work described here was to determine if and how Use-case modelling can help in the validation of soft systems models. There are, however, a number of other reasons why a study of the relationship between Soft Systems and Use-case modelling is worthwhile: Use-case modelling is well known within the software engineering community, but SSM much less so. This study can help draw attention to SSM as a potentially valuable technique for software engineers. Software engineers who try to understand SSM, and are already familiar with Use-case modelling, are distracted by the fact that both describe system behaviour, and so seem to have the same role. A more precise explanation of the relative contribution of each technique would help clarify where and how each can be used effectively. SSM focuses inwardly on the business, while Use-case modelling is user driven. This suggests that a combined use of the techniques may yield a more balanced approach. The corollary is that each technique is perhaps deficient to some extent because of this lack of balance. 1

2 Difficulties in structuring use cases have been reported [14, 15] and SSM may help alleviate those difficulties. It is not clear whether object-oriented methodologies, such as UML are sufficient by themselves or need to be preceded by an additional business analysis stage. By exploring the Use-case view of UML, and comparing it to SSM, some progress might be made towards resolving this issue. If a simple link can be established between SSM and Use-case modelling it would provide a development route from high-level business analysis down into an object-oriented implementation. Earlier work on linking SSM and object models [11] resulted in the development of a partial link but the Use-case route would be stronger. The first section of the paper discusses the modelling aspects of SSM, building activity models of a shopping centre car park to illustrate the steps involved. The second section similarly introduces Use-case modelling, again illustrating it with the same car park example. A concluding section draws together and extends a comparison of the two approaches, summarising what each has to offer and suggesting how SSM might be used to complement the Use-case and Logical views of UML. 2. Soft Systems Modelling Soft Systems Methodology is described classically as a seven-stage process of analysis [1], as summarised in Figure 1. There are five stages associated with so-called real world thinking: two of them for understanding and finding out about a problem situation, and the other three for deriving change recommendations and taking actions to improve the problem situation. There are also two stages (below the dotted line) concerned with systems thinking, in which root definitions and conceptual models are FINDING OUT Real world thinking Systems thinking 1. The problem situation: unstructured 2. The problem situation: expressed 3. Root definition of relevant systems 7. Action to solve the problem or improve the situation 5. Comparison of 4 with 2 BUILDING MODELS EVALUATING MODELS 4. Conceptual models TAKING ACTION 6. Definition of feasible desirable changes Figure 1. Checkland s seven-stage Soft Systems Methodology developed. Each root definition provides a particular perspective of the system under investigation. A conceptual model defines activities necessary to achieve the perspective given in a root definition. To help show how root definitions and conceptual models relate to Use-case modelling, their form and content are explained more fully in the paragraphs that follow. The discussion is illustrated by examining how a car park associated with a city shopping centre might be managed, triggered by a request to implement an integrated computer-based control system for the car park. A root definition, in general, identifies or implies six particular pieces of information, as described in Table 1. Table 1. General components of a Root Definition Components Meaning Customers the beneficiaries or victims of a system Actors the agents who carry out, or cause to be carried out, the main activities of the system Transformation the process by which defined inputs are transformed into defined outputs Weltanschauung a viewpoint, framework, image or purpose, which makes a particular root definition meaningful Owner those who own a system (have the power to close it down) Environment influences external to a system that affect its operation For the car park, one business perspective might be defined as shown in Table 2. Table 2. Root Definition components for a car park perspective Components Definition for car park Customers shopping centre users arriving by car Actors car park operators Transformation provide parking spaces Weltanschauung facilitate use of a city shopping centre Owner City s plc (CCP) Environment the demand for spaces; the cost of space provision A root definition is usually presented as a single statement combining the six components specified. For example, for the car park perspective, it might be: A CCP plc owned system to facilitate use of a city shopping centre on behalf of supermarket users 2

3 arriving by car by using car park operators to provide parking spaces, taking account of the demand for spaces and the cost of space provision. Further root definitions can be produced in the same way to describe other purposes for the car park. For example, a second role might be to help reduce the possibility of car theft or other criminal acts. Based on the definitions in Table 3, the root definition in this case might take the form: A CCP owned system to provide reasonably secure parking, on behalf of car park users by using car park attendants to operate equipment and carry out procedures likely to deter criminal activity taking account of the need to balance expectations with available finance. Table 3. Root Definition components for a second car park perspective Components Definition for car park Customers car park users Actors car park attendants Transformation operate equipment and carry out procedures likely to deter criminal activity Weltanschauung provide reasonably secure parking Owner City s plc (CCP) Environment the need to balance expectations with available finance Each root definition is expanded into a conceptual model, defining the activities necessary for the business to meet the purpose specified, and indicating relationships among the activities. For example, Figure 2 shows a conceptual model based on the car park root definition given in Table 2. The transformation, A7, is the main activity, with others introduced to (i) monitor that the defined Weltanschauung (viewpoint) is achieved (A8), taking control action if necessary (TCA); (ii) general management activities associated with planning and resourcing the operation of the business (A4, A5); and (iii) activities to handle the environmental constraints identified in the root definition (A1, A2, A3, A6). The conceptual model notation is largely informal in that the meaning of each activity is described solely by the text displayed in the diagram; also the linking arrows, implying relationships between activities, have no accompanying names or explanations. Nevertheless, such models do provide a framework for discussion about how a business should be managed and can form the basis of further, more detailed, analysis and modelling. In particular, they help identify activities that are either missing or performed inadequately, thereby giving a focus for business improvement. They also provide a route map for investigating where computing support might be beneficial. A1: Determine charging policy A6: Be aware of the cost of providing parking spaces A2: Calculate likely demand for parking spaces A5: Plan operation of the car park A7: Give access to parking spaces A3: Be aware of shopping centre usage A4: Resource operation of the car park A8: Monitor that the use of the shopping centre is facilitated and take control action as necessary TCA Figure 2. Conceptual model for a shopping centre car park Models are usually presented in a hierarchic form, with high level activities elaborated in sub-models. Figure 3, for example, shows an expansion of the main activity give access to parking spaces in Figure 2. The link from A5, plan operation of the car park, applies to all of the lower level activities. Sub-activity A7.3 is shown linked to A8, monitoring the overall viewpoint. Activities at this lower level can be further expanded in the same way, as necessary. A7.1: Handle customer arrival A7.2: Handle customer departure A7.3: Monitor access to car park TCA Figure 3. Sub-Model of Give Access to Parking Spaces activity Note that although the initial impetus for this analysis was a request to implement an integrated computer control system for the car park, none of the modelling completed so far is concerned with computing in any way. This provides a clean separation between identifying necessary business activities and determining how they are to be performed. Note also, that there is no indication at this stage of who does what. The root definition identifies car park controllers as actors in the system but the part they play has yet to be decided. Indeed, the nature of the controllers is itself uncertain and they may turn out to be machines or humans or a combination of the two. A8 3

4 3. Use-case Modelling and UML Use-case modelling was first presented as part of Jacobson s Object-Oriented Software Engineering (OOSE) methodology for software development [7, 8]. It is now in UML, which brings together three of the main objectoriented analysis techniques [9]. UML is gaining widespread support and acceptance, partly through adoption by the Object Management Group [16]. In UML, five views of a system can be constructed: Use-case (external user perspective), Logical (internal system design), Component (architectural constituents), Concurrency (describing mechanisms of co-ordination between independently processing system parts) and Deployment (mapping system parts onto a physical architecture). From these views a series of diagrams are developed. These include Use-case, Class, Object, State, Sequence, Collaboration, Activity, Component and Deployment. The Use-case view is the main reference base used throughout the UML modelling activity. It influences all the other views. So, once an initial set of Use-cases has been identified and documented (during requirements analysis), they facilitate step-by-step development right through to the delivery of the completed software system. Like SSM, Use-case modelling is concerned with describing system behaviour. In SSM, the system is typically the business being analysed. With Use-case modelling, however, there are several levels of system that might be considered. Use-case analysis was developed initially for computing systems, but can also be applied to the information system within a business, or to the business itself. In SSM, customers are external to a system and are serviced by it. This is exactly the same concept as an actor in Use-case analysis. As identified in the previous section, SSM also uses the term actor but in the different sense of an agent performing activity within the system. All Use-case actors are external agents that interact with a system via Use-cases. An actor in this context can be anything, human or otherwise, that triggers a system function. A Use-case is a textual description of system usage, documenting transactions or sequences of interrelated events initiated by an actor. The complete functionality of the system from an external perspective is described by the set of Use-cases thus developed. Considering the system as the complete business, the Use-case actors for the car park example would be: car driver visiting the shopping centre shopping centre manager Asking why a system exists and trying to determine whom it is likely to benefit can identify actors. SSM has similar concerns but focuses more on system activity than on those performing the activity. Each actor will have one or more associated Use-cases. A Use-case is a named function, with an accompanying description explaining what happens within the system when the function is invoked. For example, possible Use-cases for the car driver visiting the shopping centre will include entering and leaving the car park. Similarly, the shopping centre manager will track usage of the car park to see how it is affecting the shopping centre. These Use-cases are summarised diagrammatically in Figure 4. Shopping Centre Manager Car Driver Track Usage Enter Exit Figure 4. Use-Case diagram for car park business The description of the Use-case is given in textual form. For example, the use case for enter the car park might be described thus: Actor: Car Driver Visiting the Shopping Centre Use-case 1: Enter the Enter the is started by Car Driver Visiting the Shopping Centre and attempting to park. The system will check to see if space is available, and if so increment the number of cars present, allow the Car Driver Visiting the Shopping Centre to enter, and record the date and time of entry. Each Use-case, in effect, contributes to the development of an internal system model - the UML logical view. The enter car park Use-case, for example, introduces the notion of a repository in which information is stored about the number of cars in the park. There is also the notion of arrival records although at this stage the description is purposely vague to permit flexibility in later design. Traditionally, the information would be on a parking ticket but as each car park user is also visiting the shopping centre, a loyalty card might be used to enable entry. Details of arrival and departure could then be held in a customer database and payment influenced by the amount spent in the shopping centre. These ingredients 4

5 influence the development of appropriate logical views of the system concerning both structural (static) and behavioural (dynamic) aspects. The logical view is represented through various diagrams involving objectoriented elements such as Classes, Objects, Inheritance and Message Passing. Comparing the Use-case model developed so far with the SSM activity model in Figure 2 shows important differences between the two approaches. The first is that the Use-case analysis of the car park business reveals very little of what goes on within the business. Of the eight activities in Figure 2 only A3: be aware of shopping centre usage and A7: give access to parking spaces, emerge from the Use-case analysis. To narrow the gap it is necessary to look within the business at the underlying information system. This then introduces two additional actors: the car park manager and the car park operator, with their associated Use-cases. Figure 5 shows the resulting Use-cases and identifies some relationships among them. Other points to note in this comparison of the SSM and Use-case approaches are: Use-case descriptions contain much more detail than equivalent SSM models. This can help the analyst better understand each activity. Unfortunately such detail also tends to be distracting when trying to gain an initial understanding of the business and can encourage early design decisions before opportunities for improvement have been agreed. SSM is a broader form of analysis than Use-case modelling. Through multiple perspectives, SSM promotes a more thorough examination of why a business exists and hence more fully identifies where computing support would be beneficial. For example, the security perspective discussed in Section 2 (Table 3) might not emerge at all from a Use-case analysis because there is already an obvious purpose for a car park. Business models are easier to create in SSM. SSM leads directly to the development of coherent business models whereas Use-case modelling helps only to identify particular functions of a business, which then need to be integrated to produce an overall description. Some activities are more difficult to identify through Use-cases than SSM. These are activities concerned with the internal management of the business, like monitoring and control. Such activities can only be inferred indirectly through Use-cases, because of their focus on external interaction. Overall, this comparison suggests that SSM and Usecase modelling, while related, are certainly not mutually exclusive. SSM seems to offer a better approach to analysing a business, with Use-case modelling being more appropriate for the lower level information and computing systems analysis. The next section explores the possibility that the techniques might be mutually supportive. Manager Determine Charging Policy Calculate Running Costs Manage Resources Track Usage Shopping Centre Manager Manage Customers Car Driver Enter Record Customer Control Physical Access Exit Charge Customer Operator Figure 5. Use-Case diagram for car park information system 5

6 4. Linking Use-Case and Soft Systems Modelling There are essentially two ways that Use-case and SSM modelling might be used together: SSM Model Validation: One way of examining the adequacy and consistency of SSM models is to create Use-case models for the same system and compare them. Any significant differences would then prompt further investigation. UML with Business Analysis: SSM models can also be used to help develop Use-case models, especially in UML. This could be particularly beneficial given the strong influence which the Use-case view exerts on the other four UML views, and consequently on the underlying object-oriented diagrams. Each of these opportunities is now considered in turn SSM Model Validation As mentioned in the introduction, the initial motivation for the work described here was a belief that Use-case modelling could help with the validation of SSM models. The idea is that Use-cases would provide a cross-check for SSM models by describing scenarios of possible behaviour that would be recognisable in those models. Each Use-case should be executable in an associated SSM model, which means that: each interaction between a Use-case actor and the system concerned can be directly related to a particular activity in an SSM model; and each Use-case can be explained in terms of the activities in the SSM model and their interaction. These conditions can be confirmed by a systematic inspection of the models [17]. The net result of this approach is to formalise the evaluation process for SSM models. This seems to offer some benefit and indeed is consistent with recommended strategies for examining SSM models [1]. A fundamental difficulty, however, is the lack of coverage achievable through considering only Use-cases for actors (customers) that are external to the business. In effect, Use-cases define a set of tests for an SSM model, with the expectation that the tests will cover all relevant system behaviour. This means that every activity in an SSM model should be associated with at least one Use-case. This is only possible, however, if the Use-case analysis is applied to the underlying information system of the business rather than the business itself, as discussed in Section 3. The relevant Use-case actors for the information system are easy to identify in an SSM model (a combination of customers and SSM actors) but working with two notions of system is likely to be confusing. The level of detail in Use-cases is also a disadvantage. The net effect of these drawbacks is to reduce the benefit of Use-cases for SSM model validation. However, it does suggest that Use-cases are relevant to the validation of an information model derived from an SSM model and this possibility is covered in the next sub-section, which considers how SSM might support the development of Use-cases UML with Business Analysis In circumstances where the overall development goal is to implement an object-oriented computing system with UML, then an initial SSM analysis would seem to provide a good base for that work. SSM root definitions identify the Use-case actors and conceptual models help to identify Use-cases. Linguistic problems with the terms actor and activity model having different meanings in the two approaches is confusing, but otherwise the two techniques fit together quite well. A tighter link would bring even more benefit. For example, with suitable software tool support, actors could be extracted automatically from SSM root definitions and Use-cases built on top of conceptual models. One fundamental difficulty with this approach, however, is that SSM models are inherently informal, which limits the extent to which a formal linkage is possible. Earlier work on linking SSM to computing models led to the development of a bridging information model [10], based on the concept of a system as a collection of communicating processes [12, 18]. SSM activities in a conceptual model are documented as interacting processes. The necessary information is supplied in a tabular form but the resulting relationships can be summarised in an interaction diagram, which effectively extends the associated conceptual model. Figure 6, for example, shows an interaction diagram for the provide parking spaces activity sub-model in Figure 3. An interaction model is built by defining the behaviour of each SSM activity of a conceptual model in terms of how it interacts with other system elements. New descriptive elements are introduced as necessary to account for each source of input and destination of output. For example, handle customer payment is now able to make direct reference to a customer in the model. By convention, any new source or destination that is perceived to have an active role, such as the customer, is referred to an entity, while any whose role is essentially passive, such as the repository for parking data, is called a store. Entities, stores and SSM activities are known collectively as processes. 6

7 CUSTOMER Handle customer arrival Handle customer departure Parking Data Transaction Data CCP Monitor car park usage & income Figure 6. Interaction diagram for Give Access to Parking Spaces activity This information system, documented as an interaction model, is now at a level directly comparable with Usecases identified for the car park. All Use-case actors are visible in the model and their interactions, in terms of information flow, are well documented. It is then a relatively straightforward step to develop Use-cases from such descriptions and from there continue with a standard UML analysis. The Use-cases would be expressed in terms of the processes and interactions of the interaction model as far as possible so that subsequent changes could be traced through the linked models. Interaction models can be used to describe the information model for a system regardless of the subsequent form of computing analysis to be performed. In general circumstances, therefore, Use-cases might still be used for validation purposes. In this situation they would be produced separately from the interaction model and then compared systematically against it to confirm agreement and explore differences. 5. Conclusions This paper has examined how Checkland s business modelling in Soft Systems Methodology (SSM) and Jacobson s Use-case modelling in UML might be used together in a mutually supportive way. The same simple car park example has served to help clarify the approach that each takes to the description of system behaviour and to identify where and how the techniques might be combined. The question raised in the title, about the techniques being mutually exclusive, has been answered. The approaches are certainly related but SSM is better suited to business analysis and Use-case modelling more appropriate when analysing the information system within a business. This suggests that SSM could provide a valuable extension to UML, particularly when used in combination with interaction models. Use-cases are easily developed from interaction models. Similarly, Use-cases developed independently of an interaction model are easily compared for validation purposes as they refer to the same information system at a similar level of detail. Software tool support can make the combined use of SSM and Use-case modelling more attractive. A prototype tool has been developed to help build and link SSM models with object-oriented models (Shlaer-Mellor) via interaction models [11]. This is being extended to support the development of Use-cases from interaction models and provide a link to standard UML tools. This paper has also served to highlight the general benefit of SSM to software engineers and indicated a higher level way of thinking that can help establish a well founded business case for any computing driven business change. 6. Acknowledgements The work described in this paper has been undertaken as part of the RIPPLE project (Retaining Integrity in Process Products over their Long-term Evolution) funded by EPSRC, GR/L60906, under the SEBPC (Systems Engineering for Business Process Change) Programme. RIPPLE is concerned with linking business and computing models as a basis for ensuring that computing facilities are directly supportive of a business and also remain aligned as business and computing changes occur. The project is in collaboration with the Northern Ireland Civil Service and British Telecom, who are helping to evaluate the proposed approach. References [1] Checkland, P., Systems Thinking, Systems Practice, John Wiley & Sons, New York, 1981 [2] Checkland, P., and Scholes, J, Soft Systems Methodology in Action, John Wiley & Sons, New York, 1990 [3] Wilson, B., Systems: Concepts, Methodologies, and Applications, 2nd Edition, John Wiley & Sons, New York, 1990 [4] Mingers, J. and Taylor, S., 1992, The Use of Soft Systems Methodology in Practice, Journal of the Operational Research Society, 43(4), [5] Lewis, P.J., Information Systems Development: Systems Thinking in the Field of Information Systems, Pitman, 1994 [6] Stowell, F. A. (ed.), Information System Provision: The Contribution of Soft Systems Methodology, McGraw-Hill Book Company, London, 1995 [7] Jacobson, I., Christerson, M., Jonsson, P., and Overgaard, G., Objected-Oriented Software Engineering, A Use Case Driven Approach, Addison-Wesley, Wokingham, England, 1992 [8] Jacobson, I., Ericsson, M., and Jacobson, A., The Object Advantage: Business Process Re-Engineering with Object Technology, Addison-Wesley,

8 [9] Rumbaugh, J., Jacobson, I. and Booch, G. Unified Modeling Language Reference Manual, Addison-Wesley [10] Bustard, D.W., Oakes, R., and Helslin, E., Support for the Integrated Use of Conceptual and Dataflow Models in Requirements Specification, Colloquium on Requirements for Software Intensive Systems, pp , DRA Malvern, May, 1993 [11] Bustard, D. W., Dobbin, T. J., and Carey, B. N., Integrating Soft Systems and Object-Oriented Analysis, IEEE International Conference on Requirements Engineering, Colorado Springs, Colorado, April, 1996, pp [12] Bustard, D. W., and Lundy, P. J., Enhancing Soft Systems Analysis with formal Modelling, IEEE Requirements Engineering 95, March, York, England, 1995 [13] Greer, D., and Bustard, D. W., SERUM - Software Engineering Risk: Understanding and Management, International Journal of Project & Business Risk Management, 1(4), pp ), Winter, 1997 [14] Cockburn, A., Goals and Use Cases, JOOP, 10(5), Sept, 1997 [15] Cockburn, A., Using Goal-Based Use Cases, JOOP, 10(6), Sept, 1997 [16] UML Proposal to the OMG Object Analysis & Design Task Force, UML 1.1, held by the Object Management Group, document number , November 1997 [available via OMG web site [17] Weinberg, G.M., and Freedman, D.P., Reviews, Walkthroughs, and Inspections, IEEE Transactions on Software Engineering, 10 (1), 1984, pp [18] Hoare, C.A.R., Communicating Sequential Processes, Prentice-Hall International,