VIEWS: 7 PAGES: 34 POSTED ON: 4/17/2011
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: email@example.com Teaching Assistant: Haris Teguh Widjaya • firstname.lastname@example.org • Office Hours: tbd (usually in GrUVi Lab) Class e-mail list: email@example.com 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
"RASD_UML Chapter 1"