3.2.1 – Abstract Data Types and Object-Oriented

Loading...

En provenance du cours de University of Alberta

Software Architecture

109 notes

University of Alberta

Software Architecture

109 notes

Cours 3 sur 4 dans Specialization Software Design and Architecture

The way that software components — subroutines, classes, functions, etc. — are arranged, and the interactions between them, is called architecture. In this course you will study the ways these architectures are represented, both in UML and other visual tools. We will introduce the most common architectures, their qualities, and tradeoffs. We will talk about how architectures are evaluated, what makes a good architecture, and an architecture can be improved. We'll also talk about how the architecture touches on the process of software development. In the Capstone Project you will document a Java-based Android application with UML diagrams and analyze evaluate the application’s architecture using the Architecture Tradeoff Analysis Method (ATAM). After completing this course, you will be able to: • Compare and contrast the components, connections, protocols, topologies, constraints, tradeoffs, and variations of different types of architectural styles used in the design of applications and systems (e.g., main program and subroutine, object-oriented, interpreters, pipes and filters, database centric, event-based). • Describe the properties of layered and n-tier architectures. • Create UML ipackage, component, and deployment diagrams to express the architectural structure of a system. • Explain the behaviour of a system using UML activity diagrams. • Document a multi-application system with a layered architecture.

À partir de la leçon

Architectural Styles

Software comes in all shapes and sizes. The architecture you choose will affect every part of your software, from its security and efficiency, to its modularity and maintainability. In this module we will examine the different architectures that you have to choose from to shape your software.

3.2.1 – Abstract Data Types and Object-Oriented5:36

3.2.2 – Main Program and Subroutine4:42

Rencontrer les enseignants

Kenny Wong
Associate Professor
Computing Science, Faculty of Science

[MUSIC]

Hello again and welcome to the second module.

In the first module, we discussed the different ways that software architecture

can be represented visually.

Now we will get into a variety of different software architectures.

These architectures can be used separately in their pure forms or

put together to guide the design of a working software system.

After completing this module, you'll be knowledgeable in important software

architectures, their key characteristics, and how they're used in practice.

We hope you're as excited as us.

It should come as no surprise that the programming paradigm of the language used

to implement the system will affect the architectural style of that system.

Each programming paradigm has its own set of constructs and

their use will shape the system you create.

There are many different styles of language-based architecture systems.

In this lesson, we will explore the object-oriented architectural style,

which results from the object-oriented programming paradigm.

When you're choosing to develop a project using an object-oriented language,

such as Java or C++, you're not simply choosing a language.

Object-oriented principles, constructs, and

design problems are all part of the whole deal.

Before we move on,

let's briefly recap the object-oriented principles that are available to you.

First, there's abstraction.

With abstraction, you can simplify a concept by ignoring unimportant details.

Next up is encapsulation.

Encapsulation allows you to bundle data and

functions into a self-contained object.

So that other objects can interact with it through an exposed interface.

Also, let's recall decomposition,

which allows you to break up a whole problem into smaller, distinct parts.

And lastly, generalization allows you to factor out conceptual commonalities.

Also at your disposal are object-oriented design patterns.

Object-oriented design patterns fall into creational, structural, and

behavioral categories.

Creational patterns guide you in creating new objects.

Structural patterns describe the relationships between objects and

the interactions between classes and subclasses.

And behavioral patterns focus on how objects perform work individually and

how they can work as a group to accomplish something.

Together, elements like these will lead to an object-oriented

architectural style for the system.

The object-oriented architectural style is focused on the data.

When presented with a system to model,

you may begin by looking at the different kinds of data handled by the system

to see how the system can be broken down into abstract data types.

An abstract data type can be represented as a class that you define to organize

data attributes in a meaningful way, so that related

attributes are grouped together, along with their associated methods.

An encapsulation restricts access to the data and

dictates what can be done with it.

Object-oriented refers to a system composed of objects,

where each object is an instance of a class.

In other words, the type of each object is its class.

Objects may interact with each other through the use of their methods.

The object-oriented paradigm allows for inheritance among abstract data types.

This means that one abstract type can be declared an extension of another type.

These classes themselves form a language-based architecture that arises

from basic object oriented principles.

The classes within the system will determine the overall

structure of the system.

Now lets consider how an automatic pet feeder would be implemented using

an object-oriented approach.

Our goal is to create classes that accurately and

succinctly model the entities involved in the problem.

To do this, you must first take stock of the data and information flow that is

present in the system so that we can identify classes within this system.

The objects in this system are the pets and the food dispenser.

The food dispenser device consists of a pet food storage container to

hold the kibble.

The bottom of this container may be temporarily opened to dispense food to

a dish below.

The dispenser also includes a light on top that will flash when it's empty.

Each pet in the system wears a collar with a unique ID tag.

Suppose that when in close proximity to the food dispenser, the pet's collar tag

triggers the food dispenser to drop a portion of pet food into the dish.

We can model pet and

food dispenser objects in the system as abstract data types.

The pet class would have attributes for

it's collar ID, maximum daily food intake amount, and current food intake amount.

The maximum daily food intake amount is a value the pet owner can set

that determines the maximum amount of food the pet may consume in a whole day.

And the current food intake amount is the amount of food the pet consumed so

far that day.

The pet class would have a method update or reset its current food intake amount.

So each morning, this value would reset to zero.

The food dispenser class would have attributes to keep track of which

pets are authorized to visit it and how much food is left.

The food dispenser class would have a method to dispense the food and

a method to flash its light when it runs out of food.

Instances of these classes would interact with each other to determine whether or

not food should be dispensed when a particular pet visits the dispenser.

The overall object-oriented architectural style of the system directly follows from

the fact that an object-oriented approach was used in the development.

Some problems are well-suited to the object-oriented architectural style.

In the example we looked at above,

it was relatively easy to identify the classes involved.

However, this is not always the case.

In a system centered around scientific computation, the identification of classes

may result in unnecessary complexity, and in turn, lower performance.

As we shall soon see, the object-oriented programming paradigm will not always be

the most appropriate solution to a problem.

Another design choice may be better suited for the problem at hand.

Explorer notre catalogue

Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.

Coursera propose un accès universel à la meilleure formation au monde, en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.

© 2018 Coursera Inc. Tous droits réservés.

Télécharger dans l'App Store

Disponible sur Google Play