Object Oriented Analysis and Design
Using the UML
Architectural Design:
Reuse and
Security Mechanism
OOAD Using the UML - Appendix: Security Mechanism, v 4.2
Copyright  1999 Rational Software, all rights reserved
1
 Will only go through first part – around 15
slides.
OOAD Using the UML - Appendix: Security Mechanism, v 4.2
Copyright  1999 Rational Software, all rights reserved
2
Example: Reuse: Security Mechanism
Here we are reverse engineering existing components into the Design Model and from
Implementation Model. (Three reusable components –
one is a GUI framework; other two support security on the server.)
Packages in the system
Representation of components being developed that
Reused components
might depend upon the
in
the
Design
Model
from the Implementation
security packages.
Model
UIFramework
.dll
GUI Framework
ISecureUser
(from Secure Interfaces)
UserContext
RemoteObject
Your GUI
Actual interface shown on
ahead!!!!
Your
Entities
<<subsystem>>
Security
Manager
Secure.java
A package -
OOAD Using the UML - Appendix: Security Mechanism, v 4.2
Copyright  1999 Rational Software, all rights reserved
3
Your
Controllers
Secure
Interfaces
Example: Reuse: Security Mechanism
Referring to previous slide:
The GUI Framework provides a standard set of user
interface classes.
This GUI Framework is “security aware” (note the
dependency on the Secure User Interface).
Any questions on the UML? Know the
difference between a package and a
subsystem???
OOAD Using the UML - Appendix: Security Mechanism, v 4.2
Copyright  1999 Rational Software, all rights reserved
4
Referring to ‘Next’ Slide:
  For security, the UI provides a login screen that
works with a server-side business object to create a
user context. The server object will remain available to
all server-based controllers for the duration of the
session.
 DISCUSS!
 The Security Manager subsystem includes the classes
that implement the ‘security behavior’ (e.g., create the
‘secure user context’). Package Secure Interfaces,
supplies the security interfaces.
  Entries that are secure will realize an interface and
