1 Detail Design: Use-Case Design. 24 2 Background on Use Case Design Have ‘done’ Architectural Design; You know the major (eleven) precepts of good design.

Slides:



Advertisements
Similar presentations
Deliverable #8: Detailed Design - Overview due: Wednesday, 7 March All Deliverable materials are to be posted into Team Concert. Your to.
Advertisements

Introduction to Rational Rose 2000 v6.5 Copyright © 1999 Rational Software, all rights reserved 1 Rational Rose 2000 Interaction Diagrams.
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1/20 Interaction Diagrams.
Object-Oriented Analysis and Design CHAPTERS 12-14: INTRODUCTION TO DESIGN 1.
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1/18 Use Case Analysis – continued Control Classes.
Drawing System Sequence Diagrams
L4-1-S1 UML Overview © M.E. Fayad SJSU -- CmpE Software Architectures Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
J. Scott Hawker p. 1 Material © IBM Rational Software Use-Case Analysis Analyze the requirements to discover what the system objects are These.
CSCI 639 Topics in Software Engineering Assignment #5 Fall 2008.
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1 Interaction Diagrams.
NJIT Drawing System Sequence Diagrams Chapter 10 Applying UML and Patterns Craig Larman Presented by Anuradha Dharani.
Sample Analysis Model. Example: Sequence Diagram –“Richer Sample.” : Student : RegisterForCoursesForm : RegistrationController : Schedule : Student :
Detail Design: Use-Case Design
Objectives Explain the purpose and objectives of object- oriented design Develop design class diagrams Develop interaction diagrams based on the principles.
1 Detail Design Subsystem Design Static Part - VOPC.
Detail Design Subsystem Design Background and the Dynamic Part
Use Case Analysis – continued
Object Oriented Analysis and Design Using the UML
Object-Oriented Analysis and Design
OOAD – Dr. A. Alghamdi Mastering Object-Oriented Analysis and Design with UML Module 6: Use-Case Analysis Module 6 - Use-Case Analysis.
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1/29 Object Oriented Analysis and Design Using.
The Design Discipline.
Why Analysis Process Refer to earlier chapters Models what the system will do makes it easier for understanding no environment considered (hence, system.
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 4: Detailing a Use Case.
UML - Development Process 1 Software Development Process Using UML (2)
Rational Unified Process Fundamentals Module 4: Disciplines II.
Shanghai Jiao Tong University 上海交通大学软件工程中心 Object Oriented Analysis and Design Use-Case Design.
RUP Design RUP Artifacts and Deliverables
SWE © Solomon Seifu ELABORATION. SWE © Solomon Seifu Lesson 11 Subsystem Design.
Requirements To Design--Iteratively Chapter 12 Applying UML and Patterns Craig Larman.
1 Detail Design Subsystem Design Background and the Dynamic Part.
SWE © Solomon Seifu ELABORATION. SWE © Solomon Seifu Lesson 10 Use Case Design.
Copyright 2002 Prentice-Hall, Inc. Chapter 2 Object-Oriented Analysis and Design Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey.
Systems Analysis and Design in a Changing World, 3rd Edition
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Source: Peter Eeles, Kelli Houston, and Wojtek Kozaczynsky, Building J2EE Applicationa with the Rational Unified Process, Addison Wesley, 2003 Prepared.
Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.
Notes of Rational Related cyt. 2 Outline 3 Capturing business requirements using use cases Practical principles  Find the right boundaries for your.
GRASP: Designing Objects with Responsibilities
Introduction to Rational Rose 2000 v6.5 Copyright © 1999 Rational Software, all rights reserved 1 Rational Rose 2000 Class Diagrams.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 1 Object-oriented Design.
1 IBM Software Group ® Mastering Object-Oriented Analysis and Design with UML 2.0 Module 6: Use-Case Analysis.
L6-S1 UML Overview 2003 SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College.
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 1: Introduction to Use-Case Modeling.
ANALYSIS - II REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Discovering object interaction. Use case realisation The USE CASE diagram presents an outside view of the system. The functionality of the use case is.
1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements workflow –Workers participating in the requirements workflow.
Project Deliverables CIS 4328 – Senior Project 2 And CEN Engineering of Software 2.
Project Deliverables CEN Engineering of Software 2.
Use Case Model Use case diagram. Relevant Requirements Artifacts Use-Case Model Supplementary Specification Use-Case Specifications... Glossary Actors.
1 IBM Software Group ® Mastering Object-Oriented Analysis and Design with UML 2.0 Module 9: Describe the Run-time Architecture.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
1 IBM Software Group ® Essentials of Visual Modeling with UML 2.0 Module 5: Interaction Diagrams.
OOAD Using the UML - Subsystem Design, v 4.0 Copyright  Rational Software, all rights reserved 1 R Subsystem Design.
Object Oriented Analysis and Design using the UML Use-Case Analysis Adapted by Dr. Spiegel from Slides Provided by Rational Software.
Analysis Yaodong Bi. Introduction to Analysis Purposes of Analysis – Resolve issues related to interference, concurrency, and conflicts among use cases.
UML - Development Process 1 Software Development Process Using UML.
CSIS 4850: CS Senior Project – Spring 2009 CSIS 4850: Senior Project Spring 2009 Object-Oriented Design.
OOD OO Design. OOD-2 OO Development Requirements Use case analysis OO Analysis –Models from the domain and application OO Design –Mapping of model.
Project Deliverables CIS 4328 – Senior Project 2 And CEN Engineering of Software 2.
Gerhard Dueck -- CS3013Analysis 1. Gerhard Dueck -- CS3013Analysis 2 Why analysis?  Yield a more precise specification of the requirements.  Introduce.
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1 Use Case Analysis – continued Control Classes.
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1 Use Case Analysis – Part 4 Analysis Mechanisms.
The Movement To Objects
Unified Modeling Language
Use Case Model Use case diagram.
CIS 4328 – Senior Project 2 And CEN Engineering of Software 2
Use-Case Design in Context
Use Case Analysis – continued
Software Development Process Using UML Recap
Presentation transcript:

1 Detail Design: Use-Case Design

24 2 Background on Use Case Design Have ‘done’ Architectural Design; You know the major (eleven) precepts of good design. Now, we drop down a level to Detail Design Now:  Use Case Design;  Subsystem Design, and  Class Design. All are very different and satisfy different purposes. After class design, you are ready to code.

24 3 Objectives: Use-Case Design (1 of 2) Start of ‘Detail Design’ – right above coding. Verify consistency in use-case implementation  1. Verify that all necessary behaviors cited in the use case narratives have been distributed along the participating classes See use case narratives and interaction diagrams  2. Verify that all associations between design elements (classes and subsystems in layers and other components) needed for the use case realizations have been defined, See layer architecture and components therein.

24 4 Objectives: Use-Case Design (2 of 2)  3. Verify that all of the attributes needed for the use cases have been defined and found in domain models, glossary, etc.. See class diagrams  4. Refine the Use-Case Realizations (boundary, control, entity classes and subsystems interfaces) from Use-Case Analysis into design model elements  5. Ensure application architectural mechanisms (persistence, security, etc.) are incorporated into the use case realizations. Use Case Realizations are captured via software class diagrams and interaction diagrams for various scenarios.

24 5 Use-Case Design in Context Architect Designer Architectural Analysis Architecture Reviewer Review the Design Review the Architecture Use-Case Analysis Architectural Design Describe Concurrency Describe Distribution Class Design Subsystem Design Use-Case Design Reviewer Here is our workflow suggested by the Unified Process. Note ‘designer’ activities are related to architecture - but quite different from architect Important to note detailed design activities (Use Case, Subsystem, and Class Design) are tightly bound and tend to alternate between one another.

24 6 Lastly, and very importantly: Note: one of the major differences between use case analysis (what we have done) and use case design (what we are embarking upon) is scale.  Analysis classes may be quite large Lots of attributes This keeps the analysis model small.  Analysis interaction diagrams are quite easy to read and understand and most people will grasp the whole model. Model is rather small and conceptual! Model does NOT represent an implementation. (design)

Use Case Design - Guidance Use Case Design Steps:  Describe interactions between design objects  Simplify interaction diagrams using subsystems & interfaces  Will ratchet down in Subsystem Design and Class Design Let the Use Case ‘drive’ the design process  Ensure interaction diagrams do their job!  Ensure interaction diagrams model the desired behaviors (via requirements) through responsibilities (in design) 24 7

8 Use-Case Design Overview Supplementary Specifications Use-Case Design Use-Case Realization Design Subsystems and Interfaces Design Classes Use Case

24 9 Use-Case Realization – UML Notation Class Diagrams Sequence Diagrams Use Case Use-Case ModelDesign Model Use CaseUse-Case Realization Communications Diagrams Designer is responsible for the integrity of the use case realization. Must coordinate with Architect. Interaction Diagrams: Use Case Realization:

24 10 Use-Case Design Steps  Describe Interactions Between Design Objects  Involves replacing analysis classes with design elements.  Replace boundary classes (analysis) with subsystems; Such as GUI classes for boundary classes for a View  Replace external actors (e.g. external device or a system that manages a database) with an interface to the class; Will show this ahead…  Note: a number of analysis entities may prevail, although perhaps be fewer in number or adjusted. In Analysis Interaction Diagrams…  Replace applicable classes (boundary, control, …) with an associated subsystem interface  We are saying that an analysis class (in the analysis model) may often be best implemented via a subsystem in the design model. (Actually makes our job easier via abstraction)

24 11 BillingSystem // submit bill() > BillingSystem > IBillingSystem CourseCatalogSystem // get course offerings() > CourseCatalogSystem > ICourseCatalogSystem Analysis ClassesDesign Elements Ex: Incorporating Subsystem Interfaces getCourseOfferings(forSemester : Semester) : CourseOfferingList submitBill(forTuition : Double, forStudent : Student) Note: Interactions to support external system access will be more complex than can be implemented in a single class. So, we identified subsystems to encapsulate this access to external systems. So this type of e boundary class (in analysis) typically morphs into a subsystem in the Design Model. Using a subsystem as the interface to the Billing System.

24 12 Recall: We had: : Course Catalog System > : Course Catalog Actor (hence external) This actor represents the system that manages the Course Catalog, etc. Data is out ‘here.’ Our analysis class below: Sequence Diagram

24 13 Ex: Incorporating Subsystem Interfaces (before) Replace with subsystem interface : Student : RegisterForCoursesForm : RegistrationController : Schedule : Student : CourseCatalogSystem A list of the available course offerings for this semester are displayed Student wishes to create a new schedule 1. // create schedule( ) 1.2. // display course offerings( ) 1.1. // get course offerings( ) // get course offerings(forSemester) 1.3. // display blank schedule( ) 2. // select 4 primary and 2 alternate offerings( ) 2.1. // create schedule with offerings( ) // create with offerings( ) A blank schedule is displayed for the students to select offerings // add schedule(Schedule) At this point, the Submit Schedule subflow is executed We know from Architectural Design that a CourseCatalogSystem Actor has been defined to represent the external legacy Course Catalog System. So, we need to refine interaction diagram and replace the CourseCatalogSystem boundary class (from analysis) with the associated subsystem interface, ICourseCatalogSystem, here in design.

24 14 Ex: Incorporating Subsystem Interfaces (after) : Student : RegisterFor CoursesForm : Registration Controller : Schedule : Student : ICourseCatalog System A list of the available course offerings for this semester are displayed Student wishes to create a new schedule 1: // create schedule( ) 1.2: // display course offerings( ) 1.1: // get course offerings( ) 2.1.2: // add schedule(Schedule) 1.1.1: getCourseOfferings(Semester) 1.3: // display blank schedule( ) At this, point the Submit Schedule subflow is executed. 2: // select 4 primary and 2 alternate offerings( ) 2.1: // create schedule with offerings( ) 2.1.1: // create with offerings( ) A blank schedule is displayed for the students to select offerings Replaced with subsystem interface Show here how interactions are modeled between design elements where one element is a subsystem. Original use-case realization from Analysis was refined and original boundary class replaced with the associated subsystem interface, ICourseCatalogSystem Access to the Catalog system is represented via an interface to that subsystem… Now a Design element

24 15 More on interaction diagrams In Use Case Design, we do not flush out the internals of the CourseCatalogSystem subsystem. How the subsystem accesses the external system that manages the Catalog is abstracted here and represented only by an interface to the subsystem. The subsystem’s job is to connect to the external system. This part of the Use Case Design sequence diagram will become the subsystem context diagram in Subsystem Design coming up When we take on Subsystem Design we will have to design the internals of every subsystem we abstract using only its interface here.

24 16 Ex: Incorporating Subsystem Interfaces - (VOPC) ICourseCatalogSystem getCourseOfferings() initialize() (from External System Interfaces) > RegisterForCoursesForm // submit schedule() // display course offerings() // display schedule() // save schedule() // create schedule() // select 4 primary and 2 alternate offerings() // display blank schedule() (from Registration) > Student. - name - address - studentID : int // addSchedule() // getSchedule() // hasPrerequisites() // passed() (from University Artifacts) > RegistrationController // submit schedule() // save schedule() // create schedule with offerings() // getCourseOfferings() (from Registration) > 0..1 registrant 11 Schedule semester // submit() // save() // any conflicts?() // new() (from University Artifacts) > 0..* currentSchedule CourseOffering number startTime endTime days // addStudent() // removeStudent() // new() // setData() (from University Artifacts) > 0..* 0..4 primaryCourses 0..* 0..2 alternateCourses 0..* 1 Subsystem interface The above example is the VOPC after incorporating the design elements. The original CourseCatalogSystem boundary class has been replaced with the associated subsystem interface, ICourseCatalogSystem. Static part:

24 17 Use-Case Design Steps - continued  Simplify Interaction Diagrams Using Subsystems  When a use case is realized (that is, ‘design’), the flow of events is usually described in terms of executing objects; that is, as interactions between design objects.  Often useful to encapsulate a sub-flow of events within a subsystem. (below and next slide)  If done, large subsections of the interaction diagram are replaced with a single message to the subsystem.  This simplifies our first cuts at use-case design and resulting interaction diagrams.  Subsystem interaction diagrams are later developed during Subsystem Design and will illustrate the internal interactions needed to produce each of these desired behaviors.

24 18  Raises the level of abstraction Encapsulating Subsystem Interactions Interactions can be described at several levels  Lifelines in the middle represent sub-states;  Interactions in circles represent the internal interaction of subsystem members in response to the message. Subsystem interactions can / will be described in their own interaction diagrams

24 19 Encapsulate Sub-Flows in a Subsystem When a: Sub-flow occurs in multiple use-case realizations Sub-flow occurs only in one use case realization, but:  Sub-flow has reuse potential  Sub-flow is complex and easily encapsulated (abstract out the behaviors for now…)  Sub-flow is responsibility of one person/team  Sub-flow produces a well-defined result Make sure what you are abstracting is worth abstracting. There’s no free lunch!

24 20 > MySubsystem InterfaceA op1() Op1() :InterfaceA Guidelines: Encapsulating Subsystem Interactions Subsystems should be represented ONLY by their interfaces on interaction diagrams in use case design (here) Messages to subsystems are modeled as messages to the subsystem interface only.  Thus any subsystem that realizes the interface can be substituted for the interface in diagram (later).

24 21 Guidelines: Messages sent From Interfaces Messages to subsystems correspond to operations of the subsystem interface (the signatures) Interactions within subsystems will be modeled in Subsystem Design Very powerful statements here: Discuss real meanings! In many cases, the interface lifeline does not have messages going out from it, since different subsystems realizing the interface may send different messages. However, if you want to describe what messages should be sent (or are allowed to be sent) from any subsystem realizing the interface, such messages can go out from the interface lifeline.

24 22 Principle: “Design by Contract” With this approach, when describing the interactions, the focus remains concentrated on the services, NOT on how the services are implemented (realized) within design elements. This is known as “Design by Contract” and is one of the core tenets of robust software development using abstraction and encapsulation mechanisms. Describing HOW the services are implemented is the focus of Subsystem Design (for the design subsystems) and Class Design (for the design classes).

24 23 Advantages of Encapsulating Subsystem Interactions via Interfaces Use-case realizations are less cluttered – especially if the internal design of subsystem in complex. Use-case realizations can be created before the internal designs of subsystems are created (parallel development)  Ensures the use case functionality hasn’t been lost between allocation of use-case responsibility (in Use Case Analysis) and the identification of design elements (subsystems and design classes) in Architectural Design, and before Subsystem Design is performed. Use-case realizations are more generic and easy to change (subsystems can be substituted) Again, encapsulating subsystem interactions raises the level of abstraction of the use-case realization flows of events.

24 Parallel Subsystem Development IF we are developing subsystems more or less independently, first find subsystem dependencies by identifying the interfaces between them. How? Approach:  Concentrate on requirements that affect subsystem interfaces  Outline required interfaces  Show messages that are going to pass over the subsystem borders…  Draw interaction diagrams in terms of subsystem interfaces for each use case  Refine the interfaces needed to provide messages  Develop each subsystem in parallel – using the interfaces as synchronization instruments between development teams.

24 25 May decide to arrange the interaction diagrams in term of subsystems or in terms of their interfaces only. In some projects, it might be necessary to implement the classes providing the interfaces before you continue with the rest of the modeling. The detailed design of the subsystem “internals” is done during Subsystem Design. Interfaces are what ensure compatibility between the Use-Case Design and Subsystem Design. Parallel Subsystem Development