Untitled Flashcards Set

CSCW (Computer-Supported Cooperative Work)

• Inheritance: Inheritance is considered the ‘is-a’ type. It is how we represent that one class is a type of another class.

• Aggregation: Aggregation is the ‘has a’ relationship. For example, a store has employees.

• Composition: Similar to aggregation, but stronger. It’s a "owns-a" relationship. For example, a house owns rooms.

Human-Centered Design (HCD)

• Key Principle: The key principle of using an HCD is that it involves the user in mind throughout the designing process.

4 Activities in the HCD Process:

1. Observation: Looking at users and seeing the issue and potential opportunities for ideas.

2. Idea Generation: Brainstorming and thinking about how things come together.

3. Prototyping: This can be like drawings or a full 3D model.

4. Testing: Testing the prototype to make sure it works for users.

6 Core Elements of HCD:

1. Understand: Understanding what the problem is.

2. Define: State what the problem is based on research.

3. Ideate: Brainstorm potential solutions.

4. Prototype: Build prototypes based on ideas.

5. Test: Test the prototypes with users.

6. Iterate: Keep testing and making changes.

Disparity of Benefit

• Concept: This concept describes situations where the people who invest time, effort, or resources into a system are not the ones who primarily benefit from it.
  
  Example: People who write detailed reviews on Yelp, Amazon, or TripAdvisor spend time and effort providing valuable insights. However, the primary beneficiaries are future users who rely on these reviews to make purchasing decisions, and companies that profit from increased engagement.
  
  

Use Case Diagram

• Purpose: A diagram that represents how users interact with different features of the system.

Key Elements:

• Actors: Customer, Admin.

• Use Cases: Browse products, Add to cart, Make payment, Manage inventory.

• Relationships: The customer interacts with "browse products" and "make payment," while the admin manages "inventory."

State Machine Diagram (State Diagram)

• Purpose: A model that shows how something changes between different states of an event or product.

Key Elements:

• States: Represent different conditions an object can be in (e.g., "Idle," "Processing," "Completed").

• Transitions: Shows how an object moves from one state to another, labeled with the event that triggers the transition.

• Initial State: Filled black circle ⚫, represents the starting state of the system.

• Final State: Black circle with an outer ring ⭘, represents the end state (if applicable).

Behavioral Diagrams

• Purpose: The verbs of a UML diagram that represent behavior over time and space. Behavioral diagrams show how the system reacts to actions, like when you click a button, make a request, or give input.

Types:

• Use Case Diagram: Shows what the system can do (e.g., "Transfer Funds").

• Sequence Diagram: Shows the order of steps (e.g., Customer → System → Database).

• Activity Diagram: Shows the flow of tasks (e.g., log in, choose transfer, check balance, transfer money).

• State Machine Diagram: Shows how the system changes states (e.g., from "waiting" to "processing" when a transfer happens).

Grouping in UML

• Purpose: Organizing elements into packages or components, where each group contains related elements that belong together. This makes it easier to manage and understand complex systems.

Examples:

• Packages: Think of a package like a folder. You put related elements (classes, use cases, etc.) inside it to keep things organized.

  • Example: In a library system, you might have a package called "Books" that contains classes like Book, Author, and Genre.

• Components: A component is like a module or subsystem of the system. It’s a self-contained unit that performs a specific role in the system.

  • Example: In an e-commerce system, you might have a "Payment Component" that includes everything related to payment processing, like CreditCardProcessor, PaymentGateway, and Invoice.

Double Diamond Model

• Purpose: Provides a visual representation of the design process, emphasizing the iterative nature of design thinking.

4 Phases:

1. Discover: Understand the problem.

2. Define: Clarify the problem.

3. Develop: Create solutions.

4. Deliver: Finalize and implement the solutions.

Systems

• Definition: In the context of systems, the "actual set of interrelated components working together to achieve a specific purpose" refers to a real-world system or realized system that operates to fulfill its intended function.
  
  Example: A car as a real-world system, where the components (engine, wheels, sensors) work together to transport people.
  
  

Deployment Diagram

• Purpose: A development diagram that shows the software components and how they are deployed into hardware devices and how they communicate together.

Key Elements:

• Nodes: The devices that the system runs on, like servers or databases.

• Artifacts: The software components deployed onto the nodes.

  • Example: A web application deployed onto a server node.

• Communication Association: Shows how nodes and artifacts talk with each other.

  • Example: A server node may talk with a database node over a network connection.

• Deployment Specification: Details of how a specific artifact is deployed into a node, including the version of an app and installation details.

Sequence Diagram

• Purpose: Shows how objects in a system interact with each other. It models a sequence of messages between objects to carry out specific behaviors.

Key Elements:

• Objects/Actors: External entities that interact with the system (e.g., users, external systems).

• Lifelines: Dashed lines that show the existence of an object over time.

• Messages: Arrows that show communication between objects.

  • Synchronous Messages: Solid arrows indicate a request and expect a response.

  • Asynchronous Messages: Dashed arrows represent one-way communication.

• Activation Bars: Rectangles that indicate when an object is performing a process.

• Return Messages: Dashed arrows showing the return of data.

• Conditions and Loops: Represent decisions and repeated actions.

Affordances

• Definition: Affordances refer to the features or elements that help users understand what actions are possible within a system. These include visual clues like symbols, lines, arrows, and labels.

Class Diagram

• Purpose: A type of UML diagram that shows the classes in their systems, their attributes, methods, and relationships.

Example:

• Class Name: Student

  • Attributes: Name, Age

  • Methods: Enroll, Study

Structural Diagrams

• Purpose: Represent the static parts of a system that do not change over time.

Types:

1. Class Diagram: Shows classes, attributes, methods, and relationships.

2. Object Diagram: Shows instances of classes at a specific moment.

3. Component Diagram: Shows high-level components and their dependencies.

4. Deployment Diagram: Shows how hardware and software are connected.

5. Package Diagram: Organizes related classes or components into packages.

6. Composite Structure Diagram: Shows internal structure of a class.

7. Profile Diagram: Defines custom stereotypes for UML elements.

Component Diagram

• Purpose: Shows how the high-level components of a system are connected.

Example: A web app might have components for the frontend, backend, and database.

Dynamic Diagrams

• Purpose: Represent the behavior or interaction of the system over time.

Types:

1. Sequence Diagram: Shows the order of messages passed between objects.

2. Communication Diagram: Focuses on the relationships and message flow.

3. State Diagram: Shows how an object transitions between states.

4. Activity Diagram: Represents workflows or tasks.

5. Interaction Overview Diagram: Combines activity and sequence diagrams.

6. Timing Diagram: Shows the timing of events or interactions over time.

Activity Diagram

• Purpose: Shows the flow of control in a system.

Key Elements:

• Activities: Actions or tasks (e.g., login, place order).

• Start: Marks the start of the diagram.

• End: Marks the end of the workflow.

• Decision Node: A decision point in the flow (e.g., "Is payment successful?").

• Merge Node: Combines multiple paths back into one.

• Fork Node: Splits the flow into multiple paths.

• Join Node: Combines parallel paths back into one.

• Swimlanes: Divides the diagram by actors or roles.

• Control Flows: Arrows showing the sequence of activities.

Interaction Diagrams

• Purpose: Show how objects interact and communicate with each other.

Types:

1. Sequence Diagram: Focuses on the order of messages between objects.

2. Communication Diagram: Focuses on relationships and message flow.

Key Elements:

• Objects/Participants: Entities involved in the interaction.

• Messages: Arrows indicating communication.

• Activation Boxes: Represent when an object is active.

• Return Messages: Dashed arrows showing the response.