# FIT5136 Software Engineering
###### tags: `2020S1`
## Week 1 Introduction
> 理論上不會考 [name=william0204]
## Week 2 Requirements, Use case diagram
### Functional vs Non-functional requirements
* **Functional**:
* Describe functionality or system services.
* Describe how the system should react to particular inputs and how the system should behave in particular situations. (Expressed as inputs and outputs)
* Example: A user shall be able to search properties for all suburbs.
* **Non-functional**:
* A specific criteria that can be used to judge the operation
* Example: response time, storage requirements, I/O device capability...
### Imprecise requirements
* Requirements **must not be ambiguous, incomplete and inconsistent**.
* Requirements elicitation and analysis:
* Discovering the client's requirements (requirements elicitation or requirements gathering)
* Refining and extending the initial requirements (requirements analysis)
### Requirement specification
* **User requirements** must be understandable by end-users and customers who do not have a technical background.
* **System requirements** are more detailed requirements and may include more technical information.
### Use case diagram
* Inclusion and extension
* **Include**: An including use case **never stands alone**. It always includes the included use case.
* **Extend**: Extending use case is used to separate **optional behavior** from mandatory behavior.
>Example:
When a student is enrolled, a confirmation is required to be sent to the student. (Enroll course \<\<include>> --> Send confirmation)
When a student is enrolled, a student can choose to enroll to the units. (Enroll course <-- \<\<extend>> Enroll units)

### User stories
A handy guide to the production of good user stories is using the **INVEST** mnemonic:
* **Independent**: User stories should be self-contained.
* **Negotiable**: User stories should be able to be easily revised or replaced, such as with a different user story that satisfies the same outcome.
* **Valuable**: A user story must be beneficial to end users.
* **Estimable**: A user story should correspond to functionality for which implementation effort can be estimated.
* **Small**: User stories must be small enough to be considered and scheduled independently.
* **Testable**: The user story must provide enough info to verify that it has been implemented satisfactorily.

## Week 3 Analysis 1, UML Diagram, Class Diagram
### Types of UML diagrams
* **Use case diagrams**: show the interactions between a system and its environments, together with use case scenarios which provide more interaction details.
* **Class diagrams**: show the object classes in the system and the associations between these classes.
* **Interaction diagrams**: show interactions between actors and the system and between system components:
* Sequence diagram
* Communication diagram
* **Statecharts**: show how the system reacts to internal and external events.

### **Aims** of the requirement analysis
* Obtain deeper understanding of requirements.
* Model the system.
* Describe them in a way that will result in a maintainable design and implementation.

### The **three steps** of Requirement Analysis:
> Perform the following three steps "incrementally" and "iteratively".

* Functional modeling:
* use case scenarios
* Class modeling:
* Determine the entity classes and attributes
* Determine the interrelationships and interactions between the entity classes
* Present the information in the form of class diagram
* Dynamic modeling:
* Determine the operations performed by or to each entity class
* Present this information in the form of a statechart

### Step One: **Functional Modeling**:
Use case **scenarios** (a description of a use case):
* A scenario can be normal and exception:
* **Normal** scenario:
* A set of interactions between user and system that corresponds to the way we understand how the system should be used towards a goal
* **Exception** scenario:
* A scenario that describes how to handle an undesired event, that is, an event that interferes with progress towards a goal.
* Or a scenario that is the result of an exception condition that interferes with a normal scenario.

### SRS-Software Requirements Specification:
* **SRS**: detailed description of a software system to be developed with its functional and non-functional requirements.
* SRS is developed based on the agreement between client and you.
* Include the use cases of how user is going to interact with software system.
* Be consistent of all necessary requirements required for project development.

