Engineering Quality Software Sequence Diagrams Introduction Agenda Sequence

Engineering Quality Software Sequence Diagrams Introduction

Agenda Sequence Diagrams Review Schedule Sheridan

Objectives Learn how to develop interaction diagrams based on the principles of object responsibility and use case controllers Develop detailed sequence diagrams as the core process in systems design Sheridan

Overview Develop detailed object-oriented design models Design class diagrams o Extend domain model Interaction diagrams o Extend system sequence diagrams Sheridan

What is Object-Oriented Design? The bridge between a user’s requirements and programming for the new system o “Blueprints”, or design models, are necessary to build systems An adaptive approach to development o Requirements and design are done incrementally within an iteration o A complete set of designs may not be developed at one time Sheridan

Review of Object-Oriented Programs Object-oriented programs consist of a set of computing objects that cooperate to accomplish a result o Each object has program logic and data encapsulated within it o Objects send each other messages to collaborate Most object-oriented programs are event-driven Instantiation of a class creates an object based on the template provided by the class definition Sheridan

Object-oriented event-driven program flow Sheridan

Object-Oriented Design Models Identify all objects that must work together to carry out a use case Divide objects into groups for a multilayer design Interaction diagrams describe the messages that are sent between objects o Includes sequence and communication diagrams Design class diagrams document and describe the programming classes Sheridan

Design class for Student class Sheridan

Class definition of the Student class in the Java programming language Sheridan

Design models with their respective input models Sheridan

Design Classes and Design Class Diagrams �Design class diagrams are extensions of domain class model diagrams ◦ Elaborate on attribute details ◦ Define parameters and return values of methods ◦ Define the internal logic of methods �A first-cut design class diagram is based on the domain model and engineering design principles �Interaction diagrams are used to refine a design class diagram as development progresses Sheridan

Design Class Symbols Stereotypes o UML notation to categorize a model element as a certain type Two types of notation o Full notation with guillemets ( «» ) o Shorthand notation with circular icons Standard stereotypes o Entity, control, boundary, data access Sheridan

Standard stereotypes found in design models Sheridan

Student class examples for the domain diagram and the design class diagram Sheridan

Interaction Diagrams–Realizing Use Cases and Defining Methods Interaction diagrams are at the heart of object-oriented design Realization of a use case o Determine what objects collaborate by sending messages to each other Two types o Sequence o Communication Sheridan

Object Responsibility Objects are responsible for carrying out system processing Two major areas of responsibility o Knowing • Knowledge about its own data and about other classes with which it must collaborate to carry out use cases o Doing • All the activities (methods) an object does to assist in the execution of a use case Sheridan

Illustration Exercise: Course Registration System Use Case Scenario: “In-Person” – Register for Course Sheridan

Clerk Sheridan System

Use Case Controller An artifact invented by the designer to handle a system function o Serves as a collection point for incoming messages o Intermediary between the outside world and the internal system Sheridan

Designing with Sequence Diagrams An SSD captures the interactions between the system and the external world represented by actors o The system is treated like a black box A detailed sequence diagram uses all of the same elements as an SSD o The : System object is replaced by all of the internal objects and messages within the system Sheridan

First-Attempt Sequence Diagram Determine which other objects may need to be involved to carry out the use case Replace the : System object with a use case controller object Determine which other messages will be sent o Define the source and destination object for each message Use activation lifelines to indicate when an object is executing a method Sheridan

Summary Design is driven by use cases Two primary models developed during design o Class diagrams o Sequence diagrams Sheridan

System Architect Demo Sequence Diagram Notation NOTE: o Lifelines & focus of control o Persistence o Self-delegation Sheridan

Your turn- ICE-08 Sheridan