Presentation on theme: "Map Architecture Frameworks Design Patterns. Issues n Software systems are complex and are only getting more complex. They encompass a large amount of."— Presentation transcript:
Map Architecture Frameworks Design Patterns
Issues n Software systems are complex and are only getting more complex. They encompass a large amount of detail and decisions. n There is a need to do such things as make decisions about software projects early, to divide work among teams, to ensure certain qualities in the software product.
Architecture n When starting the plans for a new building, the type of faucets to install on the sinks on the 23rd floor is not a key decision. n Abstraction of detail to focus on the major requirements. Foundation, size, major materials needed. Estimates of cost and risk.
Software Architecture n You may have heard of systems as described as having a two-tiered architecture or a layered architecture. n Similar notion: abstraction of detail. n Some questions: –What are the major components of a system and how do they interact? –What are the major properties of the system?
Definition n The structure or structures of the system, which comprise software components, the properties of those components, and the relationships among them. The intent is to provide a basis for decision making and risk reduction without having to consider all the detail. n The view from several kilometers up.
Why is Architecture Important? n A means of dealing with complexity. n A basis for decision making. n Helps to define the properties and limitations of a system. n Aids long term maintenance. It defines the important components and connections (the load-bearing walls). n Division of effort. n Standard patterns and styles.
Components and Connectors n Components: computational components. –Clients, servers –databases –user interface n Connectors: the means by which components interact. –Procedure calls –network protocols
Architectural Styles n Systems are often described as having a client- server architecture, or a layered architecture, etc. These are particular styles of architecture. n A style is defined by the components, connectors and constraints for a family of architectures. n Each style has particular properties, and knowing the properties aids in decisions about which style to use. Hybrids are also common. n Examples: pipe and filter, repository, layered.
Pipe and Filter n A component (filter) reads a stream of data on its inputs and produces streams of data on its outputs. The streams are the pipes. n Filters are independent and do not know the identity of upstream or downstream filters. n Very flexible, good for batch operations. n Example: Unix pipes.
Repository n Two distinct components: –a central data repository –independent components that operation on the repository n Components may run sequentially or be triggered by changes in the repository. n Examples: compilers, database systems Repository
Compiler Architecture Symbol Table, Parse Tree Optimization Translation Scanner, Parser Code Generation
Object-Oriented Organization n Components are objects and connectors are procedure calls. n Objects are responsible for maintaining some amount of data or procedure. n Objects need to know the identity of all objects they interact with. There is no limit placed on the amount of interconnectedness. Object
Layered Systems n A hierarchy with each layer providing services to the layer above it and requesting services from the layer below it. n Support increasing levels of abstraction, which simplifies each layer. n Implementations of the same layer can be used interchangeably. n May have performance problems.
Modified Three Tier Arch. User Interface Manager Workflow Manager Business Rules Manager Persistent Object Manager Database Generic Services (Error Handling, Authentication) Client Server Database
Where Does Architecture Fit? n Architecture is related to design but is at a higher level of abstraction. n When do you define the architecture? –Since the architecture captures important decisions about the structure of the software system, it needs to be defined early on in the analysis and design phase (at the same time subsystems are defined). –Subsystems are components and connectors. n Defines the interfaces between components, and the types of connectors.
CelsiusTech Systems n Naval product line (SS2000) for command, control and communication. n Architecture defines one family of application components which support multiple ship classes, platforms and operating systems. n Lower cost and greater reliability comes from fitting requirements into the context of the product line. n 70% reuse for million plus line systems.
Reuse n The example makes the point for not only reusing code components as reuse is typically thought of, but also reusing a highly configurable architecture and design of a system.
Domains n Functionality that is used across a spectrum of applications (or subsystems) within a domain can be packaged into a single framework. n Examples: –MFC in user interfaces –OSEFA in manufacturing process control –Choices in operating systems –SEAF in engineering worksheets Framework Applications Abstraction of common operations.
Object-Oriented Frameworks n Framework: architecture + implementation + hooks. n The framework serves as the basis for many applications. Developers fill in the hooks to produce a new app. Framework Hooks Framework New Applications
Concepts n Applications customize and extend frameworks, much like a class inherits from it’s parent class. n The architecture and implementation of the framework impose restrictions on the application. Framework Application Parent Subclass
Example: GUI Builders n All window systems come with their own set of concepts, implementations, and the means by which those concepts interact. n Buttons and sliders in windows, menus that generate events, etc. n By buying into those concepts, user interfaces can be built quickly. n But it’s not for everything: –embedded systems (e.g. robotic soccer players) –voice control
Users and Developers of Frameworks n There are three main roles associated with frameworks: –Framework designers, also called framework developers or framework builders, develop the original framework –Framework users, also called framework clients or application developers, use the framework to develop applications. –Framework maintainers refine and redevelop the framework to fit new requirements.
Frameworks and Libraries n Applications call library functions. n Frameworks call application extensions. “Don’t call us, we’ll call you.” LibraryApplication FrameworkApplication FrameworkLibrary
Frameworks vs. Applications n Applications: –are complete, executable –apply to a single problem n Frameworks –are incomplete, although they may include sample applications –apply to a range of applications within a domain
Ways to use a Framework n As is: without any modifications. n Complete: add to the framework by filling in parts left open. n Customize: replacing part of the framework with custom code.
Strategies for Use n Appoint a framework expert. One or two people become familiar with the framework and can then be consulted during the project. n Design integration. It is important to fully integrate the design of the application with the design of the framework during the analysis and design phases of development.
Learning to Use the Framework n Frameworks can be difficult to learn so a means of lowering the learning curve is needed. –Tutorial sessions can be held to allow the framework builders to show users what can be done with the framework. –Tools can be used to investigate the operation of the framework and to allow the use of the hooks without learning the whole framework. –Documentation can describe the design and intended use of the framework, and provide examples of use.
CSF Overview n Java framework that handles communication between client server or peer to peer programs over a TCP/IP network. n Has some persistent storage capabilities. n Subsystem. CommunicationPersistence
Framework Concerns n Building a framework requires more resources than building a single application. n When a framework evolves, all applications built from the framework are affected. n A complex framework can take a significant amount of time to learn before it can be used effectively. n It isn’t always easy to determine if the framework is compatible with the desired application.
Framework Benefits n Reusable implementation and design that captures the expertise of developers within a domain. n The framework should have a quality design which will be ‘inherited’ by applications. n Decreased development time. n Reduced maintenance costs from maintaining a common code base.
Design Patterns n Design patterns can and have been used to design object-oriented frameworks. n A design pattern is a solution to a common software design problem in a given context. –problem: conditions that apply –solution: template of classes and collaborations –consequences: effect on the overall design n The solutions are not new, but ‘tried and tested.’
Observer Pattern n Problem: an object needs to monitor the state of another. n Solution: make the object an observer. n Consequences: –simple interface, timely notification, no need for polling –object must be able to receive updates at any time Inbox notify Client update Subject Observer
History of Design Patterns n Design patterns were inspired by the work of a real architect, Alexander, and his book A Timeless Way of Building. n Gamma adapted and applied it to software in his Ph.D. thesis. n Gamma and three others, Johnson, Helm, Vlissides, wrote a book called Design Patterns which sparked the patterns movement.
Patterns and Frameworks n Design patterns –design level constructs –small and easily implemented –the user must understand the details of the pattern to use it –used to help design frameworks n Frameworks –includes both design and implementation –larger and more complex than design patterns –the user does not need to understand the framework completely
Proxy Pattern n Problem: How can data on a server be represented at a client without having to keep a copy of the entire data object at the client. n Solution: create a proxy of the data on the client side. n Consequences: –the remote proxy hides the fact that the data isn’t local –transferring data can occur on demand Data Proxy Client Data
Composite Pattern n Problem: clients should be able to ignore the differences between compositions of objects and individual objects. n Consequences: –makes the client simple –can be overly general Leaf Operation() Component Operation() Add(Component) Remove(Component) GetChild(int) Operation() Add(Component) Remove(Component) GetChild(int) Composite n Solution:
Pattern Descriptions n A full pattern description gives: –motivation for and applicability of the pattern (the problem in context) –structure, participants and collaborations of the participants –consequences, both good and bad, of using the pattern –an example showing the implementation of the pattern –programs or projects in which it has been used –related patterns
Architecture, Frameworks, and Design Patterns n Architectures are the overall high-level structure (components and connectors) of a system. n Frameworks are reusable designs and implementations of all or part of an architecture. n Design patterns can be used to help build architectures and frameworks. Architecture Frameworks Design Patterns