Chapter Five–Part IIObject Oriented Design

Component, Deployment, Persistent and UI models

Component Diagram(Architectural Design)

A non-trivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture

or “A component is a physical, replaceable part of a

system that packages implementation, and conforms to and provides the realization of a set of interfaces.”

Components represent tangible, physical things such as an Enterprise JavaBean (EJB) or ActiveX component.

2

Cont’d

Components also captures the inter-relationships between parts of a system

The primary difference with other UML diagrams is that Component diagrams represent the implementation perspective of a system.

The component model shows how classes and interfaces are assigned to components.

You can show the assignment of a class to a component either as physical containment of the class icon in the component icon, or as a «reside» dependency between the component and the class.

3

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.

4

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. 

5

Component and Classes

Similarities 1) both may realize a set

of interfaces 2) both may participate in

dependencies, generalizations and associations

3) both may be nested 4) both may have

instances 5) both may participate in

an interaction

6

differences 1) classes represent

logical abstraction while components represent physical things

2) components represent the physical packaging of logical components and are at a different level of abstraction

3) classes may have attributes and operations whereas components only have operations reachable only through their interfaces

Cont…

Components communicate with each other via interfaces.

When a component offers services (i.e. method declared as public method) to the rest of the system, it adopts (import) a provided interface which specifies the services that can be utilized by other components

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

Developers team can be organized to easily manage the software development process

The component diagram shows the relationship between software components, their dependencies, communication, location and other conditions.

In drawing component diagram one has to keep components cohesive as a component should implement a single, related set of functionality by itself. 

8

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

9

Cont’d

An interface is a collection of operations that are used to specify a service of class or components.

Interfaces:1) Represent the major seam of the system2) Are realized by components in implementation3) Promotes the deployment of systems whose

services are location independent and replaceable

10

Types of Components

1) Deployment: Components necessary and sufficient to form an

executable system such as libraries and EXEs files

2) Work product component: Rest of development process consisting of things like

source code files and data files from which deployment components are created

3) Execution component: Created as a consequence of an executing system

11

Components Stereotypes

1) Executable: Specifies that a component may be executable on a

node

2) Library: Specifies a static or dynamic object library

3) Table: Specifies a component that represents a database table

4) File: Specifies a component that represents a document

containing source code or data

5) Document: Specifies a component that represents a document

12

Steps:

One option to componentized 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

13

Example-One

UML InterfaceUML Component

Scheduler

Planner

GUI

reservations

update

Example-Two

15

Example: Three16

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.

17

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.

18

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.

19

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!"

20

Component diagram for the Courseware Management System

21

Deployment Diagram

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.

22

Cont’d

A processor is a node that has processing capability. It can execute a component.

A device is a node that has no processing capability (at least at the level of abstraction showed).

23

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.

24

Example - Deployment25

Node name: PCRelationship: shows connection between PC and SparcStationHTTP protocol runs on this connection You deploy different components on each node. You deploy IE5 on the PC node

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-One

RuntimeDependency

Compile TimeDependency

:Planner

:PC

:Scheduler

:HostMachine

<<database>>meetingsDB

Example28

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.

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: Model View Controller Database Access

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

33

Cont’d

Deployment diagram for the Courseware Management System34

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.

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.

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.

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. E.g. course to student

For this reason any tables with many to many associations need to be bridged via the addition of an associative table. E.g. schedule as associative

This is one of the differences between design level class diagram and a persistent diagram.

38

Cont…

Relational databases do not support inheritance and designers will be forced to map inheritance structures within object schema to data schema. E.g. Person -- employee

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 sub class to its own table (no super

class).

39

Example40

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.

41

Name Address Contact Name

Credit Rating

creditLimit CreditCard

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.

42

CorporateCustomer PersonalCustomer

Name: String

Address: String

ContactName: String

creditRating: String

creditLimit: Double

Name: String

Address: String

creditCard: LongInt

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 CorporateCustomer PersonalCustomer

Name: String

Address: String

ContactName: String

creditRating: String

creditLimit: Double

Name:string

creditCard: LongInt

Name:string

Cont…

In this third option, the primary key(e.g Name) is 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 Rules47

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

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 and knowledge

48

The user interface

User interfaces should be designed to match the skills, experience and expectations of its anticipated users.

No one best design applicable for all usersSystem 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 manipulationMenu selectionForm fill-inCommand languageNatural language

Interaction styles

Interactionstyle

Main advantages Main disadvantages Applicationexamples

Directmanipulation

Fast and intuitiveinteractionEasy to learn

May be hard to implement.Only suitable where there is avisual metaphor for tasks andobjects.

Video gamesCAD systems

Menuselection

Avoids user errorLittle typing required

Slow for experienced users.Can become complex if manymenu options.

Most general-purpose systems

Form fill-in Simple data entryEasy to learnCheckable

Takes up a lot of screen space.Causes problems where useroptions do not match the formfields.

Stock control,Personal loanprocessing

Commandlanguage

Powerful and flexible Hard to learn.Poor error management.

Operating systems,Command andcontrol systems

Naturallanguage

Accessible to casualusersEasily extended

Requires more typing.Natural language understandingsystems are unreliable.

Informationretrieval systems

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