Software Engineering Concepts

Engineering Design (CEAB Definition)

• The process of engineering design involves creatively solving problems while carefully considering both technical knowledge and practical limitations.
• Engineering problems are complex, open-ended, iterative, and multidisciplinary; they may have multiple solutions, require several attempts, and involve various areas of expertise.
• Informed decisions rely on the use of science and mathematics to determine the most effective solutions.
• Design constraints include factors like health, safety, cost, environmental impact, and regulatory compliance.

The Engineering Triangle

• The engineering triangle illustrates a common trade-off where you can only prioritize two of the following attributes: good, fast, and economical.
• "Good" and "Fast" results in higher expenses.
• "Good" and "Economical" results in longer development time.
• "Fast" and "Economical" results in compromised quality.

Definitions of Software Engineering

• IEEE/ISO defines it as the systematic application of knowledge and methods for software design and maintenance.
• Sommerville states that it encompasses all aspects of software production.
• Bauer defines it as the application of engineering principles to create reliable, efficient, and cost-effective software.

Cause of Complexity

• Software systems are inherently complex due to many components, potentially leading to more points of failure.
• Multiple stakeholders with differing perspectives and needs increase the complexity of software systems.
• Emergent behavior, characterized by unexpected interactions between components, further contributes to the complexity of software systems.
• Engineering systematically manages this complexity.

Fault, Error, and Failure

• A fault is a hidden problem within the program, like an incorrect default setting.
• An error is a flawed state that occurs while the program is running, such as encountering a null value when one is not expected.
• A failure is an observable issue resulting from the error, such as when the program crashes.
• The progression is: Fault -> Error -> Failure.

What makes a Model useful?

• Modeling involves three main principles: mapping, reduction, and pragmatism.
• Mapping ensures the model accurately reflects real-world elements.
• Reduction simplifies the model to only include essential details.
• Pragmatism ensures the model is created with a specific purpose in mind.
• Models help in addressing the complexity of large systems by simplifying and focusing on the most critical aspects.

Languages for Models

• Programming languages, such as Python and Java, are different from modeling languages like UML.
• General-purpose languages are suitable for various problems, while domain-specific languages (DSLs) are designed for use in very specific fields.

UML Class Diagrams

• UML is a tool used to model systems.
• A class diagram shows classes and their relationships.
• Classes (e.g., Car) possess attributes (e.g., make, model) etc.
• Relationships, for example: a Car is driven by a Driver.

UML

• Class diagrams show the structure of a system.
• Sequence diagrams show how objects interact over time.
• Activity diagrams represent workflows.
• UML serves as a universal language for software engineers to exchange design ideas.

Delivering Value

• Developing a product involves both developing the right product, to ensure it meets user requirements, and developing the product right, to make sure that it is maintainable, safe, and efficient.

Balancing Business and Technical Value

• Focusing only on business value may result in poor performance, maintenance difficulties, and a lack of technical sustainability.
• Focusing only on technical value may result in excellent code but a product that does not meet user needs.
• Balancing both aspects is ideal but challenging, particularly with strict deadlines.

Characterising Value

• Features add visible positive value.
• Design choices add invisible but positive value.
• Bugs are those things imparting a visible, negative value.
• Technical debt is any invisible but negative value.

Delivering Value Over Time

• There are three delivery approaches: continuous delivery, a release approach, and a "You Only Live Once" (YOLO) approach.
• Continuous delivery is the most valuable and lowest risk approach

Relation to Risk Management

• Risk equals costs minus value delivered over time, Risk = Costs – Value Delivered Over Time.
• Software engineers have limited control over costs but can influence how quickly and effectively value is delivered.

Technical Debt

• Technical debt is the future cost of rework caused by suboptimal design or shortcuts taken during development.
• It occurs due to poor design decisions, rushed or untested code, and prioritizing speed over quality.
• Repercussions include increased entropy (disorder) in the codebase and higher costs for new features or fixes.

How to Manage Technical Debt

• Follow the Boy Scout rule: Always leave the code better than you found it.
• Follow the Broken Window principle By ensuring code is clean and maintained.

Iterative Development

• Building software in small cycles (iterations).
• Each iteration refines the product and incorporates feedback from previous cycles.

Iterative and Incremental Development

• Iterative development allows gradual understanding of the problem and refinement of the solution.
• Incremental development adds small, functional pieces to the system.

Benefits

• Mitigating risks through early prototypes.
• Addressing technical debt early.

Minimum Viable Product (MVP)

• An MVP is a basic version of the product with minimal features and must be viable/functional enough to validate its usefulness.

MVP Goal:

• To get feedback from users, and improve the product through iterations.

Key Enablers of Iterative Design

• Maintainability, test coverage, and version control.
• Refactor code (without breaking functionality) ensuring it can be added to easily.
• Write tests to avoid breaking existing code.
• Use tools like Git to track changes effectively.

McCall's Quality Model Triangle

• It breaks down software quality into three perspectives: product operation, product revision, and product transition.
• Includes efficiency and reliability
• Includes maintainability and testability
• Includes portability and interoperability

