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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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