ANALYSIS Analysis does not set out to make pathological reactions impossible, but to give the patient’s ego freedom to decide one way or another. Sigmund Freud, The Ego and the Id (1923 ) Analysis can be a very unappetizing affair … Thomas Mann, The Magic Mountain (1924 )

Our Process Reminder of object-oriented development process we are following in this course is that there are four phases : Inception Elaboration Construction Transition Each phase consists of one or more iterations of the following workflows : Requirements Analysis Design Implementation Test In this section, we are going to examine the analysis workflow principally in the context of the Elaboration phase.

Reminder of object-oriented development process we are following in this course is that there are four phases :

Inception

Elaboration

Construction

Transition

Each phase consists of one or more iterations of the following workflows :

Requirements

Analysis

Design

Implementation

Test

In this section, we are going to examine the analysis workflow principally in the context of the Elaboration phase.

Analysis Workflow In the requirements workflow, use case model and other artifacts (screen prototypes, glossary, etc) are used to build an initial model based on the users’ requirements. In the analysis workflow, the requirements are analyzed in more detail, so as to begin the description of the internal structure and behavior of the proposed system. Requirements Model Use Case Model Glossary Prototypes Analysis Model Use Case Realizations message() message2()

In the requirements workflow, use case model and other artifacts (screen prototypes, glossary, etc) are used to build an initial model based on the users’ requirements.

In the analysis workflow, the requirements are analyzed in more detail, so as to begin the description of the internal structure and behavior of the proposed system.

Analysis versus Design The boundary between analysis and design can be quite vague; they often overlap. Rules of thumb for analysis modeling: Analysis model is always in the language of the business Concentrate on capturing the big picture (don’t get bogged down in details). Focus on the problem domain (business requirements), not the solution domain (detailed design considerations). e.g., don’t worry about implementation classes such as database access or user interface classes. Keep the model simple. Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 101.

The boundary between analysis and design can be quite vague; they often overlap.

Rules of thumb for analysis modeling:

Analysis model is always in the language of the business

Concentrate on capturing the big picture (don’t get bogged down in details).

Focus on the problem domain (business requirements), not the solution domain (detailed design considerations).

e.g., don’t worry about implementation classes such as database access or user interface classes.

Keep the model simple.

Analysis Model The aim of the analysis workflow is to produce an analysis model . This is a logical model that is technology-independent (i.e., unconcerned with how it is to be implemented). It allows developers to focus on the problems to be solved. Ignoring technology makes it less likely that old ways of doing things will be carried forward into the design of the new system.

The aim of the analysis workflow is to produce an analysis model .

This is a logical model that is technology-independent (i.e., unconcerned with how it is to be implemented).

It allows developers to focus on the problems to be solved.

Ignoring technology makes it less likely that old ways of doing things will be carried forward into the design of the new system.

Analysis is Use Case Driven The use cases defined in the requirements model are the basis for the entire analysis and design workflows. Use Case Model Use Case Realizations Analysis and Design Models message() message2()

The use cases defined in the requirements model are the basis for the entire analysis and design workflows.

Use Case Realizations Use cases are realized in subsequent analysis and design. That is, use-case realizations describe how a use-case is performed ("realized") in terms of interacting objects in the design model (that is, in terms of how objects collaborate). Use case realizations tie together the use cases with the classes and relationships of the domain model. That is, a use case realization specifies which classes must be built to implement each use case. Development of use case realizations is the main goal of analysis; refining these use case realizations is the main goal of design. Source: Object-Oriented Analysis with UML (Rational Software Corporation, 2001), p. 3-18.

Use cases are realized in subsequent analysis and design.

That is, use-case realizations describe how a use-case is performed ("realized") in terms of interacting objects in the design model (that is, in terms of how objects collaborate).

Use case realizations tie together the use cases with the classes and relationships of the domain model.

That is, a use case realization specifies which classes must be built to implement each use case.

