System Design

New Version for Fall 2014

References:

1. Bernd Bruegge and Allen H. Dutoit, "Object-Oriented Software Engineering", Third Edition, Chapters 5, 6, and 7

Overview

• This page of notes covers the steps needed to develop an overall object-oriented system design, starting from the completed requirements, without consideration for the internal details of any objects or classes. It corresponds roughly to three chapters of the Bruegge and DuToit textbook:
  • Analysis - Preliminary identification of the most important and most obvious classes needed, along with their actions and interactions during the use-cases developed during the requirements phase. This phase will produce sequence diagrams, class diagrams, and possibly others such as state-machine diagrams or actifvity diagrams.
  • Decomposing The System - Based on structural analysis, commonly used architectures, and other considerations, divide the classes into subsystems, as illustrated in deployment diagrams.
  • Addressing Design Goals - Adjusting the system design so as to improve certain desirable qualities, such as performance, security, capacity, or resilience to adverse conditions.
  • Reviewing the Completed System Design - Checking for completeness, consistency, quality, verification, and validation. Ensuring that all use-cases have been accounted for, including exceptional and supporting cases.
  • Some additional classes, subsystems, and/or use-cases may be identified during any of the latter phases, such as communications systems to connect the other parts, caching classes to speed up performance, or a backup recovery system in the event of a power loss during operations.

  

  

  • Excerpt from the SE Process Flow Diagram:

  

   

Analysis

• The analysis phase produces a preliminary model of the system, in terms that the client can understand.
  • Objects identified at this stage are limited to those that the client can see and understand. Internal implementation details are not included at this time.
  • Specifically three types of objects are identified:
    • Entity objects represent entities in the client's problem domain, such as memos, meetings, budgets, deadlines, etc., both tangible and intangible.
    • Bondary objects provide the user interface for the system, such as forms, menus, dialog boxes, etc. These are parts of the system which are visible to the clients and users. ( Classes for interfacing with non-human external systems would also fall into this category. )
    • Control objects encapsulate the control logic for each use-case, ensuring the right steps occur in the right order.
• The overall goal is to identify as many potential objects as possible, and to document the relationships between them as they participate in acting out use-cases. ( E.g. inheritance, aggregation, etc. )

Identifying Entity Objects

• One common approach to identifying entity objects involves grammatical analysis of the project description, scenarios, and use-cases:

Identifying Boundary Objects

• Boundary objects represent an inteface as a whole, not the individual components that make it up. For example a data entry form would be a boundary object, but the individual fields, radio buttons, checkboxes, etc. on the form would not be modelled at this time.

Identifying Control Objects

Mapping Objects to Use-Cases with Sequence Diagrams

• Sequence diagrams document the classes / objects that participate in a particular use-case, the sequence of actions that each one takes during the use-case, and the sequence of messages that are passed ino order to execute the use-case.
• Modelling all use-cases as sequence diagrams helps:
  • Clarify the responsibilities of classes.
  • Identify missing classes.
  • Identify unneeded classes.

Modeling Object Interations with CRC Cards

• CRC ( Class, Responsibility, Collaborators ) cards are an alternative to sequence diagrams.
• Each potential class is represented by a separate ( 5 x 7 ) card, titled with the name of the class.
• Use-cases are acted out, with each CRC card "playing their part", much like a multi-person role-playing game.
  • As this occurs, the responsibilities of each card ( class ) are clarified, and written down on the cards, as are the list of other cards ( classes ) that this one collaborates with during the use case.
• As with sequence diagrams, this approach helps to clarify the responsibilities of each class, identify missing or unneeded classes, and to identify associations between related classes.

Identifying and Documenting Associations, Including Aggregations and Inheritance

• As the relationships between classes paticipating in use-cases are determined, they can be documented in preliminary class diagrams.
• Include information about roles, multiplicities, etc. to the extent that they are known.
  • Inheritance relationhips are more likely to be identified later, during system refinement.
• Try to avoid making diagrams that are overly cluttered. Use multiple separate diagrams as necessary for clarity.

Modelling State-Dependent Behavior of Individual Objects

• In some cases it can be beneficial to concentrate on the behavior of an individual object, to see what state transitions it undergoes in response to what events.
• This may help identify missing use-cases and undocumented behavior.
• In general this approach is most appropriate for control objects, less so for entity objects and rarely if ever for bondary objects.

• Besides state-machine diagrams, activity diagrams can also be helpful to illustrate responsibilities and the order of events:

Reviewing the Analysis Model

• The analysis model ( sequence diagrams, class diagrams, CRC cards, etc. ) is developed iteratively over a long time period by many people working together.
• It is never completely right on the first pass, and in general requires several reviews with the client to refine it.
• Initially the analysis model changes rapidly and significantly. Over time it matures, and begins to stabilize.
  • Avoid the temptation to put in too much detail before the model has stabilized.
