INFORMATION SEARCH, ANALYSIS AND PRESENTATION (ISAP)

INFORMATION SEARCH, ANALYSIS AND PRESENTATION (ISAP)

One of the primary focuses of technical education is to produce employable graduates/technicians. Through a sound knowledge of the subjects is impact. ISAP play a vital role in employability. Graduates/technicians without a good communication would not be able to face a placement committee ISAP is necessary not only in placement but also for job success.

For candidates who are entering into the carriers for the first time. The following skills are highly recommended and they must be trained in the following areas:

1. Communication Skill.
2. Presentation Skill.
3. Writing Skill.
4. Group Discussion.
5. Case Study.
6. Preparing job hunting material.
7. Resume preparation.
8. Facing the interview.
9. Carrier exploration
10. Use of communication technologies.

Barriers to Communication

There are number of barriers to communication which produce noise and prevent the achievement of desired result some of these are:

1. Badly encoded message.
2. Disturbance in the transmission channel.
3. Poor retention.
4. Inattention by the receiver.
5. Unclassified assumption.
6. Mistrust between sender and receiver.
7. Premature evaluation of the message.
8. Differences in perception.
9. Misinterpretation of the message.
10. Selection of wrong variety of long wage.

Classification of Communication

1. Non-verbal communication
2. Verbal communication

Non-Verbal communication:

Non-Verbal communication refers to all external stimuli other than spoken or written words and including body motion. Characteristics of appearance,characteristics of voice and use of space and distancing.

All these non-verbal clues taken together are also known as body language.

Verbal Communication:

Verbal Communication includes oral communication and written communication.
Body language plays a significant role in oral communication in day-to-day oral communication we kept on interpreting non verbal clues without being aware that we doing so.

Definition

It is defined as documented prose work incorporating the result of an organised analysis of a subject. In its style structure and approach closely resembles a formal report. But in certain respects research papers differ from a formal report is always prompted by a specific need of the organisation.

Research paper and Articles:

Characteristics feature of a research paper are:-
1. A research paper may be written about any subject social, cultural, scientific and technical, etc., But the treatment is scholarly and is supported by evidence.
2. There is a relatively high concentration of a certain writing techniques such as a definitions, classification interpretation and description of a process.
3. Its formal elements are generally those of a report and the writing is characterised by the use of graph cards and scientific technical or specialised vocabulary.
4. The emphasis is an presentation of information accurately and concisely and the writer maintains an attitude of complete impartiality and objectivity.

Types

There are three types of research paper
1. Library research paper of a term. Paper or a theme paper.
2. Scientific paper.
3. Technical paper

Library Research Paper:

There are three preparatory steps in writing such a paper namely.
1. Selecting a subject.
2. Locating a source of information
3. Note marking

Usually such a paper is written under the guidance of an instructor and the student is advised how to go about it.

The scientific paper and technical paper are often used interchangeably to refer to a research paper. When a distinction is made it is on the basic of its contents.

LIGHT EMITTING POLYMER

LIGHT EMITTING POLYMER'

The seminar is about polymers that can emit light when a voltage is applied to it. The structure comprises of a thin film of semiconducting polymer sandwiched between two electrodes (cathode and anode).When electrons and holes are injected from the electrodes, the recombination of these charge carriers takes place, which leads to emission of light .The band gap, ie. The energy difference between valence band and conduction band determines the wavelength (colour) of the emitted light.
They are usually made by ink jet printing process. In this method red green and blue polymer solutions are jetted into well defined areas on the substrate. This is because, PLEDs are soluble in common organic solvents like toluene and xylene .The film thickness uniformity is obtained by multi-passing (slow) is by heads with drive per nozzle technology .The pixels are controlled by using active or passive matrix. The advantages include low cost, small size, no viewing angle restrictions, low power requirement, biodegradability etc. They are poised to replace LCDs used in laptops and CRTs used in desktop computers today. Their future applications include flexible displays which can be folded, wearable displays with interactive features, camouflage etc.

The origins of polymer OLED technology go back to the discovery of conducting polymers in 1977,which earned the co-discoverers- Alan J. Heeger , Alan G. MacDiarmid and Hideki Shirakawa - the 2000 Nobel prize in chemistry. Following this discovery , researchers at Cambridge University UK discovered in 1990 that conducting polymers also exhibit electroluminescence and the light emitting polymer(LEP) was born!.

IRIS SCAN

IRIS SCAN

