---
# System prepended metadata

title: 'OOAD Lab 6, 7, 8 (04/13)'
tags: [OOAD]

---

# 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**:
        ![](https://i.imgur.com/qocEMYD.png)
    - **Attributes**:
        ![](https://i.imgur.com/reQyCqY.png)
        - Primary key first, marked with an asterisk
    - **Associations**:
        ![](https://i.imgur.com/DR98wMe.png)
    - **Multiplicity** *(cardinality)*:
        ![](https://i.imgur.com/VRcWqxe.png)
        ![](https://i.imgur.com/7O8UPCu.png)
        - 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**



