Master Preliminary Design with Robust Graphs: 10 Proven Tips
This article outlines the ADMEMS approach’s ten essential guidelines for robust graph modeling, covering rules, simplified syntax, discovery of responsibilities, incremental modeling, and practical tips to avoid over‑detailing, helping designers create clear preliminary designs for complex systems.
The ADMEMS method summarizes ten experience points for robust‑graph modeling, covering syntax, mindset, techniques, and precautions across four aspects.
Follow modeling rules. The following four statements capture the essence of the graph:
1.1 Participants can only talk to boundary objects.
1.2 Boundary objects can talk to control objects and participants.
1.3 Entity objects can only talk to control objects.
1.4 Control objects can talk to boundary objects and other control objects, but not to participants.
Simplify modeling syntax. ADMEMS recommends a concise robust‑graph syntax; a simplified syntax lets designers focus on preliminary design rather than low‑level details.
Adopt a three‑element discovery approach. Identify participants, boundary objects, and control objects based on use‑case scenarios.
Incremental modeling. Example: designing the compression feature of tools like WinZip/WinRar.
Identify the most obvious responsibilities (e.g., reading source files, creating a compressed package).
Consider relationships and discover new responsibilities (e.g., a packer delegated by the compressor).
Introduce additional elements such as compression configuration that influences the compressor’s behavior.
Draw robust graphs only for key functionalities (use cases). Not every feature requires a graph; focus on critical requirements.
Limit each robust graph to 2‑5 control objects. Fewer control objects keep the design clear; a single control object often indicates insufficient responsibility separation.
Avoid excessive detail. Do not label every object’s attributes or methods, ignore UI specifics, persistence choices, or strict control‑flow ordering in the preliminary stage.
Do not over‑focus on UI. UI details are only relevant when they assist or validate the design.
Remember the goal. Preliminary design aims to discover responsibilities; avoid delving into detailed architecture, which adds unnecessary “baggage” at the start of complex system design.
Source: CSDN article
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
ITFLY8 Architecture Home
ITFLY8 Architecture Home - focused on architecture knowledge sharing and exchange, covering project management and product design. Includes large-scale distributed website architecture (high performance, high availability, caching, message queues...), design patterns, architecture patterns, big data, project management (SCRUM, PMP, Prince2), product design, and more.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
