Giới thiệu về mô hình hóa tĩnh ppsx

Abstract Class Parameterized Class A parameterized class, also called template class, provides a mechanism that enables you to use operations and classes to work with different data ty

More About Static

Static modeling uses class diagrams and object diagrams

to represent the static constituents of a software system

These diagrams use various types of notations for

depicting different types of classes and the relationships

between them In addition, these diagrams use special

types of constructs called interfaces

This chapter discusses the various types of classes and

examines the relationships between them It also explains the concept of interfaces and the different UML notations used to depict interfaces

In this chapter, you will learn to:

 Identify various types of classes and the relationships between them

 Identify Interfaces

Objectives

After you identify the classes from the problem statement or use cases, you can classify the identified classes into various types This enables you to make the software system reusable and manageable

UML enables you to classify classes into the following types:

Consider the example of an Automobile class Some of the attributes of the Automobile class are:

The UML notation for an abstract class is same as that of a simple class However, the name of the class is italicized to indicate that the class is an abstract class

Identifying Types of Classes and Relationships

Between Classes

Types of Classes

Note

The following figure depicts the UML notation for an abstract class

Abstract Class

Parameterized Class

A parameterized class, also called template class, provides a mechanism that enables you

to use operations and classes to work with different data types

A parameterized class consists of type parameters that are unbounded, which means that the data types of the parameters are not defined in the parameterized class

You cannot create the objects of a parameterized class To use the functions defined in the parameterized class, you need to realize the parameterized class by using classes The type parameters are bounded to the class that realizes the parameterized class In other words, the datatypes of the type parameters are defined in the classes that realize the parameterized class

Consider an example where you need to create a class for maintaining a list of items It should be possible to use the same class to maintain a list of integers, a list of strings, or a list of products In such a case you can create the class as a parameterized class

In the preceding example, each entry corresponding to a product will include the

product ID and the product name

To use the functions of the parameterized class, you need to pass different types of objects

to instantiate the List class An example of a parameterized class is C# Generics The following program segment in C# illustrates the realization of the List parameterized class

by using three different types, integer, string, and Product, where Product is a

user-defined class containing two attributes, prod_id and prod_name

private int prod_id;

private string prod_name;

public Product(int id, string name)

// Declare a list of type int

List<int> list1 = new List<int>();

list1.Add(20);

list1.Add(30);

list1.Add(45);

// Declare a list of type string

List<string> list2 = new List<string>();

list2.Add("hello");

list2.Add("welcome");

list2.Add("bye");

// Declare a list of type ExampleClass

List<Product> list3 = new List<Product>();

Product p1 = new Product (1, "Baking Powder");

Product p2 = new Product (2, "Salt");

Product p3 = new Product (3, "Sugar");

list3.Add(p1);

list3.Add(p2);

list3.Add(p3);

You represent a parameterized class by a dashed rectangle that you place on the upper right corner of the class The dashed rectangle contains the list of formal parameters using the syntax, name: type The following figure shows the class, List, with its formal

parameters of the type, P

Parameterized Class

Factory Class

A class that has multiple objects having the same attribute values is known as a factory class To represent the multiple objects of a factory class, you can use a symbol of

overlapping rectangles, as shown in the following figure

Object Diagram for Factory Class

An example of a factory class is an EJB factory class that creates multiple instances of EJB in an instance pool of the J2EE middle tier server Multiple instances are used

whenever requests for the same arrive at the server

The instances of Stevens in the Employee class are linked, as shown in the following figure

Example of a Self-Linked Class

In addition to generalization, dependency, and association relationships, you can also represent the following relationships among classes and objects:

Recursive Aggregation in an Object Diagram

In the preceding figure, an object diagram depicts the recursive aggregation among the objects of the Employee class

Recursive Aggregation and Qualified Association

Relationships

You can also depict recursive aggregation in a class diagram as shown in the following figure

Recursive Aggregation in a Class Diagram

In UML, a derived element, as the name suggests, can be derived from one or more other elements of the same type It is logically redundant to depict a derived element in a design model However, you can use the derived elements to model an explicit detailed design

To represent a derived element in a class diagram, you place a slash (/) before the name of the element A derived element can be of two types:

The following figure shows the representation of a derived attribute in a UML notation

Derived Attribute

Derived Elements

Just a minute:

Derived Association

You can deduce a derived association from the other associations in a class diagram For example, the Employee class is associated to the Department class and the Department class is a part of the Organization class Therefore, the Employee class is also associated

to the Organization class You can derive this association from the associations between the Department and Employee classes and the Organization and Department classes The following figure shows the representation of a derived association in a UML notation

Note

Note

An interface is a collection of operations that are used to represent the services provided

by a class or component An interface provides the declaration of only the public methods and does not provide their implementation As a result, interfaces do not contain

