Systems Analysis and Design II

1
Systems Analysis and Design II

• Addressing the design goals

2
System Design
3
Overview

• System Design I (previous lectures)
• Overview of System Design
• Design Goals
• Subsystem Decomposition
• Software Architectures
• System Design II (this lecture)
• Hardware/Software Mapping
• Persistent Data Management (Data layer)
• Global Resource Handling and Access Control

4
Hardware Software Mapping

• This activity addresses two questions
• How shall we realize the subsystems Hardware or
  Software?
• How is the object model mapped on the chosen
  hardware software?
• Mapping Objects onto Reality Processor, Memory,
  Input/Output
• Mapping Associations onto Reality Connectivity
• Much of the difficulty of designing a system
  comes from meeting externally-imposed hardware
  and software constraints.
• Certain tasks have to be at specific locations

5
Mapping the Objects

• Processor issues
• Is the computation rate too demanding for a
  single processor?
• Can we get a speedup by distributing tasks across
  several processors?
• How many processors are required to maintain
  steady state load?
• Memory issues
• Is there enough memory to buffer bursts of
  requests?
• I/O issues
• Do you need an extra piece of hardware to handle
  the data generation rate?
• Does the response time exceed the available
  communication bandwidth between subsystems or a
  task and a piece of hardware?

6
Connectivity in Distributed Systems

• If the architecture is distributed, we need to
  describe the network architecture (communication
  subsystem) as well.
• Questions to ask
• What are the transmission media? (Ethernet,
  Wireless)
• What is the Quality of Service (QOS)? What kind
  of communication protocols can be used?
• Should the interaction asynchronous, synchronous?
• What are the available bandwidth requirements
  between the subsystems?

7
Drawing Hardware/Software Mappings in UML

• System design must model static and dynamic
  structures
• Component Diagrams for static structures
• show the structure at design time or compilation
  time
• Deployment Diagram for dynamic structures
• show the structure of the run-time system
• Note the lifetime of components
• Some exist only at design time
• Others exist only until compile time
• Some exist at link or runtime

8
Component Diagram

• Component Diagram
• A graph of components connected by dependency
  relationships.
• Shows the dependencies among software components
• source code, linkable libraries, executables
• Dependencies are shown as dashed arrows from the
  client component to the supplier component.
• The kinds of dependencies are implementation
  language specific.
• A component diagram may also be used to show
  dependencies on a façade
• Use dashed arrow the corresponding UML interface.

9
Component Diagram Example
reservations
UML Component
UML Interface
update
10
Deployment Diagram

• Deployment diagrams are useful for showing a
  system design after the following decisions are
  made
• Subsystem decomposition
• Concurrency
• Hardware/Software Mapping
• A deployment diagram is a graph of nodes
  connected by communication associations.
• Nodes are shown as 3-D boxes.
• Nodes may contain component instances.
• Components may contain objects (indicating that
  the object is part of the component)

11
Deployment Diagram Example
Compile Time Dependency
Runtime Dependency
12
Mapping Design to Code

• Transformation
• Mapping Associations
• Mapping Contracts to Exceptions
• Mapping Object Models to Tables

13
Model transformations
14
Forward Engineering Example
Object design model before transformation
LeagueOwner
User
maxNumLeaguesint
emailString
notify(msgString)
Source code after transformation

• public class LeagueOwner extends User
• private int maxNumLeagues
• public int getMaxNumLeagues()
• return maxNumLeagues
• public void setMaxNumLeagues
• (int value)
• maxNumLeagues value
• / Other methods omitted /

• public class User
• private String email
• public String getEmail()
• return email
• public void setEmail(String value)
• email value
• public void notify(String msg)
• // ....
• / Other methods omitted /

15
Realization of a unidirectional, one-to-one
association
Object design model before transformation
1
1
Account
Advertiser
?
Source code after transformation
public class Advertiser private Account
account public Advertiser() account new
Account() public Account getAccount()
return account
16
Bidirectional one-to-one association
Object design model before transformation
1
1
Advertiser
Account
Source code after transformation

• public class Account
• / The owner field is initialized
• during the constructor and
• never modified. /
• private Advertiser owner
• public Account(ownerAdvertiser)
• this.owner owner
• public Advertiser getOwner()
• return owner

