This document discusses component, deployment, persistent and UI models in object oriented design. It provides details on component diagrams, describing how they represent high-level reusable parts of a system and their inter-relationships. Deployment diagrams depict the physical resources in a system including nodes, components, and connections. Persistent modeling involves mapping object-oriented class diagrams to relational database schemas. User interface design should match user skills/experience and consider human factors like memory, preferences and preventing errors.

1. Chapter Five–Part II
Object Oriented Design
Component, Deployment,
Persistent and UI models

2. Component Diagram
(Architectural Design)
Is another static model
Particularly use full for larger sized development
teams
Is essentially a class diagram focusing on system’s
components
2

3. Cont…
Used to represent the different high-level reusable
parts of a system.
In addition to representing the high-level parts, the
Component diagram also captures the inter-
relationships between these parts.
The primary difference with other UML diagrams
is that Component diagrams represent the
implementation perspective of a system.
 Hence, components in a Component diagram reflect grouping of
the different design elements of a system, for example, classes of
the system.
3

4. Cont…
The component model illustrates the software
components that will be used to build the system.
Component modeling emphasizes the separation
of concerns in respect of the wide-ranging
functionality available throughout a given software
system.
An individual component is a software package or
a module that encapsulates a set of related
functions (or data).
4

5. Cont…
All system processes are placed into separate
components so that all of the data and functions
inside each component are semantically related
(just as with the contents of classes).
Because of this principle, it is often said that
components are modular and cohesive.
Thus, the goal of component model is to distribute
the classes of a system into large scale cohesive
components.
5

6. Cont…
Component diagrams as an architecture-level
artifact, either to model the business software
architecture or the technical software architecture.
A component diagram in the UML depicts how
components are glued (attached) together to form
larger components and or software systems.
A component diagram will also help to describe the
organization of the physical components in a system.
UML component diagrams enable the development
team to model the high-level software components,
and the interfaces to those components.
6

7. Cont…
Components communicate with each other via
interfaces.
When a component offers services to the rest of the
system, it adopts a provided interface which specifies
the services that can be utilized by other components
and how.
The client does not need to know about the inner
workings of the component (implementation) in
order to make use of it.
7

8. Cont…
This principle results in components referred to as
encapsulated
This modeling task of components helps to divide a
large software development task into smaller parts
making it much easier to organize the software
development effort between sub-teams.
The component diagram shows the relationship
between software components, their dependencies,
communication, location and other conditions.
8

9. Cont…
In drawing component diagram one has to keep
components cohesive as a component should
implement a single, related set of functionality by
itself.
This may be the user interface logic for a single user
application, business classes comprising a large-scale
domain concept.
Similarly, a component needs to be attached with user
interface classes to application components.
9

10. Elements of a Component Diagram
Element and its
description
Symbol
Component: The objects
interacting with each other in the
system. Depicted by a rectangle
with the name of the object in it,
preceded by a colon and
underlined.
Interface: An interface describes a group
of operations used or created by components.
Lollipop symbol are used to indicate an
implemented interface.
Relation/Association/Dependency:
Similar to the relation/association used in
class diagrams
10

11. Steps:
one option to componentize your system
 non-business/domain class
 Assign a stereotype “application” by categorizing related UI
classes
 Assign a stereotype “infrastructure” for persistence and security
system components
 domain components
 Identify domain components which is a set of classes that
collaborate among them selves to support cohesiveness
11

12. Example of a component model for student
management system
12

13. Example: Component diagram
13

14. Component diagram: A simple example showing 3 dependent components.
The Web browser communicates customer orders to a shopping cart. The
shopping cart accesses a database for persistence and for transactions.
14

15. Example: Courseware Management System
In the first instance, the application may
seem to be too simplistic to contain
components.
The Courseware Management System has
its own share of components, some implicit
in the design.
15

16. Identifying Components in the Courseware
Management System
The different classes that are modeled for the Courseware
Management System, such as CourseAdministrator, Course,
Topic, CourseCalendar, and Student that fall in the Model
layer need to provide a consistent interface to enable other
classes and components to interact with them and utilize
their services.
We can as well define our own set of simple interface
methods to access these services.
But, to enable our application components to be used by
external applications, we can consider basing the
components on well-defined component standards.
16

