Download Sub Phase: High

Sub Phase:
High-Level Design
1
From Requirements
A l i tto U
Analysis
User M
Manuall
System Design
2
1
Map of design phase
DESIGN
LOW LEVEL
DESIGN
HIGH LEVEL
DESIGN
Data
Persistance
Subsystem
Module Interfaces
Modularization
Classes
Class Interfaces
Cl
I t f
Interaction Diagrams
architecture
User Interface
User Manual
Implementation
Janice Regan, 2008
3
Activities for high level design
D
Decide on an architecture model to work with
D
Modularize
odu a e
‹
Divide your application into subsystems/modules
D
Design your user interface
D
If data persistence is required
D
D
‹
Determine which data needs to be persistent
‹
Decide on a solution for dealing with that persistent data.
Refine your use cases
‹
Add User interface interaction details
‹
Add Database solution interaction details
Describe the interfaces between subsystems
Janice Regan, 2008
4
2
Objectives of System Design
D The design phase produces a system model
‹
That is based on specific design goals for the designers
‹
That defines architecture and Subsystem design
‹
’
Identifying subsystems/modules (manageable parts)
’
Identifying architecture (hardware/software)
’
Data management / mapping
’
Access control, flow control (sequencing operations)
That describes boundary use cases:
’
Initialization, termination, configuration, exception
handling
Janice Regan, 2008
5
Design goals
D When assessing design goals consider
‹
Selection of existing components (off the shelf modules
or components )
‹
Hardware / software mapping,
’
Are there multiple nodes or systems
’
What is each node responsible for
‹
selecting solutions for managing persistent data
‹
Access control policies
‹
Control flow on a solution wide basis
‹
Boundary conditions (startup, error, shutdown)
Janice Regan, 2008
6
3
Design goals, System decomposition
D Identify design goals (choose aspects of the
system to be optimized) Design goals are often
derived from non-functional requirements.
‹
Guide designers in assessing trade offs
D Develop and refine a subsystem decomposition
that satisfies the maximum number of design
goals
l and
d or th
the mostt critical
iti l design
d i
goals
l
D Refine the decomposition to better satisfy the
design goals
Janice Regan, 2008
7
Selecting platform (mapping 1)
D First need to decide if the system resides on one
computer
p
or on multiple
p computers
p
((in the same
location or separated and connected through the
Internet)
D Next need to select an appropriate hardware
configuration, and operating system (virtual
machine)
D Next need to select any other external software
components (database package, communication
package …)
Janice Regan, 2008
8
4
Allocating subsystems (mapping 2)
D Next we consider the subsystems (modules) in
our system
y
and allocate modules to appropriate
pp p
nodes (virtual machines)
D If objects belong to more than one module then
they may need to communicate between modules
or even between virtual machines
D This communication can often be supported
pp
and
made more efficient using the “proxy” design
pattern
9
Janice Regan, 2008
Proxy Pattern
object
Proxy object
1
0..1
Real object
D Protection or Image proxy: enhances efficiency.
D Proxy object is similar (same interface) to real
object, only contains items like checks for
permission to use methods, or specifications of
image
D Only when permission is allowed or the actual
image is accessed is the real object used
Janice Regan, 2008
10
5
Access Control
D In a multi user system it is common for
different users (actors) to have access to
different functions of the system or
different parts of the data
D In most general case need to identify
which methods of any shared object can be
accessed by each sharing user
D Have a matrix of access information (class
or method on one axis, user type on the
other
Janice Regan, 2008
11
Access Control: representation
D Depending on the amount and type of
flexibility (generality) needed we can
represent the access matrix as
1. A global access table, explicitly list access (or
no access) for each operation, class, user tuple
2. An access control list to control if an object
(method in an object) can be accessed by a
particular user (e.g. Guest List)
3. A capability to indicate if a user may access a
particular method or object (e.g. Invitation)
Janice Regan, 2008
12
6
Access Control: representation
D
Depending on the amount and type of flexibility
(generality) needed we can represent the access
matrix as
4.
When the number of actors or objects is large methods
1, 2, 3 may not be practical. In such a case set of rules
can be used to control access (e.g a firewall)
‹ Before using the access control the user must be
authenticated to the system. Usually use
username and password known only by the user
themselves
themselves.
‹ Login over an unsecured network may also need
encryption to assure security and prevent forging
of login packets
Janice Regan, 2008
13
Design of Control Flow
D Three approaches
‹ Procedure
d
d i
driven
’
Procedures wait for input from user
’
Not generally compatible with OO languages
‹ Event driven
’
Main loop waits for events, sends them to objects
‹ Threads
’
Concurrent (multiple processes at one time) version
of procedure driven
Janice Regan, 2008
14
7
Identify boundary conditions
D Configuration: when is each object
created or destroyed?
D How is each component of the system
started?
D How is each component of the system
shut down?
D How does the system deal with error
conditions / exceptions?
Janice Regan, 2008
15
Is data persistence required?
D Are there pieces of information that need to be
‘remembered’ when the application
pp
is not
actually in use?
‹
Persistent data outlive a single execution of the
software system
D What data need to be persistent?
D We know
k
some off our data
d
should
h ld be
b persistent.
‹
How to we assure the data is persistent?
‹
Store data between executions of the software system.
How?
Janice Regan, 2008
16
8
Example: 1 data persistence
D You are designing an application which supports
users in writing documents (a word processor)
‹
Users do not wish to type their entire document each
time they use the word processor
‹
The word processor creates a file
‹
The file is saved when the user leaves the word
processor
‹
The file is loaded into the word processor when a user
wishes to continue with editing the document.
D The data (file containing document) is persistent.
It is not necessary for the word processor to be
running for the file to exist.
17
Janice Regan, 2008
Data Persistence
D Persistent data outlive a single execution of
the software system
‹ Done by storing data
’
In files on external storage medium
’
In database
Janice Regan, 2008
….
18
9
Data Persistence
D Does our application need data
persistence?
‹ Which data need to be persistent?
‹ How should this data be stored?
’
How is this external storage medium managed?
’
What tools are to be used to manage the persistent
d t ?
data?
’
Can all data reside in memory at once?
Janice Regan, 2008
19
LMS example: Data persistence
D What data need to be persistent?
‹ Patron
P
‹ Resource
‹ Librarian
D What data do not need to be persistent?
‹ Overdue fine information
‹ Overdue letters
‹ Search results
Janice Regan, 2008
20
10
Flat Files
D Storage abstractions provided by OS
D Application
‹ stores data as sequence of bytes
‹ defines how and when data is
retrieved/updated
D Low level data storage
‹ Advantage:
g g
give application
pp
control over data
storage (e.g., size)
‹ Disadvantage: application must take care of
many issues: concurrent accesses, recovery
from system crash.
Janice Regan, 2008
21
Database Management System DBMS
D Security (hacker proof)
D Recovery from crash
D Information growth
‹
Solution still works with increased data volume
D Concurrency
‹
Concurrency solution allows for increased users
D Software systems that operate on data can do so
in a consistent fashion
D Efficient queries on large data set
Janice Regan, 2008
22
11
Context of a database
Self Implemented Data Storage Solution
(Part of application)
Subsystem 1
Subsystem 2
DBMS
filestore
Subsystem 3
23
Janice Regan, 2008
Context of a database
Commercial DBMS
(Used by application, not directly part of application)
Subsystem 1
Subsystem 2
DB interface
DBMS
filestore
Subsystem 3
Janice Regan, 2008
24
12
Relational DBMS
Data stored in structured tables (called relations)
D
‹
‹
‹
‹
Each row is a record (called a tuple), each tuple contains the
values
l
off a list
li t off attributes
tt ib t
Each column, (called an attribute) contains the value of that
particular attribute for each tuple in the relation
Several tuples in diff. tables may contain attributes of individual
object (not object based)
E.g.
Patron’s Name AddressLibrary #
June Smith
123456
Jo Zhang
987655
1 relation
l i
M
Age
45
17
1 tuple
p
1 attribute
Advantage: mature technology, stable application
Disadvantage: high cost, performance bottleneck, not object
D
D
Janice Regan, 2008
oriented
25
Object Persistence
Problem:
How to go back and forth between objects held in
memory and storage entities on disk when these
storage entities are not object-oriented?
STUDENT-COURSE
2010101
J Doe
3 Ace St
Eng 10
2010111
objects
K Lu
88 B Rd
Math 101
Std #
Course
#
201011
1
Math
101
STUDENT 201010 Eng 10
COURSE
#
Title
credits
Math 101
Calculus
3
Eng 10
ESL
3
Janice Regan, 2008
#
1
Title
address
2010101
J Doe
3 Ace St
2010111
K Lu
88 B Rd
26
13
Object-Oriented DBMS
D Provides services similar to relational DB
D Stores data as objects and associations
D Higher level of abstraction
‹
no need to translate between objects and relations
(advantage)
‹
provides inheritance and abstract data types
D Disadvantages: slower than relational DB, less mature
technology
Janice Regan, 2008
27
What solution is appropriate?
D Choose a file when
‹
‹
Voluminous data (e.g. images)
Low information density (e.g. archives, logs)
D Choose a database when
‹
‹
Concurrent access
Multiple applications over same data
D Choose a relational database when
‹
‹
Large data set
C
Complex
l
queries
i over attributes
tt ib t
D Choose OO database when
Medium size data set
‹ Irregular associations among objects
‹
Based on p 269 of Bruege & Dutoit
Janice Regan, 2008
28
14
LMS Case Study: Object Persistence
D LMS may contain 1000’s of resources
D These records cannot all “live” in memory
D A DBMS is called for to provide
‹ Concurrent access by multiple users
‹ Security enforcement of different access levels
for various user categories
‹ Allow for increased data capacity
29
Janice Regan, 2008
LMS Case Study:
Relational Representation of Data
Book
Relational Tables
Patron
Resource List
Patron Address
Janice Regan, 2008
30
15
Encapsulating Data Storage
D Once storage mechanism is selected,
encapsulate it into a module, then define
interface between that module and the
storage mechanism
‹ Open Database Connectivity (ODBC)
application programming interface (API)
‹ Java Database Connectivity (JDBC) application
programming interface (API)
‹ Both use Structured Query Language (SQL) as
their database access language
31
Janice Regan, 2008
Context of a database
Commercial DBMS
(Used by application, not directly part of application)
Subsystem 1
Subsystem 2
DB interface
DBMS
filestore
Subsystem 3
Janice Regan, 2008
32
16
Encapsulating Data Storage
D Advantage: Increase changeability
‹ Allows easy substitution of different
data stores
‹ Makes your solution vendor
independent
D Disadvantage: Reduce performance
Janice Regan, 2008
33
High Level Design : Summary
D Divide your software system into
subsystems
D Design your user interface
D Decide on data persistence solution
D Refine your use cases by adding
‹ UI details
‹ DB details
D Describe inter-subsystems interfaces
Janice Regan, 2008
34
17
Janice Regan, 2008
35
Data Persistence: Solution 1
D Build DB subsystem (classes) that encapsulates
disk files
‹
‹
Random access file I/O library -> file handle
Tutorial: Binary Random-Access I/O in Java on Course
Web Site
‹
File contains unsorted records of fixed length – why?
D Build public interface for that class
‹
Must provide adequate functionality (get, add, remove,
…)
Janice Regan, 2008
36
18
Data Persistence: Solution 2
D Advantage: can change file format and organization
e g could use sorted records or B+ Tree
e.g.
rest of software system unaffected by this change
D How to transform objects into relational records
of fixed length
‹ Normalization
’
1st normal form:
fixed length records
’
2nd normal form: remove partial dependencies
’
3rd normal form: remove transitive dependencies
37
Janice Regan, 2008
Why fixed length records?
D Minimizes fragmentation of
the file.
file
‹ If record 2 is removed, a
unused space in the file will be
created
‹ Any new record may be put in
that unused space, because all
records have the same length
the new record completely fills
the space created by removal of
the previous record
‹ Fragmentation is not a problem.
Janice Regan, 2008
Record 1
Record 2
Record 3
Record 4
Record 5
Record 6
38
19
Why fixed length records?
D No need to have special
support to find the beginning
of the next record.
‹ If you know the record length
you know where each record
begins. Can easily find any
record (record n starts a n1*length)
1
length)
Record 1
Record 2
Record 3
Record 4
Record 5
Record 6
39
Janice Regan, 2008
Without fixed length records
D Fragmentation becomes a
problem
problem.
‹ If record 2 is removed, a
unused space in the file will be
created
‹ The next new record may be
put in that unused space if it is
small enough, the new record
may not fill the gap. Gaps are
created between records →
fragmentation
Janice Regan, 2008
Record 1
Record 2
Record 3
Record 4
Record 5
Record 6
40
20
Without fixed length records
D Special support to find the
beginning of the next record.
record
‹ You must keep track of where
each record begins and ends.
Need a table of contents, or
must step through all records
Janice Regan, 2008
Record 1
Record 2
Record 3
Record 4
Record 5
Record 6
41
21