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.
Key Principle: The key principle of using an HCD is that it involves the user in mind throughout the designing process.
Observation: Looking at users and seeing the issue and potential opportunities for ideas.
Idea Generation: Brainstorming and thinking about how things come together.
Prototyping: This can be like drawings or a full 3D model.
Testing: Testing the prototype to make sure it works for users.
Understand: Understanding what the problem is.
Define: State what the problem is based on research.
Ideate: Brainstorm potential solutions.
Prototype: Build prototypes based on ideas.
Test: Test the prototypes with users.
Iterate: Keep testing and making changes.
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.
Purpose: A diagram that represents how users interact with different features of the system.
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."
Purpose: A model that shows how something changes between different states of an event or product.
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).
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.
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).
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.
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.
Purpose: Provides a visual representation of the design process, emphasizing the iterative nature of design thinking.
Discover: Understand the problem.
Define: Clarify the problem.
Develop: Create solutions.
Deliver: Finalize and implement the solutions.
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.
Purpose: A development diagram that shows the software components and how they are deployed into hardware devices and how they communicate together.
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.
Purpose: Shows how objects in a system interact with each other. It models a sequence of messages between objects to carry out specific behaviors.
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.
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.
Purpose: A type of UML diagram that shows the classes in their systems, their attributes, methods, and relationships.
Class Name: Student
Attributes: Name, Age
Methods: Enroll, Study
Purpose: Represent the static parts of a system that do not change over time.
Class Diagram: Shows classes, attributes, methods, and relationships.
Object Diagram: Shows instances of classes at a specific moment.
Component Diagram: Shows high-level components and their dependencies.
Deployment Diagram: Shows how hardware and software are connected.
Package Diagram: Organizes related classes or components into packages.
Composite Structure Diagram: Shows internal structure of a class.
Profile Diagram: Defines custom stereotypes for UML elements.
Purpose: Shows how the high-level components of a system are connected.
Purpose: Represent the behavior or interaction of the system over time.
Sequence Diagram: Shows the order of messages passed between objects.
Communication Diagram: Focuses on the relationships and message flow.
State Diagram: Shows how an object transitions between states.
Activity Diagram: Represents workflows or tasks.
Interaction Overview Diagram: Combines activity and sequence diagrams.
Timing Diagram: Shows the timing of events or interactions over time.
Purpose: Shows the flow of control in a system.
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.
Purpose: Show how objects interact and communicate with each other.
Sequence Diagram: Focuses on the order of messages between objects.
Communication Diagram: Focuses on relationships and message flow.
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.