Teaching the Complete Object-oriented Development Cycle, Including OOA and OOD, with UML and the UP Robert B. Jackson Brigham Young University John W. Satzinger Southwest Missouri State University

Copyright © 2003 by R. B. Jackson and J. W. Satzinger We are teaching some OO Use case concepts UML class diagrams OO concepts OO programming languages Java VB .NET ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

But are we teaching OOA and OOD? Highly iterative development process? Emphasis on interacting objects? Three-layer architectures? Use case realization through design? Design principles and quality design? Design patterns? Models that directly support OOP? ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

OO Development using UML and the UP Model Driven Development Analysis Models drive discovery and understanding Design Models drive architecture and solution Use Case Driven Development Both Analysis and Design based on use cases ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

UP phases and iterations ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

UP disciplines and iterations ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

Object-oriented approach to Requirements OOA using UML Requirements Models

Copyright © 2003 by R. B. Jackson and J. W. Satzinger What is OO Analysis? OOA is not a phase of an SDLC in the UP OOA per se is not used in the UP OOA is really business disciplines of Business Modeling Requirements Analysis OOA still implies “discovery” and “understanding” ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

UML Models for Business Modeling and Requirements Use Case Models Use Case Diagram Use Case Descriptions Activity Diagrams for Workflow System Sequence Diagrams for Inputs/Outputs Domain Model Class Diagrams Statecharts for Status Information ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

Use Cases and Use Case Diagram Although not “Object-oriented” it forms the basis for all other analysis and design activities – i.e. building a system is “Use Case Driven.” Use Case Diagram contains “Actors” and “Use Cases” ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

A Partial Use Case Diagram ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

Detail Descriptions of Use Cases Fully developed description (textual) Activity Diagram (graphical) ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

Fully Developed Use Case Description Use Case Name: Checkout Movies Scenario: Checkout movies at counter Triggering Event: Customer brings movies to checkout counter Brief Description: When customer brings movies to counter, clerk checks membership ID, clerk scans in each movie identifier, takes payment, and notifies customer of return due date and time. Actors: Video clerk Related Use Cases: Add new member Stakeholders: Clerk, Store manager Preconditions: Movie titles must exist Movie copy must exist Customer must exist (or Add new member must be invoked) Postconditions: Video Rental and rental line items must be created Payment transaction must be created Status of movie copy must be updated Video Rental must be connected to customer family member ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

Fully Developed Use Case Description (cont) Flow of Events Actor System 1. Customer brings movies to checkout counter and presents membership card. 2. Video clerk scans card 3. Clerk scans each movie 4. Clerk indicates end of transaction 5. If coupon or special, clerk enters coupon information 6. Enter payment 7. Give movies, receipt, change to customer. 2.1 Checks membership ID. 2.2 Checks for any outstanding fines or late return fees. 2.3 Displays appropriate information 2.4 Creates new Video Rental 3.1 Creates Rental line item 3.2 Updates movie copy status 4.1 Display Total amount due, including tax and late fees. 5.1 Recalculate amount due 6.1 Process payment 6.2 Print receipt Exception Conditions: 1.1 Customer is not a valid customer – invoke create new customer use case, or reject customer status. 6.1 If payment is by credit card and credit card transaction is not authorized, (a) cancel transaction or (b) pay by cash. ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

Copyright © 2003 by R. B. Jackson and J. W. Satzinger Activity Diagram Diagram showing workflows Used to capture user procedures Used to describe sequence of steps for Use Case description (similar to Fully Developed Description) Easy for users to read and understand ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

Activity Diagram for Add New Movie ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

System Sequence Diagram Use case driven (one SSD for each use case) Identifies the inputs to and outputs from the system Analysis oriented – focuses on the business processes not on the internal system interactions An easy introduction to Interaction Diagrams ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

System Sequence Diagram for Add New Movie ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

Problem Domain Class Diagram Coordinate with Database Course? Identifies problem domain objects and relationships between those objects Analysis focuses only on problem domain objects – discovery and understanding of business objects ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

Problem Domain Class Diagram ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

