CAPE INSTITUTE OF TECHNOLOGY

Levengipuram, Rajakrishnapuram (P. O) 627 114

Tirunelveli District, TamilNadu
(Affiliated To Anna University Chennai)
LABORATORY MANUAL
OBJECT ORIENTED ANALYSIS AND DESIGN LAB (CS 66)
REGULATION 2008
B.Tech Information Technology
(2012 2013 EVEN)
VI Semester
Prepared by
Ms. S.R.Arun, AP/IT
Mr. A. J egatheesan, AP
Head, Department of Information Technology
Syllabus

CS66 OOAD LAB 0 0 3 2
OBJECTIVE:
To develop a mini-project following the 12 exercises listed below.
1. To develop a problem statement.
2. Develop an IEEE standard SRS document. Also develop risk management and project
plan (Gantt chart).
3. Identify Use Cases and develop the Use Case model.
4. Identify the business activities and develop an UML Activity diagram.
5. Identity the conceptual classes and develop a domain model with UML Class diagram.
6. Using the identified scenarios find the interaction between objects and represent them
using UML Interaction diagrams.
7. Draw the State Chart diagram.
8. Identify the User Interface, Domain objects, and Technical services. Draw the partial
layered, logical architecture diagram with UML package diagram notation.
9. Implement the Technical services layer.
10. Implement the Domain objects layer.
11. Implement the User Interface layer.
12. Draw Component and Deployment diagrams.
Suggested domains for Mini-project.
1. Passport automation system.
2. Book bank
3. Exam Registration
4. Stock maintenance system.
5. Online course reservation system
6. E-ticketing
7. Software personnel management system
8. Credit card processing
9. e-book management system
10. Recruitment system
11. Foreign trading system
12. Conference Management System
13. BPO Management System
Suggested SoftwareTools
ArgoUML, Eclipse IDE, Visual Paradigm, Visual case, and Rational Suite
Ex.No:1A) INTRODUCTION TO SOFTWARE ENGINEERING TECHNIQUES
Aim: To study the basics of Software Engineering Techniques
Project planning:
The objective of software project planning is to provide a framework that enables the
manager to make reasonable estimates of resources cost and schedule. The first activity in software
project planning is the determination of software scope. Software scope describes the data and
control to be processed, function, performance, constraints, interfaces and reliability. The second
software-planning task is estimation of the resources required to accomplish the software
development effort.
Software cost and effort estimation is an important factor to be considered. Variables like
human, technical, environmental, and political will affect the ultimate cost of software and effort
applied to develop it.
Software Requirements Analysis:
Requirements Analysis is a software engineering task that bridges the gap between system
level requirement engineering and software. Requirements engineering activities result in the
specification of softwares operational characteristics such as data and functional behavior.
Requirements analysis allows the software Engineer to refine the software allocation and
build models of the data, functional and behavioral domain that will be treated by software.
Data Modeling:
The data model consist of three interrelated pieces of information the data objects, the
attributes that describes the data object and the relationships that connect data objects to one another.
A data object is the representation of almost any composite information that must be
understood by software. composite information means something that has number of different
properties or attributes. A data object can be an external entity, a thing, an occurrence or event, a
role, an organizational unit, a place or a structure.
The attributes define the properties of data objects and take on one of three different
characteristics. They can be used to name an instance of the data object, describes the instance or
make reference to another instance in another table.
Data objects are connected to one another in different ways. Data model must be capable of
representing the number of occurrences of object in a given relationship.
Software Testing:
Software testing is the critical element of software quality assurance and represents the
ultimate review of specification design and code generation.
Testing is a process of executing a program with the intent of finding an error. The objective
is to design test the systematically uncover different classes of errors and to do so with minimum
amount of time and effort.
Different types of testing approaches used are black box testing and white box testing.
Black box test are used to demonstrate that the s/w functions are operational that is input is
properly accepted and output is correctly produced.
White box testing of software is predicated on a close examination of procedural detail.
Logical paths through the software are tested by providing test cases that exercise specifies sets of
condition and loops. The status of the program may be examined at various points to determine if the
expected status corresponds to the actual status.
Software Debugging:
It is an exercise to connect manifestation of the error and the internal cause of the error.
Debugging techniques include:
Break points - Break point is a computer program at which execution can be
suspended to permit manual or automated monitoring of program performance or results.
Desk checking - Desk checking is a technique in which code listings, test results
or other documentation are visually examined, usually by the person who generated them,
to identify errors, violations of development standards or other problems.
Dumps - Dumps display some aspect of a computer programs execution
state, usually the contents of internal storage or registers.
Single-step operation- In this debugging technique a single computer instruction, is
executed in response to an external signal.
Traces - A record of the execution of computer program, showing the
sequence of instructions executed, the names and values of variables or both.
Result:
Thus the basics of Software Engineering Techniques are studied.
Ex.No:1B) FUNDAMENTALS OF RATIONAL ROSE SOFTWARE
Aim: To know about the fundamentals of Rational Rose Software.
Introduction:
Models are constructed using views to depict different perspectives and diagrams to depict
a systems building blocks. A model is a simplification of reality or the blue print of the system. An
Architectural view can be defined as a simplified description of a system from a particular
perspective or vantage point, covering particular concerns and omitting that are not relevant to this
perspective. Diagrams are the meansby which we can visualize collections of these abstractions.
Visual modeling:
In the world today, we have business processes and computer systems. As software
professionals our challenge lies in mapping the two. That is where modeling comes in. Modeling
involves capturing the important real world things and mapping these things to computer systems.
Unified Modeling Language:
The Language of visual modeling is the UML. It can be used to visualize, specify,
construct and document the artifacts of software system. It is a standard language that may be
understood by everyone dealing with the project, - customers, domain experts, analyst, designers,
implementers, testers, trainers and so on.
Views: A View is a perspective of the model that is meaningful to specific stakeholders. When
you construct models, you can choose to create only those views significant for that iteration of
development and of value to the project stakeholders. In Rose, you can create the following views:
Use-case View, Logical View, Process View, Component View, Deployment View
Logical View
Analysts/Designers
Structure
Deployment View
System Engineering
System Topology,
Delivery, Installation,
Communication
Logical View
System Integrators
Performance,
Scalability,
Throughput
Implementation
View- Programmers
Software
Management
Use-case
View
End user
Use-Case View:
The Use-Case View is the heart of the other views because it specifies what the system
should do.
Includes the use-case model, which represents the systems intended functions and
environment as seen by its users.
Serves as a contract between customer and developer.
Is essential to analysis and design and test activities.
Includes use-case diagram, use-case flow of events, and supplemental documentation. It can
also include activity diagrams.
Is the heart of other views because it represents the required behavior of the system.
Logical View:
The Logical View supports the functional requirements of the system.
Supports the functional requirements of the system, meaning the services the system should
provide its users.
Includes use-case realizations, class and interaction diagrams. It can also include state chart
and activity diagrams.
Process View:
The Process View addresses the performance, scalability and throughput of the system.
Includes the threads and processes that form the systems concurrency and synchronization
mechanisms.
Addresses the performance, scalability, and throughput of the system.
Is not necessary for a single processing environment.
Component View (Implementation View):
The Component View addresses ease of development, management of software assets,
reuse, and sub-contracting off-the-shelf components.
Describes the organization of static software modules(source code, data files, components,
executables and so on) in terms of packaging ad layering and configuration management.
Deployment View:
The Deployment View addresses issues like deployment, installation and performance.
Is used for distributed systems only and shows one deployment diagram.
Shows how the various executables and other runtime components are mapped to the
underlying platforms or computing nodes.
Addresses issues like deployment, installation and performance.
Diagrams:
A Diagram is a graphical means to view a systems parts including classes, interfaces,
collaborations, generalizations, and associations.
Using Rational Rose the following diagrams can be drawn to facilitate the development process.
Use-case diagrams
Activity diagrams
Interaction diagrams (collaboration and sequence)
Classdiagrams
State chart diagrams
Component diagrams
Deployment diagrams
Stakeholders:
Software architect Responsible for development of the entire project and needs to
understand all aspects of the system.
System Analyst Identifies functionality (Actors and use cases) of the system based on the
user requirements.
Designer Builds the system to meet the specification identified by the analyst, generates the
software.
End-User ensures that the design of the system meets his/her requirements.

