Written by Luka Kerr on June 13, 2018

## Software Development Life Cycle (SDLC)

1. Analysis & Specification
• Understanding the problem
• Gather requirements
• Use case modelling, user stories
2. Design
• Domain modelling
• Design artifacts
3. Implementation
• Programming the solution
4. Testing
• Unit tests, integration tests, user acceptance tests
5. Release & Maintenance
• Releasing the software
• Fixing defects, adding new functionality

## Requirements

A condition or capability needed by a user to solve a problem or achieve an objective

• Functional Requirements
• Defines the specific functionality that the software system is expected to accomplish
• What inputs the system should accept and under what conditions
• The behaviour of the system
• What outputs the system must produce and under what conditions
• For example: the system must let a user login and make a booking
• Non-Functional Requirements
• Describe the quality attributes of the software system
• For example: the system must process all events quickly

## Use Cases

• A step-by-step description of how a user will use the system-to-be to accomplish business goals
• A single use case includes:
• Name/number
• Related requirements
• Initiating actors
• Actor goal
• Participating actors
• Preconditions
• Postconditions
• Flow of events

### Use Case Diagram

A use case diagram portrays how actors interact with various parts of the system.

Includes:

• A system boundary - all actors are outside, and all use cases are inside
• Actors with names (i.e. staff, customer)
• Interaction with use cases:
• <<initiate>> for actors who intiate the use case
• <<participate>> for actors who are part of the use case but don’t initiate it
• <<include>> for use cases that require another use case (e.g. the use case “Unlock” <<includes>> the use case “Authenticate User”)
• <<extend>> for use cases that are optional when performing a seperate use case (e.g. the use case “Remove Item” <<extends>> the use case “View Cart”)

### Domain Model

• A domain model provides a visual representation of the problem domain, through decomposing the domain into key concepts or objects in the real-world and identifying the relationships between these objects.
• A domain model is also known as a conceptual model or domain object model.
• It is represented using a class diagram
• It includes:
• Classes/Objects
• Attributes
• Methods
• Relationships (has one, has many)
• Cardinality
• Inheritance

## OO Principles

### Abstraction

• Incorporates the common properties of objects
• Any classes inheriting from an abstract class must implement the methods/properties of that abstract class

### Encapsulation

• Hiding the objects state (attributes)
• Use of methods to provide access to the object (getters, setters)
• Importance:
• Ensures that an objects state is consistent
• Increases usability
• Abstracts the implementation

### Inheritance

• Models a relationship between classes in which one class represents a more general concept (parent or base class) and another a more specialised class (sub-class)

### Association

• Aggregation
• The contained item is an element of a collection, but can also exist on its own if the collection is destroyed
• For example: A student at a university - the student can exist if the university is destroyed
• Uses a non-filled in diamond ◇
• Composition
• The contained item is an integral part of the collection
• For example: pages in a book - if the book is destroyed, so are the pages
• Uses a filled in diamond ◆

## CRC Cards

• CRC stands for:
• Class: represents a collection of similar objects
• Responsibility: Something the class knows or does
• Collaborator: Another class that a class must interact with to fulfil its responsibilities
• Used to represent a domain object
• Can be transformed into UML class diagrams where:
• Classes → Concepts
• Responsibilities → Aggregation/Composition
• Collaborations → Relationships

## Software Development Methodologies

### Waterfall Model

• Linear, sequential
• Requirements → Design → Implementation → Testing → Deployment and Maintenance
• Each phase must be completed, documented and signed off before the next one is started
• Simple to understand due to project visibility
• Suitable for risk-free projects with stable product statements and clear requirements
• No working software until late into the process
• Rigid and not flexible, no support for fine tuning of requirements throughout the cycle
• Heavy documentation requirements

### Rational Unified Process (RUP)

• An iterative software development approach
• Consists of four phases:
• Inception: scope the project, identify what resources are required, architecture and risks, estimate costs
• Elaboration: understand the problem domain, analysis, evaluate in detail required architecture and resources
• Construction: design, build and test software
• Transition: release software to production
• Development is organised into disciplines:
• Development disciplines
• Understanding domain, develop high-level requirements, model and document vision and requirements
• Support disciplines
• Configuration and change management, project management, environment
• Serial in the large (sequential phases), but iterative in small (work across all disciplines in each iteration)

### Agile

• Working software gets produced much faster
• Requirements can change to the clients needs over time
• The client is engaged more through each iteration and provides feedback

• Remote teams face difficulties with daily standups
• Incremental devlopment/adaptability not suited to clients desiring contracts with firm estimates
• Reliance on small self-organized teams makes it difficult to adapt to large software projects
• Lack of comprehensive documentation can make it difficult to maintain or add to the software
• Need highly experienced software engineers who know how to both work independently and interface effectively with business users

### Extreme Programming (XP)

