mirror of
https://github.com/jackyzha0/quartz.git
synced 2025-12-24 05:14:06 -06:00
146 lines
3.9 KiB
Markdown
146 lines
3.9 KiB
Markdown
---
|
|
title: "11-class-diagrams"
|
|
aliases: Class Diagrams
|
|
tags:
|
|
- info201
|
|
- lecture
|
|
sr-due: 2022-05-05
|
|
sr-interval: 20
|
|
sr-ease: 250
|
|
---
|
|
|
|
[Class Diagrams](notes/11-class-diagrams.md)
|
|
|
|
e.g., 
|
|
|
|
|
|
|
|
## 1 Stereotypes
|
|
add further meaning to fields and methods
|
|
- e.g., << unique >>, << abstrat >>, << interface >>,
|
|
|
|
## 2 Packages
|
|
group classes together
|
|
break system to logical chunks
|
|
package diagram, a class diagram with nothing but packages
|
|
|
|
|
|
|
|
## 3 Associations
|
|
UML anaglogue of ERD relationsips
|
|
- multiplicity
|
|
- realtionshpa nd role names
|
|
|
|
PlUS
|
|
- naviagability --> instances of one class can pass messages to instances of another
|
|
- several differnt types, e.g., composition, aggregation, associateive classes
|
|
|
|
### 3.1 multuplicity
|
|
|
|
|
|
|
|
ERDsd effectively only do zero one many
|
|
UML can to any non negative integer
|
|
default is 1
|
|
|
|
### 3.2 association names
|
|
|
|
|
|
- usuallya verb phrase like "assings", "manages", "enrols in" ...
|
|
- more useful is conpetual level diagrams
|
|
- optional arrow head ()
|
|
|
|
### 3.3 Role names
|
|
|
|
|
|
At conceptual level, indicates role of class in association.
|
|
|
|
At implementation level:
|
|
- implies a field in class at opposite end
|
|
- should include visibility
|
|
- closely related to navigability
|
|
|
|
### 3.4 Navigability
|
|
|
|
|
|
specifies whether we can "navigate from one end of an association to another"
|
|
affects how we code access paths between objects
|
|
|
|
e.g.,
|
|
- loan instance can see loanitem instances it contains via private field items
|
|
- a loanitem instance can't see loan instance that contains it
|
|
- must alwasy include relevant role names
|
|
- no arrows = two arrows = bidirectional
|
|
|
|
#### 3.4.1 why not always bidirectional
|
|
|
|
- more complex code --> many references/collections to manage
|
|
- navigation paths are not all equally important
|
|
- e.g., "what items are in this loan" vs "what loans does this item appear in"
|
|
- determined by requrements and typical usage
|
|
- some classes are more "central"
|
|
- usually at the "one" end of accociations
|
|
- often represent transactional entities e.g., loan, sale, order
|
|
- navigability readiates outwards from them
|
|
|
|
there are exceptions as always e.g., patron <-> item
|
|
|
|
|
|
### 3.5 Aggregation
|
|
|
|
|
|
one class is made up of one or more other classes
|
|
container and content instances _can_ exist separately
|
|
usually implied by multiplicity and navigability
|
|
|
|
e.g.,
|
|
- computer is made u of several components
|
|
- library catalogue is made up of many items
|
|
|
|
|
|
### 3.6 Composition
|
|
|
|
|
|
stonger form of aggregation
|
|
container and content _cannot_ exist separately
|
|
usually implied by multiplicity and navigability
|
|
|
|
e.g.,
|
|
- building contains many rooms
|
|
- loan includes several items
|
|
|
|
- coicident lifetime
|
|
- multiplicity at least 1 at both ends
|
|
- deleting an containter must also delete all associated contents
|
|
- creating a container should also create some contents
|
|
|
|
|
|
### 3.7 Associative classes
|
|
|
|
|
|
|
|
- used for conceptual design
|
|
- similar to associative entities
|
|
- many to many relationship with additional independent fields
|
|
- resolved into class at implementation level
|
|
|
|
### 3.8 Specialisation generalisation
|
|
|
|
|
|
class inheritance
|
|
- e.g., book and disc are subclasses of (specialise) Item
|
|
- inherit all public fields and methods of superclass
|
|
- can add their own fields and methods
|
|
- Compare with specialisation of actors and use cases
|
|
|
|
## 4 Domain class model\
|
|
|
|
|
|
only modles the associations among concepts from problem domain
|
|
|
|
can be at conceptual level or implementation level
|
|
|
|
## 5 System class model
|
|
|
|
Models associations among domain objects and system components; implementation level only
|