CMPT 370: Information Systems Design

1
CMPT 370 Information Systems Design

• Instructor Curtis Cartmill, Simon Fraser
  University Summer 2003

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

3
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

4
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

5
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

6
CMPT 370 Other Resources

• Instructor Office Hour
• ASB-9923 shared office
• Fri 1030 am - 12 pm, tel 604-291-????
  
• e-mail ccartmil_at_cs.sfu.ca
• Teaching Assistant Haris Teguh Widjaya
• htw_at_sfu.ca
• Office Hours tbd (usually in GrUVi Lab)
• Class e-mail list cmpt-370-e1_at_sfu.ca

7
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
8
The context of the software engineering process.
Iterative and incremental development
9
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-
10
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

11
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

12
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

13
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

14
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

15
Brief History of UML (cont.)

• Standardization
• UML Partners Consortium formed late 1996
• UML 1.0 January 1997 submitted to Object
  Management Groups 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

16
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

17
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

18
CMPT 370 In a nutshell
19
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

20
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).

21
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

22
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
23
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

24
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

25
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

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

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

28
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

29
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

30
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
System boundary
31
Use Case Diagram for Visiting a Doctor (U.S.
Version)
32
Use Case Diagram Airline Reservation System
33
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

34
Class exercise

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