1. Analysis And Design Workshop
Presented By
Leslie Munday
Color-code title according to discipline color:
Disc: R G B
BM:
EA:
REQ:
ANAL:
DES: - same –
IMP:
Test:
Depl:
CM:
PM:
SQA:

2. Intended Audience Pre-reqs Courses Project Roles Other Exrperience
Requirements Modeling With Rational Rose
Project Roles
Developers, Analysts and Architects who will be modeling with Rational Rose
Other Exrperience
System use case modeling
Rational Rose modeling experience
UML (class, state and sequence diagram modeling)

3. Objectives for Class
To introduce analysis and design for small projects.
To give students opportunity to ‘practice’ analysis and design with Rational Rose.
To ensure that analysis and design artifacts are consistent across all programs.

4. RUP DISCIPLINE OVERVIEW (humpback whale chart)

5. Pre-requisite Class Terminology
Activity
A unit of work a role may be asked to perform.
Artifact
Any piece of information that is produced, modified, or used by an organization during the software development process. An artifact can be a model, a model element, software, code, or a document and are subject to version control.
Component
A model element (class, attribute, etc).
Role
A definition of the behavior and responsibilities of an individual, or a group of individuals working together within a software engineering organization. Role is not synonymous with AW Title, it specifies the ‘hat’ worn by the individual or group of individuals to perform a necessary Activity.
Step
A subactivity within an activity.

6. Pre-requisite Class Terminology
Workflow
The high-level sequence of activities performed that produce a result of observable value.
Workflow Detail
A grouping of activities which are performed in close collaboration to accomplish some result. The activities are typically performed either in parallel or iteratively, with the output from one activity serving as the input to another activity. Workflow details are used to group activities to provide a higher level of abstraction and to improve the comprehensibility of workflows.

7. Pre-Requisite Info UML, Rose, Requirements, Object-Oriented modeling.
‘What’ is a requirement.
‘How’ is about design.
Analysis determines the correctness of the requirements.
Design determines a solution to those requirements.

8. Workflows Of A&D Analysis and Design is concerned
Define a Candidate
Architecture
Refine the Architecture
Analyze Behavior
Design Components
More Iterations?
Analysis & Design Workflow Overview
Maintain Data Dictionary
[ Yes ]
[ No ]
Analysis and Design is concerned
with building an Object-Oriented
design that is consistent with the
requirements for the
system. Workflows are:
Define a Candidate Architecture
Analyze Behavior
Refine the Architecture
Design Components
Maintain A Data Dictionary

9. Activities Of Analysis And Design

10. Analysis And Design Artifacts
Analyst – Responsible for maintaining data definitions.
Designer – Responsible for design model(design classes, design packages, interfaces, test classes, design subsystems), SUCRs, data model.
Architect - Responsible for ACF, Deployment model, POC, design model(
sequence diagrams), SAD.
Developer – Responsible for system interface agreements.

11. Artifacts Of A&D (Components)
The components output from Analysis and Design includes:
Analysis Class - <boundary>, <control> or <entity>, is used to realize classes from use cases.
Attribute – An attribute defined by a class represents a named property of the class or its objects.
Class – a set of objects that share the same attributes, operations, relationships and states.
Design Class – an implemented set of objects.
Design Package - a collection of design artifacts and other packages.
Design Subsystem - realizes one or more interfaces.
Event - an instantaneous occurrence that can trigger a transition between states.
Interface - A collection of operations that are used to specify a service of a component.
Method – the algorithm or procedure that implements an operation.
Object – an entity with a well-defined boundary and identity that encapsulates data, state and behavior.
Operation - a service that can be requested from an object to effect behavior.
Relationship - A semantic connection among model elements.
State – A condition or situation during the life of an object during which it satisfies some condition, performs some activity, or waits for some event.
Test Class – used to identify the test-specific functionality to facilitate or automate tests.

12. Artifacts Of A&D (Diagrams)
The diagram types that are produced during Analysis And Design include:
Class Diagram – shows a collection of classes, packages, and their contents and relationships.
Sequence Diagram - describes a pattern of interaction among objects, arranged in a chronological order .
Collaboration Diagram - describes a pattern of interaction among objects.
Statechart Diagram - specifies the behavior of an element, defining its response to events and the life cycle of the element.
System Use Case Realization - describes how a particular use case is traced to the design model.
Application Reference Architecture - a predefined architectural pattern.
Activity Diagram – may be used to describe the operation of a model component.

13. Artifacts Of A&D (Documents and Models)
Software Architecture Document - a comprehensive architectural overview of the system.
System Interface Agreement - is used to capture the analysis and design of a system interface.
Analysis And Design Model – is where analysis and design classes, diagrams and supporting artifacts are captured.
Data Model – used to capture data definitions used by the analysis and design model.
[These documents are created during Enterprise Architecture and updated in Analysis And Design.]

14. The Purpose Of A&D
The design model - required as an input to the implementation discipline and used by developers to determine classes, operations attributes and real-time issues.
The deployment model - used by the deployment discipline and by the software architect, to capture the physical execution environment of the system, and to understand distribution issues.
The data model – used by developers to determine the data used in the software.
Software Architecture Document – used by developers to determine additional design information not captured by the model.
System Interface Agreement – used by developers to design external system interfaces.

15. Views
Implementation View - describes the organization of the static software elements (code, data, and other accompanying artifacts) in the development environment.
Process View – describes the concurrent aspects of the system tasks and their interactions.
Deployment View - shows the configuration of processing nodes as they will be at run-time.
Logical View - describes the logical and physical representation of persistent data in the system.

16. Implementation View In Rose it is known as the Component View.
Describes the organization of static software modules (source code, data files, executables, documentation etc.) in the development environment.
Typically the implementation view contains the
following:
An enumeration of all subsystems in the implementation model,
Component diagrams illustrating how subsystems are organized in layers and hierarchies.
Illustrations of import dependencies between subsystems.
used in the context of configuration management on the project.
The implementation view is useful for:
Assigning implementation work to individuals (and teams) or subcontractors.
Assessing the amount of code to be developed, modified, or deleted.
Reasoning large-scale reuse.
Considering release strategies.

17. Process View
Consists of the processes and threads that form the system’s
concurrency and synchronization mechanisms, as well as their
interactions
Addresses issues such as:
Concurrency and parallelism (e.g. synchronization, deadlocks etc.)
Fault tolerance (e.g. isolation of functions and faults, reliability)
System startup and shutdown
Object distribution
Performance (response time, throughput) and scalability
Is captured using class, interaction and statechart diagrams with a focus on active classes and objects.

