Cap 17

Software Development
Alvaro Cuno Universidade Federal do Rio de Janeiro Laboratorio de Computao Grfica, PESC/COPPE February, 2008
Introduction

Build applications is not write code only Today applications require increasingly sophisticated architectures and code We'll see that one of the biggest challenges is knowing what to write
Fev 2008
Introduction (cont.)

Build applications is not write code only Today applications require increasingly sophisticated architectures and code We'll see that one of the biggest challenges is knowing what to write
Learn useful concepts for planning and building applications
flexible, efficient, reusable, and easily maintained
Introduce design patterns as solutions to common programming scenarios
Fev 2008
C++ is not difficult for programmers

A good language reference, books, tutorials, etc. IDEs, debuggers, Libraries(STL, CGAL, BOOST, etc.), etc. Multiplataform: Linux, Windows, Mac OS, etc
The challenge is not the C++ language The real challenge is how to structure your application: it is deciding when and what classes to write
Fev 2008
Building Applications
Several methodologies -> several phases, but, in general:

1) Analysis 2) Design 3) Implementation 4) Testing
No linear Thoroughness at each phase helps minimize the risk that you'll have to make major architectural changes later on, which could severely impact schedules and project success
5
Fev 2008
Analysis
What the application is supposed to do?

large projects specific functional requirements
small projects
Fev 2008
time
ideas (often vague)
Analysis (cont.)

Poor analysis = frustration

small projects
Developer: constantly guessing and refector Managers: project no closed Client: application no working Customers: limited featured sets and bugs
7
Fev 2008
time
ideas (often vague)
Analysis (cont.)

Poor analysis = frustration The goal of analysis is to

small projects
provide a CLEAR SPECIFICATION that Developer: constantly guessing and refector outlines the needs of the user. Managers: project no closed analysis phase Unlike later phases, the should be as non-technical as possible Client: application no working
Customers: limited featured sets and bugs

8
Fev 2008
time
ideas (often vague)
Analysis (cont.)
The outcome of the analysis phase is generally a document There are several approaches to define functional requirements
Fev 2008
Analysis (cont.)
The outcome of the analysis phase is generally a document There are several approaches to define functional requirements
(1) ................. (2) ................. (3) ................. (4) ................. (5) .................
Use Cases
Brief Casual Formal
Simple list of everything that the application should be able to do

Fev 2008
Use cases present the application requirements by showing various ways in which users might interact with the application
10
Analysis (cont.)
Fev 2008
11
Analysis (cont.)
Fev 2008
12
Analysis (cont.)
Fev 2008
13
Design Phase

How? The outcome of the design phase is a document that it will help you break up the application development into individual tasks
specific functional requirements
subsystems and classes that you will use and the relationships between them.
Fev 2008
14
Design Phase (cont.)
Tasks

Classes determination Responsabilities of each class The class collaborators The relationships each class has with those collaborators Formalizing Public APIs (the public methods of the classes)
Fev 2008
15
Classes determination
Deciding what constitutes a class is as much an art as it is a science It's often a good idea to look at your use cases to find classes. Classes are nouns From that use case we can easily identify these relevant nouns which are natural candidates for classes: "address form, "address data, "mapping service, "map data, and "map
Fev 2008
16
Responsabilities of each class,
A responsibility is essentially what a class (or an instance of the class) should be able to do or facilitate A responsibility is usually something that can be written out in plain language in a few words, ex:

Create user input form, Validate user input Handle requests and responses to and from server-side service Draw vector map from data model
As you work on determining the responsibilities for the classes in your application, you will most likely drop classes, add classes, and change existing classes.
Fev 2008
17
The class collaborators
To fulfill their responsabilities classes must rely on other classes to assist them. These collaborators generally lend a hand either by providing data or by enabling the class to offload functionality Locating collaborators is useful for us in terms of determining relationships between existing classes or to create new classes
The relationships each class has with those collaborators
Association(uses), aggregation(has a), inheritance(is a)
Formalizing Public APIs (the public methods of the classes)
Fev 2008
18
Implementation
Write the code you have planned out
classes ...
C++ code
Fev 2008
19
Implementation (cont.)
Coding conventions

Classes, variables, functions Consistent and conscious coding conventions are a boon to application development By applying conventions consistently you can expect to write code that is easily read by you and anyone else during team development

int year; Map city; Map cityMap; private Map _cityMap: void getMapDataForAddress(AddressData address);
Comments: doxigen
Fev 2008
20
Coding conventions example
Fev 2008
21
Encapsulation

