Software Development Principles

CSC125: Principles of Software Development - Day 16 Notes

Important Reminders for Students

  • Every Computer Science student, including the instructor, initially faced challenges in understanding concepts.

  • The instructor's role is to facilitate understanding, and they believe every student can and will grasp the material.

  • The instructor enjoys teaching and helping students learn, but students must communicate when they need assistance.

  • Avoid spending excessive hours attempting to learn concepts independently online if difficulties arise; instead, schedule office hours appointments.

Software Development Life Cycle (SDLC)

  • Definition: An SDLC is a specific process a company employs to develop its software.

  • Typical Phases of an SDLC:

    1. Phase 1: Requirements

      • Question: "What are we building?"

      • Focuses on determining user expectations regarding the features and functionalities of the target software system.

    2. Phase 2: Design

      • Question: "How should we build it?"

      • Involves structuring the software system into inter-related classes.

    3. Phase 3: Implementation

      • Action: "Build (code) it!"

      • The actual coding phase of the software.

    4. Phase 4: Verification and Validation

      • Question: "Did we build it correctly?"

      • Ensures the software meets requirements and functions as intended.

    5. Phase 5: Maintenance

      • Action: "Keep it working"

      • Ongoing activities to ensure the software continues to perform effectively, including bug fixes and updates.

The Waterfall Model

  • Description: One of the original SDLCs, designed for progress to flow linearly from one stage to the next.

  • Limitation: Software development rarely follows a clear, linear progression. It often requires returning to previous stages, making the strict Waterfall model impractical in many real-world scenarios.

  • Result: The existence of many different SDLCs adapted to varying development needs.

Phase 1: Requirements in Detail

  • Objective: To determine the expectations from users regarding the features and functionalities (the requirements) of the target software system.

  • Requirements Engineer:

    • An individual responsible for meeting with clients (domain experts) to define and document the system's requirements.

  • Types of Requirements:

    1. Functional Requirements:

      • Definition: Describe what the software system should be able to perform or do (its behavior).

      • Examples:

        • "When the user presses the Submit button, a food order will be created and added to the bottom of the orders list."

        • "When the food order is ready, a text notification will be sent to the customer."

        • "When the customer picks up their order, a survey will be delivered via email asking them to rate their experience."

    2. Non-functional Requirements:

      • Definition: Describe the quality or performance characteristics of the software system.

      • Examples:

        • "The system should be able to handle 5000 users without losing performance."

        • "Users should be able to find desired products within 3 clicks of the home page."

        • "The text messaging feature will encrypt (secure) all sensitive information."

Phase 2: Design in Detail

  • Objective: To structure the software system into a set of inter-related classes.

  • Major Steps:

    • A. Identify Classes (Object Types):

      • Typically derived from the nouns found in the requirements.

      • Cruise Ship Example Nouns (Potential Classes): software system, customers, reservations, cruise ship companies, cruises, year, cruise, port, destinations (e.g., Mexico, Bahamas), system, account, departure date, departure port, reservation, credit card information, external system, customer service representative (CSR), employee, ability, cruises, system, reservations, cruise officer, type of employee, passport information, customer, admittance, ship, employee type, activity planner, activities, customer, arriving at a port, activity, reservation.

    • B. Identify Member Variables (Data) for Objects of a Class:

      • Determining the attributes or properties that objects of each class will hold.

    • C. Identify Methods (Responsibilities) for Objects of a Class:

      • Typically derived from the verbs found in the requirements.

      • Cruise Ship Example Methods (from given slide):

        • Port: Get/Set Port Name, Get/Set Port Location, Get/Set Port Weather, Get/Set Port Depth, Get/Set Port Traffic.

        • Cruise: Get/Set Cruise Name, Get/Set Cruise Date, Get/Set Cruise Duration, Get/Set Cruise Status, Add/Remove Passenger(s) to Cruise, Add/Remove Port(s) to Cruise.

        • Passenger: Get/Set Passenger Name, Get/Set Passenger Passport Number, Get/Set Passenger Birthdate/Age, Get/Set Passenger Food Allergies, Add/Remove Activity to Itinerary.

        • Account: Get/Set Username, Get/Set Password, Add/Remove Cruise(s), Add/Remove Passenger to Account, Check Account Balance, Print Account Summary.

    • D. Identify the Relationships Among the Classes.

  • **End Products of the Design Phase:

    • A text description of the classes.

    • Diagram(s) of important Use Cases (Scenarios).

    • Diagram(s) of the classes and their relationship(s) among one another.