• Focuses on providing the highest value to the customer ASAP
• Changes to requirements are allowed
• Principles: pair programming, continuous integration, open workspace, refactoring, test driven development
• Continuous feedback is a big part of XP, coming from other developers and customers
• Steps in XP:
• Initial exploration
• Developers and customers discuss the system, break down features into user stories
• Estimations for user stories
• Release plan
• Customers prioritise user stories and negotiate a release date
• Iteration planning
• Use the release plan to create iteration plans
• An iteration size is chosen (1-2 weeks) and user stories are completed in priority
• Once begun, customers can’t change the user stories
• Iteration ends on the specified date even if the user stories aren’t done
• Developers and customers arrange an iteration planning meeting at the beginning of each iteration
• Customers choose user stories for the iteration
• User stories are broken down into programming tasks
• Developers choose user stories and provide estimates

## User Stories

A user story must contain 3 main parts: a role, goal and benefit. For example:

As a customer I want to create an account so that I can shop online

To create a good user story, follow the INVEST acronym:

• Independent
• Self contained
• Negotiable
• Leave room for negotiation, only complete what is required from the user story
• Valuable
• The user story must have value to the customer/business
• Estimable
• Each user story must be clear enough to estimate
• Small
• Each user story should be small and only contain one main goal
• Testable
• Each user story should have an acceptance criteria that when fulfilled, signifies the user story is completed

### Epic Stories

Epic story are short overarching goals that encapsulate multiple smaller user stories.

## UML Diagrams

There are 2 broad categories of UML diagrams:

• Structure diagrams
• Show the static structure of a system and its parts
• Elements are depicted irrespetive of time and no interations between elements are modelled
• Examples include: class diagram, deployment diagram
• Behaviour diagrams
• Shows the dynamic behaviour of objects in the system
• Examples include: use case diagram, sequence diagram

### Sequence Diagram

• Provides a visual summary of a use-case scenario
• Shows for a particular use case scenario the events the external actors generate, their order and possible inter-system events
• Essentially, given a use case, show what methods are called and data returned for each step in the method
• Shows:
• External actors
• Messages (methods) invoked by actors
• Return values (if any) associated with messages
• Indication of any loops or iteration area

### Activity Diagram

• Visualise the workflow of a use case
• More detailed tracing of the method for different possible paths, or concurrent threads

## Effective Software Design

### Design Smells

• A symptom of poor design
• Often caused by violation of key design principles
• Has structures in software that suggests refactoring
• Rigidity
• When the software is too large to be changed, even in simple ways
• Fragility
• Tendency of the software to break in many places when a single change is made
• Immobility
• Design is hard to reuse and has parts that could be useful to reuse, but the effort in moving them is too high
• Viscosity
• When changes in the software are easier to implement through ‘hacks’, and when the development environment is slow and inefficient
• Opacity
• Tendency of a piece of software to be difficult to understand
• Needless complexity
• Code is ahead of the requirements and contains constructs that are not currently useful
• Needless repetition
• Software contains repeaded code that could be reused under a single abstraction

### Refactoring

• The process of restructuring the internals of software to make it easier to understand and cheaper to modify, without changing its external, observable behaviour

### Characteristics of Good Design

Good software design aims to have loose coupling and high cohesion, so the software is extensible, reusable, maintainable, understandable and testable.

• Coupling
• The degree of interdependence between components/classes
• Tight coupling occurs when two components are highly dependent on each other, and any changes made affects the other component largely
• Cohesion
• The degree to which all elements of a component or class work together as a functional unit
• Low cohesion occurs when a single class performs many functions, that are not necessarily relative to that specific class

## SOLID Principles

• SRP - Single Responsibility Principle
• A class should have one reason to change
• A class only performs one main responsibility
• OCP - Open Closed Principle
• Software entities should be open for extension and closed for modification
• As requirements change, modules can be extended with new behaviours, but the internals of the module should not be changed
• Using abstract classes
• Advantages include: reduced rigidity, flexibility, reusability, maintainability
• LSP - Liskov Substitution Principle
• ISP - Interface Segregation Principle
• DIP - Dependency Inversion Principle
• High level modules should not depend on low level modules. Rather, both should depend upon abstractions
• Advantages include: loose coupling, reusability, testability, maintainability

## Testing

### Types:

• Black box testing
• Tests a program with sets of input without looking at how the program is implemented
• White box testing
• Tests a program with test data and knowledge of how the program is implemented
• Regression testing
• Verifying software that was changed, still performs correctly

### Test Coverage:

Measures the degree to which software has been exercised by tests

### Code Coverage:

Measures the degree to which the source code of a program has been tested

### Test Driven Development:

• Writing tests that fail then implementing the code to make the tests pass

### Equivalence Testing:

• Divides the space of all possible inputs into equivalence groups such that the program behaves the same on each group
• Two steps:
• Partitioning the values of input parameters into equivelance groups
• Choosing the test input values

### Boundary Testing:

• A special case of equivalence testing that focuses on the boundary values of input parameters
• Based on the assumption that developers often overlook edge cases
• One step: select elements from the ‘edges’ of the equivalence class (e.g. NULL, empty, min, max)

## Errors in Python

### Exceptions:

# create a custom exception
class MyException(BaseException):
def __init__(self, messages):
self.messages = messages

# raise an exception
raise MyException("a message")