provide a small set of behavior.
OOAD Using the UML - Appendix: Security Mechanism, v 4.2
Copyright  1999 Rational Software, all rights reserved
5
Example: Reuse: Security Mechanism (1 of 4)
Note where all these items are ‘from!!!’
MainApplicationForm
This is a secure
entry; “Realizes”
the ISecureUser
Interface.
Secure User (not Data) :
This shows how the securityrelated classes fit together.
open()
Again <<role>> stereotype is
enterUserName()
validateUserIDPassword() used to identify which classes
are roles that should be
enterPassword()
0..1
logInUser()
developed by the designer as
setupSecurityContext()
they apply the mechanism.
LoginForm
(from GUI Framework)
start()
setupSecurityContext() 1
displayAvailOperations()
1
(from GUI Framework)
0..1
UserSecurityContext
0..1
SecurityAccess
(from Security Manager)
<<Interface>>0..1
ISecureUser
setAccess()
getAccess()
getUserId()
UserSecurityContext()
checkInternalTables()
(from Secure Interfaces)
setAccess()
getAccess()
getUserId()
new()
Role to be filled by the designer
applying the mechanism
<<role>>
SampleSecureClass
(from Secure Interfaces)
isReadable()
isWriteable()
isDeleteable()
makeReadable()
Note: all four of these
makeWriteable()
items are ‘from’ the
makeDeleteable()
Secure Interfaces
new()
package! (two are
actually Interfaces to
the package that must
be realized.
<<Interface>>
ISecureData
getUniqueId()
OOAD Using the UML - Appendix: Security Mechanism, v 4.2
Copyright  1999 Rational Software, all rights reserved
Note the multiplicities and
composition and inheritance
and dependencies! Discuss!
For each application session, there
must exist a class whose object
realizes the ISecureUser Interface.
(in our eg, the UserSecurityContext
class). (In Java, we ‘implement’ this
interface)
The object manages information
about the current user’s access to
UniqueId
(from Secure Interfaces) secure data without directly
depending on the classes.
generate()
(ISecureUser classes depend on the
asString()
UniqueId()
ISecureData interface, not on the
actual secure data classes.
(from Secure Interfaces)
getUniqueID()
getUserContext()
getUserName()
6
Example: Reuse: Security Mechanism (2 of 4)
LoginForm
(from GUI Framework)
MainApplicationForm
(from GUI Framework)
start()
setupSecurityContext() 1
displayAvailOperations()
1
open()
enterUserName()
Secure User (still);
validateUserIDPassword()
enterPassword()
Setting access rights.
0..1
logInUser()
setupSecurityContext()
getUserContext()
The security system, via the
getUserName()
operations exposed in
0..1
0..1
UserSecurityContext
(from Security Manager)
<<Interface>>0..1
ISecureUser
setAccess()
getAccess()
getUserId()
UserSecurityContext()
checkInternalTables()
(from Secure Interfaces)
SecurityAccess
(from Secure Interfaces)
isReadable()
isWriteable()
isDeleteable()
makeReadable()
makeWriteable()
makeDeleteable()
new()
setAccess()
getAccess()
getUserId()
new()
Role to be filled by the designer
applying the mechanism
<<role>>
SampleSecureClass
UniqueId
<<Interface>>
ISecureData
(from Secure Interfaces)
generate()
asString()
UniqueId()
(from Secure Interfaces)
getUniqueID()
getUniqueId()
OOAD Using the UML - Appendix: Security Mechanism, v 4.2
Copyright  1999 Rational Software, all rights reserved
7
ISecureUser, allows
clients to set the access
of the objects when they
are created and check the
access when they are
manipulated at some later
time.
(Details on this are not
shown.)
There is one SecurityAccess
instance per user login /
session per secure object.
Example: Reuse: Security Mechanism (3 of 4)
LoginForm
(from GUI Framework)
MainApplicationForm
(from GUI Framework)
start()
setupSecurityContext() 1
displayAvailOperations()
1
open()
enterUserName()
validateUserIDPassword()
enterPassword()
0..1
logInUser()
setupSecurityContext()
getUserContext()
getUserName()
0..1
0..1
UserSecurityContext
(from Security Manager)
<<Interface>>0..1
ISecureUser
setAccess()
getAccess()
getUserId()
UserSecurityContext()
checkInternalTables()
(from Secure Interfaces)
SecurityAccess
isReadable()
isWriteable()
isDeleteable()
makeReadable()
makeWriteable()
makeDeleteable()
new()
setAccess()
getAccess()
getUserId()
new()
UniqueId
<<Interface>>
ISecureData
(from Secure Interfaces)
generate()
asString()
UniqueId()
(from Secure Interfaces)
getUniqueID()
getUniqueId()
OOAD Using the UML - Appendix: Security Mechanism, v 4.2
Copyright  1999 Rational Software, all rights reserved
MainApplicationForm
keeps a reference
to a ISecureUser obj
until the form closes
(this is represented by
the composition
relationship).
(from Secure Interfaces)
Role to be filled by the designer
applying the mechanism
<<role>>
SampleSecureClass
Secure User:
8
The reference to the
ISecureUser object
actually comes back
from the LoginForm,
which creates the
ISecureUser object
upon successful
logon (this is
represented by the
dependency
relationship)
Example: Reuse: Security Mechanism (4 of 4)
LoginForm
(from GUI Framework)
MainApplicationForm
(from GUI Framework)
start()
setupSecurityContext() 1
displayAvailOperations()
1
open()
enterUserName()
validateUserIDPassword() Classes can be made
security aware by
enterPassword()
0..1
realizing the ISecureData
logInUser()
setupSecurityContext()
Interface and defining an
getUserContext()
attribute to hold a UniqueID.
getUserName()
0..1
0..1
UserSecurityContext
(from Security Manager)
<<Interface>>0..1
ISecureUser
setAccess()
getAccess()
getUserId()
UserSecurityContext()
checkInternalTables()
(from Secure Interfaces)
SecurityAccess
(from Secure Interfaces)
isReadable()
isWriteable()
isDeleteable()
makeReadable()
makeWriteable()
makeDeleteable()
new()
setAccess()
getAccess()
getUserId()
new()
Role to be filled by the designer
applying the mechanism
<<role>>
SampleSecureClass
UniqueId
<<Interface>>
ISecureData
(from Secure Interfaces)
generate()
asString()
UniqueId()
(from Secure Interfaces)
getUniqueID()
getUniqueId()
OOAD Using the UML - Appendix: Security Mechanism, v 4.2
Copyright  1999 Rational Software, all rights reserved
Secure Data:
9
The UniqueID class makes
sure that all users and all
pieces of data from all
different applications get
their own unique ids.
All classes that have been
mapped to the Security
analysis mechanism should
realize the ISecureData
interface. (one object per
class will do this…)
Example: Security Mechanism: Secure User Set-Up at Login
Any User
:
MainApplicationForm
: LoginForm
: ISecureUser
1. start( )
1.1. open( )
2. enterUserName( )
We did not expand on
validation since it was a
reverse engineered
component
3. enterPassword( )
4. logInUser( )
4.1. validateUserIDPassword( )

4.2.1. new(UserID)
[ login successful ]
5.1. getUserContext( )
The
MainApplicationForm
retains the secure
user context for later
processing by the
user.
 The ISecureUser is passed to each
form that is opened.
This form in turn passes it into each
controller that starts up.
This is propagated to the remote
controllers that use the ISecureUser to set
and check privileges.
6. close( )
7. displayAvailOperations( )
Display the
operations/functions that
the application
OOAD Using the UML - Appendix: Security Mechanism,
v 4.2 provides.
Copyright  1999 Rational Software, all rights reserved
The LoginForm will – upon successful login
– create an instance of ISecureUser
(physically an instance of
UserSecurityContext).
GO THROUGH SEQUENCE DIAGRAM…
THEN NOTE for the next slide:
[ login successful ]
4.2. setupSecurityContext( )
5. setupSecurityContext( )
As mentioned earlier, for each application
session, there must exist an object whose
class realizes the ISecureUser Interface.
This object manages information about the
current user’s access to secure data.
10
(The setting up of a user context is described in
more detail for the Course Registration System
example in the Use Case Design module where
the Login use-case realization is discussed. )
Example: Security Mechanism: Secure User Propagation
:SampleMain
AppForm
:
SampleAppSubForm
:
SampleController
: User
It is assumed that the User has logged in.
1: // doSomething( )
2: open(ISecureUser)
Secure user
session was
set up during
Login
All entries that need to perform
access checks must have access
to the current user’s session (i.e.,
have access to ISecureUser).
This example shows how a
sub-form and the associated
controller are provided access to
the secure user session.
Provide secure user
session to controller for
any later validation
3: new()
4: setSession(ISecureUser)
5: // display available operations( )
OOAD Using the UML - Appendix: Security Mechanism, v 4.2
Copyright  1999 Rational Software, all rights reserved
11
The secure user session is
established during login and
maintained by the main
application form.
The secure user session is then
propagated from the main
application form to any sub-forms
and supporting controllers (note
the use of ISecureUser as a
parameter to the open command,
as well as the new setSession()
operation).
Example: Security Mechanism: Secure Object Access
Secure Data again!
Secure Object
Client
: ISecureUser
All classes that have been mapped to the
Security analysis mechanism should
:
realize the ISecureData Interface. All
SecurityAccess classes that must verify the access of
some secure data should do so via the
ISecureUser interface.
1: getAccess(ISecureData)
There will be one object whose class
realizes the ISecureUser interface per
Student session.
2: isReadable( )
When retrieving secure data, the client
must verify the current user’s ability to
access the data, using the security
access information for the current user.
AND/OR
3: isWriteable( )
AND/OR
4: isDeleteable( )
OOAD Using the UML - Appendix: Security Mechanism, v 4.2
Copyright  1999 Rational Software, all rights reserved
12
Specifically, in the example, after
retrieving an object that realizes the
ISecureData interface, the Secure
Object Client must retrieve the security
access info for the secure object for the
current user and compare them to make
sure that the current user can
view/edit/delete the object.
Incorporating the Security Mechanism: Steps
(Italicized text describes the architectural decisions made with regards to
JDBC for our Course Registration example
 We need to:
 Provide access to the class libraries needed to implement the Security
mechanism (for reuse, etc.)
 New Security package will be created to contain the
classes that implement the security mechanism.
 Note:
 Package containing forms dependent on Security GUI
Framework package
OOAD Using the UML - Appendix: Security Mechanism, v 4.2
Copyright  1999 Rational Software, all rights reserved
13
(continued)
Incorporating the Security Mechanism: Steps
(Italicized text describes the architectural decisions made with regards to
JDBC for our Course Registration example.
 Create main application forms:
• Establish main application forms, with associated login
forms
• For each application that is to be developed, a main
application form needs to be defined.
• In some cases, such a main form may have already been identified.
If not, one needs to be defined now. In any case, the main
application form must be inherited from the MainApplicationForm
provided in the GUI Frameworks package.
• You may need to create sub-forms to support the individual
functions/operations provided by the application. If any Login forms
were identified in analysis, these need to be replaced with the
LoginForm provided in the GUI Frameworks package. This
LoginForm will be associated and ‘driven by’ the
MainApplicationForm defined above via mechanisms provided in the
GUI Frameworks package.
 In Architectural Design, we make sure that the necessary package
relationships exist, but the creation of the main application forms has
been deferred until detailed design (e.g., Use Case and Subsystem
OOAD Using the UML - Appendix: Security Mechanism, v 4.2
Design).
14
Copyright  1999 Rational Software, all rights reserved
(continued)
Incorporating the Security Mechanism: Steps
(Italicized text describes the architectural decisions made with regards to
JDBC for our Course Registration example.
 Package containing core data types dependent on Security
Secure Interfaces package
• All classes that need to be secure must realize the ISecureData
interface in the Secure Interfaces package. The necessary package
relationships will be added here, but the introduction of all of the
individual realization relationships (for all data that is to be secure)
will be deferred until detailed design (e.g. Use Case and Subsystem
Design).
 Add realization relationships
• Have all secure classes realize the ISecureData interface
OOAD Using the UML - Appendix: Security Mechanism, v 4.2
Copyright  1999 Rational Software, all rights reserved
15
(continued)
Incorporating the Security Mechanism: Steps (contd)
 Provide secure user session (ISecureUser) access,
where necessary
 Package containing control classes dependent on
Security GUI Framework package
Deferred
 Control classes will need secure user session
access
 Add setSession(ISecureIUser) operation
All entities that need to perform access checks must have access to the current
user’s session (i.e., have access to ISecureUser). This means that you may need to
add ISecureUser as a parameter to some operations.
For the Course Registration System, the control classes will need access to the
secure user session, so a setSession(ISecureUser) operation needs to be added to
each control class.
The modification of the individual control classes has been deferred until detailed design
(e.g., Use-Case and Subsystem Design).
OOAD Using the UML - Appendix: Security Mechanism, v 4.2
Copyright  1999 Rational Software, all rights reserved
16
Incorporating the Security Mechanism: Steps (contd)
 Create/update interaction diagrams with security
processing
 Secure user set-up (login)
 Secure user propagation (secure user session
Deferred
availability)
 Secure data access (checking access permissions)
In order to make sure that everything has been accounted for in the system, interaction
diagrams should be defined which model the added security functionality.
Specifically, secure user set-up (including Login, as well as making sure that the secure
user session is made available to all entities that will need to perform security checks)
and secure data access (includes checking a user’s permission before providing
access to secure data).
The actual incorporation of the mechanism is deferred until detailed design (e.g., UseCase Design and Subsystem Design).
At this point, the architect provides guidance to the designers and makes sure that the
architecture has the necessary infrastructure to support the mechanism (i.e., has the
necessary packages and package relationships).
OOAD Using the UML - Appendix: Security Mechanism, v 4.2
Copyright  1999 Rational Software, all rights reserved
17
Example: Incorporating the Security Mechanism: Steps (1 of 2)
<<boundary>>
LoginForm
<<boundary>>
Sample Application Form
// login user()
// enter username and password()
// validate username and password()
LoginForm
MainApplicationForm
(from GUI Framework)
(from GUI Framework)
0..1
start()
setupSecurityContext()
1
open()
enterUserName()
validateUserIDPassword()
enterPassword()
logInUser()
setupSecurityContext()
getUserContext()
Sample
Secure Class
SampleSecureClass
getUniqueID()
<<control>>
Sample Control Class
<<control>>
Sample Control Class
setSession(toUser: ISecureUser)
ISecureDat
(fromaSecure Interfaces)
This is an example of some of the changes described on the previous slide that must be
1
made to the Course Registration Model to incorporate the Security mechanism:
. The LoginForm from the security GUI Framework will replace the LoginForm identified
0..1
in UC Analysis
. The MainApplicationForm from the security GUI framework will be used as the basis
<<boundary>>
Sample Application Form for new app main forms that will serve as the context for the forms identified in UC
Analysis.
Application Main forms will be created for each of the major system actors. This is
because the functionality in each of these applications is disjoint. The actual definition of
the main application forms has been deferred until detailed design
OOAD Using the UML - Appendix: Security Mechanism, v 4.2
18
Copyright  1999 Rational Software, all rights reserved (e.g. Use Case and Subsystem
Design)
Sample Main Form
Example: Incorporating the Security Mechanism: Steps (2 of 2)
<<boundary>>
LoginForm
<<boundary>>
Sample Application Form
// login user()
// enter username and password()
// validate username and password()
Sample
Secure Class
<<control>>
Sample Control Class
LoginForm
(from GUI Framework)
MainApplicationForm
0..1
(from GUI Framework)
1
start()
setupSecurityContext()
SampleSecureClass
open()
enterUserName()
validateUserIDPassword()
enterPassword()
logInUser()
setupSecurityContext()
getUserContext()
getUniqueID()
<<control>>
Sample Control Class
setSession(toUser: ISecureUser)
ISecureData
Sample Main Form
(from Secure Interfaces)
Any classes that must be secure will need to realize the ISecureData interface. This
involves implementing the getUniqueID() operatiion. The actual definition of the
individual realization relationships (one for each class that is to be secure)
0..1
has been deferred until detailed design (e.g. Use Case and Subsystem Design).
<<boundary>>
The control classes will need access to the secure user session, so a
Sample Application Form
setSession(ISecureUser) operation needs to be added to each control class.
The modification of the individual control classes has been deferred until detailed
design (e.g. Use Case and Subsystem Design).
1
OOAD Using the UML - Appendix: Security Mechanism, v 4.2
Copyright  1999 Rational Software, all rights reserved
19
Example: Incorporating the Security Mechanism: Steps (contd)
Sample
Application Package
Security
GUI
Framework
<<subsystem>>
Security
Manager
Sample
Secure Data
Secure
Interfaces
The above demonstrates the package dependencies needed to support the changes described on
the previous slides to incorporate the security mechanism: The design elements that support the
security mechanism have been placed in a single package, Security. The package(s) that contains
the application main forms (in the above example, the Sample Application package) will have a
dependency on the Security GUI Framework package. The package(s) that contains the classes
that need to be secure (in the above example, the Sample Secure Data package) will have a
dependency on the Security Secure Interfaces package. The package(s) that contains the classes
that will need to access the secure classes (in the above example, the Sample Application package)
will have a dependency on the Security Secure Interfaces package. Specific application and core
abstraction packages are defined in the next section.
OOAD Using the UML - Appendix: Security Mechanism, v 4.2
Copyright  1999 Rational Software, all rights reserved
20
Use-Case Design Slides
The following slides can be
inserted during the Use-Case
Design module – to address
the Security considerations.
OOAD Using the UML - Appendix: Security Mechanism, v 4.2
Copyright  1999 Rational Software, all rights reserved
21
Review: Incorporating the Security Mechanism: Steps
This represents a summary of the steps first discussed in Architectural Design that can
be used to implement the security mechanism talked about. Italicized text –
architectural decisions made with regards to JDBC for our example. The check marks
indicate what steps have been completed. Let’s continue to incorporate this
mechanism.
In Architectural Design, a new Security mechanism was created to contain the classes
that implement the security mechanism.
 Provide access to the class libraries needed to
implement the Security mechanism
 New Security package – created to contain
classes that implement the security mechanism.
OOAD Using the UML - Appendix: Security Mechanism, v 4.2
Copyright  1999 Rational Software, all rights reserved
22
(continued)
 We know that for each application to be developed, a main
application form needs to be defined. In our example,
 The main application form must inherit from the
MainApplicationForm provided in GUI Frameworks
package.
 Sub-forms may be needed to create to support the
individual functions/operations provided by the application.
 Establish main application forms, with associated
login forms
 Package containing forms dependent on
Security GUI Framework package
 Create main application forms
OOAD Using the UML - Appendix: Security Mechanism, v 4.2
Copyright  1999 Rational Software, all rights reserved
23
Review: Incorporating the Security Mechanism: Steps
If any existing Login forms were identified in analysis, these need to be replaced with
the LoginForm provided in the GUI Frameworks package.
This LoginForm will be associated and ‘driven by’ the MainApplicationForm defined
above via mechanisms provided in the GUI Frameworks package.
In architectural design, we put the infrastructure in place, now the actual main
application forms will need to be created.
All classes that need to be secured must realize the ISecureData interface in the
Secure Interfaces package.
In Arcdhitectural Design, access to the interface was provided;
now we must add the actual realizes relationships.
 Have all secure classes realize the ISecureData interface
 Package containing core data types dependent on
Security Secure Interfaces package
 Add realization relationships
OOAD Using the UML - Appendix: Security Mechanism, v 4.2
Copyright  1999 Rational Software, all rights reserved
24
(continued)
Review: Incorporating the Security Mechanism: Steps (contd)
•All entities that need to perform access checks must have access to the current
user’s session (i.e., have access to ISecureUser). This means that you may need to
add ISecureUser as a parameter to some operations.
For the Course Registration System, the control classes will need access to the
secure user session, so a setSession(ISecureUser) operation needs to be added to
each control class.
In Architectural Design, the package and package dependencies were put into place.
Now, update the control classes so that they have access to the secure user session.
 Provide secure user session (ISecureUser) access,
where necessary
 Package containing control classes dependent on
Security GUI Framework package
 Control classes will need secure user session
access
 Add setSession(ISecureIUser) operation
OOAD Using the UML - Appendix: Security Mechanism, v 4.2
Copyright  1999 Rational Software, all rights reserved
25
Review: Incorporating the Security Mechanism: Steps (contd)
In order to make sure that everything has been accounted for in the system,
interaction diagrams should be defined which model the added security functionality.
Specifically, secure user set-up (including Login, as well as making sure that the
secure user session is made available to all entities that will need to perform security
checks) and secure data access (includes checking a user’s permission before
providing access to secure data).
These interaction diagrams will now be developed.
 Create/update interaction diagrams with security
processing
 Secure user set-up (login)
 Secure user propagation (secure user session
availability)
 Secure data access (checking access permissions)
OOAD Using the UML - Appendix: Security Mechanism, v 4.2
Copyright  1999 Rational Software, all rights reserved
26
- Done
Example: Incorporating the Security Mechanism
<<boundary>>
LoginForm
<<boundary>>
RegisterForCoursesForm
// register for courses()
// login user()
// enter username and password()
// validate username and password()
MainApplicationForm
(from GUI Framework)
LoginForm
<<entity>>
Schedule
(from GUI Framework)
1
0..1
start()
setupSecurityContext()
MainStudentForm
<<entity>>
Schedule
open()
enterUserName()
validateUserIDPassword()
enterPassword()
logInUser()
setupSecurityContext()
getUserContext()
<<control>>
RegistrationController
<<control>>
RegistrationController
setSession(toUser: ISecureUser)
ISecureData
(from Secure Interfaces)
This is an example of some of the changes described on the previous slide that were
1
made to the Course Registration Model to incorporate the Security mechanism.
The LoginForm from the security GUI framework will replace the LoginForm identified
in Use-Case Analysis. The MainApplicationForm from the security GUI framework will
0..1
be used as the basis for the new MainStudentForm. TheMainStudentForm will
<<boundary>>
RegisterForCoursesForm inherit from the MainApplicationForm). Thus, the MainStudentForm will be “securityaware”. The original RegisterForCoursesForm will now be a subform of the new
MainStudentForm. The Schedule class must be secure, so it will realize the
// register for courses()
ISecureData interface. The RegistrationController control classes will need access to
the secure user session, so a setSession(ISecureUser) operation will be added.
OOAD Using the UML - Appendix: Security Mechanism, v 4.2
Copyright  1999 Rational Software, all rights reserved
27
Example: Incorporating the Security Mechanism (contd)
<<layer>>
Application
<<layer>>
Application
Registration
<<layer>>
Business Services
<<layer>>
Business
Services
University Artifacts
(from Business Services)
Security
(from Business Services)
Secure Interfaces
(from Security)
GUI Framework
(from Security)
This demonstrates the packages dependencies needed to support the changes described on the previous slides to
incorporate the security mechanism. (Packages and associated relationships are defined in Architectural Design.
This is a review slide.
The design elements that support the security mechanism will be placed in a single package, Security.
OOAD Using the UML - Appendix: Security Mechanism, v 4.2
Copyright  1999 Rational Software, all rights reserved
28
Example: Incorporating the Security Mechanism (contd)
<<layer>>
Application
<<layer>>
Application
Registration
<<layer>>
Business Services
University Artifacts
(from Business Services)
<<layer>>
Business
Services
Security
(from Business Services)
Secure Interfaces
(from Security)
GUI Framework
(from Security)
The Application package(s) that contains the application main forms will have a dependency on the Security GUI
Framework package (for the main and form definitions). For the course registration application, that package is
the Application package.
The Application package(s) that contains the control classes will have a dependency on the Security Secure
OOAD Using the package
UML - Appendix:
Security
v 4.2
Interfaces
(for
theMechanism,
ISecureUser
definition). For the
course registration application, that package is the
29
Copyright  1999 Rational Software, all rights reserved
Application package.
Example: Incorporating the Security Mechanism (contd)
<<layer>>
Application
<<layer>>
Application
Registration
<<layer>>
Business Services
<<layer>>
Business
Services
University Artifacts
(from Business Services)
Security
(from Business Services)
Secure Interfaces
(from Security)
GUI Framework
(from Security)
The University Artifacts package contains the classes that need to be secure, so it will have a dependency on the
Security Secure Interfaces package.
OOAD Using the UML - Appendix: Security Mechanism, v 4.2
Copyright  1999 Rational Software, all rights reserved
30
Example: Incorporating the Security Mechanism: Secure User Set-Up
In order to use the security features of
the system, the secure user session must
be established. This occurs during login.
Any User
: MainStudentForm
: LoginForm
StudentSession :
ISecureUser
1. start( )
1.1. open( )
The security mechanism provides a main
application form and a login form, which
will replace the original login form.
The user name
for students is
the Student ID.
2. enterUserName( )
3. enterPassword( )
4. logInUser( )
The above example is the design usecase realization for the Login use case.
4.1. validateUserIDPassword( )
[ login successful ]
4.2. setupSecurityContext( )
It is almost completely re-written from
Use-Case Analysis.
4.2.1. new(UserID)
[ login successful ]
5. setupSecurityContext( )
5.1. getUserContext( )
The MainStudentForm
retains the Student's
session for later
processing by the
user.
6. getUserName( )
7. close( )
8. displayAvailOperations( )
OOAD Using the UML - Appendix: Security Mechanism, v 4.2
Copyright  1999 Rational Software, all rights reserved
31
Display the
operations/functions that
the application provides.
Example: Incorporating the Security Mechanism: Secure User Propagation
The above is a fragment of the
:
MainStudentForm
Register for Courses
:
RegistrationController
: Student
use-case realization
interaction diagram.
:
RegisterForCoursesForm
It is assumed that the Student has logged in.
See Basic Flow - Login Interaction diagram.
It demonstrates how the created1: // register for courses( )
2: open(ISecureUser)
secure user session is
provided to the
Secure user
session was
set up during
Login
3: // is registration open?( )
RegisterForCoursesForm and
the RegistrationController. This
[registration is open]
is necessary because in our
4: new()
system, the controllers will be
5: setSession(ISecureUser)
performing the security checks.
The user may select any
of these operations
6: // display available operations( )
7: // create schedule( )
8: // update schedule( )
9: // delete schedule( )
OOAD Using the UML - Appendix: Security Mechanism, v 4.2
Copyright  1999 Rational Software, all rights reserved
32
Provide secure user
session to controller for
any later validation
 The sequence diagram fragment (next slide) from the
Register for Courses use-case realization follows.
 It demonstrates the interactions that need to be added
when the application creates secure data (specifically, a
Student’s Schedule).
 After creating the Student’s Schedule, the
RegistrationController sets the security access
information for the Schedule for the current Student.
Since the Student is the “owner” of the schedule, he/she is
given full access.
 The access permissions are maintained in the SecureUser
that is managed by the MainApplicationForm (the
MainStudentForm, in the case of Register for Courses).
 See the Login sequence diagram on an earlier slide. The
RegisterForCoursesForm is provided with the SecureUser
when it is opened by the MainStudentForm.
 As stated earlier, the Schedule class was mapped to the
Security analysis mechanism, so it realizes the
SecureData interface.
OOAD Using the UML - Appendix: Security Mechanism, v 4.2
Copyright  1999 Rational Software, all rights reserved
33
Example: Incorporating the Security Mechanism: Secure Data Access
: RegisterForCoursesForm
: RegistrationController
:
SecurityAccess
: ISecureUser
: Schedule
: Student
1: // select 4 primary and 2 alternate offerings( )
2: // create schedule with offerings( )
3: // create with offerings( )
4: new( )
5: makeReadable( )
6: makeWriteable( )
Set the access
permissions to wide open
for the Student/owner of the
Schedule
7: makeDeleteable( )
8: setAccess(ISecureData, SecurityAccess)
9: // add schedule(Schedule)
At this, point the Submit Schedule subflow is executed.
OOAD Using the UML - Appendix: Security Mechanism, v 4.2
Copyright  1999 Rational Software, all rights reserved
34
: Student
 This next sequence diagram is a subset of the View of
Participating Classes (VOPC) for the Register for Courses
use-case realization.
 It contains the classes for the instances in the previous
interaction diagrams (i.e., the classes affected by the
incorporation of the security mechanism).
 Notice the addition of SecureData, SecurityAccess and
ISecureUser and their relationships with the application
classes.
 The incorporation of the security processing has been
localized to the controllers, in addition to the secure
classes realizing the secure interface.
 Any forms “get security for free” if they inherit from the
View class provided with the GUI Frameworks.
 Note: the display of most of the operations and attributes
have been suppressed for clarity of the diagram.
However, a few selected operations that demonstrate the
security mechanism have been shown.
OOAD Using the UML - Appendix: Security Mechanism, v 4.2
Copyright  1999 Rational Software, all rights reserved
35
Example: Incorporating the Security Mechanism: VOPC
<<Interface>>
ISecureUser
MainApplicationForm
(from GUI Framework)
(from Secure Interfaces)
1
0..1
MainStudentForm
View
(from Registration)
(from GUI Framework)
open(forUser : ISecureUser)
1
<<Interface>>
ISecureData
(from Secure Interfaces)
0..1
<<boundary>>
RegisterForCoursesForm
(from Registration)
1
<<control>>
RegistrationController
SecurityAccess
(from Registration)
(from Secure Interfaces)
1
setSession(forUser : ISecureUser) 0..1
0..1
+currentSchedule
0..1
<<entity>>
Schedule
(from University Artifacts)
0..*
0..1
+registrant
1
<<entity>>
Student
(from University Artifacts)
OOAD Using the UML - Appendix: Security Mechanism, v 4.2
Copyright  1999 Rational Software, all rights reserved
36