MGMT 6170- ASAD - 1 - HO 9 © HY 2006 Lecture 9 A dvanced S ystems A nalysis and D esign Fall 2006 Convener: Houman Younessi 1-860-548-7880 [email protected]

MGMT 6170- ASAD

- 1 -HO 9

© HY 2006

Lecture 9

Advanced Systems

Analysis and DesignFall 2006Convener:

Houman Younessi

1-860-548-7880

[email protected]

MGMT 6170- ASAD

- 2 -HO 9

© HY 2006

Lecture 9

Using usecases to extract an object-oriented models:

Extracting the dynamic model

A well-formed usecase can tell us which object requested what service from which other object and in what sequence. It also captures (although deficiently) whether there was simultaneity and parallel threads.

This is almost all the information we need to extract an object-oriented dynamic model of the situation. This could be in the form of sequence diagrams, collaboration diagrams or later, state diagrams.

MGMT 6170- ASAD

- 3 -HO 9

© HY 2006

Lecture 9

Extracting sequence diagrams:

If we have a well-formed usecase, construction of a sequence diagram becomes rather trivial.

A sequence diagram depicts the order of the exchange of messages between the various objects involved in order to achieve a certain goal. Usecases do exactly the same and well-formed ones contain all the necessary information to extract a sequence diagram.

MGMT 6170- ASAD

- 4 -HO 9

© HY 2006

Lecture 9

The left-hand side object of any one line of usecase is a client object, the right-hand side one the server for a particular message request, which is the transformation of that given line. Therefore all objects needed for the sequence diagram all simply the left-hand side and the right-hand side words of the transformation set.

A message (an arrow in a sequence diagram) is from a client to a server, thus it is from the life-line of a left-hand side object to the one of the right-hand side. The label on it is the name of the transformation.

The order of the arrows are the order of the lines.

Use rules of progression to figure out multi-threading.

MGMT 6170- ASAD

- 5 -HO 9

© HY 2006

Lecture 9

TTD1:TTD Exchange:Connection

Attempt_conn( )

TTD2:TTD

Attemp_disconn( )

Reset( )Disconnect( )

Establish_call( )

Use Case: Telephony Communication

Actors: TTD 1, TTD 2

Initiating Actor: TTD 1

Events:

0TTD 1 req. ser. Attempt_connection( ) from Exchange 0Exchange req. ser. Establish_call( ) from TTD 2 0TTD 1 req. ser. Attempt_disconnect( ) from Exchange 0Exchange req. ser. Disconnect( ) from TTD 1T 1Exchange req. ser. Reset( ) from TTD2T

MGMT 6170- ASAD

- 6 -HO 9

© HY 2006

Lecture 9

TTD1:TTD NSLX:LX

Connect( )

Receive_call( )

Routed( )

Dial( )

Dial-Register:Reg FSLX:LX

Sound_dial_tone( )

Use Case: Attempt_connection

Actors: TTD 1


Events:

0TTD 1 req. ser. Connect( ) from NSLX 0NSLX req. ser. Sound_dial_tone( ) from TTD 1T 1NSLX req. ser. Dial( ) from Dial_register 1Dial_register req. ser. Receive_call( ) from FSLX 1FSLX req. ser. Routed( ) from Call_registerT

MGMT 6170- ASAD

- 7 -HO 9

© HY 2006

Lecture 9

Extracting collaboration diagrams:

Collaboration diagrams contain the same essential information as sequence diagrams.

A collaboration diagram also depicts the order of the exchange of messages between the various objects involved in order to achieve a certain goal. As we know usecases also do exactly the same and well-formed ones contain all the necessary information to extract a sequence diagram.

MGMT 6170- ASAD

- 8 -HO 9

© HY 2006

Lecture 9

TTD2:TTD

Exchange:Connection

1- Attemp_connect( ) 3- Attempt_disconnect( )

4a- Disconnect( )

2- Establish_call ( ) 4b- Reset( )

TTD1:TTD




Events:


MGMT 6170- ASAD

- 9 -HO 9

© HY 2006

Lecture 9

TTD1:TTD

NSLX:LX

1. Connect( )

3. Receive_call( )

4. Routed( )

2b. Dial( )

Dial-Register:Reg

FSLX:LX

2a. Sound_dial_tone( )


Actors: TTD 1


Events:


MGMT 6170- ASAD

- 10 -HO 9

© HY 2006

Lecture 9

A well-formed usecase can tell us which object requested what service from which other object. Therefore a full set of well-formed and related usecases would contain in it all the objects that exchange messages in the system and the messages that they exchange. As each object must belong to a class, all classes required in the system are therefore identifiable. As each message is a request for an object to perform an operation, all the operations are also known.

The hierarchy of usecases and their subordinate ones also indicate a structural hierarchy.

This almost all the information we need to extract an object-oriented static model. This could be in the form of a class diagram.

MGMT 6170- ASAD

- 11 -HO 9

© HY 2006

Lecture 9

Extracting a class diagram:

Each object (right-hand side or left-hand side) must belong to a class.

So each object named in a usecase implies a class.

Each class has a number of operations that it has to perform.

So the operations indicated by the usecase define the object as its class.

MGMT 6170- ASAD

- 12 -HO 9

© HY 2006

Lecture 9

Each line of usecase at level n implies a pair of objects (therefore also classes) and an operation on the server class. This latter class may be (usually is) a complex class (an entire system or sub-system) and the operation implied with respect to it a complex behavior.

This latter operation may however be now taken as the subject for a new usecase, implying that the server object at level n is now our “system”, with (for the moment) one goal; the operation it has to perform.

Now we can start the system analysis effort over again, this time at the lower n+1 level of granularity.

This implies new lower level (component) objects (and therefore

MGMT 6170- ASAD

- 13 -HO 9

© HY 2006

Lecture 9

classes which would logically compose the higher level object at level n.

So there is a compositional relationship between the levels of a usecase and objects with which we aught to deal.

MGMT 6170- ASAD

- 14 -HO 9

© HY 2006

Lecture 9

Attempt_connect( )Attempt_disconnect( )

Connection




Events:


MGMT 6170- ASAD

- 15 -HO 9

© HY 2006

Lecture 9

Dial( )

Dial_register

Routed( )

Call_Register

Connect( )Receive_call( )

Local_exchange


Actors: TTD 1


Events:


MGMT 6170- ASAD

- 16 -HO 9

© HY 2006

Lecture 9

Dial( )

Dial_register

Routed( )

Call_Register


Local_exchange


Connection

a_Number a_Number

MGMT 6170- ASAD

- 17 -HO 9

© HY 2006

Lecture 9

Dial( )

Dial_register

Routed( )

Call_register


Local_exchange


Connection

Register

a_Number

MGMT 6170- ASAD

- 18 -HO 9

© HY 2006

Lecture 9

Reviewing usecases:Like any other artifact in software engineering, usecases may also be reviewed . We review usecases from the perspective of:

1. Well-formedness

2. Completeness

3. Fit

We shall discuss these one at a time.

MGMT 6170- ASAD

- 19 -HO 9

© HY 2006

Lecture 9

Well-formedness:

A usecase is well-formed if it follows the one initiation, five progression and two termination rules.

There may be other rules added to these to cater for architectural concerns, but that is of no concern to us here. Should extra rules exist, then following these is also a requirement of well-formedness.

Additionally, to be well-formed, a usecase must be documented in one of the accepted usecase documentation formats. The one provided herein is recommended.

MGMT 6170- ASAD

- 20 -HO 9

© HY 2006

Lecture 9

Completeness:

There are two aspects to completeness;

Essential completeness, and

Structural completeness

We must ensure both.

MGMT 6170- ASAD

- 21 -HO 9

© HY 2006

Lecture 9

Essential completeness is ensured when there is covered traceability to at least the functional requirements set. This means that all stated and implied functional requirements must be covered by usecases.

Structural completeness is ensured when all named transformations have been either expanded into lower level usecases or into procedural flow (if at leaf level). We also need to ensure that all necessary non-normal course usecases have been considered and documented.

It is also necessary to ensure that there is a relevant entry in each cell of the usecase template and that those containing no entries are explicitly mentioned to be blank.

MGMT 6170- ASAD

- 22 -HO 9

© HY 2006

Lecture 9

Fit:

Here we must ensure that everyone is happy with our usecase set. We must check for understandability, logical consistency, and necessity (that there is nothing we don’t need).

You need to review with all stakeholders:

Review with Clients

Review with Actors, and

Review with Owners.

Remember that there are several systems with which you are concerned here, not just a software specification.

MGMT 6170- ASAD

- 23 -HO 9

© HY 2006

Lecture 9

A system to achieve goal X (the software specification)

A system to develop system to do X

A system to system administer the system that achieves X

A system to deliver value for money

A system to shine and stay employed or be promoted

MGMT 6170- ASAD

- 24 -HO 9

© HY 2006

Lecture 9

Who should be present at the review?

Project chief architect

Project manager

Chief analyst – usecase developer(s)

Project Owner or representative

Chief developer/programmer

End user representatives

MGMT 6170- ASAD

- 25 -HO 9

© HY 2006

Lecture 9

The Domain Relevance Test

The Absorption Test

The Attribute/Function Test

KEEPING THE RIGHT CLASSES

Applying these techniques shall identify many potential classes from the domain. We now need to sift through these and select a coherent set of the “right” classes, discarding the rest. To do so we apply a number of heuristics (Younessi et al.; 1995):

The Domain Relevance Test

The Absorption Test

The Attribute/Function Test

Enabling Review

MGMT 6170- ASAD

- 26 -HO 9

© HY 2006

Lecture 9

The Domain Relevance Test:

Ask the following:

Does the Provisional Class/Object relate to the purpose for which the system exists?

Is information retained within the relevant system about this Class/Object?

Does this PCO have a behavior that is needed by the system?

Does this PCO have more than one attribute and/or behavior?

MGMT 6170- ASAD

- 27 -HO 9

© HY 2006

Lecture 9

The Absorption Test;

First identify all PCOs that have identical or semantically close names.

Investigate if these names actually refer to the same entity. This may not always be the case: Clerk LoanClerk or TaxationClerk

In such situations rename all for clarity.

Investigate if different PCOs have the same name. Resolve.

MGMT 6170- ASAD

- 28 -HO 9

© HY 2006

Lecture 9

Attribute/Function Test:

Isolate PCOs that have only one attribute or function.

Isolate PCOs whose name is a quantity which is simply derived by computation.

Absorb these PCOs into other PCOs that can logically contain them.

MGMT 6170- ASAD

- 29 -HO 9

© HY 2006

Lecture 9

ATTRIBUTES

An attribute is one aspect of reality relating to the class about which we need information. In fact an attribute is the shorthand for a question about the class. For example:

name:

Person This really means:

What is the name of this person?

MGMT 6170- ASAD

- 30 -HO 9

© HY 2006

Lecture 9

There are three general categories of attributes:

• Nominal attributes: They give the object a name e.g. person’s SSN

• Essential attributes or Intrinsic attributes: They describe some feature of the object, e.g. person’s DOB

• Referential attribute: They relate one object to another e.g. person’s job

In essence attributes are how the object is identified.

In order to find the relevant attributes, ask the following questions:

• How would anyone in this domain describe this class?

• How would anyone in this domain recognize this class?

• What questions would this class be responsible to answer in this domain?

MGMT 6170- ASAD

- 31 -HO 9

© HY 2006

Lecture 9

Good attributes should have the following characteristics:

• Relevant: An attribute must relate to the universe of discourse; e.g. color of check not relevant in a banking system

• Atomic: An attribute must contain one value at any one time

• Encompassing: An attribute must be characteristic of the entire object not a component of it; e.g. diameter is an attribute of a tire not of a car

• Local(non-relational): The attribute of an object must not attempt to capture a characteristic of a relationship; e.g. permission_value is an attribute of Permission not of either a Person or a File.

MGMT 6170- ASAD

- 32 -HO 9

© HY 2006

Lecture 9

OPERATIONS

Operations are things that a class does (for other classes). They are the responsibilities of the class. This must be contrasted with things that class a does for itself. These are the private methods. We are concerned with operations (i.e. responsibilities).

Operations can also be simple or complex. Simple operations are not necessary in an analysis model. Simple operations include:

Connect(), get(), set(),disconnect().

MGMT 6170- ASAD

- 33 -HO 9

© HY 2006

Lecture 9

Operations are found by looking for:

• Action verbs in a problem statement or use case Responsibilities on a CRC card

• Actions and activities of a state diagram (if available)

MGMT 6170- ASAD

- 34 -HO 9

© HY 2006

Lecture 9

Object orientation is all about message passing between objects. For messages to pass between objects (programming view):

• Object C:c passes object B:b as an argument in a message to object A:a.

• Object A:a contains object B:b.

• Object A:a has a link to object B:b

• Object A:a’s service belongs to object B:b

ACCESS

CONTAINMENT

ASSOCIATION

INHERITANCE

In the analysis domain, these are all forms of relationships

MGMT 6170- ASAD

- 35 -HO 9

© HY 2006

Lecture 9

Technically speaking an association is a relationship between the classes of objects. This means that a link is established between these objects that are instances of this association. A link between two objects lets one object be mapped to the other.

This is a static relationship between classes, it is NOT a path for a message or a dynamic link between two individual objects.

MGMT 6170- ASAD

- 36 -HO 9

© HY 2006

Lecture 9

Look for the following categories:

• A is a physical part of B e.g., Wing-Airplane

• A is a logical part of B e.g., FlightLeg - Flight

• A is physically contained in B e.g, Passenger, Aircraft

• A is logically contained in B e.g., Passenger-Manifest

• A is a description of B e.g. FlightPlan-Flight

• A is a line item of B (aggregand) e.g. OrderLine-Order

• A is a member of B e.g. Pilot-Airline

• A is owned by B e.g., Aircraft-Airline

• A has a contract with B e.g. Passenger-Airline

• A is an organizational subunit of B e.g. Tower-Airport

• A uses B e.g. Passenger-Flight

MGMT 6170- ASAD

- 37 -HO 9

© HY 2006

Lecture 9

• Indicates a relationship of some permanence (or at least duration) between classes.

• The relationship is well defined, contextually meaningful and are usually an abstraction of a constant.

• Can be shown as:

An association:

A static mapping

MGMT 6170- ASAD

- 38 -HO 9

© HY 2006

Lecture 9

AGGERGATION V. CONTAINMENT

We said earlier that in UML, aggregation was modeled in two forms : Weak aggregation and Composition.

What is important is to note that containment IS NOT a form of aggregation.

(In fact there are seven forms of aggregation of which the above are only two examples but we shall not go into the details here).

MGMT 6170- ASAD

- 39 -HO 9

© HY 2006

Lecture 9

Containment is that relationship when an object is temporarily placed inside another. For example a picnic basket in the trunk of a car.

In contrast aggregation is the relationship between objects which has a compositional, more permanent (not necessarily perpetual), and emergent properties.

Containment is always transitive, aggregation may or may not be.

Yet both containment and aggregation are always asymmetric.

MGMT 6170- ASAD

- 40 -HO 9

© HY 2006

Lecture 9

Example:

An apple in a picnic basket in the trunk of a car (Containment)

Left arm part of Houman, Houman part of CS department (Aggreg.)

Now an apple, or a picnic basket although inside a car are not a part of the car in the sense that there is no emergent relationship or dependency between them. On the other hand, Houman’s arm is part of Houman and without it Houman will not be complete. Houman is also part of the CS department and without him (Houman hopes) the CS department is not complete.

MGMT 6170- ASAD

- 41 -HO 9

© HY 2006

Lecture 9

This is the parent-child relationship. UML’s label for this type of relationship is GENERALIZATION.

In fact there are three main forms of inheritance all of which may be gainfully used in object orientation but only one of these conforms to a generalization.

The three types are: Generalization

Specialization

Restriction

Inheritance

MGMT 6170- ASAD

- 42 -HO 9

© HY 2006

Lecture 9

The trouble stems from the confusion between the two concepts of sub-typing and sub-classing.

Sub-typing is when A is-a B or more correctly A can-act-as-a B.

Sub-classing (that is not sub-typing) is the relationship where A is-derived-from B but can not act as it.

Sub-typing implies extension

Sub-classing implies specialization or restriction

MGMT 6170- ASAD

- 43 -HO 9

© HY 2006

Lecture 9

As the name implies sub-typing is a logical relationship between types. Specialization and restriction are physical relationships between implementations of classes.

Example:

MOUSE is a sub-type of MAMMAL

A BINARY_SEARCH_TREE is a sub-type of BINARY_TREE

For B to be a sub-type of A, it first has to be an A. Then it can only ADD features, leaving all other features unchanged.

MGMT 6170- ASAD

- 44 -HO 9

© HY 2006

Lecture 9

Specialization is the relationship between classes where one class is altered to yield another by changing one or several of its features.

Example:

Compound_Interest_Account v. Simple_Interest_Account

Note:

A C.I.A. is not or can not act as a S.I.A. but we can take a S.I.A and change its feature that calculates interest to obtain a C.I.A.

MGMT 6170- ASAD

- 45 -HO 9

© HY 2006

Lecture 9

Restriction is the relationship between classes where one or several features of one class is restricted (locked) to yield another.

Example:

Interest_Bearing_Account v. No_Interest_Account

Note:

A N.I.A. is not or can not act as an I.B.A. but we can take an I.B.A and lock its feature that calculates interest to obtain a N.IA.

MGMT 6170- ASAD

- 46 -HO 9

© HY 2006

Lecture 9

The major differences between ER Diagrams and Class Diagrams:

ER Only models persistent data

Class diagrams Model persistent AND transient objects

ER The relationships are mappings

Class diagrams The relationships are mappings and other structural

ER Depicts only attributes (static individual state no information about possible operations that interact with this

state

Class diagrams Depicts attributes AND operations

MGMT 6170- ASAD

- 47 -HO 9

© HY 2006

Lecture 9

The CRC technique is used either after use cases have been developed or whilst this is happening. It has essentially four uses:

• To extract a model. To identify model elements such as classes, methods and associations

• To validate or complete use cases

• To refine a model

• To validate a model and highlight model/design flaws

CLASS-RESPONSIBILITY-COLLABORATION (CRC)

MGMT 6170- ASAD

- 48 -HO 9

© HY 2006

Lecture 9

CRC CARDS

The process of production of CRC cards is most aligned with the first utility mentioned: To identify model elements such as classes, methods and associations.A CRC card is a 4 6 or a 5 7 card one which there are three main compartments. These compartments are:

• Class Name

• Responsibility

• Collaboration

MGMT 6170- ASAD

- 49 -HO 9

© HY 2006

Lecture 9

Class Name

Responsibility CollaborationWe develop a CRC card for each new potential class.

MGMT 6170- ASAD

- 50 -HO 9

© HY 2006

Lecture 9

Example: Order

Check if item in stock

Determine price

Check for valid payment

Dispatch

::::::::::::::::::::::::::::::::::::

Order Line

Order Line

Customer

On the back of the card there is usually one or sometimes up to four compartments:

MGMT 6170- ASAD

- 51 -HO 9

© HY 2006

Lecture 9

Project

Hierarchy

Attributes

Description and comments

Back of a CRC Card

The Attribute compartment is the most important and houses information regarding the attributes of the potential class.

Project

Hierarchy Attributes

Description and commentsorder no

date

etc.

Supply Logistics

Cash order, Credit Order

MGMT 6170- ASAD

- 52 -HO 9

© HY 2006

Lecture 9

USING CRC CARDS

• Identify a potential class. This may be done with the help of a usecase.

• Create a card for that class by first selecting a name and putting that name on the card.

• Now identify one responsibility for which you feel this class must exist. Record this in the responsibilities column

• Identify the potential object that requests this responsibility of the class identified. Record this in the collaboration column and in front of the responsibility concerned.

• Identify the specific pieces of information needed to identify this class, or the class needs to hold. Write them as attributes on the back of the card.

• If this potential class is in a hierarchy, depict the hierarchy.

• Include some notes and comments if needed and identify the project.

• Produce a similar card for any new potential class that was discovered.

MGMT 6170- ASAD

- 53 -HO 9

© HY 2006

Lecture 9

CRC GAME

Once you have a handful of inter-relating CRC cards that collectively describe the system or at least some of its functionality, you are ready to play the CRC game. The game is played in two different forms depending on whether the intent is to validate the model or to refine it.

To refine the model, you have to have your CRC cards and one person to play the role of each class.

To validate you have to have a reasonably complete set of cards, a reasonably comprehensive set of use cases, one person to play each class and one or several small bean bags, balls or similar objects.

MGMT 6170- ASAD

- 54 -HO 9

© HY 2006

Lecture 9

MODEL REFINEMENT

Give each person the card they are to play the role of.

Start at a logical place with some class. Debate if it is needed or if it needs to change.

Start a thread that can be initiated by invoking one of the responsibilities of that class.

Identify the collaborator (target) class. Pass control to that class by calling the service you need of that class. If collaborator class does not exist, create it.

Keep playing until every responsibility on every card has been either discharged or debated and discarded. Similarly for every attribute.

Do not be afraid to combine classes, or split them as necessary, or indeed discard them.

Add responsibilities as and when needed or delete them if not useful.

MGMT 6170- ASAD

- 55 -HO 9

© HY 2006

Lecture 9

MODEL VALIDATION

• Give each person the card they are to play the role of. Also nominate a person to play each external actor.

• Start with your top ranking use case . Identify the actor who initiates things and give him or her the bean bag.

• The actor starts a thread that can be initiated by passing the bag to the correct class according to the use case.

• The class checks if it can accept the bag. If yes, it does so, if not we raise an alarm and debate and rectify the model. The class now passes the bag to a class whose service it needs (calls), a class for which it is a collaborator.

• Keep playing until the use case is complete and update the model if necessary

• Go to the next use case

Documents

MGMT 6170- ASAD - 1 - HO 9 © HY 2006 Lecture 9 A dvanced S ystems A nalysis and D esign Fall 2006 Convener: Houman Younessi 1-860-548-7880 [email protected]