Use Cases - Requirements UML Style

1
Use Cases - Requirements UML Style
February 6

• Definitions
• A use case is an object-oriented modeling
  construct that is used to define the behavior of
  a system. Interactions between the user and the
  system are described through a prototypical
  course of actions along with a possible set of
  alternative courses of action.
• R. Hurlbut (1999)

2

• Use cases are what happens when actors interact
  with the system. An actor uses the system to
  achieve a desired goal. By recording all the
  ways our system is used we accumulate all the
  goals or requirements of our systemThe
  collection of use cases should define all system
  behavior relevant to the actors to assure them
  that their goals will be carried out properly.
• Alistair Cockburn
• Creating a reasonably exhaustive set of use
  cases is the single best insurance you can buy to
  ensure that you are building the system the
  customer needs.
• Jesse Liberety (1998)

3

• Use cases do not say anything about the internal
  workings of the system. They just tell you how
  the users interact with the system and how it
  responds.
• Finding use cases
• To build use cases you must have the active
  participation of your customers. As in
  traditional requirements gathering, you must
  interview the users and help the user articulate
  how he uses the system.
• Domain experts are another important source of
  use cases.

4

• It is difficult to know when you have all the
  use cases.
• Having a rapid prototype available can be very
  helpful in understanding all the ways in which
  the system will be used.
• Actors
• Actors are not part of the system. They are
  anyone or anything that must interact with the
  system. To help identify them you can ask Who
  benefits from the system? Who will supply
  information or take information from the system?
  Who supports and maintains the system?

5

• For each actor, the results they require of the
  system constitute use cases. For example,
  Liberty (1998) talks about the customer of a
  video rental store may find a movie to rent, rent
  a tape, return a tape, and reserve a tape.
  Resulting use cases would include
• 1. The customer rents a tape
• 2. The customer returns a tape
• 3. The customer browses the system looking for
  a tape to rent
• 4. The customer reserves a tape for later
  viewing
• Use cases are thus the functionality provided to
  an actor by the system.

6

• Attributes and use cases
• When you look at the attributes of things in your
  problem domain you may come up with more use
  cases. For example, in the video store movies
  have names, actors, ratings, release dates, etc.
  These attributes can relate to ways actors will
  interact with the system. For example, customers
  may want movies made before some date, starring
  a particular actor, or carrying a particular
  rating.
• Naming use cases
• Once you have developed a sufficient number of
  use cases each should be given a unique name.

7

• Flows of events for use cases
• Each use case is described in terms of the events
  needed to accomplish the end state of the use
  case. This can include how the use case starts
  and ends, what data the use case requires, and
  the normal sequence of events in the use case.
• Use case diagrams
• Use cases can be represented diagrammatically to
  represent several related use cases. The actor
  is represented by a stick figure. A line between
  the actor and a use case (represented by an oval)
  indicates that the actor is associated with or
  communicates with the use case.

8
(No Transcript)
9

• Use case relationships
• Two types of relationships between use cases are
  described - uses and extends. When one use case
  ltltusesgtgt another use case it uses the
  functionality of the other use case.
• The extends relationship indicates that behavior
  that is optional or occurs only under certain
  conditions.
• Scenarios
• Scenarios are specific series of events
  illustrating typical instances of a use case.
  Scenarios are helpful in revealing relationships
  between actors and the flow of events in your
  system.

10

• The role of use cases
• The use case model is about describing what our
  system will do at a high level and with a user
  focus for the purpose of scoping the project and
  giving the application some structure. Use cases
  are an informal and imprecise modeling technique.
  Use cases are not intended to capture all of the
  system requirements.
• 
  Kenworthy (1997)
• Yet I. Jacobson writes that OO software
  engineering is a use case driven approach.

11

• Timothy Korson (2000) reported an experience
  working with a large software project which
  caused him to consider the proper role of use
  cases. This project had more than 1,000
  developers working on it. Development teams were
  called upon to send in their use cases. A total
  of 12, 386 use cases were submitted. The use
  cases were not very useful. They were seen as
  too detailed and sometimes in error.
