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.
This document discusses key concepts in software design engineering including analysis models, design models, the programmer's approach versus best practices, purposes of design, quality guidelines, design principles, fundamental concepts like abstraction and architecture, and specific design concepts like patterns, modularity, and information hiding. It emphasizes that design is important for translating requirements into a quality software solution before implementation begins.
This document discusses the Think Pair Share activity and principles of cohesion and coupling in software design. It provides definitions and examples of different types of coupling (data, stamp, control, etc.) and levels of cohesion (functional, sequential, communicational, etc.). The key goals are to minimize coupling between modules to reduce dependencies, and maximize cohesion so elements within a module are strongly related and focused on a single task. High cohesion and low coupling lead to components that are more independent, flexible, and maintainable.
Activity diagrams show the flow and sequence of activities in a system by depicting actions, decisions, and parallel processes through graphical symbols like activities, transitions, decisions, and swimlanes. They are used to model workflows, use cases, and complex methods by defining activities, states, objects, responsibilities, and connections between elements. Guidelines are provided for creating activity diagrams, such as identifying the workflow objective, pre/post-conditions, activities, states, objects, responsibilities, and evaluating for concurrency.
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.
Software requirement engineering bridges the gap between system engineering and software design. It involves gathering requirements through elicitation techniques like interviews and facilitated application specification technique (FAST), analyzing requirements, modeling them, specifying them in documents like use cases, and reviewing the requirements specification. Quality function deployment translates customer needs into technical requirements. Rapid prototyping helps validate requirements by constructing a partial system implementation using tools like 4GLs, reusable components, or formal specification languages. The software requirements specification document is produced at the end of analysis and acts as a contract between developers and customers.
The document discusses modeling different aspects of software systems using UML diagrams. It covers modeling events using state machines, the four types of events that can be modeled in UML (signals, calls, time, and state change), modeling logical database schemas using class diagrams, modeling source code using artifact diagrams, modeling executable releases using artifact diagrams to show deployment artifacts and relationships, and modeling physical databases by defining tables for classes while considering inheritance relationships.
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 component diagrams describe software components and their dependencies. A component represents a modular and replaceable unit with well-defined interfaces. Component diagrams show the organization and dependencies between components using interfaces, dependencies, ports, and connectors. They can show both the external view of a component's interfaces as well as its internal structure by nesting other components or classes.
This document discusses key concepts in software design engineering including analysis models, design models, the programmer's approach versus best practices, purposes of design, quality guidelines, design principles, fundamental concepts like abstraction and architecture, and specific design concepts like patterns, modularity, and information hiding. It emphasizes that design is important for translating requirements into a quality software solution before implementation begins.
This document discusses the Think Pair Share activity and principles of cohesion and coupling in software design. It provides definitions and examples of different types of coupling (data, stamp, control, etc.) and levels of cohesion (functional, sequential, communicational, etc.). The key goals are to minimize coupling between modules to reduce dependencies, and maximize cohesion so elements within a module are strongly related and focused on a single task. High cohesion and low coupling lead to components that are more independent, flexible, and maintainable.
Activity diagrams show the flow and sequence of activities in a system by depicting actions, decisions, and parallel processes through graphical symbols like activities, transitions, decisions, and swimlanes. They are used to model workflows, use cases, and complex methods by defining activities, states, objects, responsibilities, and connections between elements. Guidelines are provided for creating activity diagrams, such as identifying the workflow objective, pre/post-conditions, activities, states, objects, responsibilities, and evaluating for concurrency.
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.
Software requirement engineering bridges the gap between system engineering and software design. It involves gathering requirements through elicitation techniques like interviews and facilitated application specification technique (FAST), analyzing requirements, modeling them, specifying them in documents like use cases, and reviewing the requirements specification. Quality function deployment translates customer needs into technical requirements. Rapid prototyping helps validate requirements by constructing a partial system implementation using tools like 4GLs, reusable components, or formal specification languages. The software requirements specification document is produced at the end of analysis and acts as a contract between developers and customers.
The document discusses modeling different aspects of software systems using UML diagrams. It covers modeling events using state machines, the four types of events that can be modeled in UML (signals, calls, time, and state change), modeling logical database schemas using class diagrams, modeling source code using artifact diagrams, modeling executable releases using artifact diagrams to show deployment artifacts and relationships, and modeling physical databases by defining tables for classes while considering inheritance relationships.
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 component diagrams describe software components and their dependencies. A component represents a modular and replaceable unit with well-defined interfaces. Component diagrams show the organization and dependencies between components using interfaces, dependencies, ports, and connectors. They can show both the external view of a component's interfaces as well as its internal structure by nesting other components or classes.
Object oriented concepts can be summarized in 3 sentences:
Objects have state, behavior, and identity. State represents the properties and values of an object, behavior is defined by the operations or methods that can be performed on an object, and identity uniquely distinguishes one object from all others. Key concepts in object orientation include abstraction, encapsulation, modularity, hierarchy, polymorphism, and life span of objects. These concepts help organize programs through the definition and use of classes and objects.
The document discusses requirements modeling and analysis modeling in software engineering. It provides information on:
1) The different types of models that can be created during requirements modeling, including requirements models, design models, scenario-based models, data models, class-based models, flow-oriented models, and behavioral models.
2) The purposes of requirements modeling, which include representing customer requirements, gaining a better understanding of the system, and providing information to help with system design and development.
3) Key principles of requirements modeling, such as representing the information, functional, and behavioral domains of the system and partitioning models in a layered/hierarchical way.
4) Specific modeling techniques like scenario-based modeling, data
The document discusses various techniques for analysis modeling in software engineering. It describes the goals of analysis modeling as providing the first technical representation of a system that is easy to understand and maintain. It then covers different types of analysis models, including flow-oriented modeling, scenario-based modeling using use cases and activity diagrams, and class-based modeling involving identifying classes, attributes, and operations. The document provides examples and guidelines for effectively utilizing these modeling approaches in requirements analysis.
The document provides an overview of architectural design in software engineering. It defines software architecture as the structure of components, relationships between them, and properties. The key steps in architectural design are creating data design, representing structure, analyzing styles, and elaborating chosen style. It emphasizes software components and their focus. Examples of architectural styles discussed include data flow, call-and-return, data-centered, and virtual machine.
UML (Unified Modeling Language) is a standard language for specifying, visualizing, constructing and documenting software systems. It uses mainly graphical notations to express design of software projects. There are two main categories of UML diagrams - structural diagrams which focus on static elements regardless of time, and behavioral diagrams which focus on dynamic features and business processes. Common UML diagram types include class, sequence, use case, activity, state machine, component, deployment and interaction diagrams.
This document provides an overview of use case diagrams in object oriented design and analysis. It defines key components of a use case diagram including actors, use cases, the system boundary, and relationships between these elements. Actors represent people or systems that interact with the system, while use cases describe specific functions or services provided by the system. Relationships such as include, extend, and association are used to connect actors to use cases and illustrate how use cases relate to each other. The purpose of a use case diagram is to depict the functionality of a system from the user's perspective and illustrate the developer's understanding of user requirements.
UML (Unified Modeling Language) is a standardized modeling language used to visualize, specify, construct, and document software system artifacts, enabling a systematic approach to analysis, design, and implementation. This document discusses UML's history, building blocks like classes, use cases, relationships, and diagrams for modeling a system's structure and behavior statically and dynamically. The key UML diagram types covered are class, object, component, deployment, use case, sequence, collaboration, state, and activity diagrams.
This document discusses structural modeling and analysis in software engineering. It defines key concepts like objects, classes, inheritance, encapsulation, and polymorphism. It also covers modeling techniques like UML notation for class diagrams, associations between classes, aggregation, composition, constraints, and domain modeling processes. The overall summary is:
Structural modeling shows how different entities ("things") are related to each other. It involves identifying objects and classes, defining their attributes and operations, and specifying relationships like generalization, aggregation, and associations between classes. UML notation is commonly used to diagram class structures and relationships. The domain modeling process aims to develop class models that describe real-world entities and their interactions within a problem domain.
This document discusses data modeling and functional modeling techniques. [1] Data modeling is the process of creating a data model to define and analyze an organization's data requirements. It involves identifying entities, attributes, relationships, and keys. [2] Entity-relationship diagrams are used to graphically represent data models. [3] Functional modeling structures represent the functions and processes within a subject area using techniques like data flow diagrams and functional flow block diagrams.
The document discusses software architecture and the Rational Unified Process (RUP). It provides definitions of key terms:
1) Software architecture is a structural plan that describes system elements, how they fit together, and how they work together to fulfill requirements. It guides implementation and sets expectations.
2) The RUP is an iterative process focusing on requirements and design. Each iteration captures requirements, performs analysis/design, implements, and tests to evolve the system. Risks are assessed and prioritized to guide iterations.
3) The RUP uses multiple "views" including use cases, components, and interactions to represent a system from different stakeholder perspectives.
This document provides an overview of functional modeling and data flow diagrams. It discusses that functional modeling gives the process perspective of object-oriented analysis and defines the functions and data flows within a system. It then describes different types of functional models including functional flow block diagrams and data flow diagrams. It provides details on how to construct functional flow block diagrams including the use of function blocks, numbering, references, flow connections, direction and gates. It also notes some potential problems with functional modeling.
The document introduces Unified Modeling Language (UML) by describing its history, elements, and common diagram types. It explains that UML was created to model systems using object-oriented concepts and visualize software structure. The key elements are things, relationships, and diagrams. Common diagram types include use case diagrams, class diagrams, sequence diagrams, and deployment diagrams.
This document discusses modeling software architecture with the Unified Modeling Language (UML). It begins with an introduction to software architecture concepts like components, connectors, and views. It then provides an overview of UML diagrams and how they can be used to model different views of a software architecture. As an example, it analyzes the C2 Generator system and shows how UML can be used to model the logical decomposition, conceptual view, and other aspects of its architecture. The document demonstrates how UML is a useful tool for software architectural modeling and representation.
UML diagrams can be used in three ways: as a sketch, blueprint, or programming language. As a sketch, UML diagrams are informal and aim to communicate some aspect of a system to better understand it. As a blueprint, UML diagrams are more definitive and can be used by developers to follow detailed design specifications. As a programming language, UML diagrams specify a complete system so that code can be automatically generated from the diagrams.
The document discusses the software development life cycle (SDLC) which includes 8 phases: system conception, requirement gathering, system design, class design, implementation, testing, deployment, and maintenance. It states that requirement gathering focuses on what must be done without how, and involves domain and application analysis. Domain analysis emphasizes real-world objects to understand the problem domain. The implementation phase is the longest as it involves coding the requirements.
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.
An Automatic Approach to Translate Use Cases to Sequence DiagramsMohammed Misbhauddin
An automatic approach is presented to translate use case descriptions to sequence diagrams. The approach uses a metamodel for use case specifications and sequence diagrams to guide the translation process. Key steps include parsing use case steps, identifying mapping rules between meta-models, and applying a translation process. An evaluation on sample student projects found the approach produced most sequence diagram constructs from use case sentences, addressing a gap between specification and design domains. Future work includes handling compound sentences and increasing classification rates using artificial intelligence.
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
The document discusses the differences between software analysis and design. It provides details on:
- Analysis focuses on clarifying requirements and exploring the problem domain to identify concepts and analysis classes.
- Design starts with exploring the solution domain to formulate the system design using tools like class and object diagrams.
- Key outcomes of analysis include requirement specifications while design outcomes include low-level system design documentation.
- Analysis involves system analysts and end users while design involves system architects and developers.
The document discusses the unified process and use case diagrams in software development. It introduces the unified process which is an iterative and evolutionary software development methodology consisting of inception, elaboration, construction, and transition phases. The document also covers use cases, actors, use case diagrams, and how use cases influence analysis, design, implementation, project management, and testing in object-oriented software development.
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.
UML (Unified Modeling Language) is a standard language for modeling software systems. It provides notation for visualizing, specifying, constructing and documenting software artifacts. The key components of UML include classes, attributes, operations, relationships, and diagrams. Common UML diagrams are use case diagrams, class diagrams, sequence diagrams, and deployment diagrams. UML is widely used for object-oriented analysis and design. It helps model the problem domain, visualize the system design, and document implementation.
Object oriented concepts can be summarized in 3 sentences:
Objects have state, behavior, and identity. State represents the properties and values of an object, behavior is defined by the operations or methods that can be performed on an object, and identity uniquely distinguishes one object from all others. Key concepts in object orientation include abstraction, encapsulation, modularity, hierarchy, polymorphism, and life span of objects. These concepts help organize programs through the definition and use of classes and objects.
The document discusses requirements modeling and analysis modeling in software engineering. It provides information on:
1) The different types of models that can be created during requirements modeling, including requirements models, design models, scenario-based models, data models, class-based models, flow-oriented models, and behavioral models.
2) The purposes of requirements modeling, which include representing customer requirements, gaining a better understanding of the system, and providing information to help with system design and development.
3) Key principles of requirements modeling, such as representing the information, functional, and behavioral domains of the system and partitioning models in a layered/hierarchical way.
4) Specific modeling techniques like scenario-based modeling, data
The document discusses various techniques for analysis modeling in software engineering. It describes the goals of analysis modeling as providing the first technical representation of a system that is easy to understand and maintain. It then covers different types of analysis models, including flow-oriented modeling, scenario-based modeling using use cases and activity diagrams, and class-based modeling involving identifying classes, attributes, and operations. The document provides examples and guidelines for effectively utilizing these modeling approaches in requirements analysis.
The document provides an overview of architectural design in software engineering. It defines software architecture as the structure of components, relationships between them, and properties. The key steps in architectural design are creating data design, representing structure, analyzing styles, and elaborating chosen style. It emphasizes software components and their focus. Examples of architectural styles discussed include data flow, call-and-return, data-centered, and virtual machine.
UML (Unified Modeling Language) is a standard language for specifying, visualizing, constructing and documenting software systems. It uses mainly graphical notations to express design of software projects. There are two main categories of UML diagrams - structural diagrams which focus on static elements regardless of time, and behavioral diagrams which focus on dynamic features and business processes. Common UML diagram types include class, sequence, use case, activity, state machine, component, deployment and interaction diagrams.
This document provides an overview of use case diagrams in object oriented design and analysis. It defines key components of a use case diagram including actors, use cases, the system boundary, and relationships between these elements. Actors represent people or systems that interact with the system, while use cases describe specific functions or services provided by the system. Relationships such as include, extend, and association are used to connect actors to use cases and illustrate how use cases relate to each other. The purpose of a use case diagram is to depict the functionality of a system from the user's perspective and illustrate the developer's understanding of user requirements.
UML (Unified Modeling Language) is a standardized modeling language used to visualize, specify, construct, and document software system artifacts, enabling a systematic approach to analysis, design, and implementation. This document discusses UML's history, building blocks like classes, use cases, relationships, and diagrams for modeling a system's structure and behavior statically and dynamically. The key UML diagram types covered are class, object, component, deployment, use case, sequence, collaboration, state, and activity diagrams.
This document discusses structural modeling and analysis in software engineering. It defines key concepts like objects, classes, inheritance, encapsulation, and polymorphism. It also covers modeling techniques like UML notation for class diagrams, associations between classes, aggregation, composition, constraints, and domain modeling processes. The overall summary is:
Structural modeling shows how different entities ("things") are related to each other. It involves identifying objects and classes, defining their attributes and operations, and specifying relationships like generalization, aggregation, and associations between classes. UML notation is commonly used to diagram class structures and relationships. The domain modeling process aims to develop class models that describe real-world entities and their interactions within a problem domain.
This document discusses data modeling and functional modeling techniques. [1] Data modeling is the process of creating a data model to define and analyze an organization's data requirements. It involves identifying entities, attributes, relationships, and keys. [2] Entity-relationship diagrams are used to graphically represent data models. [3] Functional modeling structures represent the functions and processes within a subject area using techniques like data flow diagrams and functional flow block diagrams.
The document discusses software architecture and the Rational Unified Process (RUP). It provides definitions of key terms:
1) Software architecture is a structural plan that describes system elements, how they fit together, and how they work together to fulfill requirements. It guides implementation and sets expectations.
2) The RUP is an iterative process focusing on requirements and design. Each iteration captures requirements, performs analysis/design, implements, and tests to evolve the system. Risks are assessed and prioritized to guide iterations.
3) The RUP uses multiple "views" including use cases, components, and interactions to represent a system from different stakeholder perspectives.
This document provides an overview of functional modeling and data flow diagrams. It discusses that functional modeling gives the process perspective of object-oriented analysis and defines the functions and data flows within a system. It then describes different types of functional models including functional flow block diagrams and data flow diagrams. It provides details on how to construct functional flow block diagrams including the use of function blocks, numbering, references, flow connections, direction and gates. It also notes some potential problems with functional modeling.
The document introduces Unified Modeling Language (UML) by describing its history, elements, and common diagram types. It explains that UML was created to model systems using object-oriented concepts and visualize software structure. The key elements are things, relationships, and diagrams. Common diagram types include use case diagrams, class diagrams, sequence diagrams, and deployment diagrams.
This document discusses modeling software architecture with the Unified Modeling Language (UML). It begins with an introduction to software architecture concepts like components, connectors, and views. It then provides an overview of UML diagrams and how they can be used to model different views of a software architecture. As an example, it analyzes the C2 Generator system and shows how UML can be used to model the logical decomposition, conceptual view, and other aspects of its architecture. The document demonstrates how UML is a useful tool for software architectural modeling and representation.
UML diagrams can be used in three ways: as a sketch, blueprint, or programming language. As a sketch, UML diagrams are informal and aim to communicate some aspect of a system to better understand it. As a blueprint, UML diagrams are more definitive and can be used by developers to follow detailed design specifications. As a programming language, UML diagrams specify a complete system so that code can be automatically generated from the diagrams.
The document discusses the software development life cycle (SDLC) which includes 8 phases: system conception, requirement gathering, system design, class design, implementation, testing, deployment, and maintenance. It states that requirement gathering focuses on what must be done without how, and involves domain and application analysis. Domain analysis emphasizes real-world objects to understand the problem domain. The implementation phase is the longest as it involves coding the requirements.
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.
An Automatic Approach to Translate Use Cases to Sequence DiagramsMohammed Misbhauddin
An automatic approach is presented to translate use case descriptions to sequence diagrams. The approach uses a metamodel for use case specifications and sequence diagrams to guide the translation process. Key steps include parsing use case steps, identifying mapping rules between meta-models, and applying a translation process. An evaluation on sample student projects found the approach produced most sequence diagram constructs from use case sentences, addressing a gap between specification and design domains. Future work includes handling compound sentences and increasing classification rates using artificial intelligence.
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
The document discusses the differences between software analysis and design. It provides details on:
- Analysis focuses on clarifying requirements and exploring the problem domain to identify concepts and analysis classes.
- Design starts with exploring the solution domain to formulate the system design using tools like class and object diagrams.
- Key outcomes of analysis include requirement specifications while design outcomes include low-level system design documentation.
- Analysis involves system analysts and end users while design involves system architects and developers.
The document discusses the unified process and use case diagrams in software development. It introduces the unified process which is an iterative and evolutionary software development methodology consisting of inception, elaboration, construction, and transition phases. The document also covers use cases, actors, use case diagrams, and how use cases influence analysis, design, implementation, project management, and testing in object-oriented software development.
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.
UML (Unified Modeling Language) is a standard language for modeling software systems. It provides notation for visualizing, specifying, constructing and documenting software artifacts. The key components of UML include classes, attributes, operations, relationships, and diagrams. Common UML diagrams are use case diagrams, class diagrams, sequence diagrams, and deployment diagrams. UML is widely used for object-oriented analysis and design. It helps model the problem domain, visualize the system design, and document implementation.
UML (Unified Modeling Language) is a standard modeling language used to visualize, specify, construct, and document software systems. It includes various diagram types to show different views of a system, such as use case diagrams for requirements, class diagrams for structure, and sequence diagrams for behavior. UML aims to be independent of programming languages and development processes. It has become widely used for object-oriented analysis and design.
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
UML (Unified Modeling Language) is a standard modeling language used to visualize, specify, construct, and document software systems. It uses graphical notation to depict systems from initial design through detailed design. Common UML diagram types include use case diagrams, class diagrams, sequence diagrams, activity diagrams, and state machine diagrams. UML provides a standard way to communicate designs across development teams and is supported by many modeling tools.
The document discusses Unified Modeling Language (UML) diagrams. It provides information on static and dynamic UML models and describes common UML diagram types including use case diagrams, class diagrams, sequence diagrams, collaboration diagrams, statechart diagrams, activity diagrams, component diagrams and deployment diagrams. The key purpose of UML modeling is communication and simplification of complex systems through visual representation.
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.
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.
UML (Unified Modeling Language) is a standard modeling language used to visualize, specify, construct, and document software systems. It includes graphical notation techniques to create models of object-oriented software systems. Some key UML diagram types are use case diagrams, which depict interactions between external actors and the system; class diagrams, which show system classes and their relationships; and sequence diagrams, which illustrate object interactions over time. UML aims to improve understanding between customers, developers, and other stakeholders and supports the software development lifecycle.
The document discusses Unified Modeling Language (UML) which is a standard language used to specify, visualize, construct and document software systems. UML helps visualize a system, specify its structure and behavior, provide a template for construction and means of documentation. It includes various diagram types like class, sequence, use case diagrams to model different aspects of a system.
UML (Unified Modeling Language) is a standard modeling language used to visualize, specify, construct, and document software systems. It includes graphical notation techniques to create models of object-oriented software systems. Some key UML diagram types are use case diagrams, class diagrams, sequence diagrams, and state machine diagrams. UML is not a process but a modeling language that can be used throughout the software development lifecycle.
Presentation Use Case Diagram and Use Case Specification.pptxazida3
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 the Unified Modeling Language (UML) and use case modeling. UML was developed to provide modeling languages for software design including use case diagrams, class diagrams, and other diagrams. It describes the typical phases of system development like requirements analysis, design, implementation, and testing. It then focuses on use case modeling, explaining what a use case is, how to identify actors and use cases, and how to describe use cases. Examples of use case diagrams are provided for different systems like an ATM machine and counseling.
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.
Workshop on Basics of Software Engineering (DFD, UML and Project Culture)Dr Sukhpal Singh Gill
Three days workshop on Basics of Software Engineering at Thapar University, Patiala on 7th-9th, 2013. Workshop on Basics of Software Engineering (DFD, UML and Project Culture)
This document provides an overview of object-oriented software design using the Unified Modeling Language (UML). It discusses key concepts in object-oriented design like classes, methods, inheritance, and relationships. It also describes UML diagrams for modeling different aspects of a system, including use case diagrams for capturing user requirements, class diagrams for modeling the structural design, and how UML was developed through the merging of earlier object-oriented modeling notations. The document aims to introduce software engineering principles and object-oriented modeling techniques using UML.
The document discusses use case diagrams and modeling. It defines key concepts like use cases, actors, and their relationships. Use cases specify system functions from the user's perspective, while actors represent roles that interact with the system. Use case diagrams visualize system behavior, help capture requirements, and serve as a basis for testing and communication between developers and users.
Software Engineering Tools and Practices.pdfMeagGhn
This document discusses software engineering practices and tools, including the software crisis and issues like increasing complexity, poor quality, high costs and delays. It introduces Unified Modeling Language (UML) as a standard way to visually model software systems using diagrams. It describes different types of UML models including structural, behavioral and architectural modeling. It also discusses concepts like the software development life cycle, configuration management, revision control systems and how to create UML diagrams like use case diagrams and sequence diagrams.
Welcome to my series of articles on Unified Modeling Language. This is "Session 1 – Introduction to UML" of the series. Please view my other documents where I have covered each UML diagram with examples
Object diagrams represent a snapshot of a system at a particular moment, showing the concrete instances of classes and their relationships. They capture the static view of a system to show object behaviors and relationships from a practical perspective. Unlike class diagrams which show abstract representations, object diagrams depict real-world objects and their unlimited possible instances. They are used for forward and reverse engineering, modeling object relationships and interactions, and understanding system behavior.
Sequence diagrams show the interactions between objects over time by depicting object lifelines and messages exchanged. They emphasize the time ordering of messages. To create a sequence diagram, identify participating objects and messages, lay out object lifelines across the top, and draw messages between lifelines from top to bottom based on timing. Activation boxes on lifelines indicate when objects are active. Sequence diagrams help document and understand the logical flow of a system.
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.
This document discusses software quality and metrics. It defines software quality as conformance to requirements, standards, and implicit expectations. It outlines ISO 9126 quality factors like functionality, reliability, usability, and maintainability. It describes five views of quality: transcendental, user, manufacturing, product, and value-based. It also discusses types of metrics like product, process, and project metrics. Product metrics measure characteristics like size, complexity, and quality level. The document provides guidelines for developing, collecting, analyzing, and interpreting software metrics.
Unit 7 performing user interface designPreeti Mishra
The document discusses user interface design principles and models. It provides three key principles for user interface design:
1. Place users in control of the interface and allow for flexible, interruptible, and customizable interaction.
2. Reduce users' memory load by minimizing what they need to remember, establishing defaults, and progressively disclosing information.
3. Make the interface consistent across screens, applications, and interaction models to maintain user expectations.
It also describes four models involved in interface design: the user profile model, design model, implementation model, and user's mental model. The role of designers is to reconcile differences across these models.
Unit 8 discusses software testing concepts including definitions of testing, who performs testing, test characteristics, levels of testing, and testing approaches. Unit testing focuses on individual program units while integration testing combines units. System testing evaluates a complete integrated system. Testing strategies integrate testing into a planned series of steps from requirements to deployment. Verification ensures correct development while validation confirms the product meets user needs.
This document discusses requirements analysis and design. It covers the types and characteristics of requirements, as well as the tasks involved in requirements engineering including inception, elicitation, elaboration, negotiation, specification, validation, and management. It also discusses problems that commonly occur in requirements practices and solutions through proper requirements engineering. Additionally, it outlines goals and elements of analysis modeling, including flow-oriented, scenario-based, class-based, and behavioral modeling. Finally, it discusses the purpose and tasks of design engineering in translating requirements models into design models.
Design process interaction design basicsPreeti Mishra
This document provides an introduction to interaction design basics and terms. It discusses that interaction design involves creating technology-based interventions to achieve goals within constraints. The design process has several stages and is iterative. Interaction design starts with understanding users through methods like talking to and observing them. Scenarios are rich stories used throughout design to illustrate user interactions. Basic terms in interaction design include goals, constraints, trade-offs, and the design process. Usability and user-centered design are also discussed.
The document provides an overview of design process and factors that affect user experience in interface design. It discusses various principles and heuristics to support usability, including learnability, flexibility, and robustness. The document outlines principles that affect these factors, such as predictability, consistency and dialog initiative. It also discusses guidelines for improving usability through user testing and iterative design. The document emphasizes the importance of usability and provides several heuristics and guidelines to measure and improve usability in interface design.
Design process evaluating interactive_designsPreeti Mishra
The document discusses various methods for evaluating interactive systems, including expert analysis methods like heuristic evaluation and cognitive walkthrough, as well as user-based evaluation techniques like observational methods, query techniques, and physiological monitoring. It provides details on the process for each method and considerations for when each may be most appropriate. Evaluation aims to determine a system's usability, identify design issues, compare alternatives, and observe user effects. The criteria discussed include expert analysis, user-based, and model-based approaches.
Foundations understanding users and interactionsPreeti Mishra
This document discusses qualitative user research methods. It explains that qualitative research helps understand user behavior, which is too complex to understand solely through quantitative data. Qualitative research methods include interviews, observation, and persona creation. Personas are fictional user archetypes created from interview data to represent different types of users. They are useful for product design by providing empathy for users and guiding decisions. The document provides details on creating personas and using scenarios to represent how personas would interact with a product.
This document provides an introduction to human-computer interaction (HCI). It defines HCI as a discipline concerned with studying, designing, building, and implementing interactive computing systems for human use, with a focus on usability. The document outlines various perspectives in HCI including sociology, anthropology, ergonomics, psychology, and linguistics. It also defines HCI and lists 8 guidelines for creating good HCI, such as consistency, informative feedback, and reducing memory load. The importance of good interfaces is discussed, noting they can make or break a product's acceptance. Finally, some principles and theories of user-centered design are introduced.
The document provides an overview of system development methodologies, with a focus on structured analysis and design versus object-oriented analysis and design. It discusses the analysis, design, and implementation phases of an object-oriented systems development life cycle. In the analysis phase, it describes how use case diagrams and class diagrams are used to model object-oriented analysis using the Unified Modeling Language. It also provides guidance on identifying domain classes from problem statements by looking for noun phrases and applying subject matter expertise.
Software testing techniques document discusses various software testing methods like unit testing, integration testing, system testing, white box testing, black box testing, performance testing, stress testing, and scalability testing. It provides definitions and characteristics of each method. Some key points made in the document include that unit testing tests individual classes, integration testing tests class interactions, system testing validates functionality, and performance testing evaluates how the system performs under varying loads.
Object modeling involves identifying important objects (classes) within a system and defining their attributes, operations, and relationships. During object modeling, classes are identified based on system requirements and domain concepts. Key activities include class identification, defining class attributes and methods, and determining associations between classes. Object modeling results in a visual representation of classes and their relationships in class and other diagrams.
This document provides an introduction to object-oriented concepts and methodologies. It defines key OO terms like abstraction, encapsulation, polymorphism, and more. It also discusses object-oriented modeling techniques and popular object-oriented methodologies like Booch, RDD, OMT, and OOSE. The document aims to equip readers with an understanding of fundamental OO principles and how they are applied in analysis, design, and implementation of object-oriented systems.
This document provides an overview of software processes and the Capability Maturity Model Integration (CMMI). It defines what a software process is, characteristics of processes, and that different project types require different processes. It then describes the key elements of the CMMI, including its five maturity levels from Initial to Optimizing. Each level is defined in one sentence or less. It also briefly outlines some of the key process areas assessed at levels 2 through 5.
Unit 1 importance ofsoftengg_b.tech iii yearPreeti Mishra
Here are some key points from Unit 1:
- Software is computer programs, data structures, and documentation. Software engineering is the systematic development and maintenance of software.
- A software process provides a framework for development activities like communication, planning, modeling, construction and deployment. It establishes quality practices.
- Legacy software supports core functions but is outdated, poorly designed and documented. It is costly to replace but also to maintain.
- Common software myths include thinking requirements can change freely, documentation is unnecessary, or that quality is only important after coding. These undermine good practices.
- A process framework provides structure while methods and tools support specific technical tasks. Processes must balance control and flexibility for different projects.
Unit 1 introduction tosoftengg_mba tech ii yearPreeti Mishra
This document provides an introduction to software engineering. It defines software and discusses different categories of software products. It explains that software engineering is concerned with developing software using systematic and disciplined approaches. The document outlines important attributes of good software such as maintainability, dependability, efficiency and acceptability. It also discusses challenges with legacy software systems and reasons for evolving legacy systems. Finally, it covers key tasks for software project planning such as establishing scope, feasibility analysis, risk analysis, resource estimation, and developing a project schedule.
A high-Speed Communication System is based on the Design of a Bi-NoC Router, ...DharmaBanothu
The Network on Chip (NoC) has emerged as an effective
solution for intercommunication infrastructure within System on
Chip (SoC) designs, overcoming the limitations of traditional
methods that face significant bottlenecks. However, the complexity
of NoC design presents numerous challenges related to
performance metrics such as scalability, latency, power
consumption, and signal integrity. This project addresses the
issues within the router's memory unit and proposes an enhanced
memory structure. To achieve efficient data transfer, FIFO buffers
are implemented in distributed RAM and virtual channels for
FPGA-based NoC. The project introduces advanced FIFO-based
memory units within the NoC router, assessing their performance
in a Bi-directional NoC (Bi-NoC) configuration. The primary
objective is to reduce the router's workload while enhancing the
FIFO internal structure. To further improve data transfer speed,
a Bi-NoC with a self-configurable intercommunication channel is
suggested. Simulation and synthesis results demonstrate
guaranteed throughput, predictable latency, and equitable
network access, showing significant improvement over previous
designs
Sri Guru Hargobind Ji - Bandi Chor Guru.pdfBalvir Singh
Sri Guru Hargobind Ji (19 June 1595 - 3 March 1644) is revered as the Sixth Nanak.
• On 25 May 1606 Guru Arjan nominated his son Sri Hargobind Ji as his successor. Shortly
afterwards, Guru Arjan was arrested, tortured and killed by order of the Mogul Emperor
Jahangir.
• Guru Hargobind's succession ceremony took place on 24 June 1606. He was barely
eleven years old when he became 6th Guru.
• As ordered by Guru Arjan Dev Ji, he put on two swords, one indicated his spiritual
authority (PIRI) and the other, his temporal authority (MIRI). He thus for the first time
initiated military tradition in the Sikh faith to resist religious persecution, protect
people’s freedom and independence to practice religion by choice. He transformed
Sikhs to be Saints and Soldier.
• He had a long tenure as Guru, lasting 37 years, 9 months and 3 days
Online train ticket booking system project.pdfKamal Acharya
Rail transport is one of the important modes of transport in India. Now a days we
see that there are railways that are present for the long as well as short distance
travelling which makes the life of the people easier. When compared to other
means of transport, a railway is the cheapest means of transport. The maintenance
of the railway database also plays a major role in the smooth running of this
system. The Online Train Ticket Management System will help in reserving the
tickets of the railways to travel from a particular source to the destination.
This is an overview of my current metallic design and engineering knowledge base built up over my professional career and two MSc degrees : - MSc in Advanced Manufacturing Technology University of Portsmouth graduated 1st May 1998, and MSc in Aircraft Engineering Cranfield University graduated 8th June 2007.
2. Object Modelling Using
UML
UML is a modelling language.
Not a system design or development
methodology
Used to document object-oriented analysis and
design results.
Independent of any specific design methodology.
3. UML Origin
OOD in late 1980s and early 1990s:
Different software development houses were
using different notations.
Methodologies were tied to notations.
UML developed in early 1990s:
To standardize the large number of object-
oriented modelling notations that existed.
4. UML Lineology
Based Principally on:
OMT [Rumbaugh 1991]
Booch’s methodology[Booch 1991]
OOSE [Jacobson 1992]
Odell’s methodology[Odell 1992]
Shlaer and Mellor [Shlaer 1992]
6. UML as A Standard
Adopted by Object Management Group (OMG)
in 1997.
OMG is an association of industries
Promotes consensus notations and
techniques
UML also being used outside software
development area:
Example car manufacturing
8. Developments to UML
• UML continues to
develop:
– Refinements
– Making it applicable
to new contexts
UML 1.X
UML 1.0
UML 2.0
Application
to
embedded
systems
1997
2003
9. Why are UML Models
Required?
Modelling is an abstraction mechanism:
Capture only important aspects and ignores the
rest.
Different models result when different aspects are
ignored.
An effective mechanism to handle complexity.
UML is a graphical modelling tool
Easy to understand and construct
11. Why do we model
• Models help us to visualize a system as it is or as we
want it to be.
• Models permit us to specify the structure or behavior of
a system.
• Models give us a template that guides us in
constructing a system.
• Models document the decisions we have made.
12. UML Diagrams
Nine diagrams in UML1.x :
Used to capture 5 different views of a system.
Views:
Provide different perspectives of a software
system.
Diagrams can be refined to get the actual
implementation of a system.
13. UML Model Views
Views of a system:
User’s view
Structural view
Behavioral view
Implementation view
Environmental view
14. UML Diagrams
User’s View
- Use Case
Diagram
Structural View
- Class Diagram
- Object Diagram
Implementation View
- Component Diagram
Environmental View
- Deployment Diagram
Behavioural View
- Sequence Diagram
- Collaboration Diagram
- State-chart Diagram
- Activity Diagram
Diagrams and views in UML
16. UML 2.0 Diagrams
UML 2.0
Diagram
Behavior
Diagram
Structure
Diagram
Class
Diagram
Composite
Structure Diagram
Object
Diagram
Activity
Diagram
Use Case
Diagram
State Machine
Diagram
Interaction
Diagram
Component
Diagram
Deployment
Diagram
Package
Diagram
Sequence
Diagram
Communication
Diagram
Interaction
Overview
Diagram
Timing
Diagram
17. Structural Diagrams
• Class Diagram
– set of classes and their relationships.
• Object Diagram
– set of objects (class instances) and their relationships
• Component Diagram
– logical groupings of elements and their relationships
• Deployment Diagram
– set of computational resources (nodes) that host each
component.
18. Behavioral Diagrams
• Use Case Diagram
– high-level behaviors of the system, user goals, external entities:
actors
• Sequence Diagram
– focus on time ordering of messages
• Collaboration Diagram
– focus on structural organization of objects and messages
• State Chart Diagram
– event driven state changes of system
• Activity Diagram
– flow of control between activities
19. Quotable Quotes on Using UML
• “UML is a large and growing beast, but you don’t
need all of it in every problem you solve…”
– Martin Fowler
• The Unified Modeling Language is described as a language for
“specifying, visualizing, constructing, and documenting the artifacts of
software systems” and for business modeling (OMG UML V1.x
documents). The UML reflects some of the best experiences in object-
oriented modeling, thus it has the potential to become a widely-used
standard object-oriented modeling language.
• Robert France, Bernhard Rumpe
20. Are All Views Required for
Developing A Typical System?
NO
For a simple system:
Use case diagram, class diagram and one of the
interaction diagrams only.
State chart diagram:
when class has significant states.
When states are only one or two, state chart model
becomes trivial
Deployment diagram:
In case several hardware components used to
develop the system.
21. • In groups:
– History of: OMT, OOSe, Odell’s Methodolgy
Shlaer & Mellor, Limitations and
advantages of UML
Everyone individually:
• Current version of uml
• Tools used for UML by various vendors
23. Key Diagrams in UML
Requirements
System
Structure
System
Behaviour
Use Case Diagrams
Interaction Diagrams
Activity Diagrams
State Charts
Class Diagrams
Collaboration Diagram
25. Use Case Model
• Consists of a set of “use cases”
• It is the central model:
– Other models must conform to this model
– Not really an object-oriented model
– A functional model of the system
26. A Use Case
• A way in which a system can be used by the
users to achieve specific goals
• Corresponds to a high-level requirement.
• Defines external behavior without revealing
internal structure of system
• Set of related scenarios tied together by a
common goal.
27. Use Cases Cont…
• Normally, use cases are independent
of each other
• Implicit dependencies may exist
• Example: In Library Automation
System, renew-book and reserve-book
are independent use cases.
–But in actual implementation of renew-
book--- A check is made to see if any book
has been reserved using reserve-book.
28. Example Use Cases
–Library information system
•issue-book
•query-book
•return-book
•create-member
•add-book, etc.
29. Representation of Use Cases
• Represented in a use case diagram
• A use case is represented by an ellipse
• System boundary is represented by a
rectangle
• Users are represented by
stick person icons (actor)
• Communication relationship between
actor and use case by a line
• External system by a stereotype
Tic-tac-toe game
Play Move
30. What is a Connection?
• A connection is an association
between an actor and a use case.
• Depicts a usage relationship
• Connection does not indicate data
flow
Tic-tac-toe game
Play Move
31. Effective Use Case
Modelling
• Use cases should be named and
organized from the perspective of the
actor.
• Use cases should start off simple and
at as much high view as possible.
– Can be refined and detailed further.
• Use case diagrams represent
functionality:
– Should focus on the "what" and not the
32. An Example Use Case
Diagram
Use case model
Tic-tac-toe game
Play Move
Player
33. Relationships between Use Cases
and Actors
• Actors may be connected to a
use case by association relation:
–Indicating that the actor and the
use case communicate with one
another.
update
grades
faculty
34. Another Example Use Case
Diagram
Rent
Videos
. . .
Video Store
Information System
<<external
system>>
Credit Authorization
Service
Clerk
35. Yet Another Use Case Example
Check
Status
Place
Order
Fill Orders
Establish
credit
Customer
Salesperso
n
Shipping
Clerk
Supervisor
Telephone Catalog
36. Why Develop A Use Case Diagram?
• Serves as requirements specification
• How are actor identification useful in
software development?
–Identifies different categories of users:
• Helps in implementing appropriate
interfaces for each category of users.
–Helps in preparing appropriate
documents (e.g. user’s manual).
37. Use Case Description: Change
Flight
Actors: traveler
Preconditions:
Traveler has logged on to the system and selected
‘change flight itinerary’ option
Basic course
1. System retrieves traveler’s account and flight itinerary
from client account database
2. System asks traveler to select itinerary segment she
wants to change; traveler selects itinerary segment.
3. System asks traveler for new departure and
destination information; traveler provides information.
4. If flights are available then
5. …
6. System displays transaction summary.
Alternative courses
4. If no flights are available then …
38. ATM Money Withdraw Example
• Actors: Customer
• Pre Condition:
– The ATM must be in a state ready to accept transactions
– The ATM must have at least some cash on hand that it
can dispense
– The ATM must have enough paper to print a receipt for
at least one transaction
• Post Condition:
– The current amount of cash in the user account is the
amount before the withdraw minus the withdraw
amount
– A receipt was printed on the withdraw amount
– The withdraw transaction was audit in the System log
file
39. ATM Money Withdraw Mainline
Scenario
Actor Actions System Actions
1. Begins when a Customer
arrives at ATM
2. Customer inserts a Credit
card into ATM
3. System verifies the customer
ID and status
5. Customer chooses
“Withdraw” operation
4. System asks for an operation
type
7. Customer enters the cash
amount
6. System asks for the withdraw
amount
8. System checks if withdraw
amount is legal
9. System dispenses the cash
10. System deduces the
withdraw amount from account
11. System prints a receipt
13. Customer takes the cash
and the receipt
12. System ejects the cash card
40. ATM Money Withdraw (cont.)
• Alternative flow of events:
– Step 3: Customer authorization failed. Display an
error message, cancel the transaction and eject the
card.
– Step 8: Customer has insufficient funds in its
account. Display an error message, and go to step 6.
– Step 8: Customer exceeds its legal amount. Display
an error message, and go to step 6.
• Exceptional flow of events:
– Power failure in the process of the transaction before
step 9, cancel the transaction and eject the card
41. Identification of Use Cases
1. Actor-based:
- Identify the actors related to a system or
organization.
- For each actor, identify the processes they
initiate or participate in.
2. Event-based
- Identify the external events that the
system must respond to.
- Relate the events to actors and use cases.
42. Factoring Use Cases
• Two main reasons for factoring:
–Complex use cases need to be factored
into simpler use cases
–To represent common behavior across
different use cases
• Three ways of factoring:
–Generalization
–Include
–Extend
43. Generalization
• The child use case inherits the
behavior of the parent use
case.
–The child may add to or override
the behavior of its parent. parent
child
45. Factoring Use Cases Using
Generalization
Pay membership fee
Pay through library pay cardPay through credit card
46. Factoring Use Cases Using
Include
Base use case
Common
use case
<<include>>
Base use case 2
Common use case 3Common use case 2Common use case 1
Base use case 1
<<include>>
<<include>>
<<include>>
<<include>>
47. Example of Factoring Use Cases
Using Includes
Issue Book
Check Reservation
Renew Book
<<include>>
<<include>>
50. Extension Point
• The base use case can incorporate
another use case:
– at certain points, called extension
points.
• Note the direction of the arrow
Perform
Sale
After
checkout
Gift wrap
Product
<<extend>>
Product is a gift
51. Use Case Relationships
Place Order
Supply
Customer
Data
Order
Produc
t Arrange
Paymen
t
Request
Catalog
<<include>
>
<<include>
> <<include>
>
<<extend>
>
The salesperson asks for
catalog
Sales
Person
Cash
Paymen
t
Credit
Paymen
t
52. Hierarchical Organization of
Use Cases
External usersuse case 1
use case 2
use case 3
use case 3.1
use case 3. 2
use case 3.3
use case 1
use case 2
use case 3
Subsystems
Methods
53. Use Case Relationships
Place Order
Extension point
Additional requests:
After creation of the
order
Supply
Customer
Data
Order
Produc
t Arrange
Paymen
t
Request
Catalog
<<include>
>
<<include>
>
<<include>
>
<<extend>
>
The salesperson asks for
catalog
Sales
Person
59. Triggers
• What starts use-case?
• Examples:
–Customer initiates a claim report by
clicking a button on a web page
–Customer inserts ATM card
–System clock is 10:00
–etc.
60. Preconditions
• What the system needs to be true
before running the use-case.
• Examples
–The use has logged on
–Requested Book is issued out
–User account has been created
–The membership has expired
61. Post-Conditions
• A post-condition is the outcome of a use-case.
• Examples
– Money was transferred to the user account
– User is logged in
– The file is saved to the hard-disk
• Minimal guarantee
– The things that a system can promise, holding even when
the use case execution ended in failure
– Examples: Money is not transferred unless authorization is
granted by the user
• Success guarantee
– What happens after a successful conclusion of the use-case.
– Example: Transaction logged; Money is transferred
62. Success Scenario
• The success scenario is the main story-
line of the use-case
– Under the assumption that everything is
okay, no errors or problems occur
• It is composed of a sequence of action
steps
1. Administrator enters course name, code and description
2. System validates course code
3. System adds the course to the db and shows a confirmation
message
Interaction
step
Validation
Step
Internal
Change Step
Interaction
Step
63. Guidelines for Effective Writing
• Use simple sentence
• Do not have both system and
actor doing something in a
single step
– Bad: “Get the amount from the
user and give him the receipt.”
• Any step should lead to some
progress
– Bad: “User clicks a key”
System Actor
Actor asks for money
System asks for amount
Actor gives the amount
System produce the money
68. Online HR System: Use Case
Relationships
Employee
Update
Benefits
Extension points
benefit options :
After required
enrollments
Update
Medical Plan
Update
Dental Plan Update
Insurance
Plan
Elect
Reimbursement
for health care
Elect stock
purchase
<<include>
>
<<include>
>
<<include>
>
<<extend>>
<<extend>>
Employee requests
reimbursement options
Employee requests stock
purchase options
Extension
condition
Extension point
name and location
69. Online HR System: Update Benefits Use Case
Actors: employee, employee account db, healthcare plan
system, insurance plan system
Preconditions:
Employee has logged on to the system and selected
‘update benefits’ option
Basic course
System retrieves employee account from employee
account db
System asks employee to select medical plan type;
include Update Medical Plan.
System asks employee to select dental plan type; include
Update Dental Plan.
…
Alternative courses
If health plan is not available in the employee’s area the
employee is informed and asked to select another plan...
70. Style Notes (Ambler,
2005)
• Use case name should begin with a verb.
• While use cases do not imply timing:
– Order cases from top to bottom to imply timing -- it improves
readability.
• The primary actors should appear in the left.
• Actors are associated with one or more use cases.
• Do not use arrows on the actor-use case relationship.
• To initiate scheduled events include an actor called “time”
• Do not show actors interacting with each other.
• <<include>> should rarely nest more than 2 deep.
71. Exercise 1: Use Case Model for Course Management Software
• At the beginning of each semester,
– Professors shall register the courses that they are going
to teach.
• A student can select up to four-course offerings.
– During registration a students can request a course
catalogue showing course offerings for the semester.
– Information about each course such as professor,
department and prerequisites would be displayed.
– The registration system sends information to the billing
system so the students can be billed for the semester.
• For each semester, there is a period of time during
which dropping of courses is permitted.
• Professors must be able to access the system to see
which students signed up for each of their course
offerings.
73. Exercise 2: Home Assignment System
• HAS will be used by the instructor to:
– Distribute the homework assignments,
– Review the students’ solutions,
– Distribute suggested solution,
– Assign grade to each assignment.
• Students can:
– Download assignments
– Submit assignment solutions
• System:
– Automatically reminds the students a day before an
assignment is due.
74. HAS Use Case Diagram
Distribute
Assignments
Post
Solutions
Distribute
GradeInstructor
Remind
Student
Calendar
<<Extends>>
Get
Assignment
Submit
Assignment
Get
Solution
Get Grade
Student
75. Alternate HACS Use Case Diagram
Distribute
Assignments
Post
Solutions
Distribute
Grade
Instructor
Remind
Student
Calendar
Submit
Assignment
Student