Object Oriented Analysis Unified Modeling Language By Mary Biddle.

Slides:



Advertisements
Similar presentations
Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Advertisements

Component Oriented Programming 1 Chapter 2 Theory of Components.
Use Case Modeling SJTU. Unified Modeling Language (UML) l Standardized notation for object-oriented development l Needs to be used with an analysis and.
Unified Modeling Language
1 SWE Introduction to Software Engineering Lecture 16 – System Modeling An Example.
2008/03/25 Unified Modeling Lanauage 1 Introduction to Unified Modeling Language (UML) – Part One Ku-Yaw Chang Assistant Professor.
2-1 © Prentice Hall, 2007 Chapter 2: Introduction to Object Orientation Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph.
Lecture 11: Chapter 22 Topics –Object Oriented Modeling –UML –Use case.
Documenting Requirements using Use Case Diagrams
1 SWE Introduction to Software Engineering Lecture 15 – System Modeling Using UML.
Software Engineering CSE470: Requirements Analysis 1 Requirements Analysis Defining the WHAT.
UML Sequence Diagrams Eileen Kraemer CSE 335 Michigan State University.
Object-Oriented Analysis
Marcelo Santos – OOAD-CDT309, Spring 2008, IDE-MdH 1 Object-Oriented Analysis and Design - CDT309 Period 4, Spring 2008 More on use cases System sequence.
Object Oriented Concepts. Movement toward Objects Instead of data-oriented or process-oriented Analysis, many firms are now moving to object-oriented.
Case Study: Safe Home Security System
1 CMPT 275 Software Engineering Requirements Analysis Phase Overview of Requirements Analysis Activity System Context Diagrams.
Chapter 7: The Object-Oriented Approach to Requirements
Building The Analysis Model. Object-Oriented Analysis The object oriented analysis define all classes, the relationships and behavior associated with.
2005/05/25 Unified Modeling Lanauage 1 Introduction to Unified Modeling Language (UML) – Part One Ku-Yaw Chang Assistant Professor.
Analysis Modeling (cont’d) CpSc 372: Introduction to Software Engineering Jason O. Hallstrom Authorship Disclaimer. These slides.
Object Oriented Analysis By: Don Villanueva CS 524 Software Engineering I Fall I 2007 – Sheldon X. Liang, Ph. D.
Chapter 5 – System Modeling
Software Engineering CS B Prof. George Heineman.
ANALYSIS REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
The Unified Modeling Language Part I Omar Meqdadi SE 2730 Lecture 6 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
CS 360 Lecture 6.  A model is a simplification of reality  We build models to better understand the system being developed.  We build models of complex.
Unified Modeling Language, Version 2.0
Requirement Engineering. Review of Last Lecture Problems with requirement Requirement Engineering –Inception (Set of Questions) –Elicitation (Collaborative.
Software Engineering Object Oriented Analysis. Objectives 1.To outline an Object Oriented Analysis process and modelling language 2.To study the process.
Systems Analysis and Design in a Changing World, 3rd Edition
CS /31 Illinois Institute of Technology CS487 Software Engineering OOA with UML David Lash.
Fall 2010 CS4310 Requirements Engineering A Brief Review of UML & OO Dr. Guoqiang Hu Department of Computer Science UTEP 1.
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 1: Introduction to Use-Case Modeling.
1 Structuring Systems Requirements Use Case Description and Diagrams.
Use Cases, Part I Understanding the Business Dynamics  Understand the business workflow  Identify system support points the system 'use cases'
1 System Analysis and Design Using UML INSTRUCTOR: Jesmin Akhter Lecturer, IIT, JU.
UML-1 4. Architecture. UML-2 Artifact: Analysis Class Abstraction of one or several classes or subsystems –Focuses on handling functional requirements.
Kal Bugrara, Ph.DSoftware Engineering Northeastern University Fundamentals Of Software Engineering Lecture V.
Logical view –show classes and objects Process view –models the executables Implementation view –Files, configuration and versions Deployment view –Physical.
What is Object-Oriented?  Organization of software as a collection of discreet objects that incorporate both data structure and behavior.
Introduction to OOAD and the UML
Domain Classes – Part 1.  Analyze Requirements as per Use Case Model  Domain Model (Conceptual Class Diagram)  Interaction (Sequence) Diagrams  System.
Dynamic Models Sequence Diagrams Collaboration Diagrams Activity Diagrams.
Systems Analysis and Design in a Changing World, Fourth Edition
Lecture 9-1 : Intro. to UML (Unified Modeling Language)
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Yazd University, Electrical and Computer Engineering Department Course Title: Advanced Software Engineering By: Mohammad Ali Zare Chahooki The Rational.
Analysis Yaodong Bi. Introduction to Analysis Purposes of Analysis – Resolve issues related to interference, concurrency, and conflicts among use cases.
Spring 2007 Week 10: Object Modeling (1)Use Case Model IFS410: Advanced Analysis and Design.
UML - Development Process 1 Software Development Process Using UML.
21/1/ Analysis - Model of real-world situation - What ? System Design - Overall architecture (sub-systems) Object Design - Refinement of Design.
Object and Class Structuring Chapter 9 Part of Analysis Modeling Designing Concurrent, Distributed, and Real-Time Applications with UML Hassan Gomaa (2001)
Gerhard Dueck -- CS3013Analysis 1. Gerhard Dueck -- CS3013Analysis 2 Why analysis?  Yield a more precise specification of the requirements.  Introduce.
ISMT221 Information Systems Analysis and Design Use case diagram Lab 4 Tony Tam.
7 Systems Analysis – ITEC 3155 The Object Oriented Approach – Use Cases.
Object Oriented Analysis & Design By Rashid Mahmood.
TA: Shreya Rawal.  A use case is a description of a system’s behavior as it responds to a request that originates from outside of that system (Usually.
Systems Analysis and Design in a Changing World, Fourth Edition
Chapter 8 Analysis Engineering
The Movement To Objects
Software Architecture & Design Pattern
Unified Modeling Language
Software Design Lecture : 15.
Copyright 2007 Oxford Consulting, Ltd
Software Analysis.
Chapter 4 System Modeling.
Week 8 Lecture 1: Identifying Actors and Activities
Introduction to OOAD and the UML
Software Development Process Using UML Recap
Presentation transcript:

Object Oriented Analysis Unified Modeling Language By Mary Biddle

Use Cases Use Case – a behaviorally related sequence of transactions that make up one standard use of the system being modeled. Use Cases are generated from requirements specifications and from interviews with users/clients. Why Use Cases? Customers can describe what they want the system to do better than the entities within the system.

Actors User cases are stimulated by actors. Actors are users outside the current system – Actors may be users that play a particular role – Actors may be other systems or devices that either stimulate the system or receive output from the system Use Cases describe the users view of the system.

SafeHome Use Case Activate Security HomeownerMotion Detector Intruder Detected Siren Activate Siren Notify Police Police Deactivate Security Deactivate Siren

Security Control Alarm Create Packages (Subsystems) Activate Security Motion Detector Intruder Detected Siren Activate Siren Notify Police Police Deactivate Security Deactivate Siren Sensors Homeowner

Packages Motion Detector Intruder Detected Sensors Door Open Detector Window Open Detector Pet Detected

Packages Security Control Alarm Activate Security Motion Detector Siren Police Deactivate Security Sensors

SafeHome State Security Off Alarm Security On Activate Security Intruder Detected Deactivate Security

Encapsulation Encapsulation – creating a high level of abstraction while hiding the detailed implementation Information Hiding – hide the implementation so when requirements change the impact to the design is minimized. Using these concepts when creating the objects will increase reuse and minimize the impact of change.

Key Classes from the Use Case Homeowner Password Activate_Security Deactivate_Security Motion Detector Movement_Detected Siren Activate_Siren Deactivate_Siren Police Notify

Key Classes after Analysis Security_Monitor State Activate_Security Deactivate_Security Fire Department Notify Sensor State Type Position Activated Police Notify Siren Activate_Siren Deactivate_Siren n 1..n

Define the Interfaces for the most dynamic areas Motion Detector Sensor State Type Position Activated Fire DetectorDoor Detector

Scenario Diagram Security_MonitorSensor Activate_Security Activated True GetType Fire Alarm Fire Department Notify Siren Activate Deactivate_Security Deactivate

Documentation Each Use Case will have a description. – The description will be using terms from the user’s/client’s language. Each State Diagram will have a description Each Class will have a description. – Each attribute will have a description. – Each function will have a description. Each Scenario Diagram will have a description.