This chapter enables the learners to envisage the prevailing glitches of concern in programming and enables them to identify the concerns that may be incurred in the development of the software. How the designing phase of the product is molded separates these concerns from the core business logic, thereby providing a product with an ability to incorporate any change without actually touching the core business logic unless necessary. Moreover, creating a good design leads to less rework in the latter stages of the SDLC (Software Development Life Cycle).
TopIntroduction
Success at developing simpler systems leads to aspirations for greater complexity. Managing complex software system is one of the most important problems for software engineering to handle. Increase in the complexity of the software requirements and the initiation of innovative technology makes it indispensable for software packages to integrate and accommodate the countless assortments of special concerns which primarily include concurrency, distribution, real-time constraints, location control, persistence, and failure recovery. Hiding among these special purpose concerns is the core concern responsible for the fundamental business logic. These non-functional concerns help in either fulfilling special requests of the application (real-time, persistence, distribution), or to manage and to optimize the core business logic (location control, concurrency).
Even though the concerns may be separated conceptually and incorporated correctly, interspersing them in the code brings about a number of problems:
- •
Interpreting and maintaining a tangled code is rigid and multifaceted as all the concerns have to be maintained at the same time and at the same level due to very strong coupling among them.
- •
Tangled code is hard to understand because of the lack of abstraction as depicted in the above point.
Also in systems designed using OOPs concepts, tangled code gives rise to inheritance incongruities as it becomes impossible to re-factorize a method or a concern without re-factorizing both, which again is the byproduct of strong coupling of different concerns.
Modeling is considered to be one of the most successful elements in the progression of computer systems expansion. It is the process of representing real-world concepts in the computer domains as a blueprint for the purpose of software development. Recent trends in software development have also revealed the value of developing systems at higher levels of abstraction.
The significance of modeling and abstraction becomes further strengthened in the process of Model Driven Software Engineering (MDSE) (Bran Selic, 2003), where they are considered the heart and soul of software development.
The core objective of this chapter is to enable the learners to visualize the above mentioned glitches in the vastly followed OOP practice. A better understanding on the concept of concerns will allow the learners to separate out the concerns from the core logic while developing a software product in the initial phase itself so that the glitches are not transferred to the latter phases which in turn will lead to less rework in the latter stages of the SDLC.
TopBackground
Aspects Case
Jacobson (2003) describes how the design aspects can be developed using use cases. It uses the concept of composition techniques that maps the work directly into the program level aspects. The proposed work does not provide details about models transformations, composition rules, structural relations, etc.