Analysis And Design 1 Analysis And Design Workshop Presented By Leslie Munday

Analysis And Design 1P.R.CP.R.C

Analysis And Design Workshop

Presented By

Leslie Munday


Intended Audience

• Pre-reqs Courses– 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)


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.


RUP DISCIPLINE OVERVIEW (humpback whale chart)


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.

Create RequirementsManagment Plan

Create RMP Draft

Requirements Management Plan

Lead Process Analyst


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.

Create and Maintain Requirements Management Plan


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.


Workflows Of A&DAnalysis 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

Define a Candidate Architecture

Refine the Architecture

Analyze Behavior

Design Components

More Iterations?

Analysis & Design Workflow Overview

Maintain Data Dictionary

[ Yes ]

[ No ]


Activities Of Analysis And Design

Perform Architecture Analysis

Define A Candidate Architecture

Identify Design ElementsPerform Use Case Analysis

Incorporate Existing Design Elements

Describe Run-Time Architecture

Design Test Classes and Packages

Design Subsystem

Build Design Classes

Design Functional Area

Review The Design

Maintain System Interfaces

Review the Architecture

Review The Design

Analysis And Design Activity Overview

Analyze Behavior

Refine The Architecture

Design Components

Maintain A Data Dictionary

Maintain Data

DeploymentConstructionElaborationInception


Analysis And Design ArtifactsAnalyst – 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.


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.


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.


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.]


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.


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.


Implementation ViewIn 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.


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.


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


Logical View

• This is the view used by analysis and design.

• Where most analysis and design components are located.


Example (Patron at Library)

Handout:

SAD Template,

and SIA Template.

iSEE Baseline Software Architecture Document

Version <Current version #>

SYSTEM INTERFACE AGREEMENT

DOCUMENTATION GUIDE

Author: Timothy Watson

Creation Date: September 8, 1998

Last Updated: September 16, 2003

Version: 1.3 (rev 3)

SYSTEM INTERFACE AGREEMENT

<Interface Name Here>

Author: LeAnne Lay

Creation Date: October 10, 2001

Last Updated: September 16, 2003

Version: 1

Approvals:

<TBD>


Analysis And Design: Introduction

• Five Workflows– Define A Candidate

Architecture– Refine The Architecture– Analyze Behavior– Design Components– Maintain Data Dictionary

Def ine a Candidate Architecture

Ref ine the Architecture

Analyze Behav ior

Design Components

More Iterations?

Analysis & Design Workf low Overv iew


[ Yes ]

[ No ]


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.


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.




Analy ze Behav ior

Design Components

More Iterations?

Analy sis & Design Workf low Overv iew


[ Yes ]

[ No ]

What Is Covered By Analysis And Design?

• Define A Candidate Architecture– Architectural Analysis


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.


Architecture

• Architecture = Elements + Form + Rationale

• Elements – Classes, packages/subsystems.

• Form – Patterns, behavior, collaborations and relationships,

• Rationale – Decisions, interfaces, external influences.


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.


Workflow Details Diagram


Workflow Sequence Diagram


Workflow Sequence Diagram for Design Components

Application ArchitectRole – Architect.Input – Architecture Domain Model, Design Guidelines, System Use Case Model.Output – Software Architecture Document, Deployment Model.



• 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.


Perform Architectural Analysis


Draft Key Abstractions


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.


Stakeholder Request


Class

Book

Card

Patron

PatronSystem

An item that may be borrowed by a customer of the library.

A library card used to identify a customer of the library.

A customer.

The system that maintains customer information.


Define High-Level Organization Of Subsystems


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.


System Use Case

Check Out BookSearch Book Catalog

Desk Attendant

Check in Book


Design Model


Define High-Level Deployment Model


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.


Architecture Design Model


High-Level Deployment Model

• Shows devices and processors that the application is deployed to.

Catalog System

Accounts Receivable System

Multimedia PC

Patron System

Remote User

Modem


Review The Architecture


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.


Design Model


Update The SAD


Update The SAD

• Inputs:– Design Model.

• Process:– 5.1 Architecture Overview: Package

and Subsystem Layering – 7. Deployment View