• Periodically and certainly at the end the model must be reviewed for:
  • Correctness
  • Completeness
  • Consistency
  • Realism

Summaryof the Analysis Process

ARENA Case Study - Analysis

Decomposing The System

Once a preliminary set of classes and their relationships to each other have been identified, the next step is to break the overall system down into suitable subsystems, based on the structure of the class diagram, the semantics of the problem, and commonly used architectures.

Subsystems

• A subsystem is a collection of classes that serves as a replaceable part of the system, with a well defined interface to the rest of the system, and a well-defined set of responsibilities or services provided by the subsystem.

• Coupling is the connectedness betwen different subsystems. A good design will have minimal coupling.
• Cohesion is the bonding of classes within a subsystem. A good design will have high cohesion.

Architectural Styles

• There are a number of well-known and commonly used approaches to organizing the subsystems of a system, known as architectural styles. Knowing, understanding, and using these styles can help produce better system designs.

Repository

Model/View/Controller

Client-Server

Peer-to-Peer

Pipe-and-Filter

Example - The Open GL Graphics Processing Pipeline:

Example - Scientific Visualization with AVS:

Layered Architectural Styles

 

Three-Tier

Four-Tier

Example: From Objects to Subsystems

Starting Point: Analysis Model for a Route Planning System

Identifying Design Goals ( See Below )

Identifying Subsystems

Addressing Design Goals

Adjusting and refining the design so as to optimize certain desirable properites, such as peformance, security, capacity, or resilience.

• Design Goals are properties of the system that designers should try to optimize as much as possible.
  • The distinction between design goals and requirements are that requirements have a specific value that must be attained in order for the solution to be acceptable.
  • The same property may be specified in both a requirement and a design goal.
    • Example requirement: The system must be able to process at least 100 transactions per minute.
    • Example design goal: The system should process as many transactions per minute as possible.
• Consider the following design for the construction of a house:
  • Requirements: At least 2 bedrooms, 1 bathroom, 1 kitchen, 1 dining room, and 1 study.
  • Design goals: Minimize walking, maximize use of natural light ( coming predominately from the south. )

Some Criteria to Consider When Identifying Design Goals

Performance Criteria

Dependability Criteria

Cost Criteria

Maintenance Criteria

End User Criteria

Activities to Refine and Complete the Design, and to Address Design Goals

Map subsystems to hardware / software platform(s)

Manage persistent data

• Persistent data is any information that must be retained when the system is shut down, so that it can be restored to memory when the system resumes.
• Not all data in a program needs to be persistent.
  • An important task at this stage is to identify what data must be persistent and what can be re-calculated when the system starts up.
• There are three main types of storage options, which have different trade-offs with respect to storing object data:
  • Flat Files are ordinary text or binary files on the filesystem. Typically each line ( or entry ) in the file corresponds to one object, and holds all the information needed to describe / build that object.
  • Relational Databases are special files implemented by a database programs, and often involve "pointers" in one file that refer to entries in other files. For example there might be one file of addresses and a separate file of names, so that if multiple people live at the same address, then the address only needs to be stored one time, and is "pointed to" by all the names that live at that address.
  • Object-oriented databases are specialized to handle the particular characteristics of objects, including inheritance, aggregation versus composition, abstract classes, templates, etc.

  

  

Define access control policies

Access Control Matrix

• One view of access control is to establish an access control matrix, defining which actor(s) have what kind of access ( if any ) to each of the object(s) for which access control is deemed necessary.
  • Types of access may include read, write, execute, copy, change permissions, change ownership, distribute, or specialized access.
• For example:

• Because the matrix is often sparse, there are three common ways to implement the concept:
  1. As a two-dimensional table, where each table entry is a list of the permissions granted to that actor accessing that object.
  2. As capability lists - one linked list for each actor, describing all of the capabilities of that actor, where each node on the list corresponds to a separate object.
  3. As access control lists - One linked list for each object, listing which actors have what access to this object, where each node corresponds to a separate actor.
• With any of these schemes there are also provisions for specifying default access if not otherwise specified, either globally or per actor or per object ( or combinations thereof. )

  Firewalls, with Packet Filtering Rules

Dynamic Access Control

Encryption

Select a global control flow

Procedure-Driven Control

Event Driven Control

Threads

Identify Services

Describe boundary conditions

• Configuration ( System Setup )
• Start-up and Shutdown
• Exception Handling
• General System Maintenance

Reviewing the Completed System Design

Verifying that the final system design is:

• correct
• consistent
• realistic
• readable
• complete, including the handling of support cases and exceptional events.

Arena Case Study

See textbook