Supplementary: Using and Extending UML
description
Transcript of Supplementary: Using and Extending UML
CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003)
R
R
R
Supplementary:
Using and Extending UML
CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003)
R
R
RExtensibility Mechanisms
• Stereotypes
• Tagged Values
• Constraints ActionQueue
<<container>>
{version = 3.2}
add(a: Action)remove(n: Integer)
{add runs in O(1) time}
CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003)
R
R
RStereotypes
• Extends the UML vocabulary
• Create new building blocks derived from existing ones,– specific to problem domain– Example: Sensors for embedded systems,
<<sensor>>
thermometer
temp
read
<<sensor>>
Voltage meter
volt
read
CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003)
R
R
RTagged 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
volt
read
{reader=J. Smith}
CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003)
R
R
RConstraint
• 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
volt
read
{reader=J. Smith}
{read before thermostat check}
CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003)
R
R
RInterface
• 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)
R
R
RInterface 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
ISpellIThesaurus
IUnknown
<<interface>>URLStreamHandler
openConnection()Parse URL()setURL()toExternalForm()
Operations
CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003)
R
R
RDependency 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)
R
R
RDependency Example
QueueBasetype, size
QueueString, 400
Integer Queue
<<bind> <integer, 1000>
Explicit Parameterization
Formal parameter list
Actual parameter list
CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003)
R
R
R
Metamodels
CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003)
R
R
RClass Diagram Metamodel
CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003)
R
R
RObject ModelObject 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)
R
R
RDynamic ModelDynamic 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)
R
R
R
Approaching a Problem
Where do we start?
How do we proceed?
CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003)
R
R
RWhere 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
CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003)
R
R
RHow 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
CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003)
R
R
RHow 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
CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003)
R
R
RWhy 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)
R
R
RWhy 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)
R
R
RFirst 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)
R
R
RReasons 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
CSE870: Advanced Software Engineering: Extending and Using UML (Cheng, Sp2003)
R
R
RRequirements 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)
R
R
RAnalysis: 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)
R
R
RUse 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)
R
R
RAnalysis: 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)
R
R
RAnalysis: 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)
R
R
RAnalysis: 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)
R
R
RObject 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)
R
R
RAnalysis: 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)
R
R
RDynamic 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)
R
R
RAnalysis: 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