• Korson suggests that use cases be organized
  hierarchically. Such an organization is needed
  to manage the complexity of the typical set of
  requirements. Korson suggests that the top level
  requirements for a system should be expressed in
  no more than a dozen or so use cases.

12

• Korson (2000) is also concerned that use cases
  have led to insufficient abstraction in the
  formulation of requirements. Too often use cases
  jump right into interface specification issues.
• Unless the first level of requirements is
  interface neutral, clients are robbed of the
  natural opportunity to consider other
  alternatives and designers are not prompted to
  build extensibility into the systemFor example
  when it is explicit that deposit coin is simply
  an interface binding to the requirement of
  accept payment, then software designers,
  hardware engineers, marketing personnel, product
  managers, et. al. are prompted to consider the
  possibilities and implications of other interface
  bindings such as an electronic cash or credit
  card reader.

13

• Thus, use cases may tend to be formulated too
  concretely and at too detailed a level to
  encourage creativity and flexibility in design.
• Korson makes the point that domain knowledge is
  important for software developers. He sees a
  profusion of use cases as a symptom of
  insufficient domain knowledge among the
  programmers.

14

• Use cases are only as good as is the actors
  perspective upon which they are based.
• Identifying a complete set of actor roles means
  that I will capture all of the users viewpoints,
  but what if some of the actors dont really
  understand the true business needs? What if the
  development team misunderstands the use cases?
• Domain knowledge is seen as crucial in creating
  use cases.
• You cant create correct, useful use cases if
  you dont understand the domain. This is as true
  for the client as for the development team.
  Never assume the client can articulate business
  needs. Typically each actor and domain expert
  has a very limited view of the domain in which an
  application will live.

15

• It is difficult to implement use cases correctly
  without good understanding of the domain. Korson
  cites a scientist who worked with radar signal
  processing who needed software developed for this
  area. He stated it was easier to teach a radar
  specialist how to program than to teach a
  programmer about radar. Korson, in working on a
  large accounting software project found that
  without good understanding of accounting
  concepts, a software engineer will misinterpret
  even well written use cases. For example,the
  word journal has several different meanings to
  accountants.

16
Specification Phase

• The specification of a software project serves as
  both a statement of the agreement between the
  development team and the client over what is to
  be built and a communication to the design team
  so they can use it to draw up the design. It
  can be difficult to make the same document clear
  and intelligible to both the client and the
  design team.
• The specification document is a contract between
  the client and the developer. It specifies
  exactly what the product must do and the
  constraints on the product. The specification
  document may consist of page after page of
  description.

17

• The purpose of the specification document is to
  provide a complete and detailed description of
  the functional capabilities of the software being
  developed. It is more detailed than the
  requirements document. It informs both the
  client and the design and implementation teams
  what the software will actually do to satisfy the
  requirements. Specifications documents include
  the software functions, including such details as
  formulas for converting input to output and
  sequences of operations. Interfaces (if any)
  between client and server applications are
  detailed. The user interface is described.
  General constraints on hardware, users, and
  development software are spelled out.

18

• It has been pointed out that specifications
  written in plain English tend to have
  contradictions, ambiguities, and omissions. The
  experiences following the publications of a paper
  by Naur on the specifications of a system for
  text-processing. A year later a reviewer
  published a paper illustrating one fault in
  Naurs paper. Another year later another paper
  detected three more faults. A subsequent paper
  added three more faults. The third critique
  revised the original specifications, making them
  four times as large as they were originally.

19

• In 1985 a paper came out which detected 12 faults
  in the revised specifications. They revised the
  specifications again. Another author has pointed
  out a fault in them.
• A key point is that all these specifications were
  for a small 25-30 line program and they were
  constructed by experts with as much time as they
  needed. What chance, then, does an ordinary
  computer professional, working under a time
  deadline have of producing error-free
  specifications?

20

• Another example of the problem with ordinary
  English is illustrated by Lejk and Deeks (1998)
  with the following example
• A product is passed as fit for sale if it
  passes a mechanical test and an electrical test
  and has the correct dimensions. If it fails
  the mechanical test or the electrical test (but
  not both), it is sent back to the workshop for
  repair. In all other cases, the product is
  rejected.
