SOFTWARE ENGINEERING (FALL 2014)

CMPE 202-01
INDIVIDUAL ASSIGNMENT #2
PATTERN: OBLIGATION

Submitted to: Dr. M. E. Fayad

Submitted on:

Submitted by:
Vijeta Karani (vijetakarani6@gmail.com)
Student ID: 009979827

1. Pattern Documentation:
Pattern Name: Agreement stable Design Pattern
Obligation is generally referred to as something by which a person is bound to do
certain things and which arises out of a sense of duty. It can be Any form of agreement
between two or more actors. In general AnyParty, AnyActor is obliged to any other party
or actor or AnyEntity or AnyEvent. This acts as a contract, agreement or a promise
between the parties, actors, entities or events involved. Obligation is an Enduring
Business Theme (EBT), since it is the ultimate goal of AnyAgreement which is a Business
Object (BO).
Context:
The purpose of Agreement is to bind two or more things to a certain clause.
Scenarios:
The scenarios are as follows:
In Cinema:
Cinema involves a lot of investment in terms of time, hard work and money. Right from
the spot boys to the actors, everyone puts in a lot of effort in the making of a film. All of
these are bound by a contract or agreement during the whole tenure of the film from
making to finally promoting the film as also collecting the revenues. This agreement or
contract keeps them bound to the film and also makes the person liable to answer in
case of violation of the agreement.
In Marriage:
Marriage is an institution where two people promise to be with each other for the rest
of their lives. The promise is sort of an agreement that they make to each other.
Marriage also involves a legal agreement which makes both the parties legally bound to
duties and responsibilities towards each other. They are then bound to do certain things
out of sense of duty.
In Corporates:
An agreement in the corporate world includes many clauses. The company becomes
liable to pay a certain amount of money and services to the employee in return to the
services offered by the employee. Also, the employee is then bound to follow a certain
code of conduct to keep working peacefully in the organization as also to maintain a
decorum for other employees as well. The employee is also expected to provide certain

services and also provide those services for an agreed upon tenure. Thus, agreement
plays a very important role in the proper functioning of a corporate office.
2. Problem:
The agreement pattern is designed to set certain rules or clauses to be agreed upon by
the entities that are involved in it. AnyActor or AnyParty agree upon a contract with
AnyActor or AnyParty or AnyEntity or AnyEvent by following AnyClause. AnyAgreement
is signed for AnyReason. It has AnyConsequence on the system. The pattern is designed
in such a way that it can be used for many different scenarios and this is done by
specifying Enduring Business Theme (EBT), Business Objects (BO) and Industrial Objects
(IO).
2.1 Functional Requirements:
Obligation:
Obligation can be defined as a reason for AnyAgreement to bind the people on a
contract. AnyActor or AnyParty oblige to AnyClause mentioned in AnyAgreement.
AnyActor:
AnyActor obliges to AnyClause mentioned in the agreement and also follows AnyRules
according to the clauses mentioned in the agreement.
AnyParty:
AnyParty is a legal user such as an organization who is responsible for defining
AnyClause and AnyRule for AnyAgreement.
AnyRule:
This specifies the rules, which are supposed to be followed by AnyActor or AnyParty
which abide by AnyAgreement. Any violation of the rules leads to legal actions or
suspension of AnyAgreement.
AnyClause:
AnyClause relates to how AnyRule is going to be implemented. AnyClause is designed on
the basis of AnyRule applied by AnyParty.
AnyConsequence:
AnyConsequence is a result or effect of the violation of AnyRule and AnyClause in
AnyAgreement.
AnyLog:
The details of AnyRule and AnyClause can be maintained as AnyLog.
AnyMedia:
AnyMedia is used to store AnyLog. AnyMedia pertains to internet, websites, etc. AnyLog
can be stored in a hardware or software as also can be maintained on sheets of paper.