Development of use case realizations is the main goal of analysis; refining these use case realizations is the main goal of design.

Use Case Realizations Use case realizations consists of the following elements: Analysis class diagrams Show the analysis classes that interact to realize the use case Interaction diagrams Show collaborations and interactions between objects that realize the use case. Use Case refinement New info may be discovered that requires the original use case to be updated. Activity diagrams may be used to illustrate scenarios in the use case. Use case realization is a process of refinement. Take a use case and then model how the behavior specified in the use case will be realized by collaborations and interactions between instances of domain classes you have identified. Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 200-1.

Use case realizations consists of the following elements:

Analysis class diagrams

Show the analysis classes that interact to realize the use case

Interaction diagrams

Show collaborations and interactions between objects that realize the use case.

Use Case refinement

New info may be discovered that requires the original use case to be updated.

Activity diagrams may be used to illustrate scenarios in the use case.

Use case realization is a process of refinement.

Take a use case and then model how the behavior specified in the use case will be realized by collaborations and interactions between instances of domain classes you have identified.

Analysis Model The two key artifacts are produced in analysis model: Use case realizations These illustrate how instances of the analysis classes can interact to realize system behavior specified by a use case. Analysis class diagram Integrates the classes discovered in the use case realizations into a single diagram that shows methods and attributes uncovered in the realizations.

The two key artifacts are produced in analysis model:

Use case realizations

These illustrate how instances of the analysis classes can interact to realize system behavior specified by a use case.

Analysis class diagram

Integrates the classes discovered in the use case realizations into a single diagram that shows methods and attributes uncovered in the realizations.

Analysis Class Analysis classes are classes that: Represent a clear and concise abstraction in the problem domain. i.e., these classes represent the real-world things and concepts related to the problem the system is being design to solve. Should map directly onto real-world business concepts. Should NOT be concerned with design considerations such as performance, patterns, best practices, etc. Also referred to as domain classes .

Analysis classes are classes that:

Represent a clear and concise abstraction in the problem domain.

i.e., these classes represent the real-world things and concepts related to the problem the system is being design to solve.

Should map directly onto real-world business concepts.

Should NOT be concerned with design considerations such as performance, patterns, best practices, etc.

Also referred to as domain classes .

Finding Classes There is no simple algorithm for finding the right analysis classes. Yet, there are techniques which can help you discover these classes. They are: Noun/verb analysis CRC analysis Source: Meyer, Object Oriented Software Construction (Prentice Hall, 1997), p. Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 134-5.

There is no simple algorithm for finding the right analysis classes.

Yet, there are techniques which can help you discover these classes. They are:

Noun/verb analysis

CRC analysis

Discovering Domain Classes The best source for discovering these basic classes is a high-level (100-300 words) problem statement or system definition. If you don't have this system definition, then you will have to write one, in conjunction with the client/users. You can also use other requirements model artifacts as sources of information, in particular: the use case model the glossary of terms.

The best source for discovering these basic classes is a high-level (100-300 words) problem statement or system definition.

If you don't have this system definition, then you will have to write one, in conjunction with the client/users.

You can also use other requirements model artifacts as sources of information, in particular:

the use case model

the glossary of terms.

Noun/verb analysis You can use the grammatical inspection technique of circling/highlighting/underling all the noun and noun phrases (compound nouns or adjective+noun) in the text. This is sometimes called noun phrase identification . You will probably find that: noun and noun phrases become classes and attributes verbs and verb phrases become methods and relations possessive phrases indicate nouns should be attributes rather than classes.

You can use the grammatical inspection technique of circling/highlighting/underling all the noun and noun phrases (compound nouns or adjective+noun) in the text.

This is sometimes called noun phrase identification .

You will probably find that:

noun and noun phrases become classes and attributes

verbs and verb phrases become methods and relations

possessive phrases indicate nouns should be attributes rather than classes.

Step 1. Noun Phrase Identification The Portfolio Manager shall be able to roll up portfolios on several levels. A Trader shall be able to place orders, on behalf of a portfolio, that generate one or more trades. A Portfolio Manager shall be able to select a pairoff method in conjunction with placing a sell order. The entry of a trade shall generate forecasted cashflows associated with the given trade lot. The system shall match up actual cashflows with forecasted cashflows. The system shall automatically generate appropriate postings to the General Ledger. The system shall allow an Assistant Trader to modify trade data and propagate the results accordingly. Source: Doug Rosenberg, Use Case Driven Object Modeling with UML (Addison Wesley, 1999), p. 18 Identify the nouns and noun phrases in this example system definition.

Noun Phrase Identification The Portfolio Manager shall be able to roll up portfolios on several levels . A Trader shall be able to place orders , on behalf of a portfolio , that generate one or more trades . A Portfolio Manager shall be able to select a pairoff method in conjunction with placing a sell order . The entry of a trade shall generate forecasted cashflows associated with the given trade lot . The system shall match up actual cashflows with forecasted cashflows . The system shall automatically generate appropriate postings to the General Ledger . The system shall allow an Assistant Trader to modify trade data and propagate the results accordingly. Source: Doug Rosenberg, Use Case Driven Object Modeling with UML (Addison Wesley, 1999), p. 18 Identify the nouns and noun phrases in this example system definition.

Step 2. Noun Phrase Consolidation After identifying nouns and noun phrases, make plural terms singular eliminate duplicate terms consolidate synonyms into single term place list in alphabetic order

After identifying nouns and noun phrases,

make plural terms singular

eliminate duplicate terms

consolidate synonyms into single term

place list in alphabetic order

Noun Phrase Consolidation actual cashflow order sell order Assistant Trader pairoff method system entry portfolio trade forecasted cashflow Portfolio Manager trade data General Ledger posting trade lot level results Trader After the consolidating noun phrases

Step 3. Noun Phrase Analysis Now, remove: references to the system itself or to its context nouns which appear out of the scope of the project nouns which are too vague nouns which represent actions. Actors might be removed from our list of candidate classes, and placed instead on the use case diagrams. actual cashflow order sell order Assistant Trader pairoff method system entry portfolio trade forecasted cashflow Portfolio Manager trade data General Ledger posting trade lot level results Trader Analyze the list

Now, remove:

references to the system itself or to its context

nouns which appear out of the scope of the project

nouns which are too vague

nouns which represent actions.

Actors might be removed from our list of candidate classes, and placed instead on the use case diagrams.

Noun Phrase Analysis actual cashflow order sell order Assistant Trader pairoff method system entry portfolio trade forecasted cashflow Portfolio Manager trade data General Ledger posting trade lot level results Trader actors actions out of the scope of the project too vague

Step 4. Draw Initial Analysis Class Model If you can, draw an initial analysis class model showing just class names, generalizations, associations, and aggregation. At this stage, don't worry especially about multiplicity or composition, since further analysis is often required to address questions about multiplicity and composition. The classes in your analysis class model are sometimes referred to as entity classes . Just as noun phrase analysis helped identify candidate classes, verb phrase analysis can help identify class relationships. The result can be a table showing each candidate associations with your candidate classes. e.g., Student enrolls in Course Professor teaches Course

If you can, draw an initial analysis class model showing just class names, generalizations, associations, and aggregation.

At this stage, don't worry especially about multiplicity or composition, since further analysis is often required to address questions about multiplicity and composition.

The classes in your analysis class model are sometimes referred to as entity classes .

Just as noun phrase analysis helped identify candidate classes, verb phrase analysis can help identify class relationships.

The result can be a table showing each candidate associations with your candidate classes.

e.g., Student enrolls in Course Professor teaches Course

