Project: Stage 5  (Regional Auto Parts)

I think initially, it would be important to review data aspect of the system using work products produced during analysis, such as entity-relationship diagrams.  The system in question is to provide a range of services, yet all basically rely on the underlying data in some manner.  So to some extent, the design should be approached from a bottom-up approach focusing on the data, as the data basically provides the foundation upon which the entire system rests.  Designing the appropriate data structures along with defining related data objects would be a good place to start.In the case of this particular system, there would also need to be consideration of how the data would be distributed between retail units.  (Would there be a centralized data store?  Would each store maintain independent data stores that could still be viewed/searched from remote units?  Etc.…)   

As far as selecting an architectural style goes, I don’t think this system could be pigeon-holed into a single style.  I definitely think elements of a data-driven style would be very appropriate as alluded to above.  I could see this going hand-in-hand with a layered approach, though.  Overall, as I mentioned in this week’s online discussion, I still don’t think I have a firm handle on the idea of applying an architectural style to a design.  I understand the various discussed styles and can see situations where each would be appropriate.  The problem I seem to have is that, for me, the selection of an architectural styles seems to depend on which aspect of the system I’m considering. 

While data does underlie the whole system, there is still much more to consider.  So on the other side of it;I think there would still be the need for a top-down approach.  Basically this approach would be aimed at designing the system from the perspective of process.  This would involve breaking the system down into subsystems and further into even smaller components.  The system could be divided into three main subsystems, these being sales, inventory, and payroll.  An important task would be clearly defining the logical boundaries between these subsystems, defining what they are responsible for, as well as defining the necessary communications between them.  This would be the first step in decomposing the overall system into more manageable pieces.  Beyond this, each subsystem could be further decomposed into various components.  Again, it would also be necessary to define the communications between these components, what they should do, and even how they should do it.  (I think the general idea would be to refine each component’s process down to the point where it could basically be expressed as pseudo-code.) From a purely logical standpoint, all of this decomposition allows for problems to be broken down into smaller, more manageable problems.  Dealing with a series of smaller problems will typically prove much less cumbersome a more streamlined than trying to deal with a larger, more complex one.  Beyond this, decomposing a system into smaller pieces during design will also provide for a more manageable system in terms of testing and maintenance down the line.  In the end, I guess the overall approach would use would be more of a meet-in-the-middle approach.

Another important aspect of the design phase would be the design of various interfaces.  These would include interfaces between system components (either between components within a subsystem or between subsystems themselves), between the system and external systems, and between the system and its users.  These interfaces would provide the conduit for the necessary internal and external communications mentioned above.  Basically, these interfaces would be used to link the various system components together.  External and system interfaces would mainly be concerned with the technical details necessary for facilitating interactions.  On the other hand, other additional factors would have to be considered when designing the user interfaces.  This would be due to the “human” element.  The end users would have to be taken into account when designing the user interface.  No matter how well designed a system is, a poorly designed user interface could still spell failure for a system.  The overall goal would be for a simple, intuitive, user-friendly interface.  Additionally, leaving as little to chance as possible would also be a good idea.  In other words, try to limit the potential mistakes end users can make and make sure the system responds appropriately when user mistakes are made.