UML - Revision history

Suhridk: /* Association */

2014-02-15T08:32:34Z

Association

2014-02-15T08:31:25Z

Association

2014-02-15T08:26:44Z

Association

2014-02-15T08:16:24Z

Association

2012-01-08T00:22:33Z

Operations

2012-01-07T12:34:13Z

Generalization

2012-01-07T12:27:58Z

Generalization

2012-01-04T02:31:56Z

Association

2012-01-03T21:16:52Z

Deployment Diagrams

2012-01-03T21:15:27Z

Component and Deployment Diagrams

@@ Line 35: / Line 35: @@
 * Multiplicity specifications can be on both sides.
 * Students must apply somewhere and may not apply to more than 5 colleges. No college takes more than 20,000 applications.
-[[File:UML_Multiplicity.png]]
+[[File:UML_Multiplicity.PNG]]
 * 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.

@@ Line 33: / Line 33: @@
 * 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.
 * C1 --- (m..n) C2 : Means that ''each object'' of class C1 is related to at least m and at most n objects of class C2. Default multiplicity is "1..1"
 * 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.

@@ Line 32: / Line 32: @@
 * A role can be attached to '''each''' 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.
-* C1 --- (m..n) C2 : Means that ''each object'' of class C1 is related to at least m and at most n objects of class C2.
+* C1 --- (m..n) C2 : Means that ''each object'' of class C1 is related to at least m and at most n objects of class C2. Default multiplicity is "1..1"
 * 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.

@@ Line 32: / Line 32: @@
 * A role can be attached to '''each''' 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.
 ==== Association Class ====

@@ Line 90: / Line 90: @@
 * At a specification level, operations corresponds to public methods on a type.
-* '''Difference between an operation and a method'''
+=== Difference between an operation and a method ===
 * An operation is the procedure call on an object, and the method is the body of the procedure.
-* Makes a difference in polymorphic behavior. Consider a supertype with two subtypes each overriding supertypes foo operation - then we have one operation and three methods that implement it.
+* Difference exists because of run time binding and polymorphic behaviour.
 = Packages =

@@ Line 68: / Line 68: @@
 *** This is implementation inheritance. UML specialisation.
 *** Often a class will specialise a superclass, which is what the subclass is.
 ** Signing up to a contract. This is interface inheritance. UML Realisation.
 *** Subclass will realize a number of interfaces - how it can behave in a number of situations.
 === Dependency ===

@@ Line 63: / Line 63: @@
 ** Specification - the interface of the subtype conforms to the interface of the supertype.
 ** Implementation - Normally associated with inheritance in programming languages - but '''need not''' be. Subtyping can also be implemented through delegation.
 === Dependency ===

@@ Line 165: / Line 165: @@
 * Deployment diagrams shows the physical relationships among software and hardware components in the delivered system.
 * Each node on a deployment diagram respresents some kind of computational unit.
 = Use Case Models =

@@ Line 153: / Line 153: @@
 * The fork - join concept is important. Fork can be used to represent concurrent activities.
-= Component and Deployment Diagrams =
+= Component Diagrams =
-* Component Diagram:
+* A component is a set of classes, interfaces or collaborations. A component can represent a package, source files, DLL's, binaries etc.
-* A component is a set of classes, interfaces or collaborations
+* A component diagram represents the organization and dependencies between the components. Shows the various components in a system and their dependencies.
-* A component diagram represents the organization and dependencies between the components.
+* A component may be split up into multiple interfaces.
-* [TODO] Give a good example.
+* The dependencies are between interfaces.
-* Deployment Diagram:
+= Deployment Diagrams =
-* Deployment diagrams show the static deployment view of an architecture. They are linked to component diagrams.
-* [TODO] Give a good example.
+* Deployment diagrams shows the physical relationships among software and hardware components in the delivered system.
 = Use Case Models =