Behavioral Modeling with UML https://flic.kr/p/7xu9QE Behavioral Modeling with UML

SWEBOK Knowledge Areas Software Requirements Software Design Software Construction Software Testing Software Maintenance Software Configuration Management Software Engineering Management Software Engineering Process Software Engineering Models and Methods Software Quality Software Engineering Professional Practice Software Engineering Economics Computing Foundations Mathematical Foundations Engineering Foundations Today’s topic

Overview Structural modeling Behavioral modeling Brief intro to design patterns

What does a class diagram represent? User name : string email : string buyer 1 seller 1 Has Has purchase sale * * Sale price : integer description : string

What does a class diagram represent? User name : string email : string Set of possible objects Instances of each class Set of possible configurations Attribute values Links between objects buyer 1 seller 1 Has Has purchase sale * * Sale price : integer description : string

Pros/cons of class diagram User name : string email : string Pro: Abstract/General Represents all possible objects/configurations Con: Complex A lot of possibilities to consider buyer 1 seller 1 Has Has Sometimes easier to reason about objects (more concrete) than about classes (more abstract) purchase sale * * Sale price : integer description : string

Object Diagrams Class Diagram Object Diagram Sale price : integer description : string surface sale : Sale price = 500 description = "Microsoft Surface" ipad sale : Sale price = 600 description = "Apple iPad" galaxy sale : Sale price = 250 description = "Samsung Galaxy"

Object Diagram Notation name Colon separator type Attribute value galaxy sale : Sale price = 250 description = "Samsung Galaxy" Underline denotes object (as opposed to class) Object Corresponding class: Sale price : integer description : string

Object diagram is snapshot of system at point in time Object Diagrams Class Diagram Object Diagram Sale price : integer description : string surface sale : Sale price = 500 description = "Microsoft Surface" ipad sale : Sale price = 600 description = "Apple iPad" Object diagram is snapshot of system at point in time galaxy sale : Sale price = 250 description = "Samsung Galaxy"

What about associations? Class Diagram Object Diagram User name : string email : string buyer 1 seller 1 ipad sale : Sale price = 600 description = "Apple iPad" Has Has purchase sale * * Sale price : integer description : string

First, let’s add users Class Diagram Object Diagram User name : string email : string alice : User name = "Alice" email = "alice@memphis.edu" buyer 1 seller 1 ipad sale : Sale price = 600 description = "Apple iPad" Has Has purchase sale * * Sale price : integer description : string bob : User name = "Bob" email = "bob@memphis.edu"

Now, make Alice a seller Class Diagram Object Diagram Add a link User name : string email : string alice : User name = "Alice" email = "alice@memphis.edu" Has seller sale Add a link buyer 1 seller 1 ipad sale : Sale price = 600 description = "Apple iPad" Has Has purchase sale * * Sale price : integer description : string bob : User name = "Bob" email = "bob@memphis.edu"

No multiplicities on links Now, make Alice a seller Class Diagram Object Diagram User name : string email : string alice : User name = "Alice" email = "alice@memphis.edu" No multiplicities on links seller buyer 1 seller 1 Has sale ipad sale : Sale price = 600 description = "Apple iPad" Has Has purchase sale * * Sale price : integer description : string bob : User name = "Bob" email = "bob@memphis.edu"

Lastly, make Bob the buyer Class Diagram Object Diagram User name : string email : string alice : User name = "Alice" email = "alice@memphis.edu" seller buyer 1 seller 1 Has sale ipad sale : Sale price = 600 description = "Apple iPad" Has Has Has buyer purchase purchase sale * * Sale price : integer description : string bob : User name = "Bob" email = "bob@memphis.edu"

Is this valid? alice : User name = "Alice" email = "alice@memphis.edu" seller buyer User name : string email : string Has purchase Has ipad sale : Sale price = 600 description = "Apple iPad" buyer 1 seller 1 sale sale Has Has surface sale : Sale price = 500 description = "Microsoft Surface" Has purchase sale * * purchase Sale price : integer description : string Has buyer seller bob : User name = "Bob" email = "bob@memphis.edu"

