diff --git a/i40/architecture_system_layer.png b/i40/architecture_system_layer.png new file mode 100644 index 0000000..0ab44b8 Binary files /dev/null and b/i40/architecture_system_layer.png differ diff --git a/i40/architecture_system_layer.svg b/i40/architecture_system_layer.svg new file mode 100644 index 0000000..185e9bb --- /dev/null +++ b/i40/architecture_system_layer.svg @@ -0,0 +1,96 @@ +Sensor LayerOperating System LayerApplication LayerData LayerSensorsEmbeddedFrontendBackendFeature 1: Automatic WateringFeature 2: Watering ScheduleFeature 3: Watering AlertsDatabaseCable (water level data)WiFi (GET /water-status, POST /water-plant)HTTPS (GET /dashboard, POST /set-schedule)HTTPS (SQL Query, SELECT * FROM plant_status)REST API (POST /water-plant)REST API (POST /set-schedule)REST API (POST /send-alert) \ No newline at end of file diff --git a/i40/architecture_system_rest.png b/i40/architecture_system_rest.png new file mode 100644 index 0000000..11426f2 Binary files /dev/null and b/i40/architecture_system_rest.png differ diff --git a/i40/index.html b/i40/index.html index 8ee5a91..522895f 100644 --- a/i40/index.html +++ b/i40/index.html @@ -175,7 +175,8 @@

Welcome
Software Engineering in Industry 4.0 Ecosystems

- 5 (Feb 10, 12, 14) + 5 (Feb 10, + 12, 14) Architectural Design for Industry 4.0 Applications Lab 3 + Homework 3 (2w) @@ -305,35 +306,41 @@

Every Software Engineering Starts with Requirements<
-

Requirement

-

The IoT-enabled system should allow users to rent bikes easily through smart connectivity and - real-time tracking

+

Requirement

+

The IoT-enabled system should allow users to rent bikes easily through smart connectivity and + real-time tracking

-

Requirement

-

The IoT-enabled system should allow registered users to rent a bike by selecting a location using - a GPS-enabled app, unlocking the bike via a smart lock, and completing payment seamlessly within - three steps

+

Requirement

+

The IoT-enabled system should allow registered users to rent a bike by selecting a location + using + a GPS-enabled app, unlocking the bike via a smart lock, and completing payment seamlessly + within + three steps

-

Requirement

-

Purpose: IoT-Improved Bike Rental System to manage rentals and track customers, - bikes, and transactions in real-time

-
-
    -
  • Track the availability of bikes, including their unique ID, condition, and location using - IoT sensors
  • -
  • Log rental transactions, including bike ID, customer ID, rental start and return time, and - battery level (if e-bikes)
  • -
  • Maintain customer records, including name, contact details, and rental history
  • -
  • Integrate smart locks for secure bike rentals and returns
  • -
  • Provide real-time notifications to users about bike condition, availability, and usage stats - via the app
  • -
+

Requirement

+

Purpose: IoT-Improved Bike Rental System to manage rentals and track + customers, + bikes, and transactions in real-time

+
+
    +
  • Track the availability of bikes, including their unique ID, condition, and location + using + IoT sensors
  • +
  • Log rental transactions, including bike ID, customer ID, rental start and return time, + and + battery level (if e-bikes)
  • +
  • Maintain customer records, including name, contact details, and rental history
  • +
  • Integrate smart locks for secure bike rentals and returns
  • +
  • Provide real-time notifications to users about bike condition, availability, and usage + stats + via the app
  • +
@@ -354,7 +361,7 @@

What Are Epics?

-

What an Epic Should Include

+
What an Epic Should Include
  • Title: A concise, descriptive name for the epic
  • Description: A brief overview of the functionality or goal the epic @@ -394,7 +401,7 @@

    What Are User Stories?

-

What a User Story Should Include

+
What a User Story Should Include
  • Title: A short, clear description of the user story
  • Description: A brief explanation of the user need and the goal
  • @@ -423,14 +430,14 @@

    Acceptance Criteria

-

User Story Template

+
User Story Template

As a [user role],

I want to [desired action],

Because [reason or benefit]

-

User Stories for Bike Rental

+
User Stories for Bike Rental
  • As a registered user, I want to select a bike from available options, Because I want to quickly find a bike that suits my @@ -449,7 +456,7 @@

    Adding Implementation Task Requirements into

-

Implementation Tasks

+
Implementation Tasks

Implementation tasks are specific, actionable steps required to complete a user story or feature. They include:

    @@ -465,7 +472,7 @@

    Translating Epic / User Story / Task Requirem

-

Product Backlog

+
Product Backlog