AnyEvent:
AnyEvent refers to something that happens in the organization. It refers to the event
which lead to the violation of AnyRule and AnyCause in AnyAgreement.
AnyType:
AnyAgreement can be of AnyType. AnyType refers to a legal agreement, or a contract or
just a promise between AnyActor or AnyParty
2.2 Non-Functional Requirements:
Relevance:
Agreement should be relevant and must follow the rules and clauses. The agreement
should set rules which act as boundaries. Any change in these set of rules would lead to
the violation of the agreement.
Realistic:
The rules and clauses set in an agreement by a party must be realistic. They have to be
such which can be executed by the actors who abide by it. They should be realistic in
nature and should be achievable.
Convincible:
The actors or parties which agree to abide the rules and the clauses stated in an
agreement must find the rules and clauses convincing. The actors should be able to
follow them at any given point of time.
2.3 Challenges and constraints:
2.3.1 Challenges:
1. AnyActor is responsible for abiding by AnyRule and AnyClause in the system.
The violation of any one of them may lead to the termination of
AnyAgreement.
2. AnyParty defines AnyRule and AnyClause for AnyAgreement. If AnyRule and
AnyClause are not defined properly, then it becomes impossible for AnyActor
to follow them properly for complete execution of AnyAgreement.
3. If AnyRule or AnyClause is not defined properly for AnyAgreement, it may
result in a negative impact on the application.
4. Fulfillment of AnyAgreement is dependent on AnyRule or AnyClause
provided by AnyParty or AnyActor. Lack of rules or clauses provided for
AnyAgreement to be successful results in failure of the system efficiency.

5. AnyEvent should be correctly identified in order to avoid suspension of

AnyAgreement.
6. Absence of AnyMedia results in failure to log AnyRule or AnyClause as also
AnyConsequence. This results in lack of proof.
7. If system is built without taking AnyImpact into consideration, then
AnyImpact of the system would degrade the performance of the system.
8. Every BO should have IO. Model should be balanced and should not be
dangling.

2.3.2 Constraints:
1. Obligation for AnyAgreement should be realistic, relevant and convincible.
2. AnyActor should be responsible for Obligation of AnyAgreement in the
system.
3. Appropriate AnyRule and AnyClause should be defined by AnyParty.
4. AnyRule and AnyClause should be defined in such a way that it should be
able to define any support.
5. AnyAgreement should have one or more type to distinguish between
different reasons.
6. There should be one or more media for AnyLog to be stored.
7. One or more Anytype should be associated with AnyAgreement.
8. AnyLog should be able to store AnyRule, AnyClause, AnyImpact and
AnyConsequence of the system.
9. AnyActor should follow AnyRule and AnyClause for AnyAgreement to
achieve its goal.
10. AnyRule and AnyClause should be related to AnyCause and it should not be
out of scope.
11. AnyEvent should have be specified in order to avoid suspension of
AnyAgreement.
12. AnyAgreement requires AnyRule and AnyClause to get the best result from
the system.
13. AnyEvent and AnyAgreement should be related to each other.
14. One or more Anytype should be associated with AnyAgreement.
15. To measure AnyImpact or AnyConsequence, it is necessary to have some
Impact or Consequence of the system.
16. AnyParty must specify AnyRule or AnyClause for AnyAgreement.
3. Solution:

3.1 Pattern Structure:

Figure 1: Pattern Class Diagram

Class Diagram Description:
1. AnyActor or AnyParty seeks for Evaluation by following specific rules.
2. Evaluation is done using AnyAppraisal process.
3. AnyAppraisal uses AnyEntity, which is a part of AnyDomain to achieve
Evaluation.
4. AnyAppraisal produces AnyImpact on actor/party involved.
5. These impacts must be recorded, AnyLog based on AnyMedia.
6. AnyImpact will be based on AnyRule that is applied in the system.
7. AnyEvent will be based on AnyMedia and this participates in AnyEntity.
CRC Cards:
Obligation (Obligation)<EBT>
Responsibility

Collaboration

To set a sense of duty in the system

Client
1. AnyAgreement
2. AnyParty
3. AnyActor

Server

1. obliges()
2. bringsSystematicBeh
aviour()

3. leadsToImpact()
Attributes: name, type, impact, description

AnyParty/AnyActor (AnyParty/AnyActor)<P-BO>
Responsibility

Collaboration

To abide by the agreement.

Client

Server

