UML

UML

• A family of visual languages to describe systems (not necessarily but usually software systems).
• A UML is a modeling language and not a method. A method = modeling language + process.
  • A modeling language is a graphical notation that methods use to express design.
  • The process is the methods advice on what steps to take in doing a design.
  • The modeling language is the most important part of the method - key for communication as it expresses design.
• The fundamental reason to use UML is that it allows communication of concepts clearer than the alternatives (natural language and code).
  • Natural language is too imprecise and code is too detailed. UML is a middle ground - has precision and can be used to highlight important details.
• UML is not a research project - it is a collection of practices gained through industry usage.
• A system can be viewed through different perspectives. E.g. a house can be viewed differently by the landlord, tenant, plumber, architect, tax officials view.
• In UML, different kind of diagrams allow us to have views about the system in different ways.
  • e.g. use case diagram represent system functions from the user perspective, sequence diagram is representation of objects and their temporal interactions etc.

Classes

• A class is an intentional description ( a blueprint) of set of objects.
• A description can be thought of as : 1) a specification and 2) a realization. In UML practice, these are usually combined.
• Class diagrams represent a set of classes, interfaces, collaborations and their relationships.
• They offer a static conceptual view of the system. Each class must be a concept in the users mind, rather than diagrams of pieces of data.
• Dont make a class model a data model, class models should be responsibility oriented rather than data oriented.

Relations between classes

• Association : Represents a connection between instances of the classes. (not between the classes themselves). By default an association is bidirectional.
• As in a representation of the references to other instances that an instance has.
• A role is attached to the end of an association. The role also has a multiplicity. Make sure both of these are represented.
• For e.g. a Manager and an Employee's association role can be "manager" with multiplicity of 1 on the Manager end (each Employee has 1 manager) can and 1..* (each manager has 1 or more employees) on the Employee end.
• Navigability: A direction can be imposed on an association. This means that the destination object will have a direct reference from the source object, but not the other way around.
• for e.g. a User object can have references to Password objects, but not the other way around, since it will be a security risk.

• Aggregation : Represents asymmetric bidirectional semantic connections.
• Represents a stronger coupling between classes. for e.g. a company is made up of a number of departments.
• Generally for relations as whole and part, master and slave, composed and composing.
• Notation : a white diamond at the aggregation point. for e.g the white diamond will be at the end of the company.

• Composition : Represents a stronger form of aggregation.
• Maximum multiplicity of 1 on the aggregate side : An object may be part of only 1 composite at a time, whereas it can be part of more than 1 aggregate.
• Automatic propagation of destruction. If a composite is destroyed, so will be its parts.
• For e.g. a relation between a Engine and Pistons. If the engine is destroyed, so are the pistons.
• Represented by a filled in diamond at the end of the aggregation.

• Generalisation : Represents an IS-A relationship.

• Dependency : A weaker relationship than association.
• TODO : Look this up for more information.

Packages

• Used for model structuring - way to group classes.
• Corresponds to a Java Package.

Stereotypes

• A stereotype extends the UML Vocabulary.
• Enables us to create new kinds of basic elements deriving from existing elements in the UML Metamodel.
• e.g. modeling Java Exceptions can be turned into basic elements in the model.
• TODO: come up with a good example.

Notes

• Useful for comments. Belongs to the view, not the model.
• Since a note doesnt belong to the model, it can be stereotyped as a constraint.

Constraints

• A conditional relationship between model elements.
• Expressed in OCL or in natural language.
• TODO: Add a meaningful example.

Objects

• Represent run-time system behaviour.
• Use object diagrams.
• An object diagram is like a class diagram, except it is named differently. e.g. ObjName:Class

• Three diagram types of object:

Object Diagram

• Represents the structure of objects at run time, since object behaviour is dynamic, this is effectively a snapshot.
• Also represent the links between the objects.
• The links are instances of the class associations.
• An object diagram is an instance of a class diagram.

Communication Diagrams

• Sequence and Collaboration diagrams are interchangeable - they can be transformed into one another.

Sequence Diagram

• focus on the chronological ordering of messages.

• It is a temporal vision of an interaction : It is for a particular interaction or a scenario.
• Often used to represent a use case scenario.
• A filled in arrow represents a synchronous call.
• A blank arrow represents a asynchronous call.

Collaboration Diagram

• Focus on the structural organization of the elements sending the messages.
• Represents a collaboration between roles. Focuses on the structure, not that much on the time.
• Time ordering can be shown by numbering notations.

Statechart: Represent state automata

• Activity Diagram: Special kind of statechart - describing series of activities within systems.
• Important in system function modeling - focusing on control flow in objects.
• The fork - join concept is important. Fork can be used to represent concurrent activities.

Component and Deployment Diagrams

• Component Diagram:
• A component is a set of classes, interfaces or collaborations
• A component diagram represents the organization and dependencies between the components.
• [TODO] Give a good example.

• Deployment Diagram:
• Deployment diagrams show the static deployment view of an architecture. They are linked to component diagrams.
• [TODO] Give a good example.

Use Case Models

• See REQE's Use Case Models Page.