R R R CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003) Supplementary: Using and Extending UML.

Slides:



Advertisements
Similar presentations
Dillon: CSE470: Object Modeling1 Requirements Model l Focus on WHAT, not HOW l Analyst needs to understand the problem »How does software fit into overall.
Advertisements

UML an overview.
Chapter 22 Object-Oriented Systems Analysis and Design and UML Systems Analysis and Design Kendall and Kendall Fifth Edition.
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 04. Other.
Use Case Diagram © copyright 2001 SNU OOPSLA Lab..
Object-Oriented Analysis and Design
Introduction To System Analysis and Design
Use-case Modeling.
L4-1-S1 UML Overview © M.E. Fayad SJSU -- CmpE Software Architectures Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
The Unified Software Development Process - Workflows Ivar Jacobson, Grady Booch, James Rumbaugh Addison Wesley, 1999.
SE 555 Software Requirements & Specification1 Use-Case Modeling: Overview and Context.
© Betty H.C. Cheng. This presentation is available free for non-commercial use with attribution under a creative commons license. Approaching a.
Software Engineering CSE470: Requirements Analysis 1 Requirements Analysis Defining the WHAT.
R R R CSE870: Advanced Software Engineering: Extending and Using UML (Cheng) Supplementary: Using and Extending UML.
UML Sequence Diagrams Eileen Kraemer CSE 335 Michigan State University.
Use Case Analysis – continued
Introduction to Software Design Chapter 1. Chapter 1: Introduction to Software Design2 Chapter Objectives To become familiar with the software challenge.
USE Case Model.
Introduction To System Analysis and design
UML - Development Process 1 Software Development Process Using UML (2)
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.
PowerPoint Presentation for Dennis, Wixom, & Tegarden Systems Analysis and Design with UML, 4th Edition Copyright © 2012 John Wiley & Sons, Inc. All rights.
Introduction To System Analysis and Design
UML Diagrams: Class Diagrams The Static Analysis Model Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Chapter 9 요구사항 모델링: 시나리오 기반 방법론 Requirements Modeling: Scenario-Based Methods 임현승 강원대학교 Revised from the slides by Roger S. Pressman and Bruce R. Maxim.
Approaching a Problem Where do we start? How do we proceed?
Systems Analysis and Design in a Changing World, 3rd Edition
CS3773 Software Engineering Lecture 04 UML Class Diagram.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Notes of Rational Related cyt. 2 Outline 3 Capturing business requirements using use cases Practical principles  Find the right boundaries for your.
Unified Modeling Language* Keng Siau University of Nebraska-Lincoln *Adapted from “Software Architecture and the UML” by Grady Booch.
© 2005 Prentice Hall9-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
The Static Analysis Model Class Diagrams Prof. Hany H. Ammar, CSEE, WVU, and Dept. of Computer Science, Faculty of Computers and Information, Cairo University.
Design Analysis builds a logical model that delivers the functionality. Design fully specifies how this functionality will be delivered. Design looks from.
L6-S1 UML Overview 2003 SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College.
UML-1 8. Capturing Requirements and Use Case Model.
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.
TAL7011 – Lecture 4 UML for Architecture Modeling.
1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements workflow –Workers participating in the requirements workflow.
Logical view –show classes and objects Process view –models the executables Implementation view –Files, configuration and versions Deployment view –Physical.
CS 8532: Advanced Software Engineering Dr. Hisham Haddad Overview of Object-Oriented Design Highlights of OOD Concepts, Components, and Process.
Object-Oriented Modeling: Static Models. Object-Oriented Modeling Model the system as interacting objects Model the system as interacting objects Match.
Introduction to OOAD and the UML
Where do we start? How do we proceed?
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 Technical & Business Writing (ENG-715) Muhammad Bilal Bashir UIIT, Rawalpindi.
1 Unified Modeling Language, Version 2.0 Chapter 2.
Winter 2011SEG Chapter 11 Chapter 1 (Part 1) Review from previous courses Subject 1: The Software Development Process.
Chapter 3: Introducing the UML
Requirement engineering & Requirement tasks/Management. 1Prepared By:Jay A.Dave.
21/1/ Analysis - Model of real-world situation - What ? System Design - Overall architecture (sub-systems) Object Design - Refinement of Design.
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.
Object Oriented Programming and Data Abstraction Earl Huff Rowan University.
Dillon: CSE470: ANALYSIS1 Requirements l Specify functionality »model objects and resources »model behavior l Specify data interfaces »type, quantity,
UML (Unified Modeling Language)
UML Diagrams: Class Diagrams The Static Analysis Model
Roberta Roth, Alan Dennis, and Barbara Haley Wixom
Object-Oriented Analysis and Design
Systems Analysis and Design With UML 2
Unified Modeling Language
Object-Oriented Analysis
Unified Modeling Language
Analysis models and design models
Copyright 2007 Oxford Consulting, Ltd
Software Analysis.
Chapter 22 Object-Oriented Systems Analysis and Design and UML
Introduction to OOAD and the UML
UML  UML stands for Unified Modeling Language. It is a standard which is mainly used for creating object- oriented, meaningful documentation models for.
Presentation transcript:

R R R CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003) Supplementary: Using and Extending UML

R R R CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003) Extensibility Mechanisms Stereotypes Tagged Values Constraints ActionQueue > {version = 3.2} add(a: Action) remove(n: Integer) {add runs in O(1) time}

R R R CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003) Stereotypes Extends the UML vocabulary Create new building blocks derived from existing ones, –specific to problem domain –Example: Sensors for embedded systems, > thermometer temp read > Voltage meter volt read

R R R CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003) Tagged Values Extends properties of UML building block Create new information in that element’s spec Example: {version, author values for Software Class} > Voltage meter volt read {reader=J. Smith}

R R R CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003) Constraint Extends the semantics of a UML building block Add new rules or modify existing ones –Example: {ordered constraint on a add operation for a Queue} > Voltage meter volt read {reader=J. Smith} {read before thermostat check}

R R R CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003) Interface Interface: collection of operations that specify a service of a class or component –Externally visible behavior of that element –Set of operation specs (signatures) –Not a set of operation implementations

R R R CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003) Interface Example Interface specifies desired behavior of an abstraction independent of implementation Specifies contract May also create stereotype to further define behavior –No attributes –Only operations (visibility, concurrency, stereotypes, etc.) Wordsmith.dll ISpell IThesaurus IUnknown > URLStreamHandler openConnection() Parse URL() setURL() toExternalForm() Operations

R R R CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003) Dependency Relationship Definition: –some set of model elements requires presence of another set of model elements –for semantic completeness or correctness Examples: – >: between type and class – >: analysis class and design class – >: source class creates a target class instance – >: permission of one pkg to access public elements of another – >: reln between parameterized model elt with formal parameter list and that model elt bound to actual parameters. (e.g., templates in C++)

R R R CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003) Dependency Example Queue Basetype, size Queue String, 400 Integer Queue Explicit Parameterization Formal parameter list Actual parameter list

R R R CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003) Metamodels

R R R CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003) Class Diagram Metamodel

R R R CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003) Object Model Creation Tips –understand the problem –keep it simple at first, then refine later –choose class names carefully –try to have only binary relations –do not worry about multiplicities on first draft –do not feel you have to use all constructs –concentrate on WHAT –document reasons behind the model –refine until complete and correct

R R R CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003) Dynamic Model Creation Tips –only construct state diagrams for object classes with meaningful dynamic behavior –verify consistency between diagrams for shared events –use scenarios to begin the construction of diagrams –let application decide on granularity and distinguish between actions and activities –make use of entry and exit actions for multiple transitions –use nested states to improve understanding/readability –distinguish state diagrams for super and subclasses –watch for race conditions in the diagrams