A method for rapid visual recognition of personal identity is described, based on the failure of statistical test of independence. The most unique phenotypic feature visible in a person’s face is the detailed texture of each eye’s iris: an estimate of its statistical complexity in a sample of the human population reveals variation corresponding to several hundred independent degrees-of-freedom. Morphogenetic randomness in the texture expressed phenotypically in the iris trabeclar meshwork ensures that a test of statistical independence on two coded patterns organizing from different eyes is passed almost certainly, whereas the same test is failed almost certainly when the compared codes originate from the same eye. The visible texture of a person’s iris in a real time video image is encoded into a compact sequence of multi-scale quadrature 2-D Gabor wavelet coefficients, whose most significant bits comprise a 512 – byte “IRIS–CODE” statistical decision theory generates identification decisions from Exclusive-OR comparisons of complete iris code at the rate of 4,000 per second, including calculation of decision confidence levels. The distributions observed empirically in such comparisons imply a theoretical “cross-over” error rate of one in 1,31,000 when a decision criterion is adopted that would equalize the False Accept and False Reject error rates.

Reliable automatic recognition of persons has long been an attractive goal. As in all pattern recognition problems, the key issue is the relation between interclass and intra-class variability: objects can be reliably classified only if the variability among different instances of a given class is less than the variability between different classes. Iris patterns become interesting as an alternative approach to reliable visual recognition of persons when imaging can be done at distances of less than a meter, and especially when there is a need to search very large databases without incurring any false matches despite a huge number of possibilities. The iris has the great mathematical advantage that its pattern variability among different persons is enormous. In addition, as an internal (yet externally visible) organ of the eye, the iris is well protected from the environment and stable over time. As a planar object its image is relatively insensitive to angle of illumination, and changes in viewing angle cause only affine transformations; even the non-affine pattern distortion caused by pupillary dilation is readily reversible. Finally, the ease of localizing eyes in faces, and the distinctive annular shape of the iris, facilitates reliable and precise isolation of this feature and the creation of a size-invariant representation.
Algorithms developed by Dr. John Daugman at Cambridge are today the basis for all iris recognition systems worldwide

Code-division-duplexing

Code-division-duplexing

Reducing interference in a cellular system is the most effective approach to increasing radio capacity and transmission data rate in the wireless environment. Therefore, reducing interference is a difficult and important challenge in wireless communications. In every two-way communication system it is necessary to use separate channels to transmit information in each direction. This is called duplexing. Currently there exist only two duplexing technologies in wireless communications, Frequency division duplexing (FDD) and time division duplexing (TDD). FDD has been the primary technology used in the first three generations of mobile wireless because of its ability to isolate interference. TDD is seemingly a more spectral efficient technology but has found limited use because of interference and coverage problems.

Code-division duplexing (CDD) is an innovative solution that can eliminate all kinds of interference. CDMA is the best multiple access scheme when compared to all others for combating interference. However, the codes in CDMA can be more than one type of code. A set of smart codes can make a high-capacity CDMA system very effective without adding other technologies. The smart code plus TDD is called CDD. This paper will elaborate on a set of smart codes that will make an efficient CDD system a reality. The CDMA system based on this is known as the LAS-CDMA, where LAS is a set of smart codes. LAS-CDMA is a new coding technology that will increase the capacity and spectral efficiency of mobile networks. The advanced technology uses a set of smart codes to restrict interference, a property that adversely affects the efficiency of CDMA networks.

To utilize spectrum efficiently, two transmission techniques need to be considered: one is a multiple access scheme and the other a duplexing system. There are three multiple access schemes namely TDMA, FDMA and CDMA. The industry has already established the best multiple access scheme, code-division multiple access (CDMA), for 3G systems. The next step is to select the best duplexing system. Duplexing systems are used for two-way communications. Presently, there are only two duplexing systems used: frequency-division duplexing (FDD), and time-division duplexing (TDD). The former uses different frequencies to handle incoming and outgoing signals. The latter uses a single frequency but different time slots to handle incoming and outgoing signals.

In the current cellular duplexing systems, FDD has been the appropriate choice, not TDD. Currently, all cellular systems use frequency-division duplexing in an attempt to eliminate interference from adjacent cells. The use of many technologies has limited the effects of interference but still certain types of interference remain. Time-division duplexing has not been used for mobile cellular systems because it is even more susceptible to different forms of interference. TDD can only be used for small confined area systems..