Classes should be black boxes You only can put things in and take things out Example
student.grade = 14; // outside of the valid range
Fev 2008
22
Composition and inheritance
Advantages and Disadvantages
Fev 2008
23
Coupling

tight coupling loose coupling
Loose coupling creates flexible and adaptable systems. If objects are tightly coupled, the system is rigid. One change in one object can cascade and break the entire system.
Fev 2008
24
Testing
Run test cases to determine that the application behaves as expected and to try to catch any bugs New bugs will be introduced during bug fixing and old fixed bugs will re-emerge Who?

quality assurance (QA) group developers no automated tests automated tests
How?

Fev 2008
25
Architectural Patterns
Fev 2008
26
Introduction
Software patterns that offer well-established solutions to architectural problems in software engineering Express a structural organization schema for a software system, which consists of subsystems, their responsibilities and interrelations In comparison to design patterns, architectural patterns are larger in scale
Fev 2008
27
Three-tier architecture
Each tier is developed and maintained as a independent module Conceptually the threetier architecture is linear contrary to the MVC which is triangular
Fev 2008
28
Model View Controller
MVC is often seen in web applications

View: HTML page Controller: code that gathers dynamic data and generates the content within the HTML Model: current content, usually stored in a DB
29
Fev 2008
Pipeline
A simple pipeline
the output of each element is the input of the next
Process 1
Process 2
Process n
Fev 2008
30
More patterns

Implicit invocation Blackboard system Peer-to-peer Service-oriented architecture Naked objects
Fev 2008
31
Design Patterns
Fev 2008
32
Introduction
As you build more and more applications, you'll start to find that there are patterns that emerge time and time again There are certain ways to accomplish tasks and solve common problems that occur frequently Don't reinvent the wheel each time Learning the design patterns helps you more quickly identify intelligent and effective ways to structure each new application
Fev 2008
33
These patterns and what we have to say about the patterns is not intended to be held as gospel It is intended to serve as a guide and an inspiration for your own application development These patterns are not rules. Read everything with an open and alert, yet critical, mind.
Fev 2008
34
Advantages
DP help you build a common vocabulary to effectively communicate with other developers The Car example
Fev 2008
35
Design patterns
1) Creational patterns 2) Behavioral patterns 3) Structural patterns
Fev 2008
36
Creational patterns
Creational patterns show how to make the design more flexible, not necessarily smaller
Creational class patterns defer some part of object creation to subclasses Creational object patterns defer it to another object
Fev 2008
37
Example: Building a Maze
Components of the maze
Fev 2008
38
Fev 2008
39
Fev 2008
40
Fev 2008
41
Additional requirements:

Room with a bomb set in it. If the bomb goes off, it will damage the walls (at least) Enchanted room Magic door
Fev 2008
42
Problems with the naive implementation

Inflexibility Doesn't promote reuse It's difficult to change the classes that define the components of the maze

Simple maze -> Enchanted maze Room -> Enchanted room
Fev 2008
43
FACTORY METHOD
Allows you to trigger the creation of objects in an abstract class, but to defer the specific type to the subclass Link up two or more separate but related class hierarchies
Fev 2008
44
Factory Method: Applicability
A class can't anticipate the class of objects it must create A class wants its subclasses to specify the objects it creates Classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate
Fev 2008
45
Factory Pattern: Structure
Fev 2008
46
Factory Method: Consequences
Factory methods eliminate the need to bind application-specific classes into your code. The code only deals with the Product interface; therefore it can work with any user-defined ConcreteProduct classes A potential disadvantage of factory methods is that clients might have to subclass the Creator class just to create a particular ConcreteProduct object
Fev 2008
47
Factory Method: Building a Maze
Fev 2008
48
Factory Method: Building a Maze
BombedWall
DoorNeedingSpell RoomWithABomb BombedMazeGame Fev 2008 EnchantedMazeGame EnchantedRoom
49
Factory Method: Source Code
Fev 2008
50
Fev 2008
51
Fev 2008
52
Fev 2008
53
Fev 2008
54
Fev 2008
55
ABSTRACT FACTORY
Provide an interface for creating families of related or dependent objects without specifying their concrete classes
Fev 2008
56
Abstract Factory: Applicability
A system should be independent of how its products are created, composed and represented A system should be configured with one of multiple families of products A family of related product objects is designed to be used together, and you need to enforce this constraint You want to provide a class library of products, and you want to reveal just their interfaces, not their implementations
Fev 2008
57
Abstract Factory: Structure
Fev 2008
58
Abstract Factory: Consequences

