Information Systems Analysis and Design Overview of OOAD, UML, and RUP

1
Information Systems Analysis and DesignOverview
of OOAD, UML, and RUP

• INFO 620
• Glenn Booker

2
Syllabus

• This course is about learning and applying
  Object-Oriented Analysis and Design (OOAD),
  expressed using the Unified Modeling Language
  (UML)
• Primary text is Larmans Applying UML and
  Patterns (2nd ed.)
• Quatranis Visual Modeling with Rational Rose
  2002 and UML is for Rose users

3
Your Background

• How much experience do you have with
• Programming?
• Object oriented programming?
• If any, what programming languages are you most
  comfortable using?
• Other than your grade, are there any aspects of
  this course in which youre most interested?

4
More than Software

• The texts are focused only on software
• Remember that your system will probably involve
  other things, such as
• Hardware
• Users
• Training
• Documentation, etc.

5
What is Object Oriented?

• Earlier analysis methods were focused on process
  (such as a Data Flow Diagram, or DFD) or data
  (e.g. using an Entity Relationship Diagram, or
  ERD)
• Object oriented (OO) methods blend data and
  process into objects, and focuses on how those
  objects interact using methods (passing messages)

6
What is Object Oriented?

• Traditional design creates entities (data
  tables), and changes them using scripts,
  procedures, macros, or other techniques
• OOAD creates objects from classes, and applies
  them using their methods or operations

Image from Apple, Object-Oriented Programming
and the Objective-C Language
7
What is an Object?

• An entity with a well-defined boundary and
  identity that encapsulates state and behavior.
  State is represented by attributes and
  relationships, behavior is represented by
  operations, methods, and state machines. An
  object is an instance of a class. (UML 1.5 spec
  see slide 22)

8
Huh?

• Attributes are the data contained by an object,
  if any
• Relationships describe which objects are allowed
  to talk to each other
• The operations and methods describe the ways
  objects can interact with each other
• So objects are a set of data which can only be
  acted on in certain prescribed ways

9
What is a Class?

• A description of a set of objects that share the
  same attributes, operations, methods,
  relationships, and semantics. A class may use a
  set of interfaces to specify collections of
  operations it provides to its environment. (UML
  1.5 spec)
• Hence a class is a group of similar objects

10
OO Languages

• Common object-oriented languages include the
  cousins C, Java, and C (C sharp)
• Lesser known OO languages include
• Smalltalk (first OO language, 1980)
• Ada 95 (highly reliable, real-time systems)
• Objective-C (Macintosh)
• And many, even more obscure languages

11
The Old Ways

• Process Oriented Methodology
• Invented in the 1960s
• Focuses on using DFD
• Weak for projects over 50k LOC
• Subject to frequent change (every time a process
  is tweaked, the DFD changes)

12
The Old Ways

• Data Oriented Methodology
• Introduced in 1976, and primary method used from
  the 1980s to today
• Focuses on using the ERD
• Doesnt change as often as the DFD
• Shows business rules through cardinality (0, 1,
  ?)
• Works for systems up to about ½ million LOC

13
The New Way

• Object Oriented Methodology
• Encapsulates data and processes to allow large
  system development (millions of LOC)
• Getting standardized (UML, CORBA)
• Slow to be adopted by industry, mostly due to
  inertia of data and process methods (large
  installed base)

14
OO Objectives

• We want a development method which
• Is able to guide us through analysis, design, and
  implementation using one consistent paradigm
  throughout those phases
• Is less likely to generate errors
• Contains checks to help eliminate errors
• Facilitates reuse of designs and code

15
Object Oriented Analysis

• OOA is a method of analysis that examines
  requirements from the perspectives of the classes
  and objects. (Booch 1995)
• Emphasis is on finding and describing conceptual
  objects which are relevant to your problem

16
Object Oriented Design

• OOD is a method of design encompassing the
  process of OO decomposition and a notation for
  depicting both logical and physical as well as
  static and dynamic models of the system. (Booch
  1995)
• Emphasis is on defining software objects, and how
  they collaborate to fulfill system requirements

17
Analysis and Design

• Like the process and data methodologies, note
  that
• OO Analysis is done with no concern of how it
  will be implemented
• OO Design considers implementation issues
• Also note that there are conceptual objects
  (analysis) and software objects (design)

18
Analysis vs. Modeling

• Analysis is the process of understanding
  something