Rational Rose Interface:
The Rational rose interface includes the following:
Browser
Diagram window
Diagram tool bar
Documentation window
Log window
Options window
Browser:
The browser allows textually viewing and navigating the views and diagrams in Rational
Rose. It displays the elements that are modeled.
Diagram window:
The diagram window allows creating and updating graphical views of the current model.
Diagram tool bar:
The diagram toolbar includes the elements to build a diagram. Each diagrams toolbar is
unique to that diagram. It is active only when the diagram is displayed.
Documentation Window:
The documentation window is used to create, view or modify text that explains a selected
item within a diagram.
Log Window:
The Log window reports progress, results, and errors. For E.g. Code generation commands
post progress and error messages to this window.
Options Window:
The Options window is used to set all of the faults for modeling. It applies new settings to
future additions made to a diagram.
Result:-
Hence the fundamentals of Rational Rose Software are studied.
Ex.No:2A) PROBLEM ANALYSIS AND PROJECT PLANNING
Aim:
The basic aim of planning is to look into future, identify the activities that need to be done
complete the project successfully and plan the scheduling and resource allocation for these activities.
Description:
Planning is the most important management activity. The input to the planning activity is the
requirements specification, the output of this space is the project plan, which is a document
describing the different aspects of the plan. The project plan is the instrument in driving
development process to remaining phases.
Issues of project plan:
The major issues the project plan addresses are:
1. Cost Estimation
2. Schedule and milestones
3. Personnel Plan
4. Software Quality Assurance Plans
5. Configuration Management Plans
6. Project Monitoring Plans
7. Risk Management
Documents:
1. Cost Estimation
2. Schedule
3. Personnel Plan
Result:
Thus the project-planning phase of software development is studied
Ex.No:2B) RISK MANAGEMENT
Aim:
To study the steps involved in risk management.
Risk:
Risk refers to uncertain future conditions or circumstances that may adversely impact a
project if they occur. A risk represents the possibility, not thecertainty; of a future event affecting
the success of a project. Risk is inherent in all projects. By effectively managing risk, the project
team can reduce the likelihood of occurrence of an adverse event and the impact on the project
should such an event occur.
Risk Management:
Risk management is a repeatable, structured process that identifies and systematically
addresses risks to minimize their affect on projects.
Purpose of Risk Management
A proactive project team tries to resolve potential problems before they occur. This is the art
of risk management. The purpose of risk management is to identify the risk factors for a project and
to then establish a risk management plan that will minimize the probability that risk events may
occur and that, should they occur, their impact on the project will be minimized.
Implementation and Execution
Step 1: Risk Management Planning
Risk Management Planning is concerned with deciding how to approach and plan risk
management activities for a project. The Risk Management Plan is based on identification of risk
events followed by risk quantification, response development (mitigation), and response control
(contingency planning and execution). Risk Management is an iterative process that is initiated at
the start of the project and will continue throughout the project lifecycle.
The project team should consider both the organizations and the project stakeholders
tolerance for risk. Some organizations have very high tolerance for schedule or cost overruns, while
others have very little.
The key factors of risk identification, quantification, response, and control should be actively
managed by the Project Manager.
Risk review should be an item on the project team meeting agendas. It may also be necessary
to convene specific working sessions to assess and manage risk.
Step 2: Risk Identification
At project inception, initial risk identification should be performed. This should be done by
reviewing risks identified (or encountered but not identified) on other projects and by brainstorming
with the project team and key stakeholders.
It is essential that customers/users/stakeholders be involved in the risk identification process,
as well as members of the project team. This will serve to reinforce the concept that risk is inherent
in all projects and that proactively identifying and managing potential risks will increase the
likelihood of project success. At this point, not all details of the project may be known, and these
unknowns may constitute potential risks to the project.
All potential risks should be reviewed by the project team and key stakeholders to assess
probability of occurrence and impact. The Risk Management Matrix can be used for recording and
analysis of all identified risks. All identified potential risk events that are deemed to be relevant to
the project are to be recorded using the Risk Management Matrix. The risk matrix maintains a record
of resolved risks as well as current risks. Note that should a previously unidentified risk event
occur at any point during the project life cycle, this event should be immediately recorded on the
Risk Management Matrix.
Risk identification must include two elements:- The Risk Condition, the cause of a risk event,
and the Risk Consequence, the effect of therisk event on the project.
It may be helpful to define risk conditions as one of three types:
Business Risk A business condition that may arise that would impact the project.
Examples may include introduction of a competitors product, a merger, serious business
downturn or upswing, reorganization, etc.
Technology Risk Introduction of new technology to the organization. This may include
system components that are being developed by outside vendors.
Project Risk All of the things that can happen on a project, including such factors as
personnel turnover, poorly understood requirements, inadequate project plan, insufficient
project budget, work outside the project scope, scope creep, etc.
The risk consequence should define the effect, or impact, on the project in terms of the following
three variables:
The Project Scope - Impact on the ability to deliver all or some of the defined functions
and features of the product or the performance attributes that have been specified, either
explicitly or implicitly, for the product.
The Project Cost - Impact on the ability to deliver the product within the specified
project budget.
The Project Schedule - Impact on the ability to deliver the product within the defined time
frame for the project.
Should the project team be unable to define risk consequences for any of the above three items, it
should be assumed that the identified future event does not pose a risk to the project.
The following table may prove helpful in analyzing risks.
IMPACT SCOPE COST SCHEDULE
TYPE
Business X
Technology X X
Project
Risk identification is an ongoing process to document the future risk events. Any new or
changed risks should be incorporated into the analysis from a project's start through its completion.
All risks are to be recorded on the Risk Matrix.
In addition to project inception, Risk Identification should take place on a formal basis at the
beginning of each major project phase or iteration and any time a significant change to the project
occurs, such as a scope change or changes in key project personnel.
Step 3: Risk Analysis
Risk qualification, quantification and analysis is an ongoing process which evaluates risks to
assess the range of possible project outcomes. The evaluation may be conducted as individual
assessments by assigned team members with the results presented to the project team and
stakeholders for discussion and concurrence, or as working sessions with key project team members
where a joint assessment is recorded.
For each risk the Project Team should address the following sections of the Risk
Identify risk probability
Identify risk areas of impact
Calculate Risk Exposure
Prioritize risks
Step 4: Risk Response Planning
Risk response is the action plan to eliminate, reduce, or minimize the probability of a risk
event occurring and/or the impact of a risk event should it occur. The output from this activity is a
Risk Mitigation Plan that contains a set of actions directed at minimizing the potential occurrence or
impact of risks on a project and a Risk Contingency Plan, to be activated should the risk event occur.
For risks requiring response, there are two strategies that are considered:
Mitigation, a pre-emptive strategy, is concerned with minimizing the threat posed by a risk by
removing the risk, reducing the risk, or avoiding the risk; e.g., benchmarks for performance, start
early, provide training, implement a formal change management process, set expectations, involve
customer in early planning sessions. Risk warning flags or risk outcomes can be a part of the
mitigation plan.
Risk mitigation strategies include the following:
Acceptance
Avoidance
Reduction
Transference
Contingency strategy deals with the impact of a risk by creating a contingency plan that will be
activated should the conditions or warning flags occur, e.g., exceeded expected resolution date, delay
schedules, team is working extended hours, increased staff needs, modified scope.
Contingency plans are necessary for all project risks, including those that have mitigation
plans. They focus on the consequences, when the risk event has occurred.
For each risk, the Project Manager should assign an owner responsible for developing and
maintaining its risk mitigation and contingency plans. The project work plan should contain specific
tasks with dates for the development of mitigation and contingency plans for all risks.
Step 5: Risk Monitoring and Control
The Project Manager should implement and direct mitigation actions, monitor the mitigation
actions to determine their effectiveness, and revise the mitigation strategies as needed. The project
manager should:
Implement the Risk Mitigation Plan
Assess Mitigation Effectiveness
Reassess Exposure
The Project Manager should address probability of risks and impact changes, as well as any new
risks that are identified. Newly identified risks should be subjected to the same risk assessment and
management process.
Risks that have been successfully mitigated should be resolved and that status should be
reflected in the Risk Management Matrix and on project reports. Successful mitigation means
reducing Risk Exposure to a level where the risk is no longer deemed by the project team to be
among the projects Top Risks.
Step 6: Risk Review and Reporting
New risks that have been identified and old risks that have changed within the reporting period
should be communicated in project team meetings and should be included in all Project Status
reporting.
Risk changes will include the following:
Successful mitigation, resulting in retiring or resolving a risk.
Occurrence of a risk event, either previously identified or unidentified.
Activation of a contingency plan or de-activation of that plan.
Re-prioritization of Top Risks based on planned risk identification, risk mitigation or
changing project conditions.
Result:
Hence the steps involved in risk management are studied.
Ex.No:3 SOFTWARE REQUIREMENTS ANALYSIS
Aim:
The basic aim of software requirement analysis is to properly understand the basic needs of
software required developing a system. Problem analysis and requirement specification activities
overlap with movement both activities to other.
Requirements Analysis
Requirements Analysis is the process of understanding the customer needs and expectations
from a proposed system or application and is a well-defined stage in the Software Development Life
Cycle model.
Requirements are a description of how a system should behave or a description of system
properties or attributes. It can alternatively be a statement of what an application is expected to do.
Given the multiple levels of interaction between users, business processes and devices in global
corporations today, there are simultaneous and complex requirements from a single application, from
various levels within an organization and outside it as well.
The Software Requirements Analysis Process covers the complex task of eliciting and
documenting the requirements of all these users, modeling and analyzing these requirements and
documenting them as a basis for system design. A dedicated and specialized Requirements Analyst
is best equipped to handle the job. The Requirements Analysis function may also fall under the
scope of Project Manager, Program Manager or Business Analyst, depending on the organizational
hierarchy.
Software Requirements Analysis and Documentation Processes are critical to software
project success. Requirements Engineering is an emerging field, which deals with the systematic
handling of requirements.
Steps in the Requirements Analysis Process
I. Fix system boundaries
This initial step helps in identifying how the new application integrates with the business
processes, how it fits into the larger picture and what its scope and limitations will be.
II. Identify the customer
In more recent times there has been a focus on identifying who the users or customers of
an application are. Referred to broadly as the stake holders, these indicate the group or groups of
people who will be directly or indirectly impacted by the new application. By defining in concrete
terms who the intended user is, the Requirements Analyst knows in advance where he has to look for
answers. The Requirements Elicitation Process should focus on the wish list of this defined group
to arriveat a valid requirements list.
III. Requirements elicitation
Information is gathered from the multiple stakeholders identified. The Requirements Analyst draws
out from each of these groups what their requirements from the application are and what they expect
the application to accomplish. Considering the multiple stakeholders involved, the list of
requirements gathered in this manner could run into pages. The level of detail of the requirements
list is based on the number and size of user groups, the degree of complexity of business processes
and the size of the application.
a) Problems faced in Requirements Elicitation
Ambiguous understanding of processes
Inconsistency within a single process by multiple users
Insufficient input from stakeholders
Conflicting stakeholder interests
Changes in requirements after project has begun
A Requirements Analyst has to interact closely with multiple work-groups, often with
conflicting goals, to arrive at a bona fide requirements list. Strong communication and people
skills along with sound programming knowledge are prerequisites for an expert Requirements
Analyst.
b) Tools used in Requirements Elicitation
Traditional methods of Requirements Elicitation included stakeholder interviews and
focus group studies. Other methods like flowcharting of business processes and the use of
existing documentation like user manuals, organizational charts, process models and systems or
process specifications, on-site analysis, interviews with end-users, market research and
competitor analysis were also used extensively in Requirements Elicitation.
However current research in Software Requirements Analysis Process has thrown up
modern tools that are better equipped to handle the complex and multilayered process of
Requirements Elicitation. Some of the current Requirements Elicitation tools in use are:
Prototypes
Use cases
Data flow diagrams
Transition process diagrams
User interfaces
IV. Requirements Analysis Process
Once all stakeholder requirements have been gathered, a structured analysis of these can be
done after modeling the requirements. Some of the Software Requirements Analysis techniques used
are requirements animation, automated reasoning, knowledge-based critiquing, consistency
checking, and analogical and case-based reasoning.
V. Requirements Specification
Requirements, once elicited, modeled and analyzed should be documented in clear,
unambiguous terms. A written requirements document is critical so that its circulation is possible
among all stakeholders including the client, user-groups, the development and testing teams. Current
requirements engineering practices reveal that a well-designed, clearly documented Requirements
Specification is vital and serves as
Base for validating the stated requirements and resolving stakeholder conflicts, if any
Contract between the client and development team
Basis for systems design for the development team
Benchmark for project managers for planning project development lifecycle and goals
Source for formulating test plans for QA and testing teams
Resource for requirements management and requirements tracing
Basis for evolving requirements over the project life span
Software requirements specification involves scoping the requirements so that it meets the
customers vision. It is the result of collaboration between the end-user who is often not a technical
expert, and a Technical/Systems Analyst, who is likely to approach the situation in technical terms.
The software requirements specification is a document that lists out stakeholders needs and
communicates these to the technical community that will design and build the system. The challenge
of a well-written requirements specification is to clearly communicate to both these groups and all
the sub-groups within. To overcome this, Requirements Specifications may be documented
separately as
User Requirements - written in clear, precise language with plain text and use cases, for the
benefit of the customer and end-user
System Requirements - expressed as a programming or mathematical model, addressing the
Application Development Team and QA and Testing Team.
Requirements Specification serves as a starting point for software, hardware and database design.
It describes the function (Functional and Non-Functional specifications) of the system, performance
of the system and the operational and user-interface constraints that will govern system
development.
VI. Requirements Management
Requirements Management is the comprehensive process that includes all aspects of software
requirements analysis and additionally ensures verification, validation and trace ability of
requirements. Effective requirements management practices guarantee that all system requirements
are stated unambiguously, that omissions and errors are corrected and that evolving specifications
can be incorporated later in the project lifecycle.
Result:
Thus the requirement analyses of software development are studied.
Ex.No:4 DATA MODELING
Aim:
To study the concepts of data modeling.
Data Model:
A Data model is an abstract representation of a system constructed to understand the system
before building or modifying it. It is a simple presentation of reality. It provides the blue prints of the
system. The models are built to provide better understanding of the system that is being developed.
The models of complex systems are built to comprehend the entire system. Data modeling is
necessary for communication among project teams.
Advantages of Data Modeling:
Help in visualizing a system as it is or as it is expected.
Permit us to specify the structure or behavior of a system and it allows mastering the
complex system.
Provide us a template that guide us in constructing a system and used to generate usable work
products.
Document the decisions that are made.
Help us to capture and precisely state requirements and domain knowledge so that all stake
holders may understand and agree on them.
Give us an idea to carry out certain activities such as organize, find, filter, retrieve, examine
and edit informationabout large systems.
Provide guidelines to explore multiple solutions economically.
Enable us to capture design decisions in a mutable form separate from the requirements.
Enhance and reinforce learning and training and make manipulation of model easy.
The total cost involved in the modeling analysis is much lower than the cost of similar
experimentation conducted with a real system.
Principles of modeling:
Choose the right models
Every model may be expressed at different levels of precision.
The best models are connected to reality.
No single model is sufficient.
A Modeling Language must include:
Model elements fundamental modeling concepts and semantics.
Notation Visual rendering of model elements.
Guidelines expression of usage within the trade.
Data Modeling provides
Clarity
Familiarity
Maintenance
Simplification
Visual Modeling:
Visual modeling is defined as mapping the real world process of a computer system with a
graphical representation or blue print. It captures essential parts of the system. It is a communication
tool, which is used to analyze the design of our application.
Advantages:
Captures business process
Enhance communication
Manage complexity
Define architecture
Permits reuse
Static and Dynamic Data Modeling:
Static model: It can be viewed as an image of system parameters at rest or specific point in
time. Static models are required to represent the structural or static aspect of a system. Static models
presume stability and an absence of change in data over time. E.g. Class Diagram
Dynamic Model: It can be viewed as a collection of procedures or behaviors that taken
together reflect the behavior of a system over a period of time. Dynamic relationships show how the
business objects interact for performing tasks. Examples are Interaction diagrams and Activity
diagrams.
Result:
Thus the data modeling concepts are studied
Ex. No: 5 UNIFIED MODELING LANGUAGE
Aim:
To get a detailed descriptional study of Unified Modeling language
Definition:
The Unified Modeling Language (UML) is a graphical language for visualizing, specifying,
constructing and documenting the artifacts of a software intensive system. UML provides a
vocabulary and the rules for communication and focus on conceptual and physical representation
of the system. So it is a Modeling Language. The UML gives a standard way to write a systems
blueprints, covering conceptual things, such as classes written in a specific programming language,
database schemas and reusable software components.
UML includes both graphical and textual representation. It makes easy to visualize the
system and for better understanding. UML addresses the specification of all the important analysis,
design and implementation decisions and developing and deploying a software- intensive system.
UML models can be directly connected to a variety of programming languages. And it is
sufficiently expressive and free from any ambiguity to permit the direct execution of models, the
simulation of systems and the instrumentation of running systems. UML produces variety of
documents in addition to raw executable code; the artifacts include Requirements, Architecture,
Design, Source code, Project Plans, Test, Prototypes, and Releases.The UML may be used with
any process. Although, it is generally assumed that the process is architecture centric, use case
driven, iterative and incremental.
The UML combines the best of the best fromData modeling concepts (E-R Diagrams),
Business Modeling (workflow), Object Modelingand Component Modeling
UML Usage:
UML has been effectively used in domains such as: EIS(Enterprise Information System),
Banking and financial services, Telecommunications, Transportation, Defense/Aerospace, Retail,
Medical, Electronics, Scientific and Distributed Web-based services. It can be used with all
processes, throughout the development life cycle and across different implementation
technologies.
UML Architecture:
Architecture is used to manage different viewpoints and hence control the iterative and
incremental development of systems throughout its lifecycle. Each of the above 5 views can
standalone so that the different stakeholder can focus on the issues of the systems architecture that
most concerns them. The five views interact with one another.
MODELING A SYSTEMS ARCHITECTURE
Vocabulary,Functionality
System Assembly
configuration
management