It isolates concrete classes It makes exchanging product families easy It promotes consistency among products Supporting new kinds of products is difficult
Fev 2008
59
Abstract Factory: Source Code
Fev 2008
60
Fev 2008
61
Fev 2008
62
Fev 2008
63
BUILDER
Separate the construction of a complex object from its representation so that the same construction process can create different representations
Fev 2008
64
Builder: Applicability
The algorithm for creating a complex object should be independent of the parts that make up the object and how they are assembled The construction process must allow different representations for the object that's constructed
Fev 2008
65
Builder: Structure
Fev 2008
66
Builder: Consequences
It lets you vary a product's internal representation: Define a new kind of builder It isolates code for construction and representation: Clients needn't know anything about the classes that define the product's internal structure It gives you finer control over the construction process: Only when the product is finished does the director retrieve it from the builder
Fev 2008
67
Builder: Source Code
Fev 2008
68
Fev 2008
69
Fev 2008
70
Fev 2008
71
Structural patterns
Structural patterns are concerned with how classes and objects are composed to form larger structures

Structural class patterns use inheritance to compose classes Structural object patterns describe ways to assemble objects to realize new functionality at run-time
Examples: Adapter, Bridge, Composite, Decorator, Facade
Fev 2008
72
ADAPTER
Convert the interface of a class into another interface clients expect Adapter lets classes work together that couldnt otherwise because of incompatible interfaces
Fev 2008
73
Adapter: Motivation
Drawing editor example
Fev 2008
74
Adapter: Applicability
You want to use an existing class, and its interface does not match the one you need You want to create a reusable class that cooperates with classes that don't necessarily have compatible interfaces (object adapter only) you need to use several existing subclasses, but it's impractical to adapt their interface by subclassing every one. An object adapter can adapt the interface of its parent class
Fev 2008
75
Adapter: Structure
Class adapter
Multiple inheritance
Object adapter
Object composition
Participants
Fev 2008
76
Adapter: Consequences
Class adapters
Object adapters
won't work when we want to adapt a class and all its subclasses lets Adapter override some of Adaptee's behavior introduces only one object(no additional pointer indirection is needed)
lets a single Adapter work with the Adaptee itself and all of its subclasses makes it harder to override Adaptee behavior
Fev 2008
77
Adapter: Sample code
Fev 2008
78

Class Adapter:
Fev 2008
79
Fev 2008
80
DECORATOR
Attach additional responsibilities to an object dynamically Decorators provide a flexible alternative to subclassing for extending functionality
Fev 2008
81
Decorator: Motivation
Fev 2008
82
Decorator: Applicability
To add responsibilities to individual objects dynamically and transparently, that is, without affecting other objects For responsibilities that can be withdrawn When extension by subclassing is impractical
Fev 2008
83
Decorator: Structure
Fev 2008
84
Decorator: Consequences

More flexibility than static inheritance Avoids feature-laden classes high up in the hierarchy A decorator and its component aren't identical Lots of little objects
Fev 2008
85
Decorator: Implementation

Interface conformance Omitting the abstract Decorator class Keeping Component classes lightweight Changing the skin of an object versus changing its guts
Fev 2008
86
Decorator: Sample Code
Fev 2008
87
Decorator: Sample Code
Fev 2008
88
Behavioral Patterns
Identify common communication patterns between objects
Behavioral class patterns use inheritance to distribute algorithms and flow of control Behavioral object patterns use object composition rather than inheritance to describe how a group of objects cooperate to perform a task that no single object can carry out alone
Examples: Template Method, Interpreter, Mediator, Chain of responsability, Observer, etc.
Fev 2008
89
TEMPLATE METHOD
Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure.
Fev 2008
90
Template Method: Motivation
A framework provides Application and Document classes
Fev 2008
91
Template Method: Motivation
The abstract Application class defines the algorithm for opening and reading a document in its OpenDocument operation:
OpenDocument == The Template Method

Fev 2008 92
Template Method: Applicability
To implement the invariant parts of an algorithm once and leave it up to subclasses to implement the behavior that can vary When common behavior among subclasses should be factored and localized in a common class to avoid code duplication To control subclasses extensions
Fev 2008
93
Template Method: Structure

