The use case diagram models the interactions between a Customer and an ATM machine. The Customer can perform the use cases of Logging In, Making a Withdrawal, Checking Balance, and Depositing Funds. The ATM machine facilitates these use cases.
The document discusses use case diagrams and use case descriptions for modeling system requirements. It covers drawing use case diagrams to show functional requirements and actors, common mistakes, and writing use case descriptions including basic, alternate, and exception flows of events. The document provides examples and exercises to help understand use cases for requirements modeling.
This document provides an overview of use case diagrams and use cases. It defines what a use case is, including that it captures a user's interaction with a system to achieve a goal. It describes the key components of a use case diagram, including actors, use cases, and relationships between use cases like generalization, inclusion, and extension. An example use case diagram for a money withdrawal from an ATM is presented to illustrate these concepts. Guidelines for documenting use cases with descriptions of flows, exceptions, and other details are also provided.
This document discusses software quality assurance. It defines software quality and describes two types - quality of design and quality of conformance. It discusses quality concepts at the organizational, project, and process levels. It also describes software reviews, their types and purposes. Software quality assurance aims to establish organizational procedures and standards to achieve high quality software. Key SQA activities include applying technical methods, reviews, testing, enforcing standards and measurement.
Lab 3 Introduction to the UML - how to create a use case diagramFarah Ahmed
The document discusses use case diagrams and use case modeling. It provides an overview of use case diagrams, including their purpose and components. Key points include:
- Use case diagrams show interactions between actors and the system/software being modeled through use cases. They are used early in development to capture requirements and later to specify system behavior.
- Components of a use case diagram include actors, use cases, and relationships between them like generalization, include, and extend. Actors represent roles that interact with the system while use cases represent system functions/processes.
- Examples of a use case diagram for a vehicle sales system are provided to demonstrate how actors, use cases, and relationships can be modeled visually. Guidance is
State chart diagrams define the different states an object can be in during its lifetime, and how it transitions between states in response to events. They are useful for modeling reactive systems by describing the flow of control from one state to another. The key elements are initial and final states, states represented by rectangles, and transitions between states indicated by arrows. State chart diagrams are used to model the dynamic behavior and lifetime of objects in a system and identify the events that trigger state changes.
The document discusses requirements capture using UML use case diagrams. It describes how use case diagrams can be used to capture functional requirements by modeling actors, use cases, and relationships. Key aspects covered include identifying use cases and actors, documenting use case descriptions, modeling relationships between use cases and actors, and tips for effective use case modeling.
System Models in Software Engineering SE7koolkampus
The document discusses various types of system models used in requirements engineering including context models, behavioral models, data models, object models, and how CASE workbenches support system modeling. It describes behavioral models like data flow diagrams and state machine models, data models like entity-relationship diagrams, and object models using the Unified Modeling Language. CASE tools can support modeling through features like diagram editors, repositories, and code generation.
In systems engineering and software engineering, requirements analysis encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating and managing software or system requirements.
The document discusses use case diagrams and use case descriptions for modeling system requirements. It covers drawing use case diagrams to show functional requirements and actors, common mistakes, and writing use case descriptions including basic, alternate, and exception flows of events. The document provides examples and exercises to help understand use cases for requirements modeling.
This document provides an overview of use case diagrams and use cases. It defines what a use case is, including that it captures a user's interaction with a system to achieve a goal. It describes the key components of a use case diagram, including actors, use cases, and relationships between use cases like generalization, inclusion, and extension. An example use case diagram for a money withdrawal from an ATM is presented to illustrate these concepts. Guidelines for documenting use cases with descriptions of flows, exceptions, and other details are also provided.
This document discusses software quality assurance. It defines software quality and describes two types - quality of design and quality of conformance. It discusses quality concepts at the organizational, project, and process levels. It also describes software reviews, their types and purposes. Software quality assurance aims to establish organizational procedures and standards to achieve high quality software. Key SQA activities include applying technical methods, reviews, testing, enforcing standards and measurement.
Lab 3 Introduction to the UML - how to create a use case diagramFarah Ahmed
The document discusses use case diagrams and use case modeling. It provides an overview of use case diagrams, including their purpose and components. Key points include:
- Use case diagrams show interactions between actors and the system/software being modeled through use cases. They are used early in development to capture requirements and later to specify system behavior.
- Components of a use case diagram include actors, use cases, and relationships between them like generalization, include, and extend. Actors represent roles that interact with the system while use cases represent system functions/processes.
- Examples of a use case diagram for a vehicle sales system are provided to demonstrate how actors, use cases, and relationships can be modeled visually. Guidance is
State chart diagrams define the different states an object can be in during its lifetime, and how it transitions between states in response to events. They are useful for modeling reactive systems by describing the flow of control from one state to another. The key elements are initial and final states, states represented by rectangles, and transitions between states indicated by arrows. State chart diagrams are used to model the dynamic behavior and lifetime of objects in a system and identify the events that trigger state changes.
The document discusses requirements capture using UML use case diagrams. It describes how use case diagrams can be used to capture functional requirements by modeling actors, use cases, and relationships. Key aspects covered include identifying use cases and actors, documenting use case descriptions, modeling relationships between use cases and actors, and tips for effective use case modeling.
System Models in Software Engineering SE7koolkampus
The document discusses various types of system models used in requirements engineering including context models, behavioral models, data models, object models, and how CASE workbenches support system modeling. It describes behavioral models like data flow diagrams and state machine models, data models like entity-relationship diagrams, and object models using the Unified Modeling Language. CASE tools can support modeling through features like diagram editors, repositories, and code generation.
In systems engineering and software engineering, requirements analysis encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating and managing software or system requirements.
Interaction modeling describes how objects in a system interact and communicate through message passing. It uses several UML diagrams including use case diagrams, sequence diagrams, activity diagrams, and collaboration diagrams. A use case diagram shows relationships between actors and use cases, while a sequence diagram depicts the temporal order of messages exchanged between objects to complete a scenario. An activity diagram models system workflows and dependencies between activities. A collaboration diagram displays message flows between objects to achieve a particular task.
The document discusses agile software development methods. It covers topics like agile methods, techniques, and project management. Agile development aims to rapidly develop and deliver working software through iterative processes, customer collaboration, and responding to changing requirements. Extreme programming (XP) is an influential agile method that uses practices like test-driven development, pair programming, frequent refactoring, and user stories for requirements specification. The key principles of agile methods are also outlined.
The document discusses use case diagrams in object oriented design and analysis. It defines use cases as descriptions of system functionality from a user perspective. Use case diagrams depict system behavior, users, and relationships between actors, use cases, and other use cases. The key components of use case diagrams are described as actors, use cases, the system boundary, and relationships. Common relationships include association, extend, generalization, uses, and include. An example use case diagram for a cellular telephone is provided to illustrate these concepts.
UML stands for Unified Modelling Language.
UML is a standard language for specifying, visualizing, constructing, and documenting a system in which software represents the most significant part.
UML is different from the other common programming languages like C++, Java, COBOL etc.
UML is a pictorial language used to make software blue prints.
UML can serve as a central notation for software development process. Using UML helps project teams communicate, explore potential designs, and validate the architectural designs of software.
UML diagrams are made using notation of things and relationships.
The building blocks of UML can be defined as:
Things
Relationships
Diagrams
Things: Things are the most important building blocks of UML. Things can be:
Structural
Behavioral
Grouping
Annotational
The Structural things define the static part of the model. They represent physical and conceptual elements. Following are the brief descriptions of the structural things.
Class: Class represents set of objects having similar responsibilities.
Interface: Interface defines a set of operations which specify the responsibility of a class.
Collaboration: Collaboration defines interaction between elements.
Use case: Use case represents a set of actions performed by a system for a specific goal.
Component: Component describes physical part of a system.
Node: A node can be defined as a physical element that exists at run time.
A behavioral thing consists of the dynamic parts of UML models. Following are the behavioral things:
Interaction: Interaction is defined as a behavior that consists of a group of messages exchanged among elements to accomplish a specific task.
State machine: State machine is useful when the state of an object in its life cycle is important. It defines the sequence of states an object goes through in response to events. Events are external factors responsible for state change.
UML (Unified Modeling Language) is a standard language for specifying, visualizing, and documenting software systems. It uses various diagrams to model different views of a system, such as structural diagrams (e.g. class diagrams), behavioral diagrams (e.g. sequence diagrams), and deployment diagrams. The key building blocks of UML include things (classes, interfaces, use cases), relationships (associations, generalizations), and diagrams. UML aims to provide a clear blueprint of software systems for both technical and non-technical audiences.
This presentation is about a lecture I gave within the "Software systems and services" immigration course at the Gran Sasso Science Institute, L'Aquila (Italy): http://cs.gssi.infn.it/.
http://www.ivanomalavolta.com
The document discusses the building blocks of the Unified Modeling Language (UML). It describes the key elements as things (abstractions), relationships (ties between things), and diagrams (groups of related things). The main things are structural (classes, interfaces, etc.), behavioral (interactions, state machines), grouping (packages), and annotational (notes). Relationships include dependencies, associations, generalizations, and realizations. Common diagrams are class, object, use case, sequence, collaboration, statechart, activity, and component diagrams.
The document discusses requirements analysis and analysis modeling principles for software engineering. It covers key topics such as:
1. Requirements analysis specifies a software's operational characteristics and interface with other systems to establish constraints. Analysis modeling focuses on what the software needs to do, not how it will be implemented.
2. Analysis modeling principles include representing the information domain, defining functions, modeling behavior, partitioning complex problems, and moving from essential information to implementation details.
3. Common analysis techniques involve use case diagrams, class diagrams, state diagrams, data flow diagrams, and data modeling to define attributes, relationships, cardinality and modality between data objects.
This document discusses software engineering and software quality assurance. It begins by defining software and describing a case study on the Therac-25 radiation therapy machine which suffered from a software failure disaster. It then covers classification of causes of software errors, definitions of software quality from IEEE and Pressman, and objectives of SQA activities. Key causes of errors listed include faulty requirements, client-developer communication failures, deliberate deviations from requirements, logical design errors, coding errors, non-compliance with documentation, shortcomings in testing, procedure errors, and documentation errors. The document also discusses definitions of quality assurance and quality control and the goals of SQA in software development and maintenance.
This document discusses requirements modeling in software engineering. It covers creating various models during requirements analysis, including scenario-based models, data models, class-oriented models, flow-oriented models, and behavioral models. These models form the requirements model, which is the first technical representation of a system. The document provides examples of writing use cases and constructing a preliminary use case diagram for a home security system called SafeHome. It emphasizes that requirements modeling lays the foundation for software specification and design.
Defining the Problem - Goals and requirementsStephennancy
This document discusses goals and requirements in software engineering projects. It makes the following key points:
- Goals define targets for both the development process and final work products, and can be qualitative or quantitative. Examples of each type are given.
- Requirements specify the capabilities needed to solve the problem, and include functional, performance, and interface requirements. They provide standards for the project and product.
- Both goals and requirements should be specified quantitatively when possible to avoid later misunderstandings, though this can be difficult in the planning phase. Methods for verification should also be defined.
- High-level goals can be translated into specific requirements related to quality attributes like reliability. Milestones can quantify goals
The document discusses software architecture design. It defines software architecture as the structure of components, relationships between components, and properties of components. An architectural design model can be applied to other systems and represents predictable ways to describe architecture. The architecture represents a system and enables analysis of effectiveness in meeting requirements and reducing risks. Key aspects of architectural design include communication between stakeholders, controlling complexity, consistency, reducing risks, and enabling reuse. Common architectural styles discussed include data-centered, data flow, call-and-return, object-oriented, and layered architectures.
The document provides an overview of the Software Engineering course for the second semester of the second year (B.Tech IT/II Sem-II). It includes details about the term, text books, unit syllabus, index of topics, and slides covering introductions to software engineering, the changing nature of software, software myths, generic views of process, the Capability Maturity Model Integration and personal and team software processes.
In software engineering and software architecture design, design decisions address architecturally significant requirements; they are perceived as hard to make and/or costly to change. It is called also architecture strategies and tactics.
Objectives:
1. To understand the different processes in the realm of ‘Requirements Engineering’.
2. To see the challenges in requirements development and the importance of getting requirements right in an IT project.
3. To understand the different techniques used in different phases and processes of requirements development and management.
The document discusses requirements analysis and specification in software engineering. It defines what requirements are and explains the typical activities involved - requirements gathering, analysis, and specification. The importance of documenting requirements in a Software Requirements Specification (SRS) document is explained. Key sections of an SRS like stakeholders, types of requirements (functional and non-functional), and examples are covered. Special attention is given to requirements for critical systems and importance of non-functional requirements.
The document introduces software architecture and describes key aspects of documenting a software architecture. It defines software architecture as the structure of components and relationships in a system. It outlines the 4+1 views model for documenting architecture, including use case, logical, process, deployment, and code views. It provides examples of architectural patterns like model-view-controller and layered patterns. It describes how a software architecture document outlines architectural goals, constraints, and quality attributes.
UML (Unified Modeling Language) is a standardized modeling language used in software engineering to visualize the design of a system. There are two main types of UML diagrams: structural diagrams that depict the static elements of a system, and behavioral diagrams that show the dynamic interactions between structural elements over time. Behavioral diagrams include sequence diagrams, activity diagrams, and state machine diagrams. Sequence diagrams specifically depict the sequential order of interactions between objects in a system through message passing and lifelines.
The document discusses use case diagrams in UML modeling. It defines key components of use case diagrams including use cases, actors, the system boundary, and relationships like include, extend, and generalization. It provides examples of how to construct a use case diagram based on system functions and user goals. Specific use case diagram examples shown include an online ordering system and a vending machine.
The document discusses use case diagrams and their components. It defines key terms like actors, use cases, and relationships between use cases. It explains that use case diagrams model interactions between actors and a system, and capture the system's functional requirements. Diagrams show actors outside the system boundary and use cases inside it. Relationships like "include", "extend", and "generalization" define relationships between use cases. The document provides examples and guidelines for creating use case specifications that describe use case scenarios in detail.
Interaction modeling describes how objects in a system interact and communicate through message passing. It uses several UML diagrams including use case diagrams, sequence diagrams, activity diagrams, and collaboration diagrams. A use case diagram shows relationships between actors and use cases, while a sequence diagram depicts the temporal order of messages exchanged between objects to complete a scenario. An activity diagram models system workflows and dependencies between activities. A collaboration diagram displays message flows between objects to achieve a particular task.
The document discusses agile software development methods. It covers topics like agile methods, techniques, and project management. Agile development aims to rapidly develop and deliver working software through iterative processes, customer collaboration, and responding to changing requirements. Extreme programming (XP) is an influential agile method that uses practices like test-driven development, pair programming, frequent refactoring, and user stories for requirements specification. The key principles of agile methods are also outlined.
The document discusses use case diagrams in object oriented design and analysis. It defines use cases as descriptions of system functionality from a user perspective. Use case diagrams depict system behavior, users, and relationships between actors, use cases, and other use cases. The key components of use case diagrams are described as actors, use cases, the system boundary, and relationships. Common relationships include association, extend, generalization, uses, and include. An example use case diagram for a cellular telephone is provided to illustrate these concepts.
UML stands for Unified Modelling Language.
UML is a standard language for specifying, visualizing, constructing, and documenting a system in which software represents the most significant part.
UML is different from the other common programming languages like C++, Java, COBOL etc.
UML is a pictorial language used to make software blue prints.
UML can serve as a central notation for software development process. Using UML helps project teams communicate, explore potential designs, and validate the architectural designs of software.
UML diagrams are made using notation of things and relationships.
The building blocks of UML can be defined as:
Things
Relationships
Diagrams
Things: Things are the most important building blocks of UML. Things can be:
Structural
Behavioral
Grouping
Annotational
The Structural things define the static part of the model. They represent physical and conceptual elements. Following are the brief descriptions of the structural things.
Class: Class represents set of objects having similar responsibilities.
Interface: Interface defines a set of operations which specify the responsibility of a class.
Collaboration: Collaboration defines interaction between elements.
Use case: Use case represents a set of actions performed by a system for a specific goal.
Component: Component describes physical part of a system.
Node: A node can be defined as a physical element that exists at run time.
A behavioral thing consists of the dynamic parts of UML models. Following are the behavioral things:
Interaction: Interaction is defined as a behavior that consists of a group of messages exchanged among elements to accomplish a specific task.
State machine: State machine is useful when the state of an object in its life cycle is important. It defines the sequence of states an object goes through in response to events. Events are external factors responsible for state change.
UML (Unified Modeling Language) is a standard language for specifying, visualizing, and documenting software systems. It uses various diagrams to model different views of a system, such as structural diagrams (e.g. class diagrams), behavioral diagrams (e.g. sequence diagrams), and deployment diagrams. The key building blocks of UML include things (classes, interfaces, use cases), relationships (associations, generalizations), and diagrams. UML aims to provide a clear blueprint of software systems for both technical and non-technical audiences.
This presentation is about a lecture I gave within the "Software systems and services" immigration course at the Gran Sasso Science Institute, L'Aquila (Italy): http://cs.gssi.infn.it/.
http://www.ivanomalavolta.com
The document discusses the building blocks of the Unified Modeling Language (UML). It describes the key elements as things (abstractions), relationships (ties between things), and diagrams (groups of related things). The main things are structural (classes, interfaces, etc.), behavioral (interactions, state machines), grouping (packages), and annotational (notes). Relationships include dependencies, associations, generalizations, and realizations. Common diagrams are class, object, use case, sequence, collaboration, statechart, activity, and component diagrams.
The document discusses requirements analysis and analysis modeling principles for software engineering. It covers key topics such as:
1. Requirements analysis specifies a software's operational characteristics and interface with other systems to establish constraints. Analysis modeling focuses on what the software needs to do, not how it will be implemented.
2. Analysis modeling principles include representing the information domain, defining functions, modeling behavior, partitioning complex problems, and moving from essential information to implementation details.
3. Common analysis techniques involve use case diagrams, class diagrams, state diagrams, data flow diagrams, and data modeling to define attributes, relationships, cardinality and modality between data objects.
This document discusses software engineering and software quality assurance. It begins by defining software and describing a case study on the Therac-25 radiation therapy machine which suffered from a software failure disaster. It then covers classification of causes of software errors, definitions of software quality from IEEE and Pressman, and objectives of SQA activities. Key causes of errors listed include faulty requirements, client-developer communication failures, deliberate deviations from requirements, logical design errors, coding errors, non-compliance with documentation, shortcomings in testing, procedure errors, and documentation errors. The document also discusses definitions of quality assurance and quality control and the goals of SQA in software development and maintenance.
This document discusses requirements modeling in software engineering. It covers creating various models during requirements analysis, including scenario-based models, data models, class-oriented models, flow-oriented models, and behavioral models. These models form the requirements model, which is the first technical representation of a system. The document provides examples of writing use cases and constructing a preliminary use case diagram for a home security system called SafeHome. It emphasizes that requirements modeling lays the foundation for software specification and design.
Defining the Problem - Goals and requirementsStephennancy
This document discusses goals and requirements in software engineering projects. It makes the following key points:
- Goals define targets for both the development process and final work products, and can be qualitative or quantitative. Examples of each type are given.
- Requirements specify the capabilities needed to solve the problem, and include functional, performance, and interface requirements. They provide standards for the project and product.
- Both goals and requirements should be specified quantitatively when possible to avoid later misunderstandings, though this can be difficult in the planning phase. Methods for verification should also be defined.
- High-level goals can be translated into specific requirements related to quality attributes like reliability. Milestones can quantify goals
The document discusses software architecture design. It defines software architecture as the structure of components, relationships between components, and properties of components. An architectural design model can be applied to other systems and represents predictable ways to describe architecture. The architecture represents a system and enables analysis of effectiveness in meeting requirements and reducing risks. Key aspects of architectural design include communication between stakeholders, controlling complexity, consistency, reducing risks, and enabling reuse. Common architectural styles discussed include data-centered, data flow, call-and-return, object-oriented, and layered architectures.
The document provides an overview of the Software Engineering course for the second semester of the second year (B.Tech IT/II Sem-II). It includes details about the term, text books, unit syllabus, index of topics, and slides covering introductions to software engineering, the changing nature of software, software myths, generic views of process, the Capability Maturity Model Integration and personal and team software processes.
In software engineering and software architecture design, design decisions address architecturally significant requirements; they are perceived as hard to make and/or costly to change. It is called also architecture strategies and tactics.
Objectives:
1. To understand the different processes in the realm of ‘Requirements Engineering’.
2. To see the challenges in requirements development and the importance of getting requirements right in an IT project.
3. To understand the different techniques used in different phases and processes of requirements development and management.
The document discusses requirements analysis and specification in software engineering. It defines what requirements are and explains the typical activities involved - requirements gathering, analysis, and specification. The importance of documenting requirements in a Software Requirements Specification (SRS) document is explained. Key sections of an SRS like stakeholders, types of requirements (functional and non-functional), and examples are covered. Special attention is given to requirements for critical systems and importance of non-functional requirements.
The document introduces software architecture and describes key aspects of documenting a software architecture. It defines software architecture as the structure of components and relationships in a system. It outlines the 4+1 views model for documenting architecture, including use case, logical, process, deployment, and code views. It provides examples of architectural patterns like model-view-controller and layered patterns. It describes how a software architecture document outlines architectural goals, constraints, and quality attributes.
UML (Unified Modeling Language) is a standardized modeling language used in software engineering to visualize the design of a system. There are two main types of UML diagrams: structural diagrams that depict the static elements of a system, and behavioral diagrams that show the dynamic interactions between structural elements over time. Behavioral diagrams include sequence diagrams, activity diagrams, and state machine diagrams. Sequence diagrams specifically depict the sequential order of interactions between objects in a system through message passing and lifelines.
The document discusses use case diagrams in UML modeling. It defines key components of use case diagrams including use cases, actors, the system boundary, and relationships like include, extend, and generalization. It provides examples of how to construct a use case diagram based on system functions and user goals. Specific use case diagram examples shown include an online ordering system and a vending machine.
The document discusses use case diagrams and their components. It defines key terms like actors, use cases, and relationships between use cases. It explains that use case diagrams model interactions between actors and a system, and capture the system's functional requirements. Diagrams show actors outside the system boundary and use cases inside it. Relationships like "include", "extend", and "generalization" define relationships between use cases. The document provides examples and guidelines for creating use case specifications that describe use case scenarios in detail.
The document discusses use case modeling and UML diagrams. It provides an overview of commonly used UML diagrams such as use case diagrams, activity diagrams, class diagrams, sequence diagrams, and collaboration diagrams. It then describes use cases, use case diagrams, and relationships between use cases including include, extend, and generalize relationships.
A use case diagram captures system functionality and requirements by modeling actors and use cases. Actors represent roles that interact with the system, while use cases represent system functions. A use case diagram visually shows the relationships between actors and use cases. An include relationship shows that one use case includes the functionality of another, while an extend relationship shows optional or conditional behavior. Generalization defines one use case as a generalization of another to replace generic functionality.
Use case diagrams are used to visualize how actors interact with a system's functions. They identify the actors, functions (use cases), and relationships between actors and functions. This document discusses the key components of use case diagrams including actors, use cases, system boundary, packages, and relationship types. It provides examples of how use case diagrams are used to gather requirements and provide overviews of system functionality and actor interactions.
This document provides an overview of use case modeling. It defines what use cases are, how they are created, and the elements that comprise them. Use cases describe the functional requirements of a system from the perspective of an actor. They are developed through user interviews and documentation analysis to understand how users interact with the system. Use cases are then written as text descriptions and organized visually in a use case diagram to show relationships between use cases and actors.
Lecture no 8 use case modeling and use case diagramsnaveed428
The document discusses use case modeling and diagrams. It provides examples of use cases, actors, and relationships between them. Some key points:
- A use case represents a goal of an actor and the interactions needed to achieve that goal. Actors can be people or other systems.
- Use case diagrams show use cases, actors, and their relationships to understand system requirements and functionality.
- Common relationships include generalization, extension, and inclusion to model optional/exceptional behavior or reuse of common interactions.
- Well-defined use cases with descriptions help validate requirements, guide testing, and communicate with stakeholders.
This document discusses use case analysis, including the elements of a use case, alternative formats, and how use cases relate to functional requirements and testing. It provides details on how to build use cases, such as identifying the major steps and inputs/outputs of each use case. Use cases represent how a system interacts with users and other systems by illustrating activities and responses. They help understand user requirements to develop functional specifications for developers.
Use case diagrams depict the functionality of a system from a user perspective by showing actors, use cases, and relationships between them. Actors represent roles that interact with the system, while use cases represent system functions. Relationships include association, extend, generalization, uses, and include. Each use case contains details like preconditions, postconditions, normal and alternative flows, and exceptions. Use cases are identified through actor-based and event-based methods by determining actor tasks and system responses to external events.
A use case diagram visually presents interactions between a system and external users or systems. It uses common UML elements like actors, use cases, and relationships. Key elements include actors that represent user roles, use cases that define system functionality, and relationships that show how actors interact with use cases. A use case description provides additional text details for each interaction. Examples demonstrate use case diagrams for bank ATMs and a student-teacher information system.
Materi yang ada pada slide ini berisi :
Pengenalan UML Sebagai Alat Bantu Pemodelan Pada Pembangunan Perangkat Lunak Menggunakan Pendekatan Analisis dan Desain Berorientasi Objek
Notasi, Semantik, dan Stereotype Pada UML
Komponen pada UML (Use Case View, Logical View, Physical View, dan Process View)
Pengenalan Use Case Diagram sebagai Use Case View Pada UML
Penjelasan Aktor, Generalisasi Aktor, dan Use Case
Penjelasan Use Case Scenario
Use Case Refinement (Relasi Include, Extends, dan Generalisasi Use Case)
----------------------------------------------------------------------
Keep in touch with me in :
Twitter : https://twitter.com/rizkiadam_1991
Email : rizkiadamunikom@gmail.com
IG : @rizkiadamkurniawan
The document discusses use cases, which describe how users will interact with a system to perform tasks and achieve goals. Use cases help capture functional requirements, provide examples for developers, and form a basis for testing. Key elements of a use case include a name, summary, actors, flow of events, and exceptions. The document provides an example use case for raising an employee's salary and guidelines for writing effective use cases.
The document discusses use cases, which describe how users will interact with a system to perform tasks and achieve goals. Use cases help capture functional requirements, provide examples for developers, and form a basis for testing. Elements of a use case include a name, summary, frequency, actors, preconditions, steps, exceptions, and postconditions. An example use case described raising an employee's salary in a human-readable story format. Use cases should be understandable, meaningful, and focus on valuable tasks without being too broad or narrow in scope.
UML was developed to standardize object-oriented modeling notations. It consolidated techniques like OMT, OOSE, and the Booch Methodology. UML provides multiple views (diagrams) to model a system, including structural, behavioral, implementation, and environmental views. Common UML diagrams are use case diagrams, which model functionality from the user's perspective, and class diagrams, which show system structure.
Use case diagrams describe interactions between actors and a system to accomplish goals. A use case diagram typically includes:
1) Actors that interact with the system from outside, such as users or other systems. Common actor types are primary actors whose goals are fulfilled by the system and supporting actors that provide services.
2) Use cases that represent functions or tasks performed by the system. They are connected to relevant actors and may have relationships like include and extend.
3) Relationships between use cases like include, which shows a use case incorporating another, and extend, where a use case optionally extends another.
Use case diagrams provide an overview of a system's functions and how outside actors interact with them at a
Use case diagrams describe interactions between actors and a system to accomplish goals. A use case diagram typically includes:
1) Actors that interact with the system from outside, such as users or other systems. Common actor types are primary actors whose goals are fulfilled by the system and supporting actors that provide services.
2) Use cases that represent functions or tasks performed by the system. They are connected to relevant actors and may have relationships like include and extend.
3) Relationships between use cases like include, which shows a use case incorporating another, and extend, where a use case optionally extends another.
Use case diagrams provide an overview of a system's functions and how outside actors interact with them at a
UML (Unified Modeling Language) is a standard modeling language used to document and visualize the design of object-oriented software systems. It was developed in the 1990s to standardize the different object-oriented modeling notations that existed. UML is based on several influential object-oriented analysis and design methodologies. It includes diagrams for modeling a system's structural and behavioral elements, and has continued to evolve with refinements and expanded applicability. Use case diagrams are one type of UML diagram that are used to define system behaviors and goals from the perspective of different user types or external entities known as actors.
The document discusses various UML diagrams including use case diagrams, describing use cases as interactions between actors and systems to achieve goals, use case elements such as actors, scenarios, and relationships including generalization, extension, and inclusion. It provides examples of use case diagrams and templates for an ATM system and a school management system.
This document provides information on object oriented analysis and use case modeling. It discusses identifying objects and their relationships, defining object operations and attributes, and modeling system functionality through use cases. Use cases describe interactions between actors and the system, including typical workflows, alternative scenarios, and pre- and post-conditions. Use case diagrams visually represent the relationships between actors and use cases.
Similar to Presentation Use Case Diagram and Use Case Specification.pptx (20)
This document discusses information systems analysis and prototyping. It begins with an agenda that covers defining prototyping, the need for it, types of prototypes, prototyping as a methodology, user interface prototyping, and advantages and disadvantages. It then defines prototyping and discusses the need for it to explore problems and solutions with stakeholders. Various types of prototypes are covered, including throwaway, evolutionary, low-fidelity, and high-fidelity. Prototyping is presented as a methodology involving preliminary designs and refinements. The document concludes with risks of prototyping and key learnings around using prototypes to understand requirements and evolve systems.
The document discusses the OWASP Software Assurance Maturity Model (SAMM) which provides a framework for organizations to improve their application security practices. SAMM defines security practices across various stages of the development lifecycle. It establishes maturity levels for each practice to guide organizations from an initial to comprehensive approach. SAMM includes assessment worksheets, roadmap templates, and other resources to help organizations measure their maturity and develop a phased plan to strengthen security.
The document discusses access control and authorization in distributed systems. It introduces role-based access control (RBAC) as a promising approach. RBAC separates the administration of principals and roles from the specification of authorization policy in terms of roles. This allows authorization policy to be expressed independently of changes to principal membership. RBAC also facilitates inter-domain authorization by allowing roles to span domains. The document presents an example RBAC implementation using the OASIS framework that specifies role activation and authorization policies using rules. It also discusses engineering role certificates and maintaining credential state to support RBAC in a distributed environment.
The document discusses validating all inputs to prevent cross-site scripting (XSS) attacks. It introduces the OWASP HTML Sanitizer Project, which is a Java library that sanitizes HTML to allow untrusted user input to be safely embedded in web pages. The sanitizer removes malicious code while keeping desired markup, through a policy-based approach. Sample usages demonstrated validate specific elements like images and links. The project aims to protect against XSS while allowing third-party content through a tested, securely-designed library.
The document provides information on coding techniques and best practices for variable declarations and naming. It discusses data types, initializing variables, variable scope, naming conventions, and the Hungarian notation naming convention. The key points are:
- Variables should be declared close to where they are used and initialized immediately to avoid errors from unintended values.
- Variable names should be descriptive yet concise to indicate what they represent and avoid confusion. Naming conventions can help with readability and consistency.
- The Hungarian notation convention prefixes variable names with abbreviations to indicate their type, scope, and other properties to make their purpose clear at a glance.
Defensive programming techniques aim to avoid problems in code development and during runtime. Issues that can occur include dodgy user input data, poorly structured code that is hard to maintain, and runtime errors. Defensive design focuses on preventing unintended exploitation of systems, keeping code well-organized, and minimizing bugs. Input validation and sanitization are important techniques to check user data meets criteria and remove unwanted characters. Database inputs especially need to be sanitized to prevent SQL injection attacks.
This document discusses defensive programming techniques of assertions and parameter checking. Assertions allow programmers to explicitly check assumptions in code through boolean conditions. If an assertion fails, it throws an error. Parameter checking validates function parameters are valid, either through assertions or throwing exceptions if invalid. Both help avoid bugs by detecting errors early.
This document provides an overview of the requirements analysis process. It explains that requirements come from both business and technical perspectives and describe what the system must do and how it will be implemented. Various techniques for gathering requirements are discussed, including interviews, documentation analysis, questionnaires, observation, and prototyping. The importance of user involvement and properly documenting requirements is also covered.
This document provides an overview of the requirements analysis process. It explains that requirements come from both business and technical perspectives and describe what the system must do and how it will be implemented. Various techniques for gathering requirements are discussed, including interviews, documentation analysis, questionnaires, observation, and prototyping. The importance of user involvement and properly documenting requirements is also covered.
The document provides an overview of a lecture on system analysis and design (SAD). It introduces SAD processes and approaches, including structured analysis, design, and programming as well as object-oriented analysis and design. Key concepts covered include objects, classes, encapsulation, inheritance, and polymorphism in the object-oriented approach.
This document covers topics in requirements engineering including functional and non-functional requirements, the software requirements document, requirements specification, and requirements processes. It defines requirements engineering as establishing customer services and system constraints. Requirements can range from abstract to detailed specifications and serve both bidding and contractual purposes. User requirements use natural language while system requirements provide structured descriptions. Functional requirements define system services and behaviors while non-functional requirements constrain timing, standards, and processes.
The document provides information on modeling business processes using activity diagrams. It discusses the key elements and notation of activity diagrams including activities, transitions, start/final states, decisions, swimlanes, and parallel activities. Guidelines are provided for creating activity diagrams such as setting the context, identifying activities and organizing them in order, adding decisions, object flows, prospects for parallelism, and swimlanes. An example activity diagram for a dentist office system is described and guidelines are given for developing the diagram and associated use case descriptions.
The document provides an overview of a module on system analysis and design (SAD). It discusses the structured approach to SAD using techniques like data flow diagrams, entity relationship diagrams, and structure charts. It also covers the object-oriented approach, defining key concepts like objects, classes, encapsulation, inheritance, and polymorphism. The structured approach models the problem as a set of functions, while the object-oriented approach models the real world and subdivides problems based on objects.
A workshop hosted by the South African Journal of Science aimed at postgraduate students and early career researchers with little or no experience in writing and publishing journal articles.
This slide is special for master students (MIBS & MIFB) in UUM. Also useful for readers who are interested in the topic of contemporary Islamic banking.
LAND USE LAND COVER AND NDVI OF MIRZAPUR DISTRICT, UPRAHUL
This Dissertation explores the particular circumstances of Mirzapur, a region located in the
core of India. Mirzapur, with its varied terrains and abundant biodiversity, offers an optimal
environment for investigating the changes in vegetation cover dynamics. Our study utilizes
advanced technologies such as GIS (Geographic Information Systems) and Remote sensing to
analyze the transformations that have taken place over the course of a decade.
The complex relationship between human activities and the environment has been the focus
of extensive research and worry. As the global community grapples with swift urbanization,
population expansion, and economic progress, the effects on natural ecosystems are becoming
more evident. A crucial element of this impact is the alteration of vegetation cover, which plays a
significant role in maintaining the ecological equilibrium of our planet.Land serves as the foundation for all human activities and provides the necessary materials for
these activities. As the most crucial natural resource, its utilization by humans results in different
'Land uses,' which are determined by both human activities and the physical characteristics of the
land.
The utilization of land is impacted by human needs and environmental factors. In countries
like India, rapid population growth and the emphasis on extensive resource exploitation can lead
to significant land degradation, adversely affecting the region's land cover.
Therefore, human intervention has significantly influenced land use patterns over many
centuries, evolving its structure over time and space. In the present era, these changes have
accelerated due to factors such as agriculture and urbanization. Information regarding land use and
cover is essential for various planning and management tasks related to the Earth's surface,
providing crucial environmental data for scientific, resource management, policy purposes, and
diverse human activities.
Accurate understanding of land use and cover is imperative for the development planning
of any area. Consequently, a wide range of professionals, including earth system scientists, land
and water managers, and urban planners, are interested in obtaining data on land use and cover
changes, conversion trends, and other related patterns. The spatial dimensions of land use and
cover support policymakers and scientists in making well-informed decisions, as alterations in
these patterns indicate shifts in economic and social conditions. Monitoring such changes with the
help of Advanced technologies like Remote Sensing and Geographic Information Systems is
crucial for coordinated efforts across different administrative levels. Advanced technologies like
Remote Sensing and Geographic Information Systems
9
Changes in vegetation cover refer to variations in the distribution, composition, and overall
structure of plant communities across different temporal and spatial scales. These changes can
occur natural.
it describes the bony anatomy including the femoral head , acetabulum, labrum . also discusses the capsule , ligaments . muscle that act on the hip joint and the range of motion are outlined. factors affecting hip joint stability and weight transmission through the joint are summarized.
Walmart Business+ and Spark Good for Nonprofits.pdfTechSoup
"Learn about all the ways Walmart supports nonprofit organizations.
You will hear from Liz Willett, the Head of Nonprofits, and hear about what Walmart is doing to help nonprofits, including Walmart Business and Spark Good. Walmart Business+ is a new offer for nonprofits that offers discounts and also streamlines nonprofits order and expense tracking, saving time and money.
The webinar may also give some examples on how nonprofits can best leverage Walmart Business+.
The event will cover the following::
Walmart Business + (https://business.walmart.com/plus) is a new shopping experience for nonprofits, schools, and local business customers that connects an exclusive online shopping experience to stores. Benefits include free delivery and shipping, a 'Spend Analytics” feature, special discounts, deals and tax-exempt shopping.
Special TechSoup offer for a free 180 days membership, and up to $150 in discounts on eligible orders.
Spark Good (walmart.com/sparkgood) is a charitable platform that enables nonprofits to receive donations directly from customers and associates.
Answers about how you can do more with Walmart!"
3. Lecture Layout
Use Case Diagram
Use Case
Actor
Relationship (include & extend)
Use Case Specification
4. Objectives
Transform and represent the user
requirements into use case diagram using
UML notation
Develop use case specification
Identify basic flow, alternatives flow and
exceptional flows
6. • Use case diagram is used to show the functionality
that the system will provide and to show which users
will communicate with the system in some way to use
that functionality.
• Primary components are : use cases, actors,
system/subsystem and relationships
actor use case
Basic use case diagram
Use Case Diagram
7. To document the functionalities of the system from the
users’ perspective, resulting in an agreement between
the clients and the developers;
To document the scope of the system
To document the interaction between the users and the
system using supporting use case descriptions
To provide basis for performing system tests
To provide the ability to trace functional requirements
into implementation later on
Purpose of Use Case Diagram
8. A description of the functionality of the system from the
users’ perspective.
A set of sequences of actions that the system performs
to achieve an observable result of value to an
actor.(UML User Guide)
A depiction of a system’s behaviour or functionality
under various conditions as the system responds to
requests from users.(George et al., 2004)
is a complete and meaningful flow of events and it is
initiated by an actor
Use Case
9. Consists a set of possible sequences of interactions
between a system and a user in a particular
environment and related to a particular goal. (George et
al, 2004)
If changes are made to this use case model, other
models must be updated too.
Remember, in OOSAD all process are iterative and need
refinement!
UML notation for use case:
Name of use case
Use Case
10. Represent the roles that people, other systems or
devices take on when communicating with the
particular use cases in the system
actively interchange information with the system by
sending and receiving message
can represent a human, machine and another
system
UML notation for actor:
Actor
Actor
11. Types of Actor:
1. Primary actor
• active and initiate activity with the system
• get some values in return
2. Secondary actor
• passive and don’t initiate any activity with the
system
• ultimately fulfill the needs of primary actor
Actor
13. customer
buy drink
System or subsystem boundary
Actor
Use case
Communication
association
Based on Vending Machine Control System
Notation Of Use Case Diagram
14. • Actor
– drawn as stick people with a name
– The name is usually a noun phrase
Use case
drawn as ellipses with a name in or
below each ellipse
the name is usually an active verb (what
the system is supposed to do) and a
noun phrase (what the system to act
on) print bill
student
Notation Of Use Case Diagram
15. • Communication associations
– line drawn between an actor and a use case
– can have arrow heads to show where the
communication is initiated
– represent communication link between an instance
of the use case and an instance of the actor
• Sub-systems
– drawn as a rectangle around a group of use cases
that belongs to the same sub-system
Notation Of Use Case Diagram
16. • Grouping
It is used when a number of use cases handle
similar functionality or are related, they can be
grouped in a UML package. A package groups
related model elements.
Notation Of Use Case Diagram
17. 1. A use case is always initiated by an actor
Always performed on behalf of an actor. The actor
must directly or indirectly order the system to perform
the use case.
2. A use case provides a value to an actor
Must deliver some kind of tangible values to the users.
3. A use case is complete
Must be a complete description. It is not complete
until the end value is produced. Common mistake
make a simple use case that can only be implemented
later on as functions call.
Characteristic Of Use Case
18. 1. Which functions does the actor requires from the
system? What does the actor need to do?
2. Does the actor needs to read, create, destroy,
modify, or store some kind of info in the system?
3. Does the actor needs to notify/be notified about
events in the system?
4. Could the actor’s daily work be simplified?
automated?
5. What kind of outputs/inputs the actor requires?
6. What are major problems with current system?
Finding Use Case
19. Types of relationships between use cases:
– 2 types of stereotyped dependencies are:
• extend
• include (sometimes referred as uses)
– stereotypes are written as text strings in
« » symbol such as:
«extend» and «include»
- Stereotypes are placed along the relationship line.
Relationship between Use Cases
20. • An extend relationship is used when you wish to show
that a use case provides additional functionality that
may be required in another use case.
• Purpose:
– To model optional behaviour or alternative at certain
point in separate use case.
– To mitigate the complexity of base use case
• View as optional system behaviour
Extend Relationship
21. editor
spell checking grammar checking
edit text
<<extend>> <<extend>>
Every time an editor wants to edit text, he can do spell
checking or grammar checking use case
Extend Relationship
22. • An include relationship is used when you wish to show
that a use case provides additional functionality that
always required in another use case.
• Never stands alone
• Purpose:
– a use case may include more than one other use
cases
– can be used to separate out a sequence of behaviour
that is used in many use cases (reusable or common
behaviour)
Include Relationship
23. customer
deposit funds
withdraw money
verify customer
<<include>>
<<include>>
Every time a customer wants to deposit funds, he must verify
himself to the system.
Include Relationship
24. • Generalization
– Actors can also be implemented as classes. So, they
can also have the same relationship as classes.
– Common behaviour between a number of actors can
be modelled using generalization relationship
– When several actors play a more general role, it is
described as generalization. The specialized actor
inherit the behaviour of the super class.
– shows that one actor can participate in all the
associations with use cases that the more specific
actor can plus some additional use cases
Relationship between Actors
26. • Identify major use cases
1. Find the system’s boundary
2. List primary actors
3. List the goals of the primary actor
4. Identify and write the overviews of the major use
cases for the above
5. Carefully review the current use cases. Revise as
needed.
• Expand major use case
• Confirm major use cases
• Create use case diagram
Steps for writing effective use case
diagram & use case specification
27. • Identify major use cases
• Expand major use case
6. Choose one use case to expand
7. Start filling the details of the chosen use case
8. Write the normal flow of events
9. If the normal flow is too complex, decompose to
subflows
10. List the possible alternative or exceptional flow(s)
11. Write description for alternative or exceptional
flow(s)
• Confirm major use cases
• Create use case diagram
Steps for writing effective use case
diagram & use case specification
28. • Identify major use cases
• Expand major use case
• Confirm major use cases
12. Carefully review the current set of use cases. Revise
as needed.
13. Start at the top again. (iteratively)
• Create use case diagram
1. Draw the system boundary
2. Place the use cases
3. Place the actors
4. Draw associations.
Steps for writing effective use case
diagram & use case specification
29. • Show only those use cases that are important to
understand the behavior of the system in its context.
• Show only those actors that relate to these use cases.
• Each use case diagram should focus on
communicating one aspect of a system.
• Try to keep them simple.
Guidelines for Use Case Diagram
30. • Names a single, identifiable, and reasonably atomic
behavior of the system.
• Describes the flow of events clearly enough for an
outsider to easily understand it.
• Factor common behavior by pulling such behavior
from use cases that it includes.
• Factor variant behavior by pushing such behavior into
other use cases that extend it.
Guidelines for Use Case Diagram
32. • Use Case Specification is known as Use Case
Description.
• The Use Case Specification includes:
Brief description:
• Summary of use case
• Describe the use case not more than 5
lines.
Use Case Specification
33. Pre-conditions:
•List all the conditions that must be completed
before entering the use case.
•This is optional. State not applicable if there is
no condition.
Characteristic of activations:
•This shows how to activate the use case.
•It could be actor’s demand or event- driven.
Use Case Specification
34. Flow of events
• Basic flow
– Describe the use case as a normal flow
– Happy day scenario-that means the use case should
success in completing the task.
• Alternative flow
– Describe the alternative way
– Means that, it is optional for the actor to complete it
or not.
• Exceptional flow
– Describe the exceptional in completing the use case.
– Show the error handling
Use Case Specification
35. Post conditions
• Show the conditions after completing the
use case
• It is an optional.
Rules
• Describe the rules that the use case must
follow
• It is an optional
Use Case Specification
36. –Constraints
•Describe the limitation that the use case have
•It is an optional
For complete example, refer to Use Case
Specification f
Use Case Specification
38. Draw a use case diagram for an ATM machine with the following
functionality. A customer’s interaction with the system involves
logging in, making withdrawal requests, deposit requests, and
balance inquiry requests. If the customer logs in, there is a
possibility (although rare) that the system will confiscate the card
(for example, if the login is incorrect or if the bank determines that
the customer’s balance is significantly under zero). Card
confiscation involves triggering an alert, which will be received by
the branch manager of the bank. If the customer does a balance
inquiry, this of course causes the system to check the balance.
Checking the balance is also done when the customer requests a
withdrawal, since the system must verify that enough money is in
his account. In principle, checking the balance is a function that may
be performed to support many use cases throughout the system.
Exercise : ATM System