Reflecting on the activities in Assignment 4, I found the process both challenging and rewarding.
Developing the design class diagram, sequence diagrams, and a multilayer design, along with
adding detailed method signatures, was more complex than I initially expected. The deeper I got
into the tasks, the more I realized how much precision and attention to detail was required.
What was easy and what was difficult?
The first steps, like creating the first-cut design class diagram, felt more manageable. Identifying
the key classes, their attributes and relationships came naturally because I was able to build on
the system requirements and examples I’d seen before. But things got tricky when I had to ensure
everything followed UML conventions—such as adding method signatures, visibility indicators, and
navigation arrows. Sequence diagrams, especially, required a lot of thought. Mapping out the exact
flow of messages between the boundary, control, and entity classes pushed me to fully understand
the use case. At times, keeping the diagrams clear without being too simplistic was a real
balancing act.
Problems and solutions
One of the main struggles was keeping the diagrams both accurate and understandable. Adding
too much detail made the diagrams overwhelming, while leaving out key components risked losing
clarity. To solve this, I broke things into smaller steps, starting with a rough sketch of the big picture
before refining it piece by piece. It also helped to check my diagrams against guidelines and
examples—sometimes stepping back and getting peer feedback was the best way to spot areas for
improvement.
I also initially questioned why so many diagrams were needed. Why not just stick to one? But as I
worked, I realized that each diagram serves a unique purpose. Class diagrams show the system’s
static structure, while sequence diagrams bring the dynamic interactions to life. The multilayer
design, on the other hand, helps connect the conceptual structure to practical implementation.
Together, they give a full view of the system from different perspectives, which is essential for clear
communication with developers and other stakeholders.
Insights:
One approach that really worked for me was tackling the diagrams step by step. For example, when
working on the sequence diagrams, I first jotted down the main interactions on paper. This made it
easier to focus on one thing at a time, without getting overwhelmed by the software tools or
formatting.
Where I struggled:
Aligning all the diagrams was challenging. Small updates to the class diagram, for example, often
meant reworking parts of the sequence diagram. This interdependence was frustrating at first but
taught me an important lesson: system design is inherently iterative. You don’t get it perfect on the
first try—it’s a process of refining and improving as you go.
Final thoughts:
Overall, this assignment showed me the importance of being thorough, organized, and willing to
revise my work. I now have a much better appreciation for why system analysts use multiple
diagrams to develop and communicate a design effectively. These tools document the system and
make it easier to identify gaps, refine solutions, and collaborate with others.
References
Dennis, A., Wixom, B. H., & Roth, R. M. (2018). Systems Analysis and Design (7th ed.). Wiley.
Fowler, M. (2004). UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd ed.).
Addison-Wesley