CMPT 370: Information Systems Design

1
CMPT 370 Information Systems Design
Lecture Topic Requirement Specification Class
Exercise Use Cases revisited, CRC Cards

• Instructor Curtis Cartmill, Simon Fraser
  University Summer 2003

2
Objectives

• This lecture looks at adding to our skills in
  requirements definition and specification
• Verifying our domain models with CRC
• Class, Responsibilities, Collaborators
• Looking at Analysis Patterns to model common
  business problems

3
So far we have

• Identified actors and use cases that indicate the
  scope of the problem
• Identified concepts in the as-is and to-be domain
  model that help to communicate where we are and
  where we need to go

4
What we need to do next

• Look at our set of use cases and validate the
  relationships between actors and use cases.
• Look for opportunities to clarify and simplify
• Look at our domain model and validate that it is
  supported by our use cases
• Look for gaps or missing concepts and
  relationships

5
CRC Approach

• The CRC (Class Responsibility Collaborators)
  is a technique about class (concept) discovery
  and verification.
• Involves brainstorming sessions using special
  cards with three compartments
• Class/concept name (include possible subclasses,
  superclasses)
• Responsibility (the services (operations) that
  the class is prepared to perform on behalf of
  other classes (what do I know and what do I know
  how to do) and
• Collaborators - responsibilities that require the
  use of other classes
• On the back of the card Attributes of Class
  usually on the back as we want to assume
  privacy i.e. that classes do not need to know
  each others implementation details
• Good Resources on CRCs
• David Bellin and Susan Suchman SImone, The CRC
  Card Book, 1997.
• Timothy Budd, Introduction to Object-Oriented
  Programming, 1991.
• Original Paper on CRCs (please note though,
  method has been updated http//c2.com/doc/oopsla
  89/paper.html

6
CRC Session

• A CRC session proceeds with someone simulating
  the system by talking about which objects send
  messages to other objects using the use case
  scenarios as a script. Emphasis is placed on the
  uniform distribution of intelligence, but
  sometimes the line is blurry between discussing
  classes and instance objects within a system.
  There is also the degree of connection or
  collaboration between objects that should be
  addressed/discussed.
• We can verify classes/concepts as well as useful
  information for the determination of class
  properties (attributes). By stepping through the
  process, weaknesses and problems are easily
  uncovered. Alternatives can be explored quickly
  by simulating the scenario being proposed.
• One of the biggest criticisms of CRC Cards is the
  lack of written documentation. This is usually
  not needed as CRC Cards make the model seem
  obvious. Should a more permanent record be
  required, one card for each class/ concept can be
  written out in full and retained as
  documentation.
• CRC is used to Recipe Cards (4x6) are
  suggested. If class has too many responsibilities
  for the card, you may use this concept to look to
  break apart/split a class into a number of
  classes.

7
Discovering Classes

• Previous Analysis Techniques
• Requirements Gathering
• Use Case Scenarios
• Domain Models
• Analysis Patterns
• Suggestions From Budd
• Data Managers, Data or State
• principal responsibility to maintain data or
  state
• Data Sinks or Data Sources
• classes that consume (sink) or generate (source)
  data (e.g. output to disks)
• View or Observer (towards MVC Pattern)
• Data in one Model, different data representations
  by View (PieChart, BarGraph), controlled/coordinat
  ed by other object
• Facilitator and Helper Classes
• Little or no state information, but help
  execution of tasks

8
General Guidelines for Naming Classes (Budd)

• Use Pronounceable names
• Use Capitalization (or underscores)
• AccountTransaction or Account_transaction
• Careful with Abbreviations
• Do not use Digits
• 0 or O, 1 or I
• For Booleans, name methods appropriated
• isPrinterReady, and not printerStatus

9
Common CRC design flaws

• Classes with too much or not enough
  responsibility
• Break apart classes or make classes into
  attributes of other classes
• Issues of Inheritance
• Inappropriate use vs. Repeated functionality
  which means Inheritance should be considered
• Classes that make direct modifications to other
  classes
• Consider access restriction to methods (private,
  protected and public)

10
CRC Example

• CRC cards explicitly represent multiple objects
  simultaneously.
• CRC Cards are written out in advance but more
  than likely are written our on the spot during a
  brainstorming sessions
• CRC cards place the designer's focus on the
  motivation for collaboration by representing
  (potentially) many messages as a phrase of
  English text.

11
CRC ATM Example

• Account and Transaction provide the banking
  model. Note that Transaction assumes an active
  role while money is being dispensed and a passive
  role thereafter.
• Transactions meet their responsibilities with the
  aid of several objects that serve as device
  drivers. The Dispenser object, for example,
  ultimately operates the dispensing device.
• Example taken http//c2.com/doc/oopsla89/paper.htm
  lcards

12
CRC Value

• (CRC) Cards allow analysis and design of the
  system as a team.
• The biggest value of CRC cards is to allow people
  to break away from the procedural mode of thought
  and more fully appreciate object technology.
• CRC Cards allow entire project teams to
  contribute to the design.
• The more people who can help design the system
  the greater the number of good ideas
  incorporated.

13
Analysis Patterns

• Pattern an idea that has been useful in one
  practical context and will probably be useful in
  others
• Patterns in analysis patterns that reflect
  conceptual structures of business processes
  rather than actual software implementations
• We need however to be able to turn these into
  implementations (start to think about classes)
• Analysis patterns are useful in the review of a
  model
• Ability to compare what we are modeling to past
  experiences

14
Martin Fowler and Analysis Patterns

• Considered the expert on Analysis Patterns on a
  variety of Business Domains
• Organizational Structures (Hierarchical)
• Accounting Systems
• Temporal Structures including Calendars and
  Scheduling
• Required Reading Resources on his Analysis
  Patterns (without buying his book), are listed at
  the end of this slide presentation
• Main Websites
• Homepage http//www.martinfowler.com/
• AP info http//www.martinfowler.com/ap2/

15
Fowlers Business View to Analysis Patterns

• Discusses vital OOP concepts like classes,
  methods, and inheritance, view/perspective of
  methodology from refactoring code to address
  business challenges/problems
• Comment Perhaps we are getting ahead of
  ourselves into design phase but who said
  analysis design isnt somewhat iterative!
• Business Domain Discussions sometimes focus on
  data structures and the types of operations that
  would be of value to the Business
• Quantity Example Money and Multiple Currencies
• Attributes Amount and Unit of Measure
• Behaviours Comparisons, Conversions, and
  Mathematical Operations ( - /)
• Range Example Dates/Times
• Attributes Start and End, Information
  Granularity Level (Date and/or Time)
• Behaviours includes for testing if a particular
  date/time value fits within a date/time range

16
Format of APs

• Introduction of Business Problem (Intent)
• Sketch (UML sometimes has conditions which
  arent in standard UML, but could be extended)
• How it Works
• Narrative
• When to use it
• Reasons to use this AP
• Also includes restrictions, trade-offs from use,
  problems not solved by technique
• Code samples (example implementation)
• Not typically part of ANALYSIS but he includes
  code so that developer-types can understand
  structures in code, in case they cant understand
  UML

17
The makings of a pattern

• A good way to start thinking about modeling
  organization structures is to think of the
  obvious way.
• Imagine a company where people work in
  departments, which are organized into divisions.

18
Common Problem

• Explicit structures have two main disadvantages.
• They dont work well if there is much common
  behavior between the kinds of organization.
• They also embed the current organizational
  categories into the design. If we wanted to add
  regions between divisions and departments, you
  have some modifications to do.

19
Hierarchy pattern

• A hierarchy like this is a good choice for many
  organizations, it certainly captures the usual
  org charts pretty well.

20
Accountability pattern

• Accountabilities represent the most powerful, and
  also the most complex way of dealing with
  organizational structures.

21
Event pattern

• Many domains react to events, so in order to
  understand why things happen we need to record
  events

22
Typed relationship pattern

• How do you represent a fact about an object, and
  allow facts to be recorded about that fact
• Create a separate object for each property. Facts
  about that property can then be made properties
  of that object.
• A common pattern for this is the Typed
  Relationship pattern. Here a person may have
  number of different employment relationships with
  a number of different companies (or even several
  with the same company).

23
Recurring events for calendars pattern

• Example Mark has a gastro clinic on the first
  and third monday of the month, and a liver clinic
  on the second wednesday. This would be
  represented by a schedule with two schedule
  elements. One schedule element would have an
  event of gastro clinic and a temporal
  expression that would handle the first and third
  monday of the month. The other schedule element
  would have an event of liver clinic and a
  temporal expression that would handle the second
  wednesday of the month.

24
Role pattern

• How do you represent the many roles of an object?
• Put common features on a host object with a
  separate object for each role. Clients ask the
  host object for the appropriate role to use a
  roles features.

25
One-Line Definitions of APs (1)

• Party
• An abstraction of people and organizational units
• Organizational Hierarchy
• Represents the hierarchy or organizational units
  within a business
• Aggregating Attribute
• Allow a child to use an attribute value from a
  parent
• Accountability
• Represents a complex graph of relationships
  between parties
• Variations Connection Rules (Knowledge Levels),
  and Levelled Accountability Type
• Knowledge Level
• A group of objects that describe how another
  group of objects should behave (also known as a
  meta-level)
• Object Graph
• A group of objects connected together in a graph
  sequence

26
One-Line Definitions of APs (2)

• Quantity
• Represents dimensioned values with both their
  amount and their unit
• Range
• Represents a range of values
• Role Subtype
• Represents ways for role subtypes to exist within
  the bounds of the understanding of a Person
• Role Object
• Separating a Person from their Role, and allowing
  host Role supertype Object for features relating
  to Role
• Role Relationship
• Represent relationships between Roles and other
  Objects

27
One-Line Definitions of APs (3)

• Audit Log
• A simple log of changes, intended to be easily
  written and non-intrusive.
• Effectivity
• Add a time period to an object to show when it is
  effective.
• Snapshot
• A view of an object at a point in time
• Temporal Object
• An object that changes over time
• Temporal Property
• A property that changes over time
• Time Point
• Represents a point in time to some granularity

28
One-Line Definitions of APs (4)

• Event
• Captures the memory of something interesting
  which affects the domain
• Schedule
• Represents a recurring event(s)
• Schedule Element
• Represents the separation of an event and its
  schedule, delegating the when to a temporal
  expression
• Set Expressions
• Represents complicated mathematical expressions
  for set operations (Union, Intersection,
  Difference)

29
Martin Fowler AP Readings

• Required Reading Resources on his Analysis
  Patterns (without buying his book)
• http//www.martinfowler.com
• /ap2/ - Details on his work since his books first
  edition, and an overview of Analysis Patterns and
  Classifications
• /apsupp/accbyNar.pdf Short Narrative on Basics
  of Organizational Structures
• /apsupp/accby.pdf Details for Analysis
  Patterns Party, Org. Hierarchy, Aggregating
  Attribute, Accountability, Knowledge Level,
  Object Graph
• /ap2/timeNarrative.html Patterns that Change
  with Time discussing Audit Log, Effectivity,
  Snapshot, Temporal Object, Temporal Property,
  Time Point

30
More on Martin Fowler AP Readings

• Required Reading Resources on his Analysis
  Patterns (without buying his book)
• http//www.martinfowler.com
• /ap2/quantity.html APs dealing with Quantity
• /ap2/range.html APs dealing with Ranges
• /apsupp/recurring.pdf APs dealing with domain
  strategies for Schedules Schedule, Schedule
  Interface, Schedule Element, Day Every Month,
  Range Every Year, Set Expressions (Union,
  Intersection, Difference)
• /apsupp/roles.pdf - APs dealing with domain
  strategies for Roles Single Role Type, Separate
  Role Type, Role Subtype, Role Object, Role
  Relationship
• apsupp/accounting.pdf APs dealing with
  practical accounting business systems (i.e.
  utility billing) Event, Accounting Entry,
  Posting Rule, Secondary Posting Rule, Account,
  Accounting Transaction, Reversal Adjustment,
  Difference Adjustment, Replacement Adjustment

31
Class Exercises

• Crossword Review
• CRCs
• Analysis Patterns

32
Requirements checkpoint

• Other things to help us
• Use natural language wherever possible (probe on
  ambiguity)
• Use pictures and diagrams to further illustrate
• Ask when in doubt, never assume, state the
  obvious
• Good requirements are
• Correct, unambiguous, complete, consistent,
  prioritized, verifiable, modifiable, traceable
  and understandable
• At this stage of the project we still do not
  have
•  most of the requirements specifically defined
•  estimates or plans for the project
•  an understanding of the architecture or design
  of the solution

33
Requirements inception

• Inception of the project has given us a domain
  model and use case requirements together with
  derivative work products such as a glossary, and
  business goals / vision.
• We now have an agreed to starting point for
  working on the solution ... our scope.
• We will iterate and increment through
  requirements and design phases to produce the
  necessary model from which to start development