Design

1
Design

• Yaodong Bi

2
Introduction to Design

• Purposes of Design
• Acquire a good understanding of issues regarding
  nonfunctional requirements and constraints
• Capture requirements for individual subsystems,
  interfaces, and classes for implementation
• Decompose implementation work into pieces for
  different development teams.
• Create a seamless abstraction of the systems
  implementation so the implementation fills in the
  meat with no changes to the structure.

3
Analysis Model and Design Model

• ANALYSIS MODEL
• Conceptual model
• Use three conceptual stereotypes of classes
• Few layers
• Dynamic, but not on sequencing
• Fewer Elements
• Define a structure that is used for shaping the
  system

• DESIGN MODEL
• Physical model
• Use any number of physical stereotypes of classes
• Many Layers
• Dynamic, focus on sequencing
• More elements (15 ratio)
• Shape the system while trying to preserve the
  analysis structure

4
Artifacts of Design - Overview

• Design model
• Design classes
• Use-case realization design
• Design subsystems
• Interfaces
• Architecture description (view of the design
  model)
• Deployment model
• Architecture description (view of the deployment
  model)

5
Artifacts Design Model

• Design model
• Describe the physical realization of use-cases by
  focusing on how functional and nonfunctional
  requirements and constraints impact the system
• Serve as an abstraction of the systems
  implementation.
• Contain design subsystems, design classes,
  use-case realization-design, interfaces

6
Artifacts Design Classes

• Design classes
• A seamless abstraction of a class in
  implementation
• A design class may be given a stereotype that can
  be seamlessly mapped to a construct in the
  implementation language (ltltformgtgt, ltltclass
  modelgtgt)
• The language for coding is used to specify design
  classes
• The visibility of operations and attributes can
  be mapped to implementation directly
• Methods of a design class have a straightforward
  mapping to implementation of the methods
• Some requirements may be postponed to
  implementation as implementation requirements

7
Artifacts Use-Case Realization

• Use-case realization design
• Describe how a use-case is realized using design
  classes and design subsystems
• Each use-case realization-design can be traced
  back to the use-case realization analysis
• Handle nonfunctional requirements as well as
  functional requirements of the use case
• Consist of
• Class diagrams participating classes and
  subsystems
• Interaction diagrams (sequence diagram) flow of
  interactions between participating objects
• Textual flow-of-events description
• Implementation requirements

8
Artifacts Design Subsystem

• Design subsystems
• Subsystems should be loosely coupled and cohesive
  in each
• Separate design concerns
• Top two levels of subsystems can be mapped
  directly back to packages in analysis model
• Represent large-grained components in the
  systems implementation
• Represent reused software products
• Represent legacy systems

9
Artifacts - Interfaces

• Interfaces
• Specify the operations provided by design classes
  and subsystems
• A design class (subsystems) must provide at least
  one method for each operation of the interface.
• Operations vs. methods separate the
  specification of a function from its
  implementation
• Most interfaces between subsystems are
  architectural significant.

10
Artifacts Architecture (Design)

• Architecture description (view of the design
  model)
• Subsystems, their interfaces, and dependencies
  between them
• Key design classes including active classes,
  significant design classes.
• Use-case realizations design that realize
  important and critical functionality that needs
  to be implemented.

11
Artifacts Deployment Model

• Deployment model
• Describe the physical distribution of the system
  among computational nodes
• Each node represents a computational resource
• Describe how nodes are connected together
  (internet, intranet, bus, etc)
• May describe multiple configurations including
  testing and simulation configuration
• Manifest a mapping between the software
  architecture and the system (hardware)
  architecture.

12
Artifacts Architecture (Deploy.)

• Architecture description (view of the deployment
  model)
• All aspects of the deployment model should be
  shown in this description.
• Include the mappings of components on nodes as
  found during implementation.

13
Activities of Design - Overview

• Architectural Design
• Outline the design and deployment models and
  their architecture.
• Design Use-Cases
• Use design classes to realize use-cases and
  specify implementation requirements

14
Activities of Design - Overview

• Design Classes
• Create design classes that fulfill their roles in
  use-case realizations and the nonfunctional
  requirements that apply to them.
• Design Subsystems
• Ensure loose coupling between subsystems and
  ensure that they fulfill their purpose in
  use-case realization

15
Architectural Design - Purpose

• Purpose of architectural design
• Outline the design and deployment models and
  their architectures by identify the following
