What are the lessons learnt by you from studying the accessibility pattern [17,8]. 1.1 INTRODUCTION Developing software

What are the lessons learnt by you from studying the accessibility pattern [1–7,8].

Transcribed Image Text:

1.1 INTRODUCTION Developing software systems involves several activities, starting from domain and requirement analysis to system implementation and deployment [1-7]. Numerous requirements, techniques, and object-oriented design methods that are widely used in industry, start invariably with the develop- ment of a domain model that captures the core concepts in the domain [8]. Developing domain models, however, requires domain knowledge and modeling skills. But domain experts and analysts may have limited access to skill and knowledge, faced with under-tied "time-to-market" constraints and restricted by condensed budgets. It has been long realized that software systems do share many requirements. For example, in a health-care system and an e-commerce infrastructure, there is a common need for techniques to attain "Information Privacy" in order to protect user information. At a conceptual level, the concept of "Privacy" does not change in both systems, although, realizing privacy at the implementation level is likely to be different in both systems. Nonetheless, conceptual modeling can greatly benefit from capturing commonly recurring problems at a reusable, yet meaningful abstraction level. Software community has long realized the advantage of reuse [1,2], which is evident by the emergence of several reuse communities over the last few decades. Among these communities is the patterns community that advocates reuse by extracting and documenting solutions of recurring problems throughout the different phases of software development, for example, design (design patterns) and analysis (analysis patterns). In this book, we will focus on the important topic of analysis patterns. Analysis patterns are known to shape the knowledge of the problem domain. They support developers in understanding the underlying problem, rather than showing how to design a solution. (Please refer to Sidebar 1.2 on Common Stable Design Patterns for creating stable analysis patterns.)