• public class Advertiser
• / The account field is initialized
• in the constructor and never
• modified. /
• private Account account
• public Advertiser()
• account new Account(this)
• public Account getAccount()
• return account

17
Bidirectional, one-to-many association
Object design model before transformation
1

Advertiser
Account
Source code after transformation

• public class Account
• private Advertiser owner
• public void setOwner(Advertiser newOwner)
• if (owner ! newOwner)
• Advertiser old owner
• owner newOwner
• if (newOwner ! null)
• newOwner.addAccount(this)
• if (oldOwner ! null)
• old.removeAccount(this)

• public class Advertiser
• private Set accounts
• public Advertiser()
• accounts new HashSet()
• public void addAccount(Account a)
• accounts.add(a)
• a.setOwner(this)
• public void removeAccount(Account a)
• accounts.remove(a)
• a.setOwner(null)

18
Bidirectional, many-to-many association
Object design model before transformation
ordered


Tournament
Player
Source code after transformation

• public class Tournament
• private List players
• public Tournament()
• players new ArrayList()
• public void addPlayer(Player p)
• if (!players.contains(p))
• players.add(p)
• p.addTournament(this)

• public class Player
• private List tournaments
• public Player()
• tournaments new ArrayList()
• public void addTournament(Tournament t)
• if (!tournaments.contains(t))
• tournaments.add(t)
• t.addPlayer(this)

19
Transformation of an association class
Object design model before transformation
Statistics

getAverageStat(name)

getTotalStat(name)

updateStats(match)
Tournament
Player


Object design model after transformation 1 class
and two binary associations
20
Data Management

• Some objects in the models need to be persistent
• Provide clean separation points between
  subsystems with well-defined interfaces.
• A persistent object can be realized with one of
  the following
• Data structure
• If the data can be volatile
• Files
• Cheap, simple, permanent storage
• Low level (Read, Write)
• Applications must add code to provide suitable
  level of abstraction
• Database
• Powerful, easy to port
• Supports multiple writers and readers

21
Relational Databases

• Collection of tables
• Comprised of fields that define entities
• Primary key has unique values in each row of a
  table
• Foreign key is primary key of another table
• Tables related to each other
• Primary key field of a table is a field of
  another table and called a foreign key
• Relationship established by a foreign key of one
  table connecting to the primary key of another
  table

22
Mapping an object model to a relational database

• UML object models can be mapped to relational
  databases
• Some degradation occurs because all UML
  constructs must be mapped to a single relational
  database construct - the table.
• UML mappings
• Each class is mapped to a table
• Each class attribute is mapped onto a column in
  the table
• An instance of a class represents a row in the
  table
• A many-to-many association is mapped into its own
  table
• A one-to-many association is implemented as
  buried foreign key
• Methods are not mapped

23
Mapping the User class to a database table
User
firstNameString
loginString
emailString
User table
idlong
firstNametext25
logintext8
emailtext32
24
Example for Primary and Foreign Keys
25
Buried Association

• Associations with multiplicity one can be
  implemented using a foreign key. Because the
  association vanishes in the table, we call this a
  buried association.

• For one-to-many associations we add the foreign
  key to the table representing the class on the
  many end.

• For all other associations we can select either
  class at the end of the association.

26
Mapping Many-To-Many Associations
In this case we need a separate table for the
association
Separate table for Serves association
Primary Key
27
Realizing Inheritance

• Relational databases do not support inheritance
• Two possibilities to map UML inheritance
  relationships to a database schema
• With a separate table (vertical mapping)
• The attributes of the superclass and the
  subclasses are mapped to different tables
• By duplicating columns (horizontal mapping)
• There is no table for the superclass
• Each subclass is mapped to a table containing the
  attributes of the subclass and the attributes of
  the superclass

28
Realizing inheritance with a separate table
29
Realizing inheritance by duplicating columns
User
name
LeagueOwner
Player
maxNumLeagues
credits
30
Comparison Separate Tables vs Duplicated Columns

• The trade-off is between modifiability and
  response time
• How likely is a change of the superclass?
• What are the performance requirements for
  queries?
