PROJECT REPORT ON

ANALYSIS MODEL

Computer science &Engineering 3rd Year Sharda university Greater Noida

IN PARTIAL FULFILLMENT OF GRADUATE PROGRAM BACHELOR OF TECHNOLOGY

SUBMITTED BY: AMAN GUPTA ABHISHEK KUMAR C.SRIKAR DEEPAK KUMAR SONI 100101025 100101009 100101071 100101074

Acknowledgement
I am also grateful to my project supervisor Mrs. RITIKA CHUGH

who without his/her help and guidance this project would not have been completed.

I also show my gratitude to my friends and all who contributed in one way or the other in the course of the project

I wish to thank my parents for their tremendous contributions and support both morally and financially towards the completion of this project

Table of Contents
S. No.
1. 2. 3. 5. 6. 7. 8. Content Acknowledgement Objectives The analysis model Goals of analysis model Aims of Analysis Model Types of Object Producing an Analysis Model

9. 10. 11. 12.

Approaches Elements of the Analysis Model Inputs & Outputs Analysis Notations

13

References

Objectives
This Unit will outline the construction of the Analysis ModelBuildingon outputs of Requirements Model. It will describe the basic UML notations associated with analysis and introducenew types of analysis objects . The use cases will be used andrefined and the inputs for Design Model defined..

The analysis model

The analysis model describes the structure of the system or application that you are modeling. It consists of class diagrams and sequence diagrams that describe the logical implementation of the functional requirements that you identified in the use case model.The analysis model identifies the main classes in the system and contains a set of use case realizations that describe how the system will be built. Class diagrams describes the static structure of the system by using stereotypes to model the functional parts of the system. Sequence diagrams realize the use cases by describing the flow of events in the use cases when they are executed. These use case realizations model how the parts of the system interact within the context of a specific use case. You can think of the analysis model as the foundation of the design model since it describes the logical structure of the system, but not how it will be implemented.

Goals of analysis model

Provides the first technical representation of a system Is easy to understand and maintain

 Deals with the problem of size by partitioning the system Uses graphics whenever possible Differentiates between essential implementation information information versus

Helps in the tracking and evaluation of interfaces Provides tools other than narrative text to describe software logic and policy

Aims of Analysis Model

To provide a logical model of the system,, in terms of :: Classes,, Relationships How to get the thing right, now and in the future

Types of Object
Interface
or interface objects "One distinguished role is that of the controller. The controller receives the request to invoke the system operation. The system operation is part of the method interface of the controller." The controller is "responsible for responding to a system operation request." "A design should have interface objects for each related set of operations at the subsystem interface."

Objects-Controller

 All functionality specified in the use case description that is directly dependent on the system environment is placed in interface objects. Actors communicate with the system through these objects. The task is to translate the actors input to the system into events in the system, and to translate these events into something which is presented to the actor

EX-

Entity Object-The entity object models information in the system

that should be held for a longer time, and should typically survivea use case. "To store information, objects [instances] use attributes.To each entity object we can thus tie several attributes. Each attributehas a type, which can be of a primitive data type, ... but it can alsobe of a composite data type which is more complex and that is especiallydefined." The attributes of an object are modelled by an associationwith a name, a cardinality, and a type. These attributes are not objects. Used to model the information that the system will handle over a longer period of time The information should be kept even if the use case has been complete Also used to allocate the behavior that naturally belongs to this information Entity objects use attributes to store information

Control Object-"The control objects

model functionality thatis not naturally tied to any other object. Typically such behaviour ...consists of operating on several different entity objects, doing some computationsand then returning the result to an interface object." Used to model behavior that is not naturally placed in either of another two objects (interface and entity)Typical type of functionality placed in the control objects aretransaction-related behavior, orcontrol sequences specific to one or a few use cases, orfunctionality that separates the entity objects from the interface objects.

Ex-

Subsystem:

"A subsystem groups several objects. Subsystemsmay

include other subsystems." "The task of subsystems is topackage the objects so that the complexity is reduced." "Theaim is to have a strong functional coupling within a subsystem and a weakcoupling between subsystems." Ex-

Producing an Analysis Model

Draft initial class diagram Re-examine behaviour ii n use cases and objects Refine class diagram Execute check Revise class diagram Group classes into packages

Analysis Modeling Approaches

Structured analysis
Considers data and the processes that transform the data as separate entities Data is modeled in terms of only attributes and relationships (but no operations) Processes are modeled to show the 1) input data, 2) the transformation that occurs on that data, and 3) the resulting output data

Object-oriented analysis
Focuses on the definition of classes and the manner in which they collaborate with one another to fulfill customer requirements

Elements of the Analysis Model

Analysis Model Inputs & Outputs

Inputs:
uses cases and use case model problem domain object list Outputs::

class roles and responsibilities [Text] use case description in terms of classes and operations

[text x use case]

completed analysis model class and package diagrams]

Analysis Notations Notations introduced:: class (rectangle containing name,, attributes,, operations) object (rectangle plus obx:Cx) association (by value/aggregation,, cardinality/multiplicity) generalisation (UML term replacing OOSE inheritance) package depends association

REFERENCES:
http://en.wikipedia.org/wiki/File:Analysis_Model_Objects.jpg http://www.rspa.com/spi/analysismodeling.html http://en.wikipedia.org/wiki/Structured_analysis