The 4+1 View Model of architecture
TL;DR: The 4+1 View Model organizes a description of a software architecture using five concurrent views, each of which addresses a specific set of concerns.
Abstract: The 4+1 View Model organizes a description of a software architecture using five concurrent views, each of which addresses a specific set of concerns. Architects capture their design decisions in four views and use the fifth view to illustrate and validate them. The logical view describes the design's object model when an object-oriented design method is used. To design an application that is very data driven, you can use an alternative approach to develop some other form of logical view, such as an entity-relationship diagram. The process view describes the design's concurrency and synchronization aspects. The physical view describes the mapping of the software onto the hardware and reflects its distributed aspect. The development view describes the software's static organization in its development environment. >
Citations
More filters
Proceedings Article•
01 Jan 1994
TL;DR: This paper provides an introduction to the emerging field of software architecture by considering a number of common architectural styles upon which many systems are currently based and showing how different styles can be combined in a single design.
Abstract: As the size of software systems increases, the algorithms and data structures of the computation no longer constitute the major design problems. When systems are constructed from many components, the organization of the overall system -- the software architecture -- presents a new set of design problems. This level of design has been addressed in a number of ways including informal diagrams and descriptive terms, module interconnection languages, templates and frameworks for systems that serve the needs of specific domains, and formal models of component integration mechanisms. In this paper we provide an introduction to the emerging field of software architecture. We begin by considering a number of common architectural styles upon which many systems are currently based and show how different styles can be combined in a single design. Then we present six case studies to illustrate how architectural representations can improve our understanding of complex software systems. Finally, we survey some of the outstanding problems in the field, and consider a few of the promising research directions.
1,396 citations
Book•
01 Jan 1998TL;DR: An entertaining and often enlightening text that defines what seasoned developers have long suspected: despite advances in software engineering, most software projects still fail to meet expectations--and about a third are cancelled altogether.
Abstract: If patterns are good ideas that can be re-applied to new situations, AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis looks at what goes wrong in software development, time and time again. This entertaining and often enlightening text defines what seasoned developers have long suspected: despite advances in software engineering, most software projects still fail to meet expectations--and about a third are cancelled altogether. The authors of AntiPatterns draw on extensive industry experience, their own and others, to help define what's wrong with software development today. They outline reasons why problem patterns develop (such as sloth, avarice, and greed) and proceed to outline several dozen patterns that can give you headaches or worse. Their deadliest hit list begins with the Blob, where one object does most of the work in a project, and Continuous Obsolescence, where technology changes so quickly that developers can't keep up. Some of the more entertaining antipatterns include the Poltergeist (where do-nothing classes add unnecessary overhead), the Boat Anchor (a white elephant piece of hardware or software bought at great cost) and the Golden Hammer (a single technology that is used for every conceivable programming problem). The authors then proceed to define antipatterns oriented toward management problems with software (including Death by Planning and Project Mismanagement, along with several miniature antipatterns, that help define why so many software projects are late and overbudget). The authors use several big vendors' technologies as examples of today's antipatterns. Luckily, they suggest ways to overcome antipatterns and improve software productivity in "refactored solutions" that can overcome some of these obstacles. However, this is a realistic book, a mix of "Dilbert" and software engineering. A clever antidote to getting too optimistic about software development, AntiPatterns should be required reading for any manager facing a large-scale development project. --Richard Dragan
982 citations
TL;DR: The e3-value approach methodology shows how to model business requirements and improve business–IT alignment, in sophisticated multi-actor value constellations that are common in electronic commerce.
Abstract: Innovative e-commerce ideas are characterised by commercial products yet unknown to the market, enabled by information technology such as the Internet and technologies on top of it. How to develop such products is hardly known. We propose an interdisciplinary approach, e3-value, to explore an innovative e-commerce idea with the aim of understanding such an idea thoroughly and evaluating it for potential profitability. Our methodology exploits a requirements engineering way of working, but employs concepts and terminology from business science, marketing and axiology. It shows how to model business requirements and improve business---IT alignment, in sophisticated multi-actor value constellations that are common in electronic commerce. In addition to the e3-value approach methodology, we also present the action research-based development of our methodology, by using one of the longitudinal projects we carried out in the field of online news article provisioning.
968 citations
Cites background from "The 4+1 View Model of architecture"
...The idea of using operational scenarios for relating viewpoints is borrowed from Kruchten (1995). He introduces operational scenarios, expressed by scripts, to re-...
[...]
Book•
01 Jan 2000
TL;DR: Key business modeling concepts are presented, including how to define Business Rules with UML's Object Constraint Language (OCL) and how to use business models with use cases.
Abstract: From the Publisher:
Eriksson and Magnus Penker now provide guidance on how to use UML to model your business systems. In this book, key business modeling concepts are presented, including how to define Business Rules with UML's Object Constraint Language (OCL) and how to use business models with use cases. The authors then provide 26 valuable Business Patterns along with an e-business case study that utilizes the techniques and patterns discussed in the book.
878 citations
Book•
15 Jul 2002
TL;DR: This paper presents case Studies: Component-Based Development in Industrial Applications, which highlights the need to understand the role of software components in the development of software products.
Abstract: Preface. Introduction. The Definition and Specification of Components. Software Architecture and Components. Developing Software Components. Using Software Components. Software Product Lines. Real-Time Software Components. Case Studies: Component-Based Development in Industrial Applications.
595 citations
References
More filters
TL;DR: A model of software architecture that consists of three components: elements, form, and rationale is presented, which provides the underlying basis for the architecture in terms of the system constraints, which most often derive from the system requirements.
Abstract: The purpose of this paper is to build the foundation for software architecture. We first develop an intuition for software architecture by appealing to several well-established architectural disciplines. On the basis of this intuition, we present a model of software architecture that consists of three components: elements, form, and rationale. Elements are either processing, data, or connecting elements. Form is defined in terms of the properties of, and the relationships among, the elements --- that is, the constraints on the elements. The rationale provides the underlying basis for the architecture in terms of the system constraints, which most often derive from the system requirements. We discuss the components of the model in the context of both architectures and architectural styles and present an extended example to illustrate some important architecture and style considerations. We conclude by presenting some of the benefits of our approach to software architecture, summarizing our contributions, and relating our approach to other current work.
2,119 citations
Proceedings Article•
01 Jan 1994
TL;DR: This paper provides an introduction to the emerging field of software architecture by considering a number of common architectural styles upon which many systems are currently based and showing how different styles can be combined in a single design.
Abstract: As the size of software systems increases, the algorithms and data structures of the computation no longer constitute the major design problems. When systems are constructed from many components, the organization of the overall system -- the software architecture -- presents a new set of design problems. This level of design has been addressed in a number of ways including informal diagrams and descriptive terms, module interconnection languages, templates and frameworks for systems that serve the needs of specific domains, and formal models of component integration mechanisms. In this paper we provide an introduction to the emerging field of software architecture. We begin by considering a number of common architectural styles upon which many systems are currently based and show how different styles can be combined in a single design. Then we present six case studies to illustrate how architectural representations can improve our understanding of complex software systems. Finally, we survey some of the outstanding problems in the field, and consider a few of the promising research directions.
1,396 citations
Additional excerpts
...- ( 1 ) off-hook ) loe:tonlroller . (‘) diol ‘One c 1oe:terminol (4) digit *...
[...]
Book•
01 Dec 1993
TL;DR: This chapter discusses the development of Object-Oriented Programming Languages and the Structure of Complex Systems, and the role of Classification in this development.
Abstract: I. CONCEPTS. 1. Complexity. The Inherent Complexity of Software. The Structure of Complex Systems. Bringing Order to Chaos. On Designing Complex Systems. Sidebar: Categories of Analysis and Design Methods. 2. The Object Model. The Evolution of the Object Model. Elements of the Object Model. Applying the Object Model. Sidebar: Foundations of the Object Model. 3. Classes and Objects. The Nature of an Object. Relationships Among Objects. The Nature of a Class. Relationships Among Classes. The Interplay of Classes and Objects. On Building Quality Classes and Objects. Sidebar: Invoking a Method. 4. Classification. The Importance of Proper Classification. Identifying Classes and Objects. Key Abstractions and Mechanisms. Sidebar: A Problem of Classification. II. THE METHOD. 5 .The Notation. Elements of the Notation. Class Diagrams. State Transition Diagrams. Object Diagrams. Interaction Diagrams. Module Diagrams. Process Diagrams. Applying the Notation. 6 .The Process. First Principles. The Micro Development Process. The Macro Development Process. 7. Pragmatics. Management and Planning. Staffing. Release Management. Reuse. Quality Assurance and Metrics. Documentation. Tools. Special Topics. The Benefits and Risks of Object-Oriented Development. III. APPLICATIONS. 8. Data Acquisition: Weather Monitoring Station. Analysis. Design. Evolution. Maintenance. Sidebar: Weather Monitorint Station Requirements. 9. Frameworks: Foundation Class Library. Analysis. Design. Evolution. Maintenance. Sidebar: Foundation Class Library Requirements. 10. Client/Server Computing: Inventory Tracking. Analysis. Design. Evolution. Maintenance. Sidebar: Inventory Tracking System Requirements. 11. Artificial Intelligence Cryptanalysis. Analysis. Design. Evolution. Maintenance. Sidebar: Cryptanalysis Requirements. 12. Command and Control Traffic Management. Analysis. Design. Evolution. Maintenance. Sidebar: Traffic Management System Requirements. Afterword. Appendix: Object-Oriented Programming Languages. A.1 Concepts. A.2 Smalltalk. A.3 Object Pascal. A.4 C++. A.5 Common Lisp Object System. A.6 Ada. A.7 Eiffel. A.8 Other Object-Oriented Programming Languages. Notes. Glossary. Classified Bibliography. A. Classification. B. Object-Oriented Analysis. C. Object-Oriented Applications. D. Object-Oriented Architectures. E. Object Oriented Databases. F. Object-Oriented Design. G. Object-Oriented Programming. H. Software Engineering. I. Special References. J. Theory. K. Tools and Environments. Index. 0805353402T04062001
1,200 citations
01 Jan 1992
TL;DR: Object Behavior Analysis (OA) as mentioned in this paper is the study and modeling of a given problem domain, within the context of stated goals and objectives, focusing on what a system is supposed to do, rather than how it should do it (which we consider the design aspects).
Abstract: Object Behavior Analysis nalysis is the study and modeling of a given problem domain, within the context of stated goals and objectives. It focuses on what a system is supposed to do, rather than how it is supposed to do it (which we consider the design aspects). In addition , it must embody the rule of traceability (why), which justifies the existence of a given result by tying it back to the stated goals and objectives. The components of the problem domain can be described as anything that end users of the system, both humans and machines, view as part of the problem context. This may include technical issues, if the users view such issues as part of the problem. • • • • • • • • • • • • • • • • We want the analysis process to be carried out in a predictable and controllable manner. In taking an object-oriented approach to analysis , our goal on completion is that we have a clear understanding of the behaviors exhibited by the system , the objects that exhibit these behaviors, the relationships among the objects, and how the objects interact with one another (the system dynamics). This must all be specified in a clear and well-defined language of object and behavior names, chosen from the problem domain. In addition, any implementation code must be traceable back to the results of the analysis. This means that the vocabulary and structures apparent in the design and implementation must clearly reflect the vocabulary and structures that result from the analysis. Object-oriented analysis endeavors to model a situation in terms of a collection of interacting entities, each of which provides a well-defined set of behaviors and attributes. Most published approaches describe conceptually similar definitions , although they adopt alternate terminologies [2, 3, 10]. There is a high degree of agreement on the desired structure of the end result; we differ in how to get to the end result. Many approaches recommend first searching for the tangible objects , notably seeking the nouns in a requirements specification and any applicable verbs and adjectives. With nouns as the objects, the message interface is determined from the verbs, and the logical properties are derived from the adjectives. Although this basic approach may work for small systems, it is our experience that it simply will not scale up. First, it assumes that a complete, …
203 citations