The product backlog is a prioritized list of user stories, features, and tasks that need to be completed for the product. It includes:

    @@ -492,7 +499,7 @@

    Git Commit Message

-

Types of Requirements

+
Types of Requirements
  • UI Requirements: Define user interaction and design
  • Architecture Requirements: Specify system structure and components
  • @@ -506,7 +513,7 @@

    Types of Requirements

-

Requirement Priority

+
Requirement Priority
  • Must Have: Critical features needed for system functionality
  • Should Have: Important but non-essential features that can be deferred. @@ -516,7 +523,7 @@

    Requirement Priority

-

Effort Estimation: T-Shirt Size

+
Effort Estimation: T-Shirt Size
  • Small (S): Low complexity or effort, typically takes a short time
  • Medium (M): Moderate complexity, takes a moderate amount of time
  • @@ -527,7 +534,7 @@

    Effort Estimation: T-Shirt Size

-

Effort Estimation: Fibonacci Numbers

+
Effort Estimation: Fibonacci Numbers
  • 1: Very low effort, simple task that requires little time
  • 2: Low effort, simple task with a bit more time required
  • @@ -557,7 +564,7 @@

    Requirements Gathering

-

Requirement Types

+
Requirement Types
  • Requirement → High-level need
  • Epic → Larger body of work
  • @@ -600,13 +607,13 @@

    Process Requirements

-

Verification

+
Verification

Ensures the product is built as per specifications. ("Are we building the product right?")

-

Verification in the V-Model

+
Verification in the V-Model

Purpose: Acts as a quality gate to ensure readiness for the next stage

Verification at Each Stage:

    @@ -622,7 +629,7 @@

    Verification at Each Stage:

-

Validation

+
Validation

Confirms the product meets user needs. ("Are we building the right product?")

@@ -632,7 +639,7 @@

Horizontal and Vertical Traceability

-

Test Tickets: Verification

+
Test Tickets: Verification
  • Ticket ID: #VT-001 @@ -651,7 +658,7 @@

    Test Tickets: Verification

-

Test Ticket: Validation

+
Test Ticket: Validation
  • Ticket ID: #VD-001 | Task: Conduct acceptance testing to verify user needs are met
  • @@ -663,7 +670,7 @@

    Test Ticket: Validation

-

Project

+
Project
  • Requirement: The system must notify user to water plants based on soil moisture levels
  • @@ -678,7 +685,7 @@

    Requirement Tracebility Matrix

-

Requirements Traceability Matrix

+
Requirements Traceability Matrix
@@ -820,11 +827,11 @@

Requirement Dependency Matrix

-

Logistics Team for IoT Sensor Setup

+
Logistics Team for IoT Sensor Setup
-

Requirements for the IoT System

+
Requirements for the IoT System
@@ -858,7 +865,7 @@

Requirements for the IoT System

-

Horizontal Tickets

+
Horizontal Tickets
  • Ticket #LT-001: Purchase Sensors
      @@ -880,7 +887,7 @@

      Horizontal Tickets

-

Horizontal Tickets

+
Horizontal Tickets
  • Ticket #LT-003: Develop System Plan
      @@ -895,7 +902,7 @@

      Horizontal Tickets

-

Requirements Dependency Matrix

+
Requirements Dependency Matrix
@@ -953,7 +960,7 @@

Requirements Dependency Matrix

-

Requirements Dependency Matrix

+
Requirements Dependency Matrix

Project: Automated Plant Watering System

@@ -1012,7 +1019,7 @@

Requirements Dependency Matrix

-

Requirement Traceability Matrix

+
Requirement Traceability Matrix
@@ -1058,7 +1065,7 @@

Requirement Traceability Matrix

-

Lab 1: Issue Creation and Review

+
Lab 1: Issue Creation and Review
  • Create at least 5 issues (only client team can/edit create requirements and epics)
  • @@ -1080,7 +1087,7 @@

    Lab 1: Issue Creation and Review

-

Question?

+
Question?
@@ -1145,15 +1152,15 @@

Today: January 24, 2025

-

Requirement and Standards

+
Requirement and Standards
-

Requirement and Standard Diagrams

+
Requirement and Standard Diagrams
-

Standard UML: Component Diagram

+
Standard UML: Component Diagram
  • Represents system components and their relationships
  • Shows high-level architecture
  • @@ -1167,7 +1174,7 @@

    Standard UML: Component Diagram

-

Standard UML: Entity Relationship Diagram

+
Standard UML: Entity Relationship Diagram
  • Shows entities and their relationships
  • Highlights data structure and constraints
  • @@ -1181,7 +1188,7 @@

    Standard UML: Entity Relationship Diagram

