CS8592-OOAD Lecture Notes Unit-3

CS6502 OBJECT ORIENTED ANALYSIS AND DESIGN UNIT III - DYNAMIC AND IMPLEMENTATION UML DIAGRAMS Dynamic Diagrams: UML interaction diagrams - System sequence diagram - Collaboration diagram - When to use Communication Diagrams - State machine diagram and Modelling - When to use State Diagrams - Activity diagram - When to use activity diagrams. Implementation Diagrams: UML package diagram - When to use package diagrams - Component and Deployment Diagrams - When to use Component and Deployment diagrams.

2 Dynamic Diagrams • UML interaction diagrams • System sequence diagram • Collaboration diagram (Communication Diagrams) • State machine diagram • Activity diagram

Interaction Diagrams  Illustrates how objects interact via messages  2 diagram types:  Sequence Diagram (fence format)  Collaboration Diagram (graph or network) 3

 Class diagrams represent static modeling.  What about modeling dynamic behavior?  Interaction diagrams (Sequence and communication diagrams) model how groups of object collaborate to perform some behavior Typically captures the behavior of a single use case System Sequence Diagrams 4

System Sequence Diagram (SSD) For a use case scenario, an SSD shows:  The System (as a black box)  The external actors that interact with System  The System events that the actors generate , their temporal order. :System 5

Naming System events & operations System events and associated system operations should be expressed at the level of intent. Rather than physical input medium or UI widget Start operation names with verb (from use case) 6

Common interaction Diagram Notation  Classes and Instances: 9

Common interaction Diagram Notation  Basic Message Expression Syntax: return := message(parameter : parameterType) : returnType 10

Basic Sequence Diagram Notation  Links:  Sequence diagrams do not show links (connection paths between objects) 11

Basic Sequence Diagram Notation  Messages – illustrating returns: 12

Basic Sequence Diagram Notation  Messages to ’self’ or ’this’: 13

Basic Sequence Diagram Notation  Creation of Instances: 14

Basic Sequence Diagram Notation  Object lifelines and Object Destruction: 15

Basic Sequence Diagram Notation  Conditional Messages: 16

Basic Sequence Diagram Notation  Mutually Exclusive Conditional Messages: 17

Basic Sequence Diagram Notation  Iteration for a single message: 18

Basic Sequence Diagram Notation  Iteration of a Series of Messages: 19

Basic Sequence Diagram Notation  Iteration over a Collection: 20

Basic Sequence Diagram Notation  Messages to Class Objects 21

Basic Collaboration Diagram Notation  Links: a connection path between two objects 22

Basic Collaboration Diagram Notation  Messages:  Messages to ’self’ or ’this’ 23

Basic Collaboration Diagram Notation  Creation of Instances: 24

Basic Collaboration Diagram Notation  Message number sequencing: 25

Basic Collaboration Diagram Notation  Complex sequence numbering: 26

Basic Collaboration Diagram Notation  Conditional Messages: 27

Basic Collaboration Diagram Notation  Mutually Exclusive Conditional Paths: 28

Basic Collaboration Diagram Notation  Iteration or Looping: 29

Basic Collaboration Diagram Notation  Iteration over a Collection: 30

Basic Collaboration Diagram Notation  Messages to a Class Object 31

Sequence Diagrams Collaboration Diagrams It represents the UML, which is used to visualize the sequence of calls in a system that is used to perform a specific functionality. It also comes under the UML representation which is used to visualize the organization of the objects and their interaction. It is used to represent the sequence of messages that are flowing from one object to another. It is used to represent the structural organization of the system and the messages that are sent and received. The sequence diagram is used when time sequence is main focus. The collaboration dagram is used when object organization is main focus. The sequence diagrams are better suited of analysis activities. The collaboration diagrams are better suited for depicting simpler interactions of the smaller number of objects. 32 Sequence Diagrams vs Collaboration Diagrams

Naming System events & operations enterItem(itemID, quantity) scan(itemID, quantity) : Cashier worse name better name :System Capture the intent of the operation while remaining abstract 33

36 When to use Communication Diagrams? • Communication / Collaboration diagrams should be used when you want to look at the behavior of several objects within a single use case. • They are good at showing the collaborations between the objects, they are not so good at precise definition of the behavior.

37 State machine diagram and Modelling What is State Machine Diagram? • A state is an abstraction of the attribute values and links of an object. Sets of values are grouped together into a state according to properties that affect the gross behavior of the object. • State machine diagrams are also called as state chart diagrams. State machine diagrams are used to capture the behavior of a software system. • UML State machine diagrams can be used to model the behavior of a class, a subsystem, a package, or even an entire system. • Statechart diagrams provide us an efficient way to model the interactions or communication that occur within the external entities and a system. • These diagrams are used to model the event-based system. • A state of an object is controlled with the help of an event.

