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
• Disadvantages:
  • 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
    • Business modelling and requirements
    • 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

Advantages:

• 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
• Focused on business value

Disadvantages:

• 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
• Adaptability over predictability
• 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
  • Task planing
    • 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
  • Advantages include: readability, reusability, testability, high cohesion
• 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)