System Design -- Part 2

Identifying Design Goals

• In the process of going from the analysis model to building the system design, design goals must be identified.
• These will identify qualities that the system must focus on, so that design decisions can be based on a specific set of criteria
• Some design goals will come right from the non-functional requirements
• Others must be elicited from the client
• The overall design goals should be decided upon early in the system design process, since they will contain priorities that the rest of the system design must consider

Some Criteria for Design Goals

• Performance Criteria
  • Response time -- how soon are user requests acknowledged?
  • Throughput -- how many tasks can the system accomplish in a certain amount of time?
  • Memory requirements -- How much space is required?
• Dependability Criteria
  • Robustness -- how does the system cope with invalid user input?
  • Reliability -- difference between specified and observed behavior
  • Availability -- percentage of time the system can be used to accomplish normal user tasks
  • Fault tolerance -- how does it handle erroneous conditions?
  • Security -- how does it withstand malicious attacks?
  • Safety -- ability to avoid endangering human lives, even through errors and failures
    • This one is very important!
    • Ex: onboard system of an airplane, software running an x-ray machine, etc
• Cost criteria
  • Development cost -- intial system development
  • Deployment cost -- installation and training
  • Upgrade cost -- translating data from previous system, backwards compatibility requirements?
  • Maintenance cost -- bug fixes and future enhancements
  • Administration cost -- cost of running the system
• Maintenance criteria
  • Extensibility -- how easy to add functionlity
  • Modifiability -- how easy to change functinality
  • Adaptability -- how easy to adapt to different applcation domain
  • Portability -- how easy to port to a differentcomputer platform
  • Readability -- how easy to understand the coed
  • Tracability of requirements -- mapping of code to requirements
• End-user criteria
  • Utility -- how well does it support the end user's work?
  • Usability -- how easy is it to use?

Example: Design Goals for a Client/Server system

• Portability
  • Server can be installed on a variety of machines and operating systems and functions in a variety of networking environments
• Transparency
  • The server might itself be distributed,but should provide a single "logical" service to the user
• Performance goals
  • Client should be customized for interactive display-intensive tasks
  • Server should provide CPU-intensive operations
• Scalability
  • Server has spare capacity to handle larger number of clients
• Flexibility
  • Should be usable for a variety of user interfaces
• Reliability
  • System should survive individual node and/or communication link problems

Design Goal Trade-offs

• Inevitably, the design goals will have to be prioritized
  • It would be wonderful to have a system that is safe, secure, extensible, modifiable, delivered in a short amount of time, and cheap!
  • But is this realistic? BWAHAHAHA!!!
• There will have to be trade-offs, and decisions on which goals are most important to realize
• Examples of trade-offs
  • Space vs. speed -- More memory and storage can be expended to speed up a piece of software. But what if there are memory or storage constraints? Then storage can be compressed at the expense of speed
  • Delivery time vs. functionality -- If development runs behind, or if the allotted time is not realistic for the desired functionality, then there's a choice between: (1) less functionality, delivered on time, or (2) full functionality at a later date
  • Portability vs. Development cost -- Do we want the development of a program to be les expensive, or are we willing to pay more to make it work on multiple platforms. Consider off-the-shelf games, like Diablo 2 or Doom. Will the cost of developing for multiple platforms (like PC, Mac, Linux) pay off?

Identifying Subsystems

General guidelines for grouping objects into subsystems

• Assign objects relating to one use case to the same subsystem
• Create a subsystem for objects that control communication between subsystems
• Minimize associations and dependencies across subsystem boundaries (i.e. reduce coupling)
  • One way is to use the Facade Pattern (below)
• Objects in a subsystem should be related (i.e. increase coherence)

Facade Pattern

• Create a class to be a single interface for a subsystem
• Class acts as the sole point of entry and exit
• This class manages commication between outside subsystems and other internal classes
• Helps reduce coupling between subsystems

Other Issues

• Hardware/software mapping
• Data management
• Access control
• Global control flow
• Boundary conditions

Hardware/software mapping

• Selecting a hardware configuration -- must consider:
  • target platform(s)
  • operating system(s)
  • existing software components (for instance, to integrate with)
• Decisions about these might already be constrained by the client (non-functional requirements), or perhaps by cost considerations
• Allocate subsystems and objects to hardware nodes
  • How much new hardware will be needed?
  • Or can the system be installed on existing hardware?
  • Will this fit inside any cost design goals?
• UML Deployment Diagrams
  • A special type of UML diagram that depicts hardware nodes and the software components that will be placed on them.
  • Hardware nodes are 3-D boxes
  • Software components are represented with special "component icons", contained in the node boxes
  • Dependencies between components are represented with dashed arrows
  • See textbook page 263 for an example

Data Storage

• Persistent Data is data that needs to live beyond one run of a piece of software
  • Must be stored to persistent media -- disk, tape, etc
• Identifying persistent objects/data
  • Entity objects identified during analysis -- likely candidates for persistency
  • Not all entity objects will necessarily by persistent -- but a good place to start
  • Examine all classes that must survive system shutdown (controlled or unexpected). Good indicator of persistent data
• Should we choose storage in flat files or a database?
• Flat files -- when to use?
  • for very large data items (e.g. bitmap images)
  • for data that needs to be optimized in terms of size or speed
  • for data that will be kept only a short amount of time
  • for data with a low information density (i.e. doesn't need to be accessed so often. Examples: archive files, history logs)
• Database -- when to use?
  • for data that requires access at fine levels of detail by multiple users, possibly with concurrent access
  • for data that needs to be portable across multiple platforms
  • Do multiple application programs access the data?
  • Does data management require a lot of infrastructure? (attributes, records, in multiple categories
  • Will there be complex queries over attributes?

Access Control

• In a multi-user system, different actors have access to different functionality and data.
  • In many cases, access needs to be restricted to specific job functionality
  • Example: In a medical insurance claim/payment system, claims adjudicators (i.e. who decide on vailidity of payments) have access to the portion of the system that pays claims, but they should be restricted from entering new medical provider records and payment addresses (to prevent fraud)
  • Example: At the campus.fsu.edu system, instructors have the capability to look up rosters, but not to drop or add students. Students have the ability to drop or add on their OWN schedule, but not to look up other roster information (which contains Social Security numbers)
• So, how to plan access rights for different classes of actors?
  • Global access matrix -- a table of all actors and objects, where every cell in the matrix is a (actor, class, operation) tuple, indicating what actor has access to which operations (from which classes)
    • Pro: One master table with all access rights information
    • Con: Lots of empty cells
  • Access control list -- for each object, a list of who has access to which operations from the object.
  • Capability list -- for each actor, a list of what access right they have (classes and operations)
• How will unauthorized access be guarded against?
  • Authentication? -- username/password? smart card? retinal scan?
  • Encryption? -- useful for authentication and for guarding against interception of data transfer, like across a network

Control Flow

• Procedure driven
  • Operations wait for input only when they need data from an actor
• Event driven
  • A main loop waits for events to occur
  • E.g. a button click, a timeout
  • Typical for GUI interaction with actors
• Threads
  • Concurrent "“threas" of control in a program
  • Powerful, but harder to implement and test

Boundary Conditions

• Must address initialization and termination of system
• Initialization
  • How is the system brought up from a non-initialized state to steady state operation? (Start-up use cases)
• Termination
  • What resources are cleaned up and which systems are notified upon termination? (Termination use cases)
• Failure
  • Many potential causes: software bugs, user errors, hardware breakdowns, external factors
  • How will system recover and restart after a failure?
• Use cases that deal with these kinds of conditions are known as boundary use cases