Hi Karen- I wanted to respond to your comment about the use cases, since I wrote them. :)
There are a lot of different ways to write use cases. I tend to think of most of what I've seen in the functional specs as scenarios rather than use cases, but from what I've read, the definitions tend to blur. I actually prefer writing them the way I did, precisely for the reason that you objected to them....because they are like pseudo-code. It's a good way to start working out the logic of the user experience. I like Ethan's example of a beginning to end scenario (I think we should incorporate some of those as well). I would take a scenario like that and walk through it the same way. Doing this kind of step-by-step thinking will make development easier, in my opinion. thx, ginnie On 06/15/09 09:33, Ethan Quach wrote: > Karen, > > Thanks for taking a look at this ... > > > Karen Tung wrote: >> Hi Ethan and team, >> >> Here are my comments: >> >> Section 1.3: >> - Shouldn't there be a dependency on the parser to allow data from >> the manifest to be modifiable? > > I should probably note that possibility. I mentioned > below that on the server, a base manifest will be validated > when a user adds one to an install service on the server, > but I don't really describe how; its not yet clear to me > whether we want the parser to do anything special for this. > >> >> Section 2: >> - Will one derived manifest correspond to 1 derivation module? >> If I have code in 1 derivation module that can be re-used by >> 2 different derived manifests, would I have to register this >> same derivation module 2 times, each time with a different manifest? > > yes. > >> >> Section 3.3: >> - Perhaps it is implied, but I think it would be more clear to >> explicitly say >> whether the associated module with the >> derivation functions is automatically deleted or not when you delete a >> derived manifest. > > okay, I'll add that. > >> >> Section 5.2, second paragraph, "The installadm add subcommand....." >> - Just curious, how would the server env be able to determine whether >> the the given manifest and the derivation module will derive a valid >> manifest, >> before the values are actually derived. From the server side, I think >> we can validate that all fields that require values either have >> values or >> have functions to derive a value. We can also validate that the >> function >> they specify indeed exist in the derivation module. Until we have >> the context of the client, I don't think you can really execute any >> code.. > > This is true. The wording should be changed here to note > the exact validation that is being done on the server. As > you note, its not quite going to be like validation of a full > non derived manifest on the server. > >> >> Section 5.3 >> - Will this new smf service for deriving the XML file end when it has >> completed >> it's work? Will it output a "new" manifest with the derived values to >> be consumed by the auto-install smf service? > > yes and yes. > >> Before it create this "new" manifest, >> will it also validated the manifest syntactically, >> semantically...etc.. So, the auto-install >> smf service can assume that the given manifest is valid and not need >> to do >> duplicate work? > > It could do the same type of validation as would have > been done on the server for a complete manifest (I think > right now that's just syntactical validation.) before > coming "online". > >> - Also, since this smf service is separate from the the auto-install >> smf service, >> how would the output/error from this service be reported? Will it be >> a separate >> log file from the auto-install service? > > Its a separate log file. > >> >> Section 6: >> - All the uses cases are not really use cases. To me, they are more >> like pseudo-code >> describing the code path of different things that can happen when >> derived manifests >> are used. > > Okay. I think we need to add some end to end use case > scenarios like, "user wants target disk to install on to be > derived." Is this what you are thinking? > > > thanks, > -ethan > >> >> Thanks, >> >> --Karen >> >> Ethan Quach wrote: >>> >>> The functional spec for AI derived manifests is posted at: >>> >>> http://www.opensolaris.org/os/project/caiman/auto_install/DerivedManifests/AI_derived_manifests_func_spec.txt >>> >>> >>> >>> >>> I would appreciate and feedback comments. >>> >>> >>> thanks, >>> -ethan >>> >>> _______________________________________________ >>> caiman-discuss mailing list >>> caiman-discuss at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >> > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss -- Ginnie
