Embed Size (px)
Citation preview
Towards Automatic Problem Decomposition: AnOntology-based Approach∗
Zhi Jin∗
Academy of Mathematics and System ScienceBeijing, 100080, China
Lin LiuSchool of Software, Tsinghua University
Beijing, 100080, China
ABSTRACTIn this paper, we propose a conceptual description schemabased on the Problem Frames (PF) approach, which treatsenvironment as a first-class concept. Requirements are de-fined as problem descriptions in terms of the environmentmodel. Thus, knowledge about the environment can be usedto facilitate the derivation of software specifications from re-quirements. Heuristic rules that help structuring softwareproblems are given. Major idea of the proposed approach isillustrated with a simple real world example.
Categories and Subject DescriptorsD.2.1 [Requirements/Specifications]: Elicitation meth-ods, Languages, Methodologies, Tools
General TermsDesign, Languages, Theory
KeywordsProblem Frames, Requirements Engineering, Problem De-composition, Environment Ontology
1. INTRODUCTIONIn the field of requirements engineering, the idea of taking
the environment into account can be traced back to Parnaset al’s Four-Variable Model [1], which uses four sets of en-vironment related variables to describe system behaviors.Jackson and Zave’s well-known work proposed a more gen-eral framework [2, 3, 4], which explicitly distinguishes three
∗Partly supported by the Natural Science Foundation ofChina (No.60233010, No.60496324 and No.60503030), theNational Key Research and Development Program of China(Grant No. 2002CB312004), the Knowledge Innovation Pro-gram of the Chinese Academy of Sciences, MADIS of theChinese Academy of Sciences.∗Dr. Jin insisted her name be first.
Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.IWAAPF’06, May 23, 2006, Shanghai, China.Copyright 2006 ACM 1-59593-085-X/06/0005 ...$5.00.
sets of statements: K (the domain knowledge), R (the re-quirements) and S (the specification). Furthermore, in [5],the authors discussed in detail this relationship and formal-ized this relationship as K,S � R, to claim that a proofcan be given that an implementation of S , introduced intoa problem domain satisfying K, will guarantee satisfactionof the requirements R.
PF approach [6] gives a systematical structure to the envi-ronment (E) which the problems are situated in and describewhat is there and what effects (R) the desired software (S)located there have to achieve. Several work [7, 8] have beendone for extending some aspects of this approach. PF ap-proach allows people with knowledge in specific problem do-main to drive the RE process and to derive specificationsfrom original requirements statements.
However, at present, this derivation is an empirical, te-dious, and subjective process, which heavily depends on theanalysts’ experiences. The main arguments in PF approachis that there exist some basic problem frames and a realworld problem can be decomposed to be finally fitted tothem. But we could not assume that any original real worldproblem description can happen to be fitted to a particu-lar basic problem frame or a combination of basic problemframes. For many real world problems, in order to let thembe fitted to these basic problem frames, some intermediate ordesigned or virtual domains have to be introduced in. Thatmight be a difficult task for those inexperienced analysts.
This paper argues that explicitly modelling and represent-ing the environments can help the automated execution ofPF approach. Based on these knowledge, some heuristicscould be defined for conducting the automated problem de-composition. This paper is organized as follows. Section 2presents a small ontology for modelling the environments.Section 3 shows how to represent the software problem basedon the ontology. Section 4 discusses the principle for prob-lem decomposition. Section 5 gives several heuristics forproblem refinement and decomposition. Section 6 gives ameaningful example for illustrating the approach proposedin this paper. Finally, Section 7 briefly comments some re-lated work and indicates our future work.
2. ENVIRONMENT ONTOLOGYThe main constituents of our environment ontology are
the categories of environment concepts, the associations be-tween environment concepts, the types of the interactionsbetween software and its environment entities and the prop-erties of environment entities.
41
2.1 Top-Level ConceptsAfter examining many software applications in different
application domains as well as summarizing the results inmany books on system analysis and modelling, e.g. [2, 6,9], we extract a set of concept categories. Table 1 gives theconcept hierarchy and summarizes the meanings of theseconcepts.
Table 1: Categories of Environment ConceptsEnvironment Entity entities which a system will
interact withAtomic Entity an individual entityCausal Entity an individual entity whose
properties include predictablecausal relationships among itsshared phenomena
Autonomous Entity an individual entity whichusually consists of people
Symbolic Entity an individual entity which is aphysical representation of data
Aggregate Entity a collective entityEvent individual taking place at some
particular point of timePhysical Event event initiated by an
environment entityState Change Event event due to a state change of a
causal entitySignal Event event due to a command etc.Call/Return Event event due to a value query.
Time Event a time point, a time period, etc.State Machine a direct graph for characterizing
the dynamic property of a causalentity
State circumstances of an entity atany given time
Transition a state change in a state machineAttribute a named variable for characterizing
a static property of an entityValue intangible individual entity that
exists outside time and space,and is not subject to change
Interaction observable shared phenomenonbetween a system and one of itsenvironment entity
Event Interaction they interact with an eventState Interaction they interact with a stateValue Interaction they interact with a value
2.2 AssociationsBesides classifying things, an ontology provides the asso-
ciations between the ontological categories. These associa-tions form a general conceptualization of the related domain.Some of the associations between environment-related con-cepts are listed in Table 2.
2.3 Categories of InteractionInteractions are supposed to be observable and their con-
tents might be different. We argue that distinguishing thecontents of interactions may bring back the richer semanticsof the interactions. By summarizing the known interactionsbetween the software and its environment entities. Eightdifferent notations have been adapted to depict different in-teraction contents. These notations are listed in Table 3, inwhich ee means an environment entity, ε is an anonymousenvironment entity, event means an event, state means astate and attr .val means the value of an attribute.
Table 2: Formation of AssociationsAssociation formationhas−static−prop AtomicEntity→Attribute �→Valuehas−dynamic−prop CausalEntity→StateMachinehas−part AggerateEntity→EnvironmentEntitycan−cause AutonomousEntity→PhysicalEvent
CausalEntity→PhysicalEventTransition→PhysicalEvent
has−state StateMachine→Statehas−in−event StateMachine→Eventhas−out−event StateMachine→PhysicalEventhas−transition StateMachine→Transitionsource−from Transition→Statesink−to Transition→Statebe−triggered−by Transition→Event
Table 3: The Meaning of Interactionsnotation meaningee ↑ event ee causes event to happenee ↓ event ee accepts event that caused by othersε ↑ event ε causes event to happenee : state ee is in stateee � attr .val ee sends out attr.valee � attr .val ee receives attr.valee � attr .val ee edits and sends out attr.valee � attr .val ee sends multiply out attr.valsee � attr .val ee receives multiply attr.vals
2.4 Properties between Environment EntitiesThe static part of environment entities have some prop-
erties. An entity is multiple if it is allowed to have morethan one instances, changeable if it has changeable attributevalue, and dividable if it contains sub-structures. There arealso some properties referring to multiple entities or phe-nomena which are listed in Table 4.
Table 4: Meanings of Environment PropertyProperty Meaning1to1Map(Env,Env) an one-to-one mapping exists
between two environment entitiespaDepend(Env,Env) an environment entity partly
depends on anotherpaDepend(Phe,Phe) a phenomenon partly depends on
another oneidentical(Env,Env) two environment entities are
identicalsubEnv(Env,Env) the first environment entity is a
part of the second onemodel(Env,Env) the first environment entity is a
model of the second oneinstance(Env,Env) the first environment entity is an
instance of the second onemodeOf(Env,Env) the first environment entity is an
execution mode of the second one1
3. PROBLEM REPRESENTATION
3.1 Grounding the Environment EntitiesFor modelling the real world problems, one of the most
important steps is to ground formal representations onto re-
1Different execution modes of an environment entity have toobey some stipulations of consistency and precedence. Thatis out of the scope of this paper.
42
ality, which is referred to as ‘designation’ [3, 4, 6]. However,the designations in many available methods are rather ran-dom and sometimes lack of shared understanding. We haveshown in our previous work [10] that a shared understand-ing is extremely important and efficient in requirements en-gineering. With the environment ontology, the groundingprocess for making designations can be guided and will beeasier and immune from ambiguity. In fact, the concepts inthe environment ontology can serve as the classes of thosein the reality. The designation process could be: (1)for eachreal environment concept, choose an appropriate conceptcategory; (2)instantiate this pre-defined concept category byfilling its association slots; (3)perform cross reference check-ing for guaranteeing the term declaration completeness. Theterm declaration process and the consistency and complete-ness checking algorithms could be found in [11, 12].
For illustrating this process, we use Chemical ReactorController, adapted from [8], as an example. From theproblem statements as well as the problem diagram, we caneasily build the models of its environment entities. Table 5lists the environment entities and Table 6 shows the dynamicmodels of those causal entities.
Table 5: Environment Entities of ControllerCatalyst: CausalEntitybe−featured−as:{StateReactive}has−dynamic−property:{CatalystStateMachine}
Operator: AutonomousEntitybe−featured−as:{EventActive}can−issue:{Open,Close}
Alarm: CausalEntitybe−featured−as:{StateReactive}has−dynamic−property:{AlarmStateMachine}
CoolingSystem: CausalEntitybe−feature−as:{StateReactive}has−static−property:{waterLevel �→ RealInterval}has−dynamic−property:{CoolingSystemStateMachine}
GearBox: CausalEntitybe−featured−as: {EventActive, StoppableStateActive}has−static−property: {oilLevel �→ RealInterval}has−dynamic−property: {GearBoxStateMachine}
3.2 Extending the Problem RepresentationInstead of representing only the interactions between the
desired software and its environment entities, we also ex-plicitly represent the relationships between these interac-tions and group all of the information related to the de-sired software into four parts. Concretely, a quadruplet< Env , Int ,Sce, Con > has been designed for representingthe desired software. In which, Env is the set of environ-ment entities which the desired software will interact with ordepend on. Int is the set of observable interactions betweenthe desired software and its environment entities. Sce con-tains the scenario clauses each of which is formed as ‘causeside→effect side’ and indicate the direct causal order of the‘cause side’ interactions and ‘effect side’ interactions. Conis the set of property clauses. Each property clause is anassertion on a property of an environment entity or a rela-tionship among two environment entities. We call such akind of representation the external manifestation [13] of the
Table 6: Dynamic Models of Environment EntitiesCatalystStateMachine: StateMachinehas−state:{open,closed}has−in−event: {OpenCatalyst,CloseCatalyst}has−transition:{
open⇓CloseCatalyst→closed,closed⇓OpenCatalyst→openopen⇓OpenCatalyst→openclosed⇓CloseCatalyst→closed}
CoolingSystemStateMachine: StateMachinehas−state:{rising,falling}has−in−event:{IncreaseWater,DecreaseWater}has−transition: {
rising⇓IncreaseWater→rising,rising⇓DecreaseWater→fallingfalling⇓DecreaseWater→fallingfalling⇓IncreaseWater→rising}
AlarmStateMachine: StateMachinehas−state:{ringing,dumb}has−in−event:{RingBell}has−transition{dumb⇓RingBell→ringing,
ringing⇓1min→dumb}GearBoxStateMachine: StateMachinehas−state: {value(oilLevel)> δ, value(oilLevel)≤ δ}has−out−event:{RequestService}has−transition:{value(oilLevel)> δ →
value(oilLevel)≤ δ⇑RequestService}
desired software.We have to give more words to scenario clauses. In a
scenario clause, each cause side and effect side could be anatomic interaction or a composite interaction via ∨ and ∧.An atomic interaction could be an event interaction, a stateinteraction or a value interaction. It could also be a valueexpression constructed from value interaction and/or con-stants (such as 0) to which functions (such as +) and pred-icates (such as >) are applied. For example,
GearBox � oilLevel .value(oilLevel) < δ
Back to the above example, the external manifestation ofOperation Machine can be figured out as shown in Table 7.
Table 7: External Manifestation of Operation Ma-chineOperationMachine
Environments:{Catalyst, Operator, CoolingSystem, Alarm, Gearbox}
Interactions:{Operator↑{Open,Close}Catalyst↓{OpenCatalyst, CloseCatalyst}CoolingSystem↓{IncreaseWater, DecreaseWater}Alarm↓{RingBell}Catalyst:{open,closed}CoolingSystem:{rising,falling}Alarm:{ringing,silent}GearBox�{oilLevel.value(oilLevel)}}
Scenarios:{Operator↑open⇒Catalyst:open,Operator↑close⇒Catalyst:closed,GearBox�oilLevel.value(oilLevel)< δ ⇒Alarm:ringing}
43
4. PROBLEM DECOMPOSITION ASENVIRONMENT PARTITION
It is commonly recognized that the key to managing prob-lem size and complexity is problem decomposition, i.e. break-ing down a given large and complex problem into a numberof smaller and simpler subproblems. Different requirementsmodelling approaches have different decomposition strate-gies. Continuing our discussion on ‘Operation Machine’ withits following three scenario clauses:
Operator ↑ Open ⇒ Catalyst:open (1)
Operator ↑ Close ⇒ Catalyst:closed (2)
GearBox � oilLevel.value(oilLevel) < δ ⇒ Alarm:ringing(3)
Obviously, these clauses are not thoroughly independent.For example, clause( 1) and clause( 2) share two environ-ment entities, Operator and Catalyst. These two clausesare talking about how Operator causes the state changes ofCatalyst. We say that they are related with each other. Onthe contrary, clause( 3) is not related with any of them. Ittalks about another thing, i.e. how GearBox causes the statechange of Alarm, concerning neither Operator nor Catalyst.We say that clause( 3) is related with neither clause( 1) norclause( 2). That is to say that two scenario clauses are rele-vant when they share at least one environment entity. Withthe kind of relevance, an relevancy graph can be constructed,in which each node is a clause and each edge connecting twoclauses means that the two clauses are relevant. We call thisgraph the clause relevancy graph.
For an illustration, we can draw the clause relevancy graphof the above example as shown in Figure 1. The clauserelevant graph has two sub-graphs. This indicates the needof decomposing software problems. In other words, in termsof the clause relevant graph, two independent sub-problemscan be recognized. One responds to Operator’s commandsby issuing corresponding control signals to Catalyst. Theother monitors GearBox and issues corresponding signal toAlarm if the oil level is below a predefined value.
Operator
Catalyst Catalyst
Operator GearBox
Alarm
Figure 1: Clause Relevant Graph
This suggests that a possible process for decomposing asoftware problem is to build the clause relevancy graph, andthen each disconnected sub-graph can give the partition ofan original software problem. However, the clause relevanceoriginates from the shared environment entities of the sce-nario clauses. On the other hand, the environment entitiesinvolved in same scenario clause are also related. Thus, thepartition of the clause relevancy graph becomes the clus-tering of the environment entities. Environment entities insame cluster are related due to some scenario clauses. Oncethe set of the environment entities form clusters, the originalproblem then can be decomposed into several sub-problems.Each sub-problem interacts with one subset of the environ-ment entities and satisfies the scenario corresponding to the
environment entities. Based on these observations, we getto the following partition rule.
Partition the set of environment entities: if thereexists an equivalent relation among the set of environmententities of a software machine, the machine could be decom-posed into several sub-machines, so that these sub-machinesdon’t share any environment entities. In this case, each sub-machine corresponding to one equivalent class satisfies thescenarios on the environment entities in this equivalent class.We call this rule the environment-based partition rule.
For an illustration, we apply this rule to above mentioned“Chemical Reactor Controller” problem. Three sub-problemscan be identified by clustering the environment entities interms of the scenario clauses. That derives three sub-problemsand the external manifestations of these sub-problem ma-chines can be easily derived as shown in Table 8. Theyare a commanded behavior problem Control Catalyst, a re-quired behavior problem Regulating Cooling System2, andan information display problem Raise Alarm according tothe Problem Frame approach.
Table 8: Decomposition of ‘Control Machine’Problems Their External Manifestation
ControlCatalyst
ControlCatalystEnvironment:{Catalyst, Operator}Interactions:{Operator↑{Open,Close}
Catalyst↓{OpenCatalyst, CloseCatalyst}
Catalyst:{open,closed}}Scenarios:{
Operator↑Open⇒Catalyst:open,Operator↑Close⇒Catalyst:closed}}
CoolingSystem
ReguleteCoolingSystemEnvironment:{CoolingSystem}Interactions:{
CoolingSystem↓{IncreaseWater,DecreaseWater}
CoolingSystem:{rising,falling}}
RaiseAlarm
RaiseAlarmEnvironment:{Alarm, Gearbox}Interactions:{Alarm:{ringing,silent},
GearBox�{oilLevel.value(oilLevel)}}Scenarios:{GearBox�oilLevel.value(oilLevel)< δ
⇒Alarm:ringing}
5. PROJECTION HEURISTICSHowever, the decomposition depends on the structure of
the scenario clauses. In other words, the decomposabilityof the software problem depends on the layout of the sce-nario structure. How to make a scenario structure decom-posable becomes another key issue. We argue that intro-ducing some intermediate symbolic environment entities isthe strategy for making a software problem becoming de-composable. This strategy is indeed the problem projec-tion. This section will illustrate some heuristics for intro-ducing intermediate environment entities. Before describing
2‘Cooling System’ is not involved in any scenario. Thatindicates that information on how to regulate the flow ofthe ‘Cooling System’ might be missed. The discussion onthis issue is considered by the completeness concern whichis out of the scope of this paper.
44
these heuristics, let’s name some terms referring to the sub-structures of a scenario clause which are listed in Table 9.
Table 9: Sub-Structures of a Scenario ClauseTerms Refers Tocontroller the environment entity appears in an
event interaction in the cause side of ascenario clause
guard the environment entity appears in astate interaction in the cause side of ascenario clause
valueSender the environment entity appears in avalue interaction in the cause side of ascenario clause
controllee the environment entity appears in anevent interaction in the effect side of ascenario clause
effector the environment entity appears in astate interaction in the effect side of ascenario clause
valueReceiver the environment entity appears in avalue interaction in the effect side of ascenario clause
The following are some common used projection strategiesfor making problem more decomposable:
Projection with a shared active environment (non-interacting): There are a set of scenario clauses, whichare relevant just due to a shared environment entity ee asa controller. If the set of the rest environment entities ispartitionable and forms n independent entity clusters, maken copies of ee and let each copy instantiate ee in only onecluster. That makes the clusters unrelated.
Projection with a shared passive environment: Thereare a set of scenario clauses, which are relevant just due to ashared environment entity ee as a value receiver. If the setof the rest environment entities is partitionable and forms nindependent entity clusters, and if ee is an aggregative pas-sive entity and each sub-structure is controlled by exact oneentity cluster, divide ee into n sub-entities corresponding tothe sub-structures and let them instantiate ee in the cor-responding cluster. That makes the clusters unrelated. Wecall this heuristic rule the non-interacting value receiverprojection rule.
Projection with a shared non-passive environment:There are a set of scenario clauses, which are relevant justdue to a shared environment entity ee as a controllee. Ifthe set of the rest environment entities is partitionable andforms n independent entity clusters, make n copies of eeand let each copy instantiate ee in only one cluster. In thiscase ee has n execution modes. As these execution modesmust certainly interact, some consistency and precedenceconditions should be further considered at the same time3.
Projection by introducing a symbolic environment(the producer/consumer pattern): A typical situationwhich can use this heuristic is when the input values arechangeable and editable. For this situation, an environmententity edits an attribute value or several attribute values,which may be used by another environment entity. Just likeone producer produces the value(s) that will be consumed byconsumer(s). When the value changes, a model environmententity is introduced in for separating the changeability sothat the usage of values may not be effected. And then this
3We will leave these concerns our other papers for keepingthis paper more concentrated.
problem can be split into two subproblems: one builds themodel and the other uses it.
Projection by introducing a symbolic environment(the database pattern): A typical situation for this heuris-tic is that one environment entity produce continuously orperiodically many values of the same attribute and one otherenvironment entity will obtain a function value on the set ofvalues. In this case, as we know, we normally use a databaseto remember these values for later use. There are many sit-uations that a database environment entity may be useful,such as: remembering past events and states of the activeenvironments; summarizing the past; supporting inferencesabout the private phenomena of the environment entity; an-ticipating lengthy calculations, etc.
Projection by introducing a symbolic environment(the transformation pattern): This rule can be usedwhen the value sent out by the environment entity in thecause side functionally related with the value received bythe environment entity in the effect side. Normally, in thissituation, both the cause environment entity and the effectenvironment entity are symbolic environment entities.
6. CASE STUDYLet’s illustrate another small problem: Telemarketing [14].
A society needs a Telemarketing System for sell-ing lottery tickets to its Supporters. This soci-ety has different kind of lottery campaigns. Theavailable campaigns may be updated by the Cam-paign Designer. The telemarketer communicatewith the supporters via telephones. All of theseconnections are made by this system. If one sup-porter is willing to buy a special kind of lottery,the ticket placement should be recorded for pro-ducing a ticket order. The ticket orders will besent to Order Processor.
The external manifestation of the ‘Telemarketing’ systemis shown in Table 10. Figure 2 shows the order of scenariosclauses.
f a b
a b
d
a cf
e
(a)Adding New Supporter
(b)Updating exisiting Supporter
(c)Adding New Campaign
(d)Getting Ticket Order
d
(1)
(6)
(5)(4)
(3)
(2)
(7)
(8)
Figure 2: Scenarios of Telemarketing
Four heuristics can be used for enabling the problem de-composition. They are (1) interacting controllee projec-tion rule for duplicating ‘Phone’, (2) non-interaction con-troller projection rule for duplicating ‘Telemarketer’, (3)separation rule in database pattern for introducing ‘Sup-porter Database’ and ‘Campaign Database’, and (4) sepa-ration rule in producer/comsumer pattern for duplicating
45
Table 10: External Manifestation of TelemarketingEnvironments: {Campaign Designer(CD), Supporter(S),
Phone(P), Order Processor(OP), Telemarketer(T)}Interations: {
a.Telemarketing System(TS) connects a P for gettingthrough a S
b.A S inputs or updates his/her ‘supporter details’ toTS
c.A S inputs ‘ticket placement’ to TS based on a‘campaign details’
d:CD inputs or updates a ‘campaign details’ to TSe:TS sends a ‘ticket order’ to OPf:T inputs a phone number}
Scenarios{Adding new supporter(see Figure 2(a))Updating existing supporter(see Figure 2(b))Adding new campaign(see Figure 2(c))Getting ticket order(see Figure 2(d))}
Constraints: {multiple(P), multiple(S), changeable(S),changeable(‘campaign details’),multiple(‘campaign details’),paDepend(‘ticket order’,‘campaign details’),paDepend(‘ticket order’,‘supporter details’)}
‘Supporter’, ‘Supporter Database’ and ‘Campaign Database’.The refined problem diagram as shown in Figure 3.
CampaignDetails
TicketOrder
SupporterDatabase
SupporterDetails
TicketPlacement
CampaignDetails
SupporterDetailsSupporter
Database'
SupporterDetails
CampaignDetails
PhoneNum
PhoneNum
PhoneNum
PhoneNum
PhoneNum
PhoneNumOrder
Processer
CampaignDatabase'
CampaignDatabase
CampaignDesigner
SupporterDetailsEditor
CampaignDetailsEditor
TelemarketingScheduler
Supporter'
Phone'
Telemarketer'
Telemarketer
PhoneSupporter
TelemarketingSystem
Figure 3: Decomposition of the Telemarketing Sys-tem
By using the environment-based partition rule to the re-fined problem diagram, three sub-problems: Supporter De-tails Editor, Campaign Details Editor and TelemarketingScheduler can be identified. These three sub-problems aredepicted in Table 11, Table 12, and Table 13.
7. CONCLUSIONSIn summary, from the viewpoint of environment-based ap-
proach, partition is in essence grouping the set of environ-ments into several independent parts and each environmentappears in exactly one partition. This independency implies
Table 11: Supporter Details EditorSupporter Details Editor
Environment:{Supporter, Phone,Telemarketer, SupporterDatabase}Interactions:{
Telemarketer�{Supporter.phoneNum}Phone↓{Dial(phoneNum)}Supporter�{Supporter.Details}SupporterDatabase�{Supporter.Details}}
Scenarios:{Supporter�Supporter.Details⇒
SupporterDatabase�Supporter.Details,Telemarketer�Supporter.PhoneNum⇒
Phone↓Dial(PhoneNum),Phone↓Dial(PhoneNum)⇒
Supporter�Supporter.Details}Constraints:{changeable(Supporter),
changeable(SupporterDatabase),multiple(Supporter)}
Table 12: Campaign Details EditorCampaign Details Editor
Environment:{CompaignDesigner,CampaignDatabase}
Interactions:{CompaignDesigner�{CampaignDetails}CampaignDatabase�{CampaignDetails}}
Scenarios:{CompaignDesigner�Campaign.Details⇒
CampaignDatabase�Campaign.Details}Constraints:{changeable(CompaignDesigner),
changeable(CampaignDatabase),multiple(CompaignDesigner)}
that no relation of interest exists between any two environ-ments of different parts and no requirements constraint ex-ists for any two environments of different parts. Relatingto the problem, partition means that the problem can bedivided into several un-interacting sub-problems.
In contrast, projection, as another way to logically de-compose system viewpoints, is treated differently comparingto conventional modelling approaches [15, 7]. In these ap-proaches, this is due to the absence of explicit modellingof “environment”, such that the only way to differentiatethe switch of context is to use concepts such as viewpoints,or perspectives. we treat projection by introducing someheuristics to make the orthogonal and coherent problem sep-arated into independent parts so that the partition rule canbe used to do the further decomposition. In the proposed ap-proach, projection includes following steps, first, we decom-pose a holistic problem into physically unique subproblemsby observing their interaction with the environment entities.Then, we may compose (i.e. cluster) these subproblems toform different composite problems, among which overlap-ping or ignorance of parts may happen. It also leads tothe change of system-to-environment boundary, which im-plies switches of the perspectives accordingly. For instance,a “read attribute value” event can be viewed differently indifferent subproblems. To the least, there are perspectivessuch as the sender entity’s view, the receiver entity’s view,and a user of the entity’s view.
We think one of the most important enhancement to thePF approach by the proposed approach is explicitly mod-elling the environment entities and distinguishing different
46
Table 13: Telemarketing SchedulerTelemarketing Scheduler
Environment:{Telemarketer’,Phone’,Supporter’,SupporterDatabase’,OrderProcessor,CampaignDatabase’}
Interactions:{Telemarketer↑{start},Phone’↓{dialSupporter.PhoneNum},Supporter’�{Supporter.TicketPlacement},SupporterDatabase’�{Supporter.Details},CampaignDatabase’�{Campaign.Details},OrderProcessor�{Supporter.TicketOrder}}
Scenarios:{Telemarketer↑{start}⇒
SupporterDatabase’�{Supporter.Details},SupporterDatabase’�{Supporter.Details}⇒
Phone’↓{dialSupporter.PhoneNum},Phone’↓{dialSupporter.PhoneNum}∧
CampaignDatabase’�{Campaign.Details}⇒Supporter’�{Supporter.TicketPlacement},
Supporter’�{Supporter.TicketPlacement}⇒OrderProcessor�{Supporter.TicketOrder}}
kinds of interactions. With these explicit represented knowl-edge, the partition rule and the projection rules can be for-matted and become operatable, so that the problem decom-position process could be systematically conducted. Somekind of tool can be developed to make the process automaticor at least too-supported.
There is other proposal to model the generic elements.In [16], generic elements of requirements specifications arereviewed, some basic building blocks of which is shared bythe environment ontology proposed in this paper, such as,entities, states, transitions, etc. A major difference betweenthe two shouldn’t be ignored. That is, despite of these com-mon concepts, the semantics and reasoning behind is differ-ent. The proposed environment ontology only concerns thereal world entities interacting with the system under design.It assumes the system under design is situated among theseentities as a blackbox, who enables the state-transitions andmessage exchanges. For example, an entity in the Davisrequirements model will later become a designed element,within the system. In contrast, entities in these paper willled to the creation of a counterpart in the system inter-acts with it, but not an implementation of the entity itself.Comparing the two different perspectives yield clearer un-derstanding to the proposed approaches - one is trying tostreamline analysis with design and implementation by pro-moting implementation concepts to capture problem state-ments. The later aims to spell out the problem withoutbeing biased by specific implementation concepts.
AcknowledgmentThanks are due to Mr. Michael Jackson and the anonymousreviewers for their valuable comments and suggestions.
8. REFERENCES[1] D.L.Parnas and J.Madey. Functional documentation
for computer systems. Science Computing Program,25(1):41–61, Oct. 1995.
[2] M.Jackson. Software Requirements and Specifications:a Lexicon of Practice, Principles and Prejudices.Addison-Wesley, 1995.
[3] P.Zave and M.Jackson. Four dark corners ofrequirements engineering. ACM Transactions onSoftware Engineering and Methodology, 6(1):1–30,January 1997.
[4] M.Jackson. The meaning of requirements. Annals ofSoftware Engineering, 3:5–21, 1997.
[5] C.A.Gunter, E.L.Gunter, M.Jackson, and P.Zave. Areference model for requirements and specification.IEEE Software, 17(3):37–43, May/June 2000.
[6] M.Jackson. Problem Frames: Analyzing andStructuring software development problems.Addison-Wesley, 2001.
[7] Andres Silva. Requirements, domain andspecifications: A viewpoint-based approach torequirements engineering. In Proceedings of theICSE’02, pages 94–104, Orlando, Florida, USA, 2002.
[8] Jon G.Hall, Lucia Rapanotti, and Michael Jackson.Problem frames semantics for softrware development.Journal of Software and System Modeling,40(2):189–198, 2005.
[9] Jeffrey L.Whitten, Lonnie D.Bentley, and KevinC.Dittman. System Anaysis ans Design Methods.McGraw-Hill Companies, fifth edition, 2001.
[10] R.Lu and Z.Jin. Domain Modelling based SoftwareEngineering. Kluwer Academic Publishers, 2000.
[11] Z.Jin, D.A.Bell, F.G.Wilkie, and D.G.Leahy.Automated requirements elicitation: Combining amodel-driven approach with concept reuse.International Journal of Software Engineering andKnowledge Engineering, 13(1):53–82, 2003.
[12] Z.Jin, R.Lu, and D.A.Bell. Automaticallymulti-paradigm requirements modeling and analyzing:an ontology-based approach. Science in China (SeriesF), 46(4):279–297, Aug. 2003.
[13] Zhi Jin. Revisiting the meaning of requirements.Journal of Computer Science and Technology,21(1):32–40, 2006.
[14] Leszek A.Maciaszek. Requirements Analysis andSystem Design: Developing Information Systems withUML. Pearson Education Limited, 2001.
[15] A.Finkelstein, J.Kramer, B.Nuseibeh, L.Finkelstein,and M.Goedicke. Viewpoints: a framework forintegrating multiple perspectives in systemdevelopment. International Journal of SoftwareEngineering and Knowledge Engineering, 2(1):31–57,1992.
[16] Alan M.Davis, Kathleen Jordan, and TsuyoshiNakajima. Elments underlying the specification ofrequirements. Annals of Software Engineering,3:63–100, 1997.
47
