individual#2 final

8/10/2019 Individual#2 Final

1/22

SOFTWARE ENGINEERING (FALL 2014)

CMPE 202-01

INDIVIDUAL ASSIGNMENT #2

PATTERN: OBLIGATION

Submitted to: Dr. M. E. Fayad

Submitted on:

Submitted by:

Vijeta Karani ([email protected])

Student ID: 009979827
mailto:[email protected]:[email protected]:[email protected]:[email protected]


2/22

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 agreementbetween 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


3/22

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


4/22

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 orjust 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/22

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 beable to define any support.

5. AnyAgreement should have one or more type to distinguish betweendifferent 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 toachieve 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 ofAnyAgreement.

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:


6/22

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)

Responsibility Collaboration

To set a sense of duty in the system Client Server

1. AnyAgreement

2. AnyParty3. AnyActor

1. obliges()

2. bringsSystematicBeaviour()


7/22

3. leadsToImpact()

Attributes: name, type, impact, description

AnyParty/AnyActor (AnyParty/AnyActor)


To abide by the agreement. Client Server

1. Obligation2. AnyRule3. AnyConsequence

1. participate()2. playRole()3. join()4. leave()

5. follow()

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

AnyRule (AnyRule)


To define set of rules. Client Server

1. AnyParty2. AnyActor3. AnyIdea

1. defineRequirements)

2. modifyCriteria()3. validateRules()

Attributes: context, id, criteriaName, description, components

AnyClause (AnyClause)


To provide assistance for any cause. Client Server

1. AnyParty2. AnyActor3. AnyCriteria4. AnyCause

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

Attributes: name, theme, description, context, id

AnyImpact (AnyImpact)


To calculate the consequence or result of

cause

Client Server

1. AnyMedia 1. analysis()


8/22

2. AnyLog3. AnyInspiration

2. comparison()3. finalOutput()

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

AnyConsequence (AnyConsequence)


To get inspiration for a good cause. Client Server

4. AnyCause5. AnyEvent6. AnyEntity7. AnyOutcome

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


AnyEvent/AnyEntity (AnyEvent/AnyEntity)


To provide Motivation Client Server

1. AnyType2. AnyMedia3. AnyInspiration

1. initiateChange()2. causeMotivation()

3. spreadNews()

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

AnyAgreement (AnyAgreement)


To help and support cause Client Server

1. Motivation2. AnyIdea3. AnyInspiration4. AnyType

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


AnyType (AnyType)


To classify components. Client Server

1. AnyCause2. AnyEntity

1. change()2. operateOn()


9/22


10/22

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:

Obligation AnyAgreemen

t AnyImpact

AnyConseque

nce

AnyActor

AnyParty

AnyRule AnyClause

AnyEntity

AnyEvent

AnyType AnyLog AnyMedia

has

for

has results in

implements

stores on

mentioned on

mentioned on

mentioned on

triggers

is of

is of

1* 1*

1*

1*

1*

1*

1*

1*

1*

1*

1*

Contract

Actors

Producer

ScriptDisclos

ure Profit

Success Loss

DatabaseBoxOfficeRe

cordsPromotion

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


11/22

Obligation EBT 1. name2. type

3. outcome4. description

1. obliges()2. bringsSystematicBeh

aviour()

AnyParty BO 1. id2. partyName3. type4. role5. member

6. activity7. partiesInvolve

d

8. purpose


5. follow()

AnyActor BO 1. id

2. actorName3. type4. role5. member6. activity7. partiesInvolve

d

8. purpose

1. participate()

2. playRole()3. join()4. leave()

5. follow()

AnyClause BO 1. context

2. id3. criteriaName4. description5. components

1. defineRequirements()

2. modifyCriteria()3. validateRules()

AnyRule BO 1. name2. theme3. description

4. context5. id


AnyImpact BO 1. id2. name

3. result

4. description

5. context

6. reason

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


12/22

AnyConsequence BO 1. id

2. name

3. description

4. context

5. reason

1. reasonForCause()2. measureImpact()

3. analyzeChange()

AnyEvent BO 1. id

2. eventName

3. eventType

4. status

5. position

6. states

7. type

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

AnyType BO 1. id2. typeName

3. properties4. methodList5. attributeList

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

AnyMedia BO 1. id2. mediaName3. mediaType4. securityLevel5. status6. sector

1. connect()2. broadcast()3. capture()4. store()5. display()

AnyLog BO 1. id

2. logName3. logType

4. logReferences

5. logCriteria

6. logSize

7. logLocation

8. logPath

1. nameLog()

2. replaceLog()3. removeLog()4. searchLog()5. openLog()6. closeLog()7. editLog()

AnyAgreement BO 1. id2. name

3. type

1. outcome()2. motivate()

3. awareness()Actor IO 1. name2. id

3. degree

4. address

5. zipcode

6. number

1. chacks ()2. acts ()3. takesCheque()


13/22

Contract IO 1. name2. details

3. description

4. number

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

Producer IO 1. name

2. id3. degree

4. address

5. zipcode

6. number

1. produces()

2. givesMoney()

ScriptDisclosure IO 1. name2. type

1. discloseScript()

Profit IO 1. name2. id

3. number

1. divide()

Loss IO 1. name2. type

1. count()

Promotion IO 1. name2. id

3. type

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 ofdonor to donate blood.

3. In the process of donating blood, there are some rules and criteria that needs tobe 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 anyAnyParty or AnyActor.

5. AnyOutcome of this camp is the result of good cause. Analysis of the response gotfrom 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 inthe system.

7. AnyMedia is used to connect with the world and broadcasts about the latest newsrelated 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


14/22

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 processof 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