17. Cont…
Hence, based on the technology that you use, you would
model these as, maybe Enterprise JavaBeans (EJBs) or
Component Object Model/Distributed Component Object
Model (COM/DCOM) components.
EJB and COM/DCOM are nothing but industry-standard
component models that you can base your application
component design on.
This becomes the "physical" implementation of the logical
class diagram.
An added advantage of basing your application components
on these component models is that your components become
"reusable!"
17

18. Component diagram for the Courseware
Management System
18

19. The diagram shows the different components, such
as CourseAdministrator, Course, Topic, Tutor, and
so forth in the Model layer and how the Controller
layer component interacts with these components.
The diagram also depicts a database access
component that represents a library component
that the Model layer components will use to
interact with a database.
19

20. Deployment Diagram
(Architectural Design)
Captures the configuration of the
runtime elements of the application.
More useful when a system is built and
ready to be deployed.
Should start from the time your static
design is being formalized using class
diagrams.
20

21. Cont…
This deployment diagram then evolves and
is revised until the system is built.
It is always a best practice to have visibility
of what your deployment environment is
going to be before the system is built so that
any deployment-related issues are identified
to be resolved and not crop up at the last
minute.
21

22. Component vs. Deployment Diagrams
Essentially, the components in a
component diagram are contained in the
deployment diagram elements.
Hence, while components provide the
application functionality, the deployment
diagram elements provide the necessary
environment for the components to
execute in.
22

23. Deployment Diagram
Shows the physical relationships among software and
hardware components in the delivered system.
is a good place to show how components and objects
are routed and move around a distributed system.
Each node on a deployment diagram represents some
kind of computational unit—in most cases, a piece of
hardware.
The hardware may be a simple device or sensor, or it
could be a mainframe.
23

24. Cont…
Deployment diagrams depict the physical resources in a
system including nodes, components, and connections.
This model will be used to show how the hardware in the
organization will be connected and which component of
the software will be deployed in hardware.
In other words, a deployment diagram illustrates the
physical deployment of the system into a production (or
test) environment.
It shows where components will be located, on what
servers, machines or hardware.
24

25. Elements of a Deployment Diagram
Element and its
description
Symbol
Node: The element that provides
the execution environment for the
components of a system. Depicted
by a cube with the name of the
object in it, preceded by a colon,
and underlined.
Connection: Similar to the
relation/association used in
class diagrams to define the
interconnection between
nodes.
25

26. How?
Identify scope of the model (a part or a whole)
Identify the distribution architecture (architectural
style)
 Layered , Clinet/Server (2 or 3 teir), MVC, Repository,
Distribute components to nodes
 In case of three tier C/S architecture for example
 Application components (UI) to client machine
 Domain components to the application server
 Persistent components to the database server
26

27. Example of Deployment Diagram
27

28. 28

29. 29

30. Example
Courseware Management System
(using MVC architecture)
The first part in defining the deployment
diagram of the Courseware Management System
is to identify the components that need to be
deployed.
Once we are clear on this, we will identify what
deployment environment will be needed.
the Courseware Management System will
interact with a database to store and retrieve the
data manipulated by the application.
30

31. Cont…
Since components of the Courseware Management
System will be the primary elements represented in
the deployment diagram, we will add the components
from the component diagram to the deployment
diagram.
These components are:
 View
 Controller
 Model
 Database Access
31

32. A good deployment environment is normally well partitioned
to ensure that the application components have proper
resources in their execution environment. Hence, we will
define the nodes of our deployment environment as follows:
 Web Server—represents the Web server that will receive user requests
and send responses from the application.
 Application Server—a process user requests from the Web server and
send application responses back to the Web server is represented by
this node. This node will host the different components of the
Courseware Management System, such as View, Controller, Model,
and Database Access.
 Database Server—host the database used by the components in the
application server node to store and retrieve the data used by the
Courseware Management System.
32