1. Obligation
2. AnyRule
3. AnyConsequence

1.
2.
3.
4.

5.

participate()
playRole()
join()
leave()
follow()

Attributes: id, partyName/actorName, type, role, member, activity, partiesInvolved, purpose

AnyRule (AnyRule)<P-BO>
Responsibility

Collaboration

To define set of rules.

Client

Server

1. AnyParty
2. AnyActor
3. AnyIdea

1. defineRequirements(
)
2. modifyCriteria()
3. validateRules()

Attributes: context, id, criteriaName, description, components

AnyClause (AnyClause)<P-BO>
Responsibility

Collaboration

To provide assistance for any cause.

Client
1.
2.
3.
4.

Server
AnyParty
AnyActor
AnyCriteria
AnyCause

1. ideaForCause()
2. proposeIdea()
3. reviewIdea()

Attributes: name, theme, description, context, id

AnyImpact (AnyImpact)<P-BO>
Responsibility

Collaboration

To calculate the consequence or result of Client

cause
1. AnyMedia

Server

1. analysis()

2. AnyLog
3. AnyInspiration

2. comparison()
3. finalOutput()

Attributes: id, name, result, description, context, reason

AnyConsequence (AnyConsequence)<P-BO>
Responsibility

Collaboration

To get inspiration for a good cause.

Client
4.
5.
6.
7.

Server
AnyCause
AnyEvent
AnyEntity
AnyOutcome

1. obtainOutcome()
2. relatesToCause()
3. inspiresFromEvent()

Attributes: id, name, result, description, context, reason

AnyEvent/AnyEntity (AnyEvent/AnyEntity)<P-BO>
Responsibility

Collaboration

To provide Motivation

Client

Server

1. AnyType
2. AnyMedia
3. AnyInspiration

1. initiateChange()
2. causeMotivation()
3. spreadNews()

Attributes: id, eventName, eventType, status, position, states, type

AnyAgreement (AnyAgreement)<P-BO>
Responsibility

Collaboration

To help and support cause

Client
1.
2.
3.
4.

Server
Motivation
AnyIdea
AnyInspiration
AnyType

1. outcome()
2. motivate()
3. awareness()

Attributes: id, name, result, description, context, reason

AnyType (AnyType)<P-BO>
Responsibility

Collaboration

To classify components.

Client
1. AnyCause
2. AnyEntity

Server

1. change()
2. operateOn()

3. AnyEvent

3. nameAttribute()

Attributes: id, typeName, properties, methodList, attributeList

AnyMedia (AnyMedia)<P-BO>
Responsibility

Collaboration

To broadcast data and information of an Client

event or entity
1. AnyOutcome
2. AnyEntity
3. AnyEvent
4. AnyLog

Server

1.
2.
3.
4.
5.

connect()
broadcast()
capture()
store()
display()

Attributes: id, mediaName, mediaType, securityLevel, status, sector

AnyLog (AnyLog)<P-BO>
Responsibility

Collaboration

To store data and information of an event Client

or entity
1. AnyOutcome
2. AnyMedia

Server

1.
2.
3.
4.
5.
6.
7.

nameLog()
replaceLog()
removeLog()
searchLog()
openLog()
closeLog()
editLog()

Attributes: id, logName, logType, logReferences, logCriteria, logSize, logLocation, logPath

Case Study #1
Description: The first case study is related to film making (cinema). Cinema
involves a lot of investment in terms of time, hard work and money. Right from the
spot boys to the actors, everyone puts in a lot of effort in the making of a film. All of
these are bound by a contract or agreement during the whole tenure of the film
from making to finally promoting the film as also collecting the revenues. This
agreement or contract keeps them bound to the film and also makes the person
liable to answer in case of violation of the agreement.
Class Diagram:
has

1 *

1 *

for
AnyAgreemen
t

AnyClause

implements

AnyParty

Obligation

1 *

AnyRule

AnyActor

results in
AnyConseque
1 *
nce

has

AnyImpact

Actors

ScriptDisclos
ure

Profit

Success

Loss

Producer

Contract

1 *
mentioned
on
1 *

triggers

mentioned on

1 *

is of
1 *