Code-division duplexing is an innovative solution that can eliminate all kinds of interference. Eliminating all types of interference makes CDD the most spectrum efficient duplexing system.

One of the key criteria in evaluating a communication system is its spectral efficiency, or the system capacity, for a given system bandwidth, or sometimes, the total data rate supported by the system. For a given bandwidth, the system capacity for narrow band radio systems is dimension limited, while the system capacity of a traditional CDMA system is interference limited. Traditional CDMA systems are all self-interference system. Three types of interference are usually considered. By ISI we mean InterSymbol Interference, which is created by the multi-path replica of the useful signal itself; MAI, or Mutual Access Interference, which is the interference created by the signals and their multi-path replica from the other users onto the useful signal; and ACI, or Adjacent Cell Interference, which is all the interfering signals from the adjacent cells onto the useful signal. .

Traditional synchronous CDMA systems employ almost exclusively Walsh-Hadamard orthogonal codes, jointly with PN sequence, and Gold codes, Kasami codes, etc. In these systems, due to the difficulty in timing synchronization and the large cross-correlation values around the origin, there exists a “near far” effect, such that in some typical system, fast power control has to be employed in order to keep an uniform received signal level at the base station. On the other hand, in forward channel all the signals’ power must be kept at an uniform level. Since the transmitting power of a user would interfere others and even may interfere itself, if one of the users in the system increases its power unilaterally, all other users power should be simultaneously increased; otherwise the controlled system power regime will be destroyed, and the capacity would be drastically decreased. This is because any radio channel, especially mobile channel, is a random time-varying time dispersion channel due to the multi-path effect, so that the received signal can not be reached at the receiver simultaneously.

Sensitive skin

Sensitive skin is a large-area, flexible array of sensors with data processing capabilities, which can be used to cover the entire surface of a machine or even a part of a human body. Depending on the skin electronics, it endows its carrier with an ability to sense its surroundings via the skin’s proximity, touch, pressure, temperature, chemical/biological, or other sensors. Sensitive skin devices will make possible the use of unsupervised machines operating in unstructured, unpredictable surroundings among people, among many obstacles, outdoors on a crowded street, undersea, or on faraway planets. Sensitive skin will make machines “cautious” and thus friendly to their environment. This will allow us to build machine helpers for the disabled and elderly, bring sensing to human prosthetics, and widen the scale of machines’ use in service industry. With their ability to produce and process massive data flow, sensitive skin devices will make yet another advance in the information revolution. This paper surveys the state of the art and research issues that need to be resolved in order to make sensitive skin a reality.

Unified Modeling Language

Unified Modeling Language

This document was written as I learned UML (Unified Modeling Language). I am not an expert in UML and do not pretend to be. However I believe that this document will supplement other UML learning materials and help speed the process of learning UML along with clarify how it should be effectively used. This document should be used along with other referenced materials for learning and using UML. UML can be used as a project modeling tool for object oriented programming and the Rational Unified Process can be used as part of a project management tool
.

It is assumed that the reader has basic knowledge of object oriented programming and techniques.

This document outlines some information about Unified Modeling Language (UML) and the Rational Unified Process. Knowledge of both is important for the management and operation of projects that use iterative development. This document will address steps involved in the design process of a project. These steps will be taken for specific purposes and in the process various documents will be created.

The Rational Unified Process (RUP)

The Rational Unified Process provides method for managing tasks and developing documentation. It is a methodology package for sale on the web by Rational Software at http://www.rational.com. It contains software to aid the process.

UML

UML is a notation (graphical language with rules for creating analysis and design methods). UML is a supporting tool for the project.

The Design Process

The UML design process involves the creation of various graphical or text based documents. In UML, these documents are called artifacts and they describe the output of a step in the process. The UML design process has two main parts which are:

* Analysis - What is the problem?
* Design - How should the problem be solved?

The reason for this analysis and design process is to allow the project to be broken down into component parts which provide the following project characteristics:

* Detail is hidden
* The system is modular
* Components are connected and interact
* Layer complexity
* Components may be reusable in other products.
* Variations on a theme.

Phases

Phases describe the functional implementation of the project. There are several iterations in each phase. Project phases and general percent of the project are:

1. Inception - 5%
2. Elaboration - 20%
3. Construction - 65%
4. Transition - 10%

Iterations

The traditional design process involves a step by step process. This process basically includes:

1. Requirements Definition
2. Analysis
3. Design
4. Installation
5. Testing