# catch an exception
try:
# try to something that might raise an exception
except MyException:
# executed when MyException is raised
finally:
# always executed
else:
# executed when there is no exception


### Asserts:

def func():
x = 5
assert x > 0


### Testing With PyTest

import pytest

# check for exception being raised
with pytest.raises(BookingError) as info:
call_function()
assert info == "error message"


## Databases

### Database Design Steps:

1. Analyse requirements, identify data and operations
2. Model data at a high, abstract level (OO/ER models)
3. Create a database schema
4. Implement the database by creating an instance of the schema
5. Build operations/interface such as stored procedures, SQL
6. Tune performance
7. Evolve and develop schema

### Aims of Data Modelling:

• Describe the data stored
• Describe the relationships between data items
• Describe the constraints on data

## ER Diagrams

• Used for data modelling. Includes:
• Entities (e.g. a real world thing/object)
• Relationships (e.g. has, belongs to)
• Attributes (e.g. fields)
• Keys (e.g. primary/foreign/composite keys)
• Cardinality (e.g. one to one, one to many, many to many)
• Participation (e.g. total/partial participation)
• Inheritance
• Weak entity set has no primary key of its own and only exists because of association with strong entities
• Subclasses and inheritance:
• Subclasses can be overlapping (entity can be >= 0 subclasses) or disjoint (entity can only be 1 subclass)
• Subclasses can be total (every entity must be >= 1 subclass) or partial (an entity may be a subclass)

## Relational Data Model

• Used for modelling tables and their relationships. Includes:
• Table name
• Attributes (are atomic - no composite/multi-values attributes. belong to a domain (name data type and format))

### Database Schema:

• Used to model relationships between relational data models
• Uses arrows to show the relationship between table primary/foreign keys

### Mapping ER Diagram to Relational Data Model

The following ER concepts map to a relational data model:

• ER attribute → attribute (atomic)
• ER entity-instance/relationship-instance → tuple (row)
• ER entity-set/relationship → relation (table)
• ER key → primary key of relation

## Software Architecture

An architecture style is defined by:

• Components
• A collection of computational units that ‘do the work’. For example: classes, processes
• Connectors
• Enable communication between components. For example: functions, events
• Constraints
• Define how the components can be combined to form the system. For example: how data flows in regards to components/connectors

### Types of software architectures:

• Client/Server
• Components: server, client. Connector: request/response model.
• 2-tiered, n-tiered or multi-tiered
• Server provides a service, a client requests this service
• For example: WWW, REST, SOAP, email server
• P2P
• Component: peers. Connector: request/response model.
• Each peer can function as both a server and a client
• For example: bittorrent
• Pipe and Filter
• Component: filter. Connector: pipe.
• Output from one source is used as input to another
• Can run concurrently if only parts of the input data is needed at one time
• For example: compilers, unix pipes
• Central Repository
• Components: a data repository and a data accessor. Connectors: read/write mechanism
• For example: database, git
• Publish-Subscribe
• Components: publisher components, subscriber components. Connector: notifications/events
• For example: blogs, real time stock updates, wireless sensor networks
• Service Oriented Architecture (SOA)
• Components: servers. Connector: request/response, SOAP, REST, AJAX
• Platform independent, loosely coupled software as a service
• For example: Amazon Web Services (AWS), B2B services

## Diagrams

### Use Case Diagram

• Used for functional requirements analysis
• Has:
• Actors - can <<initiate>>, <<participate>> or both
• Use Cases - can <<include>> other use cases, or <<extend>> from a use case
• ――――― Solid line from Actor → Use Case
• ----- Dashed line from Use Case → Use Case

### Domain Model (Class Diagram)

• Displays how elements of system-to-be interact to produce external behaviour
• Has:
• Entities (classes)
• Attributes (private and public) - attributes have a data type
• Methods (private and public) - methods have a return data type
• Relationships (1, 0..*) - relationships also have names and a direction signified by an arrow/triangle
• Inheritance - subclasses can inherit from superclasses, this is represented by an arrow pointing to the superclass
• Association (aggregation or composition) - aggregation uses an open diamond ◇ and composition uses a closed diamond ◆.

### ER Diagram

• Used to model data and the relationships between entities
• Has:
• Entities - can be strong or weak (existance depends on a strong entity existing), is modelled after a real world object
• Relationships - relates $\ge$ 2 entities, has cardinality (1-1, 1-n, n-n), has participation (total or partial)
• Attributes - properties specific to an entity, can be simple, composite (made up of other attributes), multi-valued (have a set of values), derived (calculated at runtime from multiple attributes)
• Inheritance - overlapping (can be multiple subclasses, or neither), disjoint (has to be only one subclass), total (has to be a subclass) or partial (can be parent class)

### ER Relational Model

• Displays a collection of relations between tables
• Has:
• Tables (entities)
• Fields (attributes) - primary and foreign keys are underlined
• Relationships - arrows from primary keys to foreign keys

### CRC Card

• Class, Responsibilities Collaborators
• Has:
• Class name
• List of responsibilities
• A collaborating class for each responsibility (if applicable)