Soft Engg Assign 2

7/28/2019 Soft Engg Assign 2

1/4

OBJECT ORIENTED S/W ENGINEERING WITH UMLMT-21

ASSIGMENT-2

Q 1.What is the difference between object oriented analysis and object oriented design?

Ans.1

Object-oriented analysis and design (OOAD) is asoftware engineeringapproach that models a system

as a group of interactingobjects. Each object represents some entity of interest in the system being

modeled, and is characterized by its class, its state (data elements), and its behavior. Various models can

be created to show the static structure, dynamic behavior, and run-time deployment of these collaborating

objects. There are a number of different notations for representing these models, such as theUnified

Modeling Language(UML).

Object-oriented analysis (OOA) applies object-modeling techniques to analyze thefunctional

requirementsfor a system.Object-oriented design(OOD) elaborates the analysis models to produce

implementation specifications. OOA focuses on what the system does, OOD on how the system does i

Object-oriented systems

An object-oriented system is composed ofobjects. The behavior of the system results from the

collaboration of those objects. Collaboration between objects involves them sending messages to each

other. Sending a message differs from calling a function in that when a target object receives a message,

it decides on its own what function to carry out to service that message. The same message may be

implemented by many different functions, the one selected depending on the state of the target object.

The implementation of "message sending" varies depending on the architecture of the system being

modeled, and the location of the objects being communicated with.

Object-oriented analysis

Object-oriented analysis (OOA) is the process of analyzing a task (also known as a problem domain) to

develop a conceptual model that can then be used to complete the task. A typical OOA model would

describe computer software that could be used to satisfy a set of customer-defined requirements. During

the analysis phase of problem-solving, the analyst might consider a written requirements statement, a

formal vision document, or interviews with stakeholders or other interested parties. The task to be

addressed might be divided into several subtasks (or domains), each representing a different business,

technological, or other areas of interest. Each subtask would be analyzed separately. Implementation

constraints, (e.g.,concurrency,distribution,persistence, or how the system is to be built) are not

considered during the analysis phase; rather, they are addressed during object-oriented design (OOD).
http://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Object_(computer_science)http://en.wikipedia.org/wiki/Object_(computer_science)http://en.wikipedia.org/wiki/Object_(computer_science)http://en.wikipedia.org/wiki/Unified_Modeling_Languagehttp://en.wikipedia.org/wiki/Unified_Modeling_Languagehttp://en.wikipedia.org/wiki/Unified_Modeling_Languagehttp://en.wikipedia.org/wiki/Unified_Modeling_Languagehttp://en.wikipedia.org/wiki/Functional_requirementshttp://en.wikipedia.org/wiki/Functional_requirementshttp://en.wikipedia.org/wiki/Functional_requirementshttp://en.wikipedia.org/wiki/Functional_requirementshttp://en.wikipedia.org/wiki/Object-oriented_designhttp://en.wikipedia.org/wiki/Object-oriented_designhttp://en.wikipedia.org/wiki/Object-oriented_designhttp://en.wikipedia.org/wiki/Object_(computer_science)http://en.wikipedia.org/wiki/Object_(computer_science)http://en.wikipedia.org/wiki/Object_(computer_science)http://en.wikipedia.org/wiki/Problem_domainhttp://en.wikipedia.org/wiki/Problem_domainhttp://en.wikipedia.org/wiki/Problem_domainhttp://en.wikipedia.org/wiki/Concurrency_(computer_science)http://en.wikipedia.org/wiki/Concurrency_(computer_science)http://en.wikipedia.org/wiki/Concurrency_(computer_science)http://en.wikipedia.org/wiki/Distributed_computinghttp://en.wikipedia.org/wiki/Distributed_computinghttp://en.wikipedia.org/wiki/Distributed_computinghttp://en.wikipedia.org/wiki/Persistence_(computer_science)http://en.wikipedia.org/wiki/Persistence_(computer_science)http://en.wikipedia.org/wiki/Persistence_(computer_science)http://en.wikipedia.org/wiki/Persistence_(computer_science)http://en.wikipedia.org/wiki/Distributed_computinghttp://en.wikipedia.org/wiki/Concurrency_(computer_science)http://en.wikipedia.org/wiki/Problem_domainhttp://en.wikipedia.org/wiki/Object_(computer_science)http://en.wikipedia.org/wiki/Object-oriented_designhttp://en.wikipedia.org/wiki/Functional_requirementshttp://en.wikipedia.org/wiki/Functional_requirementshttp://en.wikipedia.org/wiki/Unified_Modeling_Languagehttp://en.wikipedia.org/wiki/Unified_Modeling_Languagehttp://en.wikipedia.org/wiki/Object_(computer_science)http://en.wikipedia.org/wiki/Software_engineering


2/4

The conceptual model that results from OOA will typically consist of a set ofuse cases, one or

moreUMLclass diagrams, and a number ofinteraction diagrams. It may also include some kind ofuser

interfacemock-up. Object-oriented analysis (OOA) looks at the problem domain, with the aim of

producing a conceptual model of the information that exists in the area being analyzed. Analysis

models do not consider any implementation constraints that might exist, such as concurrency,

distribution, persistence, or how the system is to be built. Implementation constraints are dealt duringobject-oriented design (OOD). Analysis is done before the Design

