SE 350 - Object-Oriented Software Development

Software Life Cycle and Documentation

Instructor: Stefan Mitsch

Learning Objectives

  • Understand software development life cycles
  • Understand documentation types
  • Build UML modeling skills

Software Development Life Cycle

Stage Activity Key Roles Deliverables
Planning Preliminary requirements, analysis, research, vision and scope Customer, sales, analyst Understanding the customer needs, basic project roadmap and technical recommendations
Analysis Identify project goals, functionality, specifications, requirements Customer, analyst, tech experts, project managers Complete functional and design specification, work breakdown structure, initial cost estimate
Design Define system architecture, UI design Architect, UI/UX, project manager Draft system architecture, product design, refined cost estimate
Implementation Software development Software engineer, architect, project manager Functioning software product
Testing Quality assurance Software engineer, test engineer, project manager, customer Finalized software product
Maintenance Deployment, support, updates Software engineer, project manager Updated product

diagram

Types of Software Documentation

Software documentation spans process vs. product documentation; product documentation is system documentation or user documentation.

Design Documentation: UML

  • Unified Modeling Language
    • visual modeling
    • specify, visualize, document
  • History
    • Before 1995: fragmented methods
    • 1995: unification (Grady Booch, Ivar Jacobson, James Rumbaugh)
    • 1997: UML 1.0 (HP, IBM, Microsoft, Oracle, ...)
    • 1998: standardization
    • 1999: industrialization
    • Today: UML 2.5.1

UML Building Blocks

  • Things
    • Structural: class, object, interface, use case, actor, component, node
    • Behavioral: state machine, activity, interaction
    • Grouping: package
    • Annotational: note
  • Relationships
    • Dependency, association
    • Generalization, realization

UML Diagram Types

  • Structure
    • Classes, objects
    • Documents static aspect of software
  • Behavior
    • Interaction between software elements and users
    • (Information) flow between components
    • Documents dynamic aspect of software

diagram

UML Class Diagram

  • Static view of software: classes and their relationships between them
  • Documents analysis and design, responsibilites
  • Builds a dictionary for other diagrams
  • Communication with non-development stakeholders
Analysis

diagram

Design

diagram

Implement

diagram

diagram

UML Class Diagram Components

  • Top section: Class name
    • Abstract class: italics or <<abstract>>
  • Middle section: Attributes
    • Visibility: + public, # protected, - private
    • Type in attributeName : type notation
  • Lower section: Methods
    • Visibility + public, # protected, - private
    • Argument types and return type in notation methodName(arg1 : Type1, ...) : Type
    • Abstract method: italics

diagram

Class Diagram Relationships

  • Dependency
    • One class depends on another class
    • uses-a relationship
  • Generalization
    • Inheritance
    • is-a relationship
  • Association
    • weak has-a
    • Aggregation: has-a, is-part-of
    • Composition
      • strong has-a, belongs-to
      • Deallocated together

diagram

diagram

Dependency

  • Denotes a weak dependency between classes
  • Temporary, e.g., as argument to a method
  • uses-a relationship (always directed)
  • Example: A uses-a B method in a class temporarily uses object of another class
  • Example: A uses-a B change in B may affect A

diagram

diagram

Generalization

  • Inheritance between classes
  • is-a relationship
  • Generalization: factor common features of objects into base class
  • Specialization: override common features in sub-class

diagram

Generalization vs. Specialization

  • Generalization: factor common features of objects into base class
  • Specialization: override common features in sub-class

Generalization

Freight generalizes bag

diagram

Specialization

Cargo specializes Freight

diagram

diagram

Realization and Implementation

  • Class realizes/implements interface
  • A realizes B, A implements B

diagram

diagram

Association

  • Permanent structural relationship, e.g., field with reference to another object
  • Undirected: both classes know about each other
  • Optional direction denotes has-a relationship: parent has reference to dependent class and can invoke its methods

diagram

diagram

Aggregation

  • Strong permanent structural relationship
  • Whole-part has-a relationship
  • Always directional: one class has-a other class
  • Objects of both classes can survive individually
    • Can be allocated separately
    • Can change to different object, e.g., with setters

diagram

Composition

  • Strong aggregation
  • has-a relationship
  • Mutually dependent classes
  • Parent unusable without dependent class
    • Parent initialized with dependent object, e.g., in constructor
  • Objects of dependent class destroyed with parent object

diagram

Relationship Examples

diagram

diagram

diagram

diagram

// Dependency
public class EnrollmentService {
  public void enroll(s : Student, c : Course) {}
}

// Association (has-a)
public class Order {
  private Customer customer;
}

// Aggregation (has-a + whole-part)
public class PlayList {
  private List<Song> songs;
}

// Composition (has-a + ownership)
public class Apartment {
  private Room bedroom = new Room();
}

Multiplicity of Associations

  • How many objects of a class are related to how many objects of other class
    • * 0 or more
    • 1 exactly 1
    • 2..5 between 2 and 5, inclusive
    • 3..* 3 or more

diagram

Class and Attributes

diagram

public class Person {
  private String name;
  private int age;
}

Constructors

diagram

public class Person {
  private String name;
  private int age;

  public Person(String name) {
    // unspecified
  }
}

Methods

diagram

public class Person {
  private String name;
  private int age;

  public Person(String name) {
    // unspecified
  }

  public void print() {
    // unspecified
  }

  public String getName() {
    // unspecified
  }
}

Class Member Visibility and Modifier Recap

Java UML Description
public + Can be accessed from any object
private - Only visible to objects of the defining class
protected # Visible to objects of the defining class or a subclass of it
package ~ Visible to objects of classes in the same package

Connections between Classes

  • Roles annotated close to their class, e.g., a Person has role author in association to a Book

diagram

public class Book {
  private String title;  
  private Person author;
  // ...
}

Connections between Classes

diagram

public class Book {
  private String title;
  private List<Person> authors;

  public List<Person> getAuthors() {
    // unspecified
  }

  public void addAuthor(Person author) {
    // unspecified
  }
}

Associations, Aggregations, Compositions

diagram

public class University {
  private List<Department> departments;
}

public class Department {
  private List<Professor> professors;
}

public class Professor {
  private Department department;
  private List<Professor> collaborators;
}

Exercise: Ticket and Show

  • Implement the classes in the diagram in Java

diagram

Solution 
public class Show {
  private String movie;
  private String time;
}

public class Ticket {
  private int seat;
  private int code;
  private Show show;
}

Exercise: Bidirectional Association

diagram

Solution 
public class Book {
  private String title;
  private List<Person> authors;
}

public class Person {
  private String name;
  private List<Book> books;
}

Exercise: Student at University

diagram

Solution 
public class Student {
  private int id;
  private String name;
  private University university;
}

public class University {
  private String name;
  private List<Student> students;
}

Exercise: Inheritance

diagram

Solution 
public abstract class Part {
  private String id;
  private String manufacturer;
}

public class Engine extends Part {
  private String type;
}

Exercise: Player and Bot

diagram

Solution 
public abstract class Player {
  private String name;
  public abstract void play();
  public String print() {
    // unspecified
  }  
}

public class Bot extends Player {
  @Override
  public void play() {
    // unspecified
  }
  public void addMove(String move) {
    // unspecified
  }
}

Interfaces

  • Interfaces are identified with annotation <<interface>>, otherwise like classes

diagram

public interface Readable {

}

public class Book implements Readable {

}

Exercise: Implement an Interface

diagram

Solution 
public interface Saveable {
  void save();
  void delete();
  void load(String address);
}

public class Person implements Saveable {
  private String name;
  private String address;

  public void save() { /* unspecified */ }
  public void delete() { /* unspecified */ }
  public void load() { /* unspecified */ }
}

Exercise: A Larger Example

diagram

Solution 
public interface IA {}
public interface IB {}
public interface IC {}
public class A implements IA {}
public class B extends A implements IB {}
public class C extends B implements IC {
  private List<E> es;
}
public class D {
  private IA ia;
}
public class E {
  private List<C> cs;
}

Exercise: Read UML

diagram

  • Relationship between Vertebrate and Animal?

    Solution

    Vertebrate is a subclass of Animal

  • What is wrong with this relationship?

    Solution

    Because Animal is an interface and Vertebrate a class, the relationship should be realize (dashed)

  • Relationship between Snake and Animal?

    Solution

    Snake is a subclass of Animal

  • Relationship between Mongoose and Snake?

    Solution

    It is a dependency association

  • Can 2 Mongoose eat 1 Snake?

    Solution

    No, the relationship is one-to-any (1 Snake can be eaten by 1 Mongoose, but 1 Mongoose can eat any number of Snakes).

Exercise: Multiplicity

diagram

  • What is the relationship between pet and owner?

    Solution
    Association

  • How many pets can an owner have?

    Solution
    1 owner can have 1 or more pets

  • How many owners can a pet have?

    Solution
    A pet can be owned by exactly 1 owner

Exercise: Multiplicity

diagram

Solution
  • A CPU works with any number of Controllers, a Controller with exactly 1 CPU
  • 1-4 Disks are associated with 1 SCSIController
  • A SCSIController is a special Controller

Example: Bank

diagram

Solution
  • A Bank has any number of Accounts, an Account is managed by exactly 1 Bank
  • Checking and Savings are Accounts

Example: Home Heating System

diagram

Solution
  • Each Thermostat is observing 1 Room
  • Each Thermostat is controlling any number of Heaters
  • ElectricHeater is a specialized Heater
  • AubeTH101D is a specialized Thermostat

Example: Printer

public class Printer {
  private Job current;
  public void print();
  public boolean busy();
  public boolean on();
}

public class Job {}

public class Queue {
  private List<Job> jobs;
  private Printer printer;
  private Registry registry;
  public void newJob();
  public int length();
}

public class Registry {
  public Queue findQueue();
}
Solution

diagram

UML Specification and Cheat Sheets

Some visual elements