---
# System prepended metadata

title: EE4001 Software Engineering Notes

---

# EE4001 Software Engineering Notes

## Unit 1: Introduction to Software Engineering 

### **Software**
* **Definition**: Computer programs and associated documentation 
    * Can be:
        * **Generic**: Wide range of different customers
        * **Customised**: Developed for single customers according to specifications
    * **New software** from
        1. Developing new programs
        2. Configuring generic systems
        3. Reusing existing software
### **Software Engineering**
* Application of engineering to develop quality software in a cost-effective way to meet the target objectives
    * Areas of application
        1. **Modeling**: Theory and methods for specifying software requirements & design
        2. **Development Methodology**
        3. **Security**: Implementation and auditing
        4. **Reuse**
        5. **Testing**: To see if specifications are met
        6. **Economics**: To estimate resources and costs od development
### **Software Process**
* **Definition**
    * Collection of activities
        * Each activity is **a set of actions**
        * Each action is defined by **a set of tasks**
        * End product is a work product
    * Comprises of the folllowing **5 activities**
        1. **Communication**: Project initialization and **requirements capture**
        2. **Planning** (of): Technical Tasks, Resources, Work Products, Work Schedule, Risk Analysis
        3. **Modeling**: requirements analysis, design
        4. **Construction**: coding, testing
        5. **Deployment**: Software delivery, Evaluation and Feedback
### <font color="red">**Software Process Model**</font>
* Gives a **Brief / Abstracted** view on how software is developed.
    * Prescriptive Models *(**Will be elaborated below**)*
        * Not specific to any software engineering approach
        * <font color="red">**Three Types**</font>
            * <font color="red">Waterfall Model</font>
            * <font color="red">Incremental Model</font>
            * <font color="red">Evolutionary Model</font> 
        * Chosen depending on environment, resources, objective etc. 
    * Agile Software Development *(**Will be elaborated below**)*


## Prescriptive Process Models


