CSC/ECE 517 Fall 2012/Table of Contents for wiki 2b topics

Introduction

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered(in 2a) and the links to the appropriate topic is available on this page.

Software Process Models

The software process model maybe defined as a simplified description of a software process, presented from a particular perspective. In essence, each stage of the software process is identified and a model is then employed to represent the inherent activities associated within that stage. Consequently, a collection of ‘local’ models may be utilized in generating the global picture representative of the software process. Examples of models include the waterfall model, spiral model, and the V-model.

• The spiral model is a software development process that combines the elements of both design and prototyping-in-stages.This model represents a risk-driven approach to software process analysis. Also known as the spiral lifecycle model (or spiral development), it is a systems development method (SDM) used in information technology (IT). This model incorporates many of the strengths of other models and resolves many of their difficulties. It combines the advantages of top-down and bottom-up concepts and promotes quality assurance through prototyping at each stage.Thus it includes the features of both prototyping and the waterfall model but provides emphasis in a key area which is mostly neglected by other methodologies: deliberate iterative risk analysis. Generally,the spiral model is intended for large, expensive and complicated projects.This approach incorporates elements of specification-driven, prototype-driven process methods, together with the classic software life cycle. More details can be found here

• The V-model also called as Verification and Validation model is a software development process which simplifies the understanding of the complexity associated with the development of a system, and is an extension to the waterfall model. Rather than proceeding linearly downwards, after the coding phase, the process steps are bent upwards to form a V shape. This creates an association between the phases in the development and the testing cycle. More details can be found here

Design Patterns

A Design Pattern in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice" - Christopher Alexander.

"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".

The different types of design patterns can be categorized and listed as below:

Creational Pattern, which help create the objects for the user, instead of having the user to instantiate the object.

• Factory Pattern, which allows a class to defer instantiation to subclasses.
• Abstract Factory Pattern, which provides an interface for creating related or dependent objects without specifying the objects' concrete classes.
• Builder Pattern, which separates the construction of a complex object from its representation so that the same construction process can create different representation.
• Prototype Pattern, which specifies the kind of object to create using a prototypical instance, and creates new objects by cloning this prototype.
• Singleton Pattern, which ensures that only one instance of a class is created and provides a global access point to the object.

Structural Pattern, which employ interfaces to achieve inheritance to enable objects to obtain new functionality.

• Adapter Pattern, which 'adapts' one interface for a class into one that a client expects.
• Bridge Pattern, which decouples an abstraction from its implementation so that the two can vary independently.
• Composite Pattern, which represents a tree structure of objects where every object has the same interface.
• Decorator Pattern, which adds additional functionality to a class at runtime where subclassing would result in an exponential rise of new classes
• Facade Pattern, which creates a simplified interface of an existing interface to ease usage for common tasks.
• Flyweight Pattern, where a high quantity of objects share a common properties object to save space.
• Proxy Pattern, where a class functions as an interface to another thing.

Behavioral Pattern, which are concerned with communication between objects.

• Command Pattern, which enables to pass around the code that needs to be executed later. More about Command Pattern is given here.
• Chain of Responsibility Pattern, where command objects are handled or passed on to other objects by logic-containing processing objects.
• Interpreter Pattern, which implements a specialized computer language to rapidly solve a specific set of problems.
• Iterator Pattern, where iterators are used to access the elements of an aggregate object sequentially without exposing its underlying representation.
• Mediator Pattern, which provides a unified interface to a set of interfaces in a subsystem.
• Memento Pattern, which provides the ability to restore an object to its previous state (rollback).
• Observer Pattern, is similar to Publish/Subscribe or Event Listener. Objects register to observe an event that may be raised by another object.
• State Pattern, is a clean way for an object to partially change its type at runtime.
• Strategy Pattern, where Algorithms can be selected on the fly.
• Template Pattern, which describes the program skeleton of a program.
• Visitor Pattern, is a way to separate an algorithm from an object.

The Active Record pattern is a Design pattern in Software Engineering which deals with the approach to store and access data in a database.A brief introduction on Active Record Pattern is given here.

Naming conventions for Active Record Pattern is given here.

CRUD stands for 'Create', 'Read' , 'Update' and 'Delete'. These are the four basic operations which are generally performed on tables in a database. The ActiveRecord module provides predefined methods for the basic CRUD operations for the model.

Details about how you connect to the databaseis given here.

Migrations help to version the various changes made to databases. It also allow developers to track a set of changes made to production or development databases and to rollback to a previous version if needed. Building a migration is given here.

Associations are used to connect two models. The association is used to describe the role of relations that models are having with each other. ActiveRecord associations can be used to describe one-to-one (1:1), one-to-many (1:n) and many-to-many (n:m) relationships between models. Associations are used to make common operations simpler and easier in your code. Rails supports six types of associations:

• belongs_to
• has_one
• has_many
• has_many :through
• has_one :through
• has_and_belongs_to_many

belongs_to and has_one form a one-to-one relationship. has_one :through is a different way to create a one-to-one relationship. has_many and belongs_to form a one-to-many relation. has_and_belongs_to_many or an alternative way has_many :through to create a many-to-many relationship Little about design patterns in Ruby is explained here.

A Comparison table for singleton,adapter,command and strategy pattern is given here.

References

<references/>

http://en.wikipedia.org/wiki/Design_pattern