CRC Cards Another way of discovering your analysis classes is to use CRC ( Class Responsibility Collaboration ) cards. CRC cards are often used within a team to brainstorm the allocation of responsibilities to domain classes as well as for the discovery of relationship for domain classes. Class Name: Collaborations Responsibilities Responsibilities of a class are listed in this section. Collaborations with other classes are listed here, together with a brief description of the purpose of the collaboration. Class name here

Another way of discovering your analysis classes is to use CRC ( Class Responsibility Collaboration ) cards.

CRC cards are often used within a team to brainstorm the allocation of responsibilities to domain classes as well as for the discovery of relationship for domain classes.

CRC Cards Class Name Client Responsibilities Collaborations Provide client information. Campaign provides campaign details. Class Name Campaign Responsibilities Collaborations Provide campaign information. Provide list of adverts. Add a new advert. Advert provides advert details. Advert constructs new object. Class Name Advert Responsibilities Collaborations Provide advert details. Construct adverts. Provide list of campaigns. Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 193.

Digression on UML Class & Object Notation Name compartment Attribute compartment Operation compartment Objects stereotype m_name m_address m_phone getName() getPhone() Customer

UML Attribute Compartment visibility name multiplicity: type=initialValue optional optional mandatory + public visibility - private visibility # protected visibility static attribute -m_name -m_address -m_phone: String -m_age:int=0 +Children[] #salary + numCustomers Customer

UML Operation Compartment visibility name ( parameterName: parameterType, ...): returnType optional optional mandatory optional constructors Note: at the analysis level, you should not be worried about details like constructors, parameters, data types, etc. These will show up in the design stage.

Reflexive Associations A reflexive association is one in which a class has an association with itself. This means that a class has links to other objects of the same class. Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 152.

A reflexive association is one in which a class has an association with itself.

This means that a class has links to other objects of the same class.

Navigability Navigability refers to ability to traverse from object of one class to an object of another class. Means messages can only be sent in the direction of the arrow. Order Product navigable not navigable Thus, a Product object does not contain an Order link, but an Order object does contain a collection of Product links. * 1 Order Product * 1 If no arrows, then the relationship is bidirectional. Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 154-5.

Navigability refers to ability to traverse from object of one class to an object of another class.

Means messages can only be sent in the direction of the arrow.

Dependency A dependency is a relationship between two elements where a change in one, affects the other. Typically used to indicate that one class uses another, but the usage is not really an association. Dependencies generated (in class diagrams) by: An operation of class A needs a parameter of class B An operation of class A returns a value of class B An operation of class A uses an object of class B somewhere in its implementation, but not as an attribute. Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 162-3.

A dependency is a relationship between two elements where a change in one, affects the other.

Typically used to indicate that one class uses another, but the usage is not really an association.

Dependencies generated (in class diagrams) by:

An operation of class A needs a parameter of class B

An operation of class A returns a value of class B

An operation of class A uses an object of class B somewhere in its implementation, but not as an attribute.

Scenarios The process of realization often begins by looking at use case scenarios . A scenario is an instance of a use case. It is one flow through a use case It is some combination of basic and alternate flows. "this happened, then this, then this …" Some people even write scenarios first, then write the use cases. Written scenarios can also be a way of documenting test behaviors for the testing phase.

The process of realization often begins by looking at use case scenarios .

A scenario is an instance of a use case.

It is one flow through a use case

It is some combination of basic and alternate flows.

"this happened, then this, then this …"

Some people even write scenarios first, then write the use cases.

Written scenarios can also be a way of documenting test behaviors for the testing phase.

Scenarios Ways of describing (not realizing) scenarios: using textual descriptions using activity diagrams

Ways of describing (not realizing) scenarios:

using textual descriptions

using activity diagrams

Activity Diagram Scenarios can be graphically described by using an activity diagram . These diagrams are the UML equivalent of a flow chart. They visually capture the step-by-step flow of a typical use case description. Are also used in business process modeling This is a preliminary requirements step in some methodologies. It is used to help the analysts better understand how a business operates. Not as useful for illustrating message communication between objects (we will use interaction diagrams for that).

Scenarios can be graphically described by using an activity diagram .

These diagrams are the UML equivalent of a flow chart.

They visually capture the step-by-step flow of a typical use case description.

Are also used in business process modeling

This is a preliminary requirements step in some methodologies. It is used to help the analysts better understand how a business operates.

Not as useful for illustrating message communication between objects (we will use interaction diagrams for that).

Activity Diagrams This diagram shows: action states , which represent the execution of a step within the flow of a use case. Transitions between those action states decisions for which guard conditions are defined forks, where flow of control is split into two or more concurrent flows joins, where separate flows are joined.

This diagram shows:

action states , which represent the execution of a step within the flow of a use case.

Transitions between those action states

decisions for which guard conditions are defined

forks, where flow of control is split into two or more concurrent flows

joins, where separate flows are joined.

initial state action state fork join guard expression

Exercise Draw the activity diagram for the following use case scenario: Use Case: Place Order Step 1. Enter the order (includes getting info about order and payment method from customer) Step 2. Authorize the purchase (requires verification that the requirement funds can be obtained from customer using the specified payment method). Step 3. Allocate the order items from the inventory. Step 4. Ship the order. Source: Charles Richter, Designing Flexible Object-Oriented Systems with UML (Macmillan, 1999), p. 27.

Draw the activity diagram for the following use case scenario:

Use Case: Place Order

Step 1. Enter the order (includes getting info about order and payment method from customer)

Step 2. Authorize the purchase (requires verification that the requirement funds can be obtained from customer using the specified payment method).

Step 3. Allocate the order items from the inventory.

Step 4. Ship the order.

Exercise This activity diagram is a refinement of the use case