18. Deployment View
Shows how the various executables and other runtime entities are mapped to the underlying platforms or computing nodes.
Addresses issues such as:
Deployment
Installation
Maintenance

19. Logical View This is the view used by analysis and design.
Where most analysis and design components are located.

20. Example (Patron at Library)
Handout:
SAD Template,
and SIA Template.

21. Analysis And Design: Introduction
Five Workflows
Define A Candidate Architecture
Refine The Architecture
Analyze Behavior
Design Components
Maintain Data Dictionary
Cant split exactly into analysis and design, but most analysis activities occur prior to design activities.

22. Discipline Purpose To realize a design from the requirements.
To create a robust architecture.
To adapt the design to work with the implementation environment.
To design for performance.
To build approved system interfaces.

23. Context Requirements provides the inputs.
The design is used to test the system.
The environment delivers supporting information.
Project management plans iterations from the design.
CCM is used to maintain and control the A&D artifacts.

24. What Is Covered By Analysis And Design?
Define A Candidate Architecture
Architectural Analysis
Cant split exactly into analysis and design, but most analysis activities occur prior to design activities.

25. Define Candidate Architecture
Why – To make an initial attempt at defining the architecture.
When – During elaboration.
What – Creates an initial high-level design model from the architecturally significant use cases.

26. Architecture Architecture = Elements + Form + Rationale
Elements – Classes, packages/subsystems.
Form – Patterns, behavior, collaborations and relationships,
Rationale – Decisions, interfaces, external influences.

27. Architecture
Involves a set of strategic design decisions, rules, patterns that contain design and construction.
Static – Subsystems/packages, attributes, class diagrams.
Dynamic – Activity diagrams, states, sequence diagrams, operations/methods.

28. Workflow Details Diagram

29. Workflow Sequence Diagram
Role – Architect.
Input – Architecture Domain Model, Design Guidelines, System Use Case Model.
Output – Software Architecture Document, Deployment Model.

30. Perform Architecture Analysis
To define a candidate architecture for the system, based on experience gained from similar systems or in similar problem domains.
To define the architectural patterns, key mechanisms and modeling conventions for the system.
To define the reuse strategy.
To provide input to the planning process.

31. Perform Architectural Analysis

32. Draft Key Abstractions

33. Draft Key Abstractions
Input:
Stakeholder Requests.
Process:
Identify preliminary entity classes.
Define any relationships that exist between entity classes.
Create a short description for each.
Look for patterns, which capture many of the key abstractions required to model the system.
The purpose of this step is not to identify a set of classes that will survive throughout design, but to identify the key concepts the system must handle.
Output:
Classes.

34. Stakeholder Request

35. Class

36. Define High-Level Organization Of Subsystems

37. Define High-Level Organization Of Subsystems
Inputs:
System Use Cases, Design Guidelines.
Process:
During architectural analysis, focus is normally on the two high-level layers, that is, the application and business-specific layers; this is what is meant by the "high-level organization of subsystems“.
Outputs:
Design Model.

38. System Use Case

39. Design Model

40. Define High-Level Deployment Model

41. Define High-Level Deployment Model
Inputs:
Architecture Domain Model, System Use Case Model.
Process:
Create the High Level Deployment Model by doing the following:
1. Under the logical View package create a package called Deployment View.
2. Create two packages named ‘Systems’ and ‘Transaction Flow Diagrams’
3. In the Systems Package:
Create a package for each identified subsystem.
Within the system package create a proxy class with the same name as the system. This class will be used on the transaction flow diagrams.
For each system investigate the physical devices connected to the system that are significant to the project. Create a class for each device, stereotyped as Device.
Create a collaboration diagram to show the relationships between the system, use the proxy class, and the devices. Name the system object in the collaboration diagram Node and set the option to show class. Add objects for each device, named Device and set the option to show the class. Add the relationships between the node object (system) and the devices.
Outputs:
Deployment Model.

42. Architecture Design Model

43. High-Level Deployment Model
Shows devices and processors that the application is deployed to.

44. Review The Architecture

45. Review The Architecture
Inputs:
Design Model.
Process:
To validate that all architectural significant considerations have been captured, the architecture will need to be reviewed at key milestones (the completion of an iteration of an activity or step), ie.. draft high level deployment model, define high level organization of subsystems, identify analysis mechanisms.
Outputs:
Change Request, Review Record.

46. Design Model

47. Update The SAD

48. Update The SAD Inputs: Process: Outputs: Design Model.
5.1  Architecture Overview: Package and Subsystem Layering
7.  Deployment View
Outputs:
Software Architecture Document.

49. Topic 1: Class Work In Rose Logical View: Create a package
Create a class diagram
Add classes to the class diagram
Create a Deployment view package
Add classes, set stereotypes and create a deployment model.

50. What Is Covered By Analysis And Design?
Analyze Behavior
Perform Use Case Analysis
Identify Design Elements
Maintain system Interfaces
Review The Design
Cant split exactly into analysis and design, but most analysis activities occur prior to design activities.

51. Workflow Details Diagram

52. Workflow Sequence Diagram

53. Analyze Behavior
Why – To transform the behavioral descriptions provided by the use cases into a set of elements upon which the design can be based.
When – During elaboration and construction.
What – Initial design model comprising analysis classes, system use case realizations.

54. Perform Use Case analysis

55. Perform Use Case Analysis
Role - Designer.
Input – System Use Case Model, Design Model.
Output – System Use Case Realization, Analysis Class, Design Model.
Purpose:
To identify the classes which perform a use case’s flow of events.
To distribute the use case behavior to those classes, using use-case realizations.
To identify the responsibilities, attributes and associations of the classes.
To note the usage of architectural mechanisms

56. Perform Use Case Analysis

57. Find Classes From Behavior

58. Find Classes From Use Case Behavior
Input:
System Use Cases.
Process:
To identify a candidate set of model elements (analysis classes) which will be capable of performing the behavior described in use cases.
Output:
Analysis Classes.

59. System Use Case

60. Analysis Classes
Analysis classes - represent conceptual things which can perform behavior.
In design, analysis classes evolve into a number of different kinds of design elements:
classes, to represent a set of rather fine-grained responsibilities;
subsystems, to represent a set of coarse-grained responsibilities, perhaps composed of a further set of subsystems, but ultimately a set of classes;
active classes, to represent threads of control in the system;
interfaces, to represent abstract declarations of responsibilities provided by a class or subsystem.