38 Two types of state machine diagrams 1. Behavioral state machine • It captures the behavior of an entity present in the system. • It is used to represent the specific implementation of an element. • The behavior of a system can be modelled using behavioral state machine diagrams. 2. Protocol state machine • These diagrams are used to capture the behavior of a protocol. • It represents how the state of protocol changes concerning the event. It also represents corresponding changes in the system. • They do not represent the specific implementation of an element.

39 Characteristics of State • State represent the conditions of objects at certain points in time. • Objects (or Systems) can be viewed as moving from state to state. • A point in the lifecycle of a model element that satisfies some condition, where some particular action is being performed or where some event is waited.

40 Three types of states • Simple state • They do not have any substrate. • Composite state • These types of states can have one or more than one substrate. • A composite state with two or more substates is called an orthogonal state. • Submachine state • These states are semantically equal to the composite states. • Unlike the composite state, we can reuse the submachine states.

43 Example - Entry / Exit Action illustrates a state machine diagram derived from a Class - "BookCopy"

State chart Diagrams A State chart diagram shows the lifecycle of an object • A state is a condition of an object for a particular time • An event causes a transition from one state to another state • Here is a State chart for a Phone Line object: initial State state transition event

State charts in UML: • Transitions labels have three optional parts: Event [Guard] / Action • Find one of each • Item Received is an event, /get first item is an action, [Not all items checked] is a guard • State may also label activities, e.g., do/check item • Actions, associated with transitions, occur quickly and aren’t interruptible • Activities, associated with states, can take longer and are interruptible • Definition of “quickly” depends on the kind of system, e.g., real-time vs. info system States in ovals, Transitions as arrows

46 Substates • A simple state is one which has no substructure. A state which has substates (nested states) is called a composite state. • Substates may be nested to any level. • A nested state machine may have at most one initial state and one final state. • Substates are used to simplify complex flat state machines by showing that some states are only possible within a particular context (the enclosing state).

Superstates (nested states) • Shows a super-state of three states • Can draw a single transition to and from a super-state

When to develop a state chart? Model objects that have change state in interesting ways: • Devices (microwave oven, Ipod) • Complex user interfaces (e.g., menus) • Transactions (databases, banks, etc.) • Stateful sessions (server-side objects) • Controllers for other objects • Role mutators

Concurrency in state diagrams • 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

51 Example 1: ATM software states at a bank

52 Example 2: Java thread states

Classes as active state machines • Consider whether a class should keep track of its own internal state • Example from Bertrand Meyer: first cut design of LINKED_LIST class class LINKABLE[T] --linkable cells feature value:T; right: LINKABLE[T]; --next cell --routines to change_value, change_right end; class LINKEDLIST[T] feature nb_elements: INTEGER; first_element: LINKABLE[T]; value(i:INTEGER):T is --value of i-th element; loop until it reaches the ith element insert(i:INTEGER; val:T); --loop until it reaches ith element, then insert val delete(i:INTEGER); --loop until it reaches ith element, then delete it • Problems with first-cut? • Getting the loops right is tricky (loops are error-prone) • Redundancy: the same loop logic recurs in all these routines • Reuse leads to inefficiency: suppose I want a routine search • Find an element then replace it: I'll do the loop twice! • Need some way to keep track of the position I found! • Could return the LINKABLE cell found, but this would ruin encapsulation

Classes as active state machines (cont.) • Instead, view LINKED_LIST as a machine with an internal state • Internal state is information stored as attributes of an object • To represent internal state • Cursor: current position in the list • search(item) routine moves the cursor until it finds item • insert and delete operate on the element pointed at by cursor • How does this simplify the code of insert, delete, etc.? • Client has a new view of LINKED_LIST objects: • l.search(item); --find item in l • if not offright then delete end; --delete LINKABLE at cursor • Other routines move cursor: l.back; l.forth

55 State machine vs Flowchart Statemachine FlowChart • It represents various states of a system. • The Flowchart illustrates the program execution flow. • The state machine has a WAIT concept, i.e., wait for an action or an event. • The Flowchart does not deal with waiting for a concept. • State machines are used for a live running system. • Flowchart visualizes branching sequences of a system. • The state machine is a modeling diagram. • A flowchart is a sequence flow or a DFD diagram. • The state machine can explore various states of a system. • Flowchart deal with paths and control flow.

