Finding Analysis Classes Written by Zvika Gutterman Adam Carmi.

Slides:



Advertisements
Similar presentations
Chapters 7 & 9 System Scope
Advertisements

Agenda What is a Use Case? Benefits of the Use Cases Use Cases vs. Requirements document Developing the Use Case model System Actor Use Case Use Case.
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1/18 Use Case Analysis – continued Control Classes.
UML Class Diagram. UML Class Diagrams2 Agenda What is a Class Diagram? Essential Elements of a UML Class Diagram Tips.
UML Class Diagram and Packages Written by Zvika Gutterman Adam Carmi.
UML Class Diagram. UML Class Diagrams2 Agenda What is a Class Diagram? Essential Elements of a UML Class Diagram Tips.
Use Case Diagram © copyright 2001 SNU OOPSLA Lab..
Department of Computing
2-1 © Prentice Hall, 2007 Chapter 2: Introduction to Object Orientation Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph.
Use-case Modeling.
Software Requirements
Copyright ©2004 Cezary Z Janikow 1 Domain Model n Visualization of entities and relationships n In UP presented as Class Diagrams – Classes, Relationships,
UML Class Diagram and Packages Written by Zvika Gutterman Adam Carmi.
UML Class Diagram and Packages Written by Zvika Gutterman Adam Carmi.
Use Case Modeling Written by: Zvika Gutterman Adam Carmi.
Irwin/McGraw-Hill Copyright © 2004 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS6th Edition.
Use Case Modeling Written by: Zvika Gutterman Adam Carmi.
Written by: Zvika Gutterman Adam Carmi
1 Lecture 2: Elaboration Tasks and Domain Modeling.
Finding Analysis Classes Written by Zvika Gutterman Adam Carmi.
Requirements Analysis 2 What objects collaborate to achieve the goal of a use case?
Data Modeling Entity - Relationship Models. Models Used to represent unstructured problems A model is a representation of reality Logical models  show.
Copyright W. Howden1 Lecture 2: Elaboration Tasks and Domain Modeling.
Use Case Modeling Written by: Zvika Gutterman Adam Carmi.
Use Case Analysis – continued
Domain Modeling (with Objects). Motivation Programming classes teach – What an object is – How to create objects What is missing – Finding/determining.
Chapter 7 Structuring System Process Requirements
Software Design Description (SDD) Diagram Samples
The chapter will address the following questions:
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1/29 Object Oriented Analysis and Design Using.
USE Case Model.
The Software Development Life Cycle: An Overview
INTROSE Introduction to Software Engineering Raymund Sison, PhD College of Computer Studies De La Salle University Analysis Modeling.
Chapter 5 Analysis Model. Analysis model (AM) The first step in describing how the system will implement the requirements specification The first step.
ANALYSIS REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Data Flow Diagram A method used to analyze a system in a structured way Used during: Analysis stage: to describe the current system Design stage: to describe.
10/12/ Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 1. Interviews & questionnaires.
Practical Object-Oriented Design with UML 2e Slide 1/1 ©The McGraw-Hill Companies, 2004 PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e Chapter 4: Restaurant.
CS3773 Software Engineering Lecture 04 UML Class Diagram.
NI ©UNITEN 2000/01 1 Faculty of Applied Engineering and Urban Planning Software Engineering Department Class Diagram Faculty of Information system Technology.
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.
Actors and Use Case Diagrams Month Day, Year. Agenda Training Plan Overview Review Detailing Requirements with Requisite Pro Concepts Setting Up XDE Integration.
1 IBM Software Group ® Mastering Object-Oriented Analysis and Design with UML 2.0 Module 6: Use-Case Analysis.
UML Class Diagram Trisha Cummings. What we will be covering What is a Class Diagram? Essential Elements of a UML Class Diagram UML Packages Logical Distribution.
Chapter 1 Applying UML and Patterns. The Need for Software Blueprints Knowing an object-oriented language and having access to a library is necessary.
What is a Structural Model?
IFS310: Module 6 3/1/2007 Data Modeling and Entity-Relationship Diagrams.
Object-Oriented Modeling: Static Models. Object-Oriented Modeling Model the system as interacting objects Model the system as interacting objects Match.
Design CIS 4800 Kannan Mohan Department of CIS Zicklin School of Business, Baruch College Copyright © 2009 John Wiley & Sons, Inc. Copyright © 2008 Course.
Use Case Model Use case diagram. Relevant Requirements Artifacts Use-Case Model Supplementary Specification Use-Case Specifications... Glossary Actors.
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1 Object Oriented Analysis and Design Using.
Use Case Textual Analysis
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
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.
Software Requirements
UML - Development Process 1 Software Development Process Using UML.
6.1 © 2007 by Prentice Hall Chapter 6 (Laudon & Laudon) Foundations of Business Intelligence: Databases and Information Management.
OOD OO Design. OOD-2 OO Development Requirements Use case analysis OO Analysis –Models from the domain and application OO Design –Mapping of model.
Gerhard Dueck -- CS3013Analysis 1. Gerhard Dueck -- CS3013Analysis 2 Why analysis?  Yield a more precise specification of the requirements.  Introduce.
Chapter 7 Part II Structuring System Process Requirements MIS 215 System Analysis and Design.
High Level Design Use Case Textual Analysis SE-2030 Dr. Mark L. Hornick 1.
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1 Use Case Analysis – Part 4 Analysis Mechanisms.
Conceptual Modeling.
Use Case Model Use case diagram.
Today’s Objectives Define the Problem Domain
Use Case Modeling.
UML Class Diagram.
Use Case Analysis – continued
Presentation transcript:

