Chapter Five–Part II

Object Oriented Design

Component, Deployment, Persistent

and UI models
 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
 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
 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
 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
 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
 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
 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
 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
 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
 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
 Example of a component model for student management
system

12
 Example: Component diagram

13
 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
 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
 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
 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
 Component diagram for the Courseware
Management System

18
  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
 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
 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
 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
 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
 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
 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
 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
 Example of Deployment Diagram

27
28
29
 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
 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
 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
 Deployment diagram for the Courseware
Management System

33
 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
 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
 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
 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
 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
 Example

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

40
 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.

CorporateCustomer PersonalCustomer
Name: String Name: String
Address: String Address: String
ContactName: String creditCard: LongInt
creditRating: String
creditLimit: Double

41
 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
 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.

Customer CorporateCustomer PersonalCustomer

Name: String ContactName: String creditCard: LongInt
Address: String creditRating: String
creditLimit: Double

43
 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
 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
 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
 Just to recall: Data Normalization Rules
Level Rule
First Normal Form A table in this normal form will not have any repeating rows
(1NF) 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 A table must be in its 1NF and that all non primary key
(2NF) 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 A table must be in 2NF and that all the non primary key
(3NF) 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.
47
 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
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.
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.
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.
Interaction styles
 Direct manipulation
 Menu selection
 Form fill-in
 Command language
 Natural language
Interaction styles
Interaction Main advantages Main disadva ntages Application
style examples
Direct Fast and intuitive May be hard to implement. Video games
manipulation interaction Only suitable wher e there is a CAD systems
Easy to learn visual metapho r for tasks and
objects.
Menu Avo ids user error Slow for experienced users. Most general-
selection Little typing required Can become complex if many purpose systems
menu options.
Form fill-in Simple data entry Takes up a lot of screen space. Stock control,
Easy to learn Causes problems whe re user Personal loan
Checkable options do not match the form processing
fields.
Command Powerful and flexible Hard to learn. Operating systems,
language Poor error manage ment. Command and
control systems
Natural Accessible to casual Requires more typing. Information
language users Natural language und erstanding retrieval systems
Easily extended systems are unreliable.
 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
 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
 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
 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
 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
 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
End of Part II