Les over het design van UML diagrammen zoals Component en class diagram.

Bij deze les had de leraar er twee youtube video’s bijgezet.

Downloads

Powerpoint
Opdracht game description
Uitwerkingen cardgame RPG

Video’s

Video 1 (Legt ook interfaces uit):

Video 2:

Lesvideo:

Aantekeningen

Review of Analysis 3

Class Notations
A class in a class diagram looks like something below and has some things in it. It has attributes, operations and visibility. The operations are in the lowest part, the attributes are above that in the middle part and the name of the class is in the top part. You can see the visibility in front of the operations and the attributes:

  • +: public
  • #: protected
  • ~: package
  • -: private

Class

Dependency vs Association

Association:

  • Object from A has an attribute of type B.
  • Object from A has access to the reference of B during its life-time.
    Association

  • Aggregation:
    • Special type of association (whole-part relation) indicating that a class owns objects of another class.
    • Aggregate may share its parts. So in the case below BlogAccounts shares the part blogs with Author.
      • When the author gets deleted, the blog will live on.

    aggregation

  • Composition
    • Composite owns its parts.
    • Lifetime of parts are related to the lifetime of composite.
      • A part only belongs to one composite at a time.
      • in the picture below, windows consists of a slider, a header and a panel. When window gets deleted all the parts will be deleted too.

    Composition

Dependency:

  • An object from A does not have an attribute of type B.
  • An object from A has access to an instance of temporarily during its life-time.

Dependency

Abstract classes and interfaces

Abstract class:
Abstract classes are classes without any implementation. All the implementation of the operations are implemented by subclasses. So in the picture below, polygon inherits the class sjape which means that it now contains the class void and it has a point which is the center.
AbstractClasses

Interface:
A sort of class which contains properties which are externally visible, but have no implementation. Interface has no direct instance. Classes that inherit an interface must implement(realize) all the properties which are in the interface.
interface

Realization:
Implementation of an interface in another class.
realization

N-ary Relations

Unary-relation
Relation between two of the same entities. So an employee can have a relation with another employee because it is his boss. Same entity (employee) but they reference eachother.
unary

Binary-relation
When two entities participate.
binary

Ternary-relation
When three entities participate.
ternary

Component diagrams

Component diagram is in the 4+1 view the development view. This is the view which is needed for the developer to see what components are used in the program.
component

Component
Component is an encapsulated, reusable and replaceable part of the system. You can link classes to make components and you can link components to make larger components. Components can be parts of a system that have a functionality and can be reused in different places in the program. changed in a component should not affect other components. Communication between components should work via interfaces.

In the lower part of the image you see the artifact of the component. In the middle part you see the provided interfaces and the required interfaces. And in the upper part you see the name of the component.

The artifact is how your component is going to be placed in the system.

The interfaces in the component is the way the component talks to other components.

component2

In the picture below you see how you should connect two components to each other when they are talking to each other via interfaces. This is one way to do it.

ballsAndSockets

The other way is to use stereotypes. Way more time intensive to make, but you can understand it without knowing UML.

StereotypeComponent

Relations

Depends on: depends

Example example