This process does not allow for changes to the overall design once a particular phase is reached. Changes to a design once the testing phase is reached can be very difficult. This causes projects to have a high maintenance cost long after initial completion. UML and the iterative design process save money by allowing the design of systems that have low maintenance cost. The UML process allows for designs to have iterative processes. Essentially this means that the each iteration add some function (based on a use case) to the system. Additional features or functions are added in succeeding iterations. This allows a project to become active sooner and as feedback is given, additions or modifications can be made with less effort. Each iteration will have a time limit and will have specific goals. This is called "time boxing".

Design steps are broken into iterations which may be performed over and over. Each iteration includes:

1. Analysis
2. Design
3. Code + Design +Test + Integration

It is important to note that test and integration is done during each iteration. This means code is tested to the extent possible during the iteration to be sure of its quality. Also integration should be done during every iteration (Except the first) to get the code from each iteration working together. If integration is left to the end of the project, it may become very difficult. Iterations have a length of two to six weeks. Iterations are "time boxed" with each iteration having a fixed length with specific goals. Use case requirements are used to determine the development to be done during each iteration. Therefore an iteration may include one or more of the following:

* A complete use case.
* A simplified use case.
* The remainder of the use case after the simplified use case was completed in a previous iteration.
* More than one use case.

The idea is to schedule just enough work in each iteration to be able to complete the work by the end of the scheduled iteration.

Workflows

Workflows include:

1. Business modeling
2. Requirements
3. Analysis and Design
4. Implementation and Test
5. Deployment
6. Configuration and change management
7. Project Management
8. Environment - Required tools and software for the project work are made available to the team.

During each project phase and each iteration, there is a certain amount of work being done in each workflow category. Obviously during the inception and elaboration phases business modeling and requirements definitions are done more, however even during the successive phases such as construction, some business modeling or requirements definitions work may be necessary. This will be especially true if the plan changes, however even if the plan does not change some reassessment of requirements definitions should be done along the way.

Artifacts

During each iteration the below artifacts (documents) are created. They are normally created in the order shown.

1. Use Case Diagram
2. High Level Use Case Diagram
3. Expanded Use Case Diagram
4. System Sequence Diagram
5. Domain Model (Formally called conceptual model)
6. Operation contract
7. Collaboration Diagram (Also called interaction diagrams)
8. Design Class Diagrams

The first six steps are part of the analysis phase and the last two steps are part of the design phase.

The Unified Modeling Language

The Unified Modeling Language

Project Start

Much of the content of the Project Process section of this document is purely connotative and is merely my opinion about what is helpful when breaking down a large project into smaller solvable problems. I believe one weakness of the Rational Unified Process is that it does not provide for well ordered methodologies to address how to logically break a large process into smaller sections. I will attempt to address that issue here.
Real World Projects

One thing to keep in mind about UML and the Rational Unified Process is that the real world is complex and project requirements will change. Also there will be unexpected events during development. Enexpected events tend to show up more often and with greater consequences in high risk parts of the project. There are not always exact rules to go by when creating artifacts when using UML and the Rational Unified Process. This is because project situations vary and your situation will depend on many factors including your current systems and staff. This document will give some general ideas and possibly some rules of thumb.
System Requirements

Determining system requirements is a very important part of the system design process. Although this document is not intended to describe this process, due to its importance, I will briefly touch on it here. Without proper determination of system requirements, the project is most likely doomed to fail. The steps in this process are generally as follows:

1. Determine the current capabilities of the present system from the user's point of view.
2. Describe (or reference documentation about) the equipment to be part of the system or that the system must interface with along with protocols and physical media used. Consider some typical calculations the system will do.
3. Get all input possible from user's and technical staff to determine additional capabilities and features to add. Also determine how strongly these features and capabilities are desired.
4. Determine the priorities of proposed features and capabilities.
5. Determine expected system performance including quality features ad discussed in the Management Guide in the management section.
6. Perform a preliminary risk assessment of all proposed features and system capabilities. Factors affecting risk include:
* Difficulty and cost of the feature or capability.
* How easily the feature can be supported by current technology.
* Political implications of including the feature.
* The risk of placing the wrong requirements or wrong emphasis of requirements on the system.
* Whether the organization has staff with the technical skills to build and maintain the system.
7. Determine which system features and capabilities to include in the first iteration by using priority and risk assessment. As the risk rises and the priority of the feature drops, it is less desirable to include the feature in an early iteration. However, if a required feature of the project has a high degree of risk, the risk must be properly assessed through testing or whatever means possible early in the project cycle to determine if the project is actually feasable.