Refactoring

• Refactoring improves existing code in a disciplined way.
• It changes the internal structure without affecting external behavior.
• Refactoring improves maintainability.
• Refactoring helps makes the code easier to read and modify.

Refactoring 101

• It involves small steps to minimize errors.
• The system remains functional after every change.
• Examples: Simplify long methods, remove duplicate code, and reduce unnecessary complexity.

Patterns That Need Refactoring

• Duplicated code, long methods, shotgun surgery (making a single change requires edits in many places), and feature envy (when one class relies heavily on another class’s data).

Polymorphism

• Polymorphism allows a single interface to represent different types or behaviors, which can replace switch statements.

Static Polymorphism

• The method that gets called is determined at compile time.
• Achieved through: method overloading and operator overloading.

Dynamic Polymorphism

• The method that gets called is determined at runtime.
• Achieved through: method overriding.

Static Code Analysis

• Examining the code without running it.
• Measures lines of code (LOC).
• Simplicity over excessive length.
• Cyclomatic complexity tracks the number of unique paths through the code.

Cyclomatic Complexity

• This metric counts the number of edges and nodes in a control flow graph.
• It measures how complicated the logic is.

Managing Code Quality

• Always use braces for clarity, even in simple conditions.
• Avoid confusing ternary operators.

Waterfall Model

• A linear, sequential approach.
• Each phase depends on the completion of the previous one.

Advantages:

• Simple and easy to follow.

Disadvantages

• Difficult to make changes once a phase is completed, slow value delivery because value isn’t delivered until the very end.

V-Model

• Similar to the Waterfall model but emphasizes verification and validation (V&V) at each stage.

Advantages;

• A strong focus on testing.

Disadvantages:

• Still rigid and slow.
• Late value delivery.

W-Model

• Testing occurs earlier, reducing late-stage issues.
• Tracking progress is harder.

Spiral Model

• A combination of iterative development with systematic risk assessment.

Advantages:

• Better risk management.

Disadvantages

• Continuous value delivery through increments, requires skilled customer interaction, and can be costly and complex.

Agile Methodology

• Breaking projects into sprints.
• Sprint examples include collaboration and continuous improvement.

Advantages:

• Flexible.

Examples:

• Scrum, Extreme Programming (XP).

Agile Frameworks: Scrum

• Key Concepts include:
  • Scrum Master
  • Product Owner (PO)
  • Backlog
  • Velocity

Agile Challenges

• Agile principles are often misused or misunderstood.
• Internal and external misalignments between principles and practices.

Agile

• It promotes working software as the primary measure of progress, instead of extensive documentation.
• It reduces risk through frequent delivery and adapting to changes.
• Not always suitable for projects requiring heavy certification.

Scrum Process

• Planning poker and Daily stand ups

DevOps

• Integrates software development (Dev) with IT operations (Ops) to automate workflows and foster collaboration.

Benefits:

• Complements Agile practices.

Sustainable DevOps (SusDevOps)

• Incorporates sustainability as a first-class principle in software delivery while retaining Agile principles.

Introduction to UML Class Diagrams

• UML gives a standard way to visualize system design.
• Class diagrams are blueprints for software, revealing its structure and relationships.

UML include:

 - Class Diagrams
 - Sequence Diagrams
 - Activity Diagrams
 - Use-Case Diagrams
 - State Machine Diagrams

General vs. Domain-Specific Languages

• General-purpose languages (Java, Python) work for every problem.
• Domain-specific languages (SQL) are tailored for specific problems.

UML Class Diagram - Entities

• Classes (name, attributes, methods)
• Objects are instances of a class.

Perspectives in Class Diagrams

• UML can be conceptual, logical, and implementational.
• Conceptual (high-level representation of entities).
• Logical (shows relationships and interactions).
• Implementation (details like database tables or code structure).

Relationships in UML

• Association, inheritance (generalization), aggregation, composition, dependency.

Association

• Solid line between two classes.
• Example: A Person owns a Car.

Inheritance (Generalization):

Hollow triangle

• Example: Dog inherits from Animal.

Aggregation

Hollow diamond

• Example: A Team contains Players.

Composition

Filled diamond

• Example: A House contains Rooms.

Dependency

Dashed line

• Example: A Student depends on Library.

Inheritance

• One class shares the behavior of another.
• Vehicle, car, bike examples .

Realization

• A class implements an interface.
• Represented by a dashed line with a hollow triangle.

Cardinality in Relationships

• Cardinality indicates how many objects are associated.
  • 1..1: Exactly one.
  • 0..*: Zero or many.
  • 1..*: One or more.

Aggregation vs. Composition

• Aggregation is a weak "has-a" relationship.
• Classrooms have students, but students can exist without the classroom.
• Composition is a strong "part-of" relationship.
  • Houses have rooms, and rooms cannot exist without the house.

Encapsulation

• Encapsulation is about bundling data (attributes) and behavior (methods) into a class, ensuring integrity by hiding internal details and defining visibility rules.

Problems Without Encapsulation

