Learning Center
Plans & pricing Sign in
Sign Out

RASD_UML Chapter 1


									CMPT 370: Information Systems Design

    Instructor: Curtis Cartmill, Simon Fraser University – Summer 2003
CMPT 370 Course Objectives
   This course is designed to look at the practice of
    software analysis and design in the context of the
    software engineering process.
   The course focuses on an object oriented
    approach, using UML to capture analysis and
    design artifacts.
   The course will also introduce the use of patterns
    as a technique to reuse analysis and design ideas
    and best practices thereby leveraging the expertise
    of others.
   The class will combine both lectured learning as
    well as in-class exercises to gain knowledge and
    experience through practice.

CMPT 370 Course Topics
   Domain Engineering (May)
    • Use Cases / Requirements
    • Domain modeling

   Solution Engineering (June)
    • Design Modeling
    • Design Patterns

   Architecture (July)
    • Implementation Modeling
    • Data / Message Modeling

CMPT 370 Course Information
• Grading
   • 40% Primarily 2 Mid-terms, plus Class Activities
   • 20% Term Project
   • 40% Final Exam (August 7, 7pm-10pm)

• Prerequisites / Corequisites
    • CMPT 275 & CMPT 354

•Textbook - Requirements Analysis and System Design, Leszek
Maciaszek, Addison Wesley, 2001

•References and Other Course Material
    • To be distributed in class or posted on class web- site

CMPT 370 Course Web Site
Class website:
 All class presentation material including class
  assignments will be posted on the web site by
  Monday evening prior to lecture
 Additional reading material will be posted on the
  web site (links)
 Website will be used to post „answers‟ to in-class
  assignments and quizzes
 Course will use the SFU Gradebook for posting
 Course will use the submission server for handing
  in of Term Project

CMPT 370 Other Resources
   Instructor Office Hour:
    • ASB-9923 – shared office
    • Fri 10:30 am - 12 pm, tel: 604-291-????
    • e-mail:

   Teaching Assistant: Haris Teguh Widjaya
    • Office Hours: tbd (usually in GrUVi Lab)

   Class e-mail list:

The class will combine both lectured learning as
well as in-class exercises to gain knowledge and
experience through practice

   First 60-90 minutes: lectured learning
   Next 30-60 minutes: exercise/practice
   Next 30-60 minutes: discussion

    The best way to learn is by doing

  The context of the software engineering process.

Requirements Design   Construction Test   Implementation

         Iterative and incremental development

This course is designed to look at the practice of
software analysis and design in this context

                             •Build the right product
                             •Build the product right
  ( Analysis)       Design

       „What‟          „How‟       SMOP*

What is analysis
   Analysis emphasizes an investigation of the
    problem and requirements, rather that the
   Analysis:
    • Requirements analysis
    • Domain analysis
   During Object Oriented Analysis there is an
    emphasis on finding and describing
    concepts in the problem domain
   Analysis = the „what‟

