1. Modeling with UML – Class Diagrams
Jarosław Kuchta
Embedded Systems Software Engineering
Modeling with UML – Class Diagrams
GUT - INTEL 2015/16
Embedded Systems Software Engineering

2. Embedded Systems Software Engineering
Goals of Modeling
To help developers to understand problem domain structure, rules, constraints
To unveil missing requirements
To control how development follows reality (to deal with complexity)
GUT - INTEL 2015/16
Embedded Systems Software Engineering

3. Modeling vs. Development
Modeling = Analysis & Design
Development = Design & Implementation
Implementation = Coding & Debugging
UML – Unified Modeling Language (graphical language)
UML was provided for modeling
UML is also used for design
UML does not have enough detail level for implementation
GUT - INTEL 2015/16
Embedded Systems Software Engineering

4. Models vs. Diagrams Model – abstract representation of a system
Abstraction – refinement stop problem
Diagram – graphical representation of a model
UML uses diagrams to model a software system
There are other model representations known (e.g. CRC – Class- Responsibility-Collaboration Cards)
UML tools usually have two layers of information:
graphical layer (layout)
semantic layer (project elements)
Diagrams are often not sufficient to represent all the model details
Not only diagrams, but semantic elements specification are needed
Diagrams provide large scale view of the project
GUT - INTEL 2015/16
Embedded Systems Software Engineering

5. Embedded Systems Software Engineering
UML Diagrams
Static structure diagrams
class diagram
component diagram
deployment diagram
Functionality diagrams
use case diagram
interaction diagram
sequence diagram
collaboration diagram
Behavioral diagrams
state transition diagram
activity diagram
Missing in UML (available by profiles)
timing diagrams
entity-relationship diagrams
navigation diagrams
...
GUT - INTEL 2015/16
Embedded Systems Software Engineering

6. Class diagram elements
class definition frame
header
class name
attributes
operations
compartments
generalization-specialization
- private attribute
# protected attribute
+ public attribute
weak aggregation
strong aggregation
0..1
1..*
association (binary)
GUT - INTEL 2015/16
Embedded Systems Software Engineering

7. Class diagram usage (differences modeling <-> development)
Developers treat classes as software structures (data + functions)
Analysts treat classes as abstraction of real world entities
One model class  many software classes
Modeling classes: no need for many classes, no need for many class attributes, no need for class functions
GUT - INTEL 2015/16
Embedded Systems Software Engineering

8. Other (subtle) differences (1)
Entity – something that exists in the real world, has a large set of features
Object – some entity that exists in the model, has limited set of features
Class – a potential object or set of objects (also empty if class is abstract)
Class – object structure definition
Property – an informative feature of a class
Attribute – data unit held by object
Relationship – a logical binding between two or more classes
Link – a logical binding between two or more objects; an instantiation of a relationship
Generalization-specialization – an ontology relationship between two classes (“is a” relationship)
Inheritance – a mechanism for passing features from a generalized to a specialized class
Multiple inheritance – when a class has multiple generalizations (often modeled)
Single inheritance – when a class has only one (direct) generalization (often required by implementation language)
GUT - INTEL 2015/16
Embedded Systems Software Engineering

9. Other (subtle) differences (2)
Aggregation (strong aggregation) – a relationship between classes that allows joining two or more objects (components) together; a new object (an assembly) is created
Containment (weak aggregation) – a relationship between classes that allows including one or more objects in other object (a container)
Association – any other logical relationship between two or more classes, enables joining many objects
Pointer, reference – a specific implementation of an association; only two objects are unidirectionally linked, bidirectional association requires two pointers / references, binary n-to-n associations and n-ary associations require complex implementation
Association role – a name of an object when it is linked to other object, class name can be used as a role substitute but only when classes at opposite sides of the association are different
Pointer/reference name – represents a role of an object in an association
Association name – a semantic name of the relationship represented by an association
Relationship name – implemented in a database data structure as an index name
Association direction – a direction in which an association should be read
Navigation direction – determines which object has a pointer/reference that enables access to the object as the other side of the association
GUT - INTEL 2015/16
Embedded Systems Software Engineering