1 *

AnyEntity

is of
1 *

AnyType

AnyLog

stores on AnyMedia
1 *

Promotion

AnyEvent
mentioned on

Figure 2: Class diagram for Obligation Scenario #1

Use Case #

Use Case 1

Use Case Title

Film Making (Cinema)

Actor

Roles

AnyParty

Actors, Producer

Classes

Type

Attributes

Operations

BoxOfficeRe
cords

Database

Obligation

EBT

1.
2.
3.
4.

AnyParty

BO

1.
2.
3.
4.
5.
6.
7.

id
partyName
type
role
member
activity
partiesInvolve
d
8. purpose

1.
2.
3.
4.

1.
2.
3.
4.
5.
6.
7.

id
actorName
type
role
member
activity
partiesInvolve
d
8. purpose

1.
2.
3.
4.

AnyActor

BO

name
type
outcome
description

1. obliges()
2. bringsSystematicBeh
aviour()

5.

5.

participate()
playRole()
join()
leave()
follow()

participate()
playRole()
join()
leave()
follow()

AnyClause

BO

1.
2.
3.
4.
5.

context
id
criteriaName
description
components

1. defineRequirements()
2. modifyCriteria()
3. validateRules()

AnyRule

BO

1.
2.
3.
4.
5.

name
theme
description
context
id

1. ideaForCause()
2. proposeIdea()
3. reviewIdea()

AnyImpact

BO

1.
2.
3.
4.
5.
6.

id
name
result
description
context
reason

1. analysis()
2. comparison()
3. finalOutput()

AnyConsequence

BO

1.
2.
3.
4.
5.

id
name
description
context
reason

1. reasonForCause()
2. measureImpact()
3. analyzeChange()

AnyEvent

BO

1.
2.
3.
4.
5.
6.
7.

id
eventName
eventType
status
position
states
type

1. initiateChange()
2. causeAwareness()
3. spreadNews()

AnyType

BO

1.
2.
3.
4.
5.

id
typeName
properties
methodList
attributeList

1. change()
2. operateOn()
3. nameAttribute()

AnyMedia

BO

1.
2.
3.
4.
5.
6.

id
mediaName
mediaType
securityLevel
status
sector

1.
2.
3.
4.
5.

connect()
broadcast()
capture()
store()
display()

AnyLog

BO

1.
2.
3.
4.
5.
6.
7.
8.

id
logName
logType
logReferences
logCriteria
logSize
logLocation
logPath

1.
2.
3.
4.
5.
6.
7.

nameLog()
replaceLog()
removeLog()
searchLog()
openLog()
closeLog()
editLog()

AnyAgreement

BO

Actor

IO

1. id
2. name
3. type
1.
2.
3.
4.
5.
6.

name
id
degree
address
zipcode
number

1. outcome()
2. motivate()
3. awareness()
1. chacks ()
2. acts ()
3. takesCheque()

Contract

IO

1.
2.
3.
4.

name
details
description
number

1. termsAndConditions()
2. descriptionOfForm()
3. mentionsCriteria()

Producer

IO

1.
2.
3.
4.
5.
6.

name
id
degree
address
zipcode
number

1. produces()
2. givesMoney()

ScriptDisclosure

IO

Profit

IO

1. name
2. type
1. name
2. id
3. number

Loss

IO

1. name
2. type

Promotion

IO

1. name
2. id
3. type

1. discloseScript()
1.

divide()

1. count()

1. act()
2. holdevent()

Use Case Description:

1. Motivation is used for bringing change in the system for creating a good cause.
2. AnyParty or AnyActor participates in the blood donation cause and plays a role of
donor to donate blood.
3. In the process of donating blood, there are some rules and criteria that needs to
be followed such as filling of the form to check for the donors previous records.
4. The idea of proposing and organizing blood donation camp is carried out any
AnyParty or AnyActor.
5. AnyOutcome of this camp is the result of good cause. Analysis of the response got
from camp is done based on the previous records and compared to see whether
the blood donation camp was a successful move or not.
6. Event of Blood donation camp is used to initiate, cause and spread awareness in
the system.
7. AnyMedia is used to connect with the world and broadcasts about the latest news
related to the camp.
8. All the data collected by AnyMedia is stored in AnyLog. AnyLog can be opened,
removed, searched in order to check for the history of the blood donation camp.
9. Doctors in the camp checks donor and takes blood from the donor. They also
treats patients when matching blood group is found for the patient that can cure
patients health.
10. Donors visits doctors to give then the blood sample which can be useful for the