What is design
   Design emphasizes a conceptual solution that
    fulfills the requirements, rather than its
    implementation (i.e. Designs/Models rather than
   Ultimately designs can be implemented
   During Object Oriented Design there is an
    emphasis on defining software objects and how
    they collaborate to fulfill the requirements
   Models capture various relationships,
    communications, data/information b/w objects
   Design = the „How‟

The course focuses on an object oriented approach, using
UML to capture analysis and design artifacts.
   Analysis and Design Artifacts ( UML)
    •   Use Case Diagram
    •   Class Diagram
    •   State Diagram
    •   Interaction Diagrams
         – Collaboration
         – Sequence
    • Activity Diagrams
    • Implementation Diagrams
         – Component
         – Deployment
In addition we will look at Use Cases and
  Architecture artifacts

What is UML
   UML = Unified Modeling Language
   UML is a language for specifying,
    visualizing, constructing and documenting
    artifacts of software systems
   UML has emerged as the de facto and de
    jure standard diagramming notation for
    object oriented modeling
   The course teaches UML implicitly through
    the performance of analysis and design

Brief History of UML
   From “UML In a Nutshell” (Sinan Si Alhir)
   Fragmentation
    • mid-1970s to mid-1990s
    • Looking for magic in production of software to increase
      quality, reduce costs, mitigate risks, reduce time-to-market
    • first generation object-oriented modeling languages
   Unification
    • mid-1990s – 1997
    • Unified Method was Grady Booch (Booch ‟93) and Jim
      Rumbaugh (OMT-2)
    • Unified Modeling Language (UML) refers to combination
      efforts of “Three Amigos” once Ivar Jacobson and his
      OOSE was merged into the mix (unified together when
      working at Rational Software Corp.)
    • Evolution of basis, goals, trade-offs

Brief History of UML (cont.)
   Standardization
    • UML Partners Consortium formed late 1996
    • UML 1.0 – January 1997 submitted to Object
      Management Group‟s Object Analysis and
      Design Task Force (RFP on standards for tools
      that support OOAD)
    • UML 1.1 – November 1997
   Industrialization
    • UML officially adopted by OMG on Nov. 17,
    • UML embraced by Industry and Software
      Vendors. UML products and services offered

What are Patterns
   A Pattern is a named problem/solution pair
    that can be applied in new contexts, with
    advice on how to apply in varying
    circumstances and discussion and
    consideration of forces and of trade-offs
   The term pattern suggests a „repeating
   Patterns attempt to apply existing tried and
    true knowledge, idioms and principles

The course will also introduce the use of patterns as a
technique to reuse analysis and design ideas
   Analysis Patterns
    • Martin Fowler

   Design Patterns
    • Gang of Four: Gamma,Helm,Johnson,Vlissides

   Architecture Patterns

   Anti-Patterns
    • Brown,Malveau,McCormick,Mowbray

CMPT 370 In a nutshell

    Architecture                             Domain


           constraints                   rules
            standards                    roles
           affordances               requirements


What is our starting point
   We have an understanding of software
    development process

   We have used and are familiar with an
    Object Oriented Programming language (i.e.
    Java / C++ / Smalltalk)

   We have no knowledge or experience with
    OOA and OOD

   We have no knowledge or experience with
What is modeling
   Modeling is a critical skill with communal
    qualities, constrained more by the need to
    communicate and describe effectively than
    by prescriptive standards.
   A model lives only through its interpretation.
   Every complex system is best approached
    through a small set of somewhat
    independent views of a model. No single
    view is sufficient. Every model needs to be
    expressed at different levels of
    fidelity/granularity (low vs. high level).

Time permitting, other good “real world”
lessons for an “Information Systems Design”
   Communications / Message Design
     • XML and related Technologies, Designing Data and Messages
       with Context

   Database design
     • Persistence, but cover Data Design with artifacts (ER Diagrams),
       Varieties of Databases

   User Interface Design
     • Veiws, but designing interfaces that meet goals such as
       efficiency, effectiveness, and simple for users to use. (i.e. Good
       Principles in UI Design)

   Information Glut (what do they all mean...)
     • Defintions and Relationships between Information Retrieval,
       Information Filtering and Information Extraction

       Getting started
                                           Gap between stakeholders
                                             • Users have the vision (to use)
                                             • Developers need the specifications
                                               (to build)
                                           Analysis and Design span the gap

       ??                               
                                             • Understand user needs
                                             • Transform needs into specifications
                                               described through artifacts
                                            This is the creative/artistic part of
                                            software development
                                           This can be the area where projects
                                           Discussion: Why do projects fail?

Vision/Requirements --- interpreting reality constructing reality --- Product

Understand user needs
   What does the user expect the solution to
   The Use Case Model uses actors and use
    cases as concepts to aid in defining what
    can exist outside the system and what can
    be performed by the system
    • Actors represent what interacts with the system
       – Differentiate between actor and user
       – Actors are used as tools for finding use cases
    • A Use Case represents a unique (business)
      value provided to the actor
       – Describes a particular, observable, system behaviour

   Actors model roles – should be separate from
    implementation details such as job titles or
   Users can have multiple roles
   A role can be performed by multiple users
   Roles need to be generic but focused
   Actors are contextual
   Identification of actors is iterative, may subdivide as
    specializing actors in process
   Actors are a critical starting point for establishing
    use cases
   A role is a candidate for being represented as an
    object within the system

Actors and Roles…
   Examples of Actors: Customer (very generic),
    Manager, Administrator, Clerk, System
    • Domain-Dependent
   Actors who may have multiple different roles
    • Secretary/Receptionist: Appointment Scheduler, Expense
      Approver, Mail Sorter
    • Customer Service Representative (CSR): Transaction
      Generator (Ordering Products), Problem Service Reporter
   Some Roles may be performed by different people
    • Booking Flights: Customer (self-service on-line) or Travel

Use Cases (1)
   Requirements are fundamental and provide
    justification for any development activity
   Requirements need to be organized and managed
   Use Cases represent requirements
   Use Cases describe how the system will be used
   Use Cases drive product specifications
   Use Cases form a basis for organizing and planning
   Use cases can be used to partition work in
    increments (though it does not impose a
    development process – use case driven

Use Cases (2)
   Use cases are a basis for trace-ability
   Use cases provide a basis for product testing
    throughout the software lifecycle as well as
    iterations of the development cycle
   Use Case model is a contract with the user that
    specifies what will be provided by the product (does
    not define the how)

Use Case Modeling
   Captures the customer expectations of the
    functionality of the system
   Must be expressed clearly so that both
    sides can commit themselves to the project
   Use Case modeling process
    • Identify potential actors
    • Identify potential use cases
    • Focus on the system boundary
       – Not on internal structure, mechanisms, or algorithms

Use Case Diagram Glossary
   Actor
   Use Case
   System Boundary
   Associations
    • Dependency
       – pre-conditions (i.e. logging in)
    • Includes
       – Incorporates behaviour of another use case at a point (Must
         complete another common use case in order to complete the
         base use case)
    • Extends (Extension Points)
       – Extends the behaviour of another use case (Could be
         performed after a base case is completed)
    • Generalization
       – Inherits behaviour of another use case, and can be
         interchanged with its parent use case

Use Case Diagram: Gas Station System
A system is required that will perform services for
customers without having them leave the comfort of
their car

                             pump gas

                             clean the windows

                        check the oil

Use Case Diagram for Visiting a Doctor
(U.S. Version)

Use Case Diagram: Airline Reservation

Textbook Notes
   Section 1.1 – Nature of Software Development
    • Understanding Stakeholders
    • Defining Process (including models in Industry [i.e. CMM])
    • Defining Modeling Languages and Tools
   Section 1.2 – System Planning
    • Theory behind Business Strategies and Decisions
    • Approaches: SWOT, VCM, BPR, ISA
   Section 1.3 – Software Lifecycle Phases
    • Appreciate the various phases for developing quality
      software (review of CMPT 275)
   Section 1.4 – Software Development Approaches
    • Structured (Procedural) Approach vs. Object-oriented
      Approach (classes, attributes, methods, inheritance,
   Section 2.2.2 – Use Case Modeling
   Section 3.5.2 – Business Use Case Model Example

Class exercise
    Draw use case diagrams for the following
     systems. I need:

1.   A system that will allow me to watch my favorite
     TV shows whenever I feel like it
2.   A system that aids me in getting up in the morning
3.   A system that allows me to communicate with
     people who do not know English
4.   Expand the Use Case for Visiting a Doctor to
     include other use cases: Check Patient Chart,
     Defer Payment, Bill Insurance
5.   Suppose you picked up a prescription from the
     doctor. Design a system that allows you to get
     medication from a Pharmacy.


To top