56 When to use State Diagrams? • State diagrams are used to implement real-life working models and object-oriented systems in depth. • These diagrams are used to compare the dynamic and static nature of a system by capturing the dynamic behavior of a system. • Statechart diagrams are used to capture the changes in various entities of the system from start to end. • They are used to analyze how an event can trigger change within multiple states of a system.

57 Activity diagram What is an Activity Diagram? • Activity diagram is defined as a UML diagram that focuses on the execution and flow of the behavior of a system instead of implementation. • It is also called object-oriented flowchart. • Activity diagrams consist of activities that are made up of actions which apply to behavioral modeling technology.

58 What is an Activity? • Activity Diagrams are used to describe activities • Activity Diagrams are useful for describing complicated methods • Activity Diagrams are useful for describing use cases, since, after all, a use case is an interaction, which is a form of activity • Using Activity Diagrams with Use Cases • Start with a coarse-grained use case, which is composed of subordinate use cases • For the complicated subordinate use cases, use Activity Diagrams rather than Use Case Diagrams • Activity Diagrams are like Flow Charts, but Flow Charts are usually limited to sequential activities while Activity Diagrams can show parallel activities as well

59 Notation Description UML Notation Activity Is used to represent a set of actions Action A task to be performed Control Flow Shows the sequence of execution Object Flow Show the flow of an object from one activity (or action) to another activity (or action). Initial Node Portrays the beginning of a set of actions or activities Activity Final Node Stop all control flows and object flows in an activity (or action) Object Node Represent an object that is connected to a set of Object Flows Time Event This refers to an event that stops the flow for a time; an hourglass depicts it. Activity Diagram Notation

60 Activity Diagram Notation Notation Description UML Notation Decision Node (Guards) Represent a test condition to ensure that the control flow or object flow only goes down one path Merge Node Bring back together different decision paths that were created using a decision-node. Fork Node (Synchronization) Split behavior into a set of parallel or concurrent flows of activities (or actions) Join Node (Synchronization) Bring back together a set of parallel or concurrent flows of activities (or actions). Swimlane and Partition A way to group activities performed by the same actor on an activity diagram or to group activities in a single thread

61 Activity Diagrams Notation Start at the top black circle If condition 1 is TRUE, go right; if condition 2 is TRUE, go down At first bar (a synchronization bar), break apart to follow 2 parallel paths At second bar, come together to proceed only when both parallel activities are done

62 Activity Diagrams – Notation (concluded) Activity – an oval Trigger – path exiting an activity Guard – each trigger has a guard, a logical expression that evaluates to “true” or “false” Synchronization Bar – can break a trigger into multiple triggers operating in parallel or can join multiple triggers into one when all are complete Decision Diamond – used to describe nested decisions (the first decision is indicated by an activity with multiple triggers coming out of it)

63 Activity Diagrams – Example 1 Business process for meeting a new client Non-Swinlane Activity Diagram

64 Activity Diagrams – Example 2 Business process for meeting a new client Swinlane Activity Diagram

65 Activity Diagram – Example 3 Use Case: Receiving a Supply

66 Activity Diagram – Example 4 Use Case: Receiving an Order and Receiving a Supply

67 Activity Diagram – Example 5 Swimlanes - Activity Diagrams that show activities by class Arrange activity diagrams into vertical zones separated by lines Each zone represents the responsibilities of a particular class (in this example, a particular department)

68 Activity Diagram – Example 6 Decomposing an Activity An activity can be decomposed into a further Activity Diagram When an Activity Diagram represents a decomposition of a higher-level activity, there can be only one start point

69 When to use activity diagrams? Activity diagram is used to model business processes and workflows. These diagrams are used in software modeling as well as business modeling. Most commonly activity diagrams are used to, • Model the workflow in a graphical way, which is easily understandable. • Model the execution flow between various entities of a system. • Model the detailed information about any function or an algorithm which is used inside the system. • Model business processes and their workflows. • Capture the dynamic behavior of a system. • Generate high-level flowcharts to represent the workflow of any application. • Model high-level view of an object-oriented or a distributed system.

Implementation Diagrams • UML package diagram • When to use package diagrams • Component and Deployment Diagrams • When to use Component and Deployment diagrams 70

UML Package Diagrams What is Package Diagram? • Package diagram, a kind of structural diagram, shows the arrangement and organization of model elements in middle to large scale project. • Package diagram can show both structure and dependencies between sub-systems or modules, showing different views of a system, for example, as multi- layered (aka multi-tiered) application - multi-layered application model. • Package diagram is used to simplify complex class diagrams, you can group classes into packages. A package is a collection of logically related UML elements. 71

 UML Package Diagrams:  Used to illustrate the logical architecture of a system  Layers, subsystems, Java packages  Provides a way to group elements  Different from (more general than) a Java package  Can group anything  Classes, other packages, diagrams, use cases, …  Nesting packages is very common UML Package Diagrams 72

