Presentation is loading. Please wait.

Presentation is loading. Please wait.

Map Architecture Frameworks Design Patterns.

Similar presentations

Presentation on theme: "Map Architecture Frameworks Design Patterns."— Presentation transcript:

1 Map Architecture Frameworks Design Patterns

2 Issues Software systems are complex and are only getting more complex. They encompass a large amount of detail and decisions. 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.

3 Architecture 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. Abstraction of detail to focus on the major requirements. Foundation, size, major materials needed. Estimates of cost and risk.

4 Software Architecture
You may have heard of systems as described as having a two-tiered architecture or a layered architecture. Similar notion: abstraction of detail. Some questions: What are the major components of a system and how do they interact? What are the major properties of the system?

5 Definition 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. The view from several kilometers up.

6 Why is Architecture Important?
A means of dealing with complexity. A basis for decision making. Helps to define the properties and limitations of a system. Aids long term maintenance. It defines the important components and connections (the load-bearing walls). Division of effort. Standard patterns and styles.

7 Components and Connectors
Components: computational components. Clients, servers databases user interface Connectors: the means by which components interact. Procedure calls network protocols

8 Architectural Styles Systems are often described as having a client-server architecture, or a layered architecture, etc. These are particular styles of architecture. A style is defined by the components, connectors and constraints for a family of architectures. Each style has particular properties, and knowing the properties aids in decisions about which style to use. Hybrids are also common. Examples: pipe and filter, repository, layered.

9 Pipe and Filter A component (filter) reads a stream of data on its inputs and produces streams of data on its outputs. The streams are the pipes. Filters are independent and do not know the identity of upstream or downstream filters. Very flexible, good for batch operations. Example: Unix pipes.

10 Repository Two distinct components:
a central data repository independent components that operation on the repository Components may run sequentially or be triggered by changes in the repository. Examples: compilers, database systems Repository

11 Compiler Architecture
Translation Scanner, Parser Optimization Symbol Table, Parse Tree Code Generation

12 Object-Oriented Organization
Components are objects and connectors are procedure calls. Objects are responsible for maintaining some amount of data or procedure. Objects need to know the identity of all objects they interact with. There is no limit placed on the amount of interconnectedness. Object Object Object

13 Layered Systems A hierarchy with each layer providing services to the layer above it and requesting services from the layer below it. Support increasing levels of abstraction, which simplifies each layer. Implementations of the same layer can be used interchangeably. May have performance problems.

14 Modified Three Tier Arch.
User Interface Manager Client Workflow Manager Generic Services (Error Handling, Authentication) Server Business Rules Manager Persistent Object Manager Database Database

15 Where Does Architecture Fit?
Architecture is related to design but is at a higher level of abstraction. 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. Defines the interfaces between components, and the types of connectors.

16 CelsiusTech Systems Naval product line (SS2000) for command, control and communication. Architecture defines one family of application components which support multiple ship classes, platforms and operating systems. Lower cost and greater reliability comes from fitting requirements into the context of the product line. 70% reuse for million plus line systems.

17 Reuse 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.

18 Domains Functionality that is used across a spectrum of applications (or subsystems) within a domain can be packaged into a single framework. Examples: MFC in user interfaces OSEFA in manufacturing process control Choices in operating systems SEAF in engineering worksheets Applications Abstraction of common operations. Framework

19 Object-Oriented Frameworks
Framework: architecture + implementation + hooks. The framework serves as the basis for many applications. Developers fill in the hooks to produce a new app. Framework Hooks Framework New Applications

20 Concepts Applications customize and extend frameworks, much like a class inherits from it’s parent class. The architecture and implementation of the framework impose restrictions on the application. Parent Framework Subclass Application

21 Example: GUI Builders All window systems come with their own set of concepts, implementations, and the means by which those concepts interact. Buttons and sliders in windows, menus that generate events, etc. By buying into those concepts, user interfaces can be built quickly. But it’s not for everything: embedded systems (e.g. robotic soccer players) voice control

22 Users and Developers of Frameworks
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.

23 Frameworks and Libraries
Applications call library functions. Frameworks call application extensions. “Don’t call us, we’ll call you.” Application Library Framework Application Framework Library

24 Frameworks vs. Applications
are complete, executable apply to a single problem Frameworks are incomplete, although they may include sample applications apply to a range of applications within a domain

25 Ways to use a Framework As is: without any modifications.
Complete: add to the framework by filling in parts left open. Customize: replacing part of the framework with custom code.

26 Strategies for Use Appoint a framework expert. One or two people become familiar with the framework and can then be consulted during the project. 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.

27 Learning to Use the Framework
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.

28 CSF Overview Java framework that handles communication between client server or peer to peer programs over a TCP/IP network. Has some persistent storage capabilities. Subsystem. Communication Persistence

29 Framework Concerns Building a framework requires more resources than building a single application. When a framework evolves, all applications built from the framework are affected. A complex framework can take a significant amount of time to learn before it can be used effectively. It isn’t always easy to determine if the framework is compatible with the desired application.

30 Framework Benefits Reusable implementation and design that captures the expertise of developers within a domain. The framework should have a quality design which will be ‘inherited’ by applications. Decreased development time. Reduced maintenance costs from maintaining a common code base.

31 Design Patterns Design patterns can and have been used to design object-oriented frameworks. 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 The solutions are not new, but ‘tried and tested.’

32 Observer Pattern Problem: an object needs to monitor the state of another. Solution: make the object an observer. Consequences: simple interface, timely notification, no need for polling object must be able to receive updates at any time Inbox notify Subject Client update Observer

33 History of Design Patterns
Design patterns were inspired by the work of a real architect, Alexander, and his book A Timeless Way of Building. Gamma adapted and applied it to software in his Ph.D. thesis. Gamma and three others, Johnson, Helm, Vlissides, wrote a book called Design Patterns which sparked the patterns movement.

34 Patterns and Frameworks
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 Frameworks includes both design and implementation larger and more complex than design patterns the user does not need to understand the framework completely

35 Proxy Pattern 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. Solution: create a proxy of the data on the client side. Consequences: the remote proxy hides the fact that the data isn’t local transferring data can occur on demand Data Data Proxy Client

36 Composite Pattern Problem: clients should be able to ignore the differences between compositions of objects and individual objects. Consequences: makes the client simple can be overly general Solution: Component Operation() Add(Component) Remove(Component) GetChild(int) Composite Leaf Operation() Operation() Add(Component) Remove(Component) GetChild(int)

37 Pattern Descriptions 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

38 Architecture, Frameworks, and Design Patterns
Architectures are the overall high-level structure (components and connectors) of a system. Frameworks are reusable designs and implementations of all or part of an architecture. Design patterns can be used to help build architectures and frameworks. Architecture Frameworks Design Patterns

Download ppt "Map Architecture Frameworks Design Patterns."

Similar presentations

Ads by Google