Arch06 3 2
Arch06 3 2
Arch06 3 2
Architectural Views
Part 3.2 Logical View
1. Overview
2. Static Structures
3. Interactions
4. Dynamic Behavior
5. Example: Logical View for the ATM
Classes, interfaces,
collaborations Use cases Process,Threads
Use Case View
Implementation Deployment View
View
1
Source, binary, executable components Nodes
1. Overview
-The purpose of the logical view is to specify the functional
requirements of the system. The main artifact of the logical view
is the design model:
÷The design model gives a concrete description of the functional
behavior of the system. It is derived from the analysis model.
÷The analysis model gives an abstract description of the system
behavior based on the use case model.
÷In general only the design model is maintained in the logical view,
since the analysis model provides a rough sketch, which is later
refined into design artifacts.
Design Model
-The design model consists of collaborating classes, organized
into subsystems or packages.
-Artifacts involved in the design model may include:
÷class, interaction, and state diagrams
÷the subsystems and their interfaces described using package diagrams 2
2. Static Structures
Notion of Class
a description of a group of objects with:
÷common properties (attributes)
÷common behavior (operations)
÷common relationships to other objects, and common semantics.
Visibility:
+ public
# protected
- private
3
Extensibility Mechanisms
•Stereotype
•Tagged value
•Constraint
Notion of Stereotype
•provides the capability to create a new kind of modeling element.
•we can create new kinds of classes by defining stereotypes for classes.
•the stereotype for a class is shown below the class name enclosed in
guillemets (<< >>).
•examples of class stereotypes: exception, utility etc.
4
Boundary, Entity, and Control Classes
The Rational Unified Process advocates for finding the classes for a
system by looking for boundary, control, and entity classes.
Entity classes:
•model information and associated behavior that is generally long lived
•may reflect a real-world entity, or may be needed to perform tasks internal
to the system
•are application independent: may be used in more than one application.
Boundary classes:
•handle the communication between the system surroundings and the inside
of the system
•can provide the interface to a user or another system
Control classes:
•model sequencing behavior specific to one or more use cases.
•typically are application-dependent classes.
5
Relationships
6
Class Diagram
Purpose
•Provide a picture or view of some or all the classes/interfaces in the model
•Static design view of the system
* *
Object Diagram
Shows a set of objects and their relationships at a point in time
Shows instances and links
Built during analysis and design (address the static design view)
Purpose
•Illustrate data/object structures
•Specify snapshots
8
Package Diagrams
Package: Independent unit of functionality that consists of a
collection of related classes and/or other subsystems.
•Offer interfaces and uses interfaces provided by other subsystems.
•In the UML, packages or subsystems are represented as folders:
<<package>>
People
Information
Dependency Relationships: provides and uses relationships
•Uses relationship, shown as a dashed arrow to the used interface.
•Provides relationship, shown as a straight line to the provided interface.
Transfer
<<package>> <<package>>
DirectBanking AccountService
9
3. Interactions
Use Case Realization
the functionality of a use case is defined by describing the
scenarios involved.
÷a scenario is an instance of a use case: it is one path through the flow of events
for the use case.
÷each use case is a web of scenarios: primary scenarios (the normal flow for the
use case) and secondary scenarios (the what-if logic of the use case).
÷scenarios help identify the objects, the classes, and the object interactions needed
to carry out a piece of the functionality specified by the use case.
10
Sequence Diagram
•Shows object interactions arranged in time sequence
•Purpose
–Model flow of control
–Illustrate typical scenarios
•Depicts the objects and classes involved in the scenario and the sequence of
messages exchanged between the objects needed to carry out the functionality
of the scenario.
11
Communication Diagram
•Shows object interactions organized around the objects and their links
to each other (Arranged to emphasize structural organization)
•Purpose
–Model flow of control
–Illustrate coordination of object structure and control
•Represent an alternate way to describe a scenario
13
State:
•a condition during the life of an object when it satisfies some condition,
performs some action, or waits for an event
•found by examining the attributes and links defined for the object
•represented as a rectangle with rounded corners
Transitions:
•represents a change from an originating state to a successor state (that
may be the same as the originating state).
•may have an action and/or a guard condition associated with it, and
may also trigger an event. 14
Activity Diagram
•Captures dynamic behavior (activity-oriented)
•Behavior that occurs within the state is called an activity: starts when the state
is entered and either completes or is interrupted by an outgoing transition.
•Purpose
-Model business workflow
-Model operations
15
5. Example: Logical View for the ATM
- Is derived from architecturally significant use cases defined in the use case view
ATM System
Deposit
<<include>> <<extend>>
<<include>>
Query Validation
<<include>>
Customer <<include>>
Withdrawal
Check PIN
Maintain
Foreign 16
Customer Bank
Officer
Communication Diagram: Withdraw Money Use case
2:requestWithdrawal
:CashierInterface :WithdrawalService
1:identify
17
Communication Diagram: Deposit Use Case
:CashierInterface 2:requestDeposit
1:identify
:DepositService 5: deposit
3:putMoney
Customer
:MoneyReceptor :Account
4:moneyReception
18
Communication Diagram: Transfer Use Case
A1:Account
1:identify :CashierInterface
4:transfer
2:requestTransfer 3:validate
A2:Account
:TransferService
19
Class Diagram <<control>>
<<boundary>> WithdrawalService
Dispenser
requestWithdrawal()
authorizeDispense()
<<control>> <<entity>>
<<boundary>> TransferService Account
CashierInterface
requestTransfer() validate()
identify() deposit()
transfer()
withdraw()
<<control>>
DepositService
<<boundary>>
MoneyReceptor
requestDeposit()
putMoney() moneyReception()
20
(Refined) Class diagram providing a view of the classes involved
in withdraw Money use case (design model)
CardReader CashierInterface WithdrawalService
Display Transaction
Manager
KeyPad Client
Customer Manager Persistent
Class
WithdrawalService
Dispenser
Feeder
Account
Cash Manager
Dispenser Counter Account
Sensor
Dispenser Account
21
Traceability (Withdraw use case)
Analysis
CashierInterface Dispenser WithdrawalService Account
<<trace> <<trace>>
Design <<trace>> <<trace>>
Display Cash
Counter
KeyPad
Withdrawal
Client Dispenser Service
CardReader Manager Sensor
Transaction Account
Dispenser Manager
Feeder
Persistent Account
Class Manager
22
A Scenario of the Withdraw Money Use Case (Design Model)
:Client :Cash :Transaction
:CardReader :Display :KeyPad Manager Counter Manager
Specify amount
Amount (A)
Request cash availability (A)
23
…
State Transition Diagram for Class Account
AccountState
debit [amount>balance]/balance-=amount
deposit [amount<1-balance]/
balance+=amount-1
[amount ⁄ balance]/balance-=amount
withdraw
[amount×1-balance]/
credit
balance+=amount-1
deposit/balance+=amount
<<package>>
ATM Interface
Classes Packages
<<package>>
UDisplay CardReader, Display, UDisplay/ATM Interface
KeyPad, ClientMgr
DispenserFeeder, Dispenser/ATM Interface
<<package>> DispenserSensor, CashCounter
Dispenser
WithdrawalService, TransactionMgt
TransactionMgr
Account, PersistentClass, AccountMgt
AccountMgr
25
Structuring Using Layer Architectural Pattern
<<layer>>
Application-specific
Packages Layers
System-software
<<layer>>
Middleware
<<layer>>
System-software
26
<<package>> Application-specific layer
ATM Interface
<<package>> <<package>>
Application-general layer
Transaction Mgt Account Mgt
<<package>> <<package>>
Java.awt Java.rmi
Middleware layer
<<package>>
Java Virtual Machine
STATES
UML use case UML Activity UML State UML
descriptions and diagrams Diagrams Diagrams Package
<<subsystem>> <<subsystem>>
Application-general layer
Diagrams
Transaction Mgt Account Mgt
CLASS STRUCTURE
<<subsystem>> <<subsystem>>
Requirements
Java.awt Java.rmi UML
Specification UML Class UML Object Component
Diagrams Diagrams Middleware layer
Diagrams
Scenarios
<<subsystem>>
Java Virtual Machine
INTERACTIONS
UML
UML Sequence UML
Communication
Diagrams Deployment
Diagrams
Diagrams