### Step Two: **Class Modelling** using **Class Diagram**:
* Shows classes, attributes and the associations between these classes.
* What kind of things are **objects**?
* Tangible or 'real world things'-book, brochure
* Roles-student, member
* Events-arrival, leaving, request
* Interactions-meeting, intersection
* **Classes**:
* A class has:
* Data **attributes**/properties: information that is pertinent to their instances
* Operations/**methods**: functionality that the objects support
* a class is a description of the commonalities of individuals.
* An object is that one individual with different values.
* Relationships between classes:
* Collaborates with (association)
* is-a (inheriance or generalisation)
* has-a (aggregation/composition)
* **Polymorphism**:
* Polymorphism: the ability of an object to take on many form.
* Abstract Class:
* **Abstract Classes** are classes that contain one or more abstract methods.
* **Abstract methods** is a method that is declared but contain s no implementations.
* Abstract classes need no instantiation and require subclasses to provide implementations for the abstract methods.
* Abstract method must be **overridden** in a subclass

## Week 4 Unified Process
Working as a team(据说不考)
The unified process
### Define
* The Unified Process is an adaptable methodology-It has to be modified for the specific software product to be developed
* Iteration and Incrementation
* An artifact is constructed piece by piece（Incrementation）
* Each increment goes through multiple versions(Iteration)
* Advantages
* Multiple opportunities for checking correctness
* Robustness of the architecture can be determined relatively early
* Risks are mitigated early
* Always have a working version of the software
### Requirements Workflow
* First, gain an understanding of the application domain
* The specific business environment in which the software product is to operate
* Second, build a business model
* use UML diagrams to describe the client's business process
* If at any time the client does not feel that the cost is justified, development terminates immediately.
### Analysis Workflow
* aim: to analyze and refine the requirements
### Design Workflow
* aim: to refine the analysis workflow until the material is in a form that can be implemented by the programmers
### Implementation Workflow
* aim: to implement the target software product in the selected implementation language
### Test Workflow
* Unit testing (as soon as it has been implemented)
* Integration testing (At the end of each iteration)
* Product testing (When the product appears to be complete)
* Acceptance testing (Once the completed product has been installed on the client’s computer)
### Traceability
* Every item in the analysis artifacts must be traceable to an item in the requirements artifacts.
### Inception Phase
* aim: to determine whether the proposed software product is economically viable
### Elaboration Phase
* aim: to refine the initial requirements
### Construction Phase
* aim: to produce the first operational-quality version of the software product
### Transition Phase
* aim: to ensure that the client’s requirements have indeed been met
The screenshot of Workflow 

## Week 5 Class Diagram, Sequence Diagram, state chart
### Class Modeling:
* Classes in the problem domain
* Relationships between classes (see week 3)
* **Iterative** process, won't get all of this in one go.
### **Association** in Class Diagram:
* Represent **relationships** between classes
* Represented as a **line connecting** the two related classes
* If the association has a **navigability** (an arrow on one end), it indicates that one class knows about the other but not vice versa.
* Name and label can be given to association to help you understand the **nature** of the relationship.
### Mutiplicity:
* Each end of an association can have its multiplicity shown and this indicates how many objects of each calss are involved in the association:
* one to one
* one to many
* many to one
* many to many
### Generalisation (inheritance/is-a/superclass-subclass):
* **Generalisation**: an everyday technique that we use to manage complexity
* This allows us to infer that different members of these classes have some common characteristics.
* In generalisation, the attributes and operations associated with higher-level classes are also associated with the lower-level classes.
* The lower-level classes are subclasses **inherit** the attributes and operations from their super classes. These lower-level classes then **add more specific attributes** and operations.
### Aggregation (has-a):
* **Shared Aggregation**: shows how classes that are collections are composed of other classes, and it is the kind of association that exists between a group and its members,
* **Characteristics** of shared aggregation:
* the aggregate object may potentially exist without its constituent objects.
* at any time, each object may be constituent of more than one aggregate.
* constituent objects are typically of the same class.
* **Composition aggregation**: the kind of aggregation that exists between a whole and its parts.
* **Characteristics** of composition aggregation:
* the composite object does not exist without its components.
* at any time, each component may be part of only one composite.
* component objects are likely to be of mixed types.
### Construction of class diagram:
* Determine entity classes and their attributes:
* Create a **dictionary of abstractions**:
* Start by looking for tangible things
* Figure out what is inside and outside the problem boundary
* Get dictionary of abstractions(1.candidate entity classes; 2.Attributes; 3.Outside problem domain)
* Determine the **interrelationships** between the classes:
* Not all classes will have a relationship with each other
* It could be:
* association
* generalization
* aggregation
* Determine the **multiplicity** between two classes:
* If two classes do not have a relationship with each other, they do not have multiplicity either
* Could be:
* one to one
* one to many
* many to one
* many to many (if many to many, leave it as it is for initial diagram)
* Determine the **interactions** between classes:
* Interaction is:
* to manage the data of the other class
* is dependent on the data of the other class
* the two classes in question needs to work together
* If two classes have a relationship, read through the requirements document to find any information related to the multiplicity, otherwise, add a multiplicity within reason:
* Generally, it is one to many
* Draw class diagram
### Three type of classes
* Entity classes:
* Models "long-lived" information
* Usually "passive"
* Examples: property, agent, real estate company
* Boundary classes:
* Class that lives on the system's "automation boundary"
* models the interaction between product and environment (actor)
* associated with input or output
* Control classes:
* Mediate interaction between boundary and entity classes
* Models complex computations and algorithms
* Sometimes relate to use case, but not always
### Sequence Diagram
* Models the flow of logic within the system
* Describes how-and in what order-a group of objects works together
* Models the details of a use case-use case scenario
* Example: see week 5 lecture slide P66-68
### Communication Diagram
* Another type of interaction diagram
* It corresponds to a simple sequence diagram
* Based on the class diagram
* Example: see week 5 lecture slide P72

## Week 6

## Week 7 Design
### Design Workflow
* To refine the analysis artifacts until the material is in a form that can be implemented by the programmers.”
#### Analysis and Design Artefacts
* The analysis artifacts are iterated and integrated until the programmers can utilize them.
* Analysis artifacts
* Use case scenarios
* Initial class diagram
* Interaction diagrams
* Statecharts
* The main artifact/output of Design is the detailed class diagram.
#### Design Architecture
* The architecture includes
* The components
* How they fit together
* The allocation of components to subsystems/packages
* Designing the architecture is a specialized test > performed by a software architect
* Easier to implement several smaller subsystems than one large system
* If subsystems are independent, can be implemented AND TESTED by programming teams working in parallel
#### Design Architect
* The architect needs to make trade-offs
* Every software product must satisfy
* its functional requirements (the use cases)
* its nonfunctional requirements (portability, reliability, robustness, maintainability, and security)
* within budget and time constraints
* The architect must assist the client by laying out the trade-offs
* Often satisfying all requirements and constraints is impossible.
* The client must
* Relax some of the requirements;
* Increase the budget; and/or
* Move the delivery deadline
### Architectural design
* Architectural design is concerned with understanding how a software system should be organized and designing the overall structure of that system.
* Architectural design is the critical link between design and requirements engineering,
* identifies the main structural components in a system and the relationships between them.
* The output of the architectural design process is an architectural model that describes how the system is organized as a set of communicating components.
#### Depicting architectural design
* In large systems, subsystems are whole collections of classes.
* Often shown in package diagrams – a package represents a set of classes with related responsibilities.
#### Challenges of the design team
* The design team should not do too much
* Detailed design ≠ code !!
* The design team should not do too little
* Must produce a complete detailed design
### Design and Abstraction
* Classical design activities (OO or non-OO)
* Architectural design
* Detailed design
* Design testing – traceability!
#### Architectural design decisions
* Architectural design is a creative process so depending on the type of system/application being developed.
* However, several common decisions span all design processes and these decisions affect the nonfunctional characteristics of the system as well.
#### Architecture reuse
* Systems in the same domain often have similar architectures that reflect domain concepts.
* Application product lines are built around a core architecture with variants that satisfy particular customer requirements.
* The architecture of a system may be designed around one of more architectural patterns or ‘styles’.
* These capture the essence of an architecture and can be instantiated in different ways.
#### Architecture and system characteristics
* Performance
* Security
* Safety
* Availability
* Maintainability
* Communications
#### Architectural patterns
* Patterns are a means of representing, sharing and reusing knowledge.
* An architectural pattern is a stylized description of good design practice, which has been tried and tested in different environments.
* Patterns should include information about when they are and when they are not useful.
* Patterns may be represented using tabular and graphical descriptions.
#### The Model-View-Controller (MVC) pattern
* Model manages the behaviour and data of the application domain
* responds to requests for information about its state(usually from the view)
* responds to instructions to change state (usually from the controller)
* View manages the display of information
* Controller interprets user inputs
* usually mouse and keyboard,
* informing the model and/or the view to change as appropriate.
#### MVC Separation of Concerns
* Both the View and the Controller depend on the Model, but the Model depends on neither of them
* The Model can be built and tested independently of the View and Controller
* In a stand-alone (desktop) application the separation between View and Controller is not always clear.
* But always beneficial
* In a web-based application, they are clearly distinguished:
* The View is implemented on the browser
* The Controller is implemented on server-side
* components that handle HTTP requests
### Layered architecture
* Used to model the interfacing of sub-systems.
* Organises the system into a set of layers (or abstract machines) each of which provide a set of services.
* However, often artificial to structure systems in this way.
#### A generic layered architecture
#### The Layered architecture pattern
### Repository architecture
* Sub-systems must exchange data. This may be done in two ways:
* Shared data is held in a central database or repository and may be accessed by all sub-systems;
* Each sub-system maintains its own database and passes data explicitly to other sub-systems.
#### A repository architecture for an IDE
### Client-server architecture
* Distributed system model which shows how data and processing is distributed across a range of components.
* Set of stand-alone servers which provide specific services such as printing, data management, etc.
* Set of clients which call on these services.
* Network which allows clients to access servers
#### A client–server architecture for a film library
#### The Client–server pattern
### Object-Oriented (OO) Design
* Aim: Design the product in terms of the classes extracted during OO Analysis
* Complete the class diagram In other words, complete the initial class diagram to produce a detailed class diagram:
* Determine attribute formats
* Assign each method
* Complete the class diagram:
* The formats of the attributes can be directly deduced from the analysis artifacts
* Assign each method （Question on Week 7 P41)
* A: Information Hiding (Hiding the implementation details from the caller! )
#### Public, private and protected
* Public – any other code can access directly.
* Private – only accessible directly by code within the class.
* Protected – subclasses can access directly.
* UML visibility prefixes
* "-" Private
* "+" Public
* "#" Protected
* Applies to both attributes and methods.
* Some languages (e.g. Java, C++) have facilities to enforce public, private, protected.
* Not all languages provide this capability.
* However, still a useful thing to implement by convention.
#### Assigning methods to classes
* By convention, for each attribute of a class:
* Mutator method: setAttribute
* Accessor method: getAttribute
* Assign each method, either to a class or to a client that sends a message to an object of that class
* If an operation is invoked by many clients of an object, assign the method to the object, not the clients
* Responsibility Driven Design
* Client C sends message to Object O
* O is responsible for carrying out request
* C doesn’t (and can’t) know how
* When request carried out by O, control returns to C
### Detailed Class Diagram
* Add Boundary and Control classes to initial class diagram
* You can have multiple boundary classes and/or multiple control classes
* Decide on attribute types
* Determine methods by referring to:
* Interaction Diagrams (Sequence or Communication)
* CRC charts
* Keep entity classes simple!!
#### Navigability
* Also known as "navigation visibility", "navigation", or "visibility“ or “Knows”.
* To send a message from an object to another, it must be visible.
* Student can “see” the units because it is an attribute in Student class.
* Denoted by arrowhead – one-way visibility (uni-directional).
#### Thoughts on navigability
* Two-way navigability (bi-directional) adds complexity
* Need to maintain both ends of the association whenever a change is made
* Student knows about the units and unit knows about the students.
* Try to avoid when one way is enough.
####
* Consider a situation, Employee object contains many information such as id, name, email Id etc. It contains one more object named address, which contains its own information such as city, state, country, postcode etc. as given below.
* In such case, Employee has an entity reference address, so relationship is Employee HAS-A Address
### Pseudocode
* Sometimes, you have a complex algorithm to describe.
* If that's the case, can use pseudocode.
* Pseudocode is a tool to describe to people the algorithm that you use.
* without being distracted by details of programming language syntax
* You are not tied down to a particular language,
* Pseudocode should be quicker to write and review (by programmers and non-programmers) than real code, otherwise no point.
* Can progressively refine pseudocode as necessary.
* In general the vocabulary used in the pseudocode should be the vocabulary of the problem domain, not of the implementation domain
* Example:
* Extract the next word from the line (good) set word to get next token (poor)
* Append the file extension to the name (good) name = name + extension (poor)
* Create a new investment record (good) Investment inv = new Investment() (poor)
#### Pseudocode Constructs
* SEQUENCE 
* WHILE 
* IF-THEN-ELSE 
* REPEAT-UNTIL 
* CASE 
* FOR
#### Nested Constructs
#### Invoking Subprocedures

## Week 8-1 Code of Ethics
### Ethic (Moral Philosophy)
* The branch of philosophy that involves sytematizing, defending, and recommending concepts of right and wrong conduct.
* Rational examination of morality
* Evaluation of people's behavior
### Ethics vs Morality
* Morality:
* "Manner, Character, Proper behavior"
* The conduct or rules that a person or community adhere to, believing that these things are obligatory
* Gives us rules for everyday life (moral rules)
* Practical
* Ethics:
* Critical reflection of "morals"
* Philosophical reflection about the nature of the good life, of right action, of duty and obiligation
* Theoretical
### Roles of Codes of Ethics
* A practical framework for moral decision-making related to problems that software engineers may encounter.
* Principles of responsibility that outline how to promote the public good.
* Key points:
* Shared standards
* Support
* Guidance
* Inspiration
* Education and mutual understanding
* Deterrence and discipline
* Contributing to the profession's image
### Mission statement of Software Engineering Code of Ethics
* To establish the appropriate set(s) of criteria and norms for professional practice of software engineering upon which industrial decisions, professional certification, and educational curricula can be based.
### 8 Principles of Code of Ethics
* ENG: http://ethics.acm.org/code-of-ethics/software-engineering-code/
* CHN: http://ethics.acm.org/wp-content/uploads/2016/07/SEERI.chinese.code_.one_.column.pdf
### Virtue Ethics
* Virtue(美德): a quality considered morally good or desirable in a person：
* Strengths:
* Provides a motivation of good behaviours
* A solution to the problem of impartiality
* Weakness:
* Using virtue ethics alone is hard to determine what to do in a particular situation.

## Week 8-2 Intellectual Property(知識產權)
### Intellectual Property/Copyright
* **Intellectual Property**:
* Refers to creations of the mind: inventions, literary and artistic works, and symbols, names, images, and designs used in commerce.
* Intellectual Property: any unique product of the human intellect that has commercial value.
* **Copyright**:
* Law secures for the owner of a creative work the exclusive right to control who can make copies, or make works derived from the original work.
* Provides owner of an origianl work **five rights**:
* Reproduciton
* Distribution
* Public display
* Public performance
* Profduction of derivative works
* Protect specific expressions of ideas, not ideas themselves
* **Fair use doctine**:
* it is legal to use copyrighted material in certain solution.
* Sometimes legal to reporduce a copyrighted work without permission
* Courts consider **four factors**:
* Purpose and character of use
* Nature of work
* Amount of work being copied
* Effect on market for work
### Benefits of Intellectual Property Protection
* Some people are altruistic(無私心的); some are not
* Allure of wealth can be an incentive for speculative work
* Authors of U.S. Constitution recognized benefits to limited intellectual property protection
### Software Copyrights
* **What** gets copyrighted?
* Expression of idea, not idea itself
* Object program, not source program
* Companies treat source code as a trade secret
* Protects the screen displays produced by the software-valuable for video game developer.
### Violation of Software Copyrights
* Copying a program to give or sell to someone else
* Preloading a program onto the hard disk of a computer being sold
* Distributing a program over the internet
### Safe Software Development
* Reverse engineering okay
* Companies must protect against unconscious copying
* Solution: "Clean room" software development strategy:
* Team 1 analyze competitor's program and writes specification
* Team 2 uses specification to develop software
* Team 2 is isolated from seeing the competitor's program
### Open-Source Software
* **Characteristics of open-source software**:
* No restrictions preventing others from selling or giving away software
* Source code included in distribution
* No restrictions preventing others from modifying source code
* No restrictions regarding how people can use software
* Same rights apply to everyone receiving redistribution of the software("copyleft")
* **Copyleft**:
* The practice of using copyright law to offer the right distribute copies and modified versions of a work and requiring that the same rights be preserved in modified version of the work.
* A general method for making a creative work as freely available to be modified, and requiring all modified and extended versions of the creative work to be free as well.
* **Reuse** of Open source software:
* "Open source" does not necessarily mean you can reuse portions of the code for your work
* Need to find our what OS(open source) license the author has.
* If unsure, need to contact the author to find out and seek permission.
* Note that:
* Publicly-available source alone grants you zero rights
* If no license implies, the author reserves all rights under copyright and grants you none

## Week 9 Implementation Issues
### Goals
* Fundamental goal is to build a working version of system.
* Craft out the architecture
* Implement the design in terms of components.
* Plan system integrations
* Implement design classes and subsystems
* Unit test components
* Integrate components
### Implementation
* The primary activities of the Implementation:
* Building the implementation model, which describes how the elements of the design model are packaged into software components, such as source code files (or code artefacts) in the selected implementation language such as Java or Python.
* Testing the developed components as units.
* Integrating the results (subsystems) produced by individual implementers (or teams) into an executable system.
### Where we are in the Unified Process
### Construction Phase
* The aim of the construction phase is to produce the first operational-quality version of the software product
* This is sometimes called the beta release
* The emphasis in this phase is on
* Implementation and
* Testing
* Unit testing of modules
* Integration testing of subsystems
* Product testing of the overall system
### What we really want for coding
* To fulfil explicit and implicit requirements:
* Functional requirements
* Non-functional requirements
* Real-life products are generally too large to be implemented by a single programmer
* Implementation therefore deals with programming-in-the-many
### Implementation Issues
* Focus is NOT on programming, but other implementation issues that are often not covered in programming texts:
* Reuse: To reuse existing components or systems.
* Configuration management: To keep track of the many different versions of software component in a configuration management system.
* Host-target development: Final software does not usually execute on the same computer as the software development environment. Develop it on one computer (the host system) and execute it on a separate computer (the target system).
### Different Levels of Reuse
* The abstraction level - Use knowledge of successful abstractions in the design of your software (e.g. Design patterns.)
* The object level - reuse objects from a library rather than writing the code yourself. (e.g. Java standard library containing packages such as java.util, java.lang, javax.swing etc.)
* The component level – reuse collections of objects and object classes in application systems. (e.g. CORBA)
* The system level - reuse entire application systems. (e.g. Gmail)
### Configuration management
* The general process of managing (tracking and controlling) a changing software system.
* To support the system integration process so that all developers can access the project code and documents in a controlled way, find out what changes have been made, and compile and link components to create a system.
* Github
* Web based version control system
* Bug/Issue Tracking
* Version control
* Feature request
* Documentation
### Configuration management activities
* Version management
* To keep track of the different versions of software components.
* Include facilities to coordinate development by several programmers.
* System integration
* To help developers define what versions of components are used to create each version of a system.
* Description used to build a system automatically by compiling and linking the required components.
* Bug Tracking
* To allow users to report bugs and other problems,
* To allow all developers to see who is working on these problems and when they are fixed.
### Configuration management tool interaction
### Host-target development (Cross-Compilation)
* Most software is developed on one computer (the host) but runs on/for a separate machine (the target).
* A platform is more than just hardware.
* It includes the installed operating system plus other supporting software such as a database management system or, for development platforms, an interactive development environment.
* Development platform usually has different installed software than execution platform; these platforms may have different architectures.
### Integrated development environments (IDEs)
* Software development tools are often grouped to create an integrated development environment (IDE).
* An IDE is a set of software tools that supports different aspects of software development, within some common framework and user interface.
* IDEs are created to support development in a specific programming language such as Java. The language IDE may be developed specially, or may be an instantiation of a general-purpose IDE, with specific languagesupport tools.
* Examples: IntelliJ, PyCharm, MS Visual Studio.
### Component / system deployment factors
* System usually designed for a specific hardware architecture, or relies on some other software system.
* Needs to be deployed on a platform that provides the required hardware and software support.
* High availability systems may require components to be deployed on more than one platform.
* High level of communications traffic between components
* makes sense to deploy them on the same platform or on platforms that are physically close to one other
* reduces the delay between the time a message is sent by one component and received by another.
### Open source development
* Open source development is an approach to software development in which the source code of a software system is published, and volunteers are invited to participate in the development process
* Its roots are in the Free Software Foundation (www.fsf.org), which advocates that source code should not be proprietary but rather should always be available for users to examine and modify as they wish.
* Open source software extended this idea by using the Internet to recruit a much larger population of volunteer developers. Many of them are also users of the code.
### Open source systems
* The best-known open source product is, of course, the Linux operating system which is widely used as a server system and, increasingly, as a desktop environment.
* Other important open source products are Java, the Apache web server and the mySQL database management system.
### Open source issues
* Should the product that is being developed make use of open source components?
* Should an open source approach be used for the software’s development?
### Open source business
* More and more product companies are using an open source approach to development.
* They believe that involving the open source community will allow software to be developed more cheaply, more quickly and will create a community of users for the software.
* Still need to figure out the licensing
### Programming Issues
* Readable code - A **key** quality requirement.
* You can read it, can understand it without documentation
* Hard to estimate exactly, but…
* You will spend **at least as** much time reading code as writing code in the real world!
* Maintainability, extensibility, understandability, changeability, debuggability, testability, reliability - **all depend on readability**.
### The Performance Issues
* Way before you were born (around 1970)
* Computers were expensive and people worried about making their programs go as fast as possible.
* Since then
* Computers are thousands of times **faster**
* Throwing **hardware** at the problem got much **cheaper**
* **Compilers** are much **better** at **optimizing**
* Correctness, robustness, and clarity are more important than efficiency. A fast program that gets the wrong answer doesn't save any time.
### Upshot
* Choose good algorithms and data structures (design…)
* particularly where algorithms are spread across multiple methods
* Write correct, simple, readable code first.
* If necessary, tweak later.
### Documentation
* Good documentation
* Self documenting code?
* Eg. The variable xCoordinateOfPositionOfRobotArm – tedious, if used frequently. Better to use xCoord
* The key issue: Can the code artifact be understood easily and unambiguously by
* The SQA team
* Maintenance programmers
* All others who have to read the code
* API documentation tools
* Javadoc
### Use of Comments
* Prologue (mandatory)
* In-line comments
* essential whenever the code is written in a non-obvious way, or makes use of some subtle aspect of the language
* Confusing code should be recoded in a clearer way
* They are not meant to promote/excuse poor programming
* However, comments can assist future maintenance programmers
### Coding Standards
* Standards can be both a blessing and a curse
* Modules of coincidental cohesion arise from rules like
* “Every module will consist of between 35 and 50 executable statements”
* Coding standards
* Things you will do (eg initialize all attributes in constructor).
* Typically described in a coding standards document.
* Java Coding Conventions
* Python Coding Conventions
### Deep Nesting
* Style 1-Badly formatted
* Style 2: Well formatted but badly constructed
* Style 3: Acceptably Nested
### Remarks on Programming Standards
* To make maintenance easier
* However, if they make development difficult, then they must be modified
* Overly restrictive standards are counterproductive - the quality of software suffers
### Code Smell
* Definition: A code smell is a surface indication that usually corresponds to a deeper problem in the system.
* Though there are many types of code smell that may exist in your code, we only discuss some common code smells and their solutions.
* Code smell we discuss are:
* Duplicate Code
* God Class/Object
* Embedded constants
### Duplicate Code
* Why duplicated code is bad?
* When the same code appears in multiple places, it must be maintained in multiple places.
* If a bug is discovered in that code, every piece of duplicate or very similar code must be checked and fixed.
* If the requirements change and the code needs to be modified, it needs to be tracked down and changed everywhere.
* Solution?
* Apply DRY Principal
* DRY stands for Don't Repeat Yourself
* abstract out common code and put it in a single location
### God Class/Object
* A god class is one that does way too much (i.e., it has more than one main responsibility). Violates:
* Separation of Concerns (SOP)
* separating a computer program into distinct sections, such that each section addresses a separate concern.
* Single Responsibility Principle
* every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class.
* Another problem is that the class can’t be reused
* Solution: It should be split into smaller classes which each have their own responsibility
### Integration
* Lots of stuff in Schach about **integration** techniques.
* In practice, modern systems are usually built using **continuous integration**.
* a practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.
* Every day, developer's work is integrated into the "mainline" of the project.
* **Bugs** revealed by integrated testing are fixed.
### So, why CI?
* Regression testing
* Teams prefer using TDD (Test-Driven Development)
* You will catch the issues until it’s too late
* All the team members push the code on the server, fires up a build request that not just run the code but also tests it.
* Quality analysis report produce judicious results.
### Student way to do this
* Write all the code.
* Run it and see what happens.
* "Big Bang" integration testing
* doesn't work very well.
* Need to test modules/classes in isolation
* Very difficult to trace the cause of failure
### Top-down Integration P60
### Bottom-up Integration P65
### Sandwich Integration P69
### CI Tools
* Professionally popular:
* GitHub CI
* Azure DevOps
* Some of our units use:
* Jenkins (open source)
* GitLab CI (self-hosted Git server)
* Azure DevOps

## Week 10 Quality and Testing
### Software quality
* Quality software is reasonably bug or defect free, delivered on time and within budget, meets requirements and/or expectations, and is maintainable.
* Quality must be built in from the beginning, not something to be done at the end.
### Software Quality Assurance(SQA)
* A collection of risk mitigation methods
* Activities to ensure that:
* Product is of sufficient quality
* Process is of sufficient quality
* Occurs in all process models and everything you do in software engineering
* Not:
* just testing
* something you do only after implementation
### What Process QA does?
* Checking to ensure process model (as documented in project plan) is being followed.
* Mostly done by human review, often by seperate SQA team
* Why do it?
* Sometimes mandated by client/standards
* Because sometimes you don’t have a product to QA until later.
* Hypothesis: following the process -> high quality product.
* Agile methods have less emphasis on process QA
* Ultimately, product is what matters.
* Regular delivery of product ASAP in development
* If process is producing quality product, then process is of high quality.

### Verification vs Validation (V&V)
* Verification
* “Are we building the product right?”
* Determine if each workflow was completed correctly
* The software should conform to its artefacts (traceability).
* Verification
* “Are we building the product right?”
* Determine if each workflow was completed correctly
* The software should conform to its artefacts (traceability).
* The term "verify" is also used for all non-execution-based testing.

### Execution and Non-Execution
* Execution-based Testing:
* Software is executed.
* Testing software by running test cases.
* Non-execution based testing:
* Testing software without running test cases.
* No software to execute yet.
### 3 classes fo QA techniques
In the Unified Process, “Testing” (Test Workflow) refers to both execution-based testing and non-execution based testing
1. Human Reviews/Inspection/Walkthroughs(non-execution-based)
* Human review
* get someone else to check your work
* can be done in-person or online
* Pros. and Cons.:
* Reviews can be effective
* Only QA method for requirements and design artifacts.
* Requirements and design faults often most serious.
* Reviews are less effective if the process is inadequate
* Large-scale software should consist of smaller, largely independent pieces
* Large-scale software should consist of smaller, largely independent pieces
* Code reviews mostly detect evolvability/maintainability defects
* Important but not everything
* Walkthroughs
* A walkthrough team consists of four to six members
* It includes representatives of
* The team responsible for the current workflow
* The team responsible for the next workflow
* The SQA group
* The client
* Lists of items
* Items not understood
* Items that appear to be incorrect
* Inspections
* An inspection team has four members
* Moderator
* A member of the team performing the current workflow
* A member of the team performing the next workflow
* A member of the SQA group
* Special roles are played by the
* Moderator
* Reader
* Recorder
* Fagan Inspections – more general, not specifically targeting the Unified Process.
* 5 normal steps of inspection:
* Overview of the document to be inspected.
* Preparation:
* Participants try to understand the documents in detail
* Aided by statistics of fault types
* Inspection (Walkthrough) with written report on faults
* Rework – resolves all faults.
* Follow-up:
* Moderator ensures that every issue raised has been resolved
* Inspections vs Walkthroughs

3. Proving(non-execution-based)
* A product is correct if it satisfies its specifications
* Independent of its use of computing resources, when operated under permitted conditions.
* Testing vs Proving
* A correctness proof is an alternative to execution-based testing, or an addition to execution-based testing
* Time and effort can be huge.
5. Software Testing(execution-based)
* What should be tested?
* correctness
* utility
* reliability
* robustness
* performance
* Who should perform?
* Programmers should never do their own testing
* Testing should involve someone else, like SQA team
* What are you testing?
* Unit testing
* testing individual modules/classes within the system(development team)
* Integration testing
* testing how modules work together(done by developer/QA group)
* System testing
* Testing the whole system(developers/QA group)
* Acceptance testing (done by client or clientappointed proxy)

## Week 11
### Software Testing
* Part of the Execution Based Testing
* Should included in Implementation and Test workflow and inside the Construction and Transition phase
#### Inspections and testing
* complementary and not opposing verification techniques.
* Inspection:
* check conformance with specification but not customer's real requirements conformance.
* cannot check non-functional characteristics such as performance, usability, etc.
* advantages:
* During software testing, errors can mask (hide) other errors. Because inspection is a static process, you don’t have to be concerned with interactions between errors.
* Incomplete versions of a system can be inspected without additional costs.
* While searching for program defects, an inspection can also consider quality attributes of a program, such as compliance with standards, portability and maintainability.
### Software testing goals
* Validation testing
* To demonstrate to the developer and the customer that the software meets the requirements - A successful test shows that the system operates as intended.
* For custom software:
* there should be at least one test for every requirement in the requirements document.
* For generic software ;products
* there should be tests for all of the system features, plus combinations of these features, that will be incorporated in the product release.
* defect testing
* To discover faults or defects in the software where its behaviour is incorrect, undesirable or not in conformance with its specification - A successful test is a test that makes the system perform incorrectly and so exposes a defect in the system.
* system crashed, incorrect computations, unwanted interactions, etc.
### Positive and Negative Test
#### Positive Testing:
> Determines that your application works as expected. if an error is encountered during positive testing, the test fails.
#### Negative Testing:
> Ensure that your appliation can gracefully handle invalid input or unexpected user behavior.
> for example: aletter typed in a numeric field will display the error message: "Incorrect, please anter the number"
> Goal: detect and prevent application from crashing.
### Unit Testing
* testing individual components.
* testing of the smallest separately testable components of a larger software system.
* "Unit" is generally a class or module
* Done by the programming team, and possibly the individual programmer who wrote the code.
* Is a defect testing process
* Units may be:
* Individual functions or methods within an object
* Object classes with several attributes and methods
* Composite components with defined interfaces used to access their functionality.
#### Test case selection
* test to specifications:
* black-box, data-driven, functional, I/O-driven testing
* ignore the code, use the spec to select test cases.
* test to code:
* glass-box, logic-driven, structured, path-oriented testing
* use the code to select test cases
### Functional Testing
* An alternative form of black-box testing for classical software.
* Base the test data on the functionality of the code artifacts.
* Each item of functionality or function is identified.
* Test data are devised to test each (lower-level) function separately.
* Then, higher-level functions composed of these lower-level functions are tested.
### Glass-box testing techniques
* Also known as Structureal testing(white-box testing)
* Code Flow Graphs help in finding the correct coverage manually
* Issues:
* Statement coverage
* 

* Branch coverage
* 

* Path coverage
* 

* All-definition-use path coverage
* 

### Integration testing
* The testing of each new code artifact when it is added to what has already been tested
* Integrating components to create a version of the system and then testing the integrated system.
### Product testing
* COTS software:
* Product testing then Alpha, beta testing
* Custom software
* Product testing done by SQA group
* Use tests to approximate forthcoming acceptance testing
* Black-box test cases for whole product
* Robustness: Stress testing, volume testing
* Satisfies constraints
* Review documents –correctness, conformity to standards etc
### Acceptance testing
* Performed after product testing.
* The client determines whether the product satisfies its specifications
* The client tests a system to decide whether or not it is ready to be accepted from the system developers and deployed in the client’s environment.
* Acceptance testing is performed by
* The client organization, or
* The SQA team in the presence of client representatives, or
* An independent SQA team hired by the client

## Week 12 Post-delivery Maintenance
> Any change to any component of the product (including documentation) after it ha passed the acceptance test.
> In the unified Process, maintenance is treated as another increment of the software product.
> Post-delivery maintenance incorporates aspects of all other workflows.
> Is a task for an unsupervised beginner, or should be done by a less skilled computer professional.
### Development vs Maintenance
* It is easier to create a new version to modify an existing version.
* However, economic considerations make maintenance far preferable to redevelopment.

### Corrective maintenance vs Perfective maintenance vs Adaptive maintenance
* Corrective maintenance
* To correct residual faults.
* Analysis, design, implementation, documentation, or any other type of faults.
* Perfective maintenance
* Client requests changes to improve product effectiveness.
* Add additional functionality
* Make product run faster
* Improve maintainability
* Adaptive maintenance
* Responses to changes in the environment in which the product operates.
* new compiler, O/S or hardware
* Changes to external standards
### Ensuring Maintainability
* Maintenance is not a one-time effort
* Must plan for maintenance over the entire life cycle

### The Moving Target Problem
* Frequent changes have an adverse effect on the maintainability of the product.
* The more changes there are
* The more the product deviates from its original design
* The more difficult further changes become
* Documentation becomes even less reliable than usual
* Regression testing files are not up to date
* A total rewrite may be needed for further maintenance.
* Apparent solution
* Freeze the specifications once they have been signed off until delivery of the product.
* After each request for perfective maintenance, freeze the specifications for 3 months or 1 year

### Object-Orientation
* Apparently promotes maintenance in four ways.
* The product consist of independent units
* Encapsulation (conceptual independence)
* Information hiding (physical independence)
* Message-passing is the sole communication
* Three obstacles
* The complete inheritance hierarchy can be large
* The consequences of polymorphism and dynamic binding
* The consequences of inheritance
* Polymorphism and Dynamic Binding
Polymorphism and Dynamic Binding can have a positive effect on development, but a negative effect on maintenance.