ECSE 6770- Software Engineering

HO 7 Lecture 7 - 1 -

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 objectoriented dynamic model of the situation. This could be in the form of sequence diagrams, collaboration diagrams or later, state diagrams.

ECSE 6770- Software Engineering © HY 2012

HO 7 Lecture 7

Extracting sequence diagrams :

- 2 -

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.


HO 7 Lecture 7 - 3 -

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


HO 7 Lecture 7 - 4 -

TTD1:TTD Exchange:Connection

Attempt_conn( )

Establish_call( )

TTD2:TTD

Establish_call( )

Attemp_disconn( )

Disconnect( )

Reset( )

ECSE 6770- Software Engineering

Use Case: Telephony Communication

Actors: TTD 1, TTD 2

Initiating Actor: TTD 1

Events :

0 TTD 1 req. ser. Attempt_connection( ) from Exchange

0 Exchange req. ser. Establish _call from TTD1

1 0 Exchange req. ser. Establish_call( ) from TTD 2

0 TTD 1 req. ser. Attempt_disconnect( ) from Exchange

0 Exchange req. ser. Disconnect( ) from TTD 1 T

1 Exchange req. ser. Reset( ) from TTD2 T

© HY 2012

HO 7 Lecture 7 - 5 -

TTD1:TTD

Connect( )

NSLX:LX

Sound_dial_tone( ) Dial( )

Dial-Register:Reg

Receive_call( )

FSLX:LX

Routed( )

Call-Register:Reg


Use Case: Attempt_connection

Actors: TTD 1


Events :

0 TTD 1 req. ser. Connect( ) from NSLX

0 NSLX req. ser. Sound_dial_tone( ) from TTD 1 T

1 NSLX req. ser. Dial( ) from Dial_register

1 Dial_register req. ser. Receive_call( ) from FSLX

1 FSLX req. ser. Routed( ) from Call_register T

© HY 2012

HO 7 Lecture 7

Extracting collaboration diagrams :

- 6 -

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 wellformed ones contain all the necessary information to extract a sequence diagram.


HO 7 Lecture 7 - 7 -

TTD1:TTD

4a- Disconnect( )

1- Attemp_connect( )

3- Attempt_disconnect( )

Exchange:Connection

TTD2:TTD


2- Establish_call ( )

4b- Reset( )




Events :


0 Exchange req. ser. Establish_call( ) from TTD 2




© HY 2012

HO 7 Lecture 7 - 8 -

TTD1:TTD

1. Connect( )

2a. Sound_dial_tone( )

NSLX:LX

2b. Dial( )

4. Routed( )

Dial-Register:Reg

3. Receive_call( )

FSLX:LX


Actors: TTD 1


Events :





1 FSLX req. ser. Routed( ) from Dial_register T


HO 7 Lecture 7 - 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 objectoriented static model. This could be in the form of a class diagram.


HO 7 Lecture 7 - 10 -

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.


HO 7 Lecture 7 - 11 -

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


HO 7 Lecture 7 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.

- 12 -


HO 7 Lecture 7




Events :


0 Exchange req. ser. Establish_call( ) from TTD 2




Connection

Attempt_connect( )

Attempt_disconnect( )


- 13 -

© HY 2012

HO 7 Lecture 7 - 14 -

Call_Register

Routed( )

Local_exchange

Connect( )

Receive_call( )

Dial( )


Actors: TTD 1


Events :





1 FSLX req. ser. Routed( ) from Call_register T


Dial_register

© HY 2012

HO 7 Lecture 7

Connection

Attempt_connect( )


- 15 -

Local_exchange

Call_Register a_Number

Routed( )


Connect( )

Receive_call( )

Dial_register a_Number

Dial( )

© HY 2012

HO 7

Connection

Attempt_connect( )


Lecture 7

Register a_Number

- 16 -

Local_exchange

Call_register

Connect( )

Receive_call( )


Routed( )

Dial( )

Dial_register

© HY 2012

HO 7 Lecture 7 - 17 -

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.


HO 7 Lecture 7 - 18 -

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.


HO 7 Lecture 7

Completeness:

There are two aspects to completeness;

Essential completeness,

Structural completeness and

We must ensure both.


- 19 -

© HY 2012

HO 7 Lecture 7 - 20 -

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.


HO 7 Lecture 7 - 21 -

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.


HO 7 Lecture 7

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

- 22 -


HO 7 Lecture 7

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


- 23 -

© HY 2012

HO 7 Lecture 7 - 24 -

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:

Person name:

This really means:

What is the name of this person?


HO 7 Lecture 7 - 25 -

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?


HO 7 Lecture 7 - 26 -

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.


HO 7 Lecture 7 - 27 -

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


HO 7 Lecture 7

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)

- 28 -


HO 7 Lecture 7 - 29 -

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.

ACCESS

CONTAINMENT

•

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

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

ASSOCIATION

INHERITANCE

In the analysis domain, these are all forms of relationships


HO 7 Lecture 7 - 30 -

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.


HO 7 Lecture 7

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


- 31 -

© HY 2012

HO 7 Lecture 7 - 32 -

An association:

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

A static mapping


HO 7 Lecture 7 - 33 -

AGGERGATION V. CONTAINMENT

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

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

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


HO 7 Lecture 7 - 34 -

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.


HO 7 Lecture 7 - 35 -

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.


HO 7 Lecture 7 - 36 -

Inheritance

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


HO 7 Lecture 7 - 37 -

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


HO 7 Lecture 7 - 38 -

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.


HO 7 Lecture 7 - 39 -

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.


HO 7 Lecture 7 - 40 -

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.


HO 7 Lecture 7 - 41 -

The major differences between ER Diagrams and Class Diagrams:

ER Only models persistent data

Class diagrams

ER

Class diagrams

Model persistent AND transient objects

The relationships are mappings

ER

Class diagrams

The relationships are mappings and other structural

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

Depicts attributes AND operations


HO 7 Lecture 7 - 42 -

CLASS-RESPONSIBILITY-COLLABORATION (CRC)

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


HO 7 Lecture 7 - 43 -

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


HO 7 Lecture 7

Class Name

- 44 -

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


Collaboration

© HY 2012

HO 7 Lecture 7 - 45 -

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:


HO 7 Lecture 7 - 46 -

Project

Hierarchy

Description and comments

Attributes

Back of a CRC Card

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

Project

Supply Logistics

Hierarchy Attributes

Cash order, Credit Order order no

Description and comments date etc.


HO 7 Lecture 7 - 47 -

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.


HO 7 Lecture 7 - 48 -

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


HO 7


Lecture 7 - 49 -

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.

© HY 2012

HO 7 Lecture 7 - 50 -

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.


HO 7 Lecture 7 - 51 -

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.


HO 7 Lecture 7 - 52 -

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.


HO 7 Lecture 7 - 53 -

• 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


ECSE 6770- Software Engineering

Inheritance

Related documents

Products

Support

ECSE 6770- Software Engineering

Inheritance

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib