0% found this document useful (0 votes)
15 views19 pages

SE Day1

Uploaded by

Suresh Naidu
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
15 views19 pages

SE Day1

Uploaded by

Suresh Naidu
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 19

SE & DP Lab

The Software Development Life Cycle (SDLC) is a systematic process employed to plan,
create, and assess high-quality software. It represents a structured methodology that outlines
the complete sequence of steps involved in software development.

Stages of the Software Development Life Cycle:

Stage 1: Planning and Requirement Analysis

Requirement analysis is the most important and fundamental


stage in SDLC. It is performed by the senior members of the
team with inputs from the customer, the sales department,
market surveys and domain experts in the industry. This
information is then used to plan the basic project approach and to
conduct product feasibility study in the economical, operational
and technical areas.

Stage 2: Defining Requirements


Once the requirement analysis is done the next step is to clearly
define and document the product requirements and get them
approved from the customer or the market analysts. This is done
through an SRS (Software Requirement Specification) document which
consists of all the product requirements to be designed and
developed during the project life cycle.
Stage 3: Designing the Product Architecture

SRS is the reference for product architects to come out with the
best architecture for the product to be developed. Based on the
requirements specified in SRS, usually more than one design
approach for the product architecture is proposed and
documented in a DDS - Design Document Specification.

This DDS is reviewed by all the important stakeholders and based


on various parameters as risk assessment, product robustness,
design modularity, budget and time constraints, the best design
approach is selected for the product.

SDLC Models
There are various software development life cycle models defined
and designed which are followed during the software
development process.

Following are the most important and popular SDLC models


followed in the industry –

Certainly, here's a concise list of some common Software


Development Life Cycle (SDLC) models:

1. Waterfall Model

2. Iterative Model

3. Incremental Model

4. V-Model (Verification and Validation Model)

5. Spiral Model

6. Agile Model

7. Scrum

8. Kanban
9. RAD (Rapid Application Development)

DESIGN PATTERNS:
Software design patterns are communicating objects and classes that are customized to
solve a general design problem in a particular context. Software design patterns are
general, reusable solutions to common problems that arise during the design and
development of software. They represent best practices for solving certain types of
problems and provide a way for developers to communicate about effective design
solutions. Design patterns capture expert knowledge and experience, making it easier for
developers to create scalable, maintainable, and flexible software systems.

Types of Design Patterns:

Abstract Factory Pattern:


The Abstract Factory Pattern is a creational design pattern that provides an
interface for creating families of related or dependent objects without
specifying their concrete classes, in simpler terms the Abstract Factory Pattern is a
way of organizing how you create groups of things that are related to each other.
RULES:
 Abstract Factory pattern is almost similar to Factory Pattern and is
considered as another layer of abstraction over factory pattern.
 Abstract Factory patterns work around a super-factory which creates other
factories.
 Abstract factory pattern implementation provides us with a framework that
allows us to create objects that follow a general pattern.
 So, at runtime, the abstract factory is coupled with any desired
concrete factory which can create objects of the desired type.

Source Code:
// Abstract Factory Interface
interface CarFactory {
Car createCar();
CarSpecification createSpecification();
}

// Concrete Factory for North America Cars


class NorthAmericaCarFactory implements CarFactory {
public Car createCar() {
return new Sedan ();
}

public CarSpecification createSpecification() {


return new NorthAmericaSpecification();
}
}

// Concrete Factory for Europe Cars


class EuropeCarFactory implements CarFactory {
public Car createCar() {
return new Hatchback ();
}

public CarSpecification createSpecification() {


return new EuropeSpecification();
}
}

// Abstract Product Interface for Cars


interface Car {
void assemble ();
}
// Abstract Product Interface for Car Specifications
interface CarSpecification {
void display ();
}

// Concrete Product for Sedan Car


class Sedan implements Car {
public void assemble () {
System.out.println("Assembling Sedan car.");
}
}

// Concrete Product for Hatchback Car


class Hatchback implements Car {
public void assemble() {
System.out.println("Assembling Hatchback car.");
}
}

// Concrete Product for North America Car Specification


