ICONIX as an object-oriented, agile software design process using UML notation

The fact that ICONIX, as a process, is relatively rarely used (this has been changing over the last few years, however), is rooted in the fact that, first and foremost, it requires an understanding of the component-oriented architecture process, it also requires knowledge and understanding of the concept of hexagonal architecture and the associated MVC pattern. Requires knowledge and understanding of many other object-oriented design patterns, requires, above all, abstract thinking and modelling (UML) skills. It requires an understanding that z coding must be preceded by design, because ‘designing’ in code is the least effective form of design (Börger, 2018).The process is also supported by the division into analysis and design and implementation stages (see above diagram: Structure of project roles and products in the ICONIX process). ICONIX is sometimes wrongly associated with a “heavy” software development process such as the Rational Unified Process (which I have hardly written about on my blog). The reason ICONIX is rarely used, is also that, unfortunately, the world was, already in the 1990s, heavily “spoiled” by C++ and Java (architectures built on cascades of inheritance). These are often heavy, monolithic frameworks based on a relational data model, where there is no strict separation between domain logic and environment (MVC). Java is still one of the most costly and least effective application development methods. The EJB framework is to this day described as the source of an object-oriented design anti-pattern called the ‘anemic domain model’. However, the growing developer interest in the C4 model over the last few years shows that analysis and modelling are needed and quietly entering through the back door….The fact that ICONIX, as a process, is relatively rarely used (this has been changing over the last few years, however), is rooted in the fact that, first and foremost, it requires an understanding of the component-oriented architecture process, it also requires knowledge and understanding of the concept of hexagonal architecture and the associated MVC pattern. Requires knowledge and understanding of many other object-oriented design patterns, requires, above all, abstract thinking and modelling (UML) skills. It requires an understanding that z coding must be preceded by design, because ‘designing’ in code is the least effective form of design (Börger, 2018).The process is also supported by the division into analysis and design and implementation stages (see above diagram: Structure of project roles and products in the ICONIX process). ICONIX is sometimes wrongly associated with a “heavy” software development process such as the Rational Unified Process (which I have hardly written about on my blog). The reason ICONIX is rarely used, is also that, unfortunately, the world was, already in the 1990s, heavily “spoiled” by C++ and Java (architectures built on cascades of inheritance). These are often heavy, monolithic frameworks based on a relational data model, where there is no strict separation between domain logic and environment (MVC). Java is still one of the most costly and least effective application development methods. The EJB framework is to this day described as the source of an object-oriented design anti-pattern called the ‘anemic domain model’. However, the growing developer interest in the C4 model over the last few years shows that analysis and modelling are needed and quietly entering through the back door….

Source: ICONIX jako obiektowo zorientowany, zwinny proces projektowania oprogramowania z użyciem notacji UML – Jarosław Żeliński IT-Consulting