One of the most important issues when starting a new project is the differentiation between those parts that are in the software system and those which are external. We need to specify clear boundaries between the system going to be built and its environment. This is an issue developers often neglect. One of the obvious implications of not considering boundaries are misunderstandings during the design and architecture modelling phase. Are these boundaries simply a consequence of the underlying domain? Not at all! If we are going to create a Web Shop, the order processing subsystem is definitely an important concept of the domain. However, we could either introduce our plain-vanilla, homegrown order processing subsystem or just integrate an existing system such as SAP R/3 to provide the same service. In other words, first we need to consider which services are required, then we need to decide whether we will build these services as part of our software system or just (re-)use other external services for the same purpose.
How to proceed: I am a big fan of component-based design. I just consider components to be independent artifacts (i.e., modular units of testing, deployment, implementation, modularization,...) providing services to their environment (services may be functionality or events or configuration interfaces) and consuming services from their environment (such as functionality or events). Note: components can aggregate other components. I will design all subsystems including the whole system itself using this component concept. Hence, I need to define which interfaces my system will provide to its environment and which it will need to obtain. For example, one typical required interface of a Web Shop is access to a credit card company to verify customer credibility.
When designing such context diagrams the obvious choice is to leverage UML component diagrams.
2 comments:
Defining the boundaries of an system is an important step in order to tame complexity and to structure the architecture. My experience (and advice): it should be stated clearly in the documentation what is covered and what is not part of the system. Anyhow, corresponding systems might have impact on the software we are about to design. This is a different topic but it should be mentioned in this context. Components and/or services (depending on the view) should facilitate options to measure and adjust this impact. Services are a great approach to deliver quality attributes (e.g.: performance) for designated functionalities.
Yes, that's is definitely right. I always demand projects to include a context view in their documentation. For example, integration into external systems and interoperability with external systems are important topics that need to be addressed. Another point you brought up is of imminent relevance. The boundaries are not only essential for functional separation but also for non-functional issues. Example: If I need to guarantee a response time of 1 msec and another external system is part of processing then this system has a clear impact on my operational quality. All those dependencies and implications should be part of the considerations and thus of the documentation.
Post a Comment