from model to implementation ii

29
Arab Open University 2 nd Semester, 2006-2007 M301 Unit 5.2 From Model to Implementation [email protected]

Upload: reem-alattas

Post on 15-Apr-2017

119 views

Category:

Education


2 download

TRANSCRIPT

Page 1: From Model to Implementation II

Arab Open University2nd Semester, 2006-2007

M301

Unit 5.2

From Model to Implementation

[email protected]

Page 2: From Model to Implementation II

Reem AlAttas © 2

Topic Road Map

Components and Component Based Development

Architectures, frame works and product lines

Patterns

Page 3: From Model to Implementation II

Reem AlAttas © 3

Component

A reusable or replaceable piece of software.

The components would have to be precisely specified in terms of their interfaces and the functions they carried out.

Page 4: From Model to Implementation II

Reem AlAttas © 4

Kinds of Interfaces

Provided Interfaces: provided by a component for use by other components shown as sockets.

Required Interfaces: required from other components for use by the component shown as plugs.

Page 5: From Model to Implementation II

Reem AlAttas © 5

Components and their Interconnection

Page 6: From Model to Implementation II

Reem AlAttas © 6

Object-oriented Components in Java

Components are represented as classes.A component is able to provide a single

provided interface, but required interfaces do not need to be made explicit.

Page 7: From Model to Implementation II

Reem AlAttas © 7

Forms of Inheritance

1. Specialization.

2. Specification.

3. Construction.

4. Extension.

5. Limitation.

6. Combination.

Page 8: From Model to Implementation II

Reem AlAttas © 8

Java Classes as Components

Classes give encapsulation and information hiding, with the provided interface being very explicit.

Page 9: From Model to Implementation II

Reem AlAttas © 9

To be Able to Reuse Java Classes:

1. Java classes need to be self-describing.2. The development environment should include

library facilities for storing reusable classes, with good search facilities to find classes of potential use.

3. The development environment should contain easy ways of incorporating an existing component into an emerging design, making the connections as required.

Page 10: From Model to Implementation II

Reem AlAttas © 10

… To be Able to Reuse Java Classes:

4. Persistence, the ability for Java objects and their states to be preserved over long periods of time, perhaps as parts of a database.

5. Distribution, the ability of Java objects to communicate with other objects when distributed over many processors connected together by communication networks.

Page 11: From Model to Implementation II

Reem AlAttas © 11

JavaBeans

Are Java classes that have been provided with the previous five capabilities in particular well-defined ways.

Page 12: From Model to Implementation II

Reem AlAttas © 12

Enterprise JavaBeans have more facilities:1. There are separate interface ‘views’ for users of the

EJB components.2. There are two types of persistence:

1. Session persistence: occurs when software is executed for a short time, and the EJB persists just for the duration of this session.

2. Entity persistence: occurs when the EJB persists over many sessions, even permanently, closely associated with the database — hence the name ‘entity’, since it is independent of the execution of the software.

3. There are containers that control the creation and execution of EJBs.

Page 13: From Model to Implementation II

Reem AlAttas © 13

How are components supposed to be used? A repository of useful components was built.

Page 14: From Model to Implementation II

Reem AlAttas © 14

Difficulties with Component Reuse

Human factor: People may mistrust software developed by someone

else. People enjoy developing their own software.

Organizational factor: The projects are judged by the success of the project

itself not by the ability to be reused. Many organizations think that reuse looks like laziness.

Page 15: From Model to Implementation II

Reem AlAttas © 15

Topic Road Map

Components and Component Based Development

Architectures, frame works and product lines

Patterns

Page 16: From Model to Implementation II

Reem AlAttas © 16

Software Architecture

Software architecture is a high-level abstract description of the structure of a software system — its major parts and how they are interrelated.

Page 17: From Model to Implementation II

Reem AlAttas © 17

Architectural Styles

Software is viewed as a system composed of a number of subsystems, perhaps of different types, that are connected together.

The way the subsystems interact and are connected together distinguishes the styles.

Page 18: From Model to Implementation II

Reem AlAttas © 18

… Architectural Styles

1. Data-flow: Support reuse and modifiability. Focuses on the flow of data through the system. common in older batch computer systems & UNIX.

2. Data-centered: Support the ability to integrate systems sharing data. Focuses on a centralized store of persistent data.

If the store is passive it is called a repository or database. If it is active and informs users of changes it is termed a

blackboard.

Page 19: From Model to Implementation II

Reem AlAttas © 19

… Architectural Styles

3. Virtual-machine: Support portability. Focuses on abstractions that give a complete service to their

users. Ex. Java Virtual Machine, which enables executable Java

code to be transported between machines.

4. Call–return: Support modifiability and scalability. Focuses on the sequence of computation. OO approaches are simply the current manifestation of this

style.

Page 20: From Model to Implementation II

Reem AlAttas © 20

… Architectural Styles

5. Independent-components: Support modifiability. Decouples subsystems so that they

communicate symbolically and indirectly. Ex. the client–server approach to distributed

systems.

Page 21: From Model to Implementation II

Reem AlAttas © 21

The Input Output Application User Interaction Architecture

In object-oriented approaches this became known as model–view–controller (MVC) architecture, which equates model with application, view with output, and controller with input.

Page 22: From Model to Implementation II

Reem AlAttas © 22

Frameworks

Composed of an architecture, together with a component repository with components suitable for use within the framework, plus whatever documentation would facilitate the use of the framework.

When a company wants to produce a range of products based on a common framework it is a called product line.

Page 23: From Model to Implementation II

Reem AlAttas © 23

The Product-line Process

1. Product-line initiation.2. Domain analysis.3. Architecture specification.4. Component collection.5. Specific-requirements capture.6. Architecture specialization.7. Component selection and specialization.8. Integration and release.

Page 24: From Model to Implementation II

Reem AlAttas © 24

Topic Road Map

Components and Component Based Development

Architectures, frame works and product lines

Patterns

Page 25: From Model to Implementation II

Reem AlAttas © 25

Patterns

Records of good solutions from experienced software engineers.

Page 26: From Model to Implementation II

Reem AlAttas © 26

The Model View Controller ArchitectureThe MVC architecture, or framework,

describes a high-level solution to the general problem of human–computer interaction, relating what the user sees on a screen and does with a keyboard, mouse or other interaction device, to the functions of an application and the data that it stores.

Page 27: From Model to Implementation II

Reem AlAttas © 27

Patterns Existing at Several Levels

Architectural patterns are the highest level pattern.

Design patterns are the intermediate level pattern.

Idioms are at the lowest level and include program code level concepts.

Page 28: From Model to Implementation II

TMA5 – Q2

Page 29: From Model to Implementation II

Thank You!