Performance, System Topology, distribution,
Scalability, throughput Delivery and Installation
UML Primary goals:
The Primary goals in the design of UML are:
Provide users a ready-to-use, expressive visual modeling language so that they can
develop and exchange meaningful models.
Provide extensibility and specialization mechanisms to extend the core concepts.
Provide the required formal basics for understanding the modeling Language.
Encourage the growth of the OO tools market.
Support development concepts at higher level.
Integrate best practices and methodologies.
Be independent of particular programming languages and development processes.
UML Concepts:
The UML may be used to visually model
The interaction of the application with the outside world
The behavior of the system
The architecture of the enterprise
The components in the system.
Design View Implementation
View
Use Case
View
Process View Deployment
View
The UML can be usedto support the entire lifecycle
See the interaction with the outside world in use-case diagrams.
Visualize object interaction in sequence and collaboration diagrams.
Look at the structure of the system by examining class diagrams.
View the system architecture by looking the defined packages.
Explore the physical nature of the system using component diagrams.
UML Foundations:
The vocabulary of the UML encompasses three kinds of building blocks:
Things Structural, Behavioral, Grouping, Annatational.
Relationships Dependency, Association, Generalization and Realization.
Diagrams Every complex system is best approached through a small set of nearly independent
views of a model. The UML diagrams are classified into static and dynamic diagrams
Static/ Structural Diagrams
1. Class Diagram
2. Object Diagram
3. Interaction Diagram
3.1 Component Diagram
3.2 Deployment Diagram