• This may, at first sight, seem like a reasonable
  description of a quality control process. But it
  contains an error.

21

• According to a literal reading of the policy, a
  product which has incorrect dimensions and has
  failed the electrical test would be sent back to
  the workshop for repair simply because it passed
  the mechanical test.
• The writer meant to say that a product must have
  the correct dimensions even to be considered as
  fit for sale. Because and has the correct
  dimensions is the end of the first sentence, the
  writer (and many readers) have assumed that this
  condition carries across to the start of the
  second sentence.
• Inconsistencies and inaccuracies are easily
  hidden in the words of ordinary English.
  Creating a more accurate description can lead to
  a lengthy narrative.

22
Need for graphical models

• Because it is so difficult to represent all that
  a software system is to do with words many
  attempts have been made to develop graphical
  means of representing software specifications so
  that they can be carried into the design and
  implementation phases.
• Established engineering disciplines have sets of
  unambiguous representations for modeling
  products. They have tools such as block and
  schematic diagrams and blueprints.

23

• Software engineering has no equivalents - there
  are many different notations and disagreement
  about which modeling primitives and notations to
  use.
• Many times software developers will implement
  systems without producing analysis and design
  models. Yet it is difficult to easily go back
  and forth between the problem and the
  implementation unless the problem is relatively
  small.

24

• The cognitive leap from understanding a problem
  to implementing a system is too great to proceed
  without including analysis and design models as
  key deliverables in the development
  process...Omitting these analysis and design
  activities or doing an incomplete job on them is
  widely recognized as a principal cause of
  development errors, high maintenance costs,and
  failure to build systems that meet user
  requirements. Without usable and precise
  requirements specifications and design models,
  acceptance testing and quality assurance become
  nearly impossible, and documentation will likely
  be inaccurate.
• Anthony Wasserman (1996)

25
Stepwise Refinement

• Stepwise refinement is a problem-solving
  technique that underlies many specification,
  design, and implementation techniques. Stepwise
  refinement is important because with large
  systems it is impossible for developers to focus
  on all aspects of the system design at once.
  Stepwise refinement prioritizes the problems to
  be solved, breaking down a stage into manageable
  chunks. Other aspects are postponed until later.
  

26

• The power of stepwise refinement is that it
  helps the software engineer to concentrate on the
  relevant aspects of the current development phase
  and to ignore details that, although essential in
  the overall scheme, need not be considered, and
  in fact should be ignored, until later. Unlike a
  divide-and-conquer technique in which the problem
  is decomposed into pieces that are essentially of
  equal importance, in stepwise refinement the
  importance of a particular aspect of the problem
  changes from refinement to refinement.
  Initially, a particular issue may be irrelevant,
  but later that same issue will be of critical
  importance.
• Stephen Schach (1999)

27

• Schach (1999) presents an example of stepwise
  refinement. It involves updating a sequential
  master file of the subscribers to a magazine. A
  software program to manage the file would support
  such operations as INSERT, MODIFY, and DELETE
  entries into the file. Transaction types are
• Type 1 INSERT (add a new subscriber)
• Type 2 MODIFY (change existing subscriber
  record)
• Type 3 DELETE (drop an existing subscriber
  record)
• A first step might be to diagram an overall view
  of the problem.

28
(No Transcript)
29

• The first refinement decomposes the update master
  file box into three boxes - INPUT, PROCESSlt and
  OUTPUT.

30
(No Transcript)
31

• We will then assume we can produce the correct
  record at the right time and write the correct
  record to the correct file at the right time. We
  concentrate on the PROCESS. If current
  transaction file record comes after the current
  old master file record, the old master file
  record is written to the new master file. If the
  current transaction file record comes before the
  current old master file record, there may be
  (only) an insertion operation into the new master
  file. If the current transaction file record are
  equal, there may be a modification or a deletion
  of the master file record.

32
(No Transcript)
33

• Now that we have worked to understand PROCESS
  better, we can produce the second refinement
  shown on the next slide. How to handle input and
  output have been deferred to a later refinement.
  Similarly, how to handle the end-of-file
  condition and what to do when an error condition
  is encountered are deferred. With stepwise
  refinement solving such problems can be postponed
  until a later refinement. Stepwise refinement
  allows us to work within human information
  processing limitations which restrict how much we
  can process at one time.

