Supplementary using and extending uml
Download
1 / 31

Supplementary: Using and Extending UML - PowerPoint PPT Presentation


  • 60 Views
  • Uploaded on

Supplementary: Using and Extending UML. Extensibility Mechanisms. Stereotypes Tagged Values Constraints. <<container>>. ActionQueue. {version = 3.2}. {add runs in O(1) time}. add(a: Action) remove(n: Integer). <<sensor>>. <<sensor>>. thermometer. Voltage meter. temp. volt. read.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Supplementary: Using and Extending UML' - erelah


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Supplementary using and extending uml

Supplementary:Using and Extending UML

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


Extensibility mechanisms
Extensibility Mechanisms

  • Stereotypes

  • Tagged Values

  • Constraints

<<container>>

ActionQueue

{version = 3.2}

{add runs in O(1) time}

add(a: Action)

remove(n: Integer)

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


Stereotypes

<<sensor>>

<<sensor>>

thermometer

Voltage meter

temp

volt

read

read

Stereotypes

  • Extends the UML vocabulary

  • Create new building blocks derived from existing ones,

    • specific to problem domain

    • Example: Sensors for embedded systems,

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


Tagged values
Tagged Values

  • Extends properties of UML building block

  • Create new information in that element’s spec

  • Example: {version, author values for Software Class}

<<sensor>>

Voltage meter

{reader=J. Smith}

volt

read

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


Constraint
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}

<<sensor>>

Voltage meter

{reader=J. Smith}

volt

{read before thermostat check}

read

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


Interface
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

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


Interface example

Wordsmith.dll

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.)

ISpell

IThesaurus

IUnknown

<<interface>>

URLStreamHandler

openConnection()

Parse URL()

setURL()

toExternalForm()

Operations

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


Dependency relationship
Dependency Relationship

  • Definition:

    • some set of model elements requires presence of another set of model elements

    • for semantic completeness or correctness

  • Examples:

    • <<realize>>: between type and class

    • <<trace>>: analysis class and design class

    • <<create>>: source class creates a target class instance

    • <<access>>: permission of one pkg to access public elements of another

    • <<bind>>: reln between parameterized model elt with formal parameter list and that model elt bound to actual parameters. (e.g., templates in C++)

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


Dependency example
Dependency Example

Formal parameter list

Basetype, size

Queue

Explicit Parameterization

<<bind> <integer, 1000>

String, 400

Queue

Integer Queue

Actual parameter list

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


Metamodels

Metamodels

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


Class diagram metamodel
Class Diagram Metamodel

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


Object model
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

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


Dynamic model
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

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


Approaching a problem

Approaching a Problem

Where do we start?

How do we proceed?

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


Where do we start
Where Do We Start?

Requirements Elicitation and Analysis

  • 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

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


How do we continue
How Do We Continue?

High-Level Design

  • 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

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


How do we wrap up
How Do We Wrap Up?

Detailed Design and Implementation

  • 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

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


Why is requirements analysis difficult
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

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


Why is requirements analysis difficult1
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

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


First law of software engineering
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.”

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

Reasons for changing requirements

Changes made after the requirements are approved increase cost and schedule

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


Requirements products
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

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


Analysis steps to follow
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

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


Use cases
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)

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


Analysis object model
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

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


Analysis object model1
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

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


Analysis object model2
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

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


Object model steps to follow
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

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


Analysis dynamic model
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

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


Dynamic model steps to follow
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

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


Analysis iteration
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

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


ad