BCS1430
Dr. Ashish Sai
đ Week 2 Lecture 1 & 2
đť BCS1430.ashish.nl
đ EPD150 MSM Conference Hall
Analyze the system
Model the system
Design the software
âď¸
Design is a conceptual solution that meets the requirements â how can we solve the problem
Object-Oriented Design (OOD):
flowchart LR
A[Analysis] --> B[Design] --> C[Implementation \n Java]
Modularity: Degree to which a system or computer program is composed of discrete components such that a change to one component has minimal impact on other components. ( ISO/IEC 2011)
Reusability: Objects and classes created for one project can be used in another, reducing development time and increasing productivity.
Degree to which an asset can be used in more than one system, or in building other assets. (ISO 25010)
OOA is the investigative phase where you dive deep into the problem domain.
Ask the right questions and identify the objects and interactions.
Goal: Create a model of the real world that can be translated into a software system.
Itâs easier to change a design than to change a built system.
Turn the conceptual model (from OOA) into a blueprint for building the system.
Decompose about the system architecture, the choice of system components etc.
ISO 25010 defines software quality with a comprehensive set of attributes:
Definition: The degree to which a product or system provides functions that meet stated and implied needs when used under specified conditions
Key Aspects:
Definition: Reliability is about the softwareâs capacity to maintain its performance level under stated conditions for a specified period.
Key Aspects:
Definition: Usability refers to how well a product or system can be used to achieve specified goals effectively, efficiently, and satisfactorily.
Key Aspects:
Definition: Efficiency relates to the relationship between the performance level of the software and the amount of resources used, under stated conditions.
Key Aspects:
Definition: Maintainability is the ease with which the software can be modified to correct faults, improve performance, adapt to a changed environment, or enhance the product.
Key Aspects:
Requirements are descriptions of the systemâs features, and constraints.
Key Points:
Essential for guiding development and testing.
Help in setting customer expectations.
Basis for project planning and design decisions.
Software Requirements:
Functional Requirements
Non-functional Requirements
Domain Requirements
Functional Requirements describe:
Functional Requirements Characteristics:
Clearly state what the system should do.
Include calculations, technical details, data manipulation and processing, and other specific functionality.
Example:
âThe system shall allow users to enter their credentials to log in.â
âUpon receiving a userâs input, the system shall calculate and display the results within 2 seconds.â
Non-functional requirements set criteria to judge the operation of a system, rather than specific behaviors, including constraints on the system and standards.
Types:
Performance: Speed, responsiveness, consumption.
Reliability: Frequency of failure, recoverability.
Usability: Understandability, learnability, operability.
Security: Access control, integrity, confidentiality.
Example:
âThe system should load the homepage in under 3 seconds when accessed from a standard broadband connection.â
âUser data should be encrypted using industry-standard encryption algorithms.â
Domain requirements reflect domain-specific knowledge, standards, or regulations that the software must comply with.
Key Aspects:
Reflect application domain behavior.
Influence system functionality and performance.
Include legal and regulatory requirements.
Example:
âThe software must store medical data in compliance with healthcare regulations.â
âThe system must perform currency conversion according to international financial standards.â
Requirements gathering is the process of collecting the needs and specifications from stakeholders to design a system that meets their expectations.
Understand stakeholder needs, and translate those into technical specifications.
Stakeholders are:
Example:
A use case is a detailed description of how users perform tasks, outlining a systemâs behavior from a userâs perspective.
Use cases are essential for understanding complex user interactions and system responses. They help in:
Visualizing system functionality.
Identifying potential issues.
Providing a framework for tests.
Communicating requirements across teams.
Description: This use case describes how a customer can enter a new order into the system.
Actors:
Customer
System
Market
Preconditions: Customer is logged on to the website.
Postconditions:
The trade has been processed.
The Customer has received the confirmation from the system.
| Step ID | Actor | Action | Notes and References |
|---|---|---|---|
| BF-1 | Customer | Customer navigates to the order entry page. | |
| BF-2 | System | System displays the order entry page. | |
| BF-3 | Customer | Customer enters the following order details: Buy/Sell, Quantity, Stock Symbol | |
| BF-4 | Customer | Customer submits the order. | |
| BF-5 | System | System validates the information entered by the customer. | AF-1: Customer enters invalid information |
| BF-6 | System | System submits the order to the marketplace. | |
| BF-7 | Market | Market executes the order. | |
| BF-8 | Market | Market sends the execution report to the system. | |
| BF-9 | System | System displays the execution report to the customer. |
AF-1: Customer enters invalid information
| Step ID | Actor | Action | Notes and References |
|---|---|---|---|
| AF-1-1 | System | If the customer has entered invalid information the system will display an error message: âYou have entered invalid information.â | |
| AF-1-2 | Customer | Customer corrects the information and resubmits. | |
| AF-1-3 | [Go to BF-5] |
EF-1: System is down or unavailable
| Step ID | Actor | Action | Notes and References |
|---|---|---|---|
| EF-1-1 | System | If the system is down/unavailable the system will display a message to the customer: âThe system is currently unavailable.â | |
| EF-1-2 | [Use case ends] |
EF-2: System cannot connect to the market
| Step ID | Actor | Action | Notes and References |
|---|---|---|---|
| EF-1-1 | System | If the system cannot connect to the market the system will display a message to the customer: âThe system cannot connect to the market. Please try again later.â | |
| EF-1-2 | [Use case ends] |
| ID | Name | Description |
|---|---|---|
| SR-1 | Tabbing | The system will enable the user to tab from field to field on the order entry page. |
User-Centric Design: Focus on user actions and system responses.
Detailing Flows: Clear definition of basic, alternate, and exception flows.
Supplemental Requirements: Address additional user experience enhancements.
Adaptability: The use caseâs structure allows for easy updates and modifications.
Not all requirements are of equal importance.
Evaluate the urgency, value, and feasibility of each requirement. (Prioritization)
Technique(s): MoSCoW (Must have, Should have, Could have, Wonât have this time)
MoSCoW technique is a prioritization tool used to reach a common understanding on the importance of various requirements.
Components:
Must have (M): Essential features, required for successful and functional project.
Should have (S): Important but not vital features.
Could have (C): Desirable features that are beneficial but not crucial.
Wonât have this time (W): Features that, may be useful, are not a priority for this iteration.
Starbucks introduced Mobile Order & Pay to allows customers to place orders and pay in advance to reduce waiting times.
Objectives:
Improve customer satisfaction by reducing in-store waiting times.
Increase operational efficiency and order accuracy.
Enhance the customerâs personalization and convenience.
Actor: Customer
Preconditions:
The customer has the Starbucks mobile app installed.
The customer has an account with payment information.
Basic Flow:
The customer opens the app and selects the âOrderâ option.
The customer browses the menu and selects items to order.
The customer reviews the order and makes any modifications.
The customer confirms the order and selects a pickup location.
The customer pays for the order through the app.
The system sends the order to the selected store.
The customer receives a notification when the order is ready for pickup.
Postconditions:
Functional Requirements:
FR1: The app must allow users to browse the menu and select items.
FR2: The app must provide an option for order modification before confirmation.
FR3: The app must securely process payment information.
FR4: The system must send the order to the selected store and confirm readiness through a notification.
Non-Functional Requirements:
NFR1: The app should load the menu within 2 seconds (Performance).
NFR2: The payment system must comply with PCI DSS standards (Security).
NFR3: The app should be accessible and user-friendly (Usability).
NFR4: The system should handle 1000 orders simultaneously without performance degradation (Scalability).
Must have (M):
FR1: Browse menu and select items - critical for basic functionality.
FR3: Securely process payment - essential for trust and legal compliance.
Should have (S):
Could have (C):
Wonât have this time (W): - Advanced custom ordering options that require new technology.
Must have (M):
NFR2: Compliance with PCI DSS for payment security - non-negotiable.
NFR3: Basic app usability - essential for user adoption.
Should have (S):
Could have (C):
Wonât have this time (W):
Changes in requirements are a natural and expected part of the software development lifecycle.
Reasons:
When requirements change, the effects ripple through the project.
These changes can impact project scope, timelines, costs, and even the overall quality of the product.
What is OOA?
Methodical approach to understanding and modeling a system by viewing it through the lens of the âobjectsâ (real-world entities) it involves.
Key Aspects:
- Understanding the Domain: Examining the problem or system from an object-centric perspective.
- Capturing Requirements: Identifying what the system must do from the viewpoint of the objects.
- Defining the System: Creating a model that effectively addresses and fulfills the identified needs.
Core Concepts:
- Objects: Instances from the problem domain represented in the system.
- Classes: Blueprints defining attributes and behaviors of objects.
Process:
Examine the Domain: Analyze the real-world scenario to model.
Spot Key Entities: Identify significant entities that play vital roles.
Define Nature and Functionality: Determine attributes and operations for each entity.
Example: - Library System: Key objects like books, members, and loans with specific attributes and behaviors.
Objects do not exist in isolation!
Types of Relationships:
Associations: Simple connections between objects.
Aggregations: Whole-part relationships indicating a collective.
Compositions: Strong whole-part relationships with dependency.
Example: - E-commerce Platform: âCustomerâ places an âOrderâ containing âProductsâ.
Definition:
Represents a âuse-aâ or âhas-aâ relationship where one object uses or interacts with another.
class Customer {
private Order order;
void placeOrder() { /*...*/ }
}
class Order {
// Order related methods
}Here, a Customer has an association with Order as it places an order. This is a one-to-one relationship.
Definition:
A specialized form of association representing a âwhole-partâ relationship, with objects having their own life cycle but forming a whole.
Denotes a âhas-aâ relationship.
The part can exist independently of the whole.
A Team consists of multiple Players. Players can exist without a team, illustrating the whole-part relationship.
Definition:
Composition is a strong form of aggregation implying ownership. When the whole is destroyed, so are the parts.
Represents a strong âcontains-aâ relationship.
The life cycle of the part is tied to the whole.
class Engine {
// Engine specific methods
}
class Car {
private Engine engine = new Engine();
void start() { /* Starts the engine */ }
}A Car has a Engine as part of its composition. If the car ceases to exist, so does the engine, indicating a strong dependency.
Object Interaction Analysis is a technique used to understand how objects in the system will communicate and collaborate.
Interaction diagrams are used to visualize these interactions 1.
Class-Responsibility-Collaborator (CRC) Cards:
CRC cards is a simple tool used to define the behaviors and interactions of classes.
Components of a CRC Card:
Class Name: The entity or concept being modeled.
Responsibilities: What the class should know or do (its behavior).
Collaborators: Other classes this class interacts with or uses.
Class Name: ShoppingCart
Responsibilities:
Add Item: Include a new product in the cart.
Calculate Total: Compute the total cost of items in the cart.
Remove Item: Take out a product from the cart.
Checkout: Initiate the purchasing process.
Collaborators:
Product: Items that can be added to the shopping cart.
User: The customer who owns the shopping cart.
class ShoppingCart {
private List<Product> products;
private User owner;
void addItem(Product product) { /*...*/ }
double calculateTotal() { /*...*/ }
void removeItem(Product product) { /*...*/ }
void checkout() { /*...*/ }
}
class Product { /* Product details */ }
class User { /* User details */ }The ShoppingCart class has clear responsibilities like managing items and calculating totals, and it collaborates with Product and User classes to fulfill these responsibilities.
Beyond aesthetics, good software design is about crafting solutions that are effective, efficient, and maintainable.
Itâs the art of making complex systems understandable and usable.
Key Attributes:
In Practice:
In Practice:
In Practice:
// Package for order processing
package com.company.orderprocessing;
public class OrderProcessor { /*...*/ }
// Separate package for customer management
package com.company.customermanagement;
public class CustomerManager { /*...*/ }Impact: - Enhances flexibility, manageability, and scalability.
In Practice:
// Simple, clear form submission feedback
if(submissionSuccess) {
displayMessage("Form submitted successfully!");
} else {
displayMessage("Submission failed. Please try again.");
}Impact:
Concept:
In Practice:
/**
* Calculates the monthly payment for a given loan.
* @param loanAmount Total amount of the loan.
* @param termInYears Number of years for the loan.
* @param interestRate Annual interest rate.
* @return The monthly payment amount.
*/
public double calculateMonthlyPayment(double loanAmount, int termInYears, double interestRate) { /*...*/ }Impact:
Concept:
In Practice:
try {
// Attempt a risky operation
} catch (SpecificException e) {
// Handle exception and provide recovery options
}Impact: - Keeps systems stable and functional under various conditions, enhancing reliability.
Challenges:
Users struggled with a complex booking process and inconsistent interface.
Hosts were concerned about guest reliability.
Design Strategy:
Simplified Booking: Streamlined steps for easier navigation and user understanding.
Consistent Visual Language: Unified colors, typography, and buttons for intuitive use.
Modular Design System: Flexible and scalable, allowing easy updates and feature additions.
Read more: https://airbnb.design
Usability Improvements:
Transparent interfaces with better listings and improved review systems.
Enhanced error handling offering clear feedback and recovery options.
Impact:
Marked increase in bookings and user engagement post-redesign.
Strengthened brand recognition as a reliable and user-friendly lodging option.
Read more: How Design Thinking Transformed Airbnb from a Failing Startup to a Billion Dollar Business
DRY (Donât Repeat Yourself): Avoid duplication.
KISS (Keep It Simple, Stupid): Keep the design simple and straightforward.
YAGNI (You Arenât Gonna Need It): Donât implement something until it is necessary.
Definition: Avoid duplication in code. Every piece of knowledge should have a single, unambiguous representation in the system.
Impact:
Definition: Simplicity in design. Avoid unnecessary complexity and keep things straightforward.
Impact:
Definition: Implement only those features that are necessary. Avoid adding functionality until it is required.
Impact:
Separation of Concerns: Different functionality managed by separate code.
Principle of Least Astonishment: Software behaves how users will expect it to.
Law of Demeter: Object should assume as little as possible about the structure or properties of anything else.
Definition:
Impact:
// After: Separated data access and business logic
class UserDataAccess {
void saveUser(User user) { /* Database code to save user */ }
}
class UserHandler {
UserDataAccess dataAccess = new UserDataAccess();
void createUser(String username) {
User user = new User(username);
dataAccess.saveUser(user); // Separated concern
}
}Definition:
Impact:
Definition:
Impact:
What is GRASP?
General Responsibility Assignment Software Patterns (GRASP) are guidelines for assigning responsibilities in object-oriented design to improve robustness and maintainability.
Principles Overview:
Information Expert: Responsibilities go to the class with the most related information.
Creator: The class that needs an object or has initializing data should create it.
Controller: Designate a class to handle system events and user input.
Low Coupling: Minimize class interdependencies for flexibility.
High Cohesion: Keep related functions together for focused class design.
Polymorphism: Handle alternatives based on object types dynamically.
Pure Fabrication: Create classes for better design, even if they donât represent real-world entities.
Principle: Assign responsibility to the class that has the necessary information to fulfill it.
Benefits:
Reduces redundancy and complexity.
Enhances maintainability and cohesion.
Makes the system more modular and easier to navigate.
Application:
class Order {
private List<Item> items;
// Other Order related methods...
}
class OrderCalculator {
// This class is wrongly taking the responsibility of calculating the total
double calculateTotalCost(Order order) {
double total = 0;
for(Item item : order.getItems()) {
total += item.getPrice();
}
return total;
}
}OrderCalculator is taking the responsibility that naturally belongs to the Order class, leading to a less intuitive and more fragmented design.Order class.Principle: Assign class B the responsibility to create an instance of class A if B closely uses A or holds the data that will initialize A.
Benefits:
Enhances encapsulation and clarity.
Reduces dependencies and coupling between classes.
Simplifies the systemâs structure.
Application:
// Order is responsible for creating Item instances, but it doesn't directly contain or closely use them
class Order {
void addNewItem() {
Item newItem = new Item(); // Order creates Item instances
// ...
}
}
class ShoppingCart {
private List<Item> items;
// ShoppingCart logic...
}Problem:
Order class is creating Item instances, but it doesnât have a logical or direct relationship with Item, leading to poor encapsulation and design.Item instances to the ShoppingCart class, which logically contains and manages items.Principle: Assign the responsibility of handling a system event to a class representing the overall system, a root object, or a subsystem.
Benefits:
Centralizes control logic.
Decouples the UI from the underlying business logic.
Simplifies maintenance and enhances scalability.
Application:
class UserInterface {
// Directly handling user input and business logic
void onLoginButtonClick(String username, String password) {
// Validate credentials
// Directly access the database to verify user
// Manage session
}
}UserInterface class is overloaded with responsibilities, handling UI events, business logic, and data access, making the system hard to maintain and scale.Solution:
class UserInterface {
// Delegates handling of the login event to the LoginController
void onLoginButtonClick(String username, String password) {
LoginController controller = new LoginController();
controller.handleLoginRequest(username, password);
}
}
class LoginController {
AuthenticationService authService;
void handleLoginRequest(String username, String password) {
// Handle the login process
User user = authService.authenticate(username, password);
// Manage session and other login-related tasks
}
}Definition:
// High Coupling: Direct dependency
class Order {
Payment payment;
void processOrder() { payment.processPayment(); }
}
// Low Coupling: Reduced dependency
class Order {
PaymentProcessor processor;
void processOrder() { processor.processPayment(); }
}
class PaymentProcessor {
void processPayment() { /*...*/ }
}Principle: Design to minimize the dependencies between classes to reduce the impact of changes and improve reusability.
Benefits:
Increases the flexibility of the system.
Makes the codebase more resilient to changes.
Facilitates easier testing and maintenance.
Application:
class User {
// Directly dependent on specific storage implementation
FileStorage storage;
void saveUserData() {
// Directly uses FileStorage methods
storage.writeData(this);
}
}User class is highly coupled with FileStorage, making it difficult to change storage methods or test the User class independently.Solution:
User and FileStorage.Definition: - Cohesion refers to the degree to which elements of a module or class belong together.
Principle: Keep related and similar functionalities together in a class, ensuring that each class has a clear, narrowly focused role.
Benefits:
Simplifies understanding of the system.
Enhances the ability to manage and modify code.
Promotes single responsibility and focused class design.
Application: - Essential in ensuring that the system remains organized and each part is as independent and focused as possible, promoting better design and easier future changes.
class UserManager {
void createUser() { /*...*/ }
void deleteUser() { /*...*/ }
void generateReport() { /* Unrelated to user management */ }
}UserManager is handling both user management and report generation, making it less cohesive and more complex.class UserManager {
void createUser() { /*...*/ }
void deleteUser() { /*...*/ }
// Removed report generation
}
class ReportGenerator {
void generateReport() { /* Focused on report generation */ }
}UserManager and ReportGenerator makes each class more focused, understandable, and maintainable.Principle: Use polymorphism to handle alternatives based on object type, where the behavior varies depending on the class of the object.
Benefits:
Enhances flexibility and reusability by allowing different classes to be used interchangeably.
Simplifies code by eliminating the need for multiple conditional statements.
Application:
class AnimalSound {
void makeSound(Animal animal) {
if (animal instanceof Dog) {
System.out.println("Woof");
} else if (animal instanceof Cat) {
System.out.println("Meow");
}
// More conditions for other animal types
}
}
class Dog extends Animal { /*...*/ }
class Cat extends Animal { /*...*/ }AnimalSound class becomes cumbersome and difficult to maintain as more animal types are added.abstract class Animal {
abstract void makeSound();
}
class Dog extends Animal {
void makeSound() { System.out.println("Woof"); }
}
class Cat extends Animal {
void makeSound() { System.out.println("Meow"); }
}
class AnimalSound {
void makeSound(Animal animal) {
animal.makeSound(); // Polymorphism in action
}
}AnimalSound and making the code more scalable and maintainable.Principle: Create a class that doesnât represent a concept in the problem domain, particularly to achieve low coupling, high cohesion, or to encapsulate change.
Benefits:
Enhances maintainability and reusability.
Allows for better separation of concerns and encapsulation.
Application:
class Order {
// Order related data and methods...
void saveOrder() {
// Direct database access code to save the order
// This mixes business logic with data access logic
}
}Order class is directly handling database operations, which is not its primary responsibility, leading to a design thatâs hard to maintain and scale.class Order {
// Order related data and methods...
}
class OrderRepository {
void saveOrder(Order order) {
// Specific database access code to save the order
}
}OrderRepository is a pure fabrication that takes over database responsibilities, leading to a cleaner separation of concerns and a more maintainable design.What is SOLID?
SOLID represents five fundamental principles in object-oriented programming and design that promote software maintainability and extensibility.
Key Objectives:
Single Responsibility: Encourage classes to have one reason to change.
Open/Closed: Design modules that are open for extension but closed for modification.
Liskov Substitution: Ensure subclasses can replace their superclasses without altering the programâs correctness.
Interface Segregation: Favor client-specific interfaces over general-purpose ones.
Dependency Inversion: Depend on abstractions rather than concrete implementations.
Definition:
A class should have one, and only one, reason to change, promoting modularity and separation of concerns.
Importance:
Simplifies understanding and modification of classes.
Enhances cohesion and reduces the impact of changes.
class UserManager {
void createUser() { /*...*/ }
void sendEmail(String message) { /*...*/ } // Unrelated to user management
}UserManager handling both user creation and email sending mixes different concerns, making it less cohesive and more prone to errors.class UserManager {
void createUser() { /*...*/ }
}
class EmailService {
void sendEmail(String message) { /*...*/ }
}Definition:
Software entities should be open for extension but closed for modification, promoting flexible and scalable systems.
How?:
class GraphicEditor {
void drawShape(Shape shape) {
if (shape.type == 1) {
drawRectangle(shape);
} else if (shape.type == 2) {
drawCircle(shape);
}
// Adding a new shape requires modifying this method
}
}GraphicEditor, violating the open/closed principle.abstract class Shape {
abstract void draw();
}
class Rectangle extends Shape {
void draw() { /* Draw rectangle */ }
}
class Circle extends Shape {
void draw() { /* Draw circle */ }
}
class GraphicEditor {
void drawShape(Shape shape) {
shape.draw(); // No modification needed for new shapes
}
}GraphicEditor, adhering to the open/closed principle and making the system more extensible.Definition:
Subclasses should be substitutable for their base classes without affecting the programâs correctness.
Java Example:
class Bird {
void fly() { /*...*/ }
}
class Ostrich extends Bird {
// Ostriches can't fly, but they're subclassed from Bird
void fly() { throw new UnsupportedOperationException(); }
}Ostrich object where a Bird is expected can cause unexpected errors due to the overridden fly method.abstract class Bird {
// Some common bird behavior
}
class FlyingBird extends Bird {
void fly() { /* Implement flying */ }
}
class Ostrich extends Bird {
// Ostrich-specific behavior, no fly method
}FlyingBird and Ostrich are now both substitutable for Bird without causing unexpected behavior, adhering to the Liskov Substitution Principle.Definition:
Clients should not be forced to depend on interfaces they do not use, encouraging fine-grained interfaces over general-purpose ones.
interface Worker {
void work();
void eat();
void takeBreak();
}
class Robot implements Worker {
void work() { /*...*/ }
void eat() { /* Robots don't eat */ }
void takeBreak() { /* Robots don't take breaks */ }
}Robot is forced to implement eat and takeBreak, which are irrelevant to its functionality.interface Worker {
void work();
}
interface HumanWorker extends Worker {
void eat();
void takeBreak();
}
class Robot implements Worker {
void work() { /*...*/ }
}
class Human implements HumanWorker {
void work() { /*...*/ }
void eat() { /*...*/ }
void takeBreak() { /*...*/ }
}Robot now only implements the relevant Worker interface, and Human implements the extended HumanWorker interface. This segregation makes the system more flexible and maintainable.Definition:
High-level modules should not depend on low-level modules; both should depend on abstractions. Abstractions should not depend on details; details should depend on abstractions.
class OrderProcessor {
MySQLDatabase database; // Directly dependent on a specific database implementation
void processOrder(Order order) {
database.save(order); // Tightly coupled to MySQLDatabase
}
}OrderProcessor is directly dependent on MySQLDatabase, making it hard to switch to a different database or test the order processing independently.interface Database {
void save(Order order);
}
class MySQLDatabase implements Database {
void save(Order order) { /*...*/ }
}
class OrderProcessor {
Database database; // Depends on the abstraction
void processOrder(Order order) {
database.save(order); // Not tied to a specific implementation
}
}OrderProcessor now depends on the Database abstraction, not the concrete MySQLDatabase implementation. This makes the system more flexible and easier to modify or test.