CPSC 3720 - DAY 17
MARCH 1, 2017

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

OBJECT DESIGN
-------------

	Have system design
	Lower level design
	Focus on objects
	How will this be implemented?
	4 activities
		Reuse
		Interface Specification
		Restructuring
		Optimizaiton
SPECIFICATION
-------------

	We identified objects in System Design
	Now we need to define them
		List all attributes
		List all methods
	Have some idea already, need to refine
	Attributes have a name and a type
	Also (optional):
		Multiplicity
		Visibility
		Default value
		Other property
	Denoted by
	<visibility><name>:<type>[<multiplicity>] = <default>{<other>}

MULTIPLICITY OF ATTRIBUTES
--------------------------

	N - exact number
		0, 1, 2
	N..M - exact range
		0..1,1..5, etc
	* - 0 or more
		* can be used in a range
		1..* is 1 or more
	In code, multiplicity is usually handled by collections

VISIBILITY
----------

	Indicates private
		Only avaliable to the class itself
	# indicates protected
		Available to the class itself and any subclasses that inherit
		this class
	+ indicates public
		Available to anyone
		Not common for attributes
	~ indicates package
		Available to other objects in the same package

OTHER PROPERTY
--------------

	Any sort of constraint that you can think of
	{readOnly}
	{Ordered}
	{Unordered}
	{Unique}
	{NonUnique}

SIGNATURES
----------

	Signatures correspond to methods/operations of the object
	Signature contains:
		Visibility
		Name
		Parameter types
		Return types
	Denoted with
	<visibility><name>(<parameter types>):<return type>{<property>}

CLASS DIAGRAMS
--------------

	Class diagrams are arguably the most common UML Diagram
	They describe the classes used in the sytem
	They will be mapped directly to code
	They include 3 fields:
		Name of the class
		Attributes
		Operations/Methods

	+-------------------------------------------------------+
	|	Customer					|
	+-------------------------------------------------------+
	| - Name: String[1]					|
	| - Address: String[1]					|
	| - City: String[1]					|
	| - State: String[1]					|
	| - ZipCode: int[1]					|
	+-------------------------------------------------------+
	| + getMailingAddress(void):string			|
	+-------------------------------------------------------+


INTERITANCE
-----------
	
	+-------------------------------------------------------+
	|	Customer					|
	+-------------------------------------------------------+
	| - Name: String[1]					|
	| - Address: String[1]					|
	| - City: String[1]					|
	| - State: String[1]					|
	| - ZipCode: int[1]					|
	+-------------------------------------------------------+
	| + getMailingAddress(void):string			|
	+-------------------------------------------------------+
				^
				|
				|
				|
				|
	+-------------------------------------------------------+
	|	CorporateCustomer				|
	+-------------------------------------------------------+
	| - CreditLimit: double[1] = 0 {Nonnegative}		|
	| - Representatives: Employee[1..*]			|
	+-------------------------------------------------------+
	| + addRep(Employee):void				|
	+-------------------------------------------------------+


ADVANCED NOTATION
-----------------

	Static Attributes and Operations
		Attributes or operations that apply to the class, rather than
		the instance of the class
			Helpful for the utility objects
		Noted by underlining the operation or attribute
	Derived properties
		An attribute of the object conceptually, but not stored in
		memory
		A property that could be easily calculated
			For instance, Age is derived since it depends on the
			birth date and the current date
		Noted by adding / to the beginning of the name

GENERAL NOTES
-------------

	Not every UML diagram will include all of this information
	Object Association diagrams leave information out
	Often times, you have a diagram that specifies each class individually
		On future diagrams, you just include the name of the class
		Then reference the individual class diagram for specifics
	Remember, you can just use UML for communication, so some information
	may be left off it is irrelevant
		ex. getters and setters when talking to another software
		engineer

DESIGN BY CONTRACT
------------------