{ "_note": "CORRECTED: Module 2 is Requirements & Design Concepts (was incorrectly Project Management)", "_syllabus_structure": { "module_1": "Introduction to Software Engineering and Process Models (10 hrs)", "module_2": "Software Requirements and Design Concepts (16 hrs)", "module_3": "Software Project Management (11 hrs) - NOT INCLUDED IN THIS FILE" }, "module_1_software_engineering": { "title": "Module 1: Introduction to Software Engineering and Process Models", "duration": "10 hours", "topics": { "software_nature": { "title": "Software and Software Engineering - Nature of Software", "cards": [ { "type": "basic", "question": "What is Software?", "answer": "Software is the intangible set of instructions, programs, and data that tell a computer how to perform specific tasks. It's the opposite of hardware.", "context": "Basic definition" }, { "type": "basic", "question": "List all 7 categories of computer software that challenge software engineers", "answer": "
  1. System Software - Services other programs, manages resources
  2. Application Software - Solves specific business needs
  3. Engineering and Scientific Software - CAD, simulation, interactive applications
  4. Embedded Software - Controls features in products/systems
  5. Product-line Software - Specific capability for many customers
  6. Web Applications - Client-server programs run in browsers
  7. Artificial Intelligence Software - Non-numerical algorithms for complex problems
", "context": "Changing nature of software" }, { "type": "cloze", "text": "{{c1::System Software}} is a collection of programs written to {{c2::service other programs}}, characterized by heavy interaction with {{c3::computer hardware}}.", "extra": "Requires scheduling, resource sharing, and sophisticated process management" }, { "type": "cloze", "text": "{{c1::Embedded Software}} resides within a system or product and is used to {{c2::implement and control features}} for the end-user and system itself.", "extra": "Can perform limited functions or provide significant control capability" }, { "type": "basic", "question": "What makes AI Software different from other software types?", "answer": "AI software uses non-numerical algorithms to solve complex problems not amenable to computation or straightforward analysis. Includes robotics, expert systems, pattern recognition, neural networks.", "context": "Artificial Intelligence Software characteristics" } ] }, "software_engineering_fundamentals": { "title": "Software Engineering Fundamentals", "cards": [ { "type": "basic", "question": "Define Software Engineering", "answer": "Software Engineering is the process of designing, developing, testing, and maintaining software using a systematic and disciplined approach to create high-quality, reliable, and maintainable software.", "context": "Core definition" }, { "type": "basic", "question": "What are the 9 key principles of Software Engineering?", "answer": "
  1. Modularity - Breaking into smaller, reusable components
  2. Abstraction - Hiding implementation details
  3. Encapsulation - Wrapping data and functions into single unit
  4. Reusability - Components usable in multiple projects
  5. Maintenance - Regular updates and improvements
  6. Testing - Verifying requirements and bug-free operation
  7. Design Patterns - Templates for recurring problems
  8. Agile Methodologies - Iterative and incremental development
  9. Continuous Integration & Deployment - Continuous code integration
", "context": "Fundamental principles guiding software engineering" }, { "type": "basic", "question": "What are the 4 main attributes of Software Engineering?", "answer": "
  1. Efficiency - Measures resource requirements
  2. Reliability - Delivers same results in similar environments
  3. Reusability - Modules can be used in multiple applications
  4. Maintainability - Easy to modify, repair, or enhance
", "context": "Core attributes that define quality software engineering" }, { "type": "cloze", "text": "Software Engineering is mainly used for {{c1::large projects}} based on {{c2::software systems}} rather than single programs or applications.", "extra": "Main goal is to develop applications improving quality, budget, and time efficiency" } ] }, "sdlc": { "title": "Software Development Life Cycle (SDLC)", "cards": [ { "type": "cloze", "text": "SDLC is a {{c1::structured process}} used to {{c2::design, develop, and test}} good-quality software that defines the {{c3::entire procedure}} of software development step-by-step.", "extra": "Goal is to deliver high-quality, maintainable software meeting user requirements" }, { "type": "basic", "question": "What are the 6 stages of SDLC in order?", "answer": "
  1. Planning and Requirement Analysis - Customer inputs, market surveys
  2. Defining Requirements - SRS document creation
  3. Designing Architecture - DDS document, design selection
  4. Developing Product - Actual coding using programming languages
  5. Product Testing and Integration - Bug tracking and quality assurance
  6. Deployment and Maintenance - Release and ongoing support
", "context": "Sequential phases of software development" }, { "type": "basic", "question": "What is SRS and when is it used?", "answer": "Software Requirement Specification - A document that specifies all things that need to be defined and created during the entire project cycle. Used in Stage 2 (Defining Requirements).", "context": "Key SDLC documentation" }, { "type": "basic", "question": "What is DDS and its purpose?", "answer": "Design Document Specification - Contains multiple designs for product architecture based on SRS. Assessed by market analysts and stakeholders to choose the most practical design.", "context": "Architecture design documentation" }, { "type": "cloze", "text": "In SDLC Stage 4, developers use specific {{c1::programming code}} as per the design in the {{c2::DDS}}. Popular languages include {{c3::C/C++, Python, Java}}.", "extra": "Conventional tools like compilers, interpreters, debuggers are used" } ] }, "prescriptive_models": { "title": "Prescriptive Process Models", "cards": [ { "type": "basic", "question": "What are the 5 framework activities in prescriptive process models?", "answer": "
  1. Communication - Requirement gathering
  2. Planning - Estimation, scheduling, tracking
  3. Modeling - Analysis and design
  4. Construction - Coding and testing
  5. Deployment - Delivery, support, feedback
", "context": "Common activities across all prescriptive models" }, { "type": "cloze", "text": "Prescriptive models are called so because they {{c1::prescribe}} a set of {{c2::activities, actions, tasks}}, quality assurance and {{c3::change mechanisms}} for every project.", "extra": "Provides structured approach to software development" } ] }, "waterfall_model": { "title": "Waterfall Model", "cards": [ { "type": "basic", "question": "What is the Waterfall Model also called?", "answer": "Linear Sequential Model or Classic Life Cycle Model", "context": "Alternative names for waterfall approach" }, { "type": "basic", "question": "What are the key characteristics of the Waterfall Model?", "answer": "", "context": "Defining features of waterfall approach" }, { "type": "basic", "question": "List 5 advantages of the Waterfall Model", "answer": "
  1. Simple and easy to understand, implement, use
  2. All requirements known at beginning - easy to manage
  3. Avoids overlapping phases - completed at once
  4. Works for small projects with well-understood requirements
  5. Preferred when quality more important than cost
", "context": "When waterfall model is beneficial" }, { "type": "basic", "question": "What are the main disadvantages of the Waterfall Model?", "answer": "
  1. Not good for complex and object-oriented projects
  2. Poor model for long projects
  3. Problems uncovered only during testing
  4. High risk due to late problem discovery
", "context": "Limitations and when not to use waterfall" } ] }, "incremental_model": { "title": "Incremental Process Model", "cards": [ { "type": "cloze", "text": "The incremental model combines elements of {{c1::waterfall model}} applied in an {{c2::iterative fashion}}. The first increment is generally a {{c3::core product}}.", "extra": "Each increment builds the product and submits to customer for modifications" }, { "type": "basic", "question": "How does the Incremental Model process work?", "answer": "
  1. First increment = core product
  2. Each increment builds the product
  3. Submit to customer for suggested modifications
  4. Next increment implements customer suggestions
  5. Add additional requirements to previous increment
  6. Process repeated until product is finished
", "context": "Step-by-step incremental development process" }, { "type": "basic", "question": "What are the advantages of the Incremental Model?", "answer": "
  1. Flexible - low development cost, faster initial delivery
  2. Easier testing and debugging during smaller iterations
  3. Quick software generation early in lifecycle
  4. Customer response to functionalities after every increment
", "context": "Benefits of incremental approach" }, { "type": "basic", "question": "What are the disadvantages of the Incremental Model?", "answer": "
  1. Final product cost may exceed initial estimates
  2. Requires very clear and complete planning
  3. Customer demands for additional functionalities cause architecture problems
", "context": "Limitations of incremental development" }, { "type": "basic", "question": "Give an example of software developed using Incremental Model", "answer": "Word-processing software - Features can be developed incrementally (basic text editing → formatting → spell check → advanced features)", "context": "Real-world application example" } ] }, "evolutionary_models": { "title": "Evolutionary Process Models", "cards": [ { "type": "cloze", "text": "The evolutionary model is based on making an {{c1::initial product}} and then {{c2::evolving}} the software over time with {{c3::iterative and incremental}} approaches with proper {{c4::feedback}}.", "extra": "Product goes through several iterations until final product is built" }, { "type": "basic", "question": "What are the 3 types of Evolutionary Process Models?", "answer": "
  1. Iterative Model - Enhance product over multiple iterations
  2. Incremental Model - Build with basic features, evolve each iteration
  3. Spiral Model - Combines waterfall and iterative with risk focus
", "context": "Different evolutionary approaches" }, { "type": "basic", "question": "How does the Iterative Model work?", "answer": "Take initial requirements → enhance product over multiple iterations → make design modifications and add functional requirements in each iteration → final product with fewer errors and high quality", "context": "Iterative development process" } ] }, "spiral_model": { "title": "Spiral Model", "cards": [ { "type": "cloze", "text": "The Spiral Model combines {{c1::waterfall}} and {{c2::iterative}} models, focusing on {{c3::risk handling}} along with developing the project using {{c4::incremental and iterative}} approach.", "extra": "Good for big projects, produces output quickly" }, { "type": "basic", "question": "What are the 4 phases of the Spiral Model in order?", "answer": "
  1. Object determination and identify alternative solutions
  2. Identify and resolve risk
  3. Develop next version of the product
  4. Review and plan for the next phase
", "context": "Four quadrants of spiral model" }, { "type": "basic", "question": "What are the main advantages of Evolutionary Process Models?", "answer": "
  1. Regular customer feedback - requirements clearly specified
  2. Risk analysis after every iteration
  3. Suitable for big complex projects
  4. Quick first build delivery using iterative approach
  5. Enhanced flexibility - continuous changes and refinements
  6. Risk reduction - early issue identification
  7. Customer collaboration throughout development
", "context": "Benefits of evolutionary development" }, { "type": "basic", "question": "What are the disadvantages of Evolutionary Process Models?", "answer": "
  1. Not suitable for small projects
  2. High complexity and cost compared to sequential models
  3. Project management complexity - harder to track
  4. Resource intensive - time, personnel, tools
  5. Documentation challenges - frequent changes
  6. Potential scope creep - uncontrolled expansion
  7. Initial planning overhead - well-defined plan required
", "context": "Limitations and challenges" } ] }, "agile_development": { "title": "Agile Development", "cards": [ { "type": "basic", "question": "What is Agility in software development?", "answer": "Agility is the ability to rapidly adapt to changing requirements and deliver working software quickly through iterative development, customer collaboration, and responding to change.", "context": "Core concept of agile methodology" }, { "type": "basic", "question": "What defines an Agile Process?", "answer": "", "context": "Key characteristics of agile processes" } ] }, "extreme_programming": { "title": "Extreme Programming (XP)", "cards": [ { "type": "basic", "question": "What is Extreme Programming (XP)?", "answer": "XP is an agile methodology emphasizing frequent releases, pair programming, test-driven development, and continuous customer involvement to deliver high-quality software quickly.", "context": "Agile methodology focused on engineering practices" }, { "type": "basic", "question": "What are the key practices of Extreme Programming?", "answer": "", "context": "Core XP engineering practices" } ] } } }, "module_2_requirements_design": { "title": "Module 2: Software Requirements and Design Concepts", "duration": "16 hours", "topics": { "requirements_engineering": { "title": "Understanding Requirements - Requirement Engineering Process", "cards": [ { "type": "basic", "question": "What is Requirements Engineering?", "answer": "Requirements Engineering is the systematic process of defining, documenting, and maintaining requirements. It involves elicitation, analysis, specification, validation, and management of software requirements.", "context": "Foundation of software development process" }, { "type": "basic", "question": "What are the main phases of the Requirements Engineering Process?", "answer": "
  1. Requirements Elicitation - Gathering requirements from stakeholders
  2. Requirements Analysis - Understanding and modeling requirements
  3. Requirements Specification - Documenting requirements clearly
  4. Requirements Validation - Ensuring requirements are correct and complete
  5. Requirements Management - Handling changes and evolution
", "context": "Systematic approach to requirements engineering" }, { "type": "cloze", "text": "Requirements Engineering involves {{c1::elicitation}} (gathering), {{c2::analysis}} (understanding), {{c3::specification}} (documenting), {{c4::validation}} (verifying), and {{c5::management}} (controlling changes).", "extra": "Five key phases of requirements engineering process" }, { "type": "basic", "question": "What are the different types of requirements?", "answer": "
  1. Functional Requirements - What the system should do (features, capabilities)
  2. Non-Functional Requirements - How the system should perform (quality attributes)
  3. Domain Requirements - Requirements from the application domain
  4. User Requirements - High-level statements in natural language
  5. System Requirements - Detailed technical specifications
", "context": "Classification of software requirements" }, { "type": "basic", "question": "What are examples of Non-Functional Requirements?", "answer": "", "context": "Quality attributes that constrain system design" }, { "type": "basic", "question": "What are common Requirements Elicitation techniques?", "answer": "", "context": "Methods for gathering requirements from stakeholders" }, { "type": "cloze", "text": "Requirements elicitation techniques include {{c1::interviews}} for direct communication, {{c2::observation}} for understanding actual work, {{c3::prototyping}} for exploring ideas, and {{c4::workshops}} for group collaboration.", "extra": "Different approaches to gathering requirements" }, { "type": "basic", "question": "What are the challenges in Requirements Engineering?", "answer": "", "context": "Common problems faced in requirements engineering" }, { "type": "basic", "question": "What makes a good requirement statement?", "answer": "A good requirement should be:
", "context": "Characteristics of well-written requirements" } ] }, "feasibility_studies": { "title": "Feasibility Studies", "cards": [ { "type": "basic", "question": "What is a Feasibility Study in software development?", "answer": "A feasibility study is an assessment of whether a proposed software project is practical and achievable given the available resources, technology, and constraints. It evaluates if the project should proceed.", "context": "Project viability assessment" }, { "type": "basic", "question": "What are the main types of feasibility studies?", "answer": "
  1. Technical Feasibility - Can the system be built with available technology?
  2. Economic Feasibility - Is the project cost-effective and profitable?
  3. Legal Feasibility - Are there any legal constraints or regulations?
  4. Operational Feasibility - Will the system work in the target environment?
  5. Schedule Feasibility - Can the project be completed on time?
", "context": "Different aspects of project feasibility" }, { "type": "cloze", "text": "{{c1::Technical feasibility}} assesses if the system can be built with available technology, while {{c2::economic feasibility}} evaluates if the project is {{c3::cost-effective}} and profitable.", "extra": "Two critical aspects of feasibility analysis" }, { "type": "basic", "question": "What factors are considered in Economic Feasibility?", "answer": "", "context": "Financial analysis components" } ] }, "design_concepts": { "title": "Design Concepts - Design Process", "cards": [ { "type": "basic", "question": "What is Software Design?", "answer": "Software Design is the creative process of transforming requirements into a detailed blueprint for implementing the software. It defines the architecture, components, interfaces, and data structures.", "context": "Bridge between requirements and implementation" }, { "type": "basic", "question": "What are the fundamental Design Concepts?", "answer": "
  1. Abstraction - Hiding unnecessary details
  2. Modularity - Dividing system into discrete modules
  3. Encapsulation - Bundling data and methods together
  4. Coupling - Degree of interdependence between modules
  5. Cohesion - Degree of relatedness within a module
  6. Separation of Concerns - Isolating different aspects
  7. Information Hiding - Concealing implementation details
", "context": "Core principles guiding software design" }, { "type": "cloze", "text": "Good design aims for {{c1::low coupling}} (minimal interdependence) and {{c2::high cohesion}} (strong relatedness within modules) to achieve {{c3::maintainable}} and {{c4::reusable}} software.", "extra": "Key principles for quality software design" }, { "type": "basic", "question": "What are the different types of Cohesion from weakest to strongest?", "answer": "
  1. Coincidental - Elements grouped randomly
  2. Logical - Elements perform similar tasks
  3. Temporal - Elements executed at same time
  4. Procedural - Elements follow execution sequence
  5. Communicational - Elements operate on same data
  6. Sequential - Output of one is input to next
  7. Functional - Elements contribute to single task
", "context": "Types of cohesion in order of strength" }, { "type": "basic", "question": "What are the different types of Coupling from tightest to loosest?", "answer": "
  1. Content Coupling - One module modifies another's data
  2. Common Coupling - Modules share global data
  3. External Coupling - Modules share external format/protocol
  4. Control Coupling - One module controls another's flow
  5. Stamp Coupling - Modules share data structures
  6. Data Coupling - Modules share data parameters only
", "context": "Types of coupling from worst to best" }, { "type": "basic", "question": "What are the phases of the Design Process?", "answer": "
  1. Architectural Design - High-level system structure
  2. Interface Design - Component interactions
  3. Component Design - Detailed module design
  4. Data Design - Data structures and databases
  5. Algorithm Design - Detailed processing logic
", "context": "Systematic approach to software design" }, { "type": "cloze", "text": "The design process starts with {{c1::architectural design}} (system structure), then {{c2::interface design}} (interactions), followed by {{c3::component design}} (modules), {{c4::data design}} (structures), and {{c5::algorithm design}} (logic).", "extra": "Sequential phases of the design process" }, { "type": "basic", "question": "What is the difference between Design and Analysis?", "answer": "
AnalysisDesign
Focuses on WHAT system should doFocuses on HOW system should do it
Problem domain orientedSolution domain oriented
Understands requirementsCreates implementation plan
Models the problemModels the solution
", "context": "Distinguishing analysis from design activities" } ] }, "design_model_elements": { "title": "Design Model Elements", "cards": [ { "type": "basic", "question": "What are Data Design Elements?", "answer": "Data Design Elements define how data is organized, stored, and accessed in the system. Includes data structures, databases, file formats, and data relationships that support system functionality.", "context": "Foundation of system data management" }, { "type": "basic", "question": "What are Architectural Design Elements?", "answer": "Architectural Design Elements define the overall structure of the software system, including major components, their relationships, communication patterns, and architectural styles (like layered, client-server, microservices).", "context": "High-level system organization" }, { "type": "basic", "question": "What are Interface Design Elements?", "answer": "Interface Design Elements specify how components interact with each other and with external systems. Includes APIs, protocols, data formats, and user interfaces that enable communication.", "context": "Component interaction specifications" }, { "type": "basic", "question": "What are Component-Level Design Elements?", "answer": "Component-Level Design Elements provide detailed specifications for individual software components, including internal structure, algorithms, data structures, and interfaces at the implementation level.", "context": "Detailed component specifications" }, { "type": "basic", "question": "What are Deployment-Level Design Elements?", "answer": "Deployment-Level Design Elements specify how the software will be installed, configured, and run in the target environment. Includes hardware requirements, network topology, and deployment strategies.", "context": "System deployment considerations" }, { "type": "cloze", "text": "Design model elements include {{c1::Data}} (storage organization), {{c2::Architectural}} (system structure), {{c3::Interface}} (component interactions), {{c4::Component-Level}} (detailed specs), and {{c5::Deployment-Level}} (environment setup).", "extra": "Five categories of design elements in software systems" } ] }, "architectural_design_dfd": { "title": "Architectural Design using DFD", "cards": [ { "type": "basic", "question": "What is a Data Flow Diagram (DFD)?", "answer": "A DFD is a graphical representation that shows how data flows through a system. It illustrates processes, data stores, external entities, and data flows without showing control flow or timing.", "context": "System analysis and design tool" }, { "type": "basic", "question": "What are the main components of a DFD?", "answer": "
  1. External Entities - Sources/destinations of data (squares/rectangles)
  2. Processes - Transform data (circles/bubbles)
  3. Data Stores - Store data (open rectangles/parallel lines)
  4. Data Flows - Movement of data (arrows with labels)
", "context": "Four basic elements of data flow diagrams" }, { "type": "cloze", "text": "In DFD, {{c1::external entities}} (squares) are sources/destinations of data, {{c2::processes}} (circles) transform data, {{c3::data stores}} (open rectangles) hold data, and {{c4::data flows}} (arrows) show data movement.", "extra": "Symbols and their meanings in data flow diagrams" }, { "type": "basic", "question": "What are the levels of DFDs?", "answer": "
  1. Context Diagram (Level 0) - Highest level, shows system boundary with external entities
  2. Level 1 DFD - Decomposes context diagram into major processes
  3. Level 2 DFD - Further decomposes Level 1 processes
  4. Lower Levels - Continue decomposition as needed for detail
", "context": "Hierarchical decomposition of system functionality" }, { "type": "basic", "question": "What are the rules for creating correct DFDs?", "answer": "", "context": "Guidelines for correct DFD construction" }, { "type": "cloze", "text": "DFD rules include: every {{c1::process}} must have input/output, data stores must be {{c2::accessed by processes}}, and {{c3::parent and child}} diagrams must be balanced.", "extra": "Key validation rules for data flow diagrams" }, { "type": "basic", "question": "What is DFD Balancing?", "answer": "DFD Balancing ensures that inputs and outputs of a process in a parent diagram match exactly with the inputs and outputs in the child diagram that decomposes that process. This maintains consistency across decomposition levels.", "context": "Consistency rule for hierarchical DFDs" }, { "type": "basic", "question": "What is the difference between Physical and Logical DFDs?", "answer": "
Logical DFDPhysical DFD
Shows WHAT the system doesShows HOW the system does it
Implementation independentImplementation specific
Focuses on business functionsFocuses on technical details
Abstract viewConcrete view with technology
", "context": "Two perspectives of data flow modeling" } ] }, "component_level_design": { "title": "Component Level Design Guidelines", "cards": [ { "type": "basic", "question": "What is Component-Level Design?", "answer": "Component-Level Design involves creating detailed specifications for individual software components, defining their internal structure, algorithms, data structures, and interfaces for implementation.", "context": "Detailed design phase of software development" }, { "type": "basic", "question": "What are the key guidelines for Component-Level Design?", "answer": "
  1. Single Responsibility - Each component should have one clear purpose
  2. High Cohesion - Related functionality grouped together
  3. Low Coupling - Minimize dependencies between components
  4. Information Hiding - Hide internal implementation details
  5. Clear Interfaces - Well-defined component boundaries
  6. Reusability - Design for potential reuse
", "context": "Principles for effective component design" }, { "type": "cloze", "text": "Component design should follow {{c1::single responsibility}} principle, achieve {{c2::high cohesion}} within components and {{c3::low coupling}} between components, while practicing {{c4::information hiding}}.", "extra": "Core principles for quality component design" }, { "type": "basic", "question": "What should be included in Component Specifications?", "answer": "", "context": "Elements of comprehensive component documentation" } ] }, "uml_modeling": { "title": "Modelling with UML", "cards": [ { "type": "basic", "question": "What is UML (Unified Modeling Language)?", "answer": "UML is a standardized modeling language used to visualize, specify, construct, and document software systems. It provides a common notation for object-oriented analysis and design.", "context": "Industry standard for software modeling" }, { "type": "basic", "question": "What is a Class Diagram in UML?", "answer": "A Class Diagram shows the static structure of a system by displaying classes, attributes, methods, and relationships between classes. It's the most commonly used UML diagram for object-oriented design.", "context": "Structural modeling in UML" }, { "type": "basic", "question": "What are the main elements of a Class Diagram?", "answer": "
  1. Classes - Rectangles with class name, attributes, methods
  2. Associations - Relationships between classes
  3. Generalization - Inheritance relationships (hollow arrow)
  4. Multiplicity - Number of instances in relationships (1, *, 0..1)
  5. Aggregation - \"Has-a\" relationship (hollow diamond)
  6. Composition - \"Part-of\" relationship (filled diamond)
", "context": "Components of UML class diagrams" }, { "type": "cloze", "text": "In class diagrams, {{c1::generalization}} shows inheritance with hollow arrows, {{c2::aggregation}} shows \"has-a\" with hollow diamonds, and {{c3::composition}} shows \"part-of\" with filled diamonds.", "extra": "Different types of relationships in class diagrams" }, { "type": "basic", "question": "What is a Use Case Diagram?", "answer": "A Use Case Diagram shows the functional requirements of a system by illustrating actors (users/external systems) and their interactions with the system through use cases (system functions).", "context": "Requirements modeling and system scope definition" }, { "type": "basic", "question": "What are the main elements of a Use Case Diagram?", "answer": "
  1. Actors - External entities (users, systems) - stick figures
  2. Use Cases - System functions (ovals/ellipses)
  3. System Boundary - Rectangle defining system scope
  4. Associations - Lines connecting actors to use cases
  5. Include - Mandatory sub-functionality (<>)
  6. Extend - Optional extensions (<>)
", "context": "Components of UML use case diagrams" }, { "type": "cloze", "text": "Use case diagrams show {{c1::actors}} (stick figures) interacting with {{c2::use cases}} (ovals) within a {{c3::system boundary}} (rectangle). {{c4::Include}} relationships are mandatory, {{c5::extend}} relationships are optional.", "extra": "Key elements and relationships in use case diagrams" }, { "type": "basic", "question": "What is a State Chart Diagram?", "answer": "A State Chart Diagram (State Machine Diagram) models the dynamic behavior of objects by showing states, transitions, events, and actions that objects undergo during their lifecycle.", "context": "Behavioral modeling for object states" }, { "type": "basic", "question": "What are the main elements of State Chart Diagrams?", "answer": "
  1. States - Rounded rectangles showing object conditions
  2. Initial State - Filled circle (starting point)
  3. Final State - Circle with filled circle inside (end point)
  4. Transitions - Arrows between states
  5. Events - Triggers that cause transitions
  6. Guards - Conditions for transitions [condition]
  7. Actions - Activities performed during transitions
", "context": "Components of state chart diagrams" }, { "type": "basic", "question": "What is an Activity Diagram?", "answer": "An Activity Diagram models the flow of activities in a system or process, showing sequential and parallel activities, decision points, and synchronization points in business or system processes.", "context": "Process and workflow modeling" }, { "type": "basic", "question": "What are the main elements of Activity Diagrams?", "answer": "
  1. Activities - Rounded rectangles showing actions
  2. Initial Node - Filled circle (start)
  3. Final Node - Circle with filled circle (end)
  4. Decision Node - Diamond shape for branching
  5. Merge Node - Diamond for combining flows
  6. Fork - Black bar for parallel flow start
  7. Join - Black bar for parallel flow end
  8. Control Flows - Arrows showing sequence
", "context": "Components of UML activity diagrams" }, { "type": "cloze", "text": "UML diagrams include {{c1::Class}} diagrams for static structure, {{c2::Use Case}} diagrams for functional requirements, {{c3::State Chart}} diagrams for object behavior, and {{c4::Activity}} diagrams for process flow.", "extra": "Four key UML diagram types covered in the syllabus" }, { "type": "basic", "question": "When would you use each type of UML diagram?", "answer": "", "context": "Appropriate usage scenarios for different UML diagrams" } ] } } } }