# OOAD Lab 6, 7, 8 (04/13)
###### tags: `OOAD`

---

[TOC]

---

## 6. Source Code Quality
-
- 軟體有**抽象**的本質 (Software has essence of being abstract)
- 軟體有**看不到**的本質 (Software has essence of being invisible)
- Not easy to evaluate the progress and quality of programs
- 軟體有**難以描述**的本質 (software has essence of being hard to describe)
- 請問軟體開發有**藝術**的成分在 (software has essence of art)
- 軟工的研究顯示：**高手與庸手的表現有極大的差異，而且往往是一個數量級的差異** （an order of magnitude, 10^1)
- 另外一個研究顯示：**成為高手與庸手與年資經驗沒有絕對關係**
- **Code Review**:A process to check and examine submitted code
- Before the integration (sometimes called code inspection)
- After the test (mostly is called code review)
- **Art vs. Science**:
- **ART**: no objective criteria
- **Science**: based on objective criteria
- Repeatable experiments
- Describable by explicit formalism such as maths
- **Typical symptoms of bad code**:
- **Difficult to understand**
- **Difficult to change**
- (changing at one place results in changes in many other places)
- **Hardwire the solutions**
- (for example, instead of coming out a nice algorithms and data structures, many if is used)
- Source code is **tightly coupled** because the **excessive use of global variables**.
- Poor design that is **difficult to extend.**
- **Good code**:
- **Clean and simple interface, replaceability, modularity, composablity**
- Their importance is not obvious in Software development, particularly if you never has chance to maintain a software
- **Coupling**:
- **Most software engineering methods (e.g., OO) focus on create beautiful design** so that:
- Change one thing does not involving changing many other things
- Replace/substitute one thing does not involving modifying many other things
- Extend one thing does not involving rewriting many other things
- High coupling is bad, We pursuit low coupling
- **OO is a technique to decouple the system architecture**
- **Why writing low-coupled source code is not as easy as other engineering?**
- **source code is not geometric related that you can judge from your eyes**
- **bad code smell**:
- No formal definitions and descriptions
- Not easy to explain why
- **Spaghetti Code**:
- an undocumented piece of software source code that cannot be extended or modified without extreme difficulty due to its convoluted structure
- rediscovery
- **Lasagna code**:
- Lasagna code is used to describe software that has a simple, understandable, and layered structure.
- Lasagna code, although structured, is unfortunately monolithic and not easy to modify.
- An attempt to change one layer conceptually simple, is often very difficult in actual practice.
- **Ravioli code**:
- In ravioli code, each of the components, or objects, is a package containing some meat or other nourishment for the system; any component can be modified or replaced without significantly affecting other components.
- The ideal software structure is one having components that are small and loosely coupled; this ideal structure is called ravioli code.

## 7. Database Design and Normalization
- Actually there is a very deep bounding between OO and Database
- **Edgar F. Codd**: The Father of relational database
- Concepts of Relational Database:
- Table, Relation
- Row, Record, Tuple
- Column, Attribute
- Field
- Primary Key, Foreign Key
- the problem of the amateur’s database design:
- This structure does not allows our database to answer **any query** that could possibly be dreamed up against that data.
- The **“Un-normalized”** structure that mimicked the report will have problems, down the line a few months or years
- **“That most dreaded of all database phenomena, Unanticipated Queries”**
- **Normalization**:
> to make sure that each database table carries only the attributes that **actually describe What is needed**.
- **eliminate redundant data**
- **ensure data dependencies**
- **Normal Forms**:
> a series of guidelines for **ensuring that databases are normalized**.
- **1NF**:
- **Eliminate duplicative columns** from the same table.
- **Create separate tables for each group of related data** and **identify each row** with a unique column or set of columns (the primary key**).
- **2NF**:
> each **nonkey attribute** in the relation must be **functionally dependent (in business logicals) upon the primary key**.
> *(not only functionally dependent on other nonkey attribute)*
- Meet all the requirements of 1NF.
- **Remove subsets** of data that apply to multiple rows of a table and **place them in separate tables**.
- **Create relationships** between these new tables and their predecessors **through the use of foreign keys**.
- **3NF**:
> No dependencies on nonkey attributes
- Meet all the requirements of 1NF and 2NF.
- **Remove columns that are not dependent upon the primary key**.
- Database designers should always keep in mind the **tradeoffs between higher level normal forms and the resource issues** that complexity creates.

## 8. Data-Oriented Models
- **Entity-Relationship Diagram (ERD)**:
> the first systems analysis tool to focus on **DATA** and **How it is Linked and Organized**.
> It was from this that objects then evolved.
- Chen's two contribution:
- The Entity-Relationship **Principle**, and
- The Entity-Relationship **Notation**.
- These further issues were also investigated by Chen and others:
- **E-R models** for database design
- The **significance of the data** of an enterprise
- **Data as a corporate asset**.
- The **stability of the data** of an enterprise
- **The Entity-Relationship Principle**:
- An **Entity Type** ***(<---> Class)***:
- **class or category** expressing the **common properties** that allow a number of entities to be treated similarly.
- A **Data Entity** ***(<---> Object)***:
> Webster: An **entity** is ***“something that has separate and distinct existence”***
- some**thing** that has separate and distinct existence **in the world of the users** and is of interest to the users in that they need to keep data **about** it in order to do their job.
- An **Occurrence** ***(<---> instance)***:
- An individual Customer or Product or Sale or Call or Artist is then an **Occurrence of the Entity Type**.
- **Attributes**:
- the **data elements** carried by an entity that describe it and record its state.
- the things we need to know **about** an Entity.
- **Associations**:
- the **interaction** of two entities and is represented by a **verb**.
- The purpose is to provide access paths to the data.
- **E-R models for database design**:
- For database design:
- Each **Entity Type** ***(<---> Class)*** becomes a **file** or **table**.
- Each **Attribute** becomes a **field** (i.e., a **column**)
- Each **Association** becomes an **access pathway** (i.e., a **foreign key**)
- **絕大部分 programming language 的發明都是為了要解決 software engineering 的問題**:
- **FORTRAN, BASIC**: GOTO
- **PASCAL**: 結構化
- **ADA**:
- spec: C++ .h 定義 class
- implementation: C++ .cpp
- **Smalltalk**: OO
- Xerox 發明
- **The Stability of Data**:
- as long as we stay in the **same business** there will be very **few new entities**.
- The Data modeler’s Creed: ***Data is the Centre of the Universe***
- **The Entity-Relationship Notation**:
- **UML** is now the standard notation in the object world
- We use UML to draw ERD
- **Entity**:
- **Attributes**:
- Primary key first, marked with an asterisk
- **Associations**:
- **Multiplicity** *(cardinality)*:
- Multiplicity is **the number of occurrences** of each entity type that can be involved in an association.
- Multiplicity is **one (straight line)** or **many (asterisk)** below each end of the line.
- **Many-to-Many ---> lack of normalization**