Exercise Draw the activity diagram for the following use case scenario: Use Case: Cancel Order Item Step 1. Update that order item (check to see if the item is still pending, and if so, change its status to cancelled. Step 2. Credit the customer's account for that item. Step 3. Release the inventory request for that item. Note: Steps two and three can happen in either order (or concurrently).

Draw the activity diagram for the following use case scenario:

Use Case: Cancel Order Item

Step 1. Update that order item (check to see if the item is still pending, and if so, change its status to cancelled.

Step 2. Credit the customer's account for that item.

Step 3. Release the inventory request for that item.

Note: Steps two and three can happen in either order (or concurrently).

Exercise

Interaction Diagrams Interaction diagrams are a graphical representation of how objects communicate with one another in a scenario. Static diagrams such as the class diagram and the use case diagram contain no dynamic or temporal information. It can be quite difficult proceeding from initial static class model to designing and implementing behaviors necessary for an application. Interaction diagrams help with this task. Interaction diagrams are a vital part of realizing a use case (along with the class diagram). They model the collaborations and interactions between the objects that realize a use case.

Interaction diagrams are a graphical representation of how objects communicate with one another in a scenario.

Static diagrams such as the class diagram and the use case diagram contain no dynamic or temporal information.

It can be quite difficult proceeding from initial static class model to designing and implementing behaviors necessary for an application.

Interaction diagrams help with this task.

Interaction diagrams are a vital part of realizing a use case (along with the class diagram).

They model the collaborations and interactions between the objects that realize a use case.

Interaction Diagrams Two types Collaboration diagrams Emphasize structural relationships between objects. Sequence diagrams Emphasize the time-ordered sequence of messages sent between objects. Both diagrams are two different representations of the same thing (i.e., the object interactions). Thus a collaboration diagram can be converted to a sequence diagram, and vice-versa.

Two types

Collaboration diagrams

Emphasize structural relationships between objects.

Sequence diagrams

Emphasize the time-ordered sequence of messages sent between objects.

Both diagrams are two different representations of the same thing (i.e., the object interactions).

Thus a collaboration diagram can be converted to a sequence diagram, and vice-versa.

Interaction Diagrams In these diagrams, focus is on communication between objects , not classes. class objects

In these diagrams, focus is on communication between objects , not classes.

Messages How do objects communicate? By sending messages (i.e., invoking a method). A message is thus a communication between two objects (or within one) what results in some activity. This activity usually involves one or more actions . Actions are executable statements that change values of the attributes of an object or return a value. Are calls to an object's methods or properties We will make use of two actions: Call Return Source: Kendall Scott, UML Explained (Addison-Wesley, 2001), p. 59-62.

How do objects communicate?

By sending messages (i.e., invoking a method).

A message is thus a communication between two objects (or within one) what results in some activity.

This activity usually involves one or more actions .

Actions are executable statements that change values of the attributes of an object or return a value.

Are calls to an object's methods or properties

We will make use of two actions:

Call

Return

UML Actions: Call and Return call action notation return action notation

Call and Return Example

Sequence Diagram A sequence diagram focuses on the time ordering of the messages. Objects appear along the top margin, with each object having a lifeline , with an optional flow of control on the rectangle.

A sequence diagram focuses on the time ordering of the messages.

Objects appear along the top margin, with each object having a lifeline , with an optional flow of control on the rectangle.

Sequence Diagram Example lifeline Focus of control

Collaboration Diagram A collaboration diagram is spatially oriented with an emphasis on the relationships between objects. Similar to sequence diagram, except no lifeline and focus of control.

A collaboration diagram is spatially oriented with an emphasis on the relationships between objects.

Similar to sequence diagram, except no lifeline and focus of control.

Collaboration Diagram Example

Collaboration vs Sequence Diagrams Collaboration Diagrams Shows relationships and interactions Better for visualizing all of the effects on a given object Easier to use/draw for brainstorming Sequence Diagrams Explicitly shows time ordering of messages Better for visualizing overall flow in real-time systems and complex scenarios.

Collaboration Diagrams

Shows relationships and interactions

Better for visualizing all of the effects on a given object

Easier to use/draw for brainstorming

Sequence Diagrams

Explicitly shows time ordering of messages

Better for visualizing overall flow in real-time systems and complex scenarios.

Analysis Class Model This is the final artifact of the analysis. This is a revised class diagram that includes all the responsibilities (operations) and attributes for all classes discovered via the use case realizations. You interaction diagrams indicate via the messages what should be the operations and attributes you need to add to your classes. Remember that this is an iterative and incremental process. The class diagram and the interaction diagrams will be modified repeatedly and in tandem as you work your work through the analysis.

This is the final artifact of the analysis.

This is a revised class diagram that includes all the responsibilities (operations) and attributes for all classes discovered via the use case realizations.

You interaction diagrams indicate via the messages what should be the operations and attributes you need to add to your classes.

Remember that this is an iterative and incremental process.

The class diagram and the interaction diagrams will be modified repeatedly and in tandem as you work your work through the analysis.

Analysis in Context refined by implemented by Design Model Implementation Model realized by Analysis Model message() message2() message() message2()

Analysis in the big picture Recall that in the Unified Software Development Process, there are four phases; in each phase there is a analysis workflow. What is produced during the analysis workflow varies from phase to phase. Nonetheless, most of the analysis will occur in the elaboration phase. Inception Elaboration Construction Transition 1 2 3 4 5 6 7 8 Requirements Analysis Design Implementation Test

Recall that in the Unified Software Development Process, there are four phases; in each phase there is a analysis workflow.

What is produced during the analysis workflow varies from phase to phase.

Nonetheless, most of the analysis will occur in the elaboration phase.

Analysis in the phases Inception Phase CRC sessions, noun phrase analysis to create domain model Elaboration Phase Use case realizations Analysis class model Construction Phase Additional use case realizations for any newly discovered use cases.

Inception Phase

CRC sessions, noun phrase analysis to create domain model

Elaboration Phase

Use case realizations

Analysis class model

Construction Phase

Additional use case realizations for any newly discovered use cases.