34
(No Transcript)
35
Structured Analysis and the Data Flow Diagram

• Structured analysis is the use of graphic
  documentation tools to produce a new kind of
  functional specification - a structured
  specification. The primary documentation tools
  of structured analysis are
• data flow diagram (DFD)
• data dictionary
• structured English
• Data flow diagrams provide an easy, graphical
  means of modeling the flow of data through a
  systemA typical system requires several levels
  of data flow diagrams.
• Yourdon (1979)

36

• Schach (1999) presents an example of the use of
  the DFD to model software to be used in a shop
  that purchases software from suppliers and sells
  it to the public. The DFD is used to model the
  logical flow of information as opposed to the
  physical data flow. That is, it focuses on what
  happens as opposed to how it happens. The
  following DFD could correspond to either a
  totally manual implementation or to a
  computerized implementation.

37

• A flow of data is shown by a line with an
  arrowhead, indicating the direction of flow.
  Each flow of data has a label to explain what it
  is.
• A source or destination of data is indicated by a
  double square. It is located outside the system.
• A process transforms the flow of data. It is the
  only part of the DFD that shows something
  happening. It makes the data flow.The
  description within the process must start with an
  imperative verb.
• A store of data within the system is represented
  by an open-ended rectangle.

38
(No Transcript)
39

• With larger systems it becomes impractical to
  have just one DFD. Stepwise refinement is done
  to parts of a DFD, creating a hierarchy of DFDs.
  That is, a single shape at one level is expanded
  to a complete DFD at a lower level. It is
  recommended that when creating DFDs it is best
  to first concentrate on the processes, then
  identify the stores of data and sources or
  destinations of data, and finally add the flows
  of data. A stepwise refinement of the initial
  DFD is presented next.

40
(No Transcript)
41

• A portion of the third refinement of the DFD is
  presented in the next slide. Sections relating
  to accounts payable and software suppliers are
  left out due to the increasing size of the DFD.
• Some recommend that the DFDs assume a prominent
  place in the specifications document as a clear
  representation of the logical flow of data in the
  system. Others suggest they be relegated to an
  appendix.

42
(No Transcript)
43

• Some believe that no control information should
  be included in a DFD. There is a strong
  implication that all of the processes shown in
  the process shapes could be taking place at the
  same time. Most believe that no control
  information should be shown in a data flow
  diagram. For example, in the previous DFD once
  an order is verified as valid the details of the
  package to be ordered can be sent to the PENDING
  ORDERS data store OR the details of the package
  on hand can be sent to the assemble orders
  process.

44

• Weinberg (1980) suggests that we should ignore
  data flow control considerations when developing
  overview DFDs. However, he suggests that we
  perhaps should include details of data-flow
  control on lower-level, more detailed diagrams.
  He proposes a notation for clarifying the
  association of flows of data
• denotes a logical AND connection
• denotes an exclusive OR connection
• denotes an inclusive OR connection

45

• Once we have used stepwise refinement to get to
  the bottom level of a DFD there is still a need
  to write about what exactly goes on in this
  bottom level. Decisions may be made or
  operations repeated. These need to be described
  in ways that are accurate, unambiguous, precise,
  and complete. Such process descriptions are
  contained in elementary process descriptions
  (EPDs), and there are several ways of writing
  these. They can be done using pseudocode,
  structured English, decision trees, or decision
  tables.

46

• Structured English has no hard and fast
  definition. It is an attempt to remove the
  background noise words from narrative
  descriptions. Pseudocode is a more formal
  variation of structured English.
• Decision trees make it easy to check that all
  possibilities have been taken into account. This
  may be especially helpful in complex cases.
• Decision Tables are useful when a combination of
  decisions have to be made in order to establish a
  result. Decision tables are made up of four
  quadrants.

47
(No Transcript)
48

• In limited entry decision tables conditions are
  entered into the table as direct questions to
  which the answer can only be yes (Y) or no (N).
  All the possible combinations of Ys and Ns are
  placed in the condition entry quadrant of the
  table and each vertical set of Ys and Ns taken
  together is called a rule. The possible results
  or actions are placed in the action stub and the
  relevant action(s) resulting from each rule are
  marked in the action entry quadrant with an X.
  
