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 system’s implementation so the implementation fills in the “meat” with no changes to the structure.

3. Analysis Model and Design 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 (1:5 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
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 system’s implementation.
Contain design subsystems, design classes, use-case realization-design, interfaces

6. Artifacts – 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 (<<form>>, <<class model>>)
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 system’s implementation
Represent reused software products
Represent legacy systems

9. Artifacts - 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
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 DBMS’s, 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.27&28)
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.32&33)

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 subsystem’s 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.