scispace - formally typeset
Search or ask a question
Author

Alan Wills

Bio: Alan Wills is an academic researcher. The author has contributed to research in topics: Proxy pattern & Module pattern. The author has an hindex of 2, co-authored 3 publications receiving 1143 citations.

Papers
More filters
Book
01 Oct 1998
TL;DR: This chapter discusses Model Frameworks as Templates, a model framework for component-based development, and its applications in architecture, management, and user experience.
Abstract: Preface. I. OVERVIEW. 1. A Tour of Catalysis. Objects and Actions. Refinement: Objects and Actions at Different Scales. Development Layers. Business Modeling. Model Frameworks as Templates. Zooming In on the Software: System Context. Requirements Specification Models. Components. Assigning Responsibilities. Object-Oriented Design. The Development Process. Three Constructs Plus Frameworks. Three Levels of Modeling. Three Principles. Summary. II. MODELING WITH OBJECTS. 2. Static Models: Object Attributes and Invariants. What Is a Static Model? Object State: Objects and Attributes. Implementations of Object State. Modeling Object State: Types, Attributes, and Associations. Static Invariants. The Dictionary. Models of Business Models of Components. Static Models: Summary. 3. Behavior Models: Object Types and Operations. Object Behavior: Objects and Actions. More Precise Action Specifications. Two Java Implementations of a Calendar. Type Specification of Calendar. Actions with Invariants. Interpreting an Action Specification. Subtypes and Type Extension. Factoring Action Specifications. State Charts. Outputs of Actions. Subjective Model: The Meaning of Containment. Type Specifications: Summary. Programming Language: Classes and Types. 4. Interaction Models: Use Cases, Actions, and Collaborations. Designing Object Collaborations. Actions (Use Cases) Abstract Complex Interactions. Use Cases Are Joint Actions. Actions and Effects. Concurrent Actions. Collaborations. Uses of Collaborations. Collaboration Specification. Collaborations: Summary. 5. Effective Documentation. What's It All For? Documentation Is Easy and Fun, and It Speeds Design. Reaching the Documentation Audience. The Main Documents: Specification and Implementation. Documenting Business Models. Documenting Component Specifications. Documenting Component Implementations. Summary. III. FACTORING MODELS AND DESIGNS. 6. Abstraction, Refinement, and Testing. Zooming In and Out: Why Abstract and Refine? Documenting Refinement and Conformance. Spreadsheet: A Refinement Example. Spreadsheet: Model Refinement. Spreadsheet: Action Refinement. Spreadsheet: Object Refinement. Spreadsheet: Operation Refinement. Refinement of State Charts. Summary. Process Patterns for Refinement. Pattern 6.1 The OO Golden Rule (Seamlessness or Continuity). Pattern 6.2 The Golden Rule versus Other Optimizations. Pattern 6.3 Orthogonal Abstractions and Refinement. Pattern 6.4 Refinement Is a Relation, Not a Sequence. Pattern 6.5 Recursive Refinement. 7. Using Packages. What Is a Package? Package Imports. How to Use Packages and Imports. Decoupling with Packages. Nested Packages. Encapsulation with Packages. Multiple Imports and Name Conflicts. Publication, Version Control, and Builds. Programming Language Packages. Summary. 8. Composing Models and Specifications. Sticking Pieces Together. Joining and Subtyping. Combining Packages and Their Definitions. Action Exceptions and Composing Specs. Summary. 9. Model Frameworks and Template Packages. Model Framework Overview. Model Frameworks of Types and Attributes. Collaboration Frameworks. Refining Frameworks. Composing Frameworks. Templates as Packages of Properties. Templates for Equality and Copying. Package Semantics. Down to Basics with Templates. Summary of Model Framework Concepts. IV. IMPLEMENTATION BY ASSEMBLY. 10. Components and Connectors. Overview of Component-Based Development. The Evolution of Components. Building Components with Java. Components with COM+. Components with CORBA. Component Kit: Pluggable Components Library. Component Architecture. Defining Cat One-A Component Architecture. Specifying Cat One Components. Connecting Cat One Components. Heterogeneous Components. Pattern 10.1 Extracting Generic Code Components. Pattern 10.2 Componentware Management. Pattern 10.3 Build Models from Frameworks. Pattern 10.4 Plug Conformance. Pattern 10.5 Using Legacy or Third-Party Components. Summary. 11. Reuse and Pluggable Design Frameworks in Code. Reuse and the Development Process. Generic Components and Plug-Points. The Framework Approach to Code Reuse. Frameworks: Specs to Code. Basic Plug Technology. Summary. Pattern 11.1 Role Delegation. Pattern 11.2 Pluggable Roles. 12. Architecture. What Is Architecture? Why Architect? Architecture Evaluation with Scenarios. Architecture Builds on Defined Elements. Architecture Uses Consistent Patterns. Application versus Technical Architecture. Typical Four-Tier Business Architecture. User Interfaces. Objects and Databases. Summary. V. HOW TO APPLY CATALYSIS. 13. Process Overview. Model, Design, Implement, and Test-Recursively. General Notes on the Process. Typical Project Evolution. Typical Package Structure. Main Process Patterns. Pattern 13.1 Object Development from Scratch. Pattern 13.2 Reengineering. Pattern 13.3 Short-Cycle Development. Pattern 13.4 Parallel Work. 14. How to Build a Business Model. Business Modeling Process Patterns. Pattern 14.1 Business Process Improvement. Pattern 14.2 Make a Business Model. Pattern 14.3 Represent Business Vocabulary and Rules. Pattern 14.4 Involve Business Experts. Pattern 14.5 Creating a Common Business Model. Pattern 14.6 Choose a Level of Abstraction. Modeling Patterns. Pattern 14.7 The Type Model Is a Glossary. Pattern 14.8 Separation of Concepts: Normalization. Pattern 14.9 Items and Descriptors. Pattern 14.10 Generalize and Specialize. Pattern 14.11 Recursive Composite. Pattern 14.12 Invariants from Association Loops. Video Case Study: Abstract Business Model. Video Business: Use Case Refinement. Pattern 14.13 Action Reification. 15. How to Specify a Component. Patterns for Specifying Components. Pattern 15.1 Specify Components. Pattern 15.2 Bridge Requirements and Specifications. Pattern 15.3 Use-Case-Led System Specification. Pattern 15.4 Recursive Decomposition: Divide and Conquer. Pattern 15.5 Make a Context Model with Use Cases. Pattern 15.6 Storyboards. Pattern 15.7 Construct a System Behavior Spec. Pattern 15.8 Specifying a System Action. Pattern 15.9 Using State Charts in System Type Models. Pattern 15.10 Specify Component Views. Pattern 15.11 Compose Component Views. Pattern 15.12 Avoid Miracles, Refine the Spec. Pattern 15.13 Interpreting Models for Clients. Video Case Study: System Specifications. System Context Diagram. System Specification. Using Model Frameworks. 16. How to Implement a Component. Designing to Meet a Specification. Pattern 16.1 Decoupling. Pattern 16.2 High-Level Component Design. Pattern 16.3 Reifying Major Concurrent Use Cases. Pattern 16.4 Separating Facades. Pattern 16.5 Platform Independence. Pattern 16.6 Separate Middleware from Business Components. Pattern 16.7 Implement Technical Architecture. Pattern 16.8 Basic Design. Pattern 16.9 Generalize after Basic Design. Pattern 16.10 Collaborations and Responsibilities. Pattern 16.11 Link and Attribute Ownership. Pattern 16.12 Object Locality and Link Implementation. Pattern 16.13 Optimization. Detailed Design Patterns. Pattern 16.14 Two-Way Link. Pattern 16.15 Role Decoupling. Pattern 16.16 Factories. Pattern 16.17 Observer. Pattern 16.18 Plug-Points and Plug-Ins. Video Case Study: Component-Based Design. Appendix A: Object Constraint Language. Appendix B: UML Perspective. Appendix C: Catalysis Support Tools, Services, and Experiences. Notes. Glossary. Index. 0201310120T04062001