Is this valid? Yes! alice : User name = "Alice" email = "alice@memphis.edu" Yes! seller buyer User name : string email : string Has purchase Has ipad sale : Sale price = 600 description = "Apple iPad" buyer 1 seller 1 sale sale Has Has surface sale : Sale price = 500 description = "Microsoft Surface" Has purchase sale * * purchase Sale price : integer description : string Has buyer seller bob : User name = "Bob" email = "bob@memphis.edu"

How ’bout this? alice : User name = "Alice" email = "alice@memphis.edu" buyer User name : string email : string Has purchase ipad sale : Sale price = 600 description = "Apple iPad" seller sale chuck : User name = "Chuck" email = "chuck@memphis.edu" Has buyer 1 seller 1 sale Has Has Has purchase sale * * Sale price : integer description : string seller bob : User name = "Bob" email = "bob@memphis.edu"

How ’bout this? No! 1 seller per sale! alice : User name = "Alice" email = "alice@memphis.edu" No! 1 seller per sale! buyer User name : string email : string Has purchase ipad sale : Sale price = 600 description = "Apple iPad" seller sale chuck : User name = "Chuck" email = "chuck@memphis.edu" Has buyer 1 seller 1 sale Has Has Has purchase sale * * Sale price : integer description : string seller bob : User name = "Bob" email = "bob@memphis.edu"

Note: No inheritance in object diagrams User name : string email : string zed : User name = "Zed" email = "zed@memphis.edu" wolverine : Spy name = "Logan" email = "logan@mutant.edu" alias = "Wolverine" Spy alias : string

Class and object diagrams model structure What the objects are How they’re connected What attributes/operations they have But structure isn’t everything What else might you want to model?

Behavioral Modeling How objects interact Two notations: What messages are exchanged over links Messages = method calls/returns Message protocols Scenarios of interaction Two notations: Communication diagram Sequence diagram

Communication Diagram From The Unified Modeling Language Reference Manual, Second Edition by Rumbaugh et al.

Communication Diagram From The Unified Modeling Language Reference Manual, Second Edition by Rumbaugh et al.

Communication Diagram Binds to link Binds to object

Communication Diagram

Communication Diagram

Communication Diagram

Communication Diagram

Sequence Diagram From The Unified Modeling Language Reference Manual, Second Edition by Rumbaugh et al.

Sequence Diagram From The Unified Modeling Language Reference Manual, Second Edition by Rumbaugh et al.

Sequence Diagram

Sequence Diagram

Sequence Diagram

Sequence Diagram

Sequence Diagram

Sequence Diagram

Sequence Diagram

Sequence Diagram

Communication and sequence diagrams both represent scenario Why prefer one over other?

Communication and sequence diagrams both represent scenario Why prefer one over other? Communication includes structure Sequence easier to read message exchange

So what are all these notations good for? Reasoning about your own designs Understanding other people’s designs And design patterns!

Required reading for software designers “Gang of Four” (GoF) book 23 patterns Template solutions to common problems

Common Problem: Many objects interconnected in complex ways From Design Patterns: Elements of Reusable Object-Oriented Software (Gamma et al., 1995)

Common Problem: Many objects interconnected in complex ways ?

Mediator Pattern From Design Patterns: Elements of Reusable Object-Oriented Software (Gamma et al., 1995)

Mediator Pattern From Design Patterns: Elements of Reusable Object-Oriented Software (Gamma et al., 1995)

Application of Mediator Pattern From Design Patterns: Elements of Reusable Object-Oriented Software (Gamma et al., 1995)

Application of Mediator Pattern From Design Patterns: Elements of Reusable Object-Oriented Software (Gamma et al., 1995)

Application of Mediator Pattern From Design Patterns: Elements of Reusable Object-Oriented Software (Gamma et al., 1995)

Summary Structural modeling with Behavioral modeling with Class diagrams Object diagrams Behavioral modeling with Communication diagrams Sequence diagrams