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.
The objective is to explain how a software design may be represented as a set of interacting objects that manage their own state and operations and to introduce various models that describe an object-oriented design.
The objective is to explain how a software design may be represented as a set of interacting objects that manage their own state and operations and to introduce various models that describe an object-oriented design.
Introduction: The Structure of Complex systems, The Inherent Complexity of Software, Attributes of Complex System, Organized and Disorganized Complexity, Bringing Order to Chaos, Designing Complex Systems
The Unified Modeling Language (UML) is a general-
purpose, developmental, modeling language in the field
of software engineering, that is intended to provide a
standard way to visualize the design of a system.
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
Introduction: The Structure of Complex systems, The Inherent Complexity of Software, Attributes of Complex System, Organized and Disorganized Complexity, Bringing Order to Chaos, Designing Complex Systems
The Unified Modeling Language (UML) is a general-
purpose, developmental, modeling language in the field
of software engineering, that is intended to provide a
standard way to visualize the design of a system.
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
Class diagrams are a type of UML (Unified Modeling Language) diagram used in ...NALESVPMEngg
Class diagrams are a type of UML (Unified Modeling Language) diagram used in software engineering to visually represent the structure and relationships of classes in a system.
UML stands for Unified Modelling Language.
UML is a standard language for specifying, visualizing, constructing, and documenting a system in which software represents the most significant part.
UML is different from the other common programming languages like C++, Java, COBOL etc.
UML is a pictorial language used to make software blue prints.
UML can serve as a central notation for software development process. Using UML helps project teams communicate, explore potential designs, and validate the architectural designs of software.
UML diagrams are made using notation of things and relationships.
The building blocks of UML can be defined as:
Things
Relationships
Diagrams
Things: Things are the most important building blocks of UML. Things can be:
Structural
Behavioral
Grouping
Annotational
The Structural things define the static part of the model. They represent physical and conceptual elements. Following are the brief descriptions of the structural things.
Class: Class represents set of objects having similar responsibilities.
Interface: Interface defines a set of operations which specify the responsibility of a class.
Collaboration: Collaboration defines interaction between elements.
Use case: Use case represents a set of actions performed by a system for a specific goal.
Component: Component describes physical part of a system.
Node: A node can be defined as a physical element that exists at run time.
A behavioral thing consists of the dynamic parts of UML models. Following are the behavioral things:
Interaction: Interaction is defined as a behavior that consists of a group of messages exchanged among elements to accomplish a specific task.
State machine: State machine is useful when the state of an object in its life cycle is important. It defines the sequence of states an object goes through in response to events. Events are external factors responsible for state change.
How to Create Map Views in the Odoo 17 ERPCeline George
The map views are useful for providing a geographical representation of data. They allow users to visualize and analyze the data in a more intuitive manner.
The Art Pastor's Guide to Sabbath | Steve ThomasonSteve Thomason
What is the purpose of the Sabbath Law in the Torah. It is interesting to compare how the context of the law shifts from Exodus to Deuteronomy. Who gets to rest, and why?
Model Attribute Check Company Auto PropertyCeline George
In Odoo, the multi-company feature allows you to manage multiple companies within a single Odoo database instance. Each company can have its own configurations while still sharing common resources such as products, customers, and suppliers.
The French Revolution, which began in 1789, was a period of radical social and political upheaval in France. It marked the decline of absolute monarchies, the rise of secular and democratic republics, and the eventual rise of Napoleon Bonaparte. This revolutionary period is crucial in understanding the transition from feudalism to modernity in Europe.
For more information, visit-www.vavaclasses.com
Instructions for Submissions thorugh G- Classroom.pptxJheel Barad
This presentation provides a briefing on how to upload submissions and documents in Google Classroom. It was prepared as part of an orientation for new Sainik School in-service teacher trainees. As a training officer, my goal is to ensure that you are comfortable and proficient with this essential tool for managing assignments and fostering student engagement.
The Roman Empire A Historical Colossus.pdfkaushalkr1407
The Roman Empire, a vast and enduring power, stands as one of history's most remarkable civilizations, leaving an indelible imprint on the world. It emerged from the Roman Republic, transitioning into an imperial powerhouse under the leadership of Augustus Caesar in 27 BCE. This transformation marked the beginning of an era defined by unprecedented territorial expansion, architectural marvels, and profound cultural influence.
The empire's roots lie in the city of Rome, founded, according to legend, by Romulus in 753 BCE. Over centuries, Rome evolved from a small settlement to a formidable republic, characterized by a complex political system with elected officials and checks on power. However, internal strife, class conflicts, and military ambitions paved the way for the end of the Republic. Julius Caesar’s dictatorship and subsequent assassination in 44 BCE created a power vacuum, leading to a civil war. Octavian, later Augustus, emerged victorious, heralding the Roman Empire’s birth.
Under Augustus, the empire experienced the Pax Romana, a 200-year period of relative peace and stability. Augustus reformed the military, established efficient administrative systems, and initiated grand construction projects. The empire's borders expanded, encompassing territories from Britain to Egypt and from Spain to the Euphrates. Roman legions, renowned for their discipline and engineering prowess, secured and maintained these vast territories, building roads, fortifications, and cities that facilitated control and integration.
The Roman Empire’s society was hierarchical, with a rigid class system. At the top were the patricians, wealthy elites who held significant political power. Below them were the plebeians, free citizens with limited political influence, and the vast numbers of slaves who formed the backbone of the economy. The family unit was central, governed by the paterfamilias, the male head who held absolute authority.
Culturally, the Romans were eclectic, absorbing and adapting elements from the civilizations they encountered, particularly the Greeks. Roman art, literature, and philosophy reflected this synthesis, creating a rich cultural tapestry. Latin, the Roman language, became the lingua franca of the Western world, influencing numerous modern languages.
Roman architecture and engineering achievements were monumental. They perfected the arch, vault, and dome, constructing enduring structures like the Colosseum, Pantheon, and aqueducts. These engineering marvels not only showcased Roman ingenuity but also served practical purposes, from public entertainment to water supply.
This is a presentation by Dada Robert in a Your Skill Boost masterclass organised by the Excellence Foundation for South Sudan (EFSS) on Saturday, the 25th and Sunday, the 26th of May 2024.
He discussed the concept of quality improvement, emphasizing its applicability to various aspects of life, including personal, project, and program improvements. He defined quality as doing the right thing at the right time in the right way to achieve the best possible results and discussed the concept of the "gap" between what we know and what we do, and how this gap represents the areas we need to improve. He explained the scientific approach to quality improvement, which involves systematic performance analysis, testing and learning, and implementing change ideas. He also highlighted the importance of client focus and a team approach to quality improvement.
Welcome to TechSoup New Member Orientation and Q&A (May 2024).pdfTechSoup
In this webinar you will learn how your organization can access TechSoup's wide variety of product discount and donation programs. From hardware to software, we'll give you a tour of the tools available to help your nonprofit with productivity, collaboration, financial management, donor tracking, security, and more.
How to Split Bills in the Odoo 17 POS ModuleCeline George
Bills have a main role in point of sale procedure. It will help to track sales, handling payments and giving receipts to customers. Bill splitting also has an important role in POS. For example, If some friends come together for dinner and if they want to divide the bill then it is possible by POS bill splitting. This slide will show how to split bills in odoo 17 POS.
1. 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.
3. Interaction Diagrams
Illustrates how objects interact via messages
2 diagram types:
Sequence Diagram
(fence format)
Collaboration Diagram
(graph or network)
3
4. 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
5. 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
6. 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
32. 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
33. 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. 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. 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. 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. 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. 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. 43
Example - Entry / Exit Action
illustrates a state machine diagram derived from a Class - "BookCopy"
44. 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
45. 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. 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).
47. Superstates (nested states)
• Shows a super-state of
three states
• Can draw a single
transition to and from a
super-state
49. 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
50. 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
53. 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
54. 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. 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. 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. 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. 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. 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. 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. 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. 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. 63
Activity Diagrams – Example 1
Business process for
meeting a new client
Non-Swinlane
Activity Diagram
64. 64
Activity Diagrams – Example 2
Business process for
meeting a new client
Swinlane Activity
Diagram
67. 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. 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. 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.
70. Implementation Diagrams
• UML package diagram
• When to use package diagrams
• Component and Deployment Diagrams
• When to use Component and Deployment diagrams
70
71. 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
72. 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
74. 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
75. Fully qualified Package Diagram
75
Fully qualified name of a package has the following syntax.
76. 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
82. Inheritance
• A package with a generalization to another package inherits
public and protected elements that are owned or imported by
the inherited package.
82
83. Subsystems
• Subsystems are used for system decomposition that can be
represented by the parts of a system.
• Specification / Realization
83
84. 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
85. 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
86. 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
87. 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
88. 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
89. 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
90. 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
92. 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
93. 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
94. 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
95. 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
96. 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
97. 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
99. 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
100. 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
101. 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
102. 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
107. 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
108. 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
114. 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
115. 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