structural specification: beyond class diagrams
TRANSCRIPT
![Page 1: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/1.jpg)
2IW80 Software specification and architecture
Structural specification: beyond class diagrams Alexander Serebrenik
![Page 2: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/2.jpg)
Before we start
/ SET / W&I PAGE 2 24/02/15
• Match the pairs (before the Carnival…)
1 Association A 2 Aggregation B 3 Composition C 4 Implementation D 5 Generalization E 6 Dependency F
![Page 3: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/3.jpg)
Before we start
/ SET / W&I PAGE 3 24/02/15
• Match the pairs
1 Association A 2 Aggregation B 3 Composition C 4 Implementation D 5 Generalization E 6 Dependency F
1E 2C 3F 4A 5D 6B
![Page 4: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/4.jpg)
Before we start
/ SET / W&I PAGE 4 24/02/15
• A patient must be assigned to only one doctor, and a doctor can have one or more patients.
Patient x y Doctor
Determine x and y
![Page 5: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/5.jpg)
Before we start
/ SET / W&I PAGE 5 24/02/15
• A patient must be assigned to only one doctor, and a doctor can have one or more patients.
Patient 1..* 1 Doctor
![Page 6: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/6.jpg)
This week sources
Slides by
David Meredith, Aalborg University, DK
Marie-Elise Kontro, Tampere University, FI
Site by
Kirill Fakhroutdinov GE Healthcare, USA
![Page 7: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/7.jpg)
Recall
Structural diagram is a diagram that identifies modules, activities, or other entities in a system or computer program and shows how larger or more general entities break down into smaller, more specific entities.
IEEE Standard Glossary of Software Engineering Terminology 610.12 1990
/ SET / W&I PAGE 7 24/02/15
![Page 8: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/8.jpg)
UML structure diagrams
/ SET / W&I PAGE 8 24/02/15
Class diagram
Composite structure diagram
Packages diagram
Component diagram
Object diagram
Deployment diagram
![Page 9: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/9.jpg)
Between specification and architecture
• Packages diagram and deployment diagram: the closest UML diagrams come to architecture • more about architecture: second half of the quartile
/ SET / W&I PAGE 9 24/02/15
![Page 10: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/10.jpg)
Packages diagram
• Represents the system at a higher abstraction level • Android SDK – 69 packages vs. 1231 classes • less prone to change, ergo better suited for evolution, than
lower level representations
• NB: Packages diagram (UML standard) is frequently called package diagram
/ SET / W&I PAGE 10 24/02/15
![Page 11: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/11.jpg)
Packages diagram: Packages and Relations
• Packages • groups of “basic elements”, e.g., classes or use cases • namespaces, i.e., all members should have unique names • represented as file folders • can contain other packages, creating hierarchy
• Relations • dependencies, implementations, … • imports and merges
/ SET / W&I PAGE 11 24/02/15
![Page 12: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/12.jpg)
Package representations
/ SET / W&I PAGE 12 24/02/15
Types
Package Types, members not shown
Types
Time Date
Package Types, some members within the borders of the package
Types
⊕
Shape Point
Package Types, some members shown using ⊕-notation
Types
Temporal
Nested packages
![Page 13: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/13.jpg)
Relations
• Dependency • Implementation • Import / access • Merge
/ SET / W&I PAGE 13 24/02/15
![Page 14: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/14.jpg)
Relations: Dependencies
• Package A depends on package B if A contains a class which depends on a class in B • Summarise dependencies between classes
• Graphic representation: or <<use>>
![Page 15: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/15.jpg)
Relations: Dependencies
• Package A depends on package B if A contains a class which depends on a class in B • Summarise dependencies between classes
• Typical 3-tier application (sketch):
Presentation layer
Business layer
Data layer
UI, web-interface, services to other systems
Core calculations, operations, etc
Data storage (DB)
![Page 16: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/16.jpg)
Relations: Dependencies
• Package A depends on package B if A contains a class which depends on a class in B • Summarise dependencies between classes
• Martin’s Acyclic Dependency Principle there should be no cycles in the dependencies
• Fowler: If there are cycles in dependencies, these cycles should be localized, and, in particular, should not cross the tiers
![Page 17: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/17.jpg)
Relations: Implementations (cf. Realization in Class Diagrams)
• Meaningful if multiple variants are present
/ SET / W&I PAGE 17 24/02/15
Database Gateway
MySQL Gateway Oracle Gateway SQL Server Gateway
![Page 18: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/18.jpg)
Relations: Import / access
• To understand the import / access relation between packages • We need to know how elements can reference each other • What does an element import / access mean • How this notion can be generalized to packages
/ SET / W&I PAGE 18 24/02/15
![Page 19: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/19.jpg)
19
How elements can reference each other? (1)
• Element can refer to other elements that are in its own package and in enclosing packages without using fully qualified names
p
q
E s D
r B C A
foo
![Page 20: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/20.jpg)
Do you remember?
• Fully qualified name: a globally unique identifier of a package, class, attribute, method.
• Fully qualified name is composed of • qualifier: all names in the hierarchic sequence above the
given element • the name of the given element itself
• Notation • UML, C++, Perl, Ruby p::A::foo, p::r::C • Java, C# p.A.foo, p.r.C
/ SET / W&I PAGE 20 24/02/15
p
A foo
r C
![Page 21: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/21.jpg)
21
How elements can reference each other? (2)
• Element can refer to other elements that are in its own package and in enclosing packages without using fully qualified names
p
q
E s D
r B C A
foo
![Page 22: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/22.jpg)
Element Import (1)
• Element import allows an element in another package to be referenced using its name without a qualifier • <<import>> imported element within importing package is public • <<access>> imported element within importing package is private
/ SET / W&I PAGE 22 24/02/15
![Page 23: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/23.jpg)
Element Import (2)
• Element import allows an element in another package to be referenced using its name without a qualifier • <<import>> imported element within importing package is public • <<access>> imported element within importing package is private
/ SET / W&I PAGE 23 24/02/15
h
e a
C
F
b
F
C
D <<access>>
<<import>> G <<import>>
![Page 24: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/24.jpg)
Element Import (3)
• Element import allows an element in another package to be referenced using its name without a qualifier • <<import>> imported element within importing package is public • <<access>> imported element within importing package is private
/ SET / W&I PAGE 24 24/02/15
h
e a
C
F
b
F
C
D <<access>>
<<import>> G <<import>>
C
or
![Page 25: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/25.jpg)
Element Import (4)
• Element import allows an element in another package to be referenced using its name without a qualifier • <<import>> imported element within importing package is public • <<access>> imported element within importing package is private
/ SET / W&I PAGE 25 24/02/15
h
e a
C
F
b
F
C
D <<access>>
<<import>> G <<import>>
C
should be referred as e::C in a
![Page 26: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/26.jpg)
Element Import (5)
• Element import allows an element in another package to be referenced using its name without a qualifier • <<import>> imported element within importing package is public • <<access>> imported element within importing package is private
/ SET / W&I PAGE 26 24/02/15
h
e a
C
F
b
F
C
D <<access>>
<<import>> G <<import>>
F cannot be imported to a since there is already an F in a. Hence, we need to rename b::F to G in a.
![Page 27: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/27.jpg)
Element Import (6)
• Element import allows an element in another package to be referenced using its name without a qualifier • <<import>> imported element within importing package is public • <<access>> imported element within importing package is private
/ SET / W&I PAGE 27 24/02/15
h
e a
C
F
b
F
C
D <<access>>
<<import>> G <<import>>
b::F is accessible as G in h, b::C is accessible as C in h, b::D is not
accessible in h (private visibility of b::D in a due to <<access>>).
![Page 28: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/28.jpg)
Package import (1)
• A package import identifies a package whose members are to be imported • Conceptually equivalent to having an element import to
each individual member of the imported package • <<import>> if package import is public • <<access>> if package import is private
/ SET / W&I PAGE 28 24/02/15
![Page 29: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/29.jpg)
Package import (2)
• A package import is a directed relationship that identifies a package whose members are to be imported • Conceptually equivalent to having an element import to
each individual member of the imported package • <<import>> if package import is public • <<access>> if package import is private
/ SET / W&I PAGE 29 24/02/15
auxiliary
shoppingCart
types
webShop <<import>>
Are elements of types accessible from webShop? Are elements of auxiliary accessible from webShop?
Are elements of types accessible from shoppingCart? Are elements of auxiliary accessible from shoppingCart?
![Page 30: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/30.jpg)
Package import (2)
• A package import is a directed relationship that identifies a package whose members are to be imported • Conceptually equivalent to having an element import to
each individual member of the imported package • <<import>> if package import is public • <<access>> if package import is private
/ SET / W&I PAGE 30 24/02/15
auxiliary
shoppingCart
types
webShop <<import>>
Are elements of types accessible from webShop? YES Are elements of auxiliary accessible from webShop? NO
Are elements of types accessible from shoppingCart? YES Are elements of auxiliary accessible from shoppingCart? YES
![Page 31: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/31.jpg)
Relations: Recap
ü Dependency ü Implementation ü Import / access • Merge
/ SET / W&I PAGE 31 24/02/15
![Page 32: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/32.jpg)
Package merge
• A package merge indicates that the contents of the two packages are to be combined. • A (merged package) is merged into B (receiving package)
that becomes B’ (resulting package)
/ SET / W&I PAGE 32 24/02/15
![Page 33: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/33.jpg)
Package merge
• A package merge indicates that the contents of the two packages are to be combined. • A (merged package) is merged into B (receiving package)
that becomes B’ (resulting package)
• Merge is possible only if • There is no cycle on “merge” dependencies • Receiving package does not contain the merged package • Receiving package is not contained in the merged package • Receiving element cannot have references to the merged
element • Matching typed elements should have the same type (class)
or a common supertype (superclass)
/ SET / W&I PAGE 33 24/02/15
![Page 34: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/34.jpg)
Merge rules
UML 2.5 Beta 2, pp. 252-262 http://www.omg.org/spec/UML/2.5/Beta2/
/ SET / W&I PAGE 34 24/02/15
s
D
B A
q
C A <<merge>>
merged package receiving package
s
D
B A
C
resulting package
Merge of s::A and q::A
Copied from s
Copied from s
Copied from q
![Page 35: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/35.jpg)
Merge rules
UML 2.5 Beta 2, pp. 252-262 http://www.omg.org/spec/UML/2.5/Beta2/
/ SET / W&I PAGE 35 24/02/15
s
A
B
q
B A <<merge>>
merged package receiving package
s
A
B
resulting package
Merge of s::B and q::B
Merge of s::A and q::A
![Page 36: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/36.jpg)
Summary: UML package diagrams
/ SET / W&I PAGE 36 24/02/15 http://www.uml-diagrams.org/package-diagrams-overview.html
![Page 37: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/37.jpg)
How do we organize classes/use-cases in packages?
• General: try to give packages meaningful names
• Two special cases: • Class package diagrams − “basic elements” are class diagrams − The most popular special case
• Use-case package diagrams − “basic elements” are use-case diagrams − Useful for larger projects to organize requirements
/ SET / W&I PAGE 37 24/02/15
![Page 38: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/38.jpg)
Class Package Diagrams
• Heuristics to organize classes into packages: • Classes of a framework belong in the same package. • Classes in the same inheritance hierarchy typically belong
in the same package. • Classes related to one another via aggregation or
composition often belong in the same package. • Classes that collaborate with each other a lot often belong
in the same package.
/ SET / W&I PAGE 38 24/02/15
![Page 39: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/39.jpg)
How would you organize into 2 packages?
• Car, Cylinder, Driver, Driving License, Engine, Person, Wheel
• Start by drawing a class diagram
/ SET / W&I PAGE 39 24/02/15
![Page 40: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/40.jpg)
How would you organize into 2 packages?
• Car, Cylinder, Driver, Driving License, Engine, Person, Wheel
/ SET / W&I PAGE 40 24/02/15
Car
Wheel Engine
Cylinder
Person
Driver
Driving License 4 1
2,4,6,8,10,12
![Page 41: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/41.jpg)
How would you organize into 2 packages?
• Car, Cylinder, Driver, Driving License, Engine, Person, Wheel
/ SET / W&I PAGE 41 24/02/15
Car
Wheel Engine
Cylinder
Person
Driver
Driving License 4 1
2,4,6,8,10,12
Vehicle
Individual
![Page 42: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/42.jpg)
How would you organize into 2 packages?
• Car, Cylinder, Driver, Driving License, Engine, Person, Wheel
/ SET / W&I PAGE 42 24/02/15
Vehicle
Individual
![Page 43: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/43.jpg)
Use-Case Package Diagrams
• Heuristics to organize use cases into packages: • Keep associated use cases together: included, extending
and inheriting use cases belong in the same package. • Group use cases on the basis of the needs of the main
actors.
/ SET / W&I PAGE 43 24/02/15
![Page 44: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/44.jpg)
Use-Case Package Diagram Example
/ SET / W&I PAGE 44 24/02/15
http://www.students.tut.fi/~kontrom/files/Lecture6.pdf
![Page 45: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/45.jpg)
UML structure diagrams
/ SET / W&I PAGE 45 24/02/15
Class diagram
Composite structure diagram
Packages diagram
Component diagram
Object diagram
Deployment diagram
![Page 46: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/46.jpg)
Component diagrams
• Component: a modular unit with well-defined interfaces that is replaceable within its environment (UML Superstructure Specification, v.2.0, Chapter 8)
• fosters reuse • stresses interfaces
• Graphical representation: special kind of class
/ SET / W&I PAGE 46 24/02/15
<<component>>
Account
Account
Account
UML 1 UML 2
![Page 47: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/47.jpg)
Component diagrams
• Component: a modular unit with well-defined interfaces that is replaceable within its environment (UML Superstructure Specification, v.2.0, Chapter 8)
• fosters reuse • stresses interfaces
• Two views: black-box and white-box • Black-box view: interfaces provided and required only
/ SET / W&I PAGE 47 24/02/15
![Page 48: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/48.jpg)
Component diagrams
• Component: a modular unit with well-defined interfaces that is replaceable within its environment (UML Superstructure Specification, v.2.0, Chapter 8)
• fosters reuse • stresses interfaces
• Two views: black-box and white-box • Black-box view: interfaces provided and required only • White-box view: structure of interfaces and/or internal
structure
/ SET / W&I PAGE 48 24/02/15
provided interface
required interface
![Page 49: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/49.jpg)
Component diagrams
• Component: a modular unit with well-defined interfaces that is replaceable within its environment (UML Superstructure Specification, v.2.0, Chapter 8)
• fosters reuse • stresses interfaces
• Two views: black-box and white-box • Black-box view: interfaces provided and required only • White-box view: structure of interfaces and/or internal
structure
/ SET / W&I PAGE 49 24/02/15
![Page 50: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/50.jpg)
Which notation indicates that I is provided by Account?
/ SET / W&I PAGE 50 24/02/15
Account
Account
Account
Account
<<interface>> I
<<interface>> I
a) b)
c) d)
![Page 51: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/51.jpg)
Which notation indicates that I is provided by Account?
/ SET / W&I PAGE 51 24/02/15
Account
Account
Account
Account
<<interface>> I
<<interface>> I
a) b)
c) d) provided interface
provided interface
![Page 52: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/52.jpg)
Nested components
• Components can be contained in other components • Interfaces can then be delegated through ports
/ SET / W&I PAGE 52 24/02/15
![Page 53: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/53.jpg)
Summary: UML component diagrams
/ SET / W&I PAGE 53 24/02/15 http://www.uml-diagrams.org/component-diagrams.html
![Page 54: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/54.jpg)
UML structure diagrams
/ SET / W&I PAGE 54 24/02/15
Class diagram
Composite structure diagram
Packages diagram
Component diagram
Object diagram
Deployment diagram
![Page 55: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/55.jpg)
Deployment
• Deployment: relationship between logical and/or physical elements of systems (Nodes) and information technology assets assigned to them (Artefacts).
/ SET / W&I PAGE 55 24/02/15
![Page 56: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/56.jpg)
Deployment
• Deployment: relationship between logical and/or physical elements of systems (Nodes) and information technology assets assigned to them (Artefacts).
• Nodes • devices: application server, client workstation, … • execution environments: DB system, J2EE container, … • Graphical representation: box
/ SET / W&I PAGE 56 24/02/15
DBServer
![Page 57: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/57.jpg)
Deployment
• Deployment: relationship between logical and/or physical elements of systems (Nodes) and information technology assets assigned to them (Artefacts).
• Nodes • devices: application server, client workstation, … • execution environments: DB system, J2EE container, … • Graphical representation: box
• Nodes can be physically connected (e.g., via cables or wireless) • UML-parlance: CommunicationPath • Graphical representation: as an association
/ SET / W&I PAGE 57 24/02/15
DBServer
![Page 58: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/58.jpg)
Deployment
• Deployment: relationship between logical and/or physical elements of systems (Nodes) and information technology assets assigned to them (Artefacts).
• Artefacts: information items produced during software development or when operating the system • model files, source files, scripts, executable files, database
tables, word-processing documents, mail messages, … • Graphical representation: “class-like”
• Relations: dependencies
/ SET / W&I PAGE 58 24/02/15
<<artifact>>
ShoppingCart.jar
![Page 59: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/59.jpg)
Deployment
• Deployment: relationship between logical and/or physical elements of systems (Nodes) and information technology assets assigned to them (Artefacts).
• Deployment: three equally valid representations
PAGE 59 24/02/15 http://www.uml-diagrams.org/deployment-diagrams.html
![Page 60: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/60.jpg)
Deployment: missing piece
• How do we know where a given use case, class, component, or package is deployed? • Use case / class / component / packages diagrams do not
discuss deployment • Deployment diagrams do not discuss use cases / classes /
components / packages but only artifacts
/ SET / W&I PAGE 60 24/02/15
![Page 61: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/61.jpg)
Deployment: missing piece
• How do we know where a given use case, class, component, or package is deployed? • Use case / class / component / packages diagrams do not
discuss deployment • Deployment diagrams do not discuss use cases / classes /
components / packages but only artifacts
• Manifestation maps artifacts to use cases / classes / components / packages
/ SET / W&I PAGE 61 24/02/15
![Page 62: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/62.jpg)
Summary: deployment diagrams
/ SET / W&I PAGE 62 24/02/15 http://www.uml-diagrams.org/deployment-diagrams-overview.html
![Page 63: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/63.jpg)
Exam question (April 2014)
• Identify correct statements pertaining to deployment diagrams: a) Artefacts are physical elements of the system such as
devices and execution environments. b) Artefacts: information items produced during software
development or when operating the system. c) Manifestation maps artefacts to components, use
cases, classes, components, packages. d) Manifestation maps components, use cases, classes,
components to artefacts.
/ SET / W&I PAGE 63 24/02/15
![Page 64: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/64.jpg)
Exam question (April 2014)
• Identify correct statements pertaining to deployment diagrams: a) Artefacts are physical elements of the system such as
devices and execution environments. b) Artefacts: information items produced during software
development or when operating the system. c) Manifestation maps artefacts to components, use
cases, classes, components, packages. d) Manifestation maps components, use cases, classes,
components to artefacts.
/ SET / W&I PAGE 64 24/02/15
Yes!
Yes!
37 students gave both correct answers 17 students gave one correct answer (and no incorrect ones) 28 students have at least one incorrect answer
![Page 65: Structural specification: beyond class diagrams](https://reader034.vdocument.in/reader034/viewer/2022042201/62587131500c941d6928ee65/html5/thumbnails/65.jpg)
Conclusions
/ SET / W&I PAGE 65 24/02/15