61. Analysis Classes
The three perspectives are that of the boundary between the system and its actors, the information the system uses, and the control logic of the system.
Boundary, used to model interaction between the system's surroundings and its inner workings.
Control, used to model control behavior specific to one or a few use cases.
Entity, used to model information and associated behavior that must be stored.
The corresponding class stereotypes, boundary, entity and control, are conveniences used during Analysis that disappear in Design.

62. Boundary Class
Involves transforming and translating events and noting changes in the system presentation (such as an interface).
Boundary classes model the parts of the system that depend on its surroundings.
Common boundary classes include windows, communication protocols, printer interfaces, sensors, and terminals.

63. Control Class
Control objects (instances of control classes) often control other objects, so their behavior is of the coordinating type. Control classes encapsulate use-case specific behavior.
The behavior of a control object is closely related to the realization of a specific use case.
When the system performs the use case, a control object is created.
Control objects usually die when their corresponding use case has been performed.

64. Entity Class
Entity objects are used to hold and update information about some phenomenon, such as an event, a person, or some real-life object. They are usually persistent, having attributes and relationships needed for a long period, sometimes for the life of the system.
Entity objects represent the key concepts of the system being developed.
Entity classes show the logical data structure.

65. Restrictions Boundary classes: Control classes: Entity Classes
Communicate associations to Boundary classes.
Communicate or subscribe associations to an Entity class.
Communicate associations from to a Control class.
Control classes:
Communicate or subscribe associations to Entity classes, (because control objects might need to keep track of certain entity objects between actions in the control object, or be informed of state changes in the entity object).
Communicate associations to Boundary classes, allowing the results of invoked behavior to be communicated to the environment.
Communicate associations to Control classes, allowing the construction of more complex behavioral patterns.
Entity Classes
Entity classes may only be the source of associations (communicate or subscribe) to other entity classes.

66. Analysis Class Diagram

67. Create Use Case Realizations

68. Find Classes From Use Case Behavior
Input:
System Use Case, Analysis Model.
Process:
For each use-case create interaction diagrams depicting its participating objects and their interactions. Sequence diagrams show the explicit sequence of messages in order to visualize the time ordering of messages.
One sequence diagram the basic flow and one for each alternative/exception flow.
Output:
System Use Case Realization.

69. System Use Case

70. System Use Case Realization

71. Distribute Behavior To Classes

72. Find Classes From Use Case Behavior
Input:
Design Model.
Process:
Assign responsibilities to classes.
Convert the sequence diagrams to collaboration diagrams to show the communication links between objects.
Output:
Class (Operations).

