Article Preview
TopIntroduction
Conventional information system (IS) analysis and design methods are restricted in their ability to distinguish among crosscutting concerns, which span across various types of diagrams. It does not matter whether designers apply structured analysis and design (SAD) methods (Gane & Sarson, 1979; Yourdon & Constantine, 1979), object-oriented (Blaha & Rumbaugh, 2005) or component based methods: their expressive power is limited in separating various concerns. Poor concern separation technique is one of the reasons why the way systems are currently built is rather primitive. Consequently, managing the complexity of specifications in software engineering is a problem that can be certainly attributed to various limitations of traditional IS modeling and design methods. The following software engineering issues have remained problematic over the last three decades (Jones, 2009):
- •
There are more defects in requirements and design than in source code,
- •
Initial requirements are seldom more than 50% complete,
- •
There are more defects in test cases than in software itself,
- •
About 7% of all defect repairs will accidentally inject new defects,
- •
About 5% of software outsource contracts end up in litigation.
In traditional areas of engineering, developers are able to present their design decisions by using a finalized computation-neutral representation. This is not the case in the area of system engineering. The limitations of conventional system modeling methods result in two side effects, which in aspect-oriented software development (Jacobson & Ng, 2005) are known as tangling and scattering. Tangling occurs when the software component or class, instead of fulfilling a particular concern, encapsulates a diverse set of concerns. If a particular concern is spread across multiple components, then this situation is called scattering. When the requirements implied by that concern are modified, the designer must identify all related components and find out how these components are affected by introduced changes. Especially, modifying requirements, which are related to a big number of diagrams, becomes quite problematic. Poor understanding of concerns makes it difficult to make even simple evolutionary extensions of IS specifications. Separation of crosscutting concerns is the first fundamental problem, which cannot be solved without modifying the modeling foundation in system analysis and design. In this paper, we will introduce system decomposition principles, which suggest a new and more natural way of managing complexity in system engineering.