Package Diagram 73 Business model in which the classes are grouped into packages

Basic Concepts of Package Diagram • Package diagram follows hierarchal structure of nested packages. • Atomic module for nested package are usually class diagrams. Few constraints while using package diagrams, they are as follows, • Package name should not be the same for a system, however classes inside different packages could have the same name. • Packages can include whole diagrams, name of components alone or no components at all. 74

Fully qualified Package Diagram 75 Fully qualified name of a package has the following syntax.

UML Package Diagrams Notation • Package - Package is a namespace used to group together elements that are semantically related and might change together. • Package Template - Package can be used as a template for other packages. • Packageable Element - Packageable element is a named element that may be owned directly by a package. 76

Domain::Sales UI::Web UI::Swing Sales Web Swing UI Domain Domain UI Swing Sales Web UML Package Diagram Notations 77

Package Diagram 78 UI Domain Swing Web Sales

Package Diagram - Dependency Notation 79

Structure of Import and Access Relationship 80

Example: Package Diagram for Order Processing subsystem 81

Inheritance • A package with a generalization to another package inherits public and protected elements that are owned or imported by the inherited package. 82

Subsystems • Subsystems are used for system decomposition that can be represented by the parts of a system. • Specification / Realization 83

Modeling Complex Grouping • A package diagram is often used to describe the hierarchical relationships (groupings) between packages and other packages or objects. A package represents a namespace. 84

Visibility of Packages • A public element is visible to elements outside the package, denoted by ‘+’ • A protected element is visible only to elements within inheriting packages, denoted by ‘#’ • A private element is not visible at all to elements outside the package, denoted by ‘-’ 85

Domain UI Swing not the Java Swing libraries, but our GUI classes based on Swing Web Sales Payments Taxes Technical Services Persistence Logging RulesEngine Higher Layer Lower Layer Example 86

 Two key architectural principles  Separation of concerns  Maintaining high cohesion  Separation of concerns:  Discrete layers of distinct, related responsibilities  Clean cohesive separation of duties:  Lower layers: Low-level, general services  Higher layers: More application-specific services  Easier to define boundaries for different developers  Collaboration and coupling from higher to lower layers Layers: Why? 87

 Limiting dependencies between subsystems:  Source code changes ripple throughout the system if many parts are tightly coupled  Example: If application logic is intertwined with UI,  it cannot be distributed to another physical node  It cannot be used with a different UI  General technical services and business logic can be re-used, replaced or moved to another physical node Layers: Why? (continued) 88

UI (AKA Presentation, View) Application (AKA Workflow, Process, Mediation, App Controller) Domain (AKA Business, Application Logic, Model) Technical Services (AKA Technical Infrastructure, High-level Technical Services) Foundation (AKA Core Services, Base Services, Low-level Technical Services/Infrastructure) width implies range of applicability GUI windows reports speech interface HTML, XML, XSLT, JSP, Javascript, ... handles presentation layer requests workflow session state window/page transitions consolidation/transformation of disparate data for presentation handles application layer requests implementation of domain rules domain services (POS, Inventory) - services may be used by just one application, but there is also the possibility of multi-application services (relatively) high-level technical services and frameworks Persistence, Security low-level technical services, utilities, and frameworks data structures, threads, math, file, DB, and network I/O more app specific dependency Business Infrastructure (AKA Low-level Business Services) very general low-level business services used in many business domains CurrencyConverter Typical set of layers for information systems 89

 What if the organization of code into packages changes later on?  Follow a good package naming convention  Use CASE tools to reverse-engineer code into UML packages  What is a tier?  Originally, it meant a logical layer  Common usage today: Physical processing node (or cluster of nodes)  What is a partition?  Division into relatively parallel subsystems for a layer. Some more issues, terms 90

Persistence Security Logging Technical Services POS Inventory Tax Domain Vertical Layers Horizontal Partitions Layers vs. Partitions 91