• Tight coupling with internal representation can lead to data corruption and difficulty maintaining code.

Benefits of Encapsulation

• Eliminates primitive obsession, access control ensures no uncontrolled modification of private data.

Encapsulation of Behaviour

• A CardPile defines business logic to shuffle and draw cards.
• Users don’t need to know how the cards are stored; they just use the services provided by the CardPile class.

Information Hiding and Trade-offs

• Overusing getters can lead to leaky abstractions, exposing internal data and violating invariants.

Abstractions

• Abstraction focuses on what an object does rather than how it does it.
• A Shape class might have an abstract method draw().
• The implementation of draw() will differ for subclasses like Circle and Rectangle.

Copying and Encapsulation

• Copying techniques ensure the safety of shared data: shallow copy, deep copy, and read-only copy.

UML Relationships

• Inheritance children get some properties from the parent
• Association key word is "uses" or "associates"
• Composition has the "has a" key word with a strong relationship
• Aggregation has the "has a" key word with a weak relationship

Recap of Foundational OOP Mechanisms

• Polymorphism (one interface, multiple implementations), encapsulation, and abstraction.
• Inheritance enables reuse of code by extending classes.
• These principles are the building blocks of the SOLID design principles.
• The SOLID principles help developers create understandable, flexible, and maintainable software.

What does SOLID stand for?

• Single Responsibility Principle (SRP), Open/Closed Principle (OCP), Liskov Substitution Principle (LSP), Interface Segregation Principle (ISP), and Dependency Inversion Principle (DIP).

Single Responsibility Principle (SRP)

• A class should have only one reason to change.
• Break Library class into BookCollection, UserRegistry, and FeeTracker classes.
• Benefits include easier maintenance, more testability, and flexibility.

Open/Closed Principle (OCP)

• A class should be open for extension but closed for modification.
• Use polymorphism: Create a Vehicle interface with a method like move().

Liskov Substitution Principle (LSP)

• Ensure predictability when using subclasses and avoid bugs due to unexpected behavior.

Interface Segregation Principle (ISP)

• A class should not be forced to implement interfaces it doesn’t use.
• Split the Searchable interface into smaller, more specific interfaces.
• Reduces unnecessary dependencies and improves modularity and flexibility.

Dependency Inversion Principle (DIP)

• Depend on abstractions, not on concrete implementations.
• Use an abstraction like BookDataSource (interface).
• Improves testability by mocking dependencies.

Responsibility

• A task or function that an object performs.
• "Who should do what" is the fundamental question in object-oriented design.

GRASP

• GRASP is a set of principles, in object oriented programming, to help decide where to assign responsibilities.
• Stand for General Responsibility Assignment Software Patterns

List of GRASP patterns:

1. Information Specialist (Expert)
2. Creator
3. Controller
4. Indirection
5. Low Coupling
6. High Cohesion
7. Polymorphism
8. Protected Variations
9. Pure Fabrication

Information Specialist (Expert Pattern)

• Give responsibility to the class that has the required data.

Example

• Board should handle tile-related operations (e.g., finding a tile).

Creator Pattern

• Object (B) should create another object (A) when:
  • B contains A.
  • B closely uses A.
  • B has the necessary initialization information.

Low Coupling

• Avoid tight dependency between classes to increase flexibility.

High Cohesion

• Keep classes focused on one task to improve reusability and readability.

Pure Fabrication

• Create helper classes when needed to keep cohesion high and coupling low.

Types in OOP

• Primitives: int, double, float.
• Non-primitive, custom objects in Java: Car, Cat, Dog.
• Classes define implementation.
• Types define behavior.

Classes vs. Types

• Classes define an object’s internal structure and implementation details.
• Types (interfaces) define an object’s behavior.

Key takeaway

• Interfaces defines what can be done, while classes define how it is done.
• Use interfaces as return types whenever possible.

YAGNI Principle (You Aren't Gonna Need It)

• Don't write code for future, uncertain requirements
• Avoid writing unnecessary code based on anticipated future needs.

Why Composition Matters?

• Decomposition and recomposition are effective problem-solving approaches.

The Big Ball of Mud (Bad Design)

• "Big Ball of Mud" refers to a messy codebase with no clear separation of concerns.
• Spaghetti code has no clear structure, making it hard to debug and maintain.
• Use composition to create well-structured relationships.

Composition As A Special Form

Composition == Stronger Ownership than Aggregation

UML Notation for Relationships

• Prefer unidirectional relationships whenever possible to reduce coupling.

Behavioral Composition

• Structural composition deals with data relationships.
• Behavioral composition combines behaviors dynamically.

Why

• Delegates behavior (does not repeat), can be changed at runtime, and follows SRP.

Behavioral Composition Key Tradeoffs

• Pros: low coupling, no if-else clutter, runtime flexibility.
• Cons: requires many small objects.

Comprehensive software engineering quiz covering design characteristics, the engineering triangle, faults, errors, failures, and polymorphism. It explores complexity in software systems and cyclomatic complexity measurements. This assessment tests understanding of core software engineering principles.