Скачать 260.53 Kb.
Inside The Oval : Use-Case Content Patterns
by Martin Langlands
Use-case modelling and the Patterns movement are among the most widely-used and influential concepts in systems development over the past 10 or 15 years. However, published Use-Case Patterns are restricted to either "process / technique" patterns, or patterns of external Use-Case structure. This paper proposes a language of Use-Case Content patterns – that is, patterns addressing concepts, such as flows and steps, that are "inside the oval" of the UML Use-Case. A language of nine ten Patterns is described, including such common use-case modelling requirements as basic creator, criteria search and viewer / updater.
Where’s The Content?
Use-cases. The patterns movement. Two of the most widely-used and influential concepts in systems development over the past 10 or 15 years. One might expect there to have been lots of work done bringing these ideas together, and that there would be a whole range of “use-case patterns” as well-known and widely-used as the Gang of Four software design patterns [gamma95] and Martin Fowler’s analysis patterns [fowler97]. So when in my own use-case modelling work with clients I have felt: “I’ve seen this problem before – surely there’s a pattern here? And surely someone before me has found and described it?”, I have gone looking. But I have come up largely empty-handed.
Google for “use-case pattern” and pretty well everything leads to one of two books1: Steve Adolph and Paul Bramble’s “Patterns for Effective Use Cases” [adolph03], or Gunnar Overgaard and Karin Palmkvist’s “Use Cases: Patterns and Blueprints” [overgaard04]. Now, I have no problem with either of these excellent books. Both have very useful insights that I have found of great value in my own modelling work. But neither is what I was looking for: patterns of use-case content.
What do I mean by this?
Use-case modelling is much more than drawing stick-men for Actors, ovals for Use-Cases and a few «include» and «extend» dependencies. Sure, this level – the UML Use-Case Diagram – is a useful first step. But we don’t really get into the meat of Use-Case Modelling until we begin to flesh out the insides of the Use-Case: stating pre- and post-conditions; identifying the main flow, alternative and exception flows; and describing the steps and their sequences in those flows. This is what I mean by use-case content, whether it’s represented in textual or diagrammatic format (or ideally both).
Neither Adolph & Bramble nor Overgaard & Palmkvist really tackle the problem at this level. Adolph & Bramble’s patterns are not about actual use-cases themselves; rather, they are what might be called use-case process patterns, or patterns of use-case modelling best-practice. They say how to do use-case modelling, not what the resulting models look like. Very useful, but not what I wanted. Overgaard & Palmkvist do talk about actual use-cases, but stop at the “outside of the oval”, as far as patterns themselves are concerned. They are what I’d term use-case external structure patterns. “Outside-the-oval” patterns are again great as far as they go, but in my experience that is only 5-10% of the effort. Both books are illustrated with examples of content – use-case steps – but these are not content patterns as such.
What Do We Need?
So what would a Use-Case Content pattern look like? To answer this, I need to go back to my initial problem. First, Use-Cases are an excellent – and now the all-but-universal standard – way of specifying and delivering the required “user-visible” behaviour of software systems (or at least a very large class of commercial software systems). But they don’t write themselves: a good deal of thought needs to go into working out, then deciding the best way to represent, what the “customer” (user / product-owner) wants the system to do. Further, we need to write that representation in a way that’s most useful to others involved in the process: UI designers, software developers, testers, overall solution architects, and those responsible for future maintenance of the software. Often there are competing issues here; all at the same time, I want my use-case descriptions to be:
Often, it’s far from obvious at the outset how best to achieve this. Given a set of fairly coarse-grained, unstructured, maybe partly conflicting user requirements – whether written in a more-or-less formal document, or still just in the customer’s head – there is often a whole range of ways these could be represented in a use-case model. A use-case content pattern – or, more accurately, a use-case content pattern language – would provide a set of tools for constructing an overall use-case model for a system that consistently and elegantly meets the criteria set out above.
The key feature that distinguishes these use-case content patterns is that they show things that live inside the oval – that is, they are not visible at the Use-Case Diagram level, but are internal to the Use-Case Description. They become visible only when the Use-Cases themselves are opened up. They concern features such as flows, sequences of steps and other aspects of the Description. Not actual, complete flows and step descriptions, of course – the detail of each flow and its steps is unique (more or less) to each individual Use-Case in each different product or project – but a pattern of flows, steps and other features that addresses a commonly-encountered Use-Case modelling problem, and that can be applied again and again to specific instances.
|Unit I introduction to Industrial Engineering: Historical background, Contribution of Taylor and Gilbreth, Productivity Improvement, Work content analysis, Definition and scope of Work Study Unit II||Health care management table of content chapter 1: Introduction to Health Care Management|
|Summary of Content||Table of Content|
|Content foreword||Summary of Content|
|Purpose and Content of the Course||Table of Content Preface|