## 3. Models
### 3.1 Motivation
* Purpose is to reduce complexity
* built by abstraction of existing objects and defining relevant relation between elements
* equivalence classes can be formed

**Abstracting** a problem can lead to find a solution more easily.

The **product concretization model** uses three layers of abstraction

### 3.2 Function Models

* A **function** states the action of a system upon an element through a **input-output relationship**, like $$y=f(x)$$

* A **function** can also be a **desired input-output relation**, like the steering wheel which must transmit steering commands

* can be modeled in a **function model**

Can be visualized by:

* *Words*: for interdisciplinary team exchange
* *Graphics*: Within a team in common language
* *Graphical description*: Within experts

* Can be **flow-oriented** or **relation-oriented**

### 3.2.1 Flow-oriented Function Modeling

> Fact sheet - Flow-oriented Function Modeling
> 1. Input:
> 	* Design goal
> 	* Requirements
> 2. Output:
> 	* complete model of important functions
> 	* design scheme
> 3. Procedure:
> 	1. Define the starting and end state of your processed object
> 	2. Find functions which are necessary to get from the starting point to the desired end state:
> 		* After defining a function write down the new state of your object and define the next function using this state as an input
> 		* Try to formulate your functions as solution neutral as possible
> 	3. When you have reached your final state make sure that your process is complete.
> 	4. Are there harmful functions which need to be addressed?
> 	5. Think about energy and information flows and how are those functions connected.
> 	6. Make a legend and explain all symbols you have used.
> Situation:
> * Early stages of PD process
> lack of understanding the problem

### 3.2.2 Relation-oriented Function Modeling
* Functions are differenced by useful and harmful functions
	* This is visualized by a rectangle with a black edge (for harmful functions) or no black edge.
	* relations between the functions can either be:
		* is required for: arrow with no dotted line
		* causes: arrow with dotted line
		* was introduced to avoid: arrow with circle head, not dotted
* can be developed by systematically questioning the considered technical system
* existing solutions can be used as a starting point

Goal:
* Understanding the technical problem
* Derivation of problem formulations from the function model

> Fact Sheet Relation Oriented Function Modeling
> Input:
> * Design goal
> * Requirements
> Output:
> * Complete model of important functions
> * Solution-neutral
> * Basis for finding solutions
> Situation:
> * Early Stages of product development process
> * Improvement of existing products
> * Lack of understanding the problem
> Procedure:
> * Question system and derive functions
> * Ask if functions itself cause or require useful or harmful functions
> * Use suitable functions to avoid harmful functions

### 3.3 Graphs and Models
#### 3.3.1 Graphs

* A graph is a set of **elements** (also vertices) with a set of **relations** (also edges, arcs) between pairs of these elements.
	* Possible element types are e.g. Functions, requirements, CAD sketches, ...
	* Possible relation types can be undirected: e.g. Spatial or related to communication or directed, like logical relations, e.g. "requires", "contains"
* graphs can be directed or undirected
* direction often expressed by position
* A **tree** is a graph in which any two vertices are connected by exactly one path
* A **polyhierarchy** can be represented by a directed graph without cycles along directed edges
* A **matrix** is a rectangular array of expressions arranged in roes and columns
* Every graph can be represented by a matrix: input in rows output in columns

#### 3.3.2 Types of matrices

1. Intra-Domain: relations between elements belonging to the same type
2. Inter-domain: -"- of different types
3. Combinations: inter and intra domain

### 3.4 Design Structure Matrices

> Fact Sheet Design Structure Matrices
> Input:
> * Elements of the same type, e.g. organization/ product architecture
> * Relation between those
> Output:
> Relation matrix
> Situation:
> * Analysis of existing product
> * Need to identify important elements
> Procedure:
> * Decompose: Identify relevant elements
> * Document relations
> * Analyze: Identify structural patterns
> * Improve system if needed

#### 3.4.1 DSM Classification

* To detect subsets with internal dependencies
* Basis for modularization strategies
Targets:
* To minimize external interactions
* To Maximize internal interactions

* High connectivity systems need algorithmic support
* partially applicable matrices if clusters are overlapping

→ Ball pen: Button and Push element form back push element