Chapter Five–Part IIObject Oriented Design

Component, Deployment, Persistent and UI models

Component Diagram(Architectural Design)

Is another static modelParticularly use full for larger sized

development teamsIs 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 DiagramElement and its

descriptionSymbol

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 diagram13

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 DiagramsEssentially, 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 Diagram27

28

29

ExampleCourseware 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 System33

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

Example39

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: StringAddress: StringContactName: StringcreditRating: StringcreditLimit: DoublecreditCard: LongInt

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 PersonalCustomerName: StringAddress: StringContactName: StringcreditRating: StringcreditLimit: Double

Name: StringAddress: StringcreditCard: LongInt

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.

43

Customer CorporateCustomer

PersonalCustomer

Name: StringAddress: String

ContactName: StringcreditRating: StringcreditLimit: Double

creditCard: LongInt

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 Rules47

Level RuleFirst 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.

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