Participants
AbstractClass:
Defines abstract primitive operations Implements a template method defining the skeleton of an algorithm Implements the primitive operations
ConcreteClass
Fev 2008
94
Template Method: Consequences
Template methods are the means for factoring out common behavior in library classes Template methods call the following kinds of operations: concrete operations, concrete AbstractClass operations, primitive operations, factory methods, hook operations
Fev 2008
95
Template Method: Implementation
Using C++ access control

Primitive operations == protected members Primitive operations ~= declared pure virtual Template Method == nonvirtual member function
Minimizing primitive operations Naming conventions: "Do-", "DoCreateDocument", "DoRead"
Fev 2008
96
Template Method: Sample Code
Fev 2008
97
MEDIATOR
Define an object that encapsulates how a set of objects interact Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently
Fev 2008
98
Mediator Pattern: Motivation
Implementation of dialog boxes in a GUI
Fev 2008
99
Mediator Pattern: Applicability
A set of objects communicate in well-defined but complex ways Reusing an object is difficult because it refers to and communicates with many other objects A behavior that's distributed between several classes should be customizable without a lot of subclassing
Fev 2008
100
Mediator Pattern: Structure
Participants

Mediator: Defines an interface Concrete Mediator

Implements cooperative behaviors knows and maintains its colleagues
Colleague Classes: each colleague communicates with its mediator and not with another colleague
Fev 2008
101
Mediator Pattern: Consequences
This pattern has the following benefits and drawbacks:

It limits subclassing It decouples colleagues It simplifies object protocols It abstracts how objects cooperate It centralizes control
Fev 2008
102
Mediator Pattern: Implementation

Omitting the abstract Mediator class Colleague-Mediator communication
Fev 2008
103
Mediator Pattern: Sample Code
Fev 2008
104
Fev 2008
105
Fev 2008
106
Fev 2008
107
Fev 2008
108
Fev 2008
109
Bibliography
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. November 2004 Anonymous. Design_Patterns. Wikipedia, the free encyclopedia. http://en.wikipedia.org/wiki/Design_Patterns [Accessed Jan 2008]. Andrei Alexandrescu. Modern C++ Design: Generic Programming and Design Patterns Applied. February 2006 Joey Lott, Danny Patterson. Advanced ActionScript 3 with Design Patterns. Adobe Press. November 2006. Olsen Russ. Design Patterns in Ruby. Addison-Wesley. December 2007.
Fev 2008
110

Cap 17

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Cap 17

Diunggah oleh

Hak Cipta:

Format Tersedia

Software Development

Learn useful concepts for planning and building applications

flexible, efficient, reusable, and easily maintained

Introduce design patterns as solutions to common programming scenarios

C++ is not difficult for programmers

Several methodologies -> several phases, but, in general:

What the application is supposed to do?

ideas (often vague)

What the application is supposed to do?

Poor analysis = frustration

ideas (often vague)

What the application is supposed to do?

Poor analysis = frustration The goal of analysis is to

Customers: limited featured sets and bugs

ideas (often vague)

Brief Casual Formal

Simple list of everything that the application should be able to do

specific functional requirements

Design Phase (cont.)

Design Phase (cont.)

Design Phase (cont.)

Responsabilities of each class,

Design Phase (cont.)

The class collaborators

The relationships each class has with those collaborators

Association(uses), aggregation(has a), inheritance(is a)

Formalizing Public APIs (the public methods of the classes)

Write the code you have planned out

Coding conventions example

student.grade = 14; // outside of the valid range

Composition and inheritance

Advantages and Disadvantages

tight coupling loose coupling

quality assurance (QA) group developers no automated tests automated tests

Model View Controller

MVC is often seen in web applications

the output of each element is the input of the next

Implicit invocation Blackboard system Peer-to-peer Service-oriented architecture Naked objects

Example: Building a Maze

Components of the maze

Example: Building a Maze

Example: Building a Maze

Example: Building a Maze

Example: Building a Maze

Example: Building a Maze

Problems with the naive implementation

Simple maze -> Enchanted maze Room -> Enchanted room

Factory Method: Applicability

Factory Pattern: Structure

Factory Method: Consequences

Factory Method: Building a Maze

Factory Method: Building a Maze

DoorNeedingSpell RoomWithABomb BombedMazeGame Fev 2008 EnchantedMazeGame EnchantedRoom

Factory Method: Source Code

Factory Method: Source Code

Factory Method: Source Code

Factory Method: Source Code

Factory Method: Source Code

Factory Method: Source Code

Abstract Factory: Applicability

Abstract Factory: Structure

Abstract Factory: Consequences

Abstract Factory: Source Code