Finding Analysis Classes Written by Zvika Gutterman Adam Carmi

Agenda Objective What are Analysis Classes? Types of Analysis Classes –Boundary classes –Entity classes –Control classes Finding Analysis Classes Example: TVRS Analysis Classes

Objective Identify a candidate set of (analysis) classes which are capable of performing the behavior described in the use cases. –The complete behavior of a use case has to be distributed to analysis classes.

What are analysis classes? The technique for finding analysis classes uses three different perspectives of the system: The boundary between the system and its actors. The information the system uses. The control logic of the system.

What are analysis classes? (cont.) > = = = A stereotype defines a new model element in terms of another model element.

Types of Analysis Classes > Actor1Actor2 Model interaction between the system and its environment Store and manage information in the system Coordinates the use case behavior

Boundary Classes Models the interaction between the system’s surroundings and its inner workings –User interface classes Concentrate on what information is presented to the user. Don’t concentrate on user interface details. Example: ViolationsDialog –System / Device interface classes Concentrate on what protocols must be defined. Don’t concentrate on how the protocols are implemented. Example: OffendersDBProxy

Boundary Classes (cont.) Boundary classes are environment dependent: –UI dependent –Communication protocol dependent.

Entity Classes Models the key concepts of the system. Usually models information that is persistent. Contains the logic that solves the system problem. Is environment independent. Can be used in multiple use cases.

Control Classes Controls and coordinates the behavior of a use case. Delegates the work of the use case to classes. –A control class should tell other classes to do something and should never do anything except for directing. Control classes decouple boundary and entity classes. Often, there is one control class per use case.

Control Classes (cont.) Use case and environment dependent Example: –ViolationsController

Finding Analysis Classes 1.For each use case: a.Supplement the use case description. b.Identify Boundary, Entity and Control classes. c.For each class identified i.Find attributes ii.Find relationships 2.Validate model, repeat process if necessary.

Supplement Use Case description The description of each use case is not always sufficient for finding analysis classes and their objects. Capture additional information needed in order to understand the required internal behavior of the system that may be missing from the use-case description written for the costumer. Focus on enhancing current flow with internal details that realize the external behavior.

Identifying Classes Classes may be hidden in: –Requirements document –Use case model –Stakeholder’s Request –Problem domain –Any project documentation Boundary classes –There should be at least one boundary class for each actor / use-case pair.

Identifying Classes (Cont.) Control classes –Often, there is one control class per use case. –If two control classes are similar, their corresponding use cases may need to be merged. Example: “manage traffic report” may replace “edit/add/remove traffic report” use cases.

Identifying Classes (cont.) Entity Classes –Identified by examining the nouns and noun phrases in problem description, requirements document, use cases and other documentation. –Nouns found may be: Objects Description of an object’s state (attributes) Actors None of the above

Identifying Classes (Cont.) –Some of the potential classes can be eliminated: Duplicate classes –Differ only in name: “System”, “TVRS”... Irrelevant classes –Classes that have nothing to do with the system (solution): “police headquarters”... Attributes / Operations –Some nouns are likely to be modeled as attributes or operations rather than classes: “ID”, “name”, “Report Lookup”...

Identifying Classes (Cont.) Roles –Some nouns are roles of objects involved in associations rather than classes: “Teaching Assistant” and “Student” may be different roles of a “Person” class. Abstract nouns –“Identify ideas or quantities that have no physical existence” –Rarely end up corresponding to classes, but rather as attributes: “Request”, “Opinion”

Finding Class Attributes Properties or characteristics of identified classes. Information retained by identified classes. Nouns that did not become classes. –Information whose value is important for the solution. –Information that is uniquely owned by an object.

Finding Relationships Associations often correspond to verbs or verb phrases. –Physical locations: next to, above, inside... –Direct actions: drives, creates, manages... –Communication: talks to, listens, notifies... –Ownership: has, part of, belongs to, contained... –Others: works for, married to, studies at... Eliminate associations that don’t relate to the problem / solution More association may be discovered using interaction diagrams (introduced later...).

Example: TVRS Analysis Classes Partial noun list from TVRS requirements and use cases (Entity classes candidates): Traffic report Supervisor Report lookup Confirmation TVRS Offender Details Form Traffic report addition System Offender Policeman Vehicle number License number Fault Traffic policeman Commander Violation ID Password Police headquarters Shutdown Date Speed Traffic Violation Clerk

Example: TVRS Analysis Classes (cont.) Eliminate duplicate classes: Traffic report Supervisor Report lookup Confirmation TVRS Offender Details Form Traffic report addition System Offender Policeman Vehicle number License number Fault Traffic policeman Commander Violation ID Password Police headquarters Shutdown Date Speed Traffic Violation Clerk Clerk and Supervisor are replaced by User

Example: TVRS Analysis Classes (cont.) Eliminate irrelevant classes Traffic report User Report lookup Confirmation TVRS Offender Details Form Traffic report addition Offender Policeman Vehicle number License number Traffic policeman Commander Violation ID Password Police headquarters Shutdown Date Speed

Example: TVRS Analysis Classes (cont.) Eliminate attributes / operations Traffic report User Report lookup Confirmation TVRS Offender Details Form Traffic report addition Offender Policeman Vehicle number License number Traffic policeman Commander Violation ID Password Shutdown Date Speed

Example: TVRS Analysis Classes (cont.) Eliminate abstract nouns Traffic report User Confirmation TVRS Offender Details Form Offender Policeman Traffic policeman Violation Date

Example: TVRS Analysis Classes (cont.) Final class list (partial) Traffic report User TVRS Offender Details Form Offender Policeman TrafficPoliceman Violation Date The remaining list will often contain classes that are not entity classes, such as “Offender Details Form”. Boundary and control classes are easier to find by analyzing use cases directly.

Example: TVRS Analysis Classes (cont.) Boundary Classes –ReportDetailsForm –PolicemanDetailsForm –LookupReportForm –ConfirmationDialog –OffendersDBProxy –PolicemanDBProxy –... A Database proxy, provides a friendly interface and encapsulated the details of communication with the actual database.

Example: TVRS Analysis Classes (cont.) Control Classes –AddReportController –RemoveReportController –LookupReportController –EditReportController –AuthenticationController –...

Example: TVRS Analysis Classes (cont.)