1,129 citations

Book ChapterDOI
18 Dec 1998

1 citations


Cited by
More filters
Book ChapterDOI
Stuart Kent1
15 May 2002
TL;DR: The Object Management Group's (OMG) Model Driven Architecture (MDA) strategy envisages a world where models play a more direct role in software production, being amenable to manipulation and transformation by machine as mentioned in this paper.
Abstract: The Object Management Group's (OMG) Model Driven Architecture (MDA) strategy envisages a world where models play a more direct role in software production, being amenable to manipulation and transformation by machine. Model Driven Engineering (MDE) is wider in scope than MDA. MDE combines process and analysis with architecture. This article sets out a framework for model driven engineering, which can be used as a point of reference for activity in this area. It proposes an organisation of the modelling 'space' and how to locate models in that space. It discusses different kinds of mappings between models. It explains why process and architecture are tightly connected. It discusses the importance and nature of tools. It identifies the need for defining families of languages and transformations, and for developing techniques for generating/configuring tools from such definitions. It concludes with a call to align metamodelling with formal language engineering techniques.

1,693 citations

Journal Article
TL;DR: A framework for model driven engineering is set out, which proposes an organisation of the modelling 'space' and how to locate models in that space, and identifies the need for defining families of languages and transformations, and for developing techniques for generating/configuring tools from such definitions.
Abstract: The Object Management Group's (OMG) Model Driven Architecture (MDA) strategy envisages a world where models play a more direct role in software production, being amenable to manipulation and transformation by machine. Model Driven Engineering (MDE) is wider in scope than MDA. MDE combines process and analysis with architecture. This article sets out a framework for model driven engineering, which can be used as a point of reference for activity in this area. It proposes an organisation of the modelling 'space' and how to locate models in that space. It discusses different kinds of mappings between models. It explains why process and architecture are tightly connected. It discusses the importance and nature of tools. It identifies the need for defining families of languages and transformations, and for developing techniques for generating/configuring tools from such definitions. It concludes with a call to align metamodelling with formal language engineering techniques.