-

PlantUML: Component Diagram

+
PlantUML: Component Diagram

                   @startuml
                     [Component 1] --> [Component 2]
@@ -1190,7 +1197,7 @@ 

PlantUML: Component Diagram

-

PlantUML: Entity Relationship Diagram

+
PlantUML: Entity Relationship Diagram

                   @startuml
                     entity "Entity" {
@@ -1207,18 +1214,18 @@ 

PlantUML: Entity Relationship Diagram

-

PlantUML Editor

+
PlantUML Editor
Open PlantUML Editor
PlantUML Language Reference Guide
-

Requirement and Standard Communication

+
Requirement and Standard Communication
-

Standard Communication Using Slack

+
Standard Communication Using Slack
  • Use public channels for specific topics
  • Keep messages clear and concise
  • @@ -1228,7 +1235,7 @@

    Standard Communication Using Slack

-

Public Channel Naming Conventions

+
Public Channel Naming Conventions
  • [team]-[topic] format
  • [logistics]-wifi-access
  • @@ -1236,14 +1243,14 @@

    Public Channel Naming Conventions

-

Special Use Case Channels

+
Special Use Case Channels
  • #all-plant-watering-system for important updates
-

Slack Communication Standards

+
Slack Communication Standards
  • Use @mentions carefully
  • Set Slack reminders
  • @@ -1253,7 +1260,7 @@

    Slack Communication Standards

-

Example Public Channels for Teams

+
Example Public Channels for Teams
  • [team-design-ui]-sprint
  • [team-architecture]-tech-stack
  • @@ -1264,7 +1271,7 @@

    Example Public Channels for Teams

-

Adding Team to Profile Name

+
Adding Team to Profile Name
  • Include your team name in your Slack profile
  • Format: [name] ([team])
  • @@ -1275,7 +1282,7 @@

    Adding Team to Profile Name

-

Slack vs GitHub

+
Slack vs GitHub
  • Slack is for **quick communication** and collaboration
  • **GitHub** is the **single source of truth** for code, issues, and tasks
  • @@ -1285,7 +1292,7 @@

    Slack vs GitHub

-

Slack Task

+
Slack Task
  • Please create one team channel per team
  • Please add your team to your handle
  • @@ -1293,11 +1300,11 @@

    Slack Task

-

Requirement and Automation

+
Requirement and Automation
-

GitHub Automation Overview

+
GitHub Automation Overview
  • Automate repetitive tasks like issue creation, CI/CD pipelines, etc
  • Improve productivity and consistency
  • @@ -1306,7 +1313,7 @@

    GitHub Automation Overview

-

Automating Issue Creation

+
Automating Issue Creation
  • Automate issue creation based on events like weekly schedules
  • Use workflows to trigger issue creation
  • @@ -1315,7 +1322,7 @@

    Automating Issue Creation

-

Setting Up GitHub Actions

+
Setting Up GitHub Actions
  • Create a workflow file: .github/workflows/automation.yml
  • Define the event triggers (e.g., schedule, push)
  • @@ -1336,7 +1343,7 @@

    Setting Up GitHub Actions

-

Slack Integration with GitHub Automation

+
Slack Integration with GitHub Automation
  • Receive GitHub notifications directly in Slack
  • Use GitHub's Slack integration to get updates on pull requests, issues, etc
  • @@ -1346,7 +1353,7 @@

    Slack Integration with GitHub Automation

-

Benefits of GitHub Automation

+
Benefits of GitHub Automation
  • Consistency: Automate repetitive tasks
  • Efficiency: Free up time for more important tasks
  • @@ -1356,14 +1363,14 @@

    Benefits of GitHub Automation

-

Automation Task (1/2)

+
Automation Task (1/2)
  • Please review which tasks can be automated in your team
-

Automation Task (2/2)

+
Automation Task (2/2)
  • Please create one task for each automation recommendation
@@ -1380,11 +1387,11 @@

Today: January 24, 2025

-

Status Project

+
Status Project
-

Project Team Task

+
Project Team Task
  • Please introduce your team
  • Assign roles and responsibilities
  • @@ -1396,11 +1403,11 @@

    Project Team Task

-

Question?

+
Question?
-

Lab 1 (Jan/31) and Homework 1 (Jan/27)

+
Lab 1 (Jan/31) and Homework 1 (Jan/27)
@@ -1422,7 +1429,7 @@

January 27, 2025

-

Conway's Law in Industry 4.0

+
Conway's Law in Industry 4.0

Conway's Law: "Organizations design systems that mirror their team and communication @@ -1460,7 +1467,7 @@

Conway's Law in Industry 4.0

-

Cross-functional Teams

+
Cross-functional Teams

Team members from different disciplines (hardware, software, data) collaborate in a single team to ensure all aspects of the project are covered from the start. This approach promotes continuous communication and immediate problem-solving

@@ -1482,14 +1489,14 @@

Cross-functional Teams

-

Modular Teams

+
Modular Teams

Separate teams are assigned to distinct components (e.g., one for embedded, one for frontend, and one for backend). Regular communication between teams ensures integration and smooth collaboration between modules

-

Product-Oriented Teams

+
Product-Oriented Teams

Organize teams around specific features or outcomes (e.g., automated watering or data analytics). This structure ensures focus and clear ownership of specific deliverables, allowing for targeted development efforts

@@ -1514,7 +1521,7 @@

Product-Oriented Teams

-

Agile/Scrum Teams

+
Agile/Scrum Teams

Teams work in iterative cycles (sprints), with regular stand-ups and sprint reviews to ensure continuous feedback and collaboration across all parts of the project. This flexible approach allows teams to quickly adapt to changes and feedback

@@ -1537,7 +1544,7 @@

Agile/Scrum Teams

-

Hierarchical Teams

+
Hierarchical Teams

Create a project lead who oversees sub-teams for different components. The lead facilitates communication and integration between sub-teams, ensuring that the overall project vision is aligned with individual component developments

@@ -1567,7 +1574,7 @@

Hierarchical Teams

-

Team Structure & Communication Impact on Software Errors

+
Team Structure & Communication Impact on Software Errors
  • Mariner 1 Spacecraft, 1962: Poor communication between engineering teams > Small coding error caused mission failure ($18.5 million)
  • @@ -1581,7 +1588,7 @@

    Team Structure & Communication Impact on Software Errors

-

Team Structures: Pros and Cons

+
Team Structures: Pros and Cons
@@ -1681,7 +1688,7 @@

Team Structures: Pros and Cons

-

Levels of Communication

+
Levels of Communication
  • Code Level: Communication through code comments and documentation (e.g., GitHub)
  • @@ -1695,7 +1702,7 @@

    Levels of Communication

-

What Do You Recommend?

+
What Do You Recommend?
  • What team structures would you implement?
  • How would you foster collaboration across different disciplines?
  • @@ -1904,13 +1911,13 @@

    January 29, 2025

-

Homework 1 - Rank ChallengFes

+
Homework 1 - Rank ChallengFes

Biggest Challenge: Lack of adequate skill sets

-

Backlog Refinement

+
Backlog Refinement
  • Review and prioritize issues
  • Clarify requirements and scope
  • @@ -2761,7 +2768,7 @@

    Proposal: One Repository

    git submodule add  embedded
    git submodule add  backend
    git submodule add  frontend
    -
    git add .
    +
    git add 
    git commit -m "Added submodules"
    git push origin main
@@ -3065,37 +3072,633 @@

Fixes vs. Resolves in GitHub Commits

  • Fixes #123: Used when the commit directly addresses a bug or issue
    ➡️ The issue is automatically closed when merged
  • -
  • Resolves #123: Used for enhancements or non-bug-related improvements +
  • Resolves #123: Used for improvements or non-bug-related improvements
    ➡️ The issue is closed when merged, but it implies a major resolution rather than just a bug fix
  • +
    + Using keywords in issues and pull requests +
    + + +
    +

    Module 5
    Architectural Design for Industry 4.0 Applications

    +
    + +
    +

    February 10, 2025

    +
      +
    • Introduction to Software Architecture
    • +
    • Architectural Styles and Patterns
    • +
    • Quality Attributes in Software Architecture
    • +
    • Software Architecture Design Process
    • +
    • Case Study: Monolith vs. Microservices
    • +
    • Practice Questions
    • +
    +
    + +
    + Introduction to Software Architecture +
    + +
    +
    What is Software Architecture?
    +

    Software architecture represents a shared understanding among + developers of the + system's design

    + Ralph Johnson, "Software Architecture: A Shared Understanding" +
    + +
    +
    What is Software Architecture?
    +

    The decisions you wish you could get right early in a project... +

    + Ralph Johnson, "Software Architecture: A Shared Understanding" +
    + +
    +
    What is Software Architecture?
    +

    Architecture defines the application boundaries by specifying + which components belong to the system and which are external. +

    + +
    +
    What is Software Architecture?
    +
      +
    • Modularity: Breaking the system into smaller, manageable components
    • +
    • Separation of Concerns: Isolating functionalities to avoid + interdependencies
    • +
    • Scalability: Designing the system to accommodate growth in traffic or data + volume
    • +
    • Maintainability: Ensuring the system is easy to update and fix
    • +
    • Performance: Optimizing for responsiveness and efficiency
    • +
    • +
    +
    + +
    +
    What is Software Architecture?
    +
      +
    • Programming Language: Choosing the language that fits system requirements + (e.g., performance, scalability)
    • +
    • Database: Deciding between SQL vs. NoSQL, and selecting the appropriate + database system
    • +
    • Framework: Selecting frameworks that align with system needs (e.g., web + frameworks, microservices)
    • +
    • Communication Protocols: Deciding between REST, gRPC, or WebSockets for + inter-component communication
    • +
    • Security: Choosing encryption methods and authentication strategies
    • +
    • Cloud Infrastructure: Deciding whether to use on-premise or cloud-based + services (e.g., AWS, Azure)
    • +
    • Deployment Strategy: Deciding between monolithic or microservices-based + deployment
    • +
    • Caching Strategy: Selecting caching mechanisms to improve performance + (e.g., Redis, Memcached)
    • +
    • API Design: Defining the structure and style of APIs (e.g., RESTful, + GraphQL)
    • +
    • Component Structure (IoT Embedded): Deciding the architecture of hardware + components, sensor interfaces, etc
    • +
    +
    + +
    + Architectural Styles and Patterns +
    + +
    +
    Architectural Styles
    +
      +
    • API-First: The API is designed first, guiding all system components and + fostering system integration
    • +
    • Feature Toggles: Enables feature management and experimentation without + deploying new code
    • +
    • Layered Architecture: Organizes software in layers: presentation, business, + and data access, promoting easy system integration
    • +
    • Microservices: Breaks the system into smaller, independent services that + interact over APIs
    • +
    • Event-Driven Architecture: The system reacts to events that trigger + processes or communication
    • +
    • Client-Server: Separates the client (user interface) and server (data + processing/storage) to improve scalability and maintainability
    • +
    +
    + +
    +
    API First - Foster System Integration
    +
    + +
    +

    A RESTful API (Representational State Transfer) is a set of guidelines for building web services + that interact over HTTP, using a stateless architecture and standard HTTP methods (GET, POST, + PUT, DELETE) to perform operations

    +
    + +
    +
      +
    • Stateless: No client context is stored on the server between requests
    • +
    • Uniform Interface: Consistent structure for requests and responses
    • +
    • Client-Server: Separation of concerns, allowing independent evolution
    • +
    +
    + +
    +
      +
    • GET: Retrieve data from the server
    • +
    • POST: Submit data to the server
    • +
    • PUT: Update an existing resource
    • +
    • DELETE: Remove a resource
    • +
    +
    + +
    +

    In REST, resources are represented by URLs. These URLs should be descriptive, hierarchical, and + correspond to the underlying data or object. Example: /users/{id} to access a + specific user

    +
    + +
    +

    Each request from the client to the server must contain all the information needed to understand + and process the request. The server does not store any client context between requests

    +
    + +
    +

    RESTful APIs commonly use JSON (JavaScript Object Notation) to exchange data, offering a + lightweight and human-readable format for data transfer

    +
    + +
    +

    RESTful APIs use standard HTTP status codes to indicate the success or failure of an API request. + Example: 404 for "Not Found," 200 for "OK," 400 for "Bad Request."

    +
    + +
    +

    RESTful APIs often use token-based authentication, such as OAuth or JWT (JSON Web Tokens), to + ensure secure communication between clients and servers

    +
    + +
    +

    RESTful APIs can improve performance through caching mechanisms like HTTP cache headers, which + store responses to reduce redundant requests

    +
    + +
    +
      +
    • Use nouns for resource names (e.g., /users)
    • +
    • Ensure consistency in naming conventions
    • +
    • Limit the number of HTTP methods per resource
    • +
    • Provide clear error messages and status codes
    • +
    +
    + +
    +
    REST API Endpoints First
    + +
    + +
    +
    REST API Endpoints
    +
    
    +                GET /api/flowers
    +                    Retrieves all flowers' watering status.
    +                    
    +                
    +                GET /api/flowers/<flower_id>
    +                    Retrieves a specific flower's watering status by ID.
    +                    
    +                
    +                PUT /api/flowers/<flower_id>
    +                    Updates the watering status of a specific flower by ID.
    +                    
    +                    
    +
    + +
    +
    REST API Endpoints (Users)
    +
    
    +                GET /api/users
    +                    Retrieves all users' data.
    +                    
    +                
    +                GET /api/users/<user_id>
    +                    Retrieves a specific user's data by ID.
    +                    
    +                
    +                PUT /api/users/<user_id>
    +                    Updates a specific user's data by ID.
    +                    
    +                    
    +
    + +
    +
    Feature Toggles - Foster System Integration
    +
    + +
    +

    + Feature Toggles (often also referred to as Feature Flags) are a powerful technique that allows + teams to modify system behavior without changing code. + By enabling or disabling specific features, teams can control which functionality is available + in a live environment without deploying new code. + This technique enables easier A/B testing, gradual rollouts, and quick + rollback in case of + issues. +

    +
    + +
    +
    Feature Toggles
    +
      +
    • Modify system behavior without code changes
    • +
    • Enable/Disable features in production
    • +
    • Facilitate A/B testing and feature rollouts
    • +
    • Quickly rollback features if needed
    • +
    +
    + +
    + +
    + +
    +
    Feature Toggles for Plant Watering System
    +

    + Feature Toggles (also known as Feature Flags) allow us to modify system behavior without + changing the code. + In this example, we use feature toggles to control different features of the plant watering + system. +

    +
    + +
    +
    +                        
    +                class FeatureToggles {
    +                    constructor() {
    +                        this.toggles = {
    +                            "automatic_watering": false,
    +                            "send_alerts": false,
    +                            "log_watering_activity": false
    +                        };
    +                    }
    +                        
    +                    
    +
    + +
    +
    +                        
    +                    isEnabled(feature) {
    +                        return this.toggles[feature] || false;
    +                    }
    +                        
    +                    
    +
    + +
    +
    +                        
    +                    enableFeature(feature) {
    +                        this.toggles[feature] = true;
    +                    }
    +                        
    +                    
    +
    + +
    +
    +                        
    +                    disableFeature(feature) {
    +                        this.toggles[feature] = false;
    +                    }
    +                }
    +                        
    +                    
    +
    + +
    +
    +                        
    +                const featureToggles = new FeatureToggles();
    +                if (featureToggles.isEnabled("automatic_watering")) {
    +                    console.log("Watering plants automatically...");
    +                } else {
    +                    console.log("Automatic watering is disabled.");
    +                }
    +                        
    +                    
    +
    + +
    +
    +                        
    +                if (featureToggles.isEnabled("send_alerts")) {
    +                    console.log("Sending watering alerts...");
    +                } else {
    +                    console.log("Alert sending is disabled.");
    +                }
    +                        
    +                    
    +
    + +
    +
    Why Feature Toggles are Important for IoT and CPS?
    +
      +
    • Enable testing of features without affecting the entire system
    • +
    • Quick rollback of features in case of failures or issues in real-time environments
    • +
    • Control feature availability, enabling updates without requiring downtime
    • +
    • Flexible features based on context or sensor data
    • +
    +
    + +
    +
    How to Start with Feature Toggles
    +
      +
    1. Identify which features need toggling based on their risk, complexity, and deployment + requirements
    2. +
    3. Integrate a feature toggle management system into your codebase
    4. +
    5. Define clear naming conventions for feature toggles to keep track of different features and + environments
    6. +
    7. Use a gradual rollout strategy, starting with a small group of users or devices before full + deployment
    8. +
    +
    + +
    + +
    + +
    +
    Layered Architecture - Sensor Data Quality First
    +
    + +
    + +
    + +
    +
    Layered Architecture Overview
    +
      +
    • Organizes systems into distinct layers, each with a specific responsibility
    • +
    • Improves modularity and separation of concerns
    • +
    • Common layers: Presentation, Application, Business Logic, Data Access, and Database
    • +
    • Each layer communicates with the adjacent one, simplifying the design
    • +
    +
    + +
    +
    Layered Architecture Overview
    +
      +
    • Improve maintainability and scalability (of some layers)
    • +
    • Clear division of responsibilities between layers
    • +
    • Ease of testing by isolating components
    • +
    • Flexibility for layer substitution (e.g., swapping the database layer)
    • +
    • Limits supports parallel development by teams on different + layers
    • +
    +
    + +
    +
    Layered Architecture Structure
    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    LayerResponsibilities
    SensorCollects data from the physical environment (e.g., water level, temperature)
    Operating SystemManages hardware resources and provides basic services for the embedded system
    PresentationHandles user interface, user input
    ApplicationHandles business logic, request routing
    Business LogicDefines the core operations and services
    Data AccessHandles communication with data sources, APIs
    DatabaseStores persistent data and ensures data consistency
    +
    + +
    +
    Layered Architecture and IoT Systems
    +
      +
    • Separation of physical devices and logic improves flexibility
    • +
    • Simplifies integration of different IoT components (e.g., sensors, databases)
    • +
    • Reduces complexity in managing communication between devices and backend systems
    • +
    • Ensures that the system can evolve (e.g., adding new features or devices)
    • +
    • Improves debugging and fault isolation by focusing on one layer at a time
    • +
    +
    + +
    + Microservices ↔ Event-Driven ↔ Client-Server +
    + +
    + Quality Attributes in Software Architecture +
    + +
    +
    Quality Attributes in Software Architecture
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    AttributeDescription
    PerformanceSystem's responsiveness and resource usage efficiency
    ScalabilityAbility to handle increased load by scaling resources
    ReliabilitySystem's ability to operate without failure over time
    MaintainabilityEase of making changes to the system, fixing bugs, and adding features
    SecurityProtection from unauthorized access, attacks, and vulnerabilities
    UsabilityEase of use for end users and administrators
    AccessibilityEnsuring the system is usable by people with disabilities
    +
    + +
    + Software Architecture Design Process +
    + +
    +
    Software Architecture Design Process
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    StepDescription
    1. Requirement GatheringUnderstand the system’s functional and non-functional requirements.
    2. Architecture PlanningDefine the high-level structure, components, and relationships.
    3. Design ComponentsDesign individual system components and their interactions.
    4. Evaluate Design AlternativesAnalyze different architectural styles and patterns to choose the best fit.
    5. PrototypingCreate a prototype or proof-of-concept to validate the design.
    6. Document ArchitectureDocument the architecture using diagrams and descriptions for future reference.
    7. Review and RefinementReview the architecture with stakeholders and make necessary refinements.
    +
    + +
    + Case Study: Monolith vs. Microservices +
    + +
    +

    + The Flower Care app integrates sensors to collect real-time data on soil + moisture, temperature, and light. Users can monitor plant health, set watering + schedules, and receive alerts. The app requires + scalable, fault-tolerant architecture for handling growing + data and user interactions. Key options include monolithic (simple, + all-in-one), layered architecture (separation of concerns), + microservices (independent services for scalability), and event-driven + architecture (real-time, event-based processing). Which architecture is optimal for + performance, scalability, and maintainability? +

    +
    +
    Questions?
    + Practice Questions +
    - Using keywords in issues and pull requests +
    +

    1. What is the main advantage of using microservices architecture?

    +
      +
    • Option A: Improved performance
    • +
    • Option B: Independent scaling of services
    • +
    • Option C: Reduced complexity
    • +
    • Option D: Easier to deploy
    • +
    + + +
    +
    +

    2. Which architecture pattern focuses on the separation of concerns and layers?

    +
      +
    • Option A: Microservices
    • +
    • Option B: Layered architecture
    • +
    • Option C: Event-driven architecture
    • +
    • Option D: Client-server architecture
    • +
    + +
    +

    3. In which architecture is the system organized into independent, loosely-coupled components + that communicate via events?

    +
      +
    • Option A: Microservices
    • +
    • Option B: Event-driven architecture
    • +
    • Option C: Layered architecture
    • +
    • Option D: Monolithic architecture
    • +
    + + +
    - Sprint #2 Demo 🙂 +
    +

    4. Which architectural style is best suited for applications that require high performance and + direct client interaction?

    +
      +
    • Option A: Monolithic
    • +
    • Option B: Microservices
    • +
    • Option C: Client-server
    • +
    • Option D: Event-driven
    • +
    + + +
    +
    +

    5. Which of the following is a key characteristic of a layered architecture?

    +
      +
    • Option A: All layers share the same database
    • +
    • Option B: No communication between layers
    • +
    • Option C: Layering increases complexity
    • +
    • Option D: Separation of concerns between layers
    • +
    + +
    +
    -

    Backlog Grooming + Questions? +

    + +
    +

    Sprint #3 Backlog + Grooming

    -

    Sprint Planning +

    Sprint #3 Planning

    @@ -3105,8 +3708,9 @@

    Fixes vs. Resolves in GitHub Commits

    -
    -

    Module 5
    Architectural Design for Industry 4.0 Applications

    +
    + Sprint #3 + Demo 🙂
    @@ -3162,15 +3766,18 @@

    Software Engineering in Industry 4.0 Ecosystems (COMP 293F)

    Course Description

    -

    In this course on Software Engineering within Industry 4.0 ecosystems, we will explore the - integration and application of IoT and Cyber-Physical Systems (CPS). The course takes a dual +

    In this course on Software Engineering within Industry 4.0 ecosystems, we will explore + the + integration and application of IoT and Cyber-Physical Systems (CPS). The course takes a + dual perspective approach.

    • First, we focus on the design aspect, the team structure, the requirements, the user interface design, the architecture, and tracking.
    • -
    • Second, we focus on the implementation, integration, testing, verification, validation, +
    • Second, we focus on the implementation, integration, testing, verification, + validation, release, and maintenance part.
    @@ -3179,29 +3786,37 @@

    Course Description

    Industry 4.0 Ecosystem Exploration 1/2

      -
    • Exploring the requirements specific to Industry 4.0 ecosystems and their influence on +
    • Exploring the requirements specific to Industry 4.0 ecosystems and their influence + on software engineering practices
    • -
    • Understanding the dynamics of team organization and coordination within these ecosystems. +
    • Understanding the dynamics of team organization and coordination within these + ecosystems.
    • Examining resource constraints and their implications in Industry 4.0 settings
    • -
    • Investigating the legal frameworks and regulations affecting Industry 4.0 projects
    • -
    • Analyzing architectural constraints, including system design and scalability considerations. +
    • Investigating the legal frameworks and regulations affecting Industry 4.0 projects +
    • +
    • Analyzing architectural constraints, including system design and scalability + considerations.
    • Studying the security challenges and strategies within Industry 4.0
    • -
    • Reviewing resource management, optimization, and constraints in software projects
    • +
    • Reviewing resource management, optimization, and constraints in software projects +

    Industry 4.0 Ecosystem Exploration 2/2

      -
    • Delving into the development processes, standards, methodologies, and best practices for +
    • Delving into the development processes, standards, methodologies, and best practices + for Industry 4.0 applications
    • -
    • Focusing on testing and verification procedures specific to these advanced systems
    • +
    • Focusing on testing and verification procedures specific to these advanced systems +
    • Addressing dependencies management in complex software environments
    • Reviewing release cycles and continuous delivery in the context of Industry 4.0
    • Updating strategies and lifecycle management for software in this dynamic field
    • -
    • Integrating AI technologies with Industry 4.0 systems, exploring synergies and innovative +
    • Integrating AI technologies with Industry 4.0 systems, exploring synergies and + innovative solutions
    @@ -3270,7 +3885,8 @@

    Instructor

  • Managerial Challenges of Industry 4.0
  • THE ESSENCE OF INDUSTRY 4.0
  • -
  • Industry 4.0 Current Status and Future Trends +
  • Industry 4.0 Current Status and Future + Trends
  • Software Engineering
  • @@ -3308,7 +3924,8 @@

    Assignments and Exams

    - @@ -3319,7 +3936,8 @@

    Assignments and Exams

    - +
    Homework:Includes written exercises and programming assignments. Submit via Canvas or GitHub. + Includes written exercises and programming assignments. Submit via Canvas or + GitHub.
    Exams:One midterm and one final. Students may bring one handwritten note sheet (8.5x11)One midterm and one final. Students may bring one handwritten note sheet + (8.5x11)
    @@ -3327,7 +3945,8 @@

    Assignments and Exams

    Policies

      -
    • Attendance and Participation: Active participation is required. Additional +
    • Attendance and Participation: Active participation is required. + Additional points may be awarded for consistent engagement
    • Late Submissions:
        @@ -3335,18 +3954,23 @@

        Policies

      • No makeup exams unless excused for valid reasons
    • -
    • Academic Integrity: Academic dishonesty (e.g., plagiarism, cheating) will - result in a grade of zero for the assignment or more severe penalties for repeated offenses. +
    • Academic Integrity: Academic dishonesty (e.g., plagiarism, + cheating) will + result in a grade of zero for the assignment or more severe penalties for repeated + offenses.
    • -
    • Collaboration: Collaborative problem-solving is encouraged but must stop +
    • Collaboration: Collaborative problem-solving is encouraged but must + stop short of sharing code or written work
    • -
    • Accommodations: Students requiring accommodations should contact the Office +
    • Accommodations: Students requiring accommodations should contact + the Office of Services for Students with Disabilities at McCaffrey Center, Rm. 137.
      • Phone: 209-946-3221
      • Email: ssd@pacific.edu
      • Website: Disabilities Support
      • + href="https://www.pacific.edu/disabilities">Disabilities Support +
    @@ -3354,13 +3978,15 @@

    Policies

    Canvas and Course Updates

    -

    All course materials, announcements, and assignments will be posted on Canvas. Check regularly +

    All course materials, announcements, and assignments will be posted on Canvas. Check + regularly for updates

    Honor Code

    -

    Students are expected to act with integrity, honesty, and responsibility. Violations of the Honor +

    Students are expected to act with integrity, honesty, and responsibility. Violations of + the Honor Code will be reported to the Office of Student Conduct and Community Standards

    For more details, see the University