patients.
11. Patient receives matching blood from donor and treatment is done based on
appropriate drug.
12. The entire information of the camp is gathered and stored in AnyLog. The process
of the camp to donate blood is broadcasted.
Case Study #2
Description: The second case study is related to marriage. Marriage is an institution
where two people promise to be with each other for the rest of their lives. The promise
is sort of an agreement that they make to each other. Marriage also involves a legal
agreement which makes both the parties legally bound to duties and responsibilities
towards each other. They are then bound to do certain things out of sense of duty.
Class Diagram:

Figure 3: Class Diagram for Obligation: Scenario 3

Use Case #

Use Case 2

Use Case Title

Marriage

Actor

Roles

AnyParty

Couple, Priest

Classes

Type

Attributes

Obligation

EBT

5.
6.
7.
8.

AnyParty

AnyActor

BO

BO

name
type
outcome
description

Operations

3. obliges()
bringsSystematicBehaviour()

9. id
10. partyName
11. type
12. role
13. member
14. activity
15. partiesInvolve
d
16. purpose

6.
7.
8.
9.

9. id
10. actorName
11. type
12. role
13. member
14. activity
15. partiesInvolve
d
16. purpose

6.
7.
8.
9.

1.

1.

participate()
playRole()
join()
leave()
follow()

participate()
playRole()
join()
leave()
follow()

AnyClause

BO

6. context
7. id
8. criteriaName
9. description
10. components

4. defineRequirements()
5. modifyCriteria()
1. validateRules()

AnyRule

BO

6. name
7. theme
8. description
9. context
10. id

4. ideaForCause()
5. proposeIdea()
1. reviewIdea()

AnyImpact

BO

7. id
8. name
9. result
10. description
11. context
12. reason

4. analysis()
5. comparison()
1. finalOutput()

AnyConsequence

BO

6. id
7. name
8. description
9. context
10. reason

4. reasonForCause()
5. measureImpact()
1. analyzeChange()

AnyEvent

BO

8. id
9. eventName
10. eventType
11. status
12. position
13. states
14. type

4. initiateChange()
5. causeAwareness()
1. spreadNews()

AnyType

BO

6.
7.
8.
9.
10.

id
typeName
properties
methodList
attributeList

4. change()
5. operateOn()
1. nameAttribute()

AnyMedia

BO

7.
8.
9.
10.
11.
12.

id
mediaName
mediaType
securityLevel
status
sector

6.
7.
8.
9.
1.

AnyLog

BO

9. id
10. logName
11. logType
12. logReferences
13. logCriteria
14. logSize
15. logLocation
16. logPath

connect()
broadcast()
capture()
store()
display()

8. nameLog()
9. replaceLog()
10. removeLog()
11. searchLog()
12. openLog()
13. closeLog()
14. editLog()

AnyAgreement

BO

Couple

IO

Contract

4. id
5. name
type

4. outcome()
5. motivate()
1. awareness()

7.
8.
9.
10.
11.
12.

name
id
degree
address
zipcode
number

4. chacks ()
5. acts ()
1. takesCheque()

IO

5.
6.
7.
8.

name
details
description
number

4. termsAndConditions()
5. descriptionOfForm()
1. mentionsCriteria()

Priest

IO

7.
8.
9.
10.
11.
12.

name
id
degree
address
zipcode
number

3. produces()
4. givesMoney()
1.

Violence

IO

1. discloseScript()

Chores

IO

3. name
type
4. name
5. id
6. number

Relation

IO

3. name
4. type
7.

count()

Reception

IO

4. name
5. id
8. type

3. act()
holdevent()

divide()

Use Case Description:

1. Motivation is used for bringing change in the system for creating a good cause.
2. AnyParty or AnyActor participates in the money donation cause and plays a role
of donor to donate money.
3. In the process of donating money, there are some rules and criteria that needs to
be followed such as filling of the form to check for the donors previous records.
4. The idea of proposing and organizing money donation is carried out any
AnyParty or AnyActor.
5. AnyOutcome of this camp is the result of good cause and to bring awareness.
Analysis of the response got from camp is done based on the previous records
and compared to see whether the blood donation camp was a successful move or

not.
6. Event of Blood donation camp is used to initiate, cause and spread awareness in
the system.
7. AnyMedia is used to connect with the world and broadcasts about the latest news
related to the camp.
8. All the data collected by AnyMedia is stored in AnyLog. AnyLog can be opened,
removed, searched in order to check for the history of the blood donation camp.
9. Organizations in the donation camp accepts money from the donor. In turn
organizations provide receipt to donors for confirmation of the donation.
10. The entire information of the camp is gathered and stored in AnyLog. The process
of the camp to donate blood is broadcasted
11. Donors visits organization to give the money which is useful to poor.

Related Patterns and Measurability

During our research, we have not come into any available or known traditional model
for robot guard or guarding, therefore we will use the traditional model we created
during an earlier phase.
A quick look into the following two figures, it shows a stark difference on how the
different classes are connected. The SSM is in a sense a higher view of the overall
problem, and it can be adapted to any specific scenario just with the addition of any
specific Industrial Objects. .

Fig 2. Traditional Model for Robot Guard

1.
2.
3.
4.
5.
6.

Some essentials by which we can compare both patterns according to the Transition to
Object-Oriented Software Development book are*1+:
Simple: measure the technique complexity in terms of number of design rules,
notational aspects, constraints, and number of process steps.
Complete(Most likely to be correct): uniformity of of components names, absence of
incomplete sections, and consistency.
Stable to technological change: how likely it would be for the model to retain its
functionality in the future.
Testable: the model must be specific, unambiguous, and quantitative wherever possible
for it to be able to be validate the model against the requirements.
Easy to understand: how easy is it for other to understand the model
Visual or graphical: whether the picture allows of easy visualization of the model.
We will divide 100 points among the 6 essentials and give score to each model.
# Essential

Traditional Model

T
w

SSM

S
w

1 Simple

20

The design process is not

easy, many
implementation details are
needed for the design
process

The design process

allows for easy
extension of the
architecture to any
implementation detail

18

2 Complete

15

The traditional model is

designed for one specific
case, robot guard. It does
not account for other use
cases

The SSM allows for

easy extension to
other instances with
different
implementations
without problem. The
essentials are already
covered.

15

3 Stable

20

This model is estimated to

be useable for about 1015 years. technologies
used on this model might
be outdated or replaced in
the future.

This architecture does

not depend on
implementation
details. It is stable as
long as the concept of
protection are still the
same.

20

4 Testable

10

The traditional model can

8
be tested against the robot
guard requirements.

The SSM can be

tested against the
robot guard
requirements and

10

many others.
5 Easy to
Understand

15

This model might not be

easy to understand.

This model is self

explanatory.

6 Visual

20

The traditional model

shows the main
components needed for a
robot guard, but fails to
show the protection
mechanism.

The SSM model shows 18

visually the whole
scenario. It accounts
for definition of danger
and the parties
involved.

Total

100

32

13

94

From the score, we get that the SSM has better score than the traditional model in
regards to the six essentials. SM 94% compared to the 32% of traditional model. The
SM got better ratings on all 6 categories.
Measurability:
The following section shows both the quantitative and qualitative comparisons in
traditional and stability model
# Quantitative

TM

SM

M = 28 - 16 +2(1)
M = 14
The result means that the
cyclomatic complexity of
the traditional model is
14.
The impact of this score is
that it shows a relatively
complex diagram.
The implication of a high
cyclomatic complexity is
that highly coupled
classes are present, and
further work should be
done to simplify the
diagram.

M = 23 -16 + 2(1)
M=9
The result means that the
cyclomatic complexity of the
stable model is 9.
The impact of this score is
that the model seems to be
well balanced. This means
our architecture is relatively
not complex.
A score less than 10 is
considered to be good,
anything higher than 10
would need refactoring.