class NorthAmericaSpecification implements CarSpecification {
public void display() {
System.out.println("North America Car Specification: Safety features
compliant with local regulations.");
}
}

// Concrete Product for Europe Car Specification


class EuropeSpecification implements CarSpecification {
public void display() {
System.out.println("Europe Car Specification: Fuel efficiency and emissions
compliant with EU standards.");
}
}

// Client Code
public class CarFactoryClient {
public static void main (String [] args) {
// Creating cars for North America
CarFactory northAmericaFactory = new NorthAmericaCarFactory();
Car northAmericaCar = northAmericaFactory.createCar();
CarSpecification northAmericaSpec = northAmericaFactory.createSpecification();
northAmericaCar.assemble();
northAmericaSpec.display();

// Creating cars for Europe


CarFactory europeFactory = new EuropeCarFactory();
Car europeCar = europeFactory.createCar();
CarSpecification europeSpec = europeFactory.createSpecification();

europeCar.assemble();
europeSpec.display();
}
}
Without factory pattern:
import java.io.*;

// Library classes
abstract class Vehicle {
public abstract void printVehicle();
}

class TwoWheeler extends Vehicle {


public void printVehicle() {
System.out.println("I am two wheeler");
}
}

class FourWheeler extends Vehicle {


public void printVehicle() {
System.out.println("I am four wheeler");
}
}

// Client (or user) class


class Client {
private Vehicle pVehicle;

public Client(int type) {


if (type == 1) {
pVehicle = new TwoWheeler();
} else if (type == 2) {
pVehicle = new FourWheeler();
} else {
pVehicle = null;
}
}

public void cleanup() {


if (pVehicle != null) {
pVehicle = null;
}
}

public Vehicle getVehicle() {


return pVehicle;
}
}

// Driver program
public class GFG {
public static void main(String[] args) {
Client pClient = new Client(1);
Vehicle pVehicle = pClient.getVehicle();
if (pVehicle != null) {
pVehicle.printVehicle();
}
pClient.cleanup();
}
}
Date: 18/03/2024

1. Define Classes:

 Product: This represents the complex object being built. It can have attributes
and methods specific to the final product.
 Builder (Abstract Class): This defines the interface for creating parts of the
Product object. It can have methods for setting different attributes of the
product (e.g., setName, setDescription).
 ConcreteBuilder: This class inherits from Builder and implements the
specific logic for building a particular variation of the Product. It implements
the Builder interface methods for constructing the desired product.
 Director: This class uses the Builder interface to construct complex objects
step by step. It can define the order of building steps and delegate them to the
ConcreteBuilder. (Director is optional and the Builder itself can be used for
simpler scenarios).

2. Create Class Diagram:

 Drag and drop the classes (Product, Builder, ConcreteBuilder, Director) onto
the workspace.
 Establish relationships between them:
o Product: Make it an abstract class (right-click, Properties, General, set
"Is Abstract" to True).
o Builder: Make it an abstract class.
o ConcreteBuilder: Show inheritance from Builder (right-click,
Inheritance, select Builder).
o Director (Optional): Show inheritance from another class or leave it as
a separate class.
 Define attributes and methods for each class:
o Product: Add attributes and methods specific to the final product.
o Builder: Add methods for setting different parts of the product
(e.g., setName(String name), setDescription(String description)).
These methods should return the Builder itself (use "this" keyword) to
allow method chaining for building step by step
(e.g., builder.setName("Product Name").setDescription("Product
Description")).
o ConcreteBuilder: Implement the Builder interface methods. These
methods typically involve setting the corresponding attribute in the
Product object being built and returning the Builder itself.
o Director (Optional): Define methods that use the Builder interface to
construct the Product in a specific order. These methods could
delegate calls to the ConcreteBuilder methods.

3. Define Design Pattern:

 Select all the classes involved (Product, Builder, ConcreteBuilder, Director).


 Right-click, select "Define Design Pattern...".
 Choose "Builder" from the list and click OK.

Additional Tips:

 You can use Rational Rose's code generation capabilities to generate code
skeletons for these classes based on the designed class diagram.
 Consider using visibility modifiers (public, private) to control access to
methods and attributes.
 You can further customize the Builder pattern by adding methods for optional
parts or validations.

Builder design pattern Example:

In the above UML class diagram, the Director class doesn't create and assemble the
ProductA1 and ProductB1 objects directly. Instead, the Director refers to the Builder interface
for building (creating and assembling) the parts of a complex object, which makes the
Director independent of which concrete classes are instantiated (which representation is
created). The Builder1 class implements the Builder interface by creating and assembling the
ProductA1 and ProductB1 objects.
The UML sequence diagram shows the run-time interactions: The Director object calls
buildPartA() on the Builder1 object, which creates and assembles the ProductA1 object.
Thereafter, the Director calls buildPartB() on Builder1, which creates and assembles the
ProductB1 object.
Key Differences between Abstract Factory and Builder design Pattern:

Abstract Factory

 Focuses on creating families of related objects.


 Ensures these objects are compatible and work together.
 Defines an interface for creating these families.
 Useful when you need to switch between creating different product families
(e.g., building a UI with Windows or Mac elements).

Builder

 Deals with constructing a single complex object in a step-by-step manner.


 Offers flexibility in customizing the object by allowing optional steps.
 Separates the object construction process from the client code.
 Often used when there are many possible configurations for the object (e.g.,
building a hamburger with various toppings).

Builder Design Pattern:


The Builder design pattern in Java is a creational design pattern used to construct complex
objects step by step. It allows the construction of an object to be done independently of
its representation. This pattern is particularly useful when dealing with objects that have
many optional parameters or configurations, as it simplifies the construction process and
improves readability.

Source Code:

// Product class
class Product {
private String part1;
private String part2;
private String part3;

public void setPart1(String part1) {


this.part1 = part1;
}
public void setPart2(String part2) {
this.part2 = part2;
}

public void setPart3(String part3) {


this.part3 = part3;
}

@Override
public String toString() {
return "Product{" +
"part1='" + part1 + '\'' +
", part2='" + part2 + '\'' +
", part3='" + part3 + '\'' +
'}';
}
}

// Builder interface
interface Builder {
void buildPart1(String part1);
void buildPart2(String part2);
void buildPart3(String part3);
Product getResult();
}

// Concrete builder
class ConcreteBuilder implements Builder {
private Product product;
public ConcreteBuilder() {
this.product = new Product();
}

@Override
public void buildPart1(String part1) {
product.setPart1(part1);
}

@Override
public void buildPart2(String part2) {
product.setPart2(part2);
}

@Override
public void buildPart3(String part3) {
product.setPart3(part3);
}

@Override
public Product getResult() {
return product;
}
}

// Director class
class Director {
private Builder builder;

public Director(Builder builder) {


this.builder = builder;
}

public Product construct() {


builder.buildPart1("Part 1");
builder.buildPart2("Part 2");
builder.buildPart3("Part 3");
return builder.getResult();
}
}

// Client code
public class Main {
public static void main(String[] args) {
Builder builder = new ConcreteBuilder();
Director director = new Director(builder);
Product product = director.construct();
System.out.println(product);
}
}

Output:
Product{part1='Part 1', part2='Part 2', part3='Part 3'}
Explanation:
// Product class: This line is a comment indicating that the following class is the definition of
the Product class.

class Product {: This line declares a class named Product, which represents the product we
want to build. This class has three private member variables: part1, part2, and part3.

private String part1;, private String part2;, private String part3;: These lines declare three
private member variables (part1, part2, and part3) of type String, representing the parts of the
product.

public void setPart1(String part1) { ... }, public void setPart2(String part2) { ... }, public void
setPart3(String part3) { ... }: These lines define setter methods for each part of the product.
These methods are used to set the values of the private member variables.

@Override public String toString() { ... }: This line overrides the toString() method inherited
from the Object class. It returns a string representation of the Product object, including its
parts (part1, part2, and part3).

// Builder interface: This line is a comment indicating that the following code defines the
Builder interface.

interface Builder {: This line declares an interface named Builder, which defines the
construction steps for building a product.

void buildPart1(String part1);, void buildPart2(String part2);, void buildPart3(String part3);:


These lines declare three abstract methods in the Builder interface: buildPart1(), buildPart2(),
and buildPart3(). These methods represent the steps to build each part of the product.

Product getResult();: This line declares an abstract method in the Builder interface named
getResult(), which is used to retrieve the final product after construction.

// Concrete builder: This line is a comment indicating that the following code defines a
concrete implementation of the Builder interface.
class ConcreteBuilder implements Builder {: This line declares a class named
ConcreteBuilder that implements the Builder interface. This class will be responsible for
building the product.

private Product product;: This line declares a private member variable product of type
Product, which represents the product being built by the concrete builder.

public ConcreteBuilder() { ... }: This constructor initializes the product member variable with
a new Product object when a ConcreteBuilder instance is created.

@Override public void buildPart1(String part1) { ... }, @Override public void


buildPart2(String part2) { ... }, @Override public void buildPart3(String part3) { ... }: These
lines override the methods declared in the Builder interface. Each method sets the
corresponding part of the product (part1, part2, or part3) in the Product object.

@Override public Product getResult() { ... }: This line overrides the getResult() method
declared in the Builder interface. It returns the fully constructed Product object.

// Director class: This line is a comment indicating that the following code defines the
Director class.

class Director {: This line declares a class named Director, which is responsible for directing
the construction process using a builder.

private Builder builder;: This line declares a private member variable builder of type Builder,
which holds a reference to the concrete builder.

public Director(Builder builder) { ... }: This constructor initializes the builder member
variable with the provided builder when a Director instance is created.

public Product construct() { ... }: This method orchestrates the construction process. It calls
the builder's methods (buildPart1(), buildPart2(), and buildPart3()) to build each part of the
product and then retrieves the final product using the getResult() method.

// Client code: This line is a comment indicating that the following code is the client code.
public class Main {: This line declares a public class named Main, which contains the main
method to start the program execution.

public static void main(String[] args) { ... }: This is the entry point of the program.

Builder builder = new ConcreteBuilder();: This line creates a new instance of the concrete
builder (ConcreteBuilder) and assigns it to a variable named builder.

Director director = new Director(builder);: This line creates a new instance of the director
(Director) and passes the builder to its constructor.

Product product = director.construct();: This line instructs the director to construct a product
using the assigned builder.

System.out.println(product);: This line prints out the product using its toString() method,
which was overridden to provide a string representation of its parts.

You might also like