attributes

Type classes can contain attributes and represent a group of objects in a similar

domain Conversely, an interface consists of only public methods and represents the

specification of a service

Interfaces are similar to classes Like classes, interfaces are also contained in a package However, you cannot create objects of interfaces To create an interface, you need to identify the methods that are interdependent and group them using interfaces This

enhances the maintenance and reusability of the system

In UML, an interface is represented as a circle Each interface has a unique name that is prefixed with the name of the package in which it is contained The following figure shows an interface with the package name

Interface Name

Names of interfaces are usually prefixed with an I, to distinguish them from other

elements, such as classes

Identifying Interfaces

Creating Interfaces

You can also represent an interface in the class notation, which contains the interface name by using the keyword, <<interface>>, and the method declarations The following figure shows the interface, IAcceptCard, with its method declarations

IAcceptCard Interface with Methods

Like classes, interfaces participate in all the relationships, such as generalization and association In addition, interfaces participate in the realization relationship Multiple classes or components can realize interfaces to provide the functions specified in the interfaces

Consider the example of the CSS again You need to define two classes,

AcceptCreditCard and AcceptECreditCard, to define the functions to accept a credit card and an e-credit card from customers These classes should realize a common

interface, IAcceptCard, because:

„ TheIAcceptCard provides the specification to the user interface of the CSS

„ The specification of both the classes, AcceptCreditCard and AcceptECreditCard,remain the same but differ in implementation

„ TheIAcceptCard enables you to add another card, such as debit card, if required in the later stages, without the need to modify any of the existing classes

UML provides two notations to realize an interface:

„ Lollipop notation: Shows the interface as a circle and displays the class that realizes

the interface in a rectangle The details of the operations contained in the interface or the class are not shown The following figure shows how the AcceptCreditCardclass realizes the interface, IAcceptCard

Realization of Interfaces by Using the Lollipop Notation

Note

„ Dashed arrow notation: Depicts an interface as a class with the help of the

<<interface>> keyword The diagram also specifies the operations of the interfaces

A dashed arrow connects the class that realizes the interface with the interface The following figure shows how the AcceptCreditCard class uses the dashed arrow notation to realize the interface, IAcceptCard

Realization of Interfaces Using the Dashed Arrow Notation

You use the lollipop notation when a class that realizes the interface overloads the

same methods as declared in the interface You use the dashed arrow notation when

either a few operations are overloaded or additional operations are declared in the

class that realizes the interface

An abstract class and an interface both provide the specification of methods and do not allow you to create instances directly The derived classes provide the implementations of the methods that the abstract classes and interfaces specify Apart from this common behavior, there are some differences between an abstract class and an interface such as:

„ Interfaces enable you to implement multiple inheritance because a class can implement more than one interface However, abstract classes do not support multiple inheritance A class cannot inherit more than one abstract class

„ An abstract class contains attributes and methods that can be public, private, or protected An interface consists of only methods

„ An abstract class may provide the definition of some of its methods, but interfaces do not provide any definitions

„ An abstract class is used in the same package as opposed to an interface that can be realized across multiple packages

You can use an abstract class when the derived classes have common attributes and

operations For example, in the CSS, you can create the classes, USD and Euro, to

provide the functions to accept cash from the customer in Euro and USD You can derive these classes from an abstract class, AcceptCash, because of the following reasons:

„ Euro and USD classes share common methods, such as CalculateTotalAmount(),

to calculate the total amount entered by the customer

„ The Euro class and USD classes have similar attributes, such as the name of the issuing authority and the counterfeit notes found

„ You can use the AcceptCash abstract class to derive another currency class to provide the functions to accept another currency

Differentiating Abstract Classes from Interfaces

Problem Statement

Janes Technology has been assigned the task to create a prototype for the InfoSuper bank ATM system The project manager of Janes Technology has created the following use case diagram for the prototype after gathering requirements from the InfoSuper bank

Use Case Diagram for the Prototype

The preceding use case diagram depicts that the customers of the InfoSuper bank can have savings and current accounts The ATM system allows customers to withdraw cash after it validates the ATM card and PIN of customers The ATM system also enables customers to change the PIN and obtain a transaction summary

To model the static view of the prototype, you need to create the following diagrams:

„ Class diagram

Activity: Modeling the Static View of the Bank ATM

System

Prerequisite: To perform this activity, you will need the BANK_ATM.vsd file, which

you created in the activity “Refining the System Definition for the Infosuper Bank ATM System” of Chapter 4

Solution

To model the static view of the prototype of the InfoSuper bank ATM system, you need to perform the following tasks:

1 Identify the classes for the prototype

2 Identify the attributes and their visibility

3 Identify the operations and their visibility