• Nodes and their network connections
• Subsystems and their interfaces
• Architecturally significant design classes
• Generic design mechanisms that handle common
  requirements on persistency, distribution,
  performance, etc
• Various reuse possibilities are considered.

16
Architectural Design - Deployment

• Identify nodes and network configurations
• Network configuration has a major impact on the
  software architecture. (p234, Fig 9.18)
• Three-tier architecture, client/server
  architecture
• Aspects of network configuration
• The processing power of each node
• The connections and protocols between nodes
• Characteristics of the network bandwidth,
  availability, etc
• Any need for redundant processing power?

17
Architectural Design - Subsystems

• Identify subsystems and their interfaces
• Identify application subsystems (p235, Fig 9.19)
• Identify subsystems in the application-specific
  and application-general layers
• Analysis packages may be designed as subsystems
  (p235 Fig 9.20)
• A refinement may be needed to accommodate (p236
  Fig 9.21)
• Part of an analysis package can be shared by
  others (P237 Fig 9.22)
• Parts of an analysis package can be realized with
  reused software
• An analysis package does not divide work properly
• Legacy systems
• Allocation to the nodes of the deployment model
  (p238 Fig 9.23)

18
Architectural Design - Subsystems

• Identify middleware and system-software
  subsystems (p238, Fig 9.24, p239, example)
• Identify DBMSs, operating systems, compiler, GUI
  kits
• Limit the dependency on middleware and system
  software
• Define subsystem dependencies (p241 Fig 9.26)
• Identify subsystem interfaces (p242 Fig 9.2728)
• Define operations that are accessible from
  outside
• The operations must be provided by classes or
  other subsystems (recursively)

19
Architectural Design - Classes

• Identify architecturally significant design
  classes
• Identify design classes from analysis classes
• Use analysis classes as design classes
• Use relationships among analysis classes for
  relationships among design classes
• A design class that does not participate in any
  use-case realization is unnecessary.
• Identify active classes (p245 Fig 9.30)
• Identify active classes based on performance
  concern
• Identify active classes for inter-node
  communication

20
Architectural Design - Classes

• Identify active classes based on requirements
  like deadlock avoidance, system startup, system
  termination.
• Active classes are outlined by considering how
  their objects communicate, synchronize, and share
  information.
• Active objects are allocated to the nodes (p245
  Fig 9.30)
• Processing power and memory of each node
• Connections between nodes, bandwidth,
  availability, etc
• An active object is a candidate for an executable
  component for implementation

21
Architectural Design Generic mechanism

• Identify generic design mechanisms
• Handle common requirements like
• Persistency (relational DBMS or OODBMS) (p247,
  top)
• Transparent object distribution (Java RMI, Corba)
  (p246)
• Security features (encryption techniques)
• Error detection and recovery
• Transaction management
• Identify generic collaborations as patterns for
  multiple use cases (p247, bottom, p248 fig
  9.3233)

22
Design Use Cases Purpose

• Identify participating design classes
• Describe design object interactions
• Identity participating subsystems and interfaces
• Describe subsystem interactions
• Capture implementation requirements

23
Design Use Cases Design classes

• Identify participating design classes (p251 Fig
  9.35)
• Identify design classes that trace back to
  analysis classes of the use case
• Identify design classes that realize special
  requirements of the use case
• Use a class diagram to show participating design
  classes for each use-case realization

24
Design Use Cases Interactions

• Describe design object interactions
• Use a sequence diagram to describe how they
  interact with each other to realize each use case
• Sequence diagram (p252 Fig 9.36)
• The use case is invoked by an actor
• Each design class identified for the use case
  must participate in the diagram
• Each message may become the name of an operation
• Use labels and flow-of-events to complement the
  diagram
• New alternative paths may be added to handle
  exceptions like time-out, erroneous inputs, error
  message from middleware, system software, etc.

25
Design Use Cases Subsystems

• Identity participating subsystems and interfaces
• Design a use case using subsystems (p254 Fig
  9.37)
• Identify design subsystems that trace back to
  analysis packages
• Identify the design classes that are used to
  realize special requirements of the use case and
  identify those subsystems that contain those
  classes
• Use class diagram to identify dependencies
  between packages and interfaces of packages (p254
  Fig 9.37)

26
Design Use Cases Sub. Interactions

• Describe subsystem interactions
• Describe how classes objects interact with each
  other on a subsystem level (p254 Fig 9.38)