System characteristics that may be important to consider when developing requirements are:

* Scalability - Involves capacity management so increasing user demand may be met and managed efficiently. The system may supply performance information allowing administrators to change configuration to enhance performance for increased demand
* Database connectivity - Efficient data flow - The system can manage the requests to the database (if required) along with caching requests when appropriate, thereby relieving and managing some of the load on the database server (if the system interfaces to one).
* Security - There may be requirements to secure or encrypt information between different parts of the system or between the system and other systems.
* Integration - Provides support to integrate with other or older systems.
* Failure management.
* Stability of the system.
* How easy will the system be to use and learn?

When determining system requirements it is helpful to consider and outline the following:

* Goals of the system.
* System functions
* Categorize functions as essential, hidden and optional. Hidden functions are those functions that the user does not see.
* Determine system characteristics (otherwise known as attributes). These are performance considerations such as system boundary constraints, how fast the system operates, and how easy it is to use.

All system function characteristics must be characterized as required or desired.
Functional System Breakdown

One helpful way to simplify a system is to break it down into levels. Generally, an interface may be developed between these levels to keep changes in one level from effecting another level. Most networking protocols in use today use this method and it works quite well. Some levels may include:

* Display interface for the user.
* Data storage interface.
* Controller interface.

Another way to break a system down is to determine its areas of functionality and attempt to conceptually separate these parts of the system.

1. Draw the overall system use case diagram including initialization. Only consider how the main system will interact with actors on the outside of the system boundary.
2. Consider the main functional steps that the system must perform in order to make the use case happen. Below is listed some example functional areas systems must deal with.
* User authentication - Be sure the user is authorized to use the system and determine their security access level. This will be compared to resources and resource lists to allow the user to see and list resources at their security level.
* Resource posting - Determining resources or information provided by the system that is available to actors outside the system. How the actors will get this information? Also consider security issues.
* Resource determination - Determine resources that are available to the system and information that the system can get from these resources.
* Data storage
* Data display
3. Consider the type of data that is saved or passed around the system. In light of the functional areas above, what kind of data should each functional area deal with or what parts of the data should those functional areas have access to?

Once the above steps/considerations have been made, it may be possible to break the system down into subsystems dependent on functionality with regard to dataflow. This can help simplify the system by breaking one large problem into a series of smaller problems. At this point it should be possible to create use case diagrams for each subsystem and begin the UML process.

Starting UML

Starting UML

As mentioned in the introduction, UML has four pro

ject phases:

* Inception Phase - Approximately 20% of requi rements determined.
* Elaboration Phase - Approximately 80% of requirements determined.
* Construction Phase
* Transition Phase

These phases and what I perceive should be done in each of them are described here.

Inception Phase

This is the part of the project where the original idea is developed. The amount of work done here is dependent on how formal project planning is done in your organization and the size of the project. During this part of the project some technical risk may be partially evaluated and/or eliminated. This may be done by using a few throw away prototypes to test for technical feasability of specific system functions. Normally this phase would take between two to six weeks for large projects and may be only a few days for smaller projects. The following should be done during this phase:

1. Project idea is developed.
2. Assess the capablilities of any current system that provides similar functionality to the new project even if the current system is a manual system. This will help determine cost savings that the new system can provide.
3. Utilize as many users and potential users as possible along with technical staff, customers, and management to determine desired system features, functional capabilities, and performance requirements. Analyze the scope of the proposed system.
4. Identify feature and functional priorities along with preliminary risk assessment of each system feature or function.
5. Identify systems and people the system will interact with.
6. For large systems, break the system down into subsystems if possible.
7. Identify all major use cases and describe significant use cases. No need to make expanded use cases at this time. This is just to help identify and present system functionality.
8. Develop a throw away prototype of the system with breadth and not depth. This prototype will address some of the greatest technical risks. The time to develop this prototype should be specifically limited. For a project that will take about one year, the prototype should take one month.
9. Present a business case for the project (white paper) identifying rough cost and value of the project. The white paper is optional for smaller projects. Define goals, estimate risks, and resources required to complete the project.
10. Set up some major project milestones (mainly for the elaboration phase). A rough estimate of the overall project size is made.
11. Preliminary determination of iterations and requirements for each iteration. This outlines system functions and features to be included in each iteration. Keep in mind that this plan will likely be changes as risks are further assessed and more requirements are determined.
12. Management Approval for a more serious evaluation of the project.