33. Deployment diagram for the Courseware
Management System33

34. Persistent Modeling
(Can be see both as architectural and or Detail)
Persistent data modeling is conceptually similar to
design class modeling in terms of content.
There are minor things to remove and add in
persistent modeling due to the nature of the DBMS
to be used for data management.
The model describes the internal schema of a
database, depicting the data tables, the data columns
of those tables, the unique nature of some functional
columns (attributes) and the relationships between
the tables.
34

35. Cont…
Even though the design so far is object oriented, the
data management part is relational and needs the
object oriented class diagram to be converted to a
persistent diagram.
 Mapping objects to tables
A good start in developing a persistent diagram is to
do a one-to-one mapping of the classes in the system
in to data tables and attributes to columns.
35

36. Cont…
Methods and visibility of neither methods nor
attributes is modeled in persistent model.
All attributes have public visibility from the DBMS
point of view.
In persistent diagram, while uniqueness of each
object is maintained using primary keys
relationships are implemented via the use of
foreign keys.
36

37. Cont…
It is very common to see classes put more than one
object for a single instance of a relationship.
The limitation with Relational data model is that it
does not support many to many relationships to be
modeled as it is.
For this reason any tables with many to many
associations need to be bridged via the addition of an
associative table.
This is one of the differences between design level
class diagram and a persistent diagram.
37

38. Cont…
Relational databases do not support
inheritance and designers will be forced to
map inheritance structures within object
schema to data schema.
There are three possible solutions for
mapping inheritance into a relational
database:
 Map the entire class hierarchy to a single table.
 Map each concrete class to its own table.
 Map each class to its own table.
38

39. Example
39

40. Option One
One can create one table that contains the
attributes of customer class, corporate
customer class and personal customer class
all together.
In such kind of mapping, all information
concerning customers will be put in this table
whether the customer is corporate or
personal customer.
 It is obvious that for some instances, the
rows of the table will have NULL value as
some attributes won’t apply for all.
40
Customer
Name: String
Address: String
ContactName: String
creditRating: String
creditLimit: Double
creditCard: LongInt

41. Option Two
The other approach is to create two tables; one
contacting the attributes of customer class and that
of corporate customer class and another table that
contains attributes of customer class and that of
personal customer class.
41
CorporateCustomer PersonalCustomer
Name: String
Address: String
ContactName: String
creditRating: String
creditLimit: Double
Name: String
Address: String
creditCard: LongInt

42. Cont…
Note here that while the corporate customer
table is without creditCard information the
Personal customer table will not have
contatName, creditRating and creditLimit
as its attributes.
Note also that the attribute Name and
Address exist is both as it is shared through
the superclass
42

43. Option Three
The third option is to create three tables; the first
table would be the customer table with its attribute
and then a table for corporate customer and relate it
to customer table using foreign key and do the same
for the personal customer class.
43
Customer CorporateCustome
r
PersonalCustome
r
Name: String
Address: String
ContactName: String
creditRating: String
creditLimit: Double
creditCard: LongInt

44. Cont…
In this third option, the primary key
selected for customer table need to be
posted in either PersonalCustomer or
CorporateCustomer table to link instances
of the customer class to either of the special
tables.
44

45. Cont…
After the mapping process, data normalization is
required to maintain less duplication in the
database.
Normalization is a process in which data attributes
within a data model are organized to increase the
cohesion of tables and to reduce the coupling
between tables.
The fundamental goal is to ensure that data are
stored in one and only one place.
45

46. Cont…
The normalization process follows the
standard rules of normalization which
progressively remove duplication from the
tables.
While there are almost handful of rules in
the process of normalization, a level up to
third normal form (3NF) is considered
sufficient for most databases.
46