• Lejk and Deeks (1998)
• Note on the following table that unnecessary
  (redundant) conditions may be eliminated by
  inserting a - entry.

49
From Lejk and Deeks (1998)
50

• The data dictionary is an important part of a
  DFD. It goes along with our goal to have a
  precise definition of all terms included in our
  system specification. Definitions are entered
  into data dictionaries in a quasi mathematical
  form called extended BNF (Backus-Naur format).
  Every data flow and store of data has a
  corresponding data entry. For example, a
  Customers data store might have the following
  hierarchy of entries
• Character az AZ - .
  
• Name Character30
• Customer Name Address Phone_Number
• Customers Customer

51

• One of the drawbacks of DFDs is that they ignore
  response times as a variable.

52
Entity-Relationship (E-R) Modeling

• E-R diagrams are widely used for specifying
  databases. E-R modeling provides us with ways of
  identifying things which need to be stored in a
  system and the relationships between these
  things. E-R models are high-level and largely
  implementation-independent models of data.
• The essential components of an E-R model are
• entities
• attributes
• relationships

53

• An entity is a thing of interest to a system
  about which data is kept. They are commonly
  real-world objects. A thing is only an entity if
  it is possible for there to be more than one
  occurrence of it in the system.
• Entities
• A patient in a medical records system
• An employee in a company personnel system
• A book in a library system
• Not entities
• A customers address in a sales system
• A social security number in a payroll system

54

• An attribute is a relevant piece of information
  about the entities stored in our system. It is a
  data item held about an entity. In databases, an
  attribute is equivalent to a field on a record.
  A record is equivalent to an entity occurrence.
  A special and important type of attribute is the
  key attribute. A key attribute uniquely
  identifies a specific occurrence of an entity.
  Examples of key attributes are as follows
• - A persons social security number
• - A cars vehicle registration number

55

• Relationships between entities model the
  corresponding real-world connections and
  interactions. It is because entities are related
  to each other that databases are so powerful at
  efficiently storing data. In a personnel system
  an Employee is related to a Department because an
  Employee belongs to a Department and a Department
  contains a number of Employees.
• Beyond saying that entities are related we also
  look at the degree of relationships. For
  example, can an order be placed by one and only
  one customer (no), and can an order be placed by
  one and only one customer (yes)? Types of
  relationships are one-to-one, one-to-many, and
  many-to -many. The cardinality ratio specifies
  the number of relationships that an entity can
  participate in.

56

• One-to-one relationship
• An estimate to an order in a customer service
  system.
• One to many relationship
• A customer and an order in a customer service
  system.
• Many to many relationship
• Athletes and the events in which they compete.

57

• Relationships are also characterized by their
  optionality. Some relationships are mandatory
  (total participation) and some are optional
  (partial participation). For example a Customers
  may be on file even if they do not have an
  Estimate. However, an Estimate cannot exist
  without a Customer.
• In E-R diagrams entities are shown as boxes with
  their name in the box. Relationships are
  signified by lines between entities that contain
  a diamond with the name of the relationship in
  it. Attributes of entities are represented by
  bubbles coming off the entities. Primary keys
  are underlined. Cardinality ratio is specified
  by ratios between 1,n,and n on the lines between
  entities. Total and partial participation is
  signified by single and doubly written lines,
  respectively.

58

• Variations on constructing E-R diagrams abound.
  For example, Pont (1996) draws arrows on the
  lines indicating relationships to give
  directional information about relationships. In
  the relationship Employee drives Car an arrow
  is added to the relationship line to indicate it
  is the employee who drives the car. In some
  relationships this may lessen ambiguity.
• Broadly speaking, each entity in our DFD will
  become a table in a database. The attributes
  for each entity will be fields in the tables.
  The relationships will become the links between
  the tables.

59
(No Transcript)
60
(No Transcript)
61
Tools for constructing E-R diagrams

• Visio
• http//www.microsoft.com/office/visio/
• smartdraw
• http//www.smartdraw2.com