This preview shows page 1. Sign up to view the full content.
Unformatted text preview: CS 578 Software Architectures Spring 2009 Homework Assignment #2 Due: Tuesday, March 3, 2009 see course websites for submission details During early development phases of a software system, the informal system requirements are often translated into more formal models to allow different types of early analyses and to support subsequent development of more concrete design artifacts. For example, natural language descriptions of the required behavior in particular use cases are commonly represented via sequence diagrams which depict the resulting interactions among the system's constituent components. Further, different states in the system execution are often captured using state variables, values of which can restrict the possible execution sequences (e.g., we can define pre- and post-conditions on these variables for different component operations). Figure 1 depicts an example system specification diagram of a web caching system. The depicted UML sequence diagram corresponds to the following use case scenario: "When the Client requests a web page that is not cached, the page should be fetched from the Server and returned to the Client." Additionally, the "OCL-like1" constraints depicted in Figure 1 describe the conditions that should be satisfied in order to invoke a particular operation. For example, the requestServerData operation can be invoked only if the particular page is not cached. Figure1.Sequencediagramandoperationconstraintsforasimplewebcachingsystem. In this assignment we provide a set of high-level natural language specifications of use cases of the C4 system from homework #1. These descriptions also contain hints suggesting possible system states. The provided specifications are reflective of the types of natural language specifications that are often given for real development projects. 1 OCL is a commonly used constraint-modeling notation often used in conjunction with UML. For the purposes of this assignment, we are not asking you to adhere to OCL syntax, but rather use first order logic constraints like those in Figure 1. Your task is to depict how one of the architectures you developed in homework #1 supports the provided set of C4 use cases. The execution sequences of the use cases should be captured as UML sequence diagrams similar to Figure 1. You are also required to define pre- and post-conditions for execution of operations occurring in your sequence diagrams. These conditions should be captured as OCL-like constraints on system state variables. You can extract the system state variables relevant for your system from the provided specifications (e.g., you can have a variable requestPending). The use cases of the C4 system you need to model are as follows: 1. Successful ISDN request submission. An administrator can submit a request for activation of ISDNservicesonuser'sbehalf.Theuser'srequestisacceptedaftercheckingwiththedatabaseif ISDNoptionexistsfortheuser'ssite,andtheuserhasnootherpendingrequests.Therequestis forwardedtoNOSSsubsystem. 2. Unsuccessful ISDN request submission. A user's request for ISDN services is rejected and the userisinformediftheuser'ssitedoesnothaveanISDNoptionortheuserhasotherpending requests. 3. ISDNisphysicallyinstalled.TheserviceprovidercaninstallISDNsupportattheuser'ssite.This scenariohappensonlywhenthereisapendinguser'sISDNrequest.Inthesystem,thiswillbe reflected with the exchange of events in which the NOSS system sends confirmation of successfulinstallationtotheC4system. 4. ISDNwillnotbephysicallyinstalled.TheserviceprovidercanrefusetoprovideISDNforauser ifthemanagementdecidesthatitisnotcostefficientafterall.Thisscenariohappensonlywhen thereisapendinguserrequest.Inthesystem,thiswillbereflectedwiththeexchangeofevents in which the NOSS subsystem sends refusal message to C4. Subsequently, the ISDN option for theuserisdisabled. 5. AdministratorenablesISDNoption.AmanageroperatingononeoftheDownstreamsubsystem canenableISDNoptionforauser.Thiscanbedoneonlyiftheuserdoesnothavethatoption alreadyenabled. 6. ISDNrequestcompleted.Anadministratorcancheckonthecompletionstatusofauser'sISDN request.Iftherequestiscompleted,theuserisinformedabouttheoutcome. 7. Successfulphoneplanrequestsubmission.Anadministratorcansubmitarequestforachange ofphoneplanonuser'sbehalf.Theuser'srequestisacceptediftheuserhasnootherpending requests.TherequestisforwardedtotheBillingsubsystem. 8. Unsuccessfulphoneplanrequestsubmission.Auser'srequestforISDNservicesisrejectedand theuserisinformedifshehasotherpendingrequests. 9. Phone plan modified. When the requested phone plan modification has been successfully completed, the Billing system reports it to the C4 system. The administrator subsequently informstheuseraboutthesuccessfulcompletionoftherequest. 10. Subscriptiontonewbusinessoptions.Ausercansubscribetoreceivinginformationaboutthe published business options. This is first reported to the database. If the user is not already subscribed, the Downstream system in charge of publishing new business options is notified abouttheuser'ssubscription.TheBillingsystemisalsonotified. 11. Unsubscriptionfromnewbusinessoptions.Ausercanunsubscribefromreceivinginformation about the published business options. This is stored in the database. If the user has actually been subscribed (users without subscriptions can still make these requests), the Downstream system in charge of publishing new business options is notified about the cancellation of the user'ssubscription.TheBillingsystemisalsonotified. 12. Newbusinessoptionsnotification.TheDownstreamsystemcanpublishnewbusinessoptions. If a user is subscribed, the C4 administrator will be notified about it in order to forward the informationtothesubscribeduser. 13. DisconnectingISDN.Ifauserdidnotpaythebills,theBillingsystemwillnotifytheC4system. TheC4systemwillthenmanagethenecessaryprocessing:theadministratorwillnotifytheuser, theISDNoptionwillbedisabledandtheNOSSsystemwillberequestedtophysicallydisconnect theuser'sISDNline. QUESTIONS 1) For each of the use cases above, create a UML sequence diagram for your C4 architecture complete with OCL-like constraints on system variables. If your architecture DOES NOT support a particular use case, do not change your architecture, but rather explain in detail why your architecture as designed in Homework 1 does not support the use case. 2) Briefly describe any discovered deficiencies with the given scenario specifications, discrepancies between different scenarios, or potential problems when executing different scenarios in your system (e.g., deadlock conditions). Be specific: For example, note where your constraints have been violated. 3) Having supported each of these use cases (or attempted to support each), how would you modify your C4 architecture to better address your scenarios. How would you resolve inconsistencies and simplify component interactions? PLEASE NOTE: For the purposes of this assignment, you can focus your models on the case of a single user who is always being serviced through the same administrator. Additionally, an administrator can do only one thing at a particular time instant (e.g., an administrator cannot report a business offer at the same time she is trying to submit an ISDN request on the user's behalf). The given specifications are at a very high level of abstraction and provide a lot of room for interpretation, which will depend on your system's architecture. If you are making substantial assumptions besides the ones given above, please write these down. ...
View Full Document
This note was uploaded on 06/16/2009 for the course CSCI 578 taught by Professor Nenadmedidovic during the Spring '08 term at USC.
- Spring '08