The sources for the analysis can be a written requirements statement, a formal vision document,

interviews with stakeholders or other interested parties. A system may be divided into multiple

domains, representing different business, technological, or other areas of interest, each of which are

analyzed separately.

The result of object-oriented analysis is a description ofwhat the system is functionally required to

do, in the form of a conceptual model. That will typically be presented as a set of use cases, one or

more UML class diagrams, and a number of interaction diagrams. It may also include some kind of

user interface mock-up. The purpose of object oriented analysis is to develop a model that describes

computer software as it works to satisfy a set of customer defined requirements.

Object-oriented design

During object-oriented design (OOD), a developer applies implementation constraints to the conceptual

model produced in object-oriented analysis. Such constraints could include not only constraints imposed

by the chosen architecture but also any non-functional technological or environmental constraints,

such as transactionthroughput, response time, run-time platform, development environment, or those

inherent in the programming language. Concepts in the analysis model are mapped onto implementation

classes and interfaces resulting in a model of the solution domain, i.e., a detailed description ofhow the

system is to be built.

Object-oriented design (OOD) transforms the conceptual model produced in object-oriented analysis to

take account of the constraints imposed by the chosen architecture and any non-functional -

technological or environmental - constraints, such as transaction throughput, response time, run-

time platform, development environment, or programming language.

The concepts in the analysis model are mapped onto implementation classes and interfaces. The

result is a model of the solution domain, a detailed description ofhow the system is to be built.
http://en.wikipedia.org/wiki/Use_caseshttp://en.wikipedia.org/wiki/Use_caseshttp://en.wikipedia.org/wiki/Use_caseshttp://en.wikipedia.org/wiki/Unified_Modeling_Languagehttp://en.wikipedia.org/wiki/Unified_Modeling_Languagehttp://en.wikipedia.org/wiki/Class_diagramhttp://en.wikipedia.org/wiki/Class_diagramhttp://en.wikipedia.org/wiki/Class_diagramhttp://en.wikipedia.org/wiki/Interaction_diagramhttp://en.wikipedia.org/wiki/Interaction_diagramhttp://en.wikipedia.org/wiki/Interaction_diagramhttp://en.wikipedia.org/wiki/User_interfacehttp://en.wikipedia.org/wiki/User_interfacehttp://en.wikipedia.org/wiki/User_interfacehttp://en.wikipedia.org/wiki/User_interfacehttp://en.wikipedia.org/wiki/Throughputhttp://en.wikipedia.org/wiki/Throughputhttp://en.wikipedia.org/wiki/Throughputhttp://en.wikipedia.org/wiki/Throughputhttp://en.wikipedia.org/wiki/User_interfacehttp://en.wikipedia.org/wiki/User_interfacehttp://en.wikipedia.org/wiki/Interaction_diagramhttp://en.wikipedia.org/wiki/Class_diagramhttp://en.wikipedia.org/wiki/Unified_Modeling_Languagehttp://en.wikipedia.org/wiki/Use_cases


3/4

Q 2. What are the critical practices used in the S/W engineering?

Ans.2

Software Engineering Practice consists of a collection of concepts, principles, methods, andtools that a software engineer calls upon on a daily basis. Equips managers to manage softwareprojects and software engineers to build computer programs. Provides necessary technical andmanagement how to in getting the job done. Transforms a haphazard unfocused approach intosomething that is more organized, more effective, and more likely to achieve success

Seven Core Principles for Software Engineering:

1) Remember the reason that the software exists The software should provide value to its users and satisfy the

requirements2) Keep it simple, stupid (KISS)

All design and implementation should be as simple as possible3) Maintain the vision of the project

A clear vision is essential to the projects success4) Others will consume what you produce

Always specify, design, and implement knowing that someone else willlater have to understand and modify what you did

5) Be open to the future Never design yourself into a corner; build software that can be easily

changed and adapted6) Plan ahead for software reuse

Reuse of software reduces the long-term cost and increases the value of

the program and the reusable components7) Think, then act

Placing clear, complete thought before action will almost always producebetter results

The "16 Critical Software Practices for Performance-based Management" and Templatescontain the 16 practices (9 best and 7 sustaining) that are the key to avoiding significantproblems for software development projects. These practices have been gathered from thecrucible of real-world, large-scale, software development and maintenance projects. Togetherthey constitute a set of high-leverage disciplines that are focused on improving a project'sbottom line. This document is intended to define the essential ingredients of each best andsustaining practice. These practices are the starting point for structuring and deploying an

effective process for managing large-scale software development and maintenance. They maybe tailored to the particular culture, environment, and program phases of a program. Of course,these practices cannot help "death march" programs that are expected to deliver underimpossible schedule deadlines with inadequate funding and without the required staffing withessential skills.

16 Critical Software Practices for Performance-Based Management


4/4

Adopt continuous risk management. Estimate cost and schedule empirically. Use metrics to manage. Track earned value. Track defects against quality targets.

Treat people as the most important resource. Adopt life cycle configuration management. Manage and trace requirements. Use system-based software design. Ensure data and database interoperability. Define and control interfaces. Design twice, code once. Assess reuse risks and costs. Inspect requirements and design. Manage testing as a continuous process. Compile and smoke test frequently.

Documents

Soft Engg Assign 2