• Use sequence diagrams
• Qualify the message with the interface when a
  subsystem provides more than one interface
• Capture implementation requirements
• Capture all requirements that should be handled
  in implementation (p255 example)

27
Design Classes - Purpose

• Outline the design classes
• Identify operations
• Identify attributes
• Identify associations and aggregations
• Identify generalizations
• Describe methods
• Describe states
• Handling special requirements

28
Design Classes - Outlining

• Outline the design classes
• Designing boundary classes depends on the
  specific interface technologies in use
• Designing persistent entity classes generally
  imply using a specific database technology,
  RDBMS, OODBMS, etc
• Designing control classes
• Distribution if the sequence is distributed
  among several nodes, separate classes on
  different nodes may be needed
• Performance control classes may be realized by
  boundary and/or entity classes
• Transaction design must encapsulate existing
  transaction technologies
• Design classes should be assigned trace
  dependencies to their corresponding analysis
  classes

29
Design Classes - Operations

• Identify operations (p258 Fig 9.40)
• Identify the operations of each design class
• Describe those operations in the programming
  language
• Specify the visibility of each operation (public,
  private, etc)
• Important inputs
• The responsibilities of the parent analysis
  classes
• The special requirements of the parent analysis
  classes
• The interfaces that the design class must provide
• Roles the class plays in use-case realizations -
  design

30
Design Classes - Attributes

• Identify attributes
• Identify attributes for each design class
• Specify the attributes in the programming
  language
• Guidelines
• Consider the attributes of the parent analysis
  class
• If an attribute is complicated, design it as a
  class
• Identify associations and aggregations
• Instances of associations might be used to hold
  references to other objects
• The number of relationships between classes
  should be minimized.

31
Design Classes - Generalizations

• Identify generalizations (p260, Fig 9.41)
• Generalization should be used with the same
  semantics as defined in the programming language
• If the programming language does not support
  generalization, use association and/or
  aggregation
• Describe methods
• Methods describe how operations are realized
• They can be specified in natural language or
  pseudocode
• They are generally completed during implementation

32
Design Classes - States

• Describe states (p261 Fig 9.42)
• Some objects are state-controlled their state
  determines the behavior when they receive a
  message
• Use statechart diagram to describe state
  transition
• Handling special requirements
• Handle any requirements that have not been
  considered yet.
• Handle those requirements using generic design
  mechanisms
• Some requirements may be postponed to
  implementation as implementation requirements

33
Design Subsystems - Purpose

• Maintain the subsystem dependencies
• Maintain the subsystem interfaces
• Maintain the subsystem contents

34
Subsystems - Dependencies

• Maintain the subsystem dependencies
• Define dependencies when elements of one
  subsystem are associated with elements of other
  subsystems
• Define dependencies when one subsystem uses the
  interfaces provided by other subsystems
• Interface dependency is better than
  content/element dependencies
• Minimize the dependencies to other subsystems
  and/or interfaces

35
Subsystems - Interfaces

• Maintain the subsystem interfaces
• The operations of a subsystems interface must
  support all the roles the subsystem plays in all
  use-case realizations

36
Subsystems - Contents

• Maintain the subsystem contents
• A subsystem must provide a correct realization of
  the operations defined in its interfaces
• Each interface of the subsystem must be realized
  by design classes and/or subsystems (recursively)
  (p264, Fig 9.45)
• Collaborations among the elements of a subsystem
  may be specified to show how the subsystems
  interfaces are realized

37
Summary of Design

• Design Model includes
• Design subsystems and service subsystems and
  their dependencies, interfaces, and contents
• Design classes, including active classes, and
  their operations, attributes, relationships and
  implementation requirements
• Use-case realization design
• Architectural view of the design model

38
Summary of Design

• Deployment Model includes
• Nodes, their characteristics, and connections
• Initial mapping of active classes onto nodes
• Architectural view of the deployment model

39
Summary of Design

• Connection to Implementation
• Design subsystems and service subsystems will be
  implemented by implementation subsystems on a
  one-to-on basis
• Design classes will be implemented by file
  components that contain source
• Multiple classes may be in one single file
  component
• Heavyweight active classes may be mapped to
  executables
• Use-case realizations-design will be used for
  implementation planning, each build may implement
  a set of use-case realizations
• Deployment model and network configurations will
  be used when executable components are
  distributed to nodes.