I.

Introduction
Socks-or-Sandals, or SoS, is a digital wardrobe management application that allows users
to create a virtual wardrobe populated with items he or she owns or would like to own so that
the user can mix-and-match outfits manually, or have outfits suggested based on calendar events
and local weather conditions. The following class diagram for the SoS system was based off of
the domain model found in Appendix B. It diagrams the core wardrobe functionality since the
additional tasks will be handled through the use of as-yet undetermined APIs, making it difficult
to model their integration. It stands to reason that, given an Agile development environment, the
diagram can be updated once it becomes clearer which APIs will be used and how their
integration will be handled.
II. The Class Diagram Larger view in Appendix A

II. Write-Up
There is considerable difference between SoSs domain model and its class diagram,
largely because the exposure to the GRASP patterns revealed that the domain model was poorly
designed indeed with high coupling, low cohesion, and no real controllers or designated creators.
The result is a class diagram that shares some class names with the domain model but little
beyond that.
A fair amount of pure fabrication took place with many of the classes in the class
diagram having no analog in the domain model. For instance, the class diagram shows the
abstract factory, factory, and prototype classes from which the objects users will interact with are
derived. The new controller class is another such fabricated class, but all of the aforementioned
are crucial to maintaining a modular design, something the domain model did not have,
regardless of whether or not it was supposed to.
The class diagram features highly focused classes with only one or two functions that
they are dedicated to carrying out. Additionally, each class knows about and relies on other
classes only to the extent that is absolutely necessary. Granted, certain classes and their
interactions are subject to change as the system becomes more developed.
For example, creator patterns and their related classes were chosen based on the type of
classes that needed to be made, but the premium and basic wardrobe classes are largely empty,
having not yet been thoroughly defined. Account objects are largely data objects which will be
virtually identical across the board, and since all the differences experienced by premium users
will be experienced either in the wardrobe or in the dashboard, it seemed only natural to create
accounts identically and allow for differences in the creation of the classes where the differences
present themselves.

After more development, however, it may become evident that the features that set apart
the basic experience from its premium counterpart may not be extensive enough to warrant their
separation into two completely different classes which would make an abstract factory class
unnecessary and another creator pattern more suitable. There are situations with most of the
classes in the diagram since theyve all been created with the understanding that flexibility at this
stage is key.
Consequently, only a few of the classes in the current design will produce objects directly
interacted with by users: the AccountController, the Account, the Wardrobe (basic or premium),
the Dashboard (basic or premium), and the Wardrobe Item, which is really just a class of object
references. All other interactions are indirected, tasked with either creating the aforementioned
classes or acting as an intermediary between them. This was done to make the components easily
swappable by promoting indirection and high cohesion.
III. Conclusion
All in all, the above class diagram makes an appropriate addition to the collection of
Elaboration Phase artifacts for SoS. There are still many questions to answer about the project,
and as development occurs, the structure of the system is likely to change. Nevertheless, the
diagram does its job of laying the beginnings of a much needed foundation as the team starts to
write code. It is an important step toward bringing the system off the page and into reality.

Appendix A

Appendix B