R R R CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003) Approaching a Problem Where do we start? How do we proceed?

R R R CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003) Where Do We Start? Start with the requirements –Capture your goals and possible constraints –Environmental assumptions Use-case analysis to better understand your requirements –Find actors and a first round of use-cases Start conceptual modeling –Conceptual class diagram –Interaction diagrams to clarify use-cases –Activity diagrams to understand major processing Requirements Elicitation and Analysis

R R R CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003) How Do We Continue? Refine use-cases –Possibly some “real” use-cases Using interface mockups Refine (or restructure) your class diagram –Based on your hardware architecture For instance, client server Refine and expand your dynamic model –Until you are comfortable that you understand the required behavior Identify most operations and attributes High-Level Design

R R R CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003) How Do We Wrap Up? Refine the class diagram based on platform and language properties –Navigability, public, private, etc –Class libraries Identify all operations –Not the trivial get, set, etc. Write a contract for each operation Define a collection of invariants for each class Implement Detailed Design and Implementation

R R R CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003) Why is requirements analysis difficult? Communication: misunderstandings between the customer and the analyst –Analyst doesn’t understand the domain –Customer doesn’t understand alternatives and trade-offs Problem complexity –Inconsistencies in problem statement –Omissions/incompleteness in problem statement –Inappropriate detail in problem statement

R R R CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003) Why is requirements analysis difficult? Need to accommodate change –Hard to predict change –Hard to plan for change –Hard to predict the impact of change

R R R CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003) First Law of Software Engineering “ No matter where you are in the system lifecycle, the system will change, and the desire to change it will persist throughout the lifecycle.”

R R R CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003) Reasons for changing requirements Poor communication Inaccurate requirements analysis Failure to consider alternatives New users New customer goals New customer environment New technology Competition Software is seen as malleable Changes made after the requirements are approved increase cost and schedule

R R R CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003) Requirements Products Specification document –Agreement between customer and developer –Validation criteria for software Preliminary users manual Prototype –If user interaction is important –If resources are available Review by customer and developer –Iteration is almost always required

R R R CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003) Analysis: Steps to follow Obtain a problem statement Develop use cases (depict scenarios of use) Build an object model and data dictionary Develop a dynamic model –state and sequence diagrams Verify, iterate, and refine the models Produce analysis document

R R R CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003) Use Cases High-level overview of system use Identify scenarios of usage Identify actors of the system: –External entities (e.g., users, systems, etc.) Identify system activities Draw connections between actors and activities Identify dependencies between activities (i.e., extends, uses)

R R R CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003) Analysis: Object Model Organization of system into classes connected by associations –Shows the static structure –Organizes and decomposes system into more manageable subsystems –Describes real world classes and relationships

R R R CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003) Analysis: Object Model Object model precedes the dynamic model because –static structure is usually better defined –less dependent on details –more stable as the system evolves

R R R CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003) Analysis: Object Model Information comes from –The problem statement and use cases –Expert knowledge of the application domain Interviews with customer Consultation with experts Outside research performed by analyst –General knowledge of the real world

R R R CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003) Object Model: Steps to follow Identify classes and associations –nouns and verbs in a problem description Create data dictionary entry for each Add attributes Combine and organize classes using inheritance

R R R CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003) Analysis: Dynamic model Shows the time dependent behavior of the system and the objects in it Expressed in terms of –states of objects and activities in states – events and actions State diagram summarizes permissible event sequences for objects with important dynamic behavior

R R R CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003) Dynamic Model: Steps to follow Use cases provide scenarios of typical interaction sequences Identify events between objects (Sequence Diagram) Prepare an event trace for each scenario Build state diagrams Match events between objects to verify consistency

R R R CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003) Analysis: Iteration Analysis model will require multiple passes to complete Look for inconsistencies and revise Look for omissions/vagueness and revise Validate the final model with the customer