At university we have learned that the complexity of algorithms is measured by the amount of "processing time" it takes to solve a given problem depending on the number of input values, e.g.:
- O(c) means that to solve a specific problem always needs the same time independent of the input. Example: a constant function that always returns 42.
- O(N) means that the processing time reveals liner increase with the input dimensions.
- O(log N): time for searching an element in a sorted field.
- O(N log N): time to sort an unsorted field of N values.
We know that if we can map a given problem in constant time to let's say a sorting problem, and vice versa, then the problem will also have O(N log N) complexity. However, this kind of complexity is not that significant for software architecture design, is it? At least, we start to assume that there might be differend kinds of complexity.
In the old latin language complexity was defined as the total set of possibilities and capabilities. Thus, we can draw the conclusion that a software architecture is complex if it reveals a large set of properties and capabilities.
An appropriate way to get a gut feeling for software architecture complexity is to ask the following question: What are typical implications when a software architecture IS complex?
Static Structure:
- The architecture consists of a whole ocean of entities with lots of different relationships
- It typically comprises insufficient or confusing abstractions
- There is no clear separation of concerns. For instance, some entities are overloaded with various unrelated responsibilities, a point that is is often tightly related to the previous issue
Dynamics:
- There are lot of possible workflows
- The system contains many states and transitions
As you surely know the old saying is that software architecture and organization are only two sides of the same coin. Complexity of architecture may thus be caused by your organization:
- No clear team responsibilities and role assignments
- Insufficient or missing process
- High level of political issues in daily work
- Documentation-addiction
- Missing doucumentation
- Insufficient amount of time dedicated to architecture design
- No supervision of architecture realization
- Lack of adequate testing
- No sufficient team education upfront
In summary, complexity in software architecture is mainly caused by missing or overused abstractions and inadequate separation of concerns in either static structure or dynamics. Or in other words, the RUP 4+1 view helps us to structure complexity in different (4+1) areas. In addition, inadequate processes, tools, education, and organizational issues inevitably cause software architecture complexity.
Good means to prevent complexity are manifold:
- software patterns
- usage of frameworks and containers
- aspect-oriented programming if done right
- model-based software development if done right
- higher abstraction by introducing domains specific languages and domain modelling
- metrics if applied right
- usage of appropriate methods and tools
- requirements traceability
- ...
All of these means help to obtain appropriate abstractions, and mapping of responsibilities to entities. Note, that humans are normally only capable of processing 8 entities at the same time. Hence, this point should be taken into account on each abstraction layer and for each architectural perspective.
But that's only my 2c.
I am wondering what your opinions are w.r.t. complexity? Any complexity definition that makes sense?
2 comments:
Michael, do keep in mind that when discussing complexity, in general we talk about average completion time, not minimal completion time as you stated. Particularly when using O(n) type notation. Many routines have both worst-case and best-case outliers.
Yes, you are absolutely right. My description is not exact enough. Another issue could be. If e.g. a list is already sorted, a sorter would be able to run in O(n)
Post a Comment