• The results of analysis may be captured
  (expressed) using modeling
• Modeling depends on have some language to express
  the concepts
• UML is a language for modeling OOAD

19
Why use UML?

• UML replaced a herd of competing OO methods from
  the early to mid 1990s, e.g.
• OMT method (most popular, Rumbaugh)
• Mainstream Objects(MO) method, Ed Yourdon
• Objectory method (Jacobson)
• Booch method (Booch duh)
• CRC method (Wirfs-Brock)
• Fusion method (developed by Coleman (HP))

20
Why use UML?

• Around 1995, five OO methods shared 75 of the
  market
• OMT led with 34-40 of market, hence UML was
  based on the OMT method
• Booch and Schlaer Mellor were also popular
• All other methods shared remaining 25 of the
  market, including corporate-defined OO methods

21
Unified Modeling Language

• The three amigos created UML in 1997-8
• Grady Booch
• James Rumbaugh
• Ivar Jacobson
• Their three 1999 books are instant classics
• The UML User Guide
• The UML Reference Manual
• The Unified Software Development Process

(ISBNs 0201571684, 020130998X, and 0201571692)
22
Intro to UML

• UML is defined by the Object Management Group
  (www.omg.org), a worldwide consortium of OO
  product vendors
• First standardized in 1997
• Latest version is 1.5 (March 2003)
• Booch, Rumbaugh, and Jacobson all work for
  Rational Software Inc. (rational.com)

A rather dry 736-page tomebut nice glossary!
23
UML Goals

• The goals of UML are
• To model systems using OO concepts
• To establish an explicit coupling between
  conceptual and software artifacts (objects)
• To address the issues of scale inherent in
  complex mission critical systems
• To create a modeling language usable by both
  humans and machines

24
UML Lineage

• UML not only replaced the methods by Booch,
  Rumbaugh, and Jacobson, but also borrowed from
• Fusion (Operation description message
  numbering)
• Embley (Singleton class)
• Meyer (Pre- and post-conditions)
• Shlaer and Mellor (Object life cycles)

25
UML Lineage

• Martin and Odell (Classification)
• Wirfs-Brock (Responsibilities)
• Harel (State charts)
• Gamma, et al (Patterns)
• So UML borrowed from all of the best ideas

26
UML and OOAD

• UML has twelve diagrams, but three types are most
  commonly used
• Use case modeling
• Class modeling
• Interaction modeling with patterns
• Just because English has 600,000 words doesnt
  mean you need to use them all 3000 is plenty
  for most occasions

27
UML Method

• A method needs a language, and a process to
  describe how to use the language Method
  Language Process
• The Rational Unified Process (RUP or UP) was
  designed to be used with UML
• UP is an iterative process
• Provides a structure for system development

28
More RUP Info

• Rational has lots of white papers if youre
  interested in the Rational Unified Process (good
  even if youre not using Rose), Rose, or the
  Suite DevelopmentStudio (sic)
• Or you can buy additional documentation on their
  products (extremely optional!)
• See Rose download instructions for more
  documentation info

29
Iterative Development
Larmanp. 15

• System is defined by use cases
• A use case is a major way of using the system,
  or a major type of functionality
• High level planning needs to
• Define what are the major use cases
• Determine in what order they will be done
• Estimate development time for each use case
  (timeboxing)

30
Iterative Development

• Each development iteration creates one use case
• Includes the entire life cycle (requirements
  analysis, design, implementation, and testing)
• Results in an executable portion of the system or
  some other clearly defined end product
• E.g. an ATM which can only do withdrawals
• Is planned with a fixed time to completion

31
UP Phases
Larmanp. 19

• Inception
• Elaboration
• Construction
• Transition

32
Inception Phase

• Conduct feasibility study
• Define approximate vision, business cases, and
  scope for project
• Develop vague estimates (size, cost, and
  schedule)

33
Elaboration Phase

• Refine vision
• Identify most requirements and scope
• Do iterative implementation of the systems core
  architecture
• Resolve high risks

34
Construction Phase

• Do iterative implementation of the systems
  easier and lower risk elements
• Prepare for deployment

35
Transition Phase

• Conduct beta tests
• Deploy system

36
UP Disciplines

• A discipline is a set of activities and the
  related artifacts created by those activities
• An artifact is any work product code,
  documents, diagrams, models, etc.
• This course focused on three disciplines
• Business Modeling
• Requirements Analysis
• Design