Unified Modeling Language (UML) Diagrams

  • History:

    • Prior to the 1990s, there was no standard for documenting software development/design.

    • In 1994, three software engineers from Rational Software developed the Unified Modeling Language (UML).

  • Purpose:

    • UML is a modeling language and a set of diagram types used to document and visualize the object-oriented design process.

    • It helps development teams represent both the structure and behavior of a system.

  • UML Class Diagrams (Focus of this Course):

    • A primary type of UML diagram used to communicate crucial information to other developers.

    • Information Communicated:

      • What are the classes.

      • What are the fields (variables) of the class.

      • What are the methods of the class (including name, parameter types, return type).

      • What is the visibility of the fields/methods (e.g., public vs. private).

      • What is the ownership of the fields/methods (e.g., static vs. non-static).

      • What are the relationships among the classes.

  • Structure of a UML Class Diagram Rectangle:

    • Each class is represented by its own rectangle.

    • Sections within the Rectangle:

      • Top Section: Class Name

      • Middle Section: Fields (variables) defined in the class (e.g., - id: int, - gpa: double, - gradYear: int).

      • Bottom Section: Methods defined in the class (e.g., + Student(), + getID(): int, + setID(int): void, + canGraduate(): boolean).

    • Method Signature Details:

      • Only parameter types are typically listed (e.g., setID(int)).

      • The return type is listed after a colon (e.g., getID(): int, setID(int): void).

    • Visibility Notation:

      • Public: Denoted with a plus sign (+).

      • Private: Denoted with a minus sign (-).

    • Ownership Notation (for Static Members):

      • Static fields/methods are denoted with an underline (e.g., + numStudents: int).

UML Class Diagram - Relationship Types

  • Analogy: UML relationships are similar to human relationships (e.g., Bob knows Jane, Bob is friends with Jane, Bob loves Jane – where a stronger relationship implies weaker ones).

  • Principle: When defining the UML relationship between two classes, be as precise as possible.

  • Five Relationship Types:

    1. Dependency ("uses")

      • Definition: Class A depends on class B if A needs to know about (use) class B to function.

      • Example: A Message class with a printMessage() method that uses System.out.println(). The Message class needs to know about/use the System class.

      • Diagram Notation: A dashed line drawn from the dependent class to the class it depends on (e.g., Message ----> System).

    2. Aggregation ("has")

      • Definition: Class A aggregates class B if A contains one or more objects of class B.

      • Relationship to Dependency: A not only needs to use B, but A specifically contains objects of B.

      • Example: A ShoppingCart object "has" or contains Product objects (e.g., ArrayList<Product> addedItems;).

      • Diagram Notation: A hollow diamond on the class that "contains" (e.g., ShoppingCart --o Product).

    3. Composition ("is composed of")

      • Definition: Class A is composed of class B if A contains one or more objects of B, and B cannot meaningfully exist on its own after A is destroyed.

      • Relationship to Aggregation: Composition is a more specific and stronger form of aggregation.

      • Example: A Book object is composed of Chapter objects (e.g., ArrayList<Chapter> chapters;). If the Book is destroyed, the Chapter objects cannot meaningfully exist independently.

      • Diagram Notation: A solid diamond on the class that "composes" (e.g., Book --# Chapter).

    4. Inheritance ("is a special type of")

      • Definition: Class A inherits from class B if A is a more specialized type of B (i.e., A inherits the fields/methods of B and can modify/augment them).

      • Analogy: A child object inheriting traits/features from its parent object.

      • Example: A Manager "is a special type of" Employee. The Manager class would inherit from the Employee class.

      • Diagram Notation: A hollow arrow that points from the specialized class to the general class it inherits from (e.g., Manager --|> Employee).

    5. Implements

      • (Note: This relationship type was listed but not elaborated upon in the provided transcript for this section, implying future coverage.)

Test Your Skills: A University Example

  • Students are prompted to apply their understanding of UML relationship types to pairs of university-themed classes (e.g., University & Department, Course & Department, Course & Student, Employee & Faculty). The goal is to identify the relationship name and draw the correct notation. The transcript then leads to a possible class diagram solution.