• Outputs:– Software Architecture Document.


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.




Analyze Behav ior

Design Components

More Iterations?



[ Yes ]

[ No ]


• Analyze Behavior– Perform Use Case

Analysis– Identify Design Elements– Maintain system

Interfaces– Review The Design


Workflow Details Diagram


Workflow Sequence Diagram


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.


Perform Use Case analysis


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


Perform Use Case Analysis


Find Classes From Behavior


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.


System Use Case


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.


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.


• 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.

Boundary Class

SearchScreen


• 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.

Control Class

SearchForBook


• 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.

Entity Class

Book


Restrictions

• Boundary 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.


Analysis Class Diagram

SearchScreen

BookSearchForBook

SearchResultsScreen

DisplaysBooksIn


Create Use Case Realizations



• 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.


System Use Case


System Use Case Realization


Distribute Behavior To Classes



• 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).


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.


Collaboration Diagram


Detail Class Attributes


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).


Class Attributes

SearchScreen

AuthorFirstNameAuthorLastName

Title<<*>> UserId

Book

<<*>> BookIdAuthorFirstNameAuthorLastName

Title

SearchResultsScreen

AuthorNameTitleShelf

Location<<*>> UserId

DisplaysBooksIn

BookSearch

BookIdBookSearchValue

BookSearchAttribute<<*>> SearchRequest


Identify Class Associations


Associations• Input:

– System Use Case Realization.• Process:

– 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).


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.


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.


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.


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.


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.


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.


• 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.

Multiplicity

Class A Class B

1..100..10..1 1..10

At any moment in time:One instance of Class A is associated with between 1 to 10 instances of Class B.One instance of Class B is associated with 0 or 1 instance of Class A.


Class Associations


Hiding Attributes And Operations


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.


Adding Key Attributes


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.


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.





Identify Classes


Identify Classes

• Input:– Analysis Classes.

• Process:– 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.


Analysis Classes


Design Classes

• Show analysis class diagram as design classes and subsystems.

• What about traceability?????


Model Active Classes


Model Active Classes• Input:

– 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.


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.


Statechart DiagramIdle

CheckingSearchParameters

SearchForBookRequired / CreateSearch

GettingNextBook

SearchParametersCorrect / GetBook

SearchDeleted

ReturningErro

DeleteSearch / DeletingSearch

SearchParametersIncorrect / IndicateErrorInData

Returning Found Book

Determininf If Anymore Books

BookReturned / DetermineIfMoreBooks

AllBooksSesrched / DeletingSearch

BookMatchesSearchCriteria ^SearchScreen.ReturnBook(Book)

MoreBooks / GetBook

NoMtach / DetermineIfMoreBooks


Describe Event Dependencies


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.


Identify Subsystems


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.


Document Subsystem Interfaces


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.




• Role – Application Architect• Input – Design Model• Output – System Interface Agreements• Purpose:

– To update external documentation to reflect changes to the design.





Update SIAs

• Input:– .

• Process:– 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.


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.

Review The Design


Review The Design


Review Overall Design Model


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.


Review Model Behavior


Review Model Behavior

• Input:– 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.


Review Subsystems


Review Subsystems

• Input:– Design Subsystems.

• Process:– 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.



Review System Interfaces


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.



Prepare Review Records


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.


Topic 2: Class Work

• In Rose Logical View:– TBA.




Analyze Behav ior

Design Components

More Iterations?



[ Yes ]

[ No ]


• Refine The Architecture– Identify Design Elements – Incorporate Existing Design

Elements– Review The Architecture






Workflow Sequence Diagram for Refine the Architecture


Review the Architecture

Architecture ReviewerApplication Architect



• 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.





• Slide 98.




• 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.



Incorporate Existing Design


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.


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.


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).


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.


Topic 3: Class Work





Analyze Behav ior

Design Components

More Iterations?



[ Yes ]

[ No ]


• Design Components– Architectural Analysis – Construct Architectural

Proof-of-Concept – Assess Viability of

Architectural Proof-of-Concept


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.


Design Components


Design Components


Design Test Classes and Packages

Design Subsystem


Workf low Sequence Diagram for Design Components

Review The Design

Designer





• 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.




Add Design To SUCRs


Add Design To SUCRs• Input:

– 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


Encapsulate Sequence Diagrams


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.


Describe Persistence ..


Describe Persistence ..• Input:

– Design Model.• Process:

– 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.


Refine The Flow Of Events


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:– System Use Case Sequence Diagrams.


Unify Classes And Subsystems


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:

– Design Model


Evaluate The Design


Evaluate The Design• Input:

– Design Model• Process:

• 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:– Design Model





• 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.




Create Initial Design Classes


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.


Identify Persistent Classes


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:– Design Classes


Define Class Visibility


Define Class Visibility


• 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.



Define States


Define States


• Process:– 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.



Define Dependencies


Define Dependencies


• Process:– 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'.



Define Associations


Define Associations


• Process:– 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.



Define Methods


Define Methods


• Process:• Define Methods

– 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.



Identify Attributes


Identify Attributes• Input:

– Design Classes• Process:

– 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:

– Design Classes


Define Generalizations


Define Generalizations


• 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.



Non-Functional Requirements


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,



Evaluate The Design


Evaluate The Design

• Input:– Design Model

• Process:– 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.



Design Test Classes/Packages


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.


Design Test Classes And Packages


Identify Test Classes And Packages


Identify Test Classes And Packages


• 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


Design Interface To Automated Test Tool


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.



Design Test Procedure Behavior


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.



Test Case


Design Class


Design Subsystems


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.


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.


Design subsystem


Design Subsystems


Distribute Subsystem behavior To Subsystem Elements


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.


Sequence Diagram


Document Subsystem Elements


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.


Design Subsystem


Class Diagram


Describe Subsystem Dependencies


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


Interface


Review The Design


Review The Design

• See slide 115


Topic 4: Class Work




• Build A Common Data Area– Maintain a data dictionary

Define a Candidate Architecture

Refine the Architecture

Analyze Behavior

Design Components

More Iterations?

Analysis & Design Workflow Overview

Build A Common Data Area

[ Yes ]

[ No ]






Process Analyst



• 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.




Add Data Entry


Add Data Entry

• Input:– Glossary

• Process:– 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.


Glossary


Data Dictionary


Reference Data


Reference Data

• Input:– Data Model.

• Process:– 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.


Data Reference


Delete Data Entry


Delete Entry

• Input:– Data Model.

• Process:– 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:– Data Model.


Report On Usage


Data Dictionary Entry


Summary:

• Where we started:– 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.


Additional Info

• Helpful links– AW Dev Case @

http://prc/resources/soft_construction/iSEE/Siebel7DevCase/Development%20Case/dc_index.htm

• Other classes– Implementation and Test

Workshop.– Analysis and Design

Rational Online Training.

Tool Mentor: Capturing the Results of Use-Case Analysis Using Rational Rose

Purpose

This tool mentor describes how to represent the results of Use-Case analysis in Rational Rose.

Related Rational Unified Process information:

Activity: Use-Case Analysis Activity: Architectural Analysis

Overview

The following is a summary of the steps you performed to record the results of Use-Case Analysis:

1. Create the analysis model (optional) 2. Create a use-case realization 3. Create diagrams for the use-case realization 4. Create analysis classes 5. Document class responsibilities 6. Create class diagrams to document analysis classes

1. Create the analysis model (optional)To top of page

The Artifact: Analysis Model is optional; the results of the Activity: Use-Case Analysis are typically represented using the Artifact: Design Model. If a separate Analysis Model is to be maintained, it can be represented in Rational Rose by creating a package within the Logical View Named "Analysis Model".

In addition, separate Use-Case realizations will need to be created within this Model. See Tool Mentor: Creating Use-Case Realizations, and follow its steps, but create the realizations within the Analysis Model package.

The goal of an analysis model is to create a preliminary mapping of required behavior onto modeling elements in the system. In most cases, it omits the detail of a design model in order to provide an overview of the system functionality. The analysis model eventually transitions into the design model, and the analysis classes directly evolve into design model elements.


Glossary


Notes


Student Survey