Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

RASD_UML Chapter 1

VIEWS: 7 PAGES: 34

									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.

                                                          2
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

                                  3
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


                                                                4
CMPT 370 Course Web Site
Class website: www.cs.sfu.ca/CourseCentral/370/
 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
  grades
 Course will use the submission server for handing
  in of Term Project


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


   Teaching Assistant: Haris Teguh Widjaya
    • htw@sfu.ca
    • Office Hours: tbd (usually in GrUVi Lab)


   Class e-mail list: cmpt-370-e1@sfu.ca


                                                 6
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




                                                   7
  The context of the software engineering process.




Requirements Design   Construction Test   Implementation




         Iterative and incremental development

                                                           8
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
  Requirements
  ( Analysis)       Design


       „What‟          „How‟       SMOP*
       -fuzzy-


                                                        9
What is analysis
   Analysis emphasizes an investigation of the
    problem and requirements, rather that the
    solution
   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‟


                                              10
What is design
   Design emphasizes a conceptual solution that
    fulfills the requirements, rather than its
    implementation (i.e. Designs/Models rather than
    Code)
   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‟



                                                      11
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

                                                     12
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
    activities


                                                13
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


                                                                14
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,
      1997
    • UML embraced by Industry and Software
      Vendors. UML products and services offered

                                                      15
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
    thing‟.
   Patterns attempt to apply existing tried and
    true knowledge, idioms and principles



                                                   16
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




                                                          17
CMPT 370 In a nutshell

                         alignment
                             fit
    Architecture                             Domain



                         Product

           constraints                   rules
            standards                    roles
           affordances               requirements




                         Solution




                                                      18
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
    modeling
                                              19
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).

                                                 20
Time permitting, other good “real world”
lessons for an “Information Systems Design”
class
   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

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

       ??                               
                                             • 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
                                            fail
                                           Discussion: Why do projects fail?


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

                                                                                  22
Understand user needs
   What does the user expect the solution to
    perform
   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

                                                                23
Actors
   Actors model roles – should be separate from
    implementation details such as job titles or
    technology
   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


                                                         24
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
      Agent




                                                                   25
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
    work
   Use cases can be used to partition work in
    increments (though it does not impose a
    development process – use case driven
    development)

                                                    26
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)




                                                      27
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
    requirements
   Use Case modeling process
    • Identify potential actors
    • Identify potential use cases
    • Focus on the system boundary
       – Not on internal structure, mechanisms, or algorithms




                                                                28
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

                                                                  29
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




       customer
                             clean the windows




                        check the oil



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




                                     31
Use Case Diagram: Airline Reservation
System




                                    32
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,
      polymorphism)
   Section 2.2.2 – Use Case Modeling
   Section 3.5.2 – Business Use Case Model Example

                                                               33
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.

                                                      34

								
To top