4 Identify the relationships among classes

5 Identify interfaces and their realization relationships

6 Create a Class diagram

7 Create an Object diagram

Task 1: Identifying the Classes for the Prototype

The classes for the prototype can be identified on the basis of the Use Cases and Actors of the prototype for the InfoSuper bank ATM system For the implementation, it is necessary

to map all the operations of classes to the functions of Use Cases, to implement the functions of the Use Cases in the implementation phase The classes of the ATM system are:

Task 2: Identifying the Attributes and their Visibility

The following table lists the classes with their respective attributes

ATM Location

BranchName

Public Public ATMCard PIN

Card_Id Acc

Private Private Private BankCustomer CustomerName

Address PhoneNumber Email Card Acc

Private Private Private Private Private Private Account AccountNumber

Balance Trans

Private Private Private CurrentAccount InterestRate Private

SavingsAccount InterestRate Private

Transaction Date

Amount Deposit

Private Private Private CardScanner No attribute –

DisplayScreen No attribute –

CashDispenser AvailableCash Private

Classes with their Respective Attributes

Task 3: Identifying the Operations and their Visibility

The following table lists the operations that the classes of the ATM system perform

<

ATM Show() Displays the location

and branch name of the ATM

GetPin() Accepts the PIN

entered by the customer and verifies

it

GetAccount() Fetches the account

information based on the card_ID and PIN

ATMCard

InsertCard() Prompts the customer

to insert the ATM card

SelectTransaction() Selects a transaction

from a list of transactions

EnterPin() Prompts the customer

to enter the PIN

ChangePin() Invokes the PIN change

request Enters the new PIN

WithdrawCash() Invokes the cash

withdrawal operation

BankCustomer

RequestTransactionSummary() Requests for a

transaction summary

CalculateInterest() Calculates the interest

for the account This is

an abstract operation

Account

UpdateAccount() Updates the account

Class Operations Description

VerifiyWithdrawalAmount() Verifies if the amount

to be withdrawn is less than the account balance amount

CurrentAccount CalculateInterest() Calculates the interest

for the current account SavingsAccount CalculateInterest() Calculates the interest

for the savings account GetAccountBalance() Gets the balance of the

ReadCard() Reads the Card_Id

associated with the ATM card

EjectCard() Ejects the ATM card

CardScanner

ValidatePIN() Validates the pin

Prompt() Prompts the respective

screen according to the request

DisplayScreen

AcceptInput() Accepts the required

input on the displayed screen

SupplyCash() Supplies the verified

amount as cash

CashDispenser

GenerateReceipt() Generates a receipt for

the cash dispensed

Classes and their Operations in the ATM System

Note

system need to interact with each other to achieve functions Therefore, all the operations

of the ATM system classes have been assigned public visibility

The Account class only declares the CalculateInterestRate() operation Therefore, it is

an abstract class The SavingsAccount and CurrentAccount classes implement the

functions of the CalculateInterestRate() operation

Task 4: Identifying the Relationships among Classes

More than one customer of the InfoSuper bank can use the card scanner, cash dispenser, and display screen Similarly, a bank customer may have more than one account in InfoSuper bank The one-to-many multiplicity relationship exists among the following pairs of classes of the InfoSuper bank ATM system:

„ CardScanner and BankCustomer

„ CashDispenser and BankCustomer

„ DisplayScreen and BankCustomer

„ BankCustomer and Account

„ ATM and BankCustomer

„ Account and Transaction

„ DisplayScreen and Transaction

„ Account and CashDispenser

The one-to-one relationship exists among the following classes of the InfoSuper bank ATM system:

„ ATM and CardScanner

„ CardScanner and DisplayScreen

The self-linked classes are:

the BankCustomer class shares a composition relationship with the ATMCard class The BankCustomer class also shares the aggregation relationship with the Account and

Transaction classes

The following diagram depicts the InfoSuper bank ATM system

Class Diagram for the Cash Withdrawal Use Case of the InfoSuperBank ATM System

Task 5: Identifying Interfaces and Realization Relationship

The InfoSuper bank ATM system needs the following interfaces that correspond to the CardScanner, DisplayScreen, and CashDispenser classes:

Relationship between CardScanner Class and ICardScanner Interface

Similarly, the CashDispenser class and ICashDispenser interface, the DisplayScreen class and IDisplayScreen interface shares a realization relationship

Task 6: Creating a Class Diagram

To create a Class diagram, you need to perform the following tasks:

1 Create classes and assign attributes and operations

2 Create relationships among classes

Task 6.1: Creating Classes and Assigning Attributes and Operations

To create classes, you need to perform the following steps:

1 Select StartÆAll ProgramsÆMicrosoft OfficeÆMicrosoft Office Visio for

Enterprise Architects.