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

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. Requirements Design Construction Test Implementation 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 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

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.