Week 3. UML Class Diagram and Configuration Management

Class Diagrams

Class diagram (UML)

A class diagram shows the static class structure, they are used when developing an object-oriented system model to show the classes in a system and the associations between these classes.

It consists of:

• Class (UML Class)

  An object class (or just class) which can be thought of as a general definition of one kind of system object.

    	graph {
    		node [shape=record]
    		Course
    		CourseCoarse [label = <{<b>Course</b> | name<br align="left"/>semester<br align="left"/>hours<br align="left"/>|getCredits()<br align="left"/>getLecturer()<br align="left"/>getGPA()<br align="left"/>}>]
    		CourseFine [label = <{<b>Course</b> | + name: String<br align="left"/>+ semester: SemesterType<br align="left"/>- hours: int<br align="left"/>- /credits: int<br align="left"/>|+ getCredits(): int<br align="left"/>+ getLecturer(): Lecturer<br align="left"/>+ getGPA(): float<br align="left"/>+ getHours(): float<br align="left"/>+ setHours(hours: float): void<br align="left"/>}>]
    	}

  Link to original

• Object (UML Class)

  Objects are instances of classes.

  graph {
  	node [shape=record]
   
  	Class [label=<{<b>User</b> <br align="left"/>| + ID: int<br align="left"/>+ name: String<br align="left"/>+ address: String<br align="left"/>}>]
   
  	Object [label=<{<b>deez:User</b> <br align="left"/>| ID = 0044<br align="left"/>name = "deez"<br align="left"/>address = "123 Fake Street"<br align="left"/>}>]
  }

  Attribute (UML Class)

  Attributes define the structural characteristics of a class, each instance / object has a different value.

  Link to original

  Operation (UML Class)

  An operation is the behaviour of a class, it is identical for all objects of a class, they are not depicted in the object diagram.

  Link to original

  Link to original

• Attribute Syntax (UML Class)

  Each attribute follows a certain syntax which is built up using the following structure:

  1. Visibility: who is permitted to access the attribute
     • +: public / everyone
     • -: private / only the object itself
     • #: protected / class itself and sub-classes
     • ~: package / classes that are in the same package
  2. Derived: / is specified if the attribute value is derived from other attributes
  3. Name: name of the attribute
  4. Type: it may be one of:
     • Another user-defined class
     • Predefined primitive data type (Boolean, Integer, String)
     • User-defined primitive data type: «primitive»

       	graph {
       		node[shape=record]
       		Float [label=<{«primitive» <br align="center"/><b>Float</b> <br align="center"/>| round(): void<br align="left"/>}>]
       	}

     • Composite data type: «datatype»

       	graph {
       		node[shape=record]
       		Float [label=<{«datatype» <br align="center"/><b>Date</b> <br align="center"/>| day<br align="left"/>month<br align="left"/>year<br align="left"/>}>]
       	}

     • Enumeration: «enumeration»

       	graph {
       		node[shape=record]
       		Float [label=<{«enumeration» <br align="center"/><b>AcademicDegree</b> <br align="center"/>| bachelor<br align="left"/>master<br align="left"/>phd<br align="left"/>}>]
       	}

  5. Multiplicity: number of values an attribute may contain
     • By default, we take it to be $1$.
     • Notation is $[\text{min}\dots \text{max}]$.
     • No upper limit may be indicated by $[\ast ]$ or $[0\dots \ast ]$.
  6. Default value: used if the attribute value is not set explicitly by the user
  7. Properties: additional restrictions on attributes
     • Predefined properties that may be used:
       • {readOnly}: value cannot be changed
       • {unique}: no duplicates permitted
       • {non-unique}: duplicated permitted
       • {ordered}: fixed order of the values
       • {unordered}: no fixed order of the values
     • Common attribute specifications:
       • Set: {unordered, unique}
       • Multi-set: {unordered, non-unique}
       • Ordered set: {ordered, unique}
       • List: {ordered, non-unique}

  Link to original

• Operation Syntax (UML Class)

  Each operation follows a certain syntax which is built up using the following structure:

  1. Visibility: see Attribute Syntax (UML Class)
  2. Name: see Attribute Syntax (UML Class)
  3. Parameter: similar notation to attributes: In addition, a direction may be specified:
     • in: input parameter When the operation is used, a value is expected from this parameter.
     • out: output parameter After the execution of the operation, the parameter has adopted a new value.
     • inout: combined input / output parameter
  4. Type: type of the return value

  Link to original

