| Home | Up | Java Resources | C++ Resources | .NET Resources | DevHood | Search |
Journal Entries, Week #3
Quick jump to: alio, beowulf, jamesmcd, jkdot, jsegars, lipinski, localguy, othello, rjmorgan, ryanaip, thewang, tjice, wrprice, swong.
----- ALIO
-------------------------------------------------------------------------------------------
Journal for Milestone 1
Status:
· 100% completed
· The Milestone was to create some stub code for the interaction between people as well as a UML of the structure for the implementation.
· The UML for communication between people (“behaviors”) can be seen at http://www.owlnet.rice.edu/~ryanaip/comp410/behaviorsUML.jpg
· The “people” objects communicate by calling the “GetBehavior” method of the person object and passes in itself as a parameter. Person A is passed as a parameter to the GetBehavior method of person B so that some decision making process can choose which of the behaviors that belong to person B will be chosen by person A.
o The setup of the Behavior class is that a person has a set of Behaviors that are done to them by another person.
o For
example it is not the person that has a Buy Behavior but an item that has that
Behavior that is able to be called.
How can an entity figure out what sort of entity it is
talking to without going through a painful and less than robust reflection
process?
·
In addition to the milestone there was a light
weight interface that was put together to show that this process can actually
work. The interface is dynamic in that you can add people and items to a space
and people will randomly interact with Items or People for a designated amount
of time.
There is definitely a time to design and a time to
code. The trick is knowing when to
switch from one to the other.
Obstacles encountered:
· The first problem was the fact that there were many different implementations of how to get behaviors to work. After thinking of several ideas it was finally decided that choosing one approach and seeing if it would work effectively was the best choice
· The other problem was the implementation of a “handshake” between people. This was solved by having each space contain a list of “members” that are within the room. Then it would call the person’s “SelfBehavior” method where the person object would then decide to interact with another person, object, or choose another behavior.
Solutions proposed:
Analysis of development process
· Discussion of where people are in the development of their milestones is having a good effect by maintaining pace of the project.
What seems to be working –
· See above.
What seems to not be working –
· . The only problem I had this week that was not project related was the inability to download files from the exciton server but that was fixed this afternoon.
Proposals for change
· I don’t think everyone is using dev web yet. Perhaps an email to the comp list serve telling everyone what to do would fix this. Done!
Nice job!
----- BEOWULF
-----------------------------------------------------------------------------------
- Status of
Milestone
- Gains Made:
Made a good start on the model for the program. Met with Jim, Ryan, Ali, and Dr. Wong
to improve and develop this design.
Stub code and UML was created for these and presented to the
class.
- Obstacles: A
number of things still need to be worked out in the model. Its still not entirely clear how the
handshaking will work out.
- Proposed
Solutions: Some good comments where made during the presentation
Friday, and I took some notes on this.
The model will continue to develop and improve with everyone
providing input. Different types
of UML diagrams could be made to better describe the processes like
handshaking.
Documentation and dissemination of the current design is crucial. Do we have a mechanism for this yet? - Analysis of
Development
- Whats Working: I
think putting in the leadership roles was a good decision. I also think the move to devhood is working well. I subscribed to the forum, so getting
the email forces me to know when new posts are made.
- Whats Not
Working: Lab time. Card
access.
- Proposed
Changes: It looks like card access might be getting solved thanks to
Dr. Wong’s efforts. You’ve got to
wonder who made this decision in the first place! Who makes these decisions up on top J Lab time I’m considering just dealing
with since no one seemed too crazy about my idea from my last
journal. It is a little concerning
how many people missed the Friday lab, however. It concerns me
too—I’m looking for alternative times.
Nice
journal.
-----
JAMESMCD
---------------------------------------------------------------------------------
·Status of this week’s Milestone:
·Gains Made: We developed a system where people and items could be added to a room where they are allowed to interact. To witness this interaction, each person has a window with a text box in it where every interaction with that person is recorded. This progress involved finalizing a general structure for People, Spaces, and Items, as well as for the behaviors each will have.
·Obstacles encountered: Several times we found that to get this demo up and running we had to hack a number of things in. We were not certain how people would run (threads, event queue, etc.) and the creation of people and the way one person selects and executes another Entities’ behaviors was not to be part of this milestone, so a temporary solution was needed.
Did you document what those hacks were and why you did
them?
·Solutions Proposed: To solve these two problems we simply came up with easy answers as temporary solutions that may or may not work as final implementations in later milestones. To execute people (really!) we used a sort of mini-event queue in which each Space is told to execute, Run(), and they tell each Person to execute. For Entity/Behavior selection we simply gave all the possibilities to the Person requesting them and made a random decision on which to use.
·Analysis of Development process
·What seems to be working: The groups. We found that our group could work very together. There are not too many people, nor too few.
·What seems to not be working: So much changed mid-milestone this week it’s difficult to say what is not working because I’ve only been working with my group. Nothing right now, I guess.
·Proposals for Change: Perhaps more use of the Devhood system. Also, there is a C# newsgroup on Devhood that I’ve already found useful. Perhaps people should use that. Ask more questions on the newsgroup. Not only does it help you in solving problems faster, but it also helps other people know what you’re doing with out you having to tell them.
What’s the name of this C# newsgroup?
Good job!
----- JKDOT
----------------------------------------------------------------------------------------
Milestone Status:
To date, I have completed my first milestone. After brainstorming, conducting interviews and role-playing sessions (great idea!) with potential users (friends), and talking with the customer, I came up with several user stories that would help describe the functionality of the application.
- There could be many more scenarios. However, I feel that this list gives a representative number of what should happen in the basic implementation. Of course, as the application grows and develops, we may realize that we need to add or remove a certain piece of functionality.
- The scenarios are organized by type of user. Mall managers have slightly more functionality than store owners (the customer requested this).
- The stories helped to guide the design of the first prototype of the application.
In talking with Dr. Nguyen, I realized that he is not my
(the UI team’s) only customer. The rest
of the development team is also our customers.
If you have any needs (special things you’d like to see for debugging
purposes, for example), please let us know.
This is an extremely important point!
There were not that many obstacles this week. I was able to accomplish the following:
- Role-play mall manager and shop owner with friends. Though this isn’t a scientific or empirical method, I was able to gain some valuable insights into how the user would or definitely wouldn’t use this program.
- Come
up with basic scenarios and consult with Jeff about the GUI. We sketched out a few possibilities for
the layouts based on the information that we’d need for the simulation.
Have you considered the issue of how to manage the dynamically changing configuration UI needed to add/remove/configure behaviors and demographics?
- Talk with Dr. Nguyen. From the sketch, Jeff and I brainstormed some other features (such as the ability to chat) that may make the experience more game-like (another request from the customer). However, after talking to the class, I realized I had to speak with the customer and make sure we didn’t overlook his needs.
- Sketch the prototype for the customer. I walked Dr. Nguyen through a couple scenarios on the white board so that he would be able to see our thought process with respect to the interface design. He seemed pleased with what I presented.
- Write the scenarios. At first, my concept of the user stories was vague, but I read some chapters in a usability engineering textbook on how to structure the scenarios and was able to make more coherent stories.
Analysis of development process:
I think the development process is going well, especially since we built some structure into the team. I’m sure we’ll get something out of it by trial and error. Thus far, I’ve been used to doing my own thing and communicating with Jeff and the customer (and then to the rest of the team). I’ve got to get used to reporting to the manager of the UI team now.
- Problem: Getting used to the new structure of the “company”
- Solution: I think this will take time and practice.
- Problem: Staying focused on our deliverables.
- Solution: First, we need to establish the deliverables (don’t know when we could do this) and then make a definite plan not to deviate too much. The customer knows what he wants and is open to cool ideas. However, we can’t get sidetracked by them.
Yes, yes,
yes! Easier said than done
however. How do we do it? Who does it?
Nice journal!
-----
JSEGARS
-------------------------------------------------------------------------------------
Milestone: Dummy UI
Gains Made
For the milestone this week, I got basically everything done that I hoped to. After meeting with Dr. Nguyen and reviewing Kijana’s notes from another meeting, I created a mockup in VS of the main management GUI. The general layout of this GUI was previously presented to Dr. Nguyen and he seemed to be pretty happy with the layout and the features presented. I also created a feature list and step by step outline for mall creation, store creation, and store management which should aid in making mockups for these portions of the project.
Where is
this feature list and step-by-step outline?
Why should you not keep these
things to yourself?
What level of functionality does the
above demo code have? Where can we get
it and try it out?
Obstacles
Although I wasn’t expecting to
complete it for this milestone, I spend some time thinking about a wizard
driven interface for mall and store creation.
I was surprised to find that VS.
Consider
dynamically generated UIs. What are the
advantages/disadvantages of trees vs. tabs?
Development Process
What's Working
I like that we divided up into teams in the last class. The hierarchy should make it lot easier to communicate between groups and get a better idea of what everyone is doing. Pair programming also seems to be working very well, at least on my part of the project. For UI, its been very helpful to have another person bounce ideas off of when trying to determine what will be intuitive to the user.
What's Not Working / Change
One thing that I still see as a problem in our development process is communication. Whereas last week the problem was the lack of a good communication method, this week the problems seems to have reversed itself. We now have the newsgroup, devhood, and a mailing list. We should probably pick one and stick to it, or at least decide what each method of communication should be used for. By trying to use three different thinks at once, we increase the odds that important information will be missed.
While the
newsgroup and DevHood are redundant, the mailing list
is not. The mailing list is for very
volatile information such as announcements, while DevHood
is better for things with medium length lifetimes.
Nice journal.
-----
LIPINSKI
-------------------------------------------------------------------------------------
Milestone: Create UML Diagram to represent a “Person”, as well as
create stub code for a person. Also
create a simulation as proof of concept.
The milestone is 100% complete.
Gains Made: Working with the rest of the “model” group, we managed to cobble together a demo, which shows a room and interactions taking place in the room. The items and people are all independent, but the behaviors allow them to interact. This shows that are model can work for the shopping mall. The actual program should be on Exciton, and accessible to all, as well as a UML diagram.
Obstacles Encountered:
· Choosing algorithm needed to make decision.
· How to control people. Should they run independently as their own thread, or use an event queue or something else entirely.
· What to abstract, and what not to.
Solutions Proposed:
· For now we decided to just have a random decision made. Later on this can be changed, but for this milestone we were just interested in seeing if it could work. Never underestimate this need.
· We are using an event queue right now, but that may change later. Based on what?
· We decided to go with the pattern in the UML diagram, although we are not completely sure if it will work out. If needed to we should be able to change later with only a minimal amount of effort.
Development Process
The project has come a lot farther then I initially thought it would in these two weeks.
What’s Working: Working as a team to do design and
programming. Furthermore, meeting as a
team to do some programming.
What’s not Working: Everything seems to be going fine, at least within the model group. If anything I’d say the things that weren’t working were the Exciton issues that were resolved today in class.
To Change: Set up interfaces for all the groups ASAP, so that we can program without having to worry about later restrictions. Setting up all the interfaces now, will mean we know exactly what we are working with. I’m still not sure exactly how the GUI will relate to the model etc.
You hit the
nail on the head here. Note that
interfaces are still subject to some amount of change, but at some point you
have to take you best guess and put it through some paces. Since everyone needs to use the APIs, then
they have to be published in a long-lifetime location.
Picture of the Simulation:
A description
here would help. Is there any
documentation as to how to use this demo?
Nice job.
-----
LOCALGUY
---------------------------------------------------------------------------------
Milestone (Web
Services):
- Gains
Made: I solved my web services problems by reinstalling the .
Have you looked at Data Access Application Blocks? They encapsulate a lot of the common connection processes.
My Database Service Front End
- Obstacles Encountered:
§
I spent entirely too much time looking into
database access. I had problems with
passwords and figuring out how access worked in general. There are several ways to do each type of
access and there is loads of information on the internet although few of it was
relevant to what I was trying to do. It
appears that this is a “deep hole”. I
seem to have lost some focus on web services and found myself knee deep in
databases.
This is unfortunately a very common problem. How can one prevent this?
§
I had a big problem with learning how to access
a web service from an application.
Apparently Visual Studio is supposed to create a proxy when you add a
web service reference. Since it never
generated a proxy for me I sat for hours trying to figure out what was
wrong. I ended up finding a command line
solution to generating the proxy manually.
Is this a problem in general with VS? Did you publish your work-around somewhere?
§ It is incredibly annoying dealing with lag when working in VS off of the exciton server and it is very hard to work in my room since there are so many distractions from roommates, etc.
- Solutions Proposed:
I am going to get back into looking
exclusively at web services and put data bases aside. There is simply too much information to deal
with and it does not seem necessary at this time. If we need to come back to it I would be glad
to pick it up. I think that it would be
nice if everyone posted their general experience with .
Development Process:
- What seems to be working?
I think it is great that we have come up with some kind of organization hierarchy. I feel that it will keep our group synchronized, and it will help me feel like I am actually working on something with a group rather than independently.
- What seems to not be working?
Now that we are all working in our separate areas I would like to see some code. It has been mentioned that we have some kind of CVS versioning on exciton. Maybe we need to spend some class or lab time in discussing how it works. We need to start some kind of repository for stub/finished code. I think it would help us to know where all the groups stand.
- Proposals for change:
I would like for our groups to
break off and have a mandatory discussion for the last 10 minutes of class so
that we can keep each other updated on where we are and where we want to
go. Maybe this could happen at least
once a week. It is not always easy to
meet after class and it is always good to keep everyone informed.
Good idea.
Let’s try it.
Good job.
-----
OTHELLO
-----------------------------------------------------------------------------------
·
Milestone Status:
o Gains:
I’ve gotten a basic Remoting sample working – it’s
under http://www.owlnet.rice.edu/~othello/comp410/RemotingTest.zip. It’s basically proof of concept code that Remoting can be used as a mechanism for implementing remote
procedure calls. In the Visual Studio
solution you will find three projects, one for a class library (object.dll)
which is a basic “remotable” object, and two console
applications, one a remoting “server” and another a remoting client.
The server just starts and listens to
client requests, printing out information so that you can see that the actual
calls to Console.WriteLine(...) are occurring on the server
process, even though they’re called from the client. You can hit enter to cause the server to
quit.
The client also just connects to the server quickly and exits afterwards. You can run it multiple times to see the server react to successive clients.
I can’t take too much credit for the code, I’ve gotten it off the
web at a MS remoting demo page, but they had it only
as C# source files, so I got to experiment to play around with VS to get the
entire thing in the same solution so that when you click build, it’ll compile
and link it all. It was nice getting
more acclimated to VS.
In addition, I’ve coded up a RemotingLib
class library, and corresponding TestClient and TestServer console app projects, however I haven’t worked
out all the kinks in it yet. The basic
design behind it was having a bidirectional Object pipe (kinda
like a TCP/IP socket, except that instead of sending and receiving bytes, we’d
send and receive objects). Depending on
whether or not the object is marshaled by value (a serializable
object) or by reference (inherits from MarshalByRefObject)
the logic for the object would either be executed on the originating machine,
or on the machine that invokes the method call.
Take a look at “smart sockets” (http://www.vbip.com/books/1861007396/chapter_7396_01.asp)
which is a way to serialize over a raw
Thus one would model an abstract protocol, of sending objects in
some sort of defined order and type, instead of sending bytes/bits at some order/type. That way you can swap out implementations,
leverage inheritance hierarchies, and do all that nifty object-level/hi-level
design without worrying too much about the low-level implementation
constraints. Of course though, if you
are marshaling by value (hence serializing), be wary about copy costs for
“large entities”.
Idealistically this RemotingLib would
take all the complications of remoting out of
it. You would pass in a “ServerSpec” or “ServiceSpec”, and
a IChannelFactory and immediately be returned a
reference to this abstracted object connection (IConnection). The ServiceSpec is
just a simple object that defines a service name (used for the remoting framework) and a port number. You can use this to register a new
server. A ServerSpec
is a subclass of ServiceSpec, and it includes a
hostname (a DNS name or IP address), because you will need that to connect to a
“server”. In reality, as far as I know,
both boxes will be “servers” once this bi-directional pipe is achieved, but I
usually reserve the term server for the box who was originally waiting for the
connection to be initiated.
o Obstacles:
The new RemotingLab isn’t completely functional yet,
I’m in the stage of debugging it. I may
be wrong about Remoting “servers” (machines that can
host remote objects) in that I thought that once you’ve connected to a
registered remote object, you can further receive other remote objects and not
have to register the types, and whatnot, regarding those other objects. It may be possible that in order for you to
use a MarshalByRefObject, each one of the object
types would have to be registered. I’m
not sure if the same library design could really be achieved then, if that
constraint were introduced.
o Proposed solution: I will look further into remoting and
read through some more example code, I suspect that after reading more
documentation, I’ll be able to discern some more information about it. In my opinon, the
documentation that I’ve been encountering has been largely hard to
understand/vague, so it doesn’t really enable a deep understanding of the
framework. Maybe if I become more versed
in it, I’d write some supplemental documentation myself to help others
interested.
Come by and borrow the Remoting book from the reference library in my office.
·
Development Process:
o What’s working: The time that Justin and I
got together to work as a pair was constructive, as I had another person to run
my ideas against. I’m also pleased that
there’s a more hierarchical arrangement for the class now, for then I can
communicate with one person, and expect him/her to communicate with the others.
o What’s not working: I don’t have very many complaints about the development process
anymore, except for the inconvenience of location. However, that’s been discussed in detail (how
Symonds is locked, and doesn’t have VS .NET installed). I’m probably resigned to the idea that
working out of home is the most convenient way to get a copy of VS in front of
me. However, that makes it difficult to
work in pairs, especially for me since I’m off campus – or it would make it
hard for my partner to work in my “room”.
o Proposals for change: It would be nice to at least get the .NET framework installed on
the Symonds workstations, so we could execute the .NET apps. Nonetheless, it would have been almost
impossible to coordinate the class using the .NET framework if we didn’t have
Exciton as our terminal server. I know
this has also been brought up in the past, but I think I would also be very supportive
of the idea of moving our Friday evening lab to some other time, or another
location if necessary. It’s not like VS
.NET is installed on the Symonds workstations... the Architecture school has
RAVL lab (basically a specialized Owlnet PC lab, much like Symonds II is
specialized), which has nice 21” monitors, and relatively fast machines. I don’t know if VS is installed there, but
I’ve seen ARCH classes reserve it. Since
it’s administered by Owlnet/CTS I don’t see why we couldn’t reserve
it. And proximity is a plus also, since
Anderson Hall is just a hop-skip-jump away from Duncan Hall.
Nice
journal.
----- RJMORGAN
--------------------------------------------------------------------------------
Gains made
I now have a
very knowledgeable understanding of the C# language, and its many linguistic
elements. I have a draft of the document
relaying this information to the rest of the class, but I need to revise and
polish it before students look to it for information. Looking forward, I will have the document
ready for publication by Sunday evening.
Obstacles encountered
The main
reason I did not complete my milestone is that I found it difficult to maintain
focus on the needs of the document. It
was very difficult to decide what information to cover and what to leave out in
the hopes that the document will be readable and useful yet still manageable
for the rest of the class. I found one
paper that is similar to my document, but I found that its scope was too wide
for someone wanting to dive into C# with little prep time.
How can you get
both your info and any other info you find out to other group members in a
timely manner?
Solutions proposed
Looking back,
I should have set up a designated schedule for completion of my milestone. Breaking it down into smaller sub-milestones
would have enabled me to track my progress as well as provide organization to
the way I was approaching the problem.
Although I failed to do that this time, I can see that this approach
should benefit future milestones.
Hugely important point here!!
Analysis of development process
What seems to be
working -- why?
With the help of Dr. Wong, I believe we are doing well at
addressing some of the problems that creep up in the communication and teamwork
aspects of our project. I’m fairly happy
with the setup of our initial organization structure, and I’m anxious to see
how it works out. We should revisit this
structure in the near future (maybe in the next few weeks) to see if
adjustments need to be made to reflect the current status of the project.
What seems to not be
working -- why?
On the flip side, it seems like all discussion about these issues
has been stimulated by Dr. Wong. It
seems like people are hesitant to speak up either because it is unfamiliar
territory or they are more comfortable letting others shape the way the project
turns out.
Great point – student input and discussion is vital here.
Proposals for change
On Fridays
when we sit in a circle and go around the room discussing milestones, we have
had some very interesting and important issues brought to the table. I propose that we try to do this more than
once a week to get a feel for how everyone is working together and separately,
so that more issues can be brought to the table by group members rather than by
Dr. Wong.
We’ll
definitely try to do that.
Good
journal overall. There’s something funny
about the formatting of the file you submit.
Can you redo the file from scratch please?
-----
RYANAIP
------------------------------------------------------------------------------------
Development Status
Milestone Progress
My assigned milestone was People-Space interactions. As it turned out, the various model group projects merged into one, mostly due to the interdependencies between all of the different designs. Here, however, I’ll focus on describing my area.
First, here’s the UML diagram specific to People-Space interactions:
There are actually very few interactions between people and spaces – people interact primarily with the entities in a space. Once a person enters a space, the only thing he does to interact with the space is to ask it for the entities contained in it (ISpace.Members).
Interesting problem here: What do we do when a task disappears? Who handles the re-tasking?
The other operations deal primarily with the flow of the
simulation. Entities can be added and
removed from a space using ISpace.AddEntity() and
ISpace.RemoveEntity(). When an entity is added to a space, the CurrentRoom
property of the entity is set to the space, enabling the entity to talk back to
the space (for example, to get its Members).
Additionally, the space is the object that calls the entities’ Run() methods. For each tick of the simulation, Space.Run() is called, which in turn causes IEntity.Run() on each of the objects contained in the space.
The next step in people-space interactions is to enable
people to move in between different spaces.
That work depends on the results of Brian’s (beowulf)
first milestone, building connections between spaces. His work should be easy to integrate, at least
for rooms on the same machine, so that should be achievable for the next
milestone.
The full code for the first milestone is located in “Archives\Model\Milestone1”
in the exciton comp410 directory. Additionally, source documentation is located
at http://www.exciton.cs.rice.edu/comp410/Project/ms1/modeldocs/Solution_Milestone1.HTM
and the full UML diagrams are at http://www.owlnet.rice.edu/~ryanaip/comp410. (also at http://www.exciton.cs.rice.edu/comp410/Project/ms1/default.htm)
Process Analysis
I think that the decision to break down into three groups was a good one. We (the design group) ended up working together on the first milestone before we’d actually created the groups, and I think that it helped us to get more work done. Hopefully the same will hold for the next milestone.
I do think we need a better method of distributing code and
updates. We should probably set up a
Nice job.
----- THEWANG
----------------------------------------------------------------------------------
Journal #3: Developing AI for decision-making
Milestone Results
1) First, in order for a person to come to a decision to perform a certain behavior, she must have some sort of preference (possibly negative) for executing that behavior. This does not necessarily correspond to separate preferences for going to shoe stores, eating at Italian restaurants, or leaving the mall. To do so would not be feasible, as there would have to be a preference for every item, store, and food in the mall, even those that have not been encountered yet.
Rather, preferences would be factors that aid in making decisions. For example, a person may have preferences such as: impulse buyer, likes shoes, likes black, frequent shopper, and wealthy. Depending on how strongly she feels about each preference, a decision will be made to enter a leather shoe store, but to stay away from Baby Gap. Some of her preferences may dynamically change (such as a reduced preferences for shoes if she has already purchased three pairs), but that would probably be dealt with in a later milestone.
Have you left out an abstraction level here? Shouldn’t there be a level at “take a bunch
of behaviors and select one”.
2) To satisfy these preferences, entities
(items, stores, other people) will need to have attributes that
will match the shopper’s preferences.
For instance, the shopper above probably will have no concept of what
leather boots are, but she can tell that the boot has attributes such as 90%
trendy, black, costs $150, and/or made in
Note that a slicked-back Italian stallion gigolo has
these same attributes. How can one
entity tell what another entity is in the first place?
As for the attributes of stores, that could be implemented in exactly the same way as items, or in some sort of kiosk, as was proposed in class. However, there would probably need some mechanism for getting a store’s attributes through window shopping (which is in itself a large component of real shopping). Interactions with people could be implemented in the same way as interactiong with items, with preferences being mugger’s target, hottie, and bag lady, for example.
Is an attribute
different than a preference? They
can be, but there are sufficient similarities, that they should be the same
class. I’ve named this Trait in the UML
diagram. Also, the demographic data will
be it’s own class, and will be used to generate traits, based on a set pattern
(see concerns below).
Be careful of falling into a huge type-based decision
tree implementation here. Is it really
about having the a particular type of attribute or that certain attributes have
certain behaviors in the decision process.
For example, could attributes be considered as simply adding to a
decision weight—the important ones add more weight, unrelated ones add zero
weight.
3) Decision making process. Decisions will constantly need to be made, most of which will be to not buy an item. So the actual implementation probably depends on the decision of what was talked about in class about looping over all the people in a particular space, as opposed to the whole mall.
As for choosing to purchase an item, the level of matching between the attributes and preferences will be computed (by some formula to be determined). Not holding a particular trait could simply mean that she is neutral in that trait. Each person will have a threshold which must be met before an item is purchased. Either items are purchased if they simply clear the threshold, or they are kept in the person’s memory, while she compares other items at the same or at other stores.
4) Feedback mechanisms. Well, from what the people group did in class showed with the get older behaviors would work well for any feedback. There could simply be behaviors that altered the traits or had some kind of countdown that, when satisfied, led to another behavior such as leave the store or stop buying shoes.
Concerns
·
It seems that the whole purpose of this piece of
software is to produce and test combinations of stores, items, layouts, etc. to
best attract customers to the mall, and eventually lead to purchases. But it seems that the customer has given (or
will give) us completely insufficient demographic data to run the
simulation. Not all middle class Asian
people want to purchase the same things, and unless we have more data, we could
arbitrarily (correctly or incorrectly) say that 65% of them like yellow
dresses. I’d like to let the customer
know about what we would have to do in the absence of real data before he
writes off our program. Of course, the
preceding discussion has absolutely no bearing on the way the software is to be
designed or developed, but I just wanted to point this out.
It is not our job to run the customer’s
simulation with the customer’s data. It
is our job however to insure that
when the customer runs our program with his data, that it runs correctly. That is if we fill our mall with middle class
Asians who have a 65% probability of buying a yellow dress, then the resultant
statistics should bear out that this did indeed happen. Our program must be able to handle enough
demographic data so that it will do a correct simulation of the mall, even if
we are not initially given all that data.
·
In looking at the UML diagram given in class
Friday, how are physical store and mall layouts going to be implemented? What if you have a Macy’s in the mall? Not all items are able to be immediately
reachable.
There’s that lack of documentation issue again.
Milestone Problems
· Getting the specifics of what I needed to complete was hard because the original milestone goal was a bit vague.
· Figuring out the boundaries between what I was doing and what the other groups were going to do, and keeping that line delineated.
What are you suggestions for
improvement? Be specific. For instance, don’t just say: “be less vague” as it gives us no guidance on
what specifically to do to solve the problem.
Good journal overall.
----- TJICE
-----------------------------------------------------------------------------------------
I completed my milestone this week which was to create a 2D renderer
for the mall. Right now it is extremely not aesthetically pleasing
It has an underlying class which actually draws the mall based on a
grid system of ColorPoints. I also tried to make an editor for this
structure from a Windows interface, but I became extremely ill
and spent all of Thursday in a clinic.
Obstacles:
There were really no obstacles that came my way.
Vague – bring up the little issues
then. They may be important to someone
else.
Possible Improvements:
It might be reasonable to consider another representation of this
system that can also help people objects decide how to get to certain
spaces within the mall. But this is for later.
Vague again.
Incomplete
due to illness.
-----
WRPRICE
------------------------------------------------------------------------------------
Milestone:
Solution for auto-detecting whether a server exists on
the local host, preferably with remoting.
Milestone Status:
- Gains made:
- Once the quirks of remoting
were resolved, it was quite easy to solve this problem; I made a demo
application that transfers an object (in this case, a string) via remoting from one instance of the application to
another – either on the local host or on a different server.
- As long as our objects avoid encapsulating
complex framework components (see below), this should be a breeze for our
main project.
- Found (but did not yet implement) a way to
transfer objects over remoting via a binary
serialization (compact) while still using the HTTP methods – this avoids
serializing possibly large object trees as ASCII text in the form of XML
SOAP.
- Obstacles encountered:
- Microsoft did not document parts of Remoting well
– neither in the online documentation with VS.NET nor MSDN, from what I
could tell. Only later was I
reminded that Dr. Wong has a library of books; all persons involved in remoting
implementation should use these books as a reference in the future
instead of wasting time (as I did) searching for answers from MSFT or the
Internet in general.