Software Engineering Concepts: A Comprehensive Guide

Module 9: Firebase Application

Realtime Database

A cloud-hosted database. Data is stored as JSON and synchronized in real-time to every connected client. Provides easy-to-use services for authentication (email/password, 3rd-party providers like Google/Facebook).

Cloud Firestore

A flexible and scalable database for mobile, web, and development. It offers synchronization, offline support, and ACID transactions.

Cloud Functions

...

Hosting

CSS/JavaScript

Cloud Storage

Provides robust, secure file uploads and downloads for Firebase apps.

Module 10: UML Diagrams

Structural Diagrams

• Class Diagram: Shows class hierarchy, fields/attributes, and relevant methods.

How to Read

• Visibility:
  • +: Public
  • -: Private
  • #: Protected (accessed only by child classes)
• Relationships:
  • Inheritance ("is-a" relationship): A solid line with a hollow arrowhead that points from the child to the parent class.
  • Simple Association: Shows that classes are related to one another (solid line connecting two classes).
  • Aggregation: If a class is part of, owned by, or belongs to another class. Classes have separate lifetimes; the owned can exist without the owner. (A solid line with an unfilled diamond at the association end. The diamond is next to the class that owns).
  • Composition: Objects of the owned die with the owner (the class that's next to the diamond = owner). (Solid line with a filled diamond connected to the class of the composite).
  • Dependency: If a class changes the definition of another class (class 1 depends on class 2). (A dashed line with an open arrow pointing to class 2, in this particular case).
  • Multiplicity: How many objects of each class take part in that relationship.

Behavioral Diagrams

Emphasize the dynamic behavior of the system and how different parts interact with each other. Models functionalities of the system and depicts the flow of control/data (use-case diagram).

• Sequence Diagram: Depicts object interactions arranged in a time sequence, showing how objects exchange messages over time.

Module 11: Presentation Patterns (Architectural Design)

Patterns

• MVC (Model View Controller): Application split into 3 components (adapted and evolved to be applied to web applications).
  • Model: Represents the business tier (e.g., a student application would have ID, name, etc.) and the data that's required to display to the view.
  • View: Displays the data to the user by interacting with the controller (invoking its methods). Also monitors the model for any state changes.
  • Controller: Processes user actions and then updates the model.
• MVVM (Model, View, View Model)

Separation of Concerns Design Principle: Separating business logic from the presentation project makes maintaining easier.

Module 12: Design Patterns (Solutions for Commonly Occurring Design Problems)

Creational Patterns (How to Instantiate/Create Objects)

• Builder Pattern: Moving the construction logic out of the object class to a separate class called the Builder class.
• Prototype Pattern: Copies existing objects without making your code dependent on their classes (the existing (prototype) object is used as a blueprint to create new objects. Implements a prototype interface that creates a clone of the current object).

Structural Patterns (Classes/Objects Combined to Form Larger Structures)

• Bridge Design Pattern: Decouples abstraction from implementation so they can vary/extend independently in two different class hierarchies. Use when you want to avoid permanent binding between abstraction and its implementation.

Behavioral Patterns (Deal with the Assignment of Responsibilities Among Objects)

• Observer Design Pattern: Subject (publisher) observer (subscriber). One-to-many dependency between objects so that when one object changes state, all its dependents are notified/updated automatically.

Module 13: Software Testing

White Box Testing vs. Black Box Testing

• White Box (WB): When you break down each component.
• Black Box (BB): Performed with no knowledge about the internals of the system (tester has no access/doesn't care about source code).
  • Boundary Value Analysis: Leads to a selection of test cases that exercise bounding values.
  • Interface Testing: Checks that the program component accepts information passed to it in the proper order and data types.
• Integration Testing: A systemic technique that takes all the unit-tested components and runs them all together (called the BIG BANG approach).
• Incremental Integration: The program is constructed and tested together in segments.
  • Top-Down Integration: Incomplete modules are "stubs" that aren't tested. (Stub: A piece of code that simulates the activity of missing components; it is an incomplete method that will compile although it's without functionality, a placeholder, so the rest of the code can run. Driver: A piece of code that passes test cases to another piece of code (a separate algorithm that runs the main code)).
  • Bottom-Up Integration: Begin testing with the atomic/smallest module at the bottom.
  • Regression Testing: The re-execution of some subset of tests that had bugs before but have been fixed (hopefully).
  • Continuous Integration: The practice of merging components into the evolving software increment at least once a day.
• Unit Testing: A technique that involves testing individual components of code in isolation against expected inputs/outputs (JUnit framework).

Module 14: Project Planning & Cost Estimate

Software Pricing: Estimates are made to discover the cost (takes into account hardware, software, travel, training, and effort costs).

Cost Estimate

• Experience-Based Techniques: An experienced manager within the project makes an informed judgment of what the effort requirements are likely to be.
• Algorithmic Cost Modeling: A formulaic approach to compute project effort based on estimates of product attributes (size, process, experience).
• COCOMO Cost Modeling: Incorporates a range of sub-models that produce increasingly detailed software estimates.