• Association (UML Class)

  An association: link between classes that indicates that there is some relationship between these classes.

  	graph {
  		rankdir=LR
  		node[shape=rectangle]
  		Lecturer--Course
  	}

  Link to original

• Binary Association (UML Class)

  A binary association is an association between two classes where an instance of one class must know about the other in order to perform its work.

  • Role names and multiplicities are labelled at both ends.
  • In uni-directional associations, role name at the start of the arrow is optional.
  • Can be used to formalise requirements such as “each professor may coach a set of students, and each student is coached by exactly one professor”

  

  Multiplicity (UML)

  The multiplicity is the number of objects that may be associated with exactly one object of the opposite side.

  UML Notation	Meaning
  $\ast$	any number of objects (incl. zero)
  $1\dots \ast$	at least one object
  $1$	exactly one object
  $n$	exactly $n$ objects
  $a\dots b$	at least $a$ and at most $b$ objects

  graph {
  	rankdir=LR
  	node [shape=rectangle]
  	Lecturer--Assignment [taillabel="1" label="issues" headlabel="*"]
  }

  graph {
  	rankdir=LR
  	node [shape=rectangle]
  	Lecturer--Assignment [taillabel="1..*" label="gives" headlabel="1..*"]
  }

  Link to original

  Role (UML Class)

  The role describes the way in which an object is involved in an association relationship.

  

  Link to original

  Link to original

• Unary Association (UML Class)

  A unary association is between a class and itself.

  graph {
  	node[shape=rectangle]
  	Person--Person [taillabel="0..1" label="  is married to"]
  	Employee--Employee [taillabel="+manager 1" headlabel="+staff 1..*" label="  manages"]
  }

  Link to original

• Association Class (UML Class)

  An association class allows us to assign attributes to the relationship between classes rather than to a class itself.

  

  This is necessary when we are modelling n:m associations.

  

  Link to original

• Aggregation (UML Class)

  An aggregation is a special form of association used to express that a class is part of another class, properties of the aggregation association include:

  • transitive: if $B$ is part of $A$ and $C$ is part of $B$, $C$ is also part of $A$
  • asymmetric: it is not possible for $A$ to be part of $B$ and $B$ to be part of $A$ at the same time

  There are two types:

  1. Shared Aggregation (UML Class)

     A shared aggregation expresses “a weak belonging of the parts to a whole” where parts also exist independently of the whole. Multiplicity at the aggregating end may be $\ge 1$ hence one element can be part of multiple other element at the same time. Syntax is a hollow diamond at the aggregating end.

     For example, take that:

     • a Student is part of LabClass
     • a Course is part of StudyProgram

     

     Link to original

  2. Composition (UML Class)

     A composition is an existence dependency between the composite object and its parts. One part can only be contained in at most one composite object at one specific point in time. Multiplicity at aggregating end is at maximum 1, the composite objects form a tree.

     If the composite object is deleted, its parts are also deleted. Syntax: solid diamond at the aggregating end.

     For example, a Beamer is part of LectureHall which is part of Building.

     

     Link to original

  Link to original

• Generalisation (UML Class)

  A generalisation is where:

  • characteristics (attrs / ops), associations, and aggregations that are specified for the super-class are passed on to its sub-classes
  • every instance of a sub-class is at the same time an instance of the super-class
  • sub-class inherits all characteristics, associations, and aggregations of the super-class except private ones
  • sub-class may have further characteristics, associations, and aggregations Generalisations can also be transitive.

  

  UML allows multiple inheritance, so a class may have multiple super-classes.

  

  Link to original

Link to original

Creating a Class Diagram

It’s not possible to completely extract classes, attrs, associations from a natural language text automatically. In general, we follow some guidelines for making class diagrams:

• nouns indicate classes
• adjectives indicate attribute values
• verbs indicate operations

Example: Library Management

The library management system stores users with their unique ID, name and address as well as books with their title, author and ISBN number. Ann Foster wants to use the library.