Copyright © 2003 by R. B. Jackson and J. W. Satzinger Statechart Diagrams Optional diagram – many developers do not use Can be complex, therefore initially only introduce simple cases Use for discovery and understanding of the behavior of business objects Use to document “Status” conditions that the system must track ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

Copyright © 2003 by R. B. Jackson and J. W. Satzinger Statechart Diagram ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

Copyright © 2003 by R. B. Jackson and J. W. Satzinger Recap of OOA We have a complete set of models that describe many (all) aspects of the problem domain and business requirements Problem oriented – discovery and understanding Focuses on the business requirements and not on design issues of the system ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

Object Oriented Approach to Design OOD with UML Design Models

Copyright © 2003 by R. B. Jackson and J. W. Satzinger What is OOD? OOD is not a phase in the UP SDLC OOD is a business disciplines in the UP OOD is the bridge between Requirements and Programming OOD is a “developer” activity, not a user activity Few programs teach OOD – mostly we teach analysis and programming ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

Copyright © 2003 by R. B. Jackson and J. W. Satzinger UML Models for OOD Design Class Diagrams Problem domain classes View layer classes Data Access layer classes Detail Interaction Diagrams Sequence Diagrams Collaboration Diagrams Advanced Statechart Diagrams (optional) ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

Making OOD an “Engineering Discipline” Engineering disciplines have principles, standards, techniques, practices, and body of knowledge OOD is still developing, but we now are beginning to see design principles and practices ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

Making OOD an “Engineering Discipline” Principles of “good” design Cohesion Coupling Object Responsibility Protection from variations Object visibility Design Patterns for standard solutions Gang of four (GoF) design patterns Enterprise level design patterns (J2EE) Microsoft Application design patterns ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

Copyright © 2003 by R. B. Jackson and J. W. Satzinger ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

Multi-layer Design Class Diagrams Includes problem domain classes Includes service and utility classes Includes view layer classes Includes data access layer classes Advanced concepts Advanced design can get complex for enterprise level systems Teach only the basics in SA&D – prepares students for advanced concepts when they get into industry ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

Detailed Interaction Diagrams Two types Sequence Diagrams Collaboration Diagrams Use Case Driven (for each use case) Show internal software objects that “collaborate” to execute a use case Objects “collaborate” by sending messages to each other Messages become method calls in OOP ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

Copyright © 2003 by R. B. Jackson and J. W. Satzinger Sequence Diagrams Same components as SSD :System is exploded into internal objects Activation Lifeline is a rectangular box on the object lifeline showing active “execution” ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

Copyright © 2003 by R. B. Jackson and J. W. Satzinger ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

Copyright © 2003 by R. B. Jackson and J. W. Satzinger The Design Process Micro-level iterations (within a UP iteration) First cut at Design Class Diagram Type cast attributes Determine preliminary navigation visibility Micro Iteration 1 With problem domain classes, develop sequence diagram Micro iteration 2 (or more) Add view layer classes Add data access layer classes Add other service classes ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

Copyright © 2003 by R. B. Jackson and J. W. Satzinger Micro Iteration 1 First – design with the problem domain classes ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

Copyright © 2003 by R. B. Jackson and J. W. Satzinger ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

Copyright © 2003 by R. B. Jackson and J. W. Satzinger Micro Iteration 2 Second – Add view layer (<<boundary>>) classes ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

Copyright © 2003 by R. B. Jackson and J. W. Satzinger ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

Copyright © 2003 by R. B. Jackson and J. W. Satzinger Micro Iteration 2 or 3 Third – Add data access layer classes ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

Copyright © 2003 by R. B. Jackson and J. W. Satzinger ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

Copyright © 2003 by R. B. Jackson and J. W. Satzinger ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved

Copyright © 2003 by R. B. Jackson and J. W. Satzinger Advance Topics Design patterns Statecharts for design Method logic on transitions action expressions System wide states, menu design, system modes Enterprise level design (multilayer, and many service components) ISECON 2003 San Diego Copyright © 2003 by R. B. Jackson and J. W. Satzinger All Rights Reserved