### <font color="red">**Waterfall Model**</font>
<span style="display:block;text-align:center">![](https://i.imgur.com/U8NEll9.png)</span>
- **Main Characteristics**:
    - 5 Phases are sequential
    - Each phase results in **1+ documents that are approved**
    - Next phases **doesn't start until the previous phase is completed**
- **Suitable** for:
    - Well-defined requirements
    - Adequate Resources
    - Project teams have good experience on system
    - System is not too large/complex
    - No urgency on any part of the system

### <font color="red">**Incremental Model**</font>
<span style="display:block;text-align:center">![](https://i.imgur.com/SBIQZQy.png)</span>
- **Main Characteristics**:
    - Rather than a single delivery - **the development is broken down into incremental stages**
    - Each increments delivers part of the required functionality
    - First increment develops the **CORE** product (Addressing the **basic requirements**)
    - Subsequent increments address modifications and additional functions
    - Different process models can be used for each increment (**Like process-within-a-proces**)
    - **Prioritise user requirements** and those with **highest priority** are included in **early increments**.
- **Suitable** for:
     - Requirements are reasonably well-defined
       - Maybe not as well defined as for Waterfall
       - Development process precludes a **purely linear process** 
       - Need to **provide some functionality first**, then **refine and expand** on that functionality in later releases.

### <font color="red">**Evolutionary Model**</font>
- Designed for products that change over time
- Iterative - so product is developed in more complete/accurate versions with each stage
- **Two submodels**
    - <font color="red">**Prototyping**</font>
            <span style="display:block;text-align:center">![](https://i.imgur.com/TK13Wie.png)</span>
        - **Process**
            - **Communication**
                - Define overall objectives, requirements
                - Identify areas where further definition is necessary
            - **Quick Plan**: Of prototyping iteration and modeling of *quick design*
            - **Quick Design**: Of prototype
            - **Full construction of Prototype**
            - **Delpoyment & Feedback**
                - Evaluation by customer/user on prototype 
                - Feedback used to refine requirements for product
            - **Each iteration occurs to tune the prototype to satisfy the customer's needs**
        - **Suitable** for
            - Small systems
            - User interface intensive 
            - Teams lack experience/expertise
    - <font color="red">**Spiral**</font>
            <span style="display:block;text-align:center">![](https://i.imgur.com/mhTKbCj.png)</span>
        - *Combines the iterative nature of prototyping and the systematic aspects of waterfall*
        - **Process**:
            - **Spiral space divided into 5 segments** (Each segment represents one key process)
            - **Circuit around the spiral represents the activity to be done**
            - **Each loop in the spiral represents one iteration**
            - **Anchor point defined at end of each phase** (Combination of work product and conditions are noted)
            - **Risks are explicitly assessed and resolved throughout the process**
        - **Suitable** for: 
            - Large systems with unclear requirements
            - Complex requirements
            - High risk cases (eg. Research Project, FYP on new Technology)

### Choosing a Model
- Depending on the requirements/situation
- Combining a number of models for a project
- Example
    - **Problem**: A Large System
        1. Reasonably well defined requirements
        2. Except a small user intensive part
        3. No manpower problem
        4. Overall system is not complex
    - **Solution**
        1. Use an incremental model 
            - Each increment is of moderate size
            - Part of the team that does not have **sufficient expertise** is in a separate increment (J)
        2. Develop each increment using Waterfall Model
            - But Team (J) is done using prototyping 
        - The overall solution uses **3 Prescriptive Process Models**

## Agile Software Development

### **What is Agility?**
- Rapid and adaptive response to change
- Effective communication among all stakeholders
- Drawing the customer onto the team
- Organize team so that it is in control of the work performed
- Fast and incremental delivery of the product

### **Agility**
- Encorages team structures that improves communication among developers and customers
- Importance given to raid delivery of operational software
    - Less importance to intermediate work products
- Can be applied to any software process
    - Team allowed to streamline tasks
    - Plan to eliminate non-essential work

### **Agile Process**
- Driven by customer descriptions
- Allows for short-lived plans
- Iteratibe development with emphasis on implementation
- Multiple increments with adaptive changes

## Unit 2: Structured Methods for Requirements Analysis

### Requirement Analysis
- **Data**: Information to deal with
- **Processes**: Tasks to perform
- **Traditional Techniques**
    - Data and processes are modeled separately and conceptually
    - Data modeling
    - Behavioural modeling (To model processes) 

## Entity-Relationship (ER) Modeling
- **Basic Principles**
    - Description from business viewpoint
        - Conceptual
        - Logical
    - Focus on data domain
    - To examine data independently from processing
    - Create model at customer's level of abstraction
    - Abstraction specifies which target aspects to focus on and which to ignore
- ER diagram describes data by **entity types** and relationships between them by **relationship types**

### <font color = "red">**Entity Type**</font>
- *Represents a collection of things that possess the same information in the target system.*
- Each *entity/ data entity/ instance* belongs to an entity type
- Each entity
  - Plays a necessary role (i.e. System will not function without it)
  - Can be uniquely identified (has a key)
  - Attributes (data items) describe each entity (characteristics)
- **Modeling**
    - <font color = "red">**Entity Type**</font>
        - **To model a type of information**
        - Eg. Info structure of suppliers or of a student
    - <font color = "red">**Attribute**</font>
        - **To model a property of information type**
        - Eg. Supplier Name
    - <font color = "red">**Instance of Entity**</font>
        - **To model an instance of information**
        - Eg. IBM is a supplier

### <font color = "red">**Relationship Type**</font>
- Collection of interactions between things modeled by entity types
- Relates one or more entity types
- Eg. "teach" relationship type represents *teaching interactions between teachers and students* (2 entity types)
- A teachers B -> **Instance of relationship type**
    - **Modeling of individual interactions**
- Diagrammatic Representation 
        - ![](https://i.imgur.com/coePh6x.png) 
        - ![](https://i.imgur.com/ALdbR0R.png)
            - Eg. At end F: *Each instance of entity type E is related to (min,max) number of instances in F*
            - Role: Define function that the entity type plays in the relationship type

### Building ER Diagrams
**Level 1**: Identify the data entities and model as entity types
**Level 2**: Identify interactions between data entities and model as relationship types
**Level 3**: Refine intial models and include attributes for entity types.

## <Font color = "red">**Data Flow Diagram (DFD)**</Font>
- For processes/ behaviour
    - To analyze requirements of the process
- **Characteristics / Principles**
    - Semi-formal operational specifications
        - System specified in terms of processing
    - DFD describes processes and the data acted upon (data flow) in DIAGRAMS
        - Computer-based modeling
        - Highest to lowest level
        - Immediate and intuitive
    - Information transformer 
        -  Input > Information transformer > Output
    - Data classified into:
        - Persistent Data: Stored in data repositories
        - Intermediate/Transient Data: Passed between sub-tasks
    - Functional Decomposition
        - Break down into a collection of functions/processes that interact with external environment
    - **Does not include control flow (sequence, selection and looping)**     
- **Representation**
    - ![](https://i.imgur.com/kUI9R7n.png)
        - **External Entity**
            - Producer or consumer of data (eg. person, device of sensor)
            - *Data must always come from and go to somewhere*
        - **Process**
            - Data/ Information transformer (Input to Output)
            - eg. computing,calculation (a task)
            - *Data is always processed in some way to achieve system function*
        - **Data Flow**
            - A piece of data (including intermediate data)
            - *Flows throughout the system*
        - **Data Stores**
            - Keeping Data repositories
            - For later access
        - Example
            - ![](https://i.imgur.com/xS3FWFt.png)
                - Guidelines
                    - **Hierarchical refinement** (Highest to lower levels)
                        - Higher level DFD defined as seprate DFD
                            - But must be consistent
                            - Lower-level DFDs must still be balanced
                            - Don't re-show higher level DFDs in the lower ones
                    - **Start with contect level diagram** **(Level 0)**
                        - All external entities shown here
                        - Whole system shown as a single process
                    - Construction
                        - ![](https://i.imgur.com/BySCrAc.png)
                            - **Step 1**: Physical DFDs: Describe existing system (eg. Name of person/etc who performs task)
                            - **Step 2:** Physical DFD transformed to DFDs for target system (**LOGICAL DFDs)
                                - eg.Describe function instead of person
                                - include enhancements to improve the system
                            - Higher to lower level
                                - Approx 1:5 expansion ratio for number of processes in each DFD
                                - All data flows and data stores defined in data dictionary
                                - Process specification for lowest-level DFD
                            - *EXAMPLE* (Unit 2 Slides 31 to 35)
                                ![](https://i.imgur.com/3RtXG2J.png)
                                ![](https://i.imgur.com/gaMV1uY.png)
                                ![](https://i.imgur.com/yxEAPTj.png)
                                ![](https://i.imgur.com/yPi9UTa.png)
                                ![](https://i.imgur.com/lcyV7MI.png)

                    - Data Dictionary
                        - Data specification
                            - For each data flow and data store
                            - Via a hierarchial combination of data items
                                - **Sequence +**
                                    - eg. A + B
                                    - indicates data item B after data item A
                                - **iterate ()**
                                    - eg. {Appointment}*
                                    - indicates the combination of multiple values of data item A together
                                - **Optional ()**
                                    - eg. employee information = ... + (car) + ...
                                    - indicates that the specified attribute is optional
                                - **Case [...|...|...]
                                    - eg. person is identifies by one method or the other [IC|FIN]
                                    - indicates can be one or the other of the combination
                        - Process specification
                            - For each lowest-level process
                                - Higher level processes are defined from the specifications of their member lower-level processes
                                - So higher level processes are not directly specified
                            - PSPEC (using Pseudocode)


### Requirements Analysis
- **FOR**
    - Specify operational characteristics
        - Conceptual processing needed to implement functions
    - Indicate software's interface with other system elements
        - All external interactions
    - Establish constraints
        - eg. Targets system that will operate on the environment
    - Allows tha analyst to
        - Elaborate on basic requirements
        - Build conceptual/ logical models without building physical system
- **Rules**
    - High level of abstraction
        - Model focuses on visible problems
        - No need for details like hardware, programming language, etc
    - Each element should provide insights into
        - **Information**: Data
        - **Function**: External interaction
        - **Behaviour**: Processing
    - Delay physical construction and non-functional aspects until design is complete
    - Minimize interdependency between different analysis components (coupling)
    - Keep it simple and useful for all stakeholders
- **Two methodologies**
    - Structured Analysis: Data and Process Modeling
    - Object Oriented Analysis


## Unit 3: UML Modeling I - Structural Modeling 

### UML
- Semi-formal language for modeling software problems and solutions
- Graphical oriented with text supplement

### Structual Modeling 
- For information and processes
    - Describe data and process together instead of separately
- Using class diagrams
    - Basic element is called **OBJECT**
    - Objects can be used for requirement analysis and for solution modeling

### OBJECTS
Abstraction of something in the problem domain
- **Reflecting**
    - Information/Data
    - Tasks it can perform
    - Tasks that can be performed on it
- **Specified by**
    - **STATE**
        - Condition of an object (at any moment) affecting its behaviour
        - Described by attributes
    - **BEHAVIOUR**
        - How it responds to events
        - Described by operations
    - **Relationships**
        - How objects in a system interact
        - Similar to relationship types in ER diagrams
- Example

| Object              | Behaviour                          | State                         |
| ------------------- | ---------------------------------- | ----------------------------- |
| A student           | Register subject, select FYP, etc. | First year, second year, etc. |
| A shirt             | Shrink, stain, rip                 | Pressed, dirty, worn          |
| A sale              | Earn loyalty points                | Invoiced, cancelled           |
| A bottle of ketchup | Spill in transit                   | Unsold, opened, empty         |

### **CLASS**
- Specify a collection of objects that have identical properties
- Each Object is an instance / object of the class
- In each class, specify
    - Attributes
    - Operations

### **CLASS DIAGRAM**
Consists of CLASSES and RELATIONSHIP TYPES

#### Relationship Types
- **Association**
    - *Interactions between different objects*
    - **3 Types**
        - Binary (Relate 2 classes)
            - ![](https://i.imgur.com/z1ydGmA.png)
                - Each person works for one company
                - Each company has 0 to many employees
                - Interaction has 2 attributes
                    - Salary
                    - Job title
                - Unit 3 Slide 18
                    - ![](https://i.imgur.com/EoOqCUc.png)

                - INSTANCE: If there are 3 people, each one has an association link
                    - Each one is an "work-for" association
                    - (c1,p1), (c1,p2), (c1,p3) 
        - Ternary (Relate 3 classes)
            - ![](https://i.imgur.com/961sn27.png)
                - Qty is the amount of a part used in a project supplied by a supplier 
                - E.g. (v1, pt1, proj1) with Quantity = 30
                - Unit 3 Slide 24
                    - ![](https://i.imgur.com/jNTK2oX.png)
        - Higher Order
            - more than 3 classes
    - Mutiplicity 
        - j..k (Meaning j to K)
        - * (Means 0 to many)
        - If at Cn end -> means associated to at least J and at most k instances in Cn
        - Implies possible and impossible sets (Represented by {(...),(...)})
    - Role
        - Each class end labelled with a role name played in association
        - Other attributes can also be indicated
    - Instances of association > collection of association links
        - Each instance of association has identical properties
- **Aggregation**
    - Part-and-Assembly type of asscociations
    - More strongly coupled type of association
    - Each instance of the "part" class is part of an instance of the "assembly" class
    - ![](https://i.imgur.com/X2EfTNf.png)
        - Each paragraph instance is part of each document instance
        - Each sentence instance is part of each paragraph instance
- **Generalization**
    - Type-and-subtype kind of relationships
    - Each type is represented by a superclass
    - Each sub-type will be represented by a subclass of the superclass (but reverse is not true)
        - Each instance in the subclass is aan instance of the superclass
        - Subclass inherits all properties of superclass
        - But properties can also be overridden in the subclass
    - ![](https://i.imgur.com/32it6Fd.png)
        - Y has **3 attributes**
            - X1 from class X
            - Redefines x2 to X2 (from class Y)
            - Intros own property y2
        - Z has **3 attributes**
            - x1 and x2 from X
            - Own attribute Z1