• Separate table mapping
• We can add attributes to the superclass easily by
  adding a column to the superclass table
• Searching for the attributes of an object
  requires a join operation.
• Duplicated columns
• Modifying the database schema is more complex and
  error-prone
• Individual objects are not fragmented across a
  number of tables, resulting in faster queries

31
Summary of mappings

• Rule 1 Map all concrete problem domain classes
  to the RDBMS tables.
• Rule 2 Map single valued attributes to columns
  of the tables.
• Rule 3 Map methods to stored procedures or to
  program modules.
• Rule 4 Map single-valued aggregation and
  association relationships to a column that can
  store the key of the related table
• Rule 5 Map multi-valued attributes and repeating
  groups to new tables and create a one-to-many
  association from the original table to the new
  ones.
• Rule 6 Map multi-valued aggregation and
  association relationships to a new associative
  table that relates the two original tables
  together. Copy the primary key from both original
  tables to the new associative table
• Rule 7 For aggregation and association
  relationships of mixed type, copy the primary key
  from the single-valued side (1..1 or 0..1) of the
  relationship to a new column in the table on the
  multi-valued side (1.. or 0..) of the
  relationship that can store the key of
• the related table
• Rule 8a Ensure that the primary key of the
  subclass instance is the same as the primary key
  of the superclass..
• OR
• Rule 8b Flatten the inheritance

32
Heuristics for Transformations

• For a given transformation use the same tool
• If you are using a CASE tool to map associations
  to code, use the tool to change association
  multiplicities.
• Keep the contracts in the source code, not in the
  object design model
• By keeping the specification as a source code
  comment, they are more likely to be updated when
  the source code changes.
• Use the same names for the same objects
• If the name is changed in the model, change the
  name in the code and or in the database schema.
• Provides traceability among the models
• Have a style guide for transformations
• By making transformations explicit in a manual,
  all developers can apply the transformation in
  the same way.

33
DESIGNING DATA ACCESS AND MANIPULATION CLASSES

• Design data access and manipulation classes
• Prevent data management functionality from
  creeping into the problem domain classes

34
Entreprise Java Beans (see tutorials)
35
Global Resource Handling

• Discusses access control
• Describes access rights for different classes of
  actors
• Describes how object guard against unauthorized
  access

36
Defining Access Control

• In multi-user systems different actors have
  access to different functionality and data.
• During analysis we model these different accesses
  by associating different use cases with
  different actors.
• During system design we model these different
  accesses by examing the object model by
  determining which objects are shared among
  actors.
• Depending on the security requirements of the
  system, we also define how actors are
  authenticated to the system and how selected data
  in the system should be encrypted.

37
Access Matrix

• We model access on classes with an access matrix.
• The rows of the matrix represents the actors of
  the system
• The column represent classes whose access we want
  to control.
• Access Right An entry in the access matrix. It
  lists the operations that can be executed on
  instances of the class by the actor.

38
Access Matrix Implementations

• Global access table Represents explicitly every
  cell in the matrix as a (actor,class, operation)
  tuple.
• Determining if an actor has access to a specific
  object requires looking up the corresponding
  tuple. If no such tuple is found, access is
  denied.
• Access control list associates a list of
  (actor,operation) pairs with each class to be
  accessed.
• Every time an object is accessed, its access list
  is checked for the corresponding actor and
  operation.
• Example guest list for a party.
• A capability associates a (class,operation) pair
  with an actor.
• A capability provides an actor to gain control
  access to an object of the class described in the
  capability.
• Example An invitation card for a party.
• Which is the right implementation?

39
Global Resource Questions

• Does the system need authentication?
• If yes, what is the authentication scheme?
• User name and password? Access control list
• Tickets? Capability-based
• What is the user interface for authentication?
• Does the system need a network-wide name server?
• How is a service known to the rest of the system?
• At runtime? At compile time?
• By port?
• By name?

40
Summary

• In this lecture, we reviewed the activities of
  system design
• Concurrency identification
• Hardware/Software mapping
• Model transformation
• Persistent data management
• Global resource handling
• Each of these activities revises the subsystem
  decomposition to address a specific issue. Once
  these activities are completed, the interface of
  the subsystems can be defined.