The document provides an overview of advanced state modeling and interaction modeling techniques in UML. It discusses nested state diagrams and concurrent state diagrams for controlling complexity in state diagrams. It also covers activity models, use case models, and sequence models for interaction modeling. The relationships between class models, state models, and interaction models are also briefly described.
Unit 2(advanced class modeling & state diagram)Manoj Reddy
This document discusses state modeling concepts in UML including states, transitions, events, and state diagrams. It provides examples of state diagrams for a phone and traffic lights. States represent conditions an object can be in, such as idle or running. Transitions are changes between states triggered by events like receiving a call. State diagrams visually depict the flow between states.
The document discusses state modeling and state diagrams. It defines states as representations of intervals of time that describe an object's behavioral condition. Events trigger transitions between states. A state diagram uses a graph to represent an object's states and the transitions between them caused by events. It specifies the object's response to input events over time. The document provides examples of how to notationally represent states, transitions, events, and other elements in a state diagram.
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.
UML (Unified Modeling Language) is a standard modeling language used to specify, visualize, and document software systems. It uses graphical notations to model structural and behavioral aspects of a system. Common UML diagram types include use case diagrams, class diagrams, sequence diagrams, and state diagrams. Use case diagrams model user interactions, class diagrams show system entities and relationships, sequence diagrams visualize object interactions over time, and state diagrams depict object states and transitions. UML aims to simplify the complex process of software design through standardized modeling.
Static modeling represents the static elements of software such as classes, objects, and interfaces and their relationships. It includes class diagrams and object diagrams. Class diagrams show classes, attributes, and relationships between classes. Object diagrams show instances of classes and their properties. Dynamic modeling represents the behavior and interactions of static elements through interaction diagrams like sequence diagrams and communication diagrams, as well as activity diagrams.
UML state machine diagrams depict the states an object can be in and the transitions between those states. States are represented by rounded rectangles with transition lines connecting them. Initial states have filled circles while final states have empty circles with dots. Transitions can have triggers, guards, and effects associated with them. Self-transitions allow an object to return to the same state. Superstates group common transitions to simplify diagrams. Compound states include submachine diagrams. Pseudo-states like choices and junctions control transitions. Concurrent regions divide states into concurrently executing parts using fork and join pseudo-states.
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.
Unit 2(advanced class modeling & state diagram)Manoj Reddy
This document discusses state modeling concepts in UML including states, transitions, events, and state diagrams. It provides examples of state diagrams for a phone and traffic lights. States represent conditions an object can be in, such as idle or running. Transitions are changes between states triggered by events like receiving a call. State diagrams visually depict the flow between states.
The document discusses state modeling and state diagrams. It defines states as representations of intervals of time that describe an object's behavioral condition. Events trigger transitions between states. A state diagram uses a graph to represent an object's states and the transitions between them caused by events. It specifies the object's response to input events over time. The document provides examples of how to notationally represent states, transitions, events, and other elements in a state diagram.
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.
UML (Unified Modeling Language) is a standard modeling language used to specify, visualize, and document software systems. It uses graphical notations to model structural and behavioral aspects of a system. Common UML diagram types include use case diagrams, class diagrams, sequence diagrams, and state diagrams. Use case diagrams model user interactions, class diagrams show system entities and relationships, sequence diagrams visualize object interactions over time, and state diagrams depict object states and transitions. UML aims to simplify the complex process of software design through standardized modeling.
Static modeling represents the static elements of software such as classes, objects, and interfaces and their relationships. It includes class diagrams and object diagrams. Class diagrams show classes, attributes, and relationships between classes. Object diagrams show instances of classes and their properties. Dynamic modeling represents the behavior and interactions of static elements through interaction diagrams like sequence diagrams and communication diagrams, as well as activity diagrams.
UML state machine diagrams depict the states an object can be in and the transitions between those states. States are represented by rounded rectangles with transition lines connecting them. Initial states have filled circles while final states have empty circles with dots. Transitions can have triggers, guards, and effects associated with them. Self-transitions allow an object to return to the same state. Superstates group common transitions to simplify diagrams. Compound states include submachine diagrams. Pseudo-states like choices and junctions control transitions. Concurrent regions divide states into concurrently executing parts using fork and join pseudo-states.
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.
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.
Object modeling represents the static structure of objects and their relationships using object diagrams. An object diagram shows instances of classes, their attributes and values, and relationships between objects through links representing associations, generalizations, or aggregations. Object diagrams are useful for understanding object behavior and relationships in a system, as well as its static view and for forward and reverse engineering.
Unit 1( modelling concepts & class modeling)Manoj Reddy
The document discusses object-oriented modeling and design. It covers key concepts like classes, objects, inheritance, polymorphism, and encapsulation. It also discusses the Unified Modeling Language (UML) which provides standard notation for visualizing, specifying, constructing, and documenting models. The document is a lecture on object-oriented concepts for students to understand modeling using classes, objects, and relationships.
The document discusses the Unified Modeling Language (UML). UML is a general-purpose modeling language used to specify, visualize, construct, and document software systems. It captures decisions and understanding about systems that must be constructed. The goals of UML included developing a modeling language that could be used across different domains and development methods. UML has three main building blocks - things, relationships, and diagrams. Things represent elements in a model like classes, components, and use cases. Relationships connect things and show dependencies, generalizations, and associations. Diagrams provide different views of UML models, including structural diagrams and behavioral diagrams.
State diagrams describe the behavior of objects by modeling their states and transitions between states based on events. Key elements of state diagrams include states, transitions, events, and actions. States represent conditions of an object, transitions are triggered by events, and actions occur on state entry/exit or during transitions. Together these elements specify the dynamic behavior of objects in response to events.
This document discusses nested state diagrams and interaction modeling techniques. It addresses:
1. The use of submachine states and composite states to model nested states within a state diagram.
2. Interaction modeling approaches including use cases, sequence diagrams, and activity diagrams.
3. Guidelines for developing use cases, sequence diagrams, and activity diagrams to fully capture system behavior.
Welcome to my series of articles on Unified Modeling Language. This is "Session 10 – Sequence Diagram" of the series. Please view my other documents where I have covered each UML diagram with examples
The document discusses various UML diagrams used for modeling dynamic and implementation aspects of software systems. It describes interaction diagrams like sequence diagrams and collaboration diagrams which are used to model object interactions. It also covers state machine diagrams and activity diagrams which are used to model dynamic system behavior. Finally, it discusses implementation diagrams like package diagrams, component diagrams, and deployment diagrams which are used to model system organization and deployment.
This document discusses domain state modeling. It explains that some domain objects pass through distinct states, each with different properties and constraints. A domain state model identifies classes with states, finds the states and events that cause transitions, builds state diagrams, and evaluates the diagrams. The document provides steps for domain state modeling and examples using an ATM machine to illustrate states like account types and events like incorrect PIN. It emphasizes iteratively refining the analysis model to improve consistency and structure.
This document provides an overview of class diagrams in UML. It describes the key components of a class diagram including classes, attributes, operations, and relationships. A class represents a set of objects with common properties and behavior. It includes a name, attributes, and operations. Relationships between classes such as dependencies, generalizations, and associations are also depicted. The document provides examples of how to represent these components and relationships in a UML class diagram.
This document provides an overview of the Unified Modeling Language (UML) including its building blocks, diagrams, and the Rational Unified Process (RUP) methodology. It defines UML, explains its advantages for visualizing, specifying, and constructing systems. It describes the different types of UML elements including structural things like classes and interfaces, behavioral things like interactions and state machines, and grouping and annotational things. It also outlines the different UML diagrams for modeling a system from various perspectives and the four phases of the iterative RUP methodology.
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.
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 object-oriented analysis and design. It defines key terms and concepts in object-oriented modeling like use cases, class diagrams, states, sequences. It describes developing requirements models using use cases and class diagrams. It also explains modeling object behavior through state and sequence diagrams and transitioning analysis models to design.
The document discusses object-oriented design using UML. It describes the design process, including refining the analysis model into a design model with more implementation details. Key artifacts of design include interfaces, subsystems, and classes. Maintaining both analysis and design models is recommended for large, complex systems. Design axioms aim to maximize independence between components and minimize complexity. Corollaries provide guidelines for loosely coupled, single-purpose classes with strong mappings between analysis and design models.
The document discusses object oriented design and analysis, specifically focusing on UML views. It states that a system can best be described using five interlocking views: the use case view, design view, implementation view, process view, and deployment view. Each view provides a different perspective and projection of the system's organization, structure, and functionality for various stakeholders.
The document discusses collaboration diagrams, which capture the dynamic behavior of objects collaborating to perform tasks. Collaboration diagrams illustrate object interactions through messages in a graph format. They show objects, links between objects, and messages to model control flow and coordination. Notations are used to represent classes, instances, links, messages, return values, self-messages, conditional messages, iteration, and collections of objects. Examples of converting sequence diagrams to collaboration diagrams for making a phone call, changing flight itineraries, and making a hotel reservation are provided.
This slide give the basic introduction about UML diagram and it's types, and brief intro about Activity Diagram, use of activity diagram in object oriented programming language..
Activity Diagram Model An activity diagram visually presents a series of actions or flow of control in a system similar to a flowshart or a data flow diagram. Activity diagrams are often used in business process modeling.
This document discusses the General Responsibility Assignment Software Patterns (GRASP) principles for object-oriented design. It begins with an introduction to GRASP and its goals of being a mental toolset for designing software. It then explains nine key GRASP design patterns - Informational Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, and Protected Variations. For each pattern, it provides a definition and example of how and when to apply the pattern when assigning responsibilities to classes. It concludes with references for further reading on GRASP patterns.
The document provides an overview of state modeling and interaction modeling techniques. It defines key concepts like events, conditions, states, and transitions that are used in state diagrams. It also discusses use case diagrams, which model user interactions with a system through actors and use cases. The document explains that state diagrams describe the behavior and life cycles of objects in response to events, while use case and interaction diagrams elaborate the functional requirements and interactions between users and a 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.
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.
Object modeling represents the static structure of objects and their relationships using object diagrams. An object diagram shows instances of classes, their attributes and values, and relationships between objects through links representing associations, generalizations, or aggregations. Object diagrams are useful for understanding object behavior and relationships in a system, as well as its static view and for forward and reverse engineering.
Unit 1( modelling concepts & class modeling)Manoj Reddy
The document discusses object-oriented modeling and design. It covers key concepts like classes, objects, inheritance, polymorphism, and encapsulation. It also discusses the Unified Modeling Language (UML) which provides standard notation for visualizing, specifying, constructing, and documenting models. The document is a lecture on object-oriented concepts for students to understand modeling using classes, objects, and relationships.
The document discusses the Unified Modeling Language (UML). UML is a general-purpose modeling language used to specify, visualize, construct, and document software systems. It captures decisions and understanding about systems that must be constructed. The goals of UML included developing a modeling language that could be used across different domains and development methods. UML has three main building blocks - things, relationships, and diagrams. Things represent elements in a model like classes, components, and use cases. Relationships connect things and show dependencies, generalizations, and associations. Diagrams provide different views of UML models, including structural diagrams and behavioral diagrams.
State diagrams describe the behavior of objects by modeling their states and transitions between states based on events. Key elements of state diagrams include states, transitions, events, and actions. States represent conditions of an object, transitions are triggered by events, and actions occur on state entry/exit or during transitions. Together these elements specify the dynamic behavior of objects in response to events.
This document discusses nested state diagrams and interaction modeling techniques. It addresses:
1. The use of submachine states and composite states to model nested states within a state diagram.
2. Interaction modeling approaches including use cases, sequence diagrams, and activity diagrams.
3. Guidelines for developing use cases, sequence diagrams, and activity diagrams to fully capture system behavior.
Welcome to my series of articles on Unified Modeling Language. This is "Session 10 – Sequence Diagram" of the series. Please view my other documents where I have covered each UML diagram with examples
The document discusses various UML diagrams used for modeling dynamic and implementation aspects of software systems. It describes interaction diagrams like sequence diagrams and collaboration diagrams which are used to model object interactions. It also covers state machine diagrams and activity diagrams which are used to model dynamic system behavior. Finally, it discusses implementation diagrams like package diagrams, component diagrams, and deployment diagrams which are used to model system organization and deployment.
This document discusses domain state modeling. It explains that some domain objects pass through distinct states, each with different properties and constraints. A domain state model identifies classes with states, finds the states and events that cause transitions, builds state diagrams, and evaluates the diagrams. The document provides steps for domain state modeling and examples using an ATM machine to illustrate states like account types and events like incorrect PIN. It emphasizes iteratively refining the analysis model to improve consistency and structure.
This document provides an overview of class diagrams in UML. It describes the key components of a class diagram including classes, attributes, operations, and relationships. A class represents a set of objects with common properties and behavior. It includes a name, attributes, and operations. Relationships between classes such as dependencies, generalizations, and associations are also depicted. The document provides examples of how to represent these components and relationships in a UML class diagram.
This document provides an overview of the Unified Modeling Language (UML) including its building blocks, diagrams, and the Rational Unified Process (RUP) methodology. It defines UML, explains its advantages for visualizing, specifying, and constructing systems. It describes the different types of UML elements including structural things like classes and interfaces, behavioral things like interactions and state machines, and grouping and annotational things. It also outlines the different UML diagrams for modeling a system from various perspectives and the four phases of the iterative RUP methodology.
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.
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 object-oriented analysis and design. It defines key terms and concepts in object-oriented modeling like use cases, class diagrams, states, sequences. It describes developing requirements models using use cases and class diagrams. It also explains modeling object behavior through state and sequence diagrams and transitioning analysis models to design.
The document discusses object-oriented design using UML. It describes the design process, including refining the analysis model into a design model with more implementation details. Key artifacts of design include interfaces, subsystems, and classes. Maintaining both analysis and design models is recommended for large, complex systems. Design axioms aim to maximize independence between components and minimize complexity. Corollaries provide guidelines for loosely coupled, single-purpose classes with strong mappings between analysis and design models.
The document discusses object oriented design and analysis, specifically focusing on UML views. It states that a system can best be described using five interlocking views: the use case view, design view, implementation view, process view, and deployment view. Each view provides a different perspective and projection of the system's organization, structure, and functionality for various stakeholders.
The document discusses collaboration diagrams, which capture the dynamic behavior of objects collaborating to perform tasks. Collaboration diagrams illustrate object interactions through messages in a graph format. They show objects, links between objects, and messages to model control flow and coordination. Notations are used to represent classes, instances, links, messages, return values, self-messages, conditional messages, iteration, and collections of objects. Examples of converting sequence diagrams to collaboration diagrams for making a phone call, changing flight itineraries, and making a hotel reservation are provided.
This slide give the basic introduction about UML diagram and it's types, and brief intro about Activity Diagram, use of activity diagram in object oriented programming language..
Activity Diagram Model An activity diagram visually presents a series of actions or flow of control in a system similar to a flowshart or a data flow diagram. Activity diagrams are often used in business process modeling.
This document discusses the General Responsibility Assignment Software Patterns (GRASP) principles for object-oriented design. It begins with an introduction to GRASP and its goals of being a mental toolset for designing software. It then explains nine key GRASP design patterns - Informational Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, and Protected Variations. For each pattern, it provides a definition and example of how and when to apply the pattern when assigning responsibilities to classes. It concludes with references for further reading on GRASP patterns.
The document provides an overview of state modeling and interaction modeling techniques. It defines key concepts like events, conditions, states, and transitions that are used in state diagrams. It also discusses use case diagrams, which model user interactions with a system through actors and use cases. The document explains that state diagrams describe the behavior and life cycles of objects in response to events, while use case and interaction diagrams elaborate the functional requirements and interactions between users and a 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.
The document discusses use case modeling and provides information on key concepts:
- A use case describes interactions between a system and external users (actors) to achieve a goal. It specifies system behavior but not implementation.
- Key components of use case modeling include actors, use cases, relationships between use cases like inclusion and extension, and use case descriptions.
- Use cases capture functional requirements while use case descriptions elaborate different scenarios through structured text or pseudocode. Organizing use cases into packages supports generalization and specialization.
The document discusses various interaction diagrams used in modeling systems, including use case diagrams, sequence diagrams, activity diagrams, and state charts. It provides examples and definitions for each type of diagram. For use case diagrams, it explains actors, scenarios, and different notations. Sequence diagrams show the sequence and timing of messages between objects to illustrate object interactions. Activity diagrams model business processes and workflows showing the flow of activities. State chart diagrams use states and transitions to model an object's behavior in response to events. The document also includes exercises to create interaction diagrams for various example systems and processes.
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.
The document discusses various Unified Modeling Language (UML) diagrams used to model different aspects of software systems. It describes structure diagrams like class diagrams that show system composition and deployment diagrams that map software to hardware. It also covers behavioral diagrams like use case diagrams, interaction diagrams (sequence and communication diagrams), state-chart diagrams, and activity diagrams that model dynamic system behavior through object interactions and state transitions. Specific examples are provided for how to construct and interpret sequence diagrams, state machine diagrams, and activity diagrams.
The document provides guidance on developing use case models for a system. It defines key concepts like actors, use cases, include and extend relationships. It explains that use cases describe interactions between actors and the system to achieve goals. The document also provides examples of use case diagrams and descriptions to illustrate how to identify actors and use cases, and describe typical and alternative flows and exceptions. It emphasizes that use cases specify expected behavior from the user's perspective without detailing implementation.
In this lesson, you will develop a system using Use Cases.
You will:
Justify the need for a Use Case diagram
Identify and describe the essential elements in a UML Use Case diagram
Identifying the Actors in a System.
Identifying Use Cases in a System
Create a Use Case Diagram that shows the Use Cases in your system.
Recognize and document use case dependencies using UML notation for extends,includes, and generalization
This document discusses behavioral modeling in software engineering requirements. It describes creating behavioral models by identifying events from use cases and building state diagrams and sequence diagrams. State diagrams represent object states and transitions, while sequence diagrams show the flow of events between objects over time. The document provides examples of a state diagram for a control panel and a sequence diagram for a home security system to illustrate behavioral modeling concepts.
The document discusses modeling techniques for object-oriented systems using Unified Modeling Language (UML) diagrams. It describes how to model message flows and object interactions using sequence diagrams and collaboration diagrams. It also explains how to model an object's lifetime behaviors using state chart diagrams and model procedural performance using activity diagrams. Specific examples are provided for each diagram type to illustrate their notation and usage.
Use case modeling involves describing how users will interact with a system to achieve goals. A use case represents a dialog between a user and the system, specifying what information must pass between them without detailing the system's internal workings. Each use case should have a name that includes a verb describing the user's goal. Actors represent people or systems that interact with the system-to-be to accomplish responsibilities. Sequence diagrams visually depict the information exchanged between actors and the system in specific use case scenarios.
The document provides an overview of modeling with the Unified Modeling Language (UML). It discusses what modeling is, introduces UML, and describes some key UML diagrams - use case diagrams, class diagrams, sequence diagrams, and activity diagrams. It explains that UML can be used to model both the application domain during requirements analysis and the solution domain during system and object design. The document recommends starting with use case diagrams to describe functionality, class diagrams to describe system structure, sequence diagrams for behavior, and focusing on these core aspects which can model 80% of problems using only 20% of UML.
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.
SE18_Lec 10_ UML Behaviour and Interaction DiagramsAmr E. Mohamed
The document discusses various Unified Modeling Language (UML) diagrams used to model different aspects of a system. It describes structure diagrams like class diagrams and deployment diagrams. It also explains behavior diagrams like use case diagrams, interaction diagrams (sequence and communication diagrams), state-chart diagrams, and activity diagrams. Specific examples are provided to illustrate sequence diagrams, state machine diagrams, and activity diagrams. Key concepts like objects, messages, states, transitions, events, and swimlanes are defined in the context of these diagram types.
topic : UML DIAGRAMS
content : Use Case Diagram
Class Diagram
Interaction diagram
Activity diagram
Case Study
details :
Use Case Diagram ::
1 Dynamic in nature.
2 It is used to model the system/subsystem of the application.
3 Built in early stage of development and developed by analyst
4 Involves interaction between user and system.
Class Diagram ::
1 Class diagram is a static diagram.
2 Class diagram used for different aspects of a system.
3 The class diagram describe the attributes and operations of a class.
4 It is also known as structural diagram.
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.
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.
OMT uses three models - the object model, dynamic model, and functional model. The dynamic model represents the temporal, behavioral, and control aspects of a system using events, states, and state transitions. It shows how objects interact over time in response to events, and is represented through state diagrams that define the different states an object can be in and the events that trigger transitions between states.
The document discusses various types of Unified Modeling Language (UML) diagrams used for software modeling including state machine diagrams, deployment diagrams, package diagrams, component diagrams, and timing diagrams. It provides descriptions of each diagram type including their purpose and how they are used to model different aspects of software design.
Use cases are best suited for reactive and interactive systems, but have some shortcomings. They do not adequately capture activities for systems that are algorithm-driven or data-intensive, and may leave out important parts of the environment. State diagrams show the behavior of a system in response to external stimuli by illustrating the actual state changes, rather than the processes that created them. They identify states, transitions between states triggered by events, and can have an initial and terminating state.
Similar to Unit 3(advanced state modeling & interaction meodelling) (20)
This document discusses small scale industries (SSI) in India. It defines SSI and outlines how the investment limit for SSI classification has increased over time from Rs. 5 lakhs to Rs. 3 crore. It discusses the role of SSI in economic development through job creation, production increase, exports growth, and regional development. The document also outlines the steps to start an SSI, including project selection, registration, clearances, financing, and implementation. Government policies over time including IPR 1948, 1956, and 1977 provided support and protection to the small sector.
This document discusses the preparation and importance of project reports. It defines a project and outlines the key steps in project identification, selection, and preparation of a project report. These include identifying potential opportunities, evaluating ideas based on factors like size, location, technology, and marketing, and developing a comprehensive project report that covers technical, financial, production, and risk aspects of the proposed project. Conducting proper feasibility analysis and appraisal is important to determine if the project is viable and ensure successful implementation.
Planning is the process of determining objectives and deciding in advance how to achieve them. The document outlines the planning process, including establishing objectives, determining premises and alternatives, evaluating alternatives, selecting a course of action, formulating supporting plans, and reviewing. It also discusses types of plans like strategic and tactical plans. Effective planning focuses attention on objectives, reduces uncertainty, and provides direction to help organizations achieve their goals.
The document discusses various institutions that provide support to industries in Karnataka, including the Karnataka Industrial Areas Development Board (KIADB), Karnataka Small Scale Industries Development Corporation (KSSIDC), Karnataka State Industrial Investment and Development Corporation (KSIMC), National Small Industries Corporation (NSIC), District Industries Centres (DICs), and Small Industries Development Bank of India (SIDBI). It provides details on the functions and services provided by these institutions such as acquiring land for industrial areas, providing infrastructure, term loans, refinancing, entrepreneurship training, and more.
This document discusses key management concepts related to directing, controlling, leadership, motivation, communication, and coordination. It provides definitions and descriptions of:
- Leadership styles including autocratic, democratic, and free rein approaches.
- Motivation theories such as expectancy theory and Maslow's hierarchy of needs.
- The importance of communication and coordination in management.
- The process of controlling including setting standards, measuring performance, and taking corrective action.
This document provides information about entrepreneurs and entrepreneurship. It defines an entrepreneur as someone who creates a new business by taking on risks and identifying opportunities. The document discusses the evolution of the concept of entrepreneurship. It outlines the functions, types, qualities and characteristics of entrepreneurs. Examples of famous entrepreneurs such as JRD Tata, Dhirubhai Ambani, and Bill Gates are provided. The document also defines and compares entrepreneurs, managers, and intrapreneurs. It discusses the stages of entrepreneurial process and the role of entrepreneurs in economic development.
This document provides an overview of management principles and concepts. It discusses key topics like the definition and functions of management, levels of management, management theories from early to modern approaches, and the roles and responsibilities of managers. The five main functions of management are identified as planning, organizing, staffing, directing, and controlling.
Using recycled concrete aggregates (RCA) for pavements is crucial to achieving sustainability. Implementing RCA for new pavement can minimize carbon footprint, conserve natural resources, reduce harmful emissions, and lower life cycle costs. Compared to natural aggregate (NA), RCA pavement has fewer comprehensive studies and sustainability assessments.
TIME DIVISION MULTIPLEXING TECHNIQUE FOR COMMUNICATION SYSTEMHODECEDSIET
Time Division Multiplexing (TDM) is a method of transmitting multiple signals over a single communication channel by dividing the signal into many segments, each having a very short duration of time. These time slots are then allocated to different data streams, allowing multiple signals to share the same transmission medium efficiently. TDM is widely used in telecommunications and data communication systems.
### How TDM Works
1. **Time Slots Allocation**: The core principle of TDM is to assign distinct time slots to each signal. During each time slot, the respective signal is transmitted, and then the process repeats cyclically. For example, if there are four signals to be transmitted, the TDM cycle will divide time into four slots, each assigned to one signal.
2. **Synchronization**: Synchronization is crucial in TDM systems to ensure that the signals are correctly aligned with their respective time slots. Both the transmitter and receiver must be synchronized to avoid any overlap or loss of data. This synchronization is typically maintained by a clock signal that ensures time slots are accurately aligned.
3. **Frame Structure**: TDM data is organized into frames, where each frame consists of a set of time slots. Each frame is repeated at regular intervals, ensuring continuous transmission of data streams. The frame structure helps in managing the data streams and maintaining the synchronization between the transmitter and receiver.
4. **Multiplexer and Demultiplexer**: At the transmitting end, a multiplexer combines multiple input signals into a single composite signal by assigning each signal to a specific time slot. At the receiving end, a demultiplexer separates the composite signal back into individual signals based on their respective time slots.
### Types of TDM
1. **Synchronous TDM**: In synchronous TDM, time slots are pre-assigned to each signal, regardless of whether the signal has data to transmit or not. This can lead to inefficiencies if some time slots remain empty due to the absence of data.
2. **Asynchronous TDM (or Statistical TDM)**: Asynchronous TDM addresses the inefficiencies of synchronous TDM by allocating time slots dynamically based on the presence of data. Time slots are assigned only when there is data to transmit, which optimizes the use of the communication channel.
### Applications of TDM
- **Telecommunications**: TDM is extensively used in telecommunication systems, such as in T1 and E1 lines, where multiple telephone calls are transmitted over a single line by assigning each call to a specific time slot.
- **Digital Audio and Video Broadcasting**: TDM is used in broadcasting systems to transmit multiple audio or video streams over a single channel, ensuring efficient use of bandwidth.
- **Computer Networks**: TDM is used in network protocols and systems to manage the transmission of data from multiple sources over a single network medium.
### Advantages of TDM
- **Efficient Use of Bandwidth**: TDM all
International Conference on NLP, Artificial Intelligence, Machine Learning an...gerogepatton
International Conference on NLP, Artificial Intelligence, Machine Learning and Applications (NLAIM 2024) offers a premier global platform for exchanging insights and findings in the theory, methodology, and applications of NLP, Artificial Intelligence, Machine Learning, and their applications. The conference seeks substantial contributions across all key domains of NLP, Artificial Intelligence, Machine Learning, and their practical applications, aiming to foster both theoretical advancements and real-world implementations. With a focus on facilitating collaboration between researchers and practitioners from academia and industry, the conference serves as a nexus for sharing the latest developments in the field.
Introduction- e - waste – definition - sources of e-waste– hazardous substances in e-waste - effects of e-waste on environment and human health- need for e-waste management– e-waste handling rules - waste minimization techniques for managing e-waste – recycling of e-waste - disposal treatment methods of e- waste – mechanism of extraction of precious metal from leaching solution-global Scenario of E-waste – E-waste in India- case studies.
ACEP Magazine edition 4th launched on 05.06.2024Rahul
This document provides information about the third edition of the magazine "Sthapatya" published by the Association of Civil Engineers (Practicing) Aurangabad. It includes messages from current and past presidents of ACEP, memories and photos from past ACEP events, information on life time achievement awards given by ACEP, and a technical article on concrete maintenance, repairs and strengthening. The document highlights activities of ACEP and provides a technical educational article for members.
CHINA’S GEO-ECONOMIC OUTREACH IN CENTRAL ASIAN COUNTRIES AND FUTURE PROSPECTjpsjournal1
The rivalry between prominent international actors for dominance over Central Asia's hydrocarbon
reserves and the ancient silk trade route, along with China's diplomatic endeavours in the area, has been
referred to as the "New Great Game." This research centres on the power struggle, considering
geopolitical, geostrategic, and geoeconomic variables. Topics including trade, political hegemony, oil
politics, and conventional and nontraditional security are all explored and explained by the researcher.
Using Mackinder's Heartland, Spykman Rimland, and Hegemonic Stability theories, examines China's role
in Central Asia. This study adheres to the empirical epistemological method and has taken care of
objectivity. This study analyze primary and secondary research documents critically to elaborate role of
china’s geo economic outreach in central Asian countries and its future prospect. China is thriving in trade,
pipeline politics, and winning states, according to this study, thanks to important instruments like the
Shanghai Cooperation Organisation and the Belt and Road Economic Initiative. According to this study,
China is seeing significant success in commerce, pipeline politics, and gaining influence on other
governments. This success may be attributed to the effective utilisation of key tools such as the Shanghai
Cooperation Organisation and the Belt and Road Economic Initiative.
DEEP LEARNING FOR SMART GRID INTRUSION DETECTION: A HYBRID CNN-LSTM-BASED MODELgerogepatton
As digital technology becomes more deeply embedded in power systems, protecting the communication
networks of Smart Grids (SG) has emerged as a critical concern. Distributed Network Protocol 3 (DNP3)
represents a multi-tiered application layer protocol extensively utilized in Supervisory Control and Data
Acquisition (SCADA)-based smart grids to facilitate real-time data gathering and control functionalities.
Robust Intrusion Detection Systems (IDS) are necessary for early threat detection and mitigation because
of the interconnection of these networks, which makes them vulnerable to a variety of cyberattacks. To
solve this issue, this paper develops a hybrid Deep Learning (DL) model specifically designed for intrusion
detection in smart grids. The proposed approach is a combination of the Convolutional Neural Network
(CNN) and the Long-Short-Term Memory algorithms (LSTM). We employed a recent intrusion detection
dataset (DNP3), which focuses on unauthorized commands and Denial of Service (DoS) cyberattacks, to
train and test our model. The results of our experiments show that our CNN-LSTM method is much better
at finding smart grid intrusions than other deep learning algorithms used for classification. In addition,
our proposed approach improves accuracy, precision, recall, and F1 score, achieving a high detection
accuracy rate of 99.50%.
3. UNIT – 3
ADVANCED STATE MODELING, INTERACTION
MODELING:
State Modeling: Nested state diagrams; Nested states; Signal
Advanced generalization; Concurrency; A sample state model;
Relation of class and state models; Practical tips.
Interaction Modeling: Use case models; Sequence models;
Activity models. Use case relationships; Procedural sequence
models; Special constructs for activity models.
4. Two major features are introduced for
controlling complexity and
combinatorial explosion in state
diagrams
◦ Nested state diagrams
◦ Concurrent state diagrams
Many other features are also added
◦ propagated transitions
◦ broadcast messages
◦ actions on state entry, exit
◦ …
S2
S1
Nested State Diagrams
Concurrent State Diagrams
5. Activities in states are composite items denoting other
lower-level state diagrams
A lower-level state diagram corresponds to a sequence
of lower-level states and events that are invisible in the
higher-level diagram.
6. When one state is complex, you
can include substates in it.
◦ drawn as nested rounded
rectangles within the larger
state
Caution: Don't over-use this
feature.
◦ easy to confuse separate states
for sub-states within one state
superstate
substates
7. A state may be represented as nested substates.
◦ In UML, substates are shown by nesting them in a superstate box.
◦ A substate inherits the transitions of its superstate.
8. Idle
off hook / play dial tone
[valid subscriber] Active
on hook
PlayingDialTone
digit digit
connected
complete
Talking
Dialing Connecting
11. Checking
do / check
Item
Dispatching
do / initiate
delivery
Delivering
[all items checked &&
some items not in stock]
Order item
[all items checked && all items available]
Dispatch items
[all items available]
Item received
delivery
get first item
Ordering
Exit/ Item received
do / order Item
cancelled Canceling
*[all items checked]
get next item
entry / deliver
Items
do / Remove
Item
12.
13. Transitions can be specific
◦ A transition can be from a specific
substate (T1)
◦ A transition can be to a specific
substate inside the nested state (T2)
Transitions can be general
◦ We saw that a transition from the
superstate is valid for all substates
(T3)
◦ A transition into the superstate (T4)
normally goes to the default initial
state (start state leading to F)
T1
S
A B
E
F
C
D
T2
T4
T3
14. ◦ concurrency is a property of systems in which several computations are
executing simultaneously, and potentially interacting with each other.
◦ Dashed line indicates that an order is in two different states, e.g. Checking &
Authorizing
◦ When order leaves concurrent states, it’s in a single state: Canceled, Delivered
or Rejected
◦ Concurrent Sub states - Used when two or more state diagrams are
executing concurrently within a single object.
15. Complex systems usually have
concurrency
◦ “subsystems” that operate (mostly)
independently
Heart monitor device
◦ The power supply and the heart
monitoring application are really
concurrent subsystems
◦ They should be modeled that way!!
◦ They are mostly independent: the
monitoring application doesn’t care
where it gets its power
Heart Monitor
Monitoring
Subsystem
Power
Subsystem
16. Startup
Alarm
Operational
Off
Switch on
Switch off
Startup
Complete
Problem
detected
Running
Monitoring Subsystem
Mains on
Battery Mains
Mains off
Dotted line
separates
concurrent state
machines
Power Subsystem
17. release key
Ignition turn key to start
[Transmin iNsseiountral]
turn key off
Transmission
Forward
Accelerator
depress accelerator
release accelerator
push R
push N
push N push F
upshift
downshift
upshift
downshift
stop
Brake
depress brake
release brake
Car
off starting on
Neutral Reverse
first second third
off on off on
18. Two types of concurrency
1. System concurrency
◦ State of overall system as the aggregation of state diagrams, one
for each object. Each state diagram is executing concurrently with
the others.
2. Object concurrency
◦ An object can be partitioned into subsets of states (attributes and
links) such that each of them has its own subdiagram.
◦ The state of the object consists of a set of states: one state from
each subdiagram.
◦ State diagrams are divided into subdiagrams by dotted lines.
19.
20. The class model describes the class & objects in a
system and their relationship.
The state model describes the life cycles of the objects.
The interaction model describes how the objects
interact.
The interaction model starts with use cases that are
then elaborated with sequence and activity diagrams
21. Use case: focuses on functionality of a system- i.e,
what a system does for users
Sequence diagrams: shows the object that interact and
the time sequence of their interactions
Activity diagrams: elaborates important processing
steps
22.
23.
24.
25.
26.
27. Functional vs. Non-Functional
Requirements
Functional
Non-Functional
Functional requirement are user ‘visible’ features and are
typically initiated by stakeholders of the system – generate
report, login, etc.
Non-functional requirements are ‘non-visible’ features and
but required for a effective running of an application – security,
backup, etc.
28.
29. Use Case diagrams show the various activities the users
can perform on the system.
◦ System is something that performs a function.
They model the dynamic aspects of the system.
Provides a user’s perspective of the system.
29
30. A use case is a model of the interaction between External users of a
software product (actors) and The software product itself
More precisely, an actor is a user playing a specific role describing a
set of user scenarios capturing user requirements contract between
end user and software developers
31. Use case diagrams are used to visualize, specify, construct,
and document the (intended) behavior of the system, during
requirements capture and analysis.
Provide a way for developers, domain experts and end-users to
Communicate.
Serve as basis for testing.
Use case diagrams contain use cases, actors, and their
relationships.
31
32. Actors: A role that a user plays with respect to the system, including
human users and other systems. e.g., inanimate physical objects (e.g.
robot); an external system that needs some information from the
current system.
Use case: A set of scenarios that describing an interaction between a
user and a system, including alternatives.
System boundary: rectangle diagram representing the boundary
between the actors and the system.
Association: Communication between an actor and a use case;
Represented by a solid line.
33. Actors
Could be human beings, other systems,
timers and clocks or hardware devices.
Actors that stimulate the system and are the
initiators of events are called primary actors
(active)
Actors that only receive stimuli from the
system are called secondary actors (passive)
34. Actors
Who/what will be interested in the system?
Who/what will want to change the data in the
system?
Who/what will want to interface with the
system?
Who/what will want information from the
system?
35. 1. Avoid showing communication between actors.
2. Actors should be named as singular. i.e student and NOT students. NO names
should be used – i.e John, Sam, etc.
36.
37. 1. Start by identifying the actors of the system
2. Define the goals of the system and how they can be
achieved using the systems’ actors
3. Illustrate these goals and actors actions using use-case
diagram(s)
37
38. A use case describes a sequence of actions a system performs to
yield an observable result or value to a particular actor
Naming convention = verb + noun (or) verb + noun-phrase,
◦ e.g. withdraw cash
A good use case should:
◦ Describe a sequence of transactions performed by a system that
produces a measurable result (goal) for a particular actor
◦ Describe the behavior expected of a system from a user's
perspective
◦ Enable the system analyst to understand and model a system from
a high-level business viewpoint
◦ Represent the interfaces that a system makes visible to the
external entities and the interrelationships between the actors and
the system
38
39. Use case is a particular activity a user can do on the
system.
Is represented by an ellipse.
Following are two use cases for a library system.
39
Borrow Reserve
40.
41. • What are the tasks of each actor?
• Will any actor create, store, change, remove, or read
the information?
• Will any actor need to inform the system about the
sudden, external changes?
• Does any actor need to informed about certain
occurrences in the system?
• What use cases will support and maintain the system?
• Can all functional requirements be performed by the
use cases?
42. Construct Description Notation
Use-case A sequence of transactions
performed by a system that produces
a measurable result for a particular
actor
Actor A coherent set of roles that users
play
when interacting with these use
cases
System
Boundary
The boundary between the physical
system and the actors who interact
with the physical system
42
43.
44.
45. • Functionality provided by the system
• Consist of a series of steps which collectively add
value to the user of the system
• Examples
– Issue a book to a member
– Receive a book back from a member
– Query the current location of a book
– Maintain member’s information
– Maintain book’s information
48. client employee
48 A Library System.
supervisor
library system
borro
w
reserve
Order title
Fine
payment
49. 49
Teacher
Student
Printing administrator
Grade system
Record
grades
View grades
Distribute
Report cards
Create report
cards
50.
51.
52. Include: a dotted line labeled <<include>> beginning at base use case
and ending with an arrows pointing to the include use case. The include
relationship occurs when a chunk of behavior is similar across more
than one use case. Use “include” in stead of copying the description of
that behavior.
<<include>>
Extend: a dotted line labeled <<extend>> with an arrow toward the base
case. The extending use case may add behavior to the base use case. The base
class declares “extension points”.
<<extend>>
53. base <<include>> included
The base use case explicitly incorporates the behavior
of another use case at a location specified in the base.
The included use case never stands alone. It only
occurs as a part of some larger base that includes it.
53 ניתוח מערכות מידע
54. Enables to avoid describing the same flow of events
several times by putting the common behavior in a use
case of its own.
54 ניתוח מערכות מידע
updating
grades
output
generating
verifying
student id
<<include>>
<<include>>
55.
56. Include relationships are used when two or more use cases
share some common portion in a flow of events
This common portion is then grouped and extracted to form an
inclusion use case for sharing among two or more use cases
Most use cases in the ATM system example, such as
Withdraw Money, Deposit Money or Check Balance, share
the inclusion use-case Login Account
56
57. 57
Login Account
(Included use case)
Withdraw Money
(Base use case)
59. base <<extend>> extending
The base use case implicitly incorporates the behavior
of another use case at certain points called extension
points.
The base use case may stand alone, but under certain
conditions its behavior may be extended by the
behavior of another use case.
59 ניתוח מערכות מידע
60. In UML modeling, you can use an extend relationship
to specify that one use case (extension) extends the
behavior of another use case (base)
This type of relationship reveals details about a system
or application that are typically hidden in a use case
60
61. 61
Process Excess Amount
(Extending use case)
Withdraw Money
(Base use case)
If conditional guard is true, extending flow is executed
66. Construct Description Notation
Association The participation of an actor in a
use case, i.e. an instance of an
actor and instances of a use case
communicating with each other
Generalization A taxonomic relationship between
a general use case and a more
specific use case. The arrow head
points to the general use case
Extend A relationship between an
extension use case and a base
use case, specifying how the
behavior of the extension use case
can be
inserted into the behavior defined
66
67. Construct Description Notation
Include A relationship between a base use
case and an inclusion use case,
specifying how the behavior for the
inclusion use case is inserted into the
behavior defined for the base use
case. The arrow head points to the
inclusion use case
67
68. Both Make
Appointment and
Request Medication
include Check Patient
Record as a subtask
(include)
The extension point is
written inside the base
case Pay bill; the
extending class Defer
payment adds the
behavior of this
extension point.
(extend)
Pay Bill is a parent use
case and Bill
Insurance is the child
use case.
(generalization)
(TogetherSoft, Inc)
69.
70.
71.
72.
73. Each use case may include all or part : of the following
Title or Reference Name - meaningful name of the UC
Author/Date - the author and creation date
Modification/Date - last modification and its date
Purpose - specifies the goal to be achieved
Overview - short description of the processes
Cross References - requirements references
Actors - agents participating
Pre Conditions - must be true to allow execution
Post Conditions - will be set when completes
normally
Normal flow of events - regular flow of activities
Alternative flow of events - other flow of activities
Exceptional flow of events - unusual situations
Implementation issues - foreseen implementation
problems
ניתוח מערכות מידע
73
74.
75. The sequence model elaborates the themes of use cases.
Two kinds of sequences models
Scenarios
Sequence diagram
76. A scenario is a sequence of events that occurs during
one particular execution of a system.
For example:
John logs in, transmits a message from John to the
broker system.
77.
78.
79. A sequence diagram shows the participants in an interaction and the
sequence of messages among them.
A sequence diagram shows the interaction of a system with its
actors to perform all or part of a use case.
Each use case requires one or more sequence diagrams to describe
its behaviour.
80. Sequence diagrams, also known as event diagrams or event
scenarios, illustrate how processes interact with each other by
showing calls between different objects in a sequence.
These diagrams have two dimensions:
The vertical lines show the sequence of messages and calls in
chronological order
Horizontal elements show object instances where the messages
are relayed.
81. Components Of A Sequence Diagram
Sequence Diagram
Active objects Messages
Control Activation Box Lifeline
Information
82. Active Objects:
◦ Any objects that play a role in the system
◦ Can be any object or class that is valid within the system
◦ Can be an Actor that is external to the system and derives benefits
from the system
Messages:
◦ Used to illustrate communication between different active
objects.
◦ Used when an object needs
to activate a process of a different object
to give information to another object
83. Lifeline
◦ Denotes the life of actors/objects over time during a sequence
Focus of control (activation box)
◦ Means the object is active and using resources during that time
period
Control information
◦ Shows the control flow in the system
◦ Creation and destruction of an object through <<create>> and
<<destroy>>
84. Squares with object type, optionally preceded by object name and
colon
◦ write object's name if it clarifies the diagram
◦ object's "life line" represented by dashed vert. line
84
85. Objects are displayed at the top of the
diagram
The vertical dimension represents time
Each object has a dashed line – lifeline
– extending below it – to indicate the
period of time during which objects
playing that role actually exist
Object Name
86. Creation: arrow with 'new'
written above it
Deletion: an X at bottom of
object's lifeline
86
87. The messages in an
interaction are drawn from
top to bottom, in the order
that they are sent.
Messages are shown
as arrows pointing from the
lifeline of the role sending the
message to the lifeline of the
receiver.
When a message is
sent, control passes from the
sender of the message to the
receiver.
Object Name Object Name
message
88. Return of control is shown using dashed arrow returning to
the calling object.
Object Name Object Name
message
89. Message (method call) indicated by horizontal arrow
to other object
◦ write message name and arguments above arrow
89
90. Activations - show when a method is active – either executing or
waiting for a subroutine to return
◦ Either that object is running its code, or it is on the stack waiting
for another object's method to finish
90
91. • Period of time during
which an object is
processing a message,
Shown on a lifeline as a
narrow rectangle whose
top is connected to a
message.
• When an object finishes
processing a message,
control returns to the
sender of the message
Object Name Object Name
message
92. a : Assembly part : CatalogEntry
getNumber()
: Client
count(part)
return number
Lifeline
Messages
Activation(
optional)
control returns to the
sender of the message
(optional)
97. Activity diagrams and use cases are logical model which describe
the business domain’s activities without suggesting how they are
conduct.
A diagram that emphasizes the flow of control from activity to
activity in an object.
Similar to the traditional program flowchart.
Used to provide detail for complex algorithms.
Primary activities and the relationships among the activities in a
process.
98. Purpose
◦ to model a task (for example in business modelling)
◦ to describe a function of a system represented by a use case
◦ to describe the logic of an operation
◦ to model the activities that make up the life cycle in the Unified
Process
99. Initial Node
Control Flow
Action or Activity
Object Flow
Branch
Merge
Fork
Join
Final Node
09/29/14 99
100. This represents the start of
the flow of an activity
diagram.
An activity diagram contains
a single start node.
The name of the initial node
is entered on the node. It
takes the form of an
adjective.
09/29/14 100
101. A control flow connects any combination of:
◦ activities
◦ branches
◦ merges
◦ forks
◦ joins
A control flow has direction, which is indicated by the arrow head
– you may only traverse the control flow in the direction of the
arrow.
A control flow may not enter an initial state.
A control flow may not exit a final node.
A control flow is the representation of an occurrence of an event.
The name of the event is entered on the control flow. It takes the
form of something has been done, noun-verb(past-tense)
09/29/14 101
102. The activity represents the
actions that occur as a result of
an incoming event from a control
flow.
The name of the activity is
entered on the activity and takes
the form of something being
done, present tense verb-noun
09/29/14 102
103. The branch is used to show alternative paths in the
activity diagram.
Label the decision node with a question(?).
Do not label the merge, (unless you have a good
reason to).
One control flow enters the decision node and two
or more alternative control flows exit the decision
node.
Only one of the paths may be transitioned as the
result of an event occurring.
Each exiting control flow contains the condition
under which it is taken (called a guard), dependent
upon the answer to the question. These guards must
be mutually exclusive.
09/29/14 103
104. The guards on exiting control flows must cover all possible
outcomes of the question being asked by the branch.
◦ The simplest way to ensure all possible outcomes are covered is
to phrase the branch question such that the only possible answers
are ‘Yes’ or ‘No’. Note, this can add extra branches to the
diagram.
Two or more control flows enter the merge node and one control
flow exits.
105. 09/29/14 105
The fork may be represented by vertical or
horizontal bars.
The fork represents that the flow through the
diagram has split into 2 paths that are running
in parallel (multitasking).
The fork has a single control flow on entry and
several control flows exiting.
Use a fork when there is no requirement on the
order of activities in a flow.
◦ For example, the Dematerializer receives an
event that the door is shut. It now suspends
the cargo and creates a vacuum, but these
actions may be performed in parallel, so we
model them with a fork.
106. 09/29/14 106
For every fork there should be a join (if not
your activity diagram is broken).
The join may be represented by vertical or
horizontal bars.
A join simply shows that when the parallel
activities have finished that they then come
back to join a single flow again.
The join has several control flows entering and
a single control flow on exit.
The exiting control flow cannot be executed
until every incoming control flow has
completed.
There is no need to label the fork or join.
107. The final node represents the termination of the activity
diagram.
There may be several termination states in a single
diagram.
Label the final node with an adjective.
09/29/14 107
108.
109. [Condition]
For each X:
START POINT
END POINT
STEP
TRANSITION
DECISION POINT
GUARD
PARALLEL STEPS
REPEATED STEPS
118. Actor elects to Add Customer
This makes it clear to the
reader that the use case
is complete and that
nothing further is needed
in order to fulfil the
intent.
Customer added
Nested state diagrams are useful for two reasons:
As a solution to cope with the complexity in your design:
Abstraction: A state is actually more complex and leads to a finite state automaton itself. On the top level we don’t model all the complex states.
Modularization: Each state diagram has up to 7+-2 states.
Hierarchy: We apply the “ Consist of” association!
Concurrency is an important aspect any application for two reasons:
Maintainability: If two classes are really concurrent, that means, they are not related to each other, and they can be designed and developed completely independently from each other.
Improved Performance: Concurrency also means in many cases a possible source for fast response time. If methods can be executed in parallel, and not in serial fashion, the systems response time will be better.
Concurrency within a state of a single object arises when the object can be paritioned into subsets of attributes, each of which has its own subdiagram.
In this case, the state of the object comprises one state from each subdiagram. Note that these subdiagrams don’t have to be independent. The same event can cause state transitions in more than one subdiagram.
Examples of concurrency within an object: A dispenser machine, that simultaneously dispenses cash and ejects the card.
Often concurrency within an object is discovered after the object has been identified. It might be the source for iterating on the object identification and question if there are not two separate objects in the problem that are worth modeling.