1,476 citations

Proceedings ArticleDOI
16 May 1999
TL;DR: A new paradigm for modeling and implementing software artifacts is described, one that permits separation of overlapping concerns along multiple dimensions of composition and decomposition, which addresses numerous problems throughout the software lifecycle.
Abstract: Done well, separation of concerns can provide many software engineering benefits, including reduced complexity, improved reusability, and simpler evolution. The choice of boundaries for separate concerns depends on both requirements on the system and on the kind(s) of decomposition and composition a given formalism supports. The predominant methodologies and formalisms available, however, support only orthogonal separations of concerns, along single dimensions of composition and decomposition. These characteristics lead to a number of well-known and difficult problems. The paper describes a new paradigm for modeling and implementing software artifacts, one that permits separation of overlapping concerns along multiple dimensions of composition and decomposition. This approach addresses numerous problems throughout the software lifecycle in achieving well-engineered, evolvable, flexible software artifacts and traceability across artifacts.

1,452 citations

Journal ArticleDOI
TL;DR: This paper presents the Alloy language in its entirety, and explains its motivation, contributions and deficiencies.
Abstract: Alloy is a little language for describing structural properties. It offers a declaration syntax compatible with graphical object models, and a set-based formula syntax powerful enough to express complex constraints and yet amenable to a fully automatic semantic analysis. Its meaning is given by translation to an even smaller (formally defined) kernel. This paper presents the language in its entirety, and explains its motivation, contributions and deficiencies.

1,280 citations

Book
01 Jan 2004
TL;DR: The confluence of component based development, model driven development and software product lines forms an approach to application development based on the concept of software factories, which promises greater gains in productivity and predictability than those produced by incremental improvements to the current paradigm of object orientation.
Abstract: The confluence of component based development, model driven development and software product lines forms an approach to application development based on the concept of software factories. This approach promises greater gains in productivity and predictability than those produced by incremental improvements to the current paradigm of object orientation, which have not kept pace with innovation in platform technology. Software factories promise to make application assembly more cost effective through systematic reuse, enabling the formation of supply chains and opening the door to mass customization.

784 citations