Devops for Growth

The Pros and Cons of Agile Modeling

The modeling brings advantages and disadvantages to the table.

Advantages

• Facilitates effective communication between teams and clients
• Enhances project flexibility, easily handling sudden changes anytime
• Cuts overall development time
• Increases customer satisfaction via rapid, continuous delivery of a workable product
• Delivers functioning software frequently, in weeks instead of months

Disadvantages

• Confusion between teams may develop because documentation wasn’t emphasized. This uncertainty can lead to difficult transitions between phases.
• It is sometimes difficult to gauge how much effort will be needed to start the development life cycle of larger software deliverables.
• If stakeholders project ladder are not on the same page, the project will derail.
• The modeling isn’t for newbies. The sort of decisions involved in Agile require people with experience and solid developer and programming skills.           

Robustness diagram

Robustness diagrams allow to visually represent the relation between entities, controls, boundaries and actors.[4] It uses graphical stereotypes introduced in Jacobson's early work:  

The following robustness contraint apply: 

• Actors may only know and communicate with boundaries
• Boundaries may communicate with actors and controls only.
• Controls may know and communicate with boundaries and entities, and if needed other controls
• Entities may only know about other entities but could communicate also with controls;

In principle entities should not know about boundaries and controls. In practice however, some variants allow entities, boundaries and controls to subscribe as observer to an entity.

Similarly, the constraint of a boundary class not knowing about another boundary classes only applies at the highest level, and not between classes that cooperate to implement the same boundary.

Relation to other architectural patterns

There is some similarity between ECB and Model-view-controller (MVC): entities belong to the model, and views belongs to boundaries.  However the role of the ECB-control is very different from MVC-controller, since it encapsulates also use-case business logic whereas the MVC controller processes user input which would be of the responsibility of the boundary in ECB.  The ECB control increases separation of concerns in the architecture by encapsulating business logic that is not directly related to an entity.[2]  

The ECB can be used in conjunction with the hexagonal architecture, whenever the boundaries form the outer adapte layer.[10]  

ECB is  compatible with the clean architecture which merges ECB principles with other architectural design[11],.[12]  Clean architecture places entities at the core, and surround them with a use-case ring (i.e. ECB control) and a ring with gateways and presenters (i.e. ECB boundaries).  However, clean architecture requires a one-way dependency from outside to inside, which requires to split ECB controls into use-case logic and object coordination.