37
Other UP Disciplines
Larmanp. 21

• Other UP Disciplines include
• Implementation (programming building the
  system)
• Test
• Deployment (releasing the system)
• Configuration and Change Management
• Project Management
• Environment (create development environment)

38
Iteration, Disciplines, Phases

• Each iteration may use some or all of the
  disciplines, depending on when that iteration
  occurs in development
• Likewise, the Phases may each correspond to one
  or more iterations (p. 22 Larman), so each Phase
  will also use some or all of the disciplines

39
Larmans Text Approach

• Larman uses three iterations
• Inception
• Iteration 1
• Iteration 2
• Iteration 3
• Course only uses one big iteration, due to time
  constraints

40
Larmans Text Approach

• Inception
• Basic requirements analysis
• Use case modeling
• Iteration 1
• Fundamental OOAD
• Assign responsibilities (define who does what)
• Build domain models (class models and interaction
  diagrams)

41
Larmans Text Approach

• Iteration 2
• Object design with design patterns
• GRASP patterns (a Larman term)
• Iteration 3
• Architectural analysis and framework design
• Relating use cases
• Refine domain models with generalization and
  advanced modeling

42
OO Concepts Class

• A Class is a group of objects with common
  features and common behaviors such as
• Attributes
• Operations
• Relationships with other objects
• A Class has two components
• Data (SSN, height, price, ISBN, etc.)
• Operations (interfaces or methods)

43
OO Concepts - Object

• An Object is any meaningful concept, abstraction,
  or thing for the problem at hand
• An Object is an instance of a class
• Bill Clinton is an object, of the class Customer
• Objects have three components
• Data
• Operations (interfaces or methods)
• Object identity (OID) like entitys primary key

44
OO Concepts Operations

• Interface
• A logical description of the way objects interact
• Describes the functions (play, record, hire)
• Method
• A physical implementation of how objects
  interact or of an operation for a class
• Pushing the VCR button is a method

45
OO Paradigm

• All OO things (AD methods, databases,
  interfaces, operating systems, etc.) have four
  common characteristics
• Abstraction
• Encapsulation
• Generalization Specialization, Inheritance
• Polymorphism

46
Abstraction

• Abstraction is the process of modeling only
  relevant features
• Hide unnecessary details which are irrelevant for
  current purpose (and/or user), like eye color
• Reduces complexity and aids understanding
• Done via class, inheritance, association, and
  aggregation concepts

47
Encapsulation

• Encapsulation is the integration of data and
  operations into a class
• Supports information hiding by concealing
  implementation of the object
• Allows us to call a function without knowing, or
  caring, how its implemented
• Sqrt(x)

48
Encapsulation
We dont access data directly ever! Only access
data via messages between objects
49
Generalization Specialization

• Generalization is the process of identifying
  common features among classes leading to
  superclasses
• Specialization is the process of creating more
  specialized subclasses from an existing class

50
Inheritance

• Subclasses inherit all of the properties and
  operations defined for the superclass, and will
  usually add more
• Sometimes modeled using is a or AKO (a kind
  of) concepts

51
Inheritance
52
Inheritance

• Is an implementation concept
• Substitutability means the subclass must be
  usable when its superclass object is expected
• Subtyping is using inheritance based on
  substitutability
• Example could also be broken by powered vs.
  unpowered, or land vs. air, or other ways

53
Inheritance

• Could also look to biology for examples
• A human being inherits properties and
  characteristics from
• Primates, and
• Mammals, and
• Animals
• But it doesnt perform the function
  photosynthesis, because it isnt a Plant

54
Polymorphism

• Means many shapes
• Allows dynamic substitution of objects within an
  inheritance hierarchy
• Allows services to be shared by many classes
  (a.k.a. overloading a function)
• A method called calculate area for a class
  drawing object will have different definitions
  depending on whether the drawing object is a
  triangle, square, diamond, circle, etc.

55
Architectural Concepts

• Software is often written to different levels of
  the systems architecture
• User Interface (what the user sees)
• Application (the body of your software)
• Technical Services (general purpose services to
  support your application)
• These later correspond to different computer
  systems which implement them

56
Inception Phase

• The inception phase focuses on analyzing the
  feasibility of a project
• Can we make a business case to prove this project
  is a good idea?
• Is this project technically feasible?
• Very roughly, how much time and money will this
  project need?
• What risks can we foresee?