graph {
	node [shape=record]
 
	Book [label=<{<b>Book</b> <br align="left"/>| + title: String<br align="left"/>+ author: String<br align="left"/>+ ISBN: int<br align="left"/>}>]
 
	User [label=<{<b>User</b> <br align="left"/>| + ID: int<br align="left"/>+ name: String<br align="left"/>+ address: String<br align="left"/>}>]
}

From Object to Class

Individuals of a system often have identical characteristics and behaviour. A class is a construction plan for a set of similar objects of a system. Objects can similarly be drawn in the class diagram.

Association vs. Regular Class

Example: Institute Class Diagram

Given the following specification, we can construct a class diagram:

• “There is a distinction between research and administrative personnel”
• “A university consists of multiple faculties which are composed of various institutes.”
• “Each faculty is led by a dean, who is an employee of the university.”
• “Research associates are assigned to at least one institute.”
• “Furthermore, research associates can be involved in projects for a certain number of hours.”
• “Some research associates hold courses. Then they are called lecturers.”

Consistency Rules

Consistency Rules (UML Class)

The following consistency rules should be followed:

• no two attributes with the same name in a class
• no attributes and roles with the same name
• no two associations from one class with the same role names at their other ends - even if they end at different classes

Link to original

Configuration Management

Configuration Management

Configuration management (CM) is concerned with the policies, processes and tools for managing changing software systems. It is useful as software systems are constantly changing during development and use, it is used as it is easy to lose track of what changes and component versions have been incorporated into each system version. CM is essential for team projects to control changes made by different developers.

There are multiple activities in CM:

• Version management

  Version management: keeping track of multiple versions of system components and ensuring that changes made to components by different developers do not interfere with each other.

  Link to original

• System building

  System building: process of assembling program components, data and libraries, then compiling these to create an executable system.

  Link to original

• Change management

  Change management: keeping track of requests for changes to the software from customers and developers, working out the costs and impact of changes, and deciding the changes that should be implemented.

  Link to original

• Release management

  Release management: preparing software for external release and keeping track of the system versions that have been released for customer use.

  Link to original

Link to original

Developer Lifecycle

Agile development where components and systems are changed several times per day, is impossible without using CM tools. The definitive versions of components are held in a shared project repository and developers copy these into their own workspace.

Developers make changes to the code then use system building tools to create a new system on their own computer for testing, once they are happy with the changes, they return the modified components back to the project repository.

Development phases

Development phase

A development phase is where the development team is responsible for managing the software configuration and new functionality being added to the software.

Link to original

System testing phase

A system testing phase is where a version of the system is released internally for testing, no new system functionality is added. Changes made are bug fixes, performance improvements, and security vulnerability repairs.

Link to original

Release phase

A release phase is where the software is released to the customers, new versions of the released system are developed to repair bugs, vulnerabilities and to include new features.

Link to original

Multi-version systems

For large systems, there is never just one ‘working’ version of a system. There are always several versions of the system at different stages of development. There may be several teams involved in the development of different system versions.

Link to original

Terminology

• Baseline

  A baseline is a collection of component versions that make up a system. Baselines are controlled, which means that the versions of the components making up the system cannot be changed. This means that it is always possible to recreate a baseline from its constituent components.

  Link to original

• Branching

  Branching is the creation of a new codeline from a version in an existing codeline. The new codeline and the existing codeline may then develop independently.

  Link to original

• Codeline

  A codeline is a set of versions of a software component and other configuration items on which that component depends.

  Link to original

• Software configuration item

  A software configuration item is anything associated with a software project (design, code, test data, document, etc.) that has been placed under configuration control. There are often different versions of a configuration item. Configuration items have a unique name.

  Link to original

• Mainline

  Mainline is a sequence of baselines representing different versions of a system.

  Link to original

• Merging

  Merging is the creation of a new version of a software component by merging separate versions in different codelines. These codelines may have been created by a previous branch of one of the codelines involved.

  Link to original

• Release

  A release is a version of a system that has been released to customers (or other users in an organization) for use.

  Link to original

• Repository

  A repository is a shared database of versions of software components and meta-information about changes to these components.

  Link to original

• Version

  A version is an instance of a configuration item that differs, in some way, from other instances of that item. Versions always have a unique identifier.

  Link to original

• Workspace

  A workspace is a private work area where software can be modified without affecting other developers who may be using or modifying that software.

  Link to original