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]8/10/2019 Individual#2 Final
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
8/10/2019 Individual#2 Final
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.
8/10/2019 Individual#2 Final
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.
8/10/2019 Individual#2 Final
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:
8/10/2019 Individual#2 Final
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()
8/10/2019 Individual#2 Final
7/22
3. leadsToImpact()
Attributes: name, type, impact, description
AnyParty/AnyActor (AnyParty/AnyActor)
Responsibility Collaboration
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)
Responsibility Collaboration
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)
Responsibility Collaboration
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)
Responsibility Collaboration
To calculate the consequence or result of
cause
Client Server
1. AnyMedia 1. analysis()
8/10/2019 Individual#2 Final
8/22
2. AnyLog3. AnyInspiration
2. comparison()3. finalOutput()
Attributes: id, name, result, description, context, reason
AnyConsequence (AnyConsequence)
Responsibility Collaboration
To get inspiration for a good cause. Client Server
4. AnyCause5. AnyEvent6. AnyEntity7. AnyOutcome
1. obtainOutcome()2. relatesToCause()3. inspiresFromEvent(
Attributes: id, name, result, description, context, reason
AnyEvent/AnyEntity (AnyEvent/AnyEntity)
Responsibility Collaboration
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)
Responsibility Collaboration
To help and support cause Client Server
1. Motivation2. AnyIdea3. AnyInspiration4. AnyType
1. outcome()2. motivate()3. awareness()
Attributes: id, name, result, description, context, reason
AnyType (AnyType)
Responsibility Collaboration
To classify components. Client Server
1. AnyCause2. AnyEntity
1. change()2. operateOn()
8/10/2019 Individual#2 Final
9/22
8/10/2019 Individual#2 Final
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
8/10/2019 Individual#2 Final
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
1. participate()2. playRole()3. join()4. leave()
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
1. ideaForCause()2. proposeIdea()3. reviewIdea()
AnyImpact BO 1. id2. name
3. result
4. description
5. context
6. reason
1. analysis()2. comparison()3. finalOutput()
8/10/2019 Individual#2 Final
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()
8/10/2019 Individual#2 Final
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
8/10/2019 Individual#2 Final
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
8/10/2019 Individual#2 Final
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
6. participate()7. playRole()8. join()9. leave()
1. follow()
AnyActor BO 9. id10.actorName11.type
12.role13.member
14.activity15.partiesInvolve
d
16.purpose
6. participate()7. playRole()8. join()9. leave()
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
4. ideaForCause()5. proposeIdea()1. reviewIdea()
8/10/2019 Individual#2 Final
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()
8/10/2019 Individual#2 Final
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
8/10/2019 Individual#2 Final
18/22
8/10/2019 Individual#2 Final
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
8/10/2019 Individual#2 Final
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.
8/10/2019 Individual#2 Final
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
8/10/2019 Individual#2 Final
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.