This phase is done once the business case is presented with major milestones determined (not cast in stone yet) and management approves the plan. At this point the following should be complete:

* Business case (if required) with risk assessment.
* Preliminary project plan with preliminary iterations planned.
* Core project requirements are defined on paper.
* Major use cases are defined.

The inception phase has only one iteration. All other phases may have multiple iterations.

Elaboration Phase

The primary purpose of this phase is to complete the most essential parts of the project that are high risk and plan the construction phase. This is the part of the project where technical risk is fully evaluated and/or eliminated by building the highest risk parts of the project. During this phase personnel requirements should be more accurately determined along with estimated man hours to complete the project. The complete cost and time frame of the project is more firmly determined. During this phase how the system will work must be considered. Use cases will help identify risks. Steps to take during this phase:

1. Complete project plan with construction iterations planned with requirements for each iteration.
2. 80% of use cases are completed. Significant use cases are described in detail.
3. The project domain model is defined. (Don't get bogged down)
4. Rank use cases by priority and risk. Do the highest priority and highest risk use cases first. Items that may be high risk:
* Overall system architecture especially when dealing with communication between subsystems.
* Team structure.
* Anything not done before or used before such as a new programming language, or using the unified/iterative process for the first time.
5. Begin design and development of the riskiest and highest priority use cases. There will be an iteration for each high risk and priority use case.
6. Plan the iterations for the construction phase. This involves choosing the length of the iterations and deciding which use cases or parts of use cases will be implemented during each iteration. Develop the higher priority and risk use cases during the first iterations in the construction phase.

As was done on a preliminary level in the previous phase, the value (priority) of use cases and their respective risks must be more fully assessed in this phase. This may be done be either assigning an number to each use case for both value and risk. or categorize them by high, medium, or low value and risk. Time required for each use case should be estimated to the man week. Do the highest priority and highest risk use cases first.

Requirements to be completed for this phase include:

* Description of the software architecture. Therefore most use cases should be done, activity diagrams, state charts, system sequence diagrams, and the domain model should be mostly complete.
* A prototype that overcomes the greatest project technical risk and has minimal high priority functionality.
* Complete project plan.
* Development plan.

There may be an elaboration phase for each high risk use case.

This is the point at which I believe many of the steps in the Unified Process become vague. Considering the various diagrams and charts to be created, when they are created, and the best order to create them in, there seems to be a variety of opinions. I believe this is because in the real world there may be more than one correct solution and there are no hard and fast rules that work everytime. In a way, this flexibility is a strength of UML. Some documentation indicates that most use cases should be done before creating a domain model and others indicate that the domain model can be built on a use case by use case basis. A good compromise is to spend a short time on a brief domain model during the elaboration phase, then enhance the domain model as each use case is developed during the elaboration and construction phase iterations. Some documentation indicates that activity diagrams and class diagrams should be complete before the domain model is done. It is possible to create some of the diagrams and charts (artifacts) in parallel with each other. I'm not sure there is really any correct best way to do this, but I favor the following order.

1. Completion of 80% of use case diagrams.
2. Completion of 80% of high level use case diagrams.
3. Completion of expanded use case diagrams for major use cases only.
4. System sequence diagrams for major use cases.
5. Domain model (Don't get bogged down here with details). Just get a good idea of concepts involved. Use use cases to create the domain model. Any use case that strongly impacts the domain model should be considered and concepts from that use case should be incorporated in the domain model. The initial domain model may be drawn without lines and attributes to avoid too much detail and determine important use cases. The domain model may be refined later as the project analysis continues. If the system is large, domain models should be done on a per use case basis.
6. Optionally create a glossary of terms for concepts to improve team communication.

After this point the design part of the project begins (although more analysis is done for each use case) and the following will be done in each iteration of the elaboration and construction phases.

1. Operation contracts based on domain model and use cases.
2. Collaboration diagrams.
3. Class diagrams.
4. Map class and collaboration diagrams to code.
5. Update the domain model but do not force it to the class diagrams.

Considerations during this project should be the following:

* Consider possible significant changes (down the road) to the system during analysis.
* Regarding system functional ability what do you expect to be able to change?

Construction Phase

Construction iterations are based on use cases. Small use cases may be done in one iteration or a larger use case may be worked on in sections. For each iteration, analysis, design, and creation of software is performed for each use case in that iteration. As I understand the process, the following would be done for each construction iteration per use case. Again, much documentation indicates that the domain model (conceptual model) should be done for each construction iteration and be based on use cases being implemented during that specific iteration. The following should be done during the construction iterations:

1. Completion of expanded use case diagrams for use cases.
2. System sequence diagrams for major use cases.
3. Operation contracts based on domain model and use cases.
4. Collaboration diagrams.
5. Class diagrams.
6. Map class and collaboration diagrams to code.
7. Update the domain model but do not force it to the class diagrams.

It is worth performing tests to be sure each use case works properly at the end of the iteration. At the end of the construction phase there is a product that users can use. The following will be complete:

* Users manuals.
* Release version and description.

Transition Phase

During this phase, the finished product is brought to the user. Items to be addressed in this phase include:

* Final program debugging
* Code Optimization
* Beta testing
* Completion of manuals.
* User training
* Possible operation in parallel with an existing system.

Iterations

Iterations mostly occur in the elaboration and construction phases, but may occur in any phase.

As iterations progress, integration of the various iterations into each other should constantly be done so integration is not left at the end of the project. Each iteration should be complete at the scheduled time. If time becomes a problem, some use cases may need to be moved to other iterations. The plan may need to be changed every two to three iterations especially if you are finding out that many use cases are being moved to later iterations.

Testing

During the construction phase unit and integration testing will be done. At the end of the construction phase, system testing is done. Unit testing is based on use cases and tests to be sure the system can perform the use case functions. Integration testing ensures that the various construction iterations (based on use cases) can interface with each other.

Common Pitfalls to the Process

* Domain models are static (not behavior oriented).
* Domain models are an analysis artifact (not design) - Once the first domain model is constructed, when the second iteration is done, modify the original domain model rather than imposing design class diagrams on the domain model.
* Design is responsibility driven (not speculative) - Conciously use GRASP patterns.
* Not following the basics with GRASP patterns.
* Not recognizing the 20% of exceptions to GRASP patterns where design patterns should be used.

UML Patterns

UML Patterns

UML patterns are used to determine responsibility assignment for objects to interact in a collaboration diagram. Patterns are:

* Identified as a solution.
* A solution to a specific problem type. The solution has a name.
* Solution ideas from experts.

There are several different sets of patterns. The patterns used for collaboration diagram responsibility assognment are General Responsibility Assignment Software Patterns (GRASP). There are:

* Low coupling
* High cohesion
* Expert
* Creator
* Controller
* Pure fabrication
* Indirection
* Don't talk to strangers
* Polymorphism

Use Patterns:

* Evaluative - Patterns that indicate the degree of flexability of the design.
o Low coupling - Coupling measures how much one class relies on another class or is connected to another class. If there are many lines between objects, coupling is high.
o High cohesion - Keep the class as uncomplicated as possible. Don't perform functions not necessary for the respective class.
* Driving Patterns - Patterns used for problem solving.
o Expert - The responsibility is assigned to the information expert. Who has the required information? Who is the expert with the requested information?
o Creator - The one who creates something. Use the creater pattern when one or more of the following are true:
+ The creating class aggregates the class to be created.
+ The creating class contains the class to be created
+ The creating class closely uses the class to be created
+ The creating class records the class to be created
o Controller - An interface between two layers such as the user and domain layer. This pattern supports low coupling and high cohesion. It handles event messages. Serves as a wrapper for a lower or domain layer. Events are received and passed through the controller.
o Polymorphism - A class that is a subclass of a superclass performs the operation itself. This way an operation sent to the subclass can be the same operation but it is specific for the needs of that subclass. Same message, different method.
o Pure fabrication - Make a class that performs some of the work in order to keep one class less complicated.
o Indirection - Assign responsibility to an intermediate object.
o Don't talk to strangers - Promote the interface. Talking to strangers causes high coupling since the object must interface with many objects. Messages cannot be sent to any other than the following from the method receiving the message:
+ A parameter of the method called by the message.
+ The self object which is the receiver.
+ A receiver attribute that references another object or an element in the referenced collection object.
+ An object that the method created.

This pattern is being replaced by one called "Protected Variation" which is a synonym to the open/close principles. The open close principles mean the design is open to extension but it is closed to modification. Many times Generalization is used to support this. Additional generalizations (or subclasses) can be added to objects without changing surounding objects.

* Design Patterns
o Singleton (GoF) - Ensure a class has one instance and provide a global path to it. How to implement using java.
o State (GoF) - The state pattern passes a reference to the state it wants to set.

o Class Depot

o {

o public static getInstance() //Get instance of the single depot

o {

o return instance;

o }

o private static Depot instance = new Depot();

o private Depot()

o {

o }

o }

Java creates the depot the first time getInstance() is called.

o Prototype - Used to make a copy of an object so the copy can be modified without changing the original.
o Flyweight - Don't make the object copy until you change it. References the template directly then apply prototype when a change is made. This pattern uses less memory by not actually making the copy until required.
o Facade (GoF) - An object represents the system as a controller.
o Command - A class for each message. The message is a command. The class has an execute method.
o Forwarder-Receiver (Siemens) - For message handling.
o Layers (Siemens) - Place login in the domain layer, not presentation layer.
o Model-View Separation (Domain-Presentation Separation) - Domain objects do not directly send messages to presentation objects. View objects send messages to domain objects to get information to display.
o Publish-Subscribe (Observer) - A means of allowing the presentation layer to get events to display from the domain layer without polling. An object in the presentation layer would subscribe to be notified of events in the domain layer.

Proxy/Remote Proxy (GoF) - Make a class that represents the actual class invloved and let the local class communicate with the actual class.

The power of patterns comes with combining them. Design patterns are for specific coding solutions.

UML Terms

UML Terms

* Abstract class - A class that will never be instantiated. An instance of this class will never exist.
* Actor - An object or person that initiates events the system is involved with.
* Aggregation - Is a part of another class. Shown with a hollow diamond next to the containing class in diagrams.
* Artifacts - Documents describing the output of a step in the design process. The description is graphic, textual, or some combination.
* Association - Describe important relationships between concepts or objects and may be bidirectional
* Attributes - Characteristics of an object which may be used to reference other objects or save object state information.
* Class diagram - Shows the system classes and relationships between them.
* Collaboration diagram - A diagram that shows how operations are done while emphasizing the roles of objects.
* Concept - A noun or abstract idea to be included in a domain model.
* Construction phase - The third phase of the Rational Unified Process during which several iterations of functionality are built into the system under construction. This is where the main work is done.
* Domain -The part of the universe that the system is involved with.
* Elaboration phase - The second phase of the Rational Unified Process that allows for additional project planning including the iterations of the construction phase.
* Encapsulation - Data in objects is private.
* Generalization - Indicates that one class is a subclass on another class (superclass). A hollow arrow points to the superclass.
* GoF - Gang of Four set of design patterns.
* High cohesion - A GRASP evaluative pattern which makes sure the class is not too complex, doing unrelated functions.
* Low coupling - A GRASP evaluative pattern which measures how much one class relies on another class or is connected to another class.
* Inception phase - The first phase of the Rational Unified Process that deals with the original conceptualization and beginning of the project.
* Inheritance - Subclasses inherit the attributes or characterics of their parent (superclass) class. These attributes can be overridden in the subclass.
* Instance - A class is used like a template to create an object. This object is called an instance of the class. Any number of instances of the class may be created.
* Iteration - A mini project section during which some small piece of functionality is added to the project. Includes the development loop of analysis, design and coding.
* Message - A request from one object to another asking the object receiving the message to do something. This is basically a call to a method in the receiving object.
* Method - A function or procedure in an object.
* Model
* Multiplicity - Shown in a domain model and indicated outside concept boxes, it indicates object quantity relationshipt to quanties of other objects.
* Notation - Graphical document with rules for creating analysis and design methods.
* Object - An instantiation of a class which includes attributes (variables) and methods (functions).
* Package - A group of UML elements that logically should be grouped together.
* Pattern - Solutions used to determine responsibility assignment for objects to interact. It is a name for a successful solution to a well known common problem.
* Polymorphism - Same message, different method. Also used as a pattern.
* Reading Direction arrow - Indicates the direction of a relationship in a domain model.
* Role - Used in a domain model, it is an optional description about the role of an actor.
* Sequence diagram - A diagram that shows how operations are done.
* Statechart diagram - A diagram that shows all possible object states.
* Time boxing - Each iteration will have a time limit with specific goals.
* Transition phase - The last phase of the Rational Unified Process during which users are trained on using the new system and the system is made available to users.
* UML - Unified Modeling Language utilizes text and graphic documents to enhance the analysis and design of software projects by allowing more cohesive relationships between objects.
* Use case - Describes event sequences for an actor to use the system. It is a narrative description of the process.
* Workflow - A set of activities that produces some specific result.