10. Other (subtle) differences (3)
Multiple property – a property with many values
Multiple association side – a side of an association which allows many objects at this side
Collection, list – a container of objects
Array – a specific implementation of a collection
Multiplicity – a potential (minimal and maximal) count of values in one property or associated objects at one side of an association
Collection (list) length - an actual count of objects in a container
Collection (list) capacity - maximal count of objects in a container
Array size – a concrete count of objects in an array
Operation – an abstract action that can be performed by an object or with an object of the class
Function – a concrete definition of an operation; needs a result type declaration and parameters specification; can be overloaded and redefined
Method – a concrete implementation of some function, can be virtual, abstract and overridden
Class name – a name of a class when it is used in a model; it can consist of two or more words and national letters
Class identifier – a name of a class when it is implemented in a program; only one word is allowed (eventually words joined with underscores), national letters in some languages
GUT - INTEL 2015/16
Embedded Systems Software Engineering

11. Other (subtle) differences (4)
ID property – not needed in analysis
– needed in database design
Visibility (private, protected, public) – not needed in analysis; all features are public
- can be used in design, in implementation also used internal visibility (in the assembly)
-attribute name – private attribute
#attribute name – protected attribute
+attribute name – public attribute
GUT - INTEL 2015/16
Embedded Systems Software Engineering

12. Embedded Systems Software Engineering
Derived attribute
/age= current year – year(birth date)
+/age
GUT - INTEL 2015/16
Embedded Systems Software Engineering

13. Embedded Systems Software Engineering
N-ary attributes
name [multiplicity]
n – exactly n values
0..1 – no values or one value
0..n – no values and no more than n values
n..m – no less than n and no more than m values
0..* – no values or possibly many values
n..* – no less than n values
* – possibly many values
GUT - INTEL 2015/16
Embedded Systems Software Engineering

14. Embedded Systems Software Engineering
Attribute types
General types – used in analysis
number
integer
real
Specific types – used in design
decimal
longint
double
Defined types (enums)
GUT - INTEL 2015/16
Embedded Systems Software Engineering

15. Embedded Systems Software Engineering
Example
Controller
+Language: String +Code: String
Device controller
+Device Name: String
Process controller
+Process ID: Number
GUT - INTEL 2015/16
Embedded Systems Software Engineering

16. Operation stereotypes
<<constructor>> – creates a new instance
<<destructor>> – destroys an instance
<<query>> – gets a state of an object (state remains unchanged)
<<update>> – changes a state of an object
A state of an object – one or more object attributes
GUT - INTEL 2015/16
Embedded Systems Software Engineering

17. Embedded Systems Software Engineering
Aggregation
Measurement
+Number: String +Date: Date Time +Person ID: Number
Measurement result
+Controller: Controller +Value: Real
GUT - INTEL 2015/16
Embedded Systems Software Engineering

18. Embedded Systems Software Engineering
Association
multiplicity
Measurement
+Number: String +Date: Date Time +Person ID: Number
Employee
0..* 1
3performs
association name
association direction
GUT - INTEL 2015/16
Embedded Systems Software Engineering

19. Embedded Systems Software Engineering
N-ary association
Measurement
+Number: String +Date: Date Time +Person ID: Number
Employee
Supervisor
GUT - INTEL 2015/16
Embedded Systems Software Engineering

20. Embedded Systems Software Engineering
Association roles
Employee
Employee
subordinate
superordinate 1
0..*
GUT - INTEL 2015/16
Embedded Systems Software Engineering

21. Embedded Systems Software Engineering
Association class
Employee
Department
Delegation
+Date
GUT - INTEL 2015/16
Embedded Systems Software Engineering

22. Embedded Systems Software Engineering
Class model purpose
Static analysis of a problem domain
Basis for functional and behavioral analysis
Application logic design
Helper for implementation
Note: various levels of abstraction-refinement
GUT - INTEL 2015/16
Embedded Systems Software Engineering

23. Embedded Systems Software Engineering
Bibliography
Grady Booch, James Rumbaugh, Ivar Jacobson: Unified Modeling User Guide (book, PDF)
GUT - INTEL 2015/16
Embedded Systems Software Engineering