47. Just to recall: Data Normalization Rules
47
Level Rule
First Normal Form
(1NF)
A table in this normal form will not have any repeating rows
and every cell (row-column intersection point) contains single
vale. Identification of a primary key for a table is considered
mandatory for this level of normalization
Second Normal Form
(2NF)
A table must be in its 1NF and that all non primary key
attributes should be fully functionally dependent on the primary
key. If there is any partial dependency, then the non primary
key attribute with partial dependency must be put in a separate
table to avoid duplication.(NB: the primary key should be
composed of more than one attribute to have partial or full
dependency)
Third Normal Form
(3NF)
A table must be in 2NF and that all the non primary key
attributes should only be directly dependent on the primary key.
Any transitive dependency on the primary key via another non
primary key should be put in a separate table.

48. Evolving User Interface Prototype
The user interface design at the design level should
be based on the programming language sought to be
used during implementation.
The user interface design should use the common UI
design issues and the UI requirements of the
organization.
The major criteria for judging quality of a UI is its
usability.
Thus design of UI is a task that demand a wide
variety of skills
48

49. The user interface
User interfaces should be designed to match the
skills, experience and expectations of its anticipated
users.
System users often judge a system by its
interface rather than its functionality.
A poorly designed interface can cause a user to make
catastrophic errors.
Poor user interface design is the reason why so many
software systems are never used.

50. Human factors in interface design
Limited short-term memory
 People can instantaneously remember about 7 items of information.
If you present more than this, they are more liable to make mistakes.
People make mistakes
 When people make mistakes and systems go wrong, inappropriate
alarms and messages can increase stress and hence the likelihood of
more mistakes.
People are different
 People have a wide range of physical capabilities. Designers should
not just design for their own capabilities.
People have different interaction preferences
 Some like pictures, some like text.

51. Design issues in UIs
Two problems must be addressed in interactive
systems design
 How should information from the user be provided to the
computer system?
 How should information from the computer system be
presented to the user?
User interaction and information presentation may
be integrated through a coherent framework such
as a user interface metaphor.

52. Interaction styles
Direct manipulation
Menu selection
Form fill-in
Command language
Natural language

53. Interaction styles
Interaction
style
Main advantages Main disadvantages Application
examples
Direct
manipulation
Fast and intuitive
interaction
Easy to learn
May be hard to implement.
Only suitable where there is a
visual metaphor for tasks and
objects.
Video games
CAD systems
Menu
selection
Avoids user error
Little typing required
Slow for experienced users.
Can become complex if many
menu options.
Most general-
purpose systems
Form fill-in Simple data entry
Easy to learn
Checkable
Takes up a lot of screen space.
Causes problems where user
options do not match the form
fields.
Stock control,
Personal loan
processing
Command
language
Powerful and flexible Hard to learn.
Poor error management.
Operating systems,
Command and
control systems
Natural
language
Accessible to casual
users
Easily extended
Requires more typing.
Natural language understanding
systems are unreliable.
Information
retrieval systems

54. Principles in user interface design and development:
The structure principle:
 the design should organize the UI purposefully,
in meaningful and useful ways that are
recognizable to users
 should put related things together and separating
unrelated things
54

55. Cont…
The simplicity principle:
The design should make simple, common
tasks simple to do,
The design should be communicate clearly
and simply in the user's own language, and
 The design should provide good shortcuts that
are meaningfully related to longer procedures.
55

56. Cont…
The visibility principle:
 The design should keep all needed options and
materials for a given task visible without
distracting the user with extraneous or
redundant information.
 Good designs do not overwhelm users with too
many alternatives or confuse them with
unneeded information.
56

57. Cont…
The feedback principle:
The design should keep users informed of
actions or interpretations, changes of state
or condition, and errors or exceptions
relevant and of interest to the user through
clear, concise, and unambiguous language
familiar to users
57

58. Cont…
The tolerance principle:
 The design should be flexible and tolerant,
reducing the cost of mistakes and misuse by
allowing undoing and redoing,
 The design should also prevent errors wherever
possible by tolerating varied inputs and
sequences and by interpreting all reasonable
actions as reasonable.
58

59. Cont…
The reuse principle:
The design should reuse internal and
external components and behaviors,
maintaining consistency with purpose
rather than merely arbitrary consistency,
thus reducing the need for users to rethink
and remember.
59

60. End of Part II