# 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"></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"></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"></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"></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
- 
- 
- 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**
- 
- **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
- 
- 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
- 
- **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)

- 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)
- 
- Each person works for one company
- Each company has 0 to many employees
- Interaction has 2 attributes
- Salary
- Job title
- Unit 3 Slide 18
- 

- 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)
- 
- 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
- 
- 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
- 
- 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
- 
- 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