Domain(s) Technical Services Foundation MySQL Inventory Persistence Namingand Directory Services Web AppFramework Technical Services POS Inventory Domain(s) Foundation Worse mixes logical anddeployment views Better alogical view alogical representation of the needfor dataor services relatedtothese subdomains, abstracting implementation decisionssuch asa database. «component» Novell LDAP UMLnotation: AUMLcomponent, or replaceable, modular part of the physical system UMLnotation: Aphysical databaseintheUML. Don’t mix physical implementation components and logical architecture components 92

 Old terminology  Model: Domain layer (application logic)  View: UI objects (windows, web pages, reports, …)  Model-view separation:  Do not put application logic (such as tax calculation code) in the UI objects  UI objects should only  initialize UI elements,  receive UI events (mouse click, etc.)  delegate requests for application logic on to non-UI objects  Do not connect non-UI objects to UI objects  Example: a Sale object should not have a reference to a JFrame window object  Why not?  What if we want to use the application logic with different windows or multiple views? The Model-View Separation Principle 93

 A relaxation of the model-view principle: the Observer pattern  Domain objects send messages to UI objects viewed only in terms of an interface  Example: PropertyListener interface  Domain object is aware of existence of object implementing PropertyListener  But not of particular object  Notification happens using interface methods What if domain objects need to notify the UI? 94

 Domain objects focus on domain processes  Not on user interfaces  Domain objects and UI can be developed separately  Effect of requirements changes in one component to the other one minimized  New views (UIs) connected to existing domain layer  Multiple simultaneous views (e.g. a GUI and a text- based interface) on the same model object  Domain layer operable without needing UI layer to be on  Basically, modularity. Motivation for the model-view principle 95

When to use package diagrams? Package diagram used to create an overview of a large set of model elements. • To organize a large model • To group related elements • To separate namespaces 96

UML Component and Deployment Diagrams What is Component diagram? • UML Component diagrams are used in modeling the physical aspects of object-oriented systems that are used for visualizing, specifying, and documenting component-based systems and also for constructing executable systems through forward and reverse engineering. • Component diagrams are essentially class diagrams that focus on a system's components that often used to model the static implementation view of a system. 97

Interface Two type of component interfaces • Provided interface symbols with a complete circle at their end represent an interface that the component provides "lollipop" symbol is shorthand for a realization relationship of an interface classifier. • Required Interface symbols with only a half circle at their end represent an interface that the component requires. Example 99

Subsystems • The subsystem classifier is a specialized version of a component classifier. Because of this, the subsystem notation element inherits all the same rules as the component notation element. • The only difference is that a subsystem notation element has the keyword of subsystem instead of component. 100

Port • Ports are represented using a square along the edge of the system or a component. • A port is often used to help expose required and provided interfaces of a component. 101

Relationships • A component diagram is a collection of vertices and arcs and commonly contain components, interfaces and dependency, aggregation, constraint, generalization, association, and realization relationships. 102 Relationships Notation Association Composition Aggregation Constraint Dependency Links

Component Example - Java Source Code 103

Component Diagram Example - C++ Code with versioning 104

Component Diagram Example - Modeling an Executable Release 105

Component Diagram Example - Modeling a Physical Database 106

UML Component and Deployment Diagrams What is Deployment diagram? • A UML deployment diagram is a diagram that shows the configuration of run time processing nodes and the components that live on them. • Deployment diagrams is a kind of structure diagram used in modeling the physical aspects of an object-oriented system. • They are often be used to model the static deployment view of a system (topology of the hardware). 107

Deployment Diagram Notations • Node • 3-D box represents a node, either software or hardware • HW node can be signified with <<stereotype>> • Connections between nodes are represented with a line, with optional <<stereotype>> • Nodes can reside within a node • Dependency • Association relationships. • Notes and constraints. 108

Deployment Diagram Notations 109

Deployment Example - Modeling an Embedded System 110

Deployment Example - Modeling a Client/Server System 111

Deployment Example - TCP/IP Client / Server 112

Deployment Example - Modeling a Distributed System 113

When to use Component and Deployment diagrams? • What existing systems will the newly added system need to interact or integrate with? • How robust does system need to be (e.g., redundant hardware in case of a system failure)? • What and who will connect to or interact with system, and how will they do it • What middleware, including the operating system and communications approaches and protocols, will system use? • What hardware and software will users directly interact with (PCs, network computers, browsers, etc.)? • How will you monitor the system once deployed? • How secure does the system needs to be (needs a firewall, physically secure hardware, etc.)? 114

References • Text Book 1 : Craig Larman, Applying UML and Patterns: An Introduction to Object Oriented Analysis and Design and Iterative Development, Third Edition, Pearson Education, 2005. • Text Book2 : Ali Bahrami, Object Oriented Systems Development, McGraw Hill International Edition, 1999 • https://www.visual-paradigm.com • https://www.tutorialspoint.com • https://medium.com 115

CS8592-OOAD Lecture Notes Unit-3

More Related Content

What's hot

Similar to CS8592-OOAD Lecture Notes Unit-3

More from Gobinath Subramaniam

Recently uploaded

In this document

CS8592-OOAD Lecture Notes Unit-3