Tải bản đầy đủ (.pdf) (44 trang)

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

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.08 MB, 44 trang )

More About Static
Modeling
Chapter 6
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

¤NIIT More About Static Modeling 6.3
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:
 Abstract class
 Parameterized class
 Factory class
 Self-linked class
Abstract Class
An abstract class is a class that does not have any direct instances. However, the classes
inherited from an abstract class can have direct instances. An abstract class is used to


define the common features and common behavior of a set of subclasses.
Consider the example of an Automobile class. Some of the attributes of the Automobile
class are:
 Has wheels
 Has an engine
 Has a color
You can derive two subclasses
Bus and Car from the Automobile class. In this case, you
may never be required to create an object of the
Automobile class in your program.
Instead, you may want to use it only because you want it to act as a superclass that defines
the common attributes for the
Car and Bus classes. In this case, you can declare the
Automobile class as an abstract class.
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
6.4 More About Static Modeling ¤NIIT
N
ote
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.
public class List<T>
{
private T[] list = new T[5];
private int n = 0; //No. of elements in list
¤NIIT More About Static Modeling 6.5

public void Add(T input)
{
if (n < 5)
list[n++] = input;
}
}
class TestList
{
private class Product
{

private int prod_id;
private string prod_name;
public Product(int id, string name)
{
prod_id = id;
prod_name = name;
}
}

static void Main()
{
// 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);
}

}
6.6 More About Static Modeling ¤NIIT
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.
Self-Linked Class
A class that has objects, which fulfill more than one role, is called a self-linked class. The
following figure shows the representation of a self-linked class.
Object Diagram for a Self-Linked Class
Consider an example for a self-linked class. In an organization, if an employee, Stevens,
acts as both, project manager and team leader, then the two positions are linked.
List
ElementType: T
Add (T)
¤NIIT More About Static Modeling 6.7
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
 Qualified association
Recursive Aggregation
Recursive aggregation is an association relationship between two objects of the same
class. Consider an employee information system in which
ProjectManager and
Developer are two objects of the Employee class. The developer reports to the project
manager. Therefore, the
ProjectManager and Developer objects of the Employee class
share a recursive aggregation relationship, as shown in the following figure.
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
6.8 More About Static Modeling ¤NIIT
You can also depict recursive aggregation in a class diagram as shown in the following
figure.
Recursive Aggregation in a Class Diagram
Qualified Association
Qualified association is an association relationship that relates an object of a class to a
particular object or a set of objects of another class. You use a value, known as qualifier,
to distinguish the objects of one class from another. A qualifier can be an attribute of the
class.
For example, many students are associated to a university. To distinguish a particular
student from other students, you need to map a particular enrolment number to the
student. For this reason, the
University class uses the Enrolment Number attribute of the
Student class as the qualifier to distinguish a particular student from other students. The

University and Student classes share an association relationship, as shown in the
following figure.
Qualified Association
¤NIIT More About Static Modeling 6.9
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:
 Derived attribute
 Derived association
Derived Attribute
You calculate the value of a derived attribute from the value of the other attributes of the
object. The formula to calculate the derived attribute is represented as a constraint in the
class diagram. For example, the Employee class may have DateOfBirth and Age as
attributes. The
DateOfBirth attribute is used to derive the value of the Age attribute. You
use a dotted straight line with the term,
<<derive>>, to represent the relationship between
the
DateOfBirth and Age attributes.
The following figure shows the representation of a derived attribute in a UML notation.
Derived Attribute
Derived Elements
6.10 More About Static Modeling ¤NIIT
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.
Derived Association
Which of the following is an association relationship between two objects of the same
class?
1. Recursive aggregation
2. Derived association
3. Qualified association
4. Derived attribute
Answer:
1. Recursive aggregation
¤NIIT More About Static Modeling 6.11
N
ote
N
ote
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
6.12 More About Static Modeling ¤NIIT
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:
 The IAcceptCard 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.
 The IAcceptCard 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 AcceptCreditCard
class realizes the interface,
IAcceptCard.
Realization of Interfaces by Using the Lollipop Notation
¤NIIT More About Static Modeling 6.13
N
ote
 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.
6.14 More About Static Modeling ¤NIIT
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
¤NIIT More About Static Modeling 6.15
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

 Object diagram
Activity: Modeling the Static View of the Bank ATM
System
6.16 More About Static Modeling ¤NIIT
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:
 ATM
 ATMCard
 BankCustomer
 Account
 CurrentAccount
 SavingsAccount
 Transaction

 CardScanner
 DisplayScreen
 CashDispenser
¤NIIT More About Static Modeling 6.17
Task 2: Identifying the Attributes and their Visibility
The following table lists the classes with their respective attributes.
Class Attributes Visibility
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
6.18 More About Static Modeling ¤NIIT
Task 3: Identifying the Operations and their Visibility
The following table lists the operations that the classes of the ATM system perform.
<
Class Operations Description
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
SetPin(int) Updates the PIN.
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
information.
¤NIIT More About Static Modeling 6.19
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
account.
CalculateBalance()
Calculates the balance
in the account.
StartTransaction()
Initiates the
transaction.
Transaction
CancelTransaction()

Cancels the
transaction.
AcceptCard()
Accepts/rejects the
ATM card.
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
Typically, the operations of classes are assigned public visibility to enable the

generalization and association relationships among classes. The classes of the ATM
6.20 More About Static Modeling ¤NIIT
N
ote
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:
 CardScanner
 ATMCard
 CashDispenser

The classes, SavingsAccount and CurrentAccount, are the types of the Account class.
They inherit the properties of the Account class to calculate the interest on each account.
For this reason, the Account class has a generalization relationship with the
CurrentAccount and SavingsAccount classes.
The BankCustomer class has an association relationship with the CardScanner,
DisplayScreen, and CashDispenser classes. The ATM class shares a composition
relationship with the CashDispenser, DisplayScreen and CardScanner classes. Similarly,
¤NIIT More About Static Modeling 6.21
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
6.22 More About Static Modeling ¤NIIT
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:
 ICardScanner
 IDisplayScreen
 ICashDispenser
The following diagram depicts the realization relationship between the CardScanner class
and the ICardScanner interface.
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.
¤NIIT More About Static Modeling 6.23
2. Open the Bank_ATM Visio file. The Bank ATM model appears, as shown in the
following figure.
Bank ATM Model
3. Right-click the Iteration2 in the Model Explorer window, and select NewÆStatic
Structure Diagram. The Static Structure-1 page with blank drawing page appears.
4. Click the UML Static Structure (Metric) stencil in the Shapes window.
5. Drag the Class symbol (
) on the drawing page from the UML Static Structure
(Metric) stencil, as shown in the following figure.
UML Class Diagram
6. Double-click the Class1. The UML Class Properties dialog box appears.
6.24 More About Static Modeling ¤NIIT
7. Select Class from Categories section and type ATM in the Name text box, as
shown in the following figure.
UML Class Properties Dialog Box
8. Select Attributes from Categories section in the UML Class Properties dialog box.
9. Type the Location in the Attribute column of Attribute section.
¤NIIT More About Static Modeling 6.25
N
ote
10. Select the C#::string and public from Type and Visibility drop-down list
respectively, as shown in the following figure.
UML Class Properties Dialog Box Showing the Attributes of ATM class
By default the Multiplicity in UML Class Properties dialog box appears 1. You have to
select the multiplicity according to the type of relationship between the classes.
11. Similarly specify the other attributes of the ATM class.

12. Select Operations from Categories section in the UML Class Properties dialog
box.
13. Type Show in the Operation column of Operations section.

×