CPSC 3720 - DAY 11
FEBRUARY 8, 2017

================================================================================

SYSTEM DESIGN
-------------

Associations
	.show a relationship between two or more objects
	.Indentifying associations has advantages
		.Makes the relationships between objects explicit
		.Enables the developer to disover boundry cases with associated
		links.
	.Boundry cases are exceptions that must be clarified within the model
		.Anonymous reports
		.Multiple reports

Properties of associations
	.Name(writes)
	.Role - identifies the function of each class with respect to the 
	association (author, document)
	.Multiplicity at each end
		.* = 0 or more
		.1 = exactly one
		.1..* = one or more

	+-----------------------+ 1	writes	       *+---------------------+
	| FieldOfficer		|<--------------------->| Emer. Report	      |
	+-----------------------+			+---------------------+
		author					document

Identifying Associations
	.Heuristics
		.Examine verb phrases
		.Name associations and roles precisely
		.Use qualifiers as often as possible to identify namespaces and
		key attributes
		.Eliminate any assocation that can be derived from other 
		associations
		.Do not worry about multiplicity until the set of associations
		is stable
		.Too many associations make a model unreadable, eliminates 
		redundancies

		author					document
	+-----------------------+ 1	writes	       *+---------------------+
	| FieldOfficer		|<--------------------->| Emer. Report	      |
	+-----------------------+			+---------------------+
		\						  / 1
		 \						 /
		  \ 1						/ triggers
	reports	   \					       /	
		    \ +-------------------------------------+ /
		    1 |		Incident		    | 1
		      +-------------------------------------+

Aggregates
	.associations that denote a whole-part relationship
	.Compostition aggregation indicates that the existence of the part 
	depends on the whiole.
		.A county is always part of a state.
		.A township is always part of a country.
		.Denoted with a solid diaond
	.Shared aggregation indicates the whole and part can exist indpenedently
		.Fire engine and fire station
		.Denoted with a hollow diamond

Subsystem Decomposition
	.Now that we have our objects, we can begin subsystem decomposition
	.You should see natural grouing
	.Heuristics
		.Assign objects identified in one use case into the same 
		subsystem
		.Create a dedicated subsystem for objects used for moving data
		among subsystems
		.Minimize the number of associations crossing system boundries
		.All objects in the same subsystem should be functionally
		related.

Services
	.A subsystem is characterized by the services it provides
	.A service is a set of related operations that share a common purpose
		.Notification subsytem
			.Defines operations to send notifications
			.Those operations are grouped into one or many services
	.Subsystem Inteface
		.Set of operations avaliable to other subsystems.
		.Includes parameters, return values
			.Types
	.System design focuses on defining the services provided by each sub-
	system.
	.Object Design will focus on the API
		.More refined version of the subsystem interface.

Assembly connecters
	.AKA Ball and Socket connectors
	.Use in subsystem diagrams

Interface design
	.Subsystem interface design is focuesed on the interface
		.Not implementation
		.No internal data structures
	.Minimizes the impact of future changes and revisions

Coupling
	.The number of dependencies between subsystems
	.Loosely coupled
		.Relatively independent
	.Strongly coupled
		.Highly dependent
		.High number of dependencies
	.You want your subsystems to be loosely coupled
		.Minimizes imput of changing one subsystem
		.Can use abstraction layers to do so.

Coupling vs. Complexity
	.By reducing coupling, we increase the complexity of the system
		.Added that abstract layer
	.It's a trade-off
	.It may be worth considering how likely that subsystem is to change.
	.Probably a good idea in that specific case.