Dynamic / Behavior Diagrams
1. Use Case Diagram
2. Interaction Diagram
2.1 Sequence Diagram
2.2 Collaboration Diagram
3. State Chart Diagram
4. Activity Diagram
Use-case Diagram: A Use-case diagram is created to visualize the interaction of the system
with the outside world.
Activity Diagram: An activity diagram shows the flow of events within the system.
Sequence diagram: A sequence diagram shows step by step what must happen to accomplish
a piece of functionality provided by the system. A sequence diagram is also known as
interaction diagram.
Collaboration Diagram: This type of diagram shows the object and their links to one
another. A collaboration diagram is also known as interaction diagram.
Class Diagram: Class diagrams are created to show the structure of the system. Class diagrams
contain classes, relationships and multiplicity indicators. A class is a collection of objects with
common - structures, behaviors, relationships and semantics. The UML notation for class is a
compartmented rectangle. The first compartment shows the name of the class. Each class also
has data associated with it, which are represented by set of activities.
State Chart Diagram: A state chart diagram shows the lifecycle of the single class.
Component Diagram: A Component diagram illustrates the organization and dependencies
among software components.
Deployment diagram: A deployment diagram visualizes the distribution of components across
the enterprise.
Extending the UML:
Stereotypes can be used to extend the UML notational elements. Stereotypes may be used
to classify and extend associations, inheritance, relationships, classes, and components.
Examples:
Class Stereotypes: interface, exception, server page
Association Stereotypes: identifying, non identifying
Dependency Stereotypes: include, extend
Component Stereotypes: subsystem
Rules of the UML:
The UML has the following semanticrules to become a well-formed model.
Names - What you can call things, relationships and diagrams.
Scope - The context that gives specific meaning to a name.
Visibility - How those names can be seen and used by others.
Integrity - How things properly and consistently related.
Execution - What it means to run or simulate a dynamic model?
Common Mechanisms in UML:
The UML is made simpler by the presence of four common mechanisms that apply
throughout the language:
Specifications
Adornments
Common divisions
Extensibility mechanisms.
Result:
Thus a detailed description of Unified Modeling language is studied.
EX.NO : ATM SYSTEM
DATE :
Problem Statement:
The Bank client must be able to withdraw an amount from his/her account using Bank
application. Each transaction must be recorded and the client must have the ability to review all
transaction performed against a given account. Recorded transaction must include date, time,
transaction type, amount and account balance after the transaction.The application must verify
that a client can gain access to his/her account by identification through a PIN code (Personal
Identification Number). If the balance is insufficient to cover the requested amount then
application should inform the user and terminate the transaction.
Project Scope:
To analyze the ATMSystem and design the Use case diagram, Sequence diagram,
Collaboration diagram and Class diagram using Rational Rose software.
Problem Analysis:
The client enters the PIN number and required amount.
The system validates the PIN
If the pin number is valid the controller checks the remaining amount in the clients
account
If there is sufficient amount, the requested amount will be given to the client. The balance
amount will be updated in the database.
If the requested amount is not present in the client will be informed that there is no
amount
Object:
This system helps to check the ATM card and give the money to the client.
Infrastructure:
The software required to develop to develop the ATM system isRational Rose
EnterpriseEdition.
Component Diagram
member
controller
Data base
ATM : Member
ATM :
login
ATM :
controller
ATM : Database
Atm:
Logout
4: Check the PIN number
9: check the account
2: enter the PIN number
8: withdraw the amount
13: take the card
6: Take the ATM card
1: insert the card
3: Verify the the PIN number
5: code is invalid
7: pin code is valid
10: Account is possible
12: account is impossible
11: with draw the amount
Collaboration Diagram
ATM : Database
ATM : Member
ATM :
controller
ATM :
login
Atm:
Logout
3: Check the card
4: card is valid
8: Card is invalid
6: store the account
1: insert the ATM card
5: deposit the amount
7: view the account
9: Take the ATM card
2: Verify the card
atmcontroller
checking
withdraw
deposit
checking()
withdraw()
deposit()
member
withdraw
deposit
login()
logout()
deposit()
withdraw()
1
*
1
*
database
log in
store
withdraw
logout
checking
checking()
withdraw()
deposit()
login() 1..*
*
1
*
1
*
1..*
*
Class Diagram
ATM : Member
ATM : login
ATM :
controller
ATM : Database
Atm: Logout
8: withdraw the amount
3: Verify the the PIN number
4: Check the PIN number
7: pin code is valid
10: Account is possible
5: code is invalid
6: Take the ATM card
1: insert the card
2: enter the PIN number
9: check the account
11: with draw the amount
12: account is impossible
13: take the card
Sequence Diagramfor with draw amount
Login
deposit the amount
View account
Logout
Database
Member
Withdraw amount
Use case Diagram
ATM : Member
ATM : login
ATM :
controller
ATM : Database
Atm: Logout
1: insert the ATM card
2: Verify the card
3: Check the card
4: card is valid
5: deposit the amount
6: store the account
7: view the account
9: Take the ATM card
8: Card is invalid
Sequence Diagram for Deposit amount
insert the card
Enter the
password
Performthe
transaction
Take the card
Select type of
transaction
Member access to the ATM
Exit the member in ATM
No more Transaction
More transaction
Password accepted
Password not accepted
Activity Diagram