Professional Documents
Culture Documents
Individual#2 Final
Individual#2 Final
CMPE 202-01
INDIVIDUAL ASSIGNMENT #2
PATTERN: OBLIGATION
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.
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:
Collaboration
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
Client
Server
1. Obligation
2. AnyRule
3. AnyConsequence
1.
2.
3.
4.
5.
participate()
playRole()
join()
leave()
follow()
AnyRule (AnyRule)<P-BO>
Responsibility
Collaboration
Client
Server
1. AnyParty
2. AnyActor
3. AnyIdea
1. defineRequirements(
)
2. modifyCriteria()
3. validateRules()
AnyClause (AnyClause)<P-BO>
Responsibility
Collaboration
Client
1.
2.
3.
4.
Server
AnyParty
AnyActor
AnyCriteria
AnyCause
1. ideaForCause()
2. proposeIdea()
3. reviewIdea()
AnyImpact (AnyImpact)<P-BO>
Responsibility
Collaboration
Server
1. analysis()
2. AnyLog
3. AnyInspiration
2. comparison()
3. finalOutput()
AnyConsequence (AnyConsequence)<P-BO>
Responsibility
Collaboration
Client
4.
5.
6.
7.
Server
AnyCause
AnyEvent
AnyEntity
AnyOutcome
1. obtainOutcome()
2. relatesToCause()
3. inspiresFromEvent()
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()
AnyAgreement (AnyAgreement)<P-BO>
Responsibility
Collaboration
Client
1.
2.
3.
4.
Server
Motivation
AnyIdea
AnyInspiration
AnyType
1. outcome()
2. motivate()
3. awareness()
AnyType (AnyType)<P-BO>
Responsibility
Collaboration
To classify components.
Client
1. AnyCause
2. AnyEntity
Server
1. change()
2. operateOn()
3. AnyEvent
3. nameAttribute()
AnyMedia (AnyMedia)<P-BO>
Responsibility
Collaboration
Server
1.
2.
3.
4.
5.
connect()
broadcast()
capture()
store()
display()
AnyLog (AnyLog)<P-BO>
Responsibility
Collaboration
Server
1.
2.
3.
4.
5.
6.
7.
nameLog()
replaceLog()
removeLog()
searchLog()
openLog()
closeLog()
editLog()
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
Use Case 1
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()
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:
Use Case #
Use Case 2
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()
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.
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
18
2 Complete
15
15
3 Stable
20
20
4 Testable
10
10
many others.
5 Easy to
Understand
15
6 Visual
20
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.
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.
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.