T H E U N I V E R S I T Y O F B R I T I S H C O L U M B I A 1 Modeling software behavior UML Acknowledgement: some slides from Philippe Kruchten, Steve.
Post on 26-Dec-2015
213 Views
Preview:
Transcript
T H E U N I V E R S I T Y O F B R I T I S H C O L U M B I A
1
Modeling software behaviorUML
Acknowledgement: some slides from Philippe Kruchten, Steve Easterbrook
2
What is a model?
A representation of a system that allows for investigation of the properties of the system.
3
Why build one?
A model can guide your exploration:• It can help you figure out what questions to ask• It can help to reveal key design decisions• It can help you to uncover problems
• e.g. conflicting or infeasible requirements, confusion over terminology, scope, etc
Can help you check your understanding• Reason about the model to understand its consequences
• Does it have the properties you expect?• Animate the model to help us visualize/validate requirements
Can help you communicate• Provides useful abstracts that focus on the point you want to make• …without overwhelming people with detail
Throw-away modeling?• The exercise of modeling is more important than the model itself• Time spent perfecting the models might be time wasted…
4
What is UML?
Modeling language
What UML is not Not a method in itself
• A notation designed to support various methods for requirement analysis and software design
• E.g., (IBM) Rational Unified Process (RUP)
5
Two types of UML diagrams
ActivityDiagrams
Models
Dynamic Diagrams (Behavior and Interaction
StatechartDiagrams
CollaborationDiagrams
SequenceDiagrams
Use-CaseDiagrams
ClassDiagrams
ObjectDiagrams
ComponentDiagrams
DeploymentDiagrams
Static Diagrams
6
Visual modeling of a software system
Actor A
Use Case 1
Use Case 2
Actor B
user : Clerk
mainWnd : MainWnd
fileMgr : FileMgr
repository : Repositorydocument : Document
gFile : GrpFile
9: sortByName ( )
L1: Doc view request ( )
2: fetchDoc( )
5: readDoc ( )
7: readFile ( )
3: create ( )
6: fillDocument ( )
4: create ( )
8: fillFile ( )
Window95
¹®¼ °ü¸®
Ŭ¶óÀ̾ðÆ®.EXE
Windows
NT
¹®¼ °ü¸® ¿£Áø.EXE
WindowsNT
Windows95
Solaris
ÀÀ¿ë¼ ¹ö.EXE
AlphaUNIX
IBM
Mainframe
µ¥ÀÌŸº£À̽º¼ ¹ö
Windows95
¹®¼ °ü¸® ¾ÖÇø´Document
FileManager
GraphicFile
File
Repository DocumentList
FileList
user
mainWnd fileMgr : FileMgr
repositorydocument : Document
gFile
1: Doc view request ( )
2: fetchDoc( )
3: create ( )
4: create ( )
5: readDoc ( )
6: fillDocument ( )
7: readFile ( )
8: fillFile ( )
9: sortByName ( )
ƯÁ¤¹®¼ ¿¡ ́ ëÇÑ º¸±â¸¦ »ç¿ëÀÚ°¡ ¿äûÇÑ´Ù.
È ÀÏ°ü̧ ®ÀÚ´Â Àоî¿Â ¹®¼ ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼
°´Ã¼¿¡ ¼³Á¤À» ¿äûÇÑ´Ù.
È ̧é °´Ã¼´Â ÀоîµéÀÎ °´Ã¼µé¿¡ ´ëÇØ ÀÌ̧ §º°·Î
Á¤·ÄÀ» ½ÃÄÑ È ̧é¿¡ º¸¿©ÁØ´Ù.
Forward and Reverse Engineering
Openning
Writing
ReadingClosing
add file [ numberOffile==MAX ] / flag OFF
add file
close file
close fileUse Case 3
Use-CaseDiagram Class Diagram
Collaboration Diagram
Sequence Diagram
Component Diagram
StateDiagram
GrpFile
read( )open( )create( )fillFile( )
rep
Repository
name : char * = 0
readDoc( )readFile( )
(from Persistence)
FileMgr
fetchDoc( )sortByName( )
DocumentList
add( )delete( )
Document
name : intdocid : intnumField : int
get( )open( )close( )read( )sortFileList( )create( )fillDocument( )
fList
1
FileList
add( )delete( )
1
File
read( )
read() fill the code..
Deployment Diagram
8
Reminder: Class
A description of a set of objects that share the same attributes, operations, methods, relationships, and semantics.
A class may use a set of interfaces to specify collections of operations it provides to its environment
9
Reminder: Object
An entity with a well-defined boundary and identity that encapsulates state and behavior . • State is represented by attributes and
relationships; • Behavior is represented by operations, methods,
and state machines.
An object is an instance of a class.
11
Types of relationships in class diagrams
Class level:• Dependency:
• x depends on y (for implementation, for example)• A dependency exists between two defined elements if
a change to the definition of one would result in a change to the other.
• Generalization (& specialization):• x is a kind of y (taxonomy, subclassing)
Instance level• Association:
• x is a part of y
14
Types of relationships in class diagrams
Class level:• Dependency:
• x depends on y (for implementation, for example)• A dependency exists between two defined elements if
a change to the definition of one would result in a change to the other.
• Generalization (& specialization):• x is a kind of y (taxonomy, subclassing)
Instance level• Association:
• x is a part of y
15
Instance-Level Relationships: Association
A relationship that models a bi (or multi)-directional semantic connection among instances.
An association
represents a
family of links
16
One more association example
Role
Activity0..*
1
0..*
1
Performs
Artifact0..*1 0..*1 IsResponsibleFor
0..*
0..*
0..*
input0..*
Consumes
0..*
0..*
0..*
0..*
Produces
17
Aggregation = grouping (e.g., “by reference”)
Composition = is made of (e.g., “by value”)
Two Special Cases of Associations
20
Composition versus Aggregation Assume A associated with B
• If I destroy an object A, is the associated B also destroyed?
• Yes? you probably have a composition
• If an object A1 is associated with object B1, can the same object B1 be also associated with another object A2
• Yes? you probably have an aggregation
21
Composition vs. Aggregation
The whole of a composition must have a multiplicity of 0..1 or 1, indicating that a part must be for only one whole. • The whole of an aggregation may have any multiplicity.
Example: • represent real-world whole-part relationships,
• e.g., an engine is part of a car, the composition relationship is most appropriate.
• represent database relationship, • e.g., car model engine ENG01 is part of a car model
CM01, an aggregation relationship is best, (as the engine,
ENG01 may be also part of a different car model)
22
Class Diagram (2)
WorkItem(from Basic Elements)
Step ActivityKind1
1..*
1
1..*
WorkDefinitionName(from Names)
ArtifactName(from Names)
RoleKind(f rom Basic Elements)
0..10..* performer0..10..*
0..* 0..*0..* assistant 0..*
WorkDefinition
0..*
1
0..*
1
1
0..*
1
0..*
ArtifactKind
+ isDeliverable : Boolean
(from Basic Elements)
1
0..*
1
0..*
1
0..*
1
0..*
0..*
0..1
0..*
0..1
IsResponsibleFor
ArtifactUsageName
+ isInput : Boolean+ isOutput : Boolean+ hasWorkPerArtifact : Boolean
(from Names)
1
0..*
1
0..*
1
0..*
1
0..*IsOfKind
23
Exercise
A system requires representation of folders and files. Both folders and files have names, creation date, and size. Files must be contained in folders and folders may contain files and other folders.
Draw the class diagram
Now add symbolic links
24
One more …
A company consists of departments. Departments themselves can be made of other sub-departments.
Departments are located in one or more offices. One office acts as the company headquarter.
Each department has a manager who is recruited from the set of employees of that department.
An employee is associated with one or more departments but it has one ‘home’ department.
Your task is to model the system for the company. Draw a class diagram with the classes in your system their
attributes, operations and relationships, multiplicity specifications, and other model elements that you find appropriate.
25
Summary so far: What UML class diagrams can show?
Division of Responsibility• Operations that objects are responsible for providing
Subclassing• Inheritance, generalization
Navigability / Visibility• When objects need to know about other objects to call their
operations Aggregation / Composition
• When objects are part of other objects Dependencies
• When changing the design of a class will affect other classes Interfaces
• Used to reduce coupling between objects
26
Uses of UML As a sketch
• Very selective - informal and dynamic• Forward engineering: describe some concept to implement• Reverse engineering: explain how some part of the program works
As a blueprint• Emphasis on completeness• Forward engineering: model as a detailed spec for the programmer• Reverse engineering: model as a code browser• Roundtrip: tools provide both forward and reverse engineering to move
back and forth between program and code
As a programming language• UML models are automatically compiled into working code• Requires sophisticated tools• “tripless” - the model is the code
29
Things to Model
Structure of the code• Code Dependencies• Components and couplings
E.g. Behaviour of the code• Execution traces• State machines models of complex objects
E.g. Function of the code• What functions does it provide to the user?
30
Modeling Dynamic Behavior
Sequence diagram• Depict object interaction by highlighting the
time ordering of method invocation
34
Interaction Frame Operators
Operator Meaning
alt Alternative; only the frame whose guard is true will execute
opt Optional; only executes if the guard is true
par Parallel; frames execute in parallel
loop Frame executes multiple times, guard indicates how many
region Critical region; only one thread can execute this frame at a time
neg Negative; frame shows an neg invalid interaction
ref Reference; refers to a sequence shown on another
Diagram
sd Sequence Diagram; used to surround the whole
diagram (optional)
35
When to use sequence diagrams
Comparing Design Options• Shows how objects collaborate to carry out a task• Graphical form shows alternative behaviours
Assessing Bottlenecks• E.g. an object through which many messages pass
Explaining Design Patterns• Enhances structural models• Good for documenting behaviour of design features
Elaborating Use Cases• Shows how the user expects to interact with the system• Shows how the user interface operates
Modeling a design pattern: The Observer Pattern
An object, i.e., the subject, maintains a list of its dependents, the observers, and notifies them of any state changes, usually by calling one of their methods.
Recap: Sequence Diagram Key Parts
participant: object or entity that acts in the diagram • diagram starts with an unattached "found
message" arrow
message: communication between participant objects
the axes in a sequence diagram: • horizontal: which object/participant is acting • vertical: time (down -> forward in time)
40
45
Style Guide for Sequence Diagrams
Spatial Layout• Strive for left-to-right ordering of messages• Put proactive actors on the left• Put reactive actors on the right
Readability• Keep diagrams simple• Don’t show obvious return values• Don’t show object destruction
Usage• Focus on critical interactions only
Consistency• Class names must be consistent with class diagram• Message routes must be consistent with (navigable) class
associations
Coming up: In class exercise
Draw a sequence diagram for: Netflix process to deal with returned DVDs•When a return comes in a person scan’s it in, the S/W detects that and goes through a sequence of steps to send a new movie to a customer.
•Think of the different classes that would be involved: Queue, Shipping, Inventory, UserAccount, other classes??
47
Modeling Dynamic Behavior: State diagrams
• Depict the flow of control using the concepts of state and transitions
• Labels of transitions are in the form:
[Event-List][[Guard]][/Action]- Entry action and exit action
entry/Action1 or exit/Action2
50
Exercise
Reservations are made for repairs of vehicles (if space is available, otherwise they are added to a waiting list). The vehicle is delivered and waits in the dock until repair can commence. Repair can commence at any time. During repair new parts may be needed and the vehicle may have to wait for the parts to arrive. When repairs are completed a test drive is organized. Following the test, more repairs may be needed, or the vehicle will become ready to be picked up. Eventually the vehicle is picked up by its owner.
51
Two types of UML diagrams
ActivityDiagrams
Models
Dynamic Diagrams (Behavior and Interaction
StatechartDiagrams
CollaborationDiagrams
SequenceDiagrams
Use-CaseDiagrams
ClassDiagrams
ObjectDiagrams
ComponentDiagrams
DeploymentDiagrams
Static Diagrams
52
Design Patterns
“Each pattern describes
a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice”.
--- Christopher Alexander, 1977
This was in describing patterns in buildings and towns.This was in describing patterns in buildings and towns.In SE, design patterns are in terms of objects and interfaces, not In SE, design patterns are in terms of objects and interfaces, not
walls and doors.walls and doors.
The manner in which a collection of interacting objects collaborate to accomplish a specific task or provide some specific functionality.
53
Architecture vs. Design Patterns
Key decisions ….
Architecture
Design Patterns Lower level than architectures (Sometimes, called micro-architecture) Reusable collaborations that solve subproblems within an application
how can I decouple subsystem X from subsystem Y?
Design patterns support object-oriented reuse at a high level of abstraction Design patterns provide a “framework” that guides and constrains object-oriented implementation
Why Design Patterns?
What is a Design Pattern?
A design pattern is a general reusable solution to a commonly occurring problem
A design pattern is not a finished design that can be transformed directly into code.
It is a description or template for how to solve a problem that can be used in many different situations.
Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. 54
55
55
FactoryBuilderPrototypeSingleton
AdapterBridgeCompositeDecoratorFaçadeFlyweightProxy
InterpreterTemplateChain of ResponsibilityCommandIteratorMediatorMementoObserverStateStrategyVisitor
Creational Structural Behavioral
Design Patterns : Elements of Reusable Object-Oriented Software (1995) , Gamma, Helm, Johnson , Vlissides
56
4 Essential Elements of each Design Pattern
Name: identifies a pattern
Problem: describes when to apply the pattern in terms of the problem and context
Solution: describes elements that make up the design, their relationships, responsibilities, and collaborations
Consequences: results and trade-offs of applying the pattern
More patterns: Singleton
Ensure a class has only one instance, and provide a global point of access to it.
public class Singleton { private Singleton() {} private static _instance = null; public static S getInstance () { if (_instance == null) _instance = new Singleton(); return _instance; } ...}
Lazy instantiationTactic of delaying the creation of an object, the calculation of a value, or some other expensive process until the first time it is needed.
57
return _instance;return _instance;
58
One more pattern: Factory
Define an interface for creating an object, but let subclasses decide which class to instantiate. • Factory Method lets a class defer instantiation to
subclasses.
58
return new ConcreteProduct();return new ConcreteProduct();
...Product product = CreateProduct();
...
...Product product = CreateProduct();
...
top related