73. Responsibilities
To document a class responsibility, you add an operation to the class. When you enter the operation name, precede it with two forward slashes (//). Using these special characters indicates that the operation is being used to describe the responsibilities of the analysis class.
Use the Documentation field of the Operation Specification to describe the responsibility.
A responsibility is a statement of something an object can be asked to provide. Responsibilities evolve into one (but usually more) operations on classes in design; they can be characterized as:
The actions that the object can perform.
The knowledge that the object maintains and provides to other objects.

74. Collaboration Diagram

75. Detail Class Attributes

76. Detail Class Attributes
Input:
System Use Case Realization.
Process:
Attributes are used to store information by a class. Specifically, attributes are used where the information is:
Referred to "by value"; that is, it is only the value of the information, not it's location or object identifier which is important. Uniquely "owned" by the object to which it belongs; no other objects refer to the information.
Accessed by operations which only get, set or perform simple transformations on the information; the information has no "real" behavior other than providing its value. If the information has complex behavior, is shared by two or more objects, or is passed "by reference" between two or more objects, the information should be modeled as a separate class.
The attribute name should be a noun that clearly states what information the attribute holds.
The attribute type references an element in the data dictionary.
Indicate an identifying attribute with a ‘*’ stereotype.
Output:
Classes (Attributes).

77. Class Attributes

78. Identify Class Associations

79. Associations Input: System Use Case Realization. Process: Output:
Associations between classes indicate that objects of the two classes communicate with one another. Once we start designing the system, these links may be realized in several ways:
The object may have "global" scope, in which case any object in the system can send messages to it
One object may be passed the second object as a parameter, after which it can send messages to the passed object
The object may have a permanent association to the object to which messages are sent.
The object may be created and destroyed within the scope of the operation (i.e. a 'temporary' object) - these objects are considered to be 'local' to the operation.
Focus only on associations needed to realize the use cases; don't add association you think "might" exist unless they are required based on the collaboration diagrams.
Give the associations roles/name and multiplicities.
Write a brief description of the association to indicate how the association is used, or what relationships the association represents.
Output:
Classes (Associations).

80. Types Of Relationship
Association - between two classes, each end of the association takes a cardinality.
Aggregation – between a whole class and a part class, is a type of association, but the whole class has cardinality of 0..1.
Composition – a type of aggregation where the whole class has cardinality of 1.
Associative class association – when cardinality of an association is many ‘*’ at both ends, look for an associative class attached to the relationship.
Generalization – Used to design supertypes and subtypes into the model.

81. Association
Associations represent structural relationships between objects of different classes; they represent connections between instances of two or more classes that exist for some duration.
You can use associations to show that objects know about another objects. Sometimes, objects must hold references to each other to be able to interact, for example send messages to each other.
Associations are binary (exist between exactly two classes), and are drawn as solid paths connecting pairs of class symbols. An association may have either a name or the association roles may have names at each end of the association.
Association names should reflect the purpose of the relationship and be a verb phrase. The name of the association is placed on, or adjacent to the association path.

82. Aggregation
Aggregation is used to model a containment relationship between model elements.
A hollow diamond is attached to the end of an association path on the side of the aggregate (the whole) class to indicate aggregation.
The contained (or part) class is given a cardinality.
An part may exist without the aggregate.

83. Composition
Composition is a form of aggregation with strong ownership and coincident lifetime of the part with the aggregate.
The aggregation is unchangeable, that is once established, its links cannot be changed.
Deletion of the whole deletes the parts. A part cannot exist without the whole.
A solid filled diamond is attached to the aggregate end of an association path to indicate composition.

84. Associative Relationship
An association class is an association that also has class properties (such as attributes, operations, and associations).
It is shown by drawing a dashed line, representing an associative relationship, from the association to a class that holds the attributes and operations describing the association.
As a minimum, the association class will contain all identifying attributes of the classes in the association.
The most common use of association classes is the reconciliation of many-to-many relationships.
A degenerate association class just contains attributes for the association.

85. Generalization
A generalization shows that one class inherits from another.
The inheriting class is called a descendant (subtype).
The class inherited from is called the ancestor (supertype).
Inheritance means that the definition of the ancestor - including any properties such as attributes, relationships, or operations on its objects - is also valid for objects of the descendant.
The generalization is drawn from the descendant class to its ancestor class.

86. Multiplicity
Indicates the cardinality of how many instances of a class participate in a relationship.
Multiplicity is indicated by placing a numeric expression on the role end of an association. The expression may be a comma-separated list of integer ranges, where a range is indicated by a lower value integer, two dots, and an upper value integer, or a single integer
The symbol '*' indicates "many", that is, an unknown, or unlimited, number of object instances.
Read the multiplicity as shown in the diagram below.

87. Class Associations

88. Hiding Attributes And Operations

89. Formalizing Relationships
Can be used to formalize the relationship.
A key attribute is the identifying attribute of a class that is used by related classes to access an instance of the class.
The direction of the key is dependent upon the cardinality of the relationship:
0..1 to *, 0..*, 1..* put the key on the many end.
0..1, 1 to *, 0..*, 1..* put the key on the many end
1 to 1 pick whichever is the more appropriate.
0..*, 1..*, * to 0..*, 1..*, * use an associative class to hold the keys.

90. Adding Key Attributes

91. Describe Event Dependencies
Input:
Statechart Diagram.
Process:
Map external events on statechart diagrams to objects on a collaboration diagram.
Update the statechart diagrams.
Update class diagrams.
Output:
Design Model.

92. Identify Design Elements

93. Identify Design Elements
Role – Application Architect.
Input – System Use Case Realization, Analysis Classes.
Output – Design Subsystem, Interfaces, Classes
Purpose:
To analyze interactions of analysis classes to identify design model elements.
To refine the analysis classes into appropriate design model elements.

94. Identify Design Elements

95. Identify Classes

96. Identify Classes Input: Process: Output: Analysis Classes.
When the analysis class is simple and already represent a single logical abstraction, it can be directly mapped, 1:1, to a design class. Typically, entity classes survive relatively intact into Design. Since entity classes are typically also persistent, determine whether the design class should be persistent and note it accordingly in the class description.
When identifying classes, they should be grouped into packages for organizational and configuration management purposes.
Output:
Design Classes.

97. Analysis Classes

98. Design Classes
Show analysis class diagram as design classes and subsystems.
What about traceability?????

99. Model Active Classes

100. Model Active Classes Input: Process: Output:
Classes, System Use Case Realizations.
Process:
Active classes have an associated state machine, which is modeled by a state transition diagram attached to the class. Is there a need for the system to respond to externally generated events, and if so, which analysis classes are 'active' when the events occur? Look at the corresponding Use-Case Realizations to see which objects interact when an event occurs.
The instances of active classes represent independent 'logical' threads of execution.
Use active classes to model analysis control classes.
Use active classes as internal representatives of external physical devices that are connected to a computer since those physical entities are inherently asynchronous. These "device driver" classes serve not only to monitor and control the corresponding physical devices but they also isolate the rest of the system from the specifics of the devices.
Use active classes is to represent logical concurrent activities. A logical activity represents a conceptual concurrent "object", such as, for example, a financial transaction or a telephone call.
Active classes are also useful as guardians of shared resources. In this case, one or more resources that are required by multiple concurrent activities are encapsulated within an active class. By virtue of their built-in mutual exclusion semantics, such guardians automatically protect these resources against concurrency conflicts.
Output:
Statechart Diagrams.

101. Statechart Guidelines
Begin with a start state.
Events cause transitions between states.
Events generate actions (which define operations on the class), or external events to other classes.
Update classes with operations used on statecharts.
Finish with an end state.
See Statechart Guidelines document.

102. Statechart Diagram

103. Describe Event Dependencies

104. Describe Event Dependencies
Input:
Statechart Diagrams.
Process:
Analyze events passing between objects.
Capture these on collaboration diagrams.
Create appropriate class operations.
Update sequence diagrams.
Output:
Design Model.

105. Identify Subsystems

106. Identify Subsystems Input: Analysis Classes. Process:
Complex analysis classes may be mapped to a design subsystem.
The design subsystem is used to encapsulate collaborations in such a way that clients of the subsystem can be completely unaware of the internal design of the subsystem.
A subsystem is a special kind of package which has only interfaces as public elements.
The decision to create a subsystem from a set of collaborating analysis classes is based largely on whether the collaboration can be or will be developed independently by a separate design team..
Output:
Design Subsystems.

107. Document Subsystem Interfaces

108. Document Subsystem Interfaces
Input:
Design Subsystems.
Process:
Using the grouped collaborations identified in the previous step, identify the responsibility which is 'activated' when the collaboration is initiated. Determine what information must be provided by the 'client' and what information is returned when the collaboration is complete. These sets of information become the prototype input and output parameters and return value for an operation which the subsystem will realize.
Define a name for this operation.
Group operations together according to their related responsibilities.
Where the same operations exist in several interfaces, re-factor the interfaces, extracting the common operations into a new interface.
In cases where the parameters are objects that realize a particular interface, define dependency relationships between the interface and the interfaces on which it depends.
Once interfaces have been identified, create realization associations between the subsystem and the interfaces it realizes.
Define the behavior specified by the interfaces with a state machine that illustrates the publicly visible states that any design element that realizes the interface must supports.
Interfaces should be grouped into one or more packages owned by the software architect.
Output:
Interfaces.

109. Maintain System Interfaces

110. Maintain System Interfaces
Role – Application Architect
Input – Design Model
Output – System Interface Agreements
Purpose:
To update external documentation to reflect changes to the design.

111. Maintain System Interfaces

112. Update SIAs Input: Process: Output: .
Update the System Interface Agreement documents interfacing with the system.
The SIAs are created during the enterprise architecture discipline, but their details will change as the design of one or both of the interfacing systems is developed.
Changes may occur to effect:
Event Modeling (Logical Elements)
Initial Information Mapping Analysis
Information Gap Analysis
Permitted Values (Reference Data, List of Values)
Supplemental Specifications.
Output:
System Interface Agreements.

113. Review The Design

114. Review The Design Role – Design Reviewers
Input – Design Subsystem, System Use Case Realization, Design Model, SIAs.
Output – Change Requests, Review Records
Purpose:
verify that the design model fulfills the requirements on the system, and that it serves as a good basis for its implementation.
ensure that the design model is consistent with respect to the general design guidelines.
ensure that the design guidelines fulfill their objectives.

115. Review The Design

116. Review Overall Design Model

117. Review Overall Design Model
Input: .
Process:
The design model as a whole must be reviewed to detect glaring problems with layering and responsibility partitioning. The purpose of reviewing the model as a whole is to detect large-scale problems that a more detailed review would miss.
Package and Subsystem dependencies should be examined to ensure loose coupling between packaging elements.
The contents of packages and subsystems should be examined to ensure high cohesion within packaging elements.
In general, all elements should be examined to ensure that they have clear and appropriate responsibilities, and that their names reflect these responsibilities.
Output:
Change Requests.

118. Review Model Behavior

119. Review Model Behavior Input: Process: Output:
System Use Case Realizations, Statechart Diagrams.
Process:
Once the structure of the design model is reviewed, the behavior of the model needs to be reviewed. First, make sure that there is no missing behavior by checking to see that all scenarios for the current iteration have been completely covered by use-case realizations. All of the behavior in the relevant use-case sub-flows must be described in the completed use-case realizations.
In cases where the behavior of the system is event-driven, you may have used statechart diagrams to describe the behavior of the use case. Where they exist, statechart diagrams need to be examined to ensure that they describe the correct behavior,
Make sure the behavior of the use-case realization is correctly distributed between model elements in the realizations
Make sure collaboration diagrams are consistent with statechart diagrams.
Output:
Change Requests.

120. Review Subsystems

121. Review Subsystems Input: Process: Output: Design Subsystems.
For each model element to which behavior is allocated, the internal design of the model element must be reviewed:
For subsystems, this means ensuring that the behavior specified in the interfaces the subsystem realizes has been allocated to one or more contained classes or subsystems.
For classes, this means that the description of each operation is sufficient defined so that it may be implemented unambiguously.
Output:
Change Requests.

122. Review System Interfaces

123. Review System Interfaces
Input: .
Process:
Ensure that the System Interface Agreement documents are consistent with the needs of the interfacing systems.
Ensure that the description of the interfaces matches that which was agreed upon.
Ensure that the interface is described in an unambiguous manner such that both teams have the same understanding of the interface.
The SIA is the agreed contract between the developers of two or more systems. The SIA must explicitly specify in an unambiguous manner all protocols and data interchange agreements between the systems affected by the SIA.
Output:
Change Requests.

124. Prepare Review Records

125. Prepare Review Records
Input:
Change Requests.
Process:
Following each review meeting, the results of the meeting must be documented in a Review Record. In addition, defects must be documented (and eventually assigned to someone to own and drive to resolution).
Output:
Review Records.

126. Topic 2: Class Work
In Rose Logical View:
TBA.

127. What Is Covered By Analysis And Design?
Refine The Architecture
Identify Design Elements
Incorporate Existing Design Elements
Review The Architecture
Cant split exactly into analysis and design, but most analysis activities occur prior to design activities.

128. Refine The Architecture

129. Refine The Architecture

130. Refine The Architecture
Why – Provide the natural transition from analysis activities to design activities, identifying appropriate design elements from analysis elements and maintain the consistency and integrity of the architecture, ensuring that:
new design elements identified for the current iteration are integrated with pre-existing design elements
maximal re-use of available components and design elements is achieved as early as possible in the design effort.
the organization of the system's run-time and deployment architecture is described.
the implementation model is organized to make the transition between design and implementation seamless.
When – During construction, after behavior has been analyzed.
What – Update the design model.

131. Identify Design Elements

132. Identify Design Elements
Slide 98.

133. Incorporate Existing Design Elements

134. Incorporate Existing Design Elements
Role – Application Architect.
Input – Design Model, Existing Components.
Output – Design Model, Subsystems, Interfaces.
Purpose:
analyze interactions of analysis classes to find interfaces, design classes and design subsystems.
refine the architecture, incorporating reuse where possible.
identify common solutions to commonly encountered design problems.
include architecturally significant design model elements in the Logical View section of the Software Architecture Document.

135. Incorporate Existing Design

136. Reverse Engineer Components
To incorporate potentially reusable model elements from other projects, external sources or prior iterations.
Based upon the results of Activity: Incorporate Existing Design Elements, existing code and database definitions can be 'scavenged' to make work done on previous projects or iterations available to the current project/iteration. By using potential reuse opportunities as a filter, the work that is reverse engineered can be focused on just the components which are reusable for the current iteration.
Reverse Engineer Components
In organizations which build similar systems, there is often a set of common components which provide many of the architectural mechanisms needed for a new system. There may also be components available in the marketplace which also provide the architectural mechanisms. Existing components should be examined to determine their suitability and compatibility within the software architecture.
Existing components, either developed during prior iterations but not yet included in the Design Model, or purchased components, must be reverse-engineered and incorporated into the Design Model. In the Design Model, each component is represented as a Subsystem with one or more Interfaces.

137. Identify Re-Use Opportunities
To identify where existing subsystems and/or components may be reused based on their interfaces.
Guidelines: Interfaces
Look for existing subsystems or components which offer similar interfaces. Compare each interface identified to the interfaces provided by existing subsystems or components. There usually will not be an exact match, but approximate matches can be found. Look first for similar behavior and returned values, then consider parameters.
Modify the newly identified interfaces to improve the fit. There may be opportunities to make minor changes to a candidate interface which will improve its conformance to the existing interface. Simple changes include rearranging or adding parameters to the candidate interface, and then factoring the interface by splitting it into several interfaces, one or more of which match those of the existing component, with the "new" behaviors located in a separate interface.
Replace candidate interfaces with existing interfaces where exact matches occur. After simplification and factoring, if there is an exact match to an existing interface, eliminate the candidate interface and simply use the existing interface.
Map the candidate subsystem to existing components. Look at existing components and the set of candidate subsystems. Factor the subsystems so that existing components are used wherever possible to satisfy the required behavior of the system. Where a candidate subsystem can be realized by an existing component, create traceability between the design subsystem and the component in the implementation model.
In mapping subsystems onto components, consider the design mechanisms associated with the subsystem; performance or security requirements may disqualify a component from reuse despite an otherwise perfect match between operation signatures.

138. Update The Design Organization
To account for the new model elements in the organization of the Design Model.
To re-balance the structure of the Design Model where necessary.
Guidelines: Layering, Design Subsystems, Design Packages
Tool Mentor: Managing the Design Model Using Rational Rose
As new elements have been added to the Design Model, re-packaging the elements of the Design Model is often necessary. Repackaging achieves several objectives: it reduces coupling between packages and improves cohesion within packages in the design model. The ultimate goal is to allow different packages (and subsystems) to be designed and developed independently of one another by separate individuals or teams. While complete independence is probably impossible to achieve, loose coupling between packages tends to improve the ease of development of large or complex systems.
A 'flat' model structure (where all packages and subsystems reside at the same conceptual level in the system) is suitable for a small system; larger systems need an additional structuring tool called 'layering' (see Guidelines: Layering and Concepts: Layering). Layering rules define restrictions on allowed relationships between certain types of packages. These rules recognize that certain dependencies should not exist: application functionality should not be directly dependent on specific operating system or windowing system services - there should be an intermediate layer containing logical operating system and windowing services that insulate the application functionality from changes in low-level implementation services. Layering provides a way to reduce the impact of change: by enforcing rules which restrict the dependencies between packages and subsystems, reducing the degree of coupling between packages and subsystems, the system becomes more robust. It tolerates change.
As new model elements are added to the system, existing packages may grow too large to be managed by a single team: the package must be split into several packages which are highly cohesive within the package but loosely coupled between the packages. Doing this may be difficult - some elements may be difficult to place in one specific package because they are used by elements of both packages. There are two possible solutions: split the element into several objects, one in each package (this works where the element has several 'personalities', or sets of somewhat disjoint responsibilities), or move the element into a package in a lower layer, where all higher layer elements may depend upon it equally.
As the system grows in complexity, a larger number of layers will be needed in order to have a maintainable and understandable structure. More than 7-10 layers, however, are unusual in even the largest systems, since complexity increases and understandability decreases with the number of layers.
An example of layering, including middle-ware and System-software layers, is shown below:
Sample package layering for a Java/Web-based application. Note: the dependencies on the TCP/IP package would not normally be explicitly modeled as the use of TCP/IP services is encapsulated within the Java VM, java.rmi and the Web Browser. They are depicted here only for illustration.
Assign responsibilities for the subsystems and layers to individuals or teams. Each package or subsystem should be the responsibility of a single person (if its scope is small) or a team (if its scope is large).

139. Update The SAD
When classes, packages and subsystems (model elements) are important from an architectural perspective, they should be included in the Software Architecture Document. This will ensure that new architecturally significant model elements are communicated to other project team members.

140. Topic 3: Class Work
In Rose Logical View:
TBA.

141. What Is Covered By Analysis And Design?
Design Components
Architectural Analysis
Construct Architectural Proof-of-Concept
Assess Viability of Architectural Proof-of-Concept
Cant split exactly into analysis and design, but most analysis activities occur prior to design activities.

142. Design Components
Why – Refine the definitions of design elements by working out the 'details' of how the design elements implement the behavior required of them. Refine and update the use-case realizations based on new design element identified. Review the design as it evolves. Implementing the design elements as components. Testing the implemented components to verify functionality and satisfaction of requirements at the component/unit level.
When – During construction, after analyzing behavior.
What – Update the Design Model.

143. Design Components

144. Design Components

145. Design Functional Area

146. Design Functional Area
Role – Designer
Input – System Use Case Realizations, Design Model.
Output – Design Model, System Use case Sequence Diagrams.
Purpose:
To refine use-case realizations in terms of interactions.
To refine requirements on the operations of design classes.
To refine requirements on the operations of subsystems and/or their interfaces.
To refine requirements on the operations of capsules.

147. Design Functional Area

148. Add Design To SUCRs

149. Add Design To SUCRs Input: Process: Output:
System Use Case Realization.
Process:
For each use-case realization, illustrate the interactions between its participating design objects by creating one or more sequence diagrams.
You may use a proxy class to represent subsystems on sequence diagrams.
Describe what an object does when it receives a message. This is done by attaching a script to the corresponding message. Place these scripts in the margin of the diagram.
You may need new objects at this point, for example if you are using a centralized structure and need a new object to control the flow.
Output:
System Use Case Sequence Diagram

150. Encapsulate Sequence Diagrams

151. Encapsulate Sequence Diagrams
Input:
System Use Case Sequence Diagram
Process:
Replace large subsections of the sequence diagram with a single message to a subsystem.
Within the subsystem, a separate sequence diagram illustrates the internal interactions within the subsystem that provide the required behavior.
Sub-sequences of messages within sequence diagrams should be encapsulated within a subsystem when:
The sub-sequence occurs repeatedly in different sequence diagrams.
The sub-sequence occurs in only one sequence diagram, but it is expected to be performed repeatedly in future iterations.
The sub-sequence occurs in only one use-case realization, but is complex but easily encapsulated, can be the responsibility of one person or team, and provides a well-defined result.
The sub-sequence is determined to be encapsulated within a component in the implementation model. In this case, a subsystem is the appropriate representation for the component within the design model.
Output:
System Use Case Sequence Diagram.

152. Describe Persistence ..

153. Describe Persistence .. Input: Process: Output: Design Model.
There may be times when the application needs to control various aspects of persistence:
Writing Persistent Objects.
Reading Persistent Objects.
Retrieval of objects from a persistent object store. Send a message to an object that knows how to query the database, retrieve the correct object, and instantiate it.
Deleting Persistent Objects. How transactions are managed.
How locking and concurrency control is achieved.
Error handling. If an interface reports that an error has occurred in its communication with some external system, for example.
Time-out handling. If the user does not reply within a certain period, the use case should take some special measures.
Handling of erroneous input to the objects that participate in the use case.
Output:
System Use Case Sequence Diagrams.

154. Refine The Flow Of Events

155. Refine The Flow Of Events
Input:
System Use Case Sequence Diagrams.
Process:
In the flow of events of the use-case realization you may need to add additional description to the sequence diagrams, Examples of these cases
timing annotations,
notes on conditional behavior,
looping, and branching,
extension points,
clarification of operation behavior.
Output:

156. Unify Classes And Subsystems

157. Unify Classes And Subsystems
Input:
Design Model
Process:
Unify the classes and subsystems to ensure homogeneity and consistency in the model by considering:
Names of model elements should describe their function.
Avoiding similar names and synonyms because they make it difficult to distinguish between model elements.
Merging model elements that define similar behavior, or that represent the same phenomenon.
Merging entity classes that represent the same concept or have the same attributes, even if their defined behavior is different.
Using inheritance to abstract model elements, which tends to make the model more robust.
Output:

158. Evaluate The Design

159. Evaluate The Design Input: Process: Output: Design Model
Check the design model at this stage to verify that:
The objectives of the model are clearly stated and visible.
The model is at an appropriate level of detail given the model objectives.
The model's use of modeling constructs is appropriate to the problem at hand.
The model is as simple as possible while still achieving the goals of the model.
The model appears to be able to accommodate reasonably expected future change.
The design is appropriate to the task at hand (neither too complex nor too advanced)
The design appears to be understandable and maintainable
The design appears to be implementable
There are no more than nine layers.
The rationale for layer definition is clearly presented and consistently applied.
Layer boundaries are respected within the design.
Layers are used to encapsulate conceptual boundaries between different kinds of services and provide useful abstractions which makes the design easier to understand.
Output:

160. Build Design Classes

161. Build Design Classes Role - Designer
Input – Analysis Class, Design Guidelines.
Output – Design Model, Design Class.
Purpose:
To ensure that the class provides the behavior the use-case realizations.
To ensure that sufficient information is provided to unambiguously implement the class.
To handle non-functional requirements related to the class.
To incorporate the design mechanisms used by the class.

162. Build Design Classes

163. Create Initial Design Classes

164. Create Initial Design Classes
Input:
Analysis Class.
Process:
Creating one or more design classes for each analysis class
Assign trace dependencies.
[Depending on the type of the analysis class (boundary, entity, or control) that is to be designed, there are specific strategies that can be used to create initial design classes – See RUP for details.]
Output:
Design Class.

165. Identify Persistent Classes

166. Identify Persistent Classes
Input:
Design Classes
Process:
Classes which need to be able to store their state on a permanent medium are referred to as 'persistent'.
Identifying persistent classes serves to notify the Database Designer that the class requires special attention to its physical storage characteristics.
Output:

167. Define Class Visibility

168. Define Class Visibility
Input:
Design Classes
Process:
For each class, determine the class visibility within the package in which it resides as:
'public' class may be referenced outside the containing package.
'private' class (or one whose visibility is 'implementation') may only be referenced by classes within the same package.
Output:

169. Define States

170. Define States Input: Process: Output: Design Classes
The behavior of the operation may depend upon the state the object is in. A state machine is a tool for describing the states the object can assume and the events that cause the object to move from one state to another, See state diagram guidelines.
Output:

171. Define Dependencies

172. Define Dependencies Input: Process: Output: Design Classes
For each case where the communication between objects is required, ask the following questions:
Is the reference to the receiver passed as an parameter to the operation? If so, establish a dependency between the sender and receiver classes in a class diagram containing the two classes. In addition, if the collaboration diagram format for interactions is used, qualify the link visibility, setting it to 'parameter'.
Is the receiver a 'global'? If so, establish a dependency between the sender and receiver classes in a class diagram containing the two classes. In addition, if the collaboration diagram format for interactions is used, qualify the link visibility, setting it to 'global'.
Is the receiver a temporary object created and destroyed during the operation itself? If so, establish a dependency between the sender and receiver classes in a class diagram containing the two classes. In addition, if the collaboration diagram format for interactions is used, qualify the link visibility, setting it to 'local'.
Output:

173. Define Associations

174. Define Associations Input: Process: Output: Design Classes
Examine the method descriptions for each operation to understand how instances of the class communicate and collaborates with other objects. In order to send a message to another object, an object must have a reference to the receiver of the message.
In the Design Model explicitly handle event dependencies, either using available event-handler frameworks, or by designing and building event-handler framework. In some programming languages such as Visual Basic this is straightforward by declaring, raising, and handling the corresponding events. In other languages you might have to use some additional library of reusable functions to handle subscriptions and events; if the functionality can't be purchased, it will need to be designed and built.
Output:
Design Model

175. Define Methods

176. Define Methods Input: Process: Define Methods Output: Design Classes
A method specifies the implementation of an operation in the programming language
The method, should discuss:
How operations are to be implemented.
How attributes are to be implemented and used to implement operations.
How relationships are to be implemented and used to implement operations.
What is to be done according to the requirements?
What other objects and their operations are to be used?
How parameters are to be implemented.
Any special algorithms to be used.
Output:

177. Identify Attributes

178. Identify Attributes Input: Process: Output: Design Classes
During the definition of methods and states, attributes needed by the class needs to carry out its operations are identified.
For each attribute, define the following:
its name, which should follow the naming conventions of both the implementation language and the project;
its type, by referencing an element in the data dictionary.
its default or initial value, to which it is initialized when new instances of the class are created
its visibility, which will take one of the following values:
Public: the attribute is visible both inside and outside the package containing the class.
Protected: the attribute is visible only to the class itself, to its subclasses, or to friends of the class (language dependent)
Private: the attribute is only visible to the class itself and to friends of the class.
Implementation: the attribute is visible only to the class itself.
Check to make sure the attribute is needed.
Output:

179. Define Generalizations

180. Define Generalizations
Input:
Design Classes
Process:
Classes may be organized into a generalization hierarchy to reflect common behavior and common structure.
When generalization is found, create a common super-class to contain the common attributes, associations, aggregations, and operations.
Remove the common behavior from the classes which are to become sub-classes of the common super-class.
Define a generalization relationship from each sub-class to the super-class.
Output:
Design Model

181. Non-Functional Requirements

182. Non-Functional Requirements
Input:
Design Guidelines
Process:
Design Classes are refined to handle general non-functional requirements as stated in the Design Guidelines.
General design guidelines and mechanisms that need to be taken into consideration when classes are designed:
How to use existing products and components,
How to adapt to the programming language,
How to distribute objects,
How to achieve acceptable performance,
How to achieve certain security levels,
How to handle errors,
Output:
Design Model

183. Evaluate The Design

184. Evaluate The Design Input: Process: Output: Design Model
Check the design model to verify that the work is headed in the right direction:
The objectives of the model are clearly stated and visible.
The model is at an appropriate level of detail given the model objectives.
The model's use of modeling constructs is appropriate to the problem at hand.
The model is as simple as possible while still achieving the goals of the model.
The model appears to be able to accommodate reasonably expected future change.
The design is appropriate to the task at hand (neither too complex nor too advanced)
The design appears to be understandable and maintainable
The design appears to be implementable.
Layer boundaries are respected within the design.
Output:

185. Design Test Classes/Packages

186. Design Test Classes And Packages
Role – Designer
Input – Design Classes, Test I/F Specs, Test Cases
Output – Test Classes.
Purpose:
To design test-specific functionality.

187. Design Test Classes And Packages

188. Identify Test Classes And Packages

189. Identify Test Classes And Packages
Input:
Design Classes
Process:
Identify and design the classes and packages that will provide the needed test specific functionality.
A driver or stub of a design class has the same methods as the original class, but there is no behavior defined for the methods other than to provide for input (to the target for test) or returning a pre-defined value (to the target for test).
A driver or stub of a design package contains simulated classes for the classes that form the public interface of the original package.
Output:
Test Classes

190. Design Interface To Automated Test Tool

191. Design Interface To Automated Test Tool
Input:
Test Interface Specifications.
Process:
Identify what behavior is needed to make the test automation tool communicate with your target for test in an efficient way.
Identify and describe the appropriate design classes and packages.
Output:
Design Classes.

192. Design Test Procedure Behavior

193. Design Test Procedure Behavior
Input:
Test Cases.
Process:
To automate test procedures for which there is no automation tool:
Identify appropriate design classes and packages.
Use the test cases and the use cases they derive from as input.
Output:
Design Classes.

194. Test Case

195. Design Class

196. Design Subsystems

197. Design Subsystems Role – Designer Input – Design Subsystems.
Output – Design Subsystems, Interfaces, Sequence Diagrams, Design Classes.
Purpose:
The purpose of this activity is to:
define the behaviors specified in subsystem interfaces in terms of collaborations of contained classes.
document internal structure of subsystems.
define realizations between subsystem interfaces and contained classes.
determine the dependencies upon other subsystems.

198. Design Subsystem
A model element which has the semantics of a package and a class.
The behavior of the subsystem is provided by classes or other subsystems it contains.
A subsystem realizes one or more interfaces, which define the behavior it can perform.
Provides the ability to completely encapsulate the interactions of a number of class and/or subsystems.

199. Design subsystem

200. Design Subsystems

201. Distribute Subsystem behavior To Subsystem Elements

202. Distribute Subsystem behavior To Subsystem Elements
Input:
Design Subsystems
Process:
The external behaviors of the subsystem are defined by the interfaces it realizes. When a subsystem realizes an interface, it makes a commitment to support each and every operation defined by the interface. The operation may be in turn realized by:
an operation on a class contained by the subsystem; this operation may require collaboration with other classes or subsystems
an operation on an interface realized by a contained subsystem
The collaborations of model elements within the subsystem are documented using sequence diagrams which show how the subsystem behavior is realized.
Output:
Design Subsystems, Sequence Diagrams.

203. Sequence Diagram

204. Document Subsystem Elements

205. Document Subsystem Elements
Input:
Design Subsystems.
Process:
Ddocument the internal structure of each subsystem by creating one or more class diagrams showing the elements contained by the subsystem, and their associations with one another.
One class diagram per subsystem may be sufficient, but more can be used to reduce complexity and improve readability.
Output:
Class Diagram.

206. Design Subsystem

207. Class Diagram

208. Describe Subsystem Dependencies

209. Describe Subsystem Dependencies
Input:
Design Subsystems
Process:
When an element contained by a subsystem uses some behavior of an element contained by another subsystem, a dependency is created between the enclosing subsystems.
To improve reuse and reduce maintenance dependencies, we want to express this in terms of a dependency on a particular interface of the subsystem, not upon the subsystem itself nor on the element contained in the subsystem.
Output:
Interfaces

210. Interface

211. Review The Design

212. Review The Design
See slide 115

213. Topic 4: Class Work
In Rose Logical View:
TBA.

214. What Is Covered By Analysis And Design?
Build A Common Data Area
Maintain a data dictionary
Cant split exactly into analysis and design, but most analysis activities occur prior to design activities.

215. Build A Common Data Area

216. Build A Common Data Area

217. Maintain A Data Dictionary
Why – Used to capture a common set of data definitions that may be used by all analysis and design artifacts. See guidelines for a data dictionary.
When – From inception through to deployment.
What – Package in Rose containing classes that define all data types.

218. Maintain A Data Dictionary

219. Add Data Entry

220. Add Data Entry Input: Process: Output: Glossary
In the data dictionary package, in the logical view, create a new class and give it the name of the data type.
Add a description of the data element in the documentation field.
In the Stereotype filed, identify the type of data dictionary entry. Different types include:
Integer - create attributes for the 'lower bound' and 'upper bound' of the integer type.
Real - create attributes representing the 'lower bound', 'upper bound' and the 'resolution' for the real.
Char - describe the character set that the data dictionary attribute represents. Is it pure ASCII, or are additional characters included or are some ASCII characters excluded.
Enumeration - Create an attribute for each value in the enumerated type. Give the attribute the name of that value.
In the attributes display create an attribute for every value that the enumerated type may take.
Reference other data dictionary entries from new data dictionary entries where the new entry is a subset of an existing entry.
Output:
Data model.

221. Glossary

222. Data Dictionary

223. Reference Data

224. Reference Data Input: Process: Output: Data Model.
Any attribute of the analysis and design model should reference a data dictionary entry through its 'Type' field. If an appropriate type does not exist then create one in the data dictionary.
Elements within the data dictionary may reference other data dictionary entries through their 'Type' field.
If an attribute is of a type that is a structure of data dictionary entries, for example an 'Address' field, then build the appropriate structure in the data dictionary and reference a data dictionary entry which represents that structure.
Output:
Analysis And Design Model.

225. Data Reference

226. Delete Data Entry

227. Delete Entry Input: Process: Output: Data Model.
Delete any elements that are no longer needed.
Select the data dictionary entry and enter Report->Show Usage to determine that the entry is being referenced.
Output:

228. Report On Usage

229. Data Dictionary Entry

230. Summary: Where we started: What we did – how we did it
System Use Case Model, Supplemental Specifications, Design Guidelines.
What we did – how we did it
System Use Case Realizations, Analysis Model, Design Model, Architecture Model, Deployment Model.
Where to go next
Implementation Model, Code and Test.

231. Additional Info Helpful links Other classes
AW Dev
Other classes
Implementation and Test Workshop.
Analysis and Design Rational Online Training.

232. Glossary

233. Notes

234. Student Survey