Hi, folks.
I am fairly new to UML and even more so to design methodologies, such as the Unified Process. However, I am versed on object-oriented design realized through object-orient programming. In other words, I’m more of a programmer than a software engineer. As such, I’ve decided to learn UML in earnest and use it to apply various design methodologies, and my first real attempt is to design a CD catalog application to track one’s CD collection. It’s meant to be a simple, single-user application. Therefore, I will deliberately forego any business modeling, as it is beyond the scope of this application.
On the first pass, I began to define use cases but then realized my thinking was steered toward use case models that “looked” like classes. I scrapped that idea. On the second pass, I documented a requirements model first. This was helpful, since I was able to describe the system without thinking about implementation.
Now, I realize a full requirements model includes both functional and non-functional requirements. However, I have thus far focused only on functional requirements, and here is why. In the spirit of the Unified Process, I don’t want to bite off more than I can chew. I’m thinking that I should being with an iterative approach to an architectural solution in small steps. Therefore, after I defined most of the functional requirements (at least the important core requirements), I began building a use case model that traced to these requirements. For each use case, I provided a short description, external requirements (traced back to the functional requirements), constraints with pre-, post- and invariant conditions, and scenarios.
So far, so good. Next I started on creating sequence diagrams for each scenario of each use case. For the diagrams I created so far, I used elements stereotyped as “boundary”, “control” and “entity”, and I did this for two reasons. First, they seem effective in abstractly representing a class, and this was necessary for me since I have not yet designed any classes. However, with the aforementioned elements and the messages passed between them, one begins to draw a mental picture of the classes required by the system. My second reason for using these stereotyped elements, is that they correlate to the MVC design pattern, where a “boundary” element maps to a “view”, a “control” element maps to a “controller”, and an “entity” element maps to a “model”. In my application, I will make extensive use of the MVC design pattern.
Now, I have nearly reached a point of uncertainty in what to do next. My goal is to design the system as abstractly as possible, so I don’t enter into “programmer” mode to early and miss good design opportunities.
I’d appreciate some feedback that speaks to this issue. First, is my approach thus far practical? I know implementing UML is still very open-ended, but I would imagine some practical guidelines have surfaced, at least in the area of object-oriented software development using UML. Second, if my approach is practical what would be the best place to continue designing my application solution? For example, I suspect state machine diagrams will come in very handy, except I wonder if sequence diagrams alone are sufficient to begin class modeling.
Finally, although my target language is C++, I’d still like to design a Platform Independent Model first. This will provide me the flexibility of porting the classes to different languages in the form of Platform Specific Models, using a model-driven architecture.
Thanks for reading my post. I look forward to learning from your considered responses.