15/22

Use Case # Use Case 2

Use Case Title Marriage

Actor Roles

AnyParty Couple, Priest

Classes Type Attributes Operations

Obligation EBT 5. name6. type7. outcome8. description

3. obliges()bringsSystematicBehaviour()

AnyParty BO 9. id10.partyName

11.type12.role13.member14.activity15.partiesInvolve

d

16.purpose


1. follow()

AnyActor BO 9. id10.actorName11.type

12.role13.member

14.activity15.partiesInvolve

d

16.purpose


1. follow()

AnyClause BO 6. context7. id8. criteriaName

9. description10.components

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

AnyRule BO 6. name7. theme8. description9. context10.id



16/22

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. id9. eventName

10.eventType

11.status

12.position

13.states

14.type

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

AnyType BO 6. id7. typeName8. properties

9. methodList10. attributeList

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

AnyMedia BO 7. id8. mediaName9. mediaType10. securityLevel11. status12. sector

6. connect()7. broadcast()8. capture()9. store()1. display()

AnyLog BO 9. id

10.logName

11.logType

12.logReferences

13.logCriteria

14.logSize

15.logLocation

16.logPath

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


17/22

AnyAgreement BO 4. id5. name

type

4. outcome()5. motivate()

1. awareness()Couple IO 7. name

8. id

9. degree

10. address

11. zipcode

12. number

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

Contract IO 5. name6. details

7. description

8. number

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

Priest IO 7. name8. id

9. degree10. address

11. zipcode

12. number

3. produces()4. givesMoney()

1.

Violence IO 3. nametype

1. discloseScript()

Chores IO 4. name5. id

6. number

divide()

Relation IO 3. name4. type

7.

count()

Reception IO 4. name5. id

8. type

3. act()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 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 tobe 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


18/22


19/22

Fig 2. Traditional Model for Robot Guard

Some essentials by which we can compare both patterns according to the Transition to

Object-Oriented Software Development book are*1+:

1. Simple: measure the technique complexity in terms of number of design rules,

notational aspects, constraints, and number of process steps.2. Complete(Most likely to be correct): uniformity of of components names, absence of

incomplete sections, and consistency.

3. Stable to technological change: how likely it would be for the model to retain its

functionality in the future.

4. Testable: the model must be specific, unambiguous, and quantitative wherever possible

for it to be able to be validate the model against the requirements.

5. Easy to understand: how easy is it for other to understand the model

6. 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 w Traditional Model T

w

SSM S

w

1 Simple 20 The design process is noteasy, manyimplementation details areneeded for the designprocess

8 The design processallows for easyextension of thearchitecture to anyimplementation detail

18

2 Complete 15 The traditional model is

designed for one specificcase, robot guard. It doesnot account for other usecases

5 The SSM allows for

easy extension toother instances withdifferentimplementationswithout problem. Theessentials are alreadycovered.

15

3 Stable 20 This model is estimated tobe useable for about 10-15 years. technologiesused on this model mightbe outdated or replaced inthe future.

0 This architecture doesnot depend onimplementationdetails. It is stable aslong as the concept ofprotection are still thesame.

20

4 Testable 10 The traditional model canbe tested against the robotguard requirements.

8 The SSM can betested against therobot guardrequirements and

10


20/22

many others.

5 Easy toUnderstand

15 This model might not beeasy to understand.

5 This model is selfexplanatory.

13

6

Visual

20

The traditional modelshows the maincomponents needed for arobot guard, but fails toshow the protectionmechanism.

6

The SSM model showsvisually the wholescenario. It accountsfor definition of dangerand the partiesinvolved.

18

Total 100 32 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

1 Cyclomatic Complexity

calculates the number of

linearly independentpaths 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

M = 28 - 16 +2(1)

M = 14

The result means that thecyclomatic 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, andfurther work should be

done to simplify the

diagram.

M = 23 -16 + 2(1)

M = 9

The result means that thecyclomatic 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 10would need refactoring.


21/22

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

Adapted from another

student work. [4]

D = 1B = (7 - 1) = 6T = [ 4(2)/14 ] ^2 = 0.327 M =100/[(1+1)*(6+1)*(0.327+1)]= 5.38The score is based on threemain parts, dangling, classtypes ratio, and differencebetween largest and

smallest # of connections toa class in the design. These3 factors are used as divisorto get a score where thegreater the number thebetter it is.The implication of this scoreis that the design might beunbalanced.The impact of this score onthe quantitative score is thatthe design needs major re-structuring due to imbalance

and high complexity Bothquantitative and qualitativesupports the conclusion thatthe design could do withsome improvements.

D = 0B = (5 - 2) = 3T = [ 4(2)/14 ] ^ 2 = 0.327 M= 100/[(0+1)*(3+1)*(0.327+1)]= 18.8The score is based on threemain parts, dangling, classtypes ratio, and differencebetween largest and smallest #

of connections to a class in thedesign. These 3 factors areused as divisor to get a scorewhere the greater the numberthe better it is.The implication of this score onthe architecture is that it isrelatively balanced. Someminor balances can be made toimprove the balance.The impact of this score on thequantitative score is that itvalidates the finding of the

quantitative score as being wellbalanced.

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 couplingcan affect the stability of the entire system if a strongly coupled module needs some

changes that would break some of the functionality.

Known Usages


22/22

Some scenarios that could use our SSM model would be:

1. Marriage: contract signed in marriage.

2. Film Making: script disclosure agreement.

3. Corporate: contract between employer and employee.

4. Identity theft protection: a system that monitors abnormal behaviors or patterns andactivate 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/cmpe202-

fall2014/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.

individual#2 final

Documents