CSE3308/CSC3080 - Software Engineering: Analysis and DesignLecture 4B.1 Software Engineering: Analysis and Design - CSE3308 Object-Oriented Analysis 2.

Slides:



Advertisements
Similar presentations
Object-Oriented Software Engineering Visual OO Analysis and Design
Advertisements

Activity Diagrams in UML. Definition Activity diagrams represent the dynamics of the system. They are flow charts that are used to show the workflow of.
System Sequence Diagrams
Karolina Muszyńska Based on:
9/10/2004Use Case Workshop 1 CSC480 Software Engineering Workshop 1 Requirements Modeling.
Object-Oriented Analysis and Design
Jan 16, Ron McFadyen1 Ch 9. Use-case model: drawing System Sequence Diagrams Iteration 1: a simple cash-only success scenario of Process Sale.
Introduction To System Analysis and Design
January Ron McFadyen1 Ch 9. Use-case model: drawing System Sequence Diagrams Elaboration Iteration 1: a simple cash-only success scenario of.
Solving the Problem Analysis & Design.
6/8/991 Analysis Tuesday 09/14/99 Revised: September 11, 2000 (APM)
Software Engineering CSE470: Requirements Analysis 1 Requirements Analysis Defining the WHAT.
Requirements Analysis 2 What objects collaborate to achieve the goal of a use case?
© Copyright Eliyahu Brutman Programming Techniques Course.
CSE Software Engineering: Analysis and Design, 2004Lecture 6A.1 Software Engineering: Analysis and Design - CSE3308 Object-Oriented Analysis 2 CSE3308/DMS/2004/18.
Introductory case study. 2 The problem The most difficult part of any design project is understanding the task you are attempting You have been contacted.
SE-565 Software System Requirements More UML Diagrams.
CSE3308/CSC Software Engineering: Analysis and DesignLecture 13.1 Software Engineering: Analysis and Design - CSE3308 Exam Revision CSE3308/CSC3080/DMS/2000/32.
Sharif University of Technology Session # 7.  Contents  Systems Analysis and Design  Planning the approach  Asking questions and collecting data 
An Introduction to Rational Rose Real-Time
Software Engineering Case Study Slide 1 Introductory case study.
Unified Modeling Language
Object-Oriented Analysis and Design
TK2023 Object-Oriented Software Engineering CHAPTER 6 SYSTEM SEQUENCE DIAGRAMS.
Chapter 7: The Object-Oriented Approach to Requirements
Object-Oriented Design. From Analysis to Design Analysis Artifacts –Essential use cases What are the problem domain processes? –Conceptual Model What.
Use Case modelling 1. Objectives  Document user requirements with a model  Describe the purpose of an actor and a use case  Construct a use case model.
Interaction Modeling. Overview The class model describes the objects in a system and their relationships, the state model describes the life cycles of.
Object Oriented Analysis and Design System Events & Contracts.
1 Object-Oriented Analysis Use Case Driven. 2 The outline method for OOA 1.Identify object classes within the problem domain 2.Define the behaviour of.
Software Architecture in Practice Architectural description (The reduced version)
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 20. Review Software Requirements Requirements Engineering Process.
USE CASE Bayu Adhi Tama, MTI Faculty of Computer Science, University of Sriwijaya Slides are adapted from Petrus Mursanto
Requirements Analysis Visual Modeling] Lab 02 Visual Modeling (from Visual Modeling with Rational Rose and UML) A way of thinking about problems using.
Behavioral diagrams Lecture p4 T120B pavasario sem.
Approaching a Problem Where do we start? How do we proceed?
Review ♦ System sequence diagram ♦ Domain model
1 Devon M. Simmonds University of North Carolina, Wilmington CSC450 Software Engineering WorkFlow Modeling with Activity Diagrams.
Object-Oriented Analysis and Design Fall 2009.
Software Engineering Prof. Ing. Ivo Vondrak, CSc. Dept. of Computer Science Technical University of Ostrava
Chapter 9 Applying UML and Patterns -Craig Larman
7 Systems Analysis and Design in a Changing World, Fifth Edition.
1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements workflow –Workers participating in the requirements workflow.
1 System Analysis and Design Using UML INSTRUCTOR: Jesmin Akhter Lecturer, IIT, JU.
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.
1 The Unified Modeling Language. 2 The Unified Modeling Language (UML) is a standard language for writing software blueprints. The UML may be used to.
Business Analysis with For PG MDI, Gurgaon Kamna Malik, Ph.D.
Design Model Lecture p6 T120B pavasario sem.
Systems Analysis and Design in a Changing World, Fourth Edition
Georgia Institute of Technology Workshop for CS-AP Teachers Chapter 4 Object-Oriented Design.
PRESENTATION ON USE CASE. Use Case Modeling Use case diagrams describe what a system does from the standpoint of an external observer. The emphasis is.
22 August, 2007Information System Design IT60105, Autumn 2007 Information System Design IT60105 Lecture 8 Use Case Diagrams.
OO DomainModeling With UML Class Diagrams and CRC Cards Chapter 6 Princess Nourah bint Abdulrahman University College of Computer and Information Sciences.
1 BTS330 Visual Modeling. What is Visual Modeling? 2 Copyright © 1997 by Rational Software Corporation Computer System Business Process Order Item Ship.
High Level Design Use Case Textual Analysis SE-2030 Dr. Mark L. Hornick 1.
1 More About UML Todd Bacastow Penn State University Geospatial System Analysis & Design.
1 7 Systems Analysis and Design in a Changing World, 2 nd Edition, Satzinger, Jackson, & Burd Chapter 7 The Object-Oriented Approach to Requirements.
Object Oriented Analysis & Design By Rashid Mahmood.
Requirements capture: Using UML Use Cases David Millard and Yvonne Howard {dem,
1 Object Oriented Analysis and Design System Events & Contracts.
Elaboration popo.
Course Outcomes of Object Oriented Modeling Design (17630,C604)
Unified Modeling Language
UML Use Case Diagrams.
OO Domain Modeling With UML Class Diagrams and CRC Cards
OO Domain Modeling With UML Class Diagrams and CRC Cards
CHAPTER 2 Object-Oriented Modeling Using UML (Continued)
Object-Oriented Software Engineering
Presentation transcript:

CSE3308/CSC Software Engineering: Analysis and DesignLecture 4B.1 Software Engineering: Analysis and Design - CSE3308 Object-Oriented Analysis 2 CSE3308/CSC3080/DMS/1999/10 Monash University School of Computer Science and Software Engineering

CSE3308/CSC Software Engineering: Analysis and DesignLecture 4B.2 Lecture Outline u Linking Use Cases and Class Diagrams u Interaction Diagrams v Sequence Diagrams v Collaboration Diagrams u Package Diagrams u State Diagrams u Activity Diagrams u A criticism of Use Cases

CSE3308/CSC Software Engineering: Analysis and DesignLecture 4B.3 Linking Use Cases and Class Diagrams u Use Cases are a key tool in determining the concepts/classes in a system u One of the earliest methods of finding the classes was Noun Identification u Noun identification is both simple and deceptive v Simple to apply to requirements v Deceptive because natural language is ambiguous u Use cases (especially expanded use cases) provide a more focused view of the requirements and therefore can act as a very good source of inspiration

CSE3308/CSC Software Engineering: Analysis and DesignLecture 4B.4 Example u Identifies both concepts and attributes. u Different nouns can mean the same thing u Often a question of experience Actor Action System Response 1. This use case begins when a Customer arrives at a checkout with items to purchase. 2. The Cashier records the Universal Product Code (UPC) from each item. If there is more than one of the same item, the Cashier can enter the quantity as well. 3. Determines the item price and adds the item information to the running sales transaction. The description and price of the current item are displayed.

CSE3308/CSC Software Engineering: Analysis and DesignLecture 4B.5 Rejecting Classes u We will come up with many possible classes, some of which we will not need u Competing priorities: vSimplest set of classes to satisfy current needs vSet of classes which will easily accommodate future needs u Need to apply criteria to possible classes

CSE3308/CSC Software Engineering: Analysis and DesignLecture 4B.6 Rejection criteria u Redundant classes ve.g. User and Customer of an ATM vretain the more descriptive name u Irrelevant classes vcontext dependent ve.g. Customer complaint is outside the scope of the ATM example u Vague classes vA class should be specific ve.g. ATM Death is not clearly defined in our material u Attributes »e.g. name, age, weight, address are not usually classes

CSE3308/CSC Software Engineering: Analysis and DesignLecture 4B.7 Rejection criteria (2) u Functions va behaviour of a class rather than a class in itself ve.g. in a car system, acceleration is a function not a class u Roles vThe name of a class should reflect its intrinsic nature and not a role it plays in an association vCustomer confused with Car Owner, Car Driver and Car Renter u Implementation constructs vclasses which are extraneous to the real world ve.g. CPU, subroutine, array, linked list etc.

CSE3308/CSC Software Engineering: Analysis and DesignLecture 4B.8 Interaction Diagrams u Models which show how groups of objects collaborate in some behaviour u Typically we describe how the behaviour of a single use case is implemented by a group of objects and the messages they pass between them u Two types of Interaction diagrams v Sequence v Collaboration u Both are useful, choice is a matter of personal/organisational preference

CSE3308/CSC Software Engineering: Analysis and DesignLecture 4B.9 Filling an Order A real use case Name:Filling an Order Actors:Order Clerk Purpose: To fill an order for a customer Overview: Type: Primary and real Actor Action System Response 1. An order clerk enters an order in the entry window. 2. The Order Entry Window sends a prepare message to an Order. 3. The order then sends “prepare” to each Order Line on the Order. 4. Each Order Line checks the given Stock Item 5. Order Line removes the appropriate quantity of Stock Item from stock Typical Course of Events Alternative Course: Quantity of Stock Item below reorder level and that Stock Item requests a new delivery

CSE3308/CSC Software Engineering: Analysis and DesignLecture 4B.10 Sequence Diagram

CSE3308/CSC Software Engineering: Analysis and DesignLecture 4B.11 Collaboration Diagram

CSE3308/CSC Software Engineering: Analysis and DesignLecture 4B.12 Comparing Sequence and Collaboration Diagrams u Sequence diagrams emphasise the sequences of events well u Collaboration diagrams show the relationships between the classes well u Keep both types of diagrams simple u They are not particularly good at defining behaviour precisely

CSE3308/CSC Software Engineering: Analysis and DesignLecture 4B.13 Package Diagrams u Method to break down a large system into smaller systems u Basically lets us group classes into higher- level units u Group classes based upon dependencies u Dependency means a change in one group will cause a change in another group u Packages give us a way of depicting dependencies u Reducing dependencies is the key to building large systems u Can be implemented in Java directly (Packages)

CSE3308/CSC Software Engineering: Analysis and DesignLecture 4B.14 A Package Diagram Order Capture UI AWT Mailing List UI Mailing List Application Customers Orders Order Capture Application dependency package

CSE3308/CSC Software Engineering: Analysis and DesignLecture 4B.15 Another package diagram Order Capture UI AWT Mailing List UI Mailing List Application C ustomers Orders Order Capture Application Domain Quantity Money Date Range Common {global} Database Interface {abstract} Oracle Interface Sybase Interface

CSE3308/CSC Software Engineering: Analysis and DesignLecture 4B.16 Package Diagrams (2) u You need to create a package diagram, if your class diagram is larger than a sheet of A4 paper u Dependencies are not transitive, they go one step only u You should aim to break cycles in the relationships between packages where possible (often difficult within the domain) u Are useful for testing, can do unit testing on a per package basis rather than per class

CSE3308/CSC Software Engineering: Analysis and DesignLecture 4B.17 State Diagrams u Very similar to those in Structured Analysis u Describe the lifecycle of an object v All the possible states of an object v How the object’s state changes as a result of events that reach the object u Good at describing the behaviour of an object across several use cases u Not good at describing behaviour where several objects are interacting u Use state diagrams only for classes that exhibit interesting behaviour u If too much concurrent behaviour in an object’s state diagram, is probably more than one object

CSE3308/CSC Software Engineering: Analysis and DesignLecture 4B.18 A Basic State Diagram for an Order Item Received [all items available] Waiting Delivered Cancelled Checking Dispatching cancelled [all items checked && all items available] [all items checked && some items not in stock] Item received [some items not in stock] cancelled do/initiate delivery do/check item start self-transition State transition /get first item activity guard condition [not all items checked] / get next item action event

CSE3308/CSC Software Engineering: Analysis and DesignLecture 4B.19 Superstates Item Received [all items available] Waiting DeliveredCancelled Checking Dispatching [all items checked && all items available] [all items checked && some items not in stock] Item received [some items not in stock] cancelled do/initiate delivery do/check item get next item [not all items checked] /get first item Active

CSE3308/CSC Software Engineering: Analysis and DesignLecture 4B.20 Concurrent States Checking Dispatching Waiting AuthorisedAuthorising Rejected Delivered Cancelled

CSE3308/CSC Software Engineering: Analysis and DesignLecture 4B.21 Activity Diagrams u In a conceptual diagram, an activity is some task to be done u In a specification/implementation diagram, an activity is a method on a class u Each activity can be followed by another activity u Activities can span multiple use cases u Show the whole picture of behaviour just as a class diagram shows the whole picture of the static relationships

CSE3308/CSC Software Engineering: Analysis and DesignLecture 4B.22 An Activity Diagram

CSE3308/CSC Software Engineering: Analysis and DesignLecture 4B.23 Another Activity Diagram

CSE3308/CSC Software Engineering: Analysis and DesignLecture 4B.24 Joining Activity Diagrams

CSE3308/CSC Software Engineering: Analysis and DesignLecture 4B.25 Activity Diagrams (2) u Strength is their support for parallel behaviour u Ideal for describing workflow modelling and multi-threaded programming u Disadvantage is that the link between activities and objects is not very clear u Either use swimlanes or specifically indicate the object on the diagram u Not used for looking at how objects collaborate or how an object behaves over its lifetime

CSE3308/CSC Software Engineering: Analysis and DesignLecture 4B.26 A criticism of Use Cases u Meyer (1997) criticises use cases as a method for OO Analysis and Design especially as a tool for finding classes u Use cases emphasise ordering and thus harm the system’s reuseability and robustness u Use cases emphasise a current view of the system and reduce the possibility of new and better ways of doing things u Use cases favor a a functional approach based on processes, the reverse of OO’s concentration on data abstraction