Cyclomatic Complexity
calculates the number of
linearly independent
paths by which the
model/source code can
go through. The
Cyclomatic Complexity is
defined as follow:
M = E - N +2P
M = Cyclomatic
Complexity
E = the number of edges
N = the number of nodes
P = the number of
connected components
Following McCabes
application of limiting

the complexity, a
cyclomatic complexity
larger than 10 needs
refactoring or
redesign[3]
# Qualitative

TM

SM

2 M=
100/((D+1)*(B+1)*(T+1))
Where:
D = : n = number of
dangling classes
B = (G-L) : G = greatest
class connectivity, L =
least class connectivity
T = (4A/S)^2 : S =
number of system
classes, A = number of
actor/role classes
M = quality design
score. The higher the
number the better

D=1
B = (7 - 1) = 6
T = [ 4(2)/14 ] ^2 = 0.327
M=
100/[(1+1)*(6+1)*(0.327+1)]
= 5.38
The score is based on three
main parts, dangling, class
types ratio, and difference
between largest and
smallest # of connections to
a class in the design. These
3 factors are used as divisor
to get a score where the
greater the number the
better it is.
The implication of this score
is that the design might be
unbalanced.
The impact of this score on
the quantitative score is that
the design needs major restructuring due to imbalance
and high complexity Both
quantitative and qualitative
supports the conclusion that
the design could do with
some improvements.

D=0
B = (5 - 2) = 3
T = [ 4(2)/14 ] ^ 2 = 0.327
M
= 100/[(0+1)*(3+1)*(0.327+1)]
= 18.8
The score is based on three
main parts, dangling, class
types ratio, and difference
between largest and smallest #
of connections to a class in the
design. These 3 factors are
used as divisor to get a score
where the greater the number
the better it is.
The implication of this score on
the architecture is that it is
relatively balanced. Some
minor balances can be made to
improve the balance.
The impact of this score on the
quantitative score is that it
validates the finding of the
quantitative score as being well
balanced.

Adapted from another

student work. [4]

The qualitative and the quantitative scores support each other in that the traditional
pattern is measurably more complex than the SSM pattern. The impact of this result
means that the Traditional model is not as well balanced as the Stable model. The
traditional model can be balanced more. The traditional model seems to be more
coupled than the SM which could impact on how reuseable it could be. Strong coupling
can affect the stability of the entire system if a strongly coupled module needs some
changes that would break some of the functionality.

Known Usages

Some scenarios that could use our SSM model would be:
1.
2.
3.
4.

Marriage: contract signed in marriage.

Film Making: script disclosure agreement.
Corporate: contract between employer and employee.
Identity theft protection: a system that monitors abnormal behaviors or patterns and
activate necessary protections to minimize damage.
Conclusions:
It is observed that the exercise of software stability model during the software design
may lead to more stable, reusable and scalable modelling compared to the traditional
object oriented approach. With the stable modelling applicability on two different
scenarios having far problem domain, it is very evident, how the EBTs and BOs can
remain stable over changing IOs. This is possible because the problem domains have the
same goals and similar mechanisms. Moreover, from qualitative and quantitative
measures, it is more apparent that stability model surpasses the traditional model. In
conclusion, stability modelling is more effective than traditional modelling when
compared in terms of engineering processes, cost effectiveness, time and maintenance
required.
Updated Problem Statement:

References
[1] M.E. Fayad and M. Laitinen "Transition to Object-Oriented Software
Development." New York: John Wiley & Sons, August 1998, ISBN# 0-471-24529-1
[2] Fayad, M. (n.d.). Modeling Adequacies. Retrieved November 14, 2014, from
http://www.engr.sjsu.edu/fayad/current.courses/cmpe202fall2014/docs/Projects/IndividualProjects/02P-CmpE202-IA-1 2-adeguecies-InMind.pdf
[3] McCabe, Thomas J.. "Measuring and Limiting Program Complexity." Structured
testing. Silver Spring, Md.: IEEE Computer Society Press ;, 1983. 26. Print.