SlideShare une entreprise Scribd logo
1  sur  6
Télécharger pour lire hors ligne
International Journal of Modern Engineering Research (IJMER)
                www.ijmer.com             Vol.2, Issue.4, July-Aug 2012 pp-1923-1928        ISSN: 2249-6645

                     Oofp: Mapping the Oose Models into Function Points:
                                Rules, Tool and Case Study
                                      1
                                       Durga Gehlot, 2Prof. Meena Sharma
            1
                Departmen of Computer Engineering, Institute of Engineering and Technology, DAVV Indore, India
                 2
                   HOD of Computer Engineering, Institute of Engineering and Technology, DAVV Indore, India


Abstract: Function point analysis is useful to measure size     1.1Function Point Analysis with object – oriented design
of software projects in terms of functionality requested by                               methods
user. The main advantage of function point analysis is that              The Function Point software measure does not
it is independent of the technology used for implementation.    require a particular development technique. However, the
When we apply function points to object-oriented software       high level concepts of object-oriented development methods
projects, the concepts of development method have to be         cannot be mapped directly to the concepts of Function Point
mapped into abstract models that contain functional items       Analysis. In order to apply this software measure early in
of the application. This proposed idea implement a tool for     the development process, the object-oriented concepts
mapping function points into use case driven OOSE (object-      corresponding to transactional and data function types have
oriented software engineering) Jacobson approach. In this       to be determined.
idea we only considers analysis phase of OOSE life cycle.                Object-oriented methods differ, especially in their
OOFP tool measures function point from requirements             early development phases. The Object-Oriented method of
models and analysis model.                                      Jacobson et al. is based on so-called use cases. The OO-
Keyword: function points, size, requirements model, and         Jacobson identifies the functionality of an application with
analysis model, OOFP.                                           requirements use case model. Data types are described with
                I.        INTRODUCTION                          domain or analysis object model on the requirements level.
         Function Points Analysis (FPA) is one of the           The work proposes rules to map these models into function
earliest models that are used to predict the size of software   point counting procedures. With proposed rules, it is
in the early stages. Albrecht proposed the FPA model in         possible to count software developed with the OO-Jacobson
1979 and it measures the size of software based on its          method.
functionalities [1]. The main advantages of the FPA model       In this research paper, we focus on the approach of
are that it is independent of the technology. Up to the         Jacobson et al [3]. This method is called Object- Oriented
present, various FPA versions based on the Albrecht’s           Software Engineering. The OOSE method defines a process
version have been proposed (e.g. IFPUG method, MarkII,          to transform formalized requirements into a sequence of
COSMIC-FFP and they have been accepted as ISO/IEC               models. The steps include the requirements, analysis,
standards. The current version of counting rules is recorded    design, implementation and testing models. The use case
in the Counting Practices Manual [2]. This counting method      model is the basis on which all the models are developed.
isimplicitly based on the high- level model of software         Together with the domain object model it forms
applications. Though independent of implementation,             requirements model as shown in Figure 1.
counting rules are thus based on the implicit assumptions on
the abstract model of software applications. The items in the
abstract model that are than counted include transaction and
file types. These items are typically identified from
documents of traditional, structured design technique e.g.
data flow diagrams, hierarchical process models or database
structures. The proposed paper focus on object oriented
models based on the OOSE Jacobson approach. The
transaction and file type items are counted from models of
analysis phase. The models of analysis phase of OOSE
includes use case model, domain object model and analysis
model but this research paper focuses on counting function
points from analysis model and use case model.




                                                                  Figure 1: The use case model is the basis on which all
                                                                    other models of OOSE approach are developed.




                                                   www.ijmer.com                                             1923 | P a g e
International Journal of Modern Engineering Research (IJMER)
             www.ijmer.com                Vol.2, Issue.4, July-Aug 2012 pp-1923-1928       ISSN: 2249-6645
The objectives of this research paper are:
1. The application of Function Point Analysis following
   the IFPUG standards.
2. To measure for software developed with OOSE method.
3. To count early in the life cycle, in the requirements
   analysis phase.

1.2 Related Work
          Little work has been published on Function Point
Analysis in the context of object-oriented software                 Figure 2: Analysis Phase of the OOSE life cycle.
engineering techniques. But these approaches are based on
a model that consists with objects together with their                   At the focus of our work are the models developed
methods. In these approaches objects are treated as data        in analysis phase as shown in Figure2. As Jacobson et al.
files and methods as transactions which are the counting        state, the requirements model can be regarded as
items in the Function Point Analysis. These approaches do       formulating the functional requirements specification based
not applicable to early OOSE documents. It is also              on the needs of the users. The goal of this research paper
questionable whether each individual method is to be            work is to count Function Points early in the life cycle,
counted as a transaction.                                       measuring the functionality requested by the user from
          Whitmire[4] considers each class as an internal       these models. The overview of these three models discussed
logical file and treats messages sent outside the system        in [7].
boundary as transactions.
The ASMA paper takes a similar approach. Services                      III.         Fuction Point Concepts
delivered by objects to the client are considered as            3.1 Function Point model
transactions. The complexity of services is weighted based               A high level model of the FPA mode is given in
on accessed attributes and communications. Objects are          Figure 3 [7]. The function Point model specifies which
treated as files, their attributes determining their            component types of the software application will be
complexity.                                                     measures and from which viewpoint this will be done. Hat
          IFPUG [5] is working on a case study which            is to be counted, and measured, are the internal files and
illustrates the use of the counting practices for object-       external files of the application, together with the inputs,
oriented analysis and design. This case study, which is         outputs and inquiries from and to the user. Software
currently in draft form, uses object models in which the        components or deliverables which are not visible from a
methods of classes are identical with the services recorded     user viewpoint are not considered part of the Function Point
in the requirements. Under this assumption, the methods         measurement model.
can be counted as transactions.
          Karner [6] proposes a new measure called Use                             Function Point Model
Case Points for projects developed with the OOSE method.
The structure of this measure is similar to Function Points,
but it does not conform to the concepts of Function Points.
          Thomas Fetcke[7] proposes rules for mapping the
OO-Jacobson approach into Function Point Analysis. This
paper is based on Thomas proposed rules. This research
paper considers how to apply these rules to OOSE models
to measure data and transaction functions. In this paper data
files and transactionfunctions counting is done using
models of analysis phase of the OOSE life cycle. Analysis       Figure 3: High-level view of the abstract Function Point
phase model includes use case model and analysis model.          model with users and links to other applications. The
                                                                     dotted line marks the application boundary.
      II.          Brief Introduction To Oose
         The OOSE method is divided into three major            3.2 Function Point Counting Process
consecutive processes: analysis, constructive and testing.                In the IFPUG version, the counting procedure of
The analysis phase is further divided into two steps called     function point consists of the following seven steps. The
                                                                details of these seven steps are discussed in IFPUG [2].
requirements analysis and robustness analysis as shown in
Figure 2. The first step derives the requirements model         1. Determine type of function point count.
                                                                2. Identify the application boundary (A boundary
from the informal customer requirements. This model is
                                                                    indicates the border between theapplication or project
expressed in terms of use case model, and may be
augmented by a domain object model. The second step,                being measured and the external applications or the
robustness analysis, then structures the use case model into        user domain. A boundary establishes which functions
the analysis model by applying use case analysis. The               are included in the function point count).
                                                                3. Identify and rate transactional function types to
succeeding process furthertransforms these models, as
                                                                    determine their contribution to the unadjusted function
indicated in Figure 1.
                                                                    point count.
                                                                4. Identify and rate data function types to determine their
                                                                    contribution to the unadjusted function point count.
                                                   www.ijmer.com                                             1924 | P a g e
International Journal of Modern Engineering Research (IJMER)
               www.ijmer.com                Vol.2, Issue.4, July-Aug 2012 pp-1923-1928              ISSN: 2249-6645
 5. Determine the Unadjusted function point counts.                 5. Select every use case that extends a use case selected by
 6. Determine the value adjustment factor (VAF) that takes          rule 4 as a candidate.
      so-called global system characteristics into account,         6. No other use cases will be counted.
      e.g. data communication, performance or end user              Determining the types of transaction (external input (EI),
      efficiency. This adjustment is external of and                external output (EO) and external inquiry (EQ) is based on
      independent from the concepts of the abstract FPA             a set of detailed rules in FPA [1]. The rules are recorded in
      model. The global system        characteristics determine     the IFPUG Counting Practices Manual [2]. The relevant
      an adjustment factor that is multiplied with the              sections are:
      unadjusted count.                                             “External Input Counting Rules”,
  7. Calculate the adjusted function point count.                   “External Output Counting Rules”, and
           The next section describes the proposed mapping          “External Inquiry Counting Rules”.
 of OOSE models to function points along these five steps.
                                                                    The rates of transactions are based on detailed rules in the
IV.           Mapping Concepts (Proposed Method)                    counting practices Manual. The rules require the
           The aim of this research paper is to calculate the       determination of data element types (DET) and file types
 Unadjusted Function Point. The paper work proposes the             that are referenced (FTR), illustrated in Figure 5
 following five steps to apply IFPUG version to the OOSE            .
 requirements analysis models (use case model and analysis          4.4 Step4 (Identify and rate data function types to
 model).                                                            determine their contribution to the unadjusted function
 4.1 Step1(Determine the type of function count): This              point count.):
      paper handles only the application project function           Data files are automatically decided based on analysis
      point.                                                        classes of analysis model. In the analysis model, the objects
 4.2 Step2(Identify the application boundary): The counting         are typed into three groups, namely entity, interface and
      boundary is determined by the type of actors appeared         control objects. The set of objects that have to be analyzed
      in use case model of OOSE requirement analysis                is limited to the entity objects and is thus set of objects
      phase.                                                        typically smaller. Interface (boundary) and control objects
                                                                    are part of implementation.
 Proposed mapping rules to identify the application
 boundary                                                           4.4.1 Finding of Analysis Classes from Use Case Model
 1. Accept each human actor as a user of the system.                1. Is this candidate inside our system boundary?
 2. Accept each non-human actor, which is separate                       2. If not, it might be an actor of our system.
      system not design to provide functionality solely to the           Does this candidate have identifiable behavior for our
      system under consideration as an external application.             problem                                         domain?
 3. Reject each non-human actor, which is part of the                    (i.e., can we name the services/functions that are
      underlying system, e.g. a rational database system or a            needed in our problem domain and that this candidate
      printing device.                                                   would own and provide?)
 The result is a representation of the application boundary as      3. Does this candidate have identifiable structure?
 a set of users and applications external to the one under               (i.e., can we identify some set of data this candidate
 consideration as shown in Figure 4.                                     should own and manage?)
                                                                    4. Does this candidate have relationships with any other
                                                                         candidates?




Figure 4: Step2-        Identification of the        counting
boundary.

4.3 Step3 (Identify and rate transactional function types to
determine their contribution to the unadjusted Function
point count.):
       The transaction functions are automatically decided
based on actors and use cases of the use case model. Use
cases are the OOSE concept corresponding to transactions.                   If you find a "no," then the candidate is probably
                                                                   not a class; move on to the next candidate. If the answer is
Proposed mapping rules to identify and rate transaction            "yes," keep asking the questions. If you get all "yes"
function types                                                     answers, conclude the candidate is a class, and get the next
                                                                   candidate to evaluate.
4. Select every use case that has a direct relation to an actor
accepted by rule 1 or 2. This use case will be a candidate         Proposed mapping rules to identify and rate data
for one or several transactions.                                   function types


                                                     www.ijmer.com                                               1925 | P a g e
International Journal of Modern Engineering Research (IJMER)
               www.ijmer.com               Vol.2, Issue.4, July-Aug 2012 pp-1923-1928            ISSN: 2249-6645
7. Select every object of entity type as a candidate for a         4.5 Step 5 (Determine the unadjusted function point
     logical file.                                                 counts)
8. No other objects will be selected.                              As the result of Step3 and Step4, the counts for each
                                                                   function type are automatically classified according to
For aggregation relationships                                      complexity and then weighted. The total for all function
9. An entity objects that is part of another object (is            types is the unadjusted function point count.
     aggregated into another object) is not a candidate for a
     logical file, but it is a candidate for a record element                     V.           CASE STUDY
     type (RET) for the file related to the aggregating top-       In this section the rules proposed in section 4 are applied to
     level object                                                  OOSE approach based project. The documentation
                                                                   provided included use case models and analysis object
For inheritance relationships                                      models together with the textual description these models.
10. An abstract object is not a candidate for a logical file. It
is a candidate for a RET for each object that inherits its         5.1 Example of OOSE based analysis models
properties.                                                                  In OOSE life cycle, analysis phase is divided into
11. Sub-objects of a concrete object are candidates for a          two phases: requirement analysis and robustness analysis.
     logical file or for a RET of that object.                     Requirement analysis consists with two models, use case
12. If use cases make implicit use of logical files that are       models and domain object models. Robustness analysis
     not represented in the analysis object (class) model,         consists with a model known as analysis model. This
     these files have to be included in the set of files.          research work focuses on use case models and analysis
                                                                   classes.
          Determining the types of data files (internal logical
files (ILF) and external interface files (EIF)) is based on a      Case Study: A part of Course Registration System Use
set of detailed rules in FPA [1]. The rules are recorded in        Case Model
the IFPUG Counting Practices Manual [2]. The relevant
section is “ILF/EIF counting rules”.
          The rates of data files are based on detailed rules
in the counting practices Manual. The rules require the
determination of data element types (DET) and record
element types (RET), illustrated in Figure 5.

                                                                  Figure6: Use Case: Register for Courses

                                                                           This use case allows a Student to register for
                                                                  course offerings in the current semester. The Student can
                                                                  also update or delete course selections if changes are made
                                                                  within add/drop period at the beginning of the semester.
                                                                  The Course Catalog System provides a list of all the course
                                                                  offerings for the current semester.
     Figure 5: Step3 and Step4- Rating of data and
               transaction function types.                        5.2 Finding Analysis classes from use case model
                                                                  (Behavior)
Proposed Mapping Rules for determining DET, RET                   Register for Courses Use Case-This use case starts when a
and FTR                                                           Student wishes to register for course offerings, or to change
13. Attributes of objects are candidates for data element         his/her existing course schedule.
     types (DET) for files and for the transactions by which      1. The system requests that the Student specify the
     it is read and maintained.                                        function he/she would like to perform (Create a
14. Candidates for record element types are determined by              Schedule, Update a Schedule, or Delete a Schedule).
     subgroups of files and by rules 9-11.                        2. Once the Student provides the requested information,
15. Each object maintained and /or read by a use case                  one of the sub flows is executed. If the Registrar
     counts as a file type referenced (FTR) for the                    selected “Create a Schedule”, the Create a Schedule
     associated transaction(s), if and only if the object has          sub flow is executed. If the Registrar selected “Update
     been identified as a file in step 4.                              a Schedule”, the Update a Schedule sub flow is
           After determining DETs, RETs, FTRs rate the data            executed. If the Registrar selected “Delete a Schedule”,
files and transaction functions according to rating matrix             the Delete a Schedule sub flow is executed.
and then allot weighs according to weighting matrix in the        Candidates for entity (noun) and applying 4 conditions of
Counting Practices Manual [2]. The total weight of data           section 4.4.1 to make them entity analysis classes as shown
files types and transaction types are the required unadjusted     in Figure7.
function points count.                                            1. Student-A person enrolled in classes at the university.
                                                                  2. Schedule-The courses a student has selected for the
                                                                  current semester.


                                                    www.ijmer.com                                                1926 | P a g e
International Journal of Modern Engineering Research (IJMER)
              www.ijmer.com              Vol.2, Issue.4, July-Aug 2012 pp-1923-1928       ISSN: 2249-6645
3. Course Offering-A specific delivery of the course for a
specific semester – you could run the same course in
parallel sessions in the semester. Includes the days of the
week and times it is offered.




Figure7: Analysis class model consists with entity
analysis classes

5.3 Now, applying proposed rules to Analysis Class                Table2: Global System Characteristics (GSC)
Model and Use Case Model of above Case Study:
                                                                               So using formulae:
By rules 1, 2 and 3 application boundary includes-                  VAF = 0.65 + ((sum of all GSC factor)/100).
Human actors- student                                                       = 0.65 + (22/100) = 0.87
Non-human actors-Nil
                                                             This factor affects the whole FP like anything, be very
By rules 4-12 and 13-15 candidates for transaction/data      particular with this factor.
function types with ratings and weight are shown in          So               now,               calculating          the
Table1.                                                      Adjusted FP (AFP) = VAF * Total Unadjusted
                                                                                             FP (UAFP)
Transactio Transactio No.   of No. of Comple Weight/                             = 0.87* 24 =20.88,
n/     data n/   data DET      RET/ xity     Value                               =Rounded           to       21      FPs
function function              FTR                           Compared with the approaches proposed in the literature,
name        type                                             these mapping rules have certain advantages.
Register EI           3        2FTRs low       3             1. The mapping rules are based on the standard FPA
for                            (Studen                            defined in the IFPUG Counting Practice Manual. This
courses                        t,                                 widely used measure independent of technology.
                               Schedul                       2. The count is based on requirements models, which are
                               e)                                 the first models available in the OOSE life cycle. For
Register   EO       3          2FTRs low       3                  the purpose of effort estimation based on Function
for                            (Studen                            Points, this is an essential prerequisite.
courses                        t,                            This approach also has some limitations.
                               Schedul                       1. The main limitation is the focus on the Jacobson OOSE
                               e)                                 method. Mapping rules are based on the requirements
                                                                  models of this approach and cannot be applied to
Register   EQ       4          1FTR low        4
                                                                  methods that do not develop these models. Also an
for                            (Course
                                                                  advantage this focus on OOSE, that the models are
courses                        Offerin
                                                                  unambiguously defined in the method.
                               g)
Student    ILF      3          1RET(S low      7                          VI.          OOFP TOOL
                               chedule                       The concept of mapping the object oriented software
                               )
                                                             models into function Points lead to implement a tool
Course     ILF      4          1RET(S low      7             called OOFP. This tool is implemented in java language.
Offering                       chedule                       The inputs for the tool are use case model and analysis class
                               )                             (object) model and the output includes the values of
UAFP                                           24 FPs        function points, transactional functions, and data functions.
                                                                      The OOFP tool is automated using XMI (xml
Table1: Transaction/Data function types with ratings         metadata interchange) parser. The XMI parser takes .xmi or
and weight.                                                  .xml files of use case and analysis class models as input
In order to make it adjusted function point, we have to      then read and extracts the use cases, actors, entity classes
calculate and tabulate the GSC and come out with the VAF     from these files. Extracted candidates are then used for
as shown in Table2.                                          calculating function points.

                                                www.ijmer.com                                              1927 | P a g e
International Journal of Modern Engineering Research (IJMER)
                 www.ijmer.com                Vol.2, Issue.4, July-Aug 2012 pp-1923-1928        ISSN: 2249-6645




                                                                              Screen1: Function Point Calculation




   Figure: 8 Function Point Counting Tool (OOFP tool).

                 VII.           SUMMARY
            This work demonstrated the applicability of
   function points as a measure of functional software size to
   the object- oriented Jacobson approach, OOSE. This work
   supports that the function point measures independent of
   the technology used for implementation and that it can be
   used in the object-oriented paradigm.
     Future work in the field has to deal with the mapping of                  Screen 2: Value Adjustment Factor
   OOSE design model into function points.

                            References
   [1] A. J. Albrecht. Measuring          Application Development
        Productivity.        IBM      Applications      Development
        Symposium, Monterey, CA, 1979
   [2] Function Point Counting Practices Manual, Release 4.0.
        Westerville. Ohio, International Function Point Users Group,
        1994.
   [3] Jacobson, I., M. Christerson et al. Object-Oriented Software
        Engineering. A Use Case driven Approach. Addison-Wesely,
        1992.
   [4] Whitmire, S.A. Applying function points to object-oriented
        software models, 1992. In Software engineering productivity
        handbook. J. Keyes, McGraw-Hill, pp.229-244.                      Screen 3: Function Point Report for a Project
   [5] Function Point Counting Practices: case Study3- Object-
        Oriented Analysis. Object-Oriented Analysis. Object-
        Oriented Design (Draft), International Function Point Users
        Group, 1995.
   [6] Karner, G. Resource Estimation for Objectory Projects,
        Objectory Systems, 1993.
   [7] ThomasFetcke, Alain Abran and THo- Hau Nguyen.Mapping
        the OO-Jacobson Approach into Function Point Analysis,
        1997.Published in the Proceeding of TOOLS- 23’97.
   [8] “CostEstimatingWebSite”,
        http://cost.jsc.nasa.gov/COCOMO.html
   [9] “Construx Estimate tool”, www.construx.com
   [10] ”CoStar tool”, www.softstarsystems.com
   [11] “An introduction (tutorial) to Function Point Analysis”,
        www.devdaily.com/FunctionPoints.


VIII.         APPENDIX: Screenshots For OOFP Tool
            The following screenshots show how function
   points are calculated using OOFP (Object oriented function
   point) tool.

                                                          www.ijmer.com                                        1928 | P a g e

Contenu connexe

Tendances

Study for big data analysis design model
Study for big data analysis design modelStudy for big data analysis design model
Study for big data analysis design modelJoon ho Park
 
A practical approach for model based slicing
A practical approach for model based slicingA practical approach for model based slicing
A practical approach for model based slicingIOSR Journals
 
Software Engineering course
Software Engineering courseSoftware Engineering course
Software Engineering courseJeremy Rose
 
STRUCTURAL VALIDATION OF SOFTWARE PRODUCT LINE VARIANTS: A GRAPH TRANSFORMATI...
STRUCTURAL VALIDATION OF SOFTWARE PRODUCT LINE VARIANTS: A GRAPH TRANSFORMATI...STRUCTURAL VALIDATION OF SOFTWARE PRODUCT LINE VARIANTS: A GRAPH TRANSFORMATI...
STRUCTURAL VALIDATION OF SOFTWARE PRODUCT LINE VARIANTS: A GRAPH TRANSFORMATI...IJSEA
 
60780174 49594067-cs1403-case-tools-lab-manual
60780174 49594067-cs1403-case-tools-lab-manual60780174 49594067-cs1403-case-tools-lab-manual
60780174 49594067-cs1403-case-tools-lab-manualChitrarasan Kathiravan
 
Size and Time Estimation in Goal Graph Using Use Case Points (UCP): A Survey
Size and Time Estimation in Goal Graph Using Use Case Points (UCP): A SurveySize and Time Estimation in Goal Graph Using Use Case Points (UCP): A Survey
Size and Time Estimation in Goal Graph Using Use Case Points (UCP): A SurveyIJERA Editor
 
CS8592 Object Oriented Analysis & Design - UNIT V
CS8592 Object Oriented Analysis & Design - UNIT V CS8592 Object Oriented Analysis & Design - UNIT V
CS8592 Object Oriented Analysis & Design - UNIT V pkaviya
 
Software Engineering Lab Manual
Software Engineering Lab ManualSoftware Engineering Lab Manual
Software Engineering Lab ManualNeelamani Samal
 
Minimal Testcase Generation for Object-Oriented Software with State Charts
Minimal Testcase Generation for Object-Oriented Software with State ChartsMinimal Testcase Generation for Object-Oriented Software with State Charts
Minimal Testcase Generation for Object-Oriented Software with State Chartsijseajournal
 
IJCER (www.ijceronline.com) International Journal of computational Engineerin...
IJCER (www.ijceronline.com) International Journal of computational Engineerin...IJCER (www.ijceronline.com) International Journal of computational Engineerin...
IJCER (www.ijceronline.com) International Journal of computational Engineerin...ijceronline
 
75752177 ooad-lab-manual-by-n-gopinath-skpit
75752177 ooad-lab-manual-by-n-gopinath-skpit75752177 ooad-lab-manual-by-n-gopinath-skpit
75752177 ooad-lab-manual-by-n-gopinath-skpitSubramaniyan94
 
Evolution of Modelling Techniques for Service Oriented Architecture
Evolution of Modelling Techniques for Service Oriented ArchitectureEvolution of Modelling Techniques for Service Oriented Architecture
Evolution of Modelling Techniques for Service Oriented ArchitectureIJERA Editor
 
"Just Enough" System Modeling
"Just Enough" System Modeling"Just Enough" System Modeling
"Just Enough" System ModelingProf. Amir Tomer
 
Unit 1( modelling concepts & class modeling)
Unit  1( modelling concepts & class modeling)Unit  1( modelling concepts & class modeling)
Unit 1( modelling concepts & class modeling)Manoj Reddy
 
Round - Trip Software Engineering using UML: From Architecture to Design and...
Round - Trip Software Engineering using UML:  From Architecture to Design and...Round - Trip Software Engineering using UML:  From Architecture to Design and...
Round - Trip Software Engineering using UML: From Architecture to Design and...Aman Mishra
 

Tendances (20)

Study for big data analysis design model
Study for big data analysis design modelStudy for big data analysis design model
Study for big data analysis design model
 
Ooad overview
Ooad overviewOoad overview
Ooad overview
 
A practical approach for model based slicing
A practical approach for model based slicingA practical approach for model based slicing
A practical approach for model based slicing
 
Software Engineering course
Software Engineering courseSoftware Engineering course
Software Engineering course
 
STRUCTURAL VALIDATION OF SOFTWARE PRODUCT LINE VARIANTS: A GRAPH TRANSFORMATI...
STRUCTURAL VALIDATION OF SOFTWARE PRODUCT LINE VARIANTS: A GRAPH TRANSFORMATI...STRUCTURAL VALIDATION OF SOFTWARE PRODUCT LINE VARIANTS: A GRAPH TRANSFORMATI...
STRUCTURAL VALIDATION OF SOFTWARE PRODUCT LINE VARIANTS: A GRAPH TRANSFORMATI...
 
60780174 49594067-cs1403-case-tools-lab-manual
60780174 49594067-cs1403-case-tools-lab-manual60780174 49594067-cs1403-case-tools-lab-manual
60780174 49594067-cs1403-case-tools-lab-manual
 
Size and Time Estimation in Goal Graph Using Use Case Points (UCP): A Survey
Size and Time Estimation in Goal Graph Using Use Case Points (UCP): A SurveySize and Time Estimation in Goal Graph Using Use Case Points (UCP): A Survey
Size and Time Estimation in Goal Graph Using Use Case Points (UCP): A Survey
 
CS8592 Object Oriented Analysis & Design - UNIT V
CS8592 Object Oriented Analysis & Design - UNIT V CS8592 Object Oriented Analysis & Design - UNIT V
CS8592 Object Oriented Analysis & Design - UNIT V
 
Software Engineering Lab Manual
Software Engineering Lab ManualSoftware Engineering Lab Manual
Software Engineering Lab Manual
 
Minimal Testcase Generation for Object-Oriented Software with State Charts
Minimal Testcase Generation for Object-Oriented Software with State ChartsMinimal Testcase Generation for Object-Oriented Software with State Charts
Minimal Testcase Generation for Object-Oriented Software with State Charts
 
IJCER (www.ijceronline.com) International Journal of computational Engineerin...
IJCER (www.ijceronline.com) International Journal of computational Engineerin...IJCER (www.ijceronline.com) International Journal of computational Engineerin...
IJCER (www.ijceronline.com) International Journal of computational Engineerin...
 
75752177 ooad-lab-manual-by-n-gopinath-skpit
75752177 ooad-lab-manual-by-n-gopinath-skpit75752177 ooad-lab-manual-by-n-gopinath-skpit
75752177 ooad-lab-manual-by-n-gopinath-skpit
 
Evolution of Modelling Techniques for Service Oriented Architecture
Evolution of Modelling Techniques for Service Oriented ArchitectureEvolution of Modelling Techniques for Service Oriented Architecture
Evolution of Modelling Techniques for Service Oriented Architecture
 
"Just Enough" System Modeling
"Just Enough" System Modeling"Just Enough" System Modeling
"Just Enough" System Modeling
 
Unit 1( modelling concepts & class modeling)
Unit  1( modelling concepts & class modeling)Unit  1( modelling concepts & class modeling)
Unit 1( modelling concepts & class modeling)
 
Round - Trip Software Engineering using UML: From Architecture to Design and...
Round - Trip Software Engineering using UML:  From Architecture to Design and...Round - Trip Software Engineering using UML:  From Architecture to Design and...
Round - Trip Software Engineering using UML: From Architecture to Design and...
 
Ooad
OoadOoad
Ooad
 
1 introduction of OOAD
1 introduction of OOAD1 introduction of OOAD
1 introduction of OOAD
 
Ooad ch 2
Ooad ch 2Ooad ch 2
Ooad ch 2
 
Me2011 Presentation by Loniewski
Me2011 Presentation by LoniewskiMe2011 Presentation by Loniewski
Me2011 Presentation by Loniewski
 

En vedette

Industrial Microcontroller Based Neural Network Controlled Autonomous Vehicle
Industrial Microcontroller Based Neural Network Controlled  Autonomous VehicleIndustrial Microcontroller Based Neural Network Controlled  Autonomous Vehicle
Industrial Microcontroller Based Neural Network Controlled Autonomous VehicleIJMER
 
Bw31297301
Bw31297301Bw31297301
Bw31297301IJMER
 
Analysis of Machining Characteristics of Cryogenically Treated Die Steels Usi...
Analysis of Machining Characteristics of Cryogenically Treated Die Steels Usi...Analysis of Machining Characteristics of Cryogenically Treated Die Steels Usi...
Analysis of Machining Characteristics of Cryogenically Treated Die Steels Usi...IJMER
 
Effect on Efficiency of Two-phase Flow Distribution in a Parallel Flow Heat E...
Effect on Efficiency of Two-phase Flow Distribution in a Parallel Flow Heat E...Effect on Efficiency of Two-phase Flow Distribution in a Parallel Flow Heat E...
Effect on Efficiency of Two-phase Flow Distribution in a Parallel Flow Heat E...IJMER
 
Experimental and Analytical Study on Reinforced Concrete Deep Bea
Experimental and Analytical Study on Reinforced Concrete Deep BeaExperimental and Analytical Study on Reinforced Concrete Deep Bea
Experimental and Analytical Study on Reinforced Concrete Deep BeaIJMER
 
Ireland's Energy Futures
Ireland's Energy FuturesIreland's Energy Futures
Ireland's Energy Futuressaulcj
 
Df3211051114
Df3211051114Df3211051114
Df3211051114IJMER
 
Ba32759764
Ba32759764Ba32759764
Ba32759764IJMER
 
Dh31504508
Dh31504508Dh31504508
Dh31504508IJMER
 
Cq31401405
Cq31401405Cq31401405
Cq31401405IJMER
 
On The Zeros of Polynomials
On The Zeros of PolynomialsOn The Zeros of Polynomials
On The Zeros of PolynomialsIJMER
 
Ijmer 46051622
Ijmer 46051622Ijmer 46051622
Ijmer 46051622IJMER
 
A Technique by using Neuro-Fuzzy Inference System for Intrusion Detection and...
A Technique by using Neuro-Fuzzy Inference System for Intrusion Detection and...A Technique by using Neuro-Fuzzy Inference System for Intrusion Detection and...
A Technique by using Neuro-Fuzzy Inference System for Intrusion Detection and...IJMER
 
A Distributed Cut Detection Method for Wireless Sensor Networks
A Distributed Cut Detection Method for Wireless Sensor NetworksA Distributed Cut Detection Method for Wireless Sensor Networks
A Distributed Cut Detection Method for Wireless Sensor NetworksIJMER
 
Am2418831887
Am2418831887Am2418831887
Am2418831887IJMER
 
Aa02417361740
Aa02417361740Aa02417361740
Aa02417361740IJMER
 

En vedette (20)

Industrial Microcontroller Based Neural Network Controlled Autonomous Vehicle
Industrial Microcontroller Based Neural Network Controlled  Autonomous VehicleIndustrial Microcontroller Based Neural Network Controlled  Autonomous Vehicle
Industrial Microcontroller Based Neural Network Controlled Autonomous Vehicle
 
Bw31297301
Bw31297301Bw31297301
Bw31297301
 
Analysis of Machining Characteristics of Cryogenically Treated Die Steels Usi...
Analysis of Machining Characteristics of Cryogenically Treated Die Steels Usi...Analysis of Machining Characteristics of Cryogenically Treated Die Steels Usi...
Analysis of Machining Characteristics of Cryogenically Treated Die Steels Usi...
 
Effect on Efficiency of Two-phase Flow Distribution in a Parallel Flow Heat E...
Effect on Efficiency of Two-phase Flow Distribution in a Parallel Flow Heat E...Effect on Efficiency of Two-phase Flow Distribution in a Parallel Flow Heat E...
Effect on Efficiency of Two-phase Flow Distribution in a Parallel Flow Heat E...
 
Experimental and Analytical Study on Reinforced Concrete Deep Bea
Experimental and Analytical Study on Reinforced Concrete Deep BeaExperimental and Analytical Study on Reinforced Concrete Deep Bea
Experimental and Analytical Study on Reinforced Concrete Deep Bea
 
Ireland's Energy Futures
Ireland's Energy FuturesIreland's Energy Futures
Ireland's Energy Futures
 
Garrett’s moving inc
Garrett’s moving incGarrett’s moving inc
Garrett’s moving inc
 
Df3211051114
Df3211051114Df3211051114
Df3211051114
 
Ba32759764
Ba32759764Ba32759764
Ba32759764
 
Dh31504508
Dh31504508Dh31504508
Dh31504508
 
Cq31401405
Cq31401405Cq31401405
Cq31401405
 
On The Zeros of Polynomials
On The Zeros of PolynomialsOn The Zeros of Polynomials
On The Zeros of Polynomials
 
Ijmer 46051622
Ijmer 46051622Ijmer 46051622
Ijmer 46051622
 
Unit 10 lesson1
Unit 10 lesson1Unit 10 lesson1
Unit 10 lesson1
 
A Technique by using Neuro-Fuzzy Inference System for Intrusion Detection and...
A Technique by using Neuro-Fuzzy Inference System for Intrusion Detection and...A Technique by using Neuro-Fuzzy Inference System for Intrusion Detection and...
A Technique by using Neuro-Fuzzy Inference System for Intrusion Detection and...
 
A Distributed Cut Detection Method for Wireless Sensor Networks
A Distributed Cut Detection Method for Wireless Sensor NetworksA Distributed Cut Detection Method for Wireless Sensor Networks
A Distributed Cut Detection Method for Wireless Sensor Networks
 
Hip hop
Hip hopHip hop
Hip hop
 
Am2418831887
Am2418831887Am2418831887
Am2418831887
 
Coca cola
Coca colaCoca cola
Coca cola
 
Aa02417361740
Aa02417361740Aa02417361740
Aa02417361740
 

Similaire à At2419231928

object oriented methodologies
object oriented methodologiesobject oriented methodologies
object oriented methodologiesAmith Tiwari
 
A SOFTWARE REQUIREMENT ENGINEERING TECHNIQUE USING OOADA-RE AND CSC FOR IOT B...
A SOFTWARE REQUIREMENT ENGINEERING TECHNIQUE USING OOADA-RE AND CSC FOR IOT B...A SOFTWARE REQUIREMENT ENGINEERING TECHNIQUE USING OOADA-RE AND CSC FOR IOT B...
A SOFTWARE REQUIREMENT ENGINEERING TECHNIQUE USING OOADA-RE AND CSC FOR IOT B...ijseajournal
 
Object Oriented Approach for Software Development
Object Oriented Approach for Software DevelopmentObject Oriented Approach for Software Development
Object Oriented Approach for Software DevelopmentRishabh Soni
 
Generating requirements analysis models from textual requiremen
Generating requirements analysis models from textual requiremenGenerating requirements analysis models from textual requiremen
Generating requirements analysis models from textual requiremenfortes
 
A Systematic Mapping Review of Software Quality Measurement: Research Trends,...
A Systematic Mapping Review of Software Quality Measurement: Research Trends,...A Systematic Mapping Review of Software Quality Measurement: Research Trends,...
A Systematic Mapping Review of Software Quality Measurement: Research Trends,...IJECEIAES
 
Module3 - Object Oriented Analysis & Functional Model.pdf
Module3 - Object Oriented Analysis & Functional Model.pdfModule3 - Object Oriented Analysis & Functional Model.pdf
Module3 - Object Oriented Analysis & Functional Model.pdfGerard Alba
 
A Comparative Study between Agile Methods of Software Development
A Comparative Study between Agile Methods of Software DevelopmentA Comparative Study between Agile Methods of Software Development
A Comparative Study between Agile Methods of Software DevelopmentFelipe Alves
 
Ooad lab manual(original)
Ooad lab manual(original)Ooad lab manual(original)
Ooad lab manual(original)dipenpatelpatel
 
MK_MSc_Degree_Project_Report ver 5_updated
MK_MSc_Degree_Project_Report ver 5_updatedMK_MSc_Degree_Project_Report ver 5_updated
MK_MSc_Degree_Project_Report ver 5_updatedMohammed Ali Khan
 
07. MTE - Studi Kasus Pemodelan Sistem.pptx
07. MTE - Studi Kasus Pemodelan Sistem.pptx07. MTE - Studi Kasus Pemodelan Sistem.pptx
07. MTE - Studi Kasus Pemodelan Sistem.pptxAsalReview
 
Management of time uncertainty in agile
Management of time uncertainty in agileManagement of time uncertainty in agile
Management of time uncertainty in agileijseajournal
 
Meffortmob a effort size measurement
Meffortmob a effort size measurementMeffortmob a effort size measurement
Meffortmob a effort size measurementijseajournal
 
Performance Evaluation using Blackboard Technique in Software Architecture
Performance Evaluation using Blackboard Technique in Software ArchitecturePerformance Evaluation using Blackboard Technique in Software Architecture
Performance Evaluation using Blackboard Technique in Software ArchitectureEditor IJCATR
 
Consolidated Model of Procedures for Workflow Management
Consolidated Model of Procedures for Workflow ManagementConsolidated Model of Procedures for Workflow Management
Consolidated Model of Procedures for Workflow ManagementZac Darcy
 
Consolidated model of procedures for workflow management
Consolidated model of procedures for workflow managementConsolidated model of procedures for workflow management
Consolidated model of procedures for workflow managementZac Darcy
 
UNIT V TESTING.pptx
UNIT V TESTING.pptxUNIT V TESTING.pptx
UNIT V TESTING.pptxanguraju1
 

Similaire à At2419231928 (20)

object oriented methodologies
object oriented methodologiesobject oriented methodologies
object oriented methodologies
 
A SOFTWARE REQUIREMENT ENGINEERING TECHNIQUE USING OOADA-RE AND CSC FOR IOT B...
A SOFTWARE REQUIREMENT ENGINEERING TECHNIQUE USING OOADA-RE AND CSC FOR IOT B...A SOFTWARE REQUIREMENT ENGINEERING TECHNIQUE USING OOADA-RE AND CSC FOR IOT B...
A SOFTWARE REQUIREMENT ENGINEERING TECHNIQUE USING OOADA-RE AND CSC FOR IOT B...
 
Object Oriented Approach for Software Development
Object Oriented Approach for Software DevelopmentObject Oriented Approach for Software Development
Object Oriented Approach for Software Development
 
Generating requirements analysis models from textual requiremen
Generating requirements analysis models from textual requiremenGenerating requirements analysis models from textual requiremen
Generating requirements analysis models from textual requiremen
 
A Systematic Mapping Review of Software Quality Measurement: Research Trends,...
A Systematic Mapping Review of Software Quality Measurement: Research Trends,...A Systematic Mapping Review of Software Quality Measurement: Research Trends,...
A Systematic Mapping Review of Software Quality Measurement: Research Trends,...
 
Object oriented analysis and design unit- ii
Object oriented analysis and design unit- iiObject oriented analysis and design unit- ii
Object oriented analysis and design unit- ii
 
Assign1
Assign1Assign1
Assign1
 
Module3 - Object Oriented Analysis & Functional Model.pdf
Module3 - Object Oriented Analysis & Functional Model.pdfModule3 - Object Oriented Analysis & Functional Model.pdf
Module3 - Object Oriented Analysis & Functional Model.pdf
 
A Comparative Study between Agile Methods of Software Development
A Comparative Study between Agile Methods of Software DevelopmentA Comparative Study between Agile Methods of Software Development
A Comparative Study between Agile Methods of Software Development
 
Different Proposed Models to Mapping MDA to RUP
Different Proposed Models to Mapping MDA to RUPDifferent Proposed Models to Mapping MDA to RUP
Different Proposed Models to Mapping MDA to RUP
 
Ooad lab manual(original)
Ooad lab manual(original)Ooad lab manual(original)
Ooad lab manual(original)
 
MK_MSc_Degree_Project_Report ver 5_updated
MK_MSc_Degree_Project_Report ver 5_updatedMK_MSc_Degree_Project_Report ver 5_updated
MK_MSc_Degree_Project_Report ver 5_updated
 
07. MTE - Studi Kasus Pemodelan Sistem.pptx
07. MTE - Studi Kasus Pemodelan Sistem.pptx07. MTE - Studi Kasus Pemodelan Sistem.pptx
07. MTE - Studi Kasus Pemodelan Sistem.pptx
 
Management of time uncertainty in agile
Management of time uncertainty in agileManagement of time uncertainty in agile
Management of time uncertainty in agile
 
Meffortmob a effort size measurement
Meffortmob a effort size measurementMeffortmob a effort size measurement
Meffortmob a effort size measurement
 
Performance Evaluation using Blackboard Technique in Software Architecture
Performance Evaluation using Blackboard Technique in Software ArchitecturePerformance Evaluation using Blackboard Technique in Software Architecture
Performance Evaluation using Blackboard Technique in Software Architecture
 
Consolidated Model of Procedures for Workflow Management
Consolidated Model of Procedures for Workflow ManagementConsolidated Model of Procedures for Workflow Management
Consolidated Model of Procedures for Workflow Management
 
Consolidated model of procedures for workflow management
Consolidated model of procedures for workflow managementConsolidated model of procedures for workflow management
Consolidated model of procedures for workflow management
 
SMD Unit i
SMD Unit iSMD Unit i
SMD Unit i
 
UNIT V TESTING.pptx
UNIT V TESTING.pptxUNIT V TESTING.pptx
UNIT V TESTING.pptx
 

Plus de IJMER

A Study on Translucent Concrete Product and Its Properties by Using Optical F...
A Study on Translucent Concrete Product and Its Properties by Using Optical F...A Study on Translucent Concrete Product and Its Properties by Using Optical F...
A Study on Translucent Concrete Product and Its Properties by Using Optical F...IJMER
 
Developing Cost Effective Automation for Cotton Seed Delinting
Developing Cost Effective Automation for Cotton Seed DelintingDeveloping Cost Effective Automation for Cotton Seed Delinting
Developing Cost Effective Automation for Cotton Seed DelintingIJMER
 
Study & Testing Of Bio-Composite Material Based On Munja Fibre
Study & Testing Of Bio-Composite Material Based On Munja FibreStudy & Testing Of Bio-Composite Material Based On Munja Fibre
Study & Testing Of Bio-Composite Material Based On Munja FibreIJMER
 
Hybrid Engine (Stirling Engine + IC Engine + Electric Motor)
Hybrid Engine (Stirling Engine + IC Engine + Electric Motor)Hybrid Engine (Stirling Engine + IC Engine + Electric Motor)
Hybrid Engine (Stirling Engine + IC Engine + Electric Motor)IJMER
 
Fabrication & Characterization of Bio Composite Materials Based On Sunnhemp F...
Fabrication & Characterization of Bio Composite Materials Based On Sunnhemp F...Fabrication & Characterization of Bio Composite Materials Based On Sunnhemp F...
Fabrication & Characterization of Bio Composite Materials Based On Sunnhemp F...IJMER
 
Geochemistry and Genesis of Kammatturu Iron Ores of Devagiri Formation, Sandu...
Geochemistry and Genesis of Kammatturu Iron Ores of Devagiri Formation, Sandu...Geochemistry and Genesis of Kammatturu Iron Ores of Devagiri Formation, Sandu...
Geochemistry and Genesis of Kammatturu Iron Ores of Devagiri Formation, Sandu...IJMER
 
Experimental Investigation on Characteristic Study of the Carbon Steel C45 in...
Experimental Investigation on Characteristic Study of the Carbon Steel C45 in...Experimental Investigation on Characteristic Study of the Carbon Steel C45 in...
Experimental Investigation on Characteristic Study of the Carbon Steel C45 in...IJMER
 
Non linear analysis of Robot Gun Support Structure using Equivalent Dynamic A...
Non linear analysis of Robot Gun Support Structure using Equivalent Dynamic A...Non linear analysis of Robot Gun Support Structure using Equivalent Dynamic A...
Non linear analysis of Robot Gun Support Structure using Equivalent Dynamic A...IJMER
 
Static Analysis of Go-Kart Chassis by Analytical and Solid Works Simulation
Static Analysis of Go-Kart Chassis by Analytical and Solid Works SimulationStatic Analysis of Go-Kart Chassis by Analytical and Solid Works Simulation
Static Analysis of Go-Kart Chassis by Analytical and Solid Works SimulationIJMER
 
High Speed Effortless Bicycle
High Speed Effortless BicycleHigh Speed Effortless Bicycle
High Speed Effortless BicycleIJMER
 
Integration of Struts & Spring & Hibernate for Enterprise Applications
Integration of Struts & Spring & Hibernate for Enterprise ApplicationsIntegration of Struts & Spring & Hibernate for Enterprise Applications
Integration of Struts & Spring & Hibernate for Enterprise ApplicationsIJMER
 
Microcontroller Based Automatic Sprinkler Irrigation System
Microcontroller Based Automatic Sprinkler Irrigation SystemMicrocontroller Based Automatic Sprinkler Irrigation System
Microcontroller Based Automatic Sprinkler Irrigation SystemIJMER
 
On some locally closed sets and spaces in Ideal Topological Spaces
On some locally closed sets and spaces in Ideal Topological SpacesOn some locally closed sets and spaces in Ideal Topological Spaces
On some locally closed sets and spaces in Ideal Topological SpacesIJMER
 
Intrusion Detection and Forensics based on decision tree and Association rule...
Intrusion Detection and Forensics based on decision tree and Association rule...Intrusion Detection and Forensics based on decision tree and Association rule...
Intrusion Detection and Forensics based on decision tree and Association rule...IJMER
 
Natural Language Ambiguity and its Effect on Machine Learning
Natural Language Ambiguity and its Effect on Machine LearningNatural Language Ambiguity and its Effect on Machine Learning
Natural Language Ambiguity and its Effect on Machine LearningIJMER
 
Evolvea Frameworkfor SelectingPrime Software DevelopmentProcess
Evolvea Frameworkfor SelectingPrime Software DevelopmentProcessEvolvea Frameworkfor SelectingPrime Software DevelopmentProcess
Evolvea Frameworkfor SelectingPrime Software DevelopmentProcessIJMER
 
Material Parameter and Effect of Thermal Load on Functionally Graded Cylinders
Material Parameter and Effect of Thermal Load on Functionally Graded CylindersMaterial Parameter and Effect of Thermal Load on Functionally Graded Cylinders
Material Parameter and Effect of Thermal Load on Functionally Graded CylindersIJMER
 
Studies On Energy Conservation And Audit
Studies On Energy Conservation And AuditStudies On Energy Conservation And Audit
Studies On Energy Conservation And AuditIJMER
 
An Implementation of I2C Slave Interface using Verilog HDL
An Implementation of I2C Slave Interface using Verilog HDLAn Implementation of I2C Slave Interface using Verilog HDL
An Implementation of I2C Slave Interface using Verilog HDLIJMER
 
Discrete Model of Two Predators competing for One Prey
Discrete Model of Two Predators competing for One PreyDiscrete Model of Two Predators competing for One Prey
Discrete Model of Two Predators competing for One PreyIJMER
 

Plus de IJMER (20)

A Study on Translucent Concrete Product and Its Properties by Using Optical F...
A Study on Translucent Concrete Product and Its Properties by Using Optical F...A Study on Translucent Concrete Product and Its Properties by Using Optical F...
A Study on Translucent Concrete Product and Its Properties by Using Optical F...
 
Developing Cost Effective Automation for Cotton Seed Delinting
Developing Cost Effective Automation for Cotton Seed DelintingDeveloping Cost Effective Automation for Cotton Seed Delinting
Developing Cost Effective Automation for Cotton Seed Delinting
 
Study & Testing Of Bio-Composite Material Based On Munja Fibre
Study & Testing Of Bio-Composite Material Based On Munja FibreStudy & Testing Of Bio-Composite Material Based On Munja Fibre
Study & Testing Of Bio-Composite Material Based On Munja Fibre
 
Hybrid Engine (Stirling Engine + IC Engine + Electric Motor)
Hybrid Engine (Stirling Engine + IC Engine + Electric Motor)Hybrid Engine (Stirling Engine + IC Engine + Electric Motor)
Hybrid Engine (Stirling Engine + IC Engine + Electric Motor)
 
Fabrication & Characterization of Bio Composite Materials Based On Sunnhemp F...
Fabrication & Characterization of Bio Composite Materials Based On Sunnhemp F...Fabrication & Characterization of Bio Composite Materials Based On Sunnhemp F...
Fabrication & Characterization of Bio Composite Materials Based On Sunnhemp F...
 
Geochemistry and Genesis of Kammatturu Iron Ores of Devagiri Formation, Sandu...
Geochemistry and Genesis of Kammatturu Iron Ores of Devagiri Formation, Sandu...Geochemistry and Genesis of Kammatturu Iron Ores of Devagiri Formation, Sandu...
Geochemistry and Genesis of Kammatturu Iron Ores of Devagiri Formation, Sandu...
 
Experimental Investigation on Characteristic Study of the Carbon Steel C45 in...
Experimental Investigation on Characteristic Study of the Carbon Steel C45 in...Experimental Investigation on Characteristic Study of the Carbon Steel C45 in...
Experimental Investigation on Characteristic Study of the Carbon Steel C45 in...
 
Non linear analysis of Robot Gun Support Structure using Equivalent Dynamic A...
Non linear analysis of Robot Gun Support Structure using Equivalent Dynamic A...Non linear analysis of Robot Gun Support Structure using Equivalent Dynamic A...
Non linear analysis of Robot Gun Support Structure using Equivalent Dynamic A...
 
Static Analysis of Go-Kart Chassis by Analytical and Solid Works Simulation
Static Analysis of Go-Kart Chassis by Analytical and Solid Works SimulationStatic Analysis of Go-Kart Chassis by Analytical and Solid Works Simulation
Static Analysis of Go-Kart Chassis by Analytical and Solid Works Simulation
 
High Speed Effortless Bicycle
High Speed Effortless BicycleHigh Speed Effortless Bicycle
High Speed Effortless Bicycle
 
Integration of Struts & Spring & Hibernate for Enterprise Applications
Integration of Struts & Spring & Hibernate for Enterprise ApplicationsIntegration of Struts & Spring & Hibernate for Enterprise Applications
Integration of Struts & Spring & Hibernate for Enterprise Applications
 
Microcontroller Based Automatic Sprinkler Irrigation System
Microcontroller Based Automatic Sprinkler Irrigation SystemMicrocontroller Based Automatic Sprinkler Irrigation System
Microcontroller Based Automatic Sprinkler Irrigation System
 
On some locally closed sets and spaces in Ideal Topological Spaces
On some locally closed sets and spaces in Ideal Topological SpacesOn some locally closed sets and spaces in Ideal Topological Spaces
On some locally closed sets and spaces in Ideal Topological Spaces
 
Intrusion Detection and Forensics based on decision tree and Association rule...
Intrusion Detection and Forensics based on decision tree and Association rule...Intrusion Detection and Forensics based on decision tree and Association rule...
Intrusion Detection and Forensics based on decision tree and Association rule...
 
Natural Language Ambiguity and its Effect on Machine Learning
Natural Language Ambiguity and its Effect on Machine LearningNatural Language Ambiguity and its Effect on Machine Learning
Natural Language Ambiguity and its Effect on Machine Learning
 
Evolvea Frameworkfor SelectingPrime Software DevelopmentProcess
Evolvea Frameworkfor SelectingPrime Software DevelopmentProcessEvolvea Frameworkfor SelectingPrime Software DevelopmentProcess
Evolvea Frameworkfor SelectingPrime Software DevelopmentProcess
 
Material Parameter and Effect of Thermal Load on Functionally Graded Cylinders
Material Parameter and Effect of Thermal Load on Functionally Graded CylindersMaterial Parameter and Effect of Thermal Load on Functionally Graded Cylinders
Material Parameter and Effect of Thermal Load on Functionally Graded Cylinders
 
Studies On Energy Conservation And Audit
Studies On Energy Conservation And AuditStudies On Energy Conservation And Audit
Studies On Energy Conservation And Audit
 
An Implementation of I2C Slave Interface using Verilog HDL
An Implementation of I2C Slave Interface using Verilog HDLAn Implementation of I2C Slave Interface using Verilog HDL
An Implementation of I2C Slave Interface using Verilog HDL
 
Discrete Model of Two Predators competing for One Prey
Discrete Model of Two Predators competing for One PreyDiscrete Model of Two Predators competing for One Prey
Discrete Model of Two Predators competing for One Prey
 

At2419231928

  • 1. International Journal of Modern Engineering Research (IJMER) www.ijmer.com Vol.2, Issue.4, July-Aug 2012 pp-1923-1928 ISSN: 2249-6645 Oofp: Mapping the Oose Models into Function Points: Rules, Tool and Case Study 1 Durga Gehlot, 2Prof. Meena Sharma 1 Departmen of Computer Engineering, Institute of Engineering and Technology, DAVV Indore, India 2 HOD of Computer Engineering, Institute of Engineering and Technology, DAVV Indore, India Abstract: Function point analysis is useful to measure size 1.1Function Point Analysis with object – oriented design of software projects in terms of functionality requested by methods user. The main advantage of function point analysis is that The Function Point software measure does not it is independent of the technology used for implementation. require a particular development technique. However, the When we apply function points to object-oriented software high level concepts of object-oriented development methods projects, the concepts of development method have to be cannot be mapped directly to the concepts of Function Point mapped into abstract models that contain functional items Analysis. In order to apply this software measure early in of the application. This proposed idea implement a tool for the development process, the object-oriented concepts mapping function points into use case driven OOSE (object- corresponding to transactional and data function types have oriented software engineering) Jacobson approach. In this to be determined. idea we only considers analysis phase of OOSE life cycle. Object-oriented methods differ, especially in their OOFP tool measures function point from requirements early development phases. The Object-Oriented method of models and analysis model. Jacobson et al. is based on so-called use cases. The OO- Keyword: function points, size, requirements model, and Jacobson identifies the functionality of an application with analysis model, OOFP. requirements use case model. Data types are described with I. INTRODUCTION domain or analysis object model on the requirements level. Function Points Analysis (FPA) is one of the The work proposes rules to map these models into function earliest models that are used to predict the size of software point counting procedures. With proposed rules, it is in the early stages. Albrecht proposed the FPA model in possible to count software developed with the OO-Jacobson 1979 and it measures the size of software based on its method. functionalities [1]. The main advantages of the FPA model In this research paper, we focus on the approach of are that it is independent of the technology. Up to the Jacobson et al [3]. This method is called Object- Oriented present, various FPA versions based on the Albrecht’s Software Engineering. The OOSE method defines a process version have been proposed (e.g. IFPUG method, MarkII, to transform formalized requirements into a sequence of COSMIC-FFP and they have been accepted as ISO/IEC models. The steps include the requirements, analysis, standards. The current version of counting rules is recorded design, implementation and testing models. The use case in the Counting Practices Manual [2]. This counting method model is the basis on which all the models are developed. isimplicitly based on the high- level model of software Together with the domain object model it forms applications. Though independent of implementation, requirements model as shown in Figure 1. counting rules are thus based on the implicit assumptions on the abstract model of software applications. The items in the abstract model that are than counted include transaction and file types. These items are typically identified from documents of traditional, structured design technique e.g. data flow diagrams, hierarchical process models or database structures. The proposed paper focus on object oriented models based on the OOSE Jacobson approach. The transaction and file type items are counted from models of analysis phase. The models of analysis phase of OOSE includes use case model, domain object model and analysis model but this research paper focuses on counting function points from analysis model and use case model. Figure 1: The use case model is the basis on which all other models of OOSE approach are developed. www.ijmer.com 1923 | P a g e
  • 2. International Journal of Modern Engineering Research (IJMER) www.ijmer.com Vol.2, Issue.4, July-Aug 2012 pp-1923-1928 ISSN: 2249-6645 The objectives of this research paper are: 1. The application of Function Point Analysis following the IFPUG standards. 2. To measure for software developed with OOSE method. 3. To count early in the life cycle, in the requirements analysis phase. 1.2 Related Work Little work has been published on Function Point Analysis in the context of object-oriented software Figure 2: Analysis Phase of the OOSE life cycle. engineering techniques. But these approaches are based on a model that consists with objects together with their At the focus of our work are the models developed methods. In these approaches objects are treated as data in analysis phase as shown in Figure2. As Jacobson et al. files and methods as transactions which are the counting state, the requirements model can be regarded as items in the Function Point Analysis. These approaches do formulating the functional requirements specification based not applicable to early OOSE documents. It is also on the needs of the users. The goal of this research paper questionable whether each individual method is to be work is to count Function Points early in the life cycle, counted as a transaction. measuring the functionality requested by the user from Whitmire[4] considers each class as an internal these models. The overview of these three models discussed logical file and treats messages sent outside the system in [7]. boundary as transactions. The ASMA paper takes a similar approach. Services III. Fuction Point Concepts delivered by objects to the client are considered as 3.1 Function Point model transactions. The complexity of services is weighted based A high level model of the FPA mode is given in on accessed attributes and communications. Objects are Figure 3 [7]. The function Point model specifies which treated as files, their attributes determining their component types of the software application will be complexity. measures and from which viewpoint this will be done. Hat IFPUG [5] is working on a case study which is to be counted, and measured, are the internal files and illustrates the use of the counting practices for object- external files of the application, together with the inputs, oriented analysis and design. This case study, which is outputs and inquiries from and to the user. Software currently in draft form, uses object models in which the components or deliverables which are not visible from a methods of classes are identical with the services recorded user viewpoint are not considered part of the Function Point in the requirements. Under this assumption, the methods measurement model. can be counted as transactions. Karner [6] proposes a new measure called Use Function Point Model Case Points for projects developed with the OOSE method. The structure of this measure is similar to Function Points, but it does not conform to the concepts of Function Points. Thomas Fetcke[7] proposes rules for mapping the OO-Jacobson approach into Function Point Analysis. This paper is based on Thomas proposed rules. This research paper considers how to apply these rules to OOSE models to measure data and transaction functions. In this paper data files and transactionfunctions counting is done using models of analysis phase of the OOSE life cycle. Analysis Figure 3: High-level view of the abstract Function Point phase model includes use case model and analysis model. model with users and links to other applications. The dotted line marks the application boundary. II. Brief Introduction To Oose The OOSE method is divided into three major 3.2 Function Point Counting Process consecutive processes: analysis, constructive and testing. In the IFPUG version, the counting procedure of The analysis phase is further divided into two steps called function point consists of the following seven steps. The details of these seven steps are discussed in IFPUG [2]. requirements analysis and robustness analysis as shown in Figure 2. The first step derives the requirements model 1. Determine type of function point count. 2. Identify the application boundary (A boundary from the informal customer requirements. This model is indicates the border between theapplication or project expressed in terms of use case model, and may be augmented by a domain object model. The second step, being measured and the external applications or the robustness analysis, then structures the use case model into user domain. A boundary establishes which functions the analysis model by applying use case analysis. The are included in the function point count). 3. Identify and rate transactional function types to succeeding process furthertransforms these models, as determine their contribution to the unadjusted function indicated in Figure 1. point count. 4. Identify and rate data function types to determine their contribution to the unadjusted function point count. www.ijmer.com 1924 | P a g e
  • 3. International Journal of Modern Engineering Research (IJMER) www.ijmer.com Vol.2, Issue.4, July-Aug 2012 pp-1923-1928 ISSN: 2249-6645 5. Determine the Unadjusted function point counts. 5. Select every use case that extends a use case selected by 6. Determine the value adjustment factor (VAF) that takes rule 4 as a candidate. so-called global system characteristics into account, 6. No other use cases will be counted. e.g. data communication, performance or end user Determining the types of transaction (external input (EI), efficiency. This adjustment is external of and external output (EO) and external inquiry (EQ) is based on independent from the concepts of the abstract FPA a set of detailed rules in FPA [1]. The rules are recorded in model. The global system characteristics determine the IFPUG Counting Practices Manual [2]. The relevant an adjustment factor that is multiplied with the sections are: unadjusted count. “External Input Counting Rules”, 7. Calculate the adjusted function point count. “External Output Counting Rules”, and The next section describes the proposed mapping “External Inquiry Counting Rules”. of OOSE models to function points along these five steps. The rates of transactions are based on detailed rules in the IV. Mapping Concepts (Proposed Method) counting practices Manual. The rules require the The aim of this research paper is to calculate the determination of data element types (DET) and file types Unadjusted Function Point. The paper work proposes the that are referenced (FTR), illustrated in Figure 5 following five steps to apply IFPUG version to the OOSE . requirements analysis models (use case model and analysis 4.4 Step4 (Identify and rate data function types to model). determine their contribution to the unadjusted function 4.1 Step1(Determine the type of function count): This point count.): paper handles only the application project function Data files are automatically decided based on analysis point. classes of analysis model. In the analysis model, the objects 4.2 Step2(Identify the application boundary): The counting are typed into three groups, namely entity, interface and boundary is determined by the type of actors appeared control objects. The set of objects that have to be analyzed in use case model of OOSE requirement analysis is limited to the entity objects and is thus set of objects phase. typically smaller. Interface (boundary) and control objects are part of implementation. Proposed mapping rules to identify the application boundary 4.4.1 Finding of Analysis Classes from Use Case Model 1. Accept each human actor as a user of the system. 1. Is this candidate inside our system boundary? 2. Accept each non-human actor, which is separate 2. If not, it might be an actor of our system. system not design to provide functionality solely to the Does this candidate have identifiable behavior for our system under consideration as an external application. problem domain? 3. Reject each non-human actor, which is part of the (i.e., can we name the services/functions that are underlying system, e.g. a rational database system or a needed in our problem domain and that this candidate printing device. would own and provide?) The result is a representation of the application boundary as 3. Does this candidate have identifiable structure? a set of users and applications external to the one under (i.e., can we identify some set of data this candidate consideration as shown in Figure 4. should own and manage?) 4. Does this candidate have relationships with any other candidates? Figure 4: Step2- Identification of the counting boundary. 4.3 Step3 (Identify and rate transactional function types to determine their contribution to the unadjusted Function point count.): The transaction functions are automatically decided based on actors and use cases of the use case model. Use cases are the OOSE concept corresponding to transactions. If you find a "no," then the candidate is probably not a class; move on to the next candidate. If the answer is Proposed mapping rules to identify and rate transaction "yes," keep asking the questions. If you get all "yes" function types answers, conclude the candidate is a class, and get the next candidate to evaluate. 4. Select every use case that has a direct relation to an actor accepted by rule 1 or 2. This use case will be a candidate Proposed mapping rules to identify and rate data for one or several transactions. function types www.ijmer.com 1925 | P a g e
  • 4. International Journal of Modern Engineering Research (IJMER) www.ijmer.com Vol.2, Issue.4, July-Aug 2012 pp-1923-1928 ISSN: 2249-6645 7. Select every object of entity type as a candidate for a 4.5 Step 5 (Determine the unadjusted function point logical file. counts) 8. No other objects will be selected. As the result of Step3 and Step4, the counts for each function type are automatically classified according to For aggregation relationships complexity and then weighted. The total for all function 9. An entity objects that is part of another object (is types is the unadjusted function point count. aggregated into another object) is not a candidate for a logical file, but it is a candidate for a record element V. CASE STUDY type (RET) for the file related to the aggregating top- In this section the rules proposed in section 4 are applied to level object OOSE approach based project. The documentation provided included use case models and analysis object For inheritance relationships models together with the textual description these models. 10. An abstract object is not a candidate for a logical file. It is a candidate for a RET for each object that inherits its 5.1 Example of OOSE based analysis models properties. In OOSE life cycle, analysis phase is divided into 11. Sub-objects of a concrete object are candidates for a two phases: requirement analysis and robustness analysis. logical file or for a RET of that object. Requirement analysis consists with two models, use case 12. If use cases make implicit use of logical files that are models and domain object models. Robustness analysis not represented in the analysis object (class) model, consists with a model known as analysis model. This these files have to be included in the set of files. research work focuses on use case models and analysis classes. Determining the types of data files (internal logical files (ILF) and external interface files (EIF)) is based on a Case Study: A part of Course Registration System Use set of detailed rules in FPA [1]. The rules are recorded in Case Model the IFPUG Counting Practices Manual [2]. The relevant section is “ILF/EIF counting rules”. The rates of data files are based on detailed rules in the counting practices Manual. The rules require the determination of data element types (DET) and record element types (RET), illustrated in Figure 5. Figure6: Use Case: Register for Courses This use case allows a Student to register for course offerings in the current semester. The Student can also update or delete course selections if changes are made within add/drop period at the beginning of the semester. The Course Catalog System provides a list of all the course offerings for the current semester. Figure 5: Step3 and Step4- Rating of data and transaction function types. 5.2 Finding Analysis classes from use case model (Behavior) Proposed Mapping Rules for determining DET, RET Register for Courses Use Case-This use case starts when a and FTR Student wishes to register for course offerings, or to change 13. Attributes of objects are candidates for data element his/her existing course schedule. types (DET) for files and for the transactions by which 1. The system requests that the Student specify the it is read and maintained. function he/she would like to perform (Create a 14. Candidates for record element types are determined by Schedule, Update a Schedule, or Delete a Schedule). subgroups of files and by rules 9-11. 2. Once the Student provides the requested information, 15. Each object maintained and /or read by a use case one of the sub flows is executed. If the Registrar counts as a file type referenced (FTR) for the selected “Create a Schedule”, the Create a Schedule associated transaction(s), if and only if the object has sub flow is executed. If the Registrar selected “Update been identified as a file in step 4. a Schedule”, the Update a Schedule sub flow is After determining DETs, RETs, FTRs rate the data executed. If the Registrar selected “Delete a Schedule”, files and transaction functions according to rating matrix the Delete a Schedule sub flow is executed. and then allot weighs according to weighting matrix in the Candidates for entity (noun) and applying 4 conditions of Counting Practices Manual [2]. The total weight of data section 4.4.1 to make them entity analysis classes as shown files types and transaction types are the required unadjusted in Figure7. function points count. 1. Student-A person enrolled in classes at the university. 2. Schedule-The courses a student has selected for the current semester. www.ijmer.com 1926 | P a g e
  • 5. International Journal of Modern Engineering Research (IJMER) www.ijmer.com Vol.2, Issue.4, July-Aug 2012 pp-1923-1928 ISSN: 2249-6645 3. Course Offering-A specific delivery of the course for a specific semester – you could run the same course in parallel sessions in the semester. Includes the days of the week and times it is offered. Figure7: Analysis class model consists with entity analysis classes 5.3 Now, applying proposed rules to Analysis Class Table2: Global System Characteristics (GSC) Model and Use Case Model of above Case Study: So using formulae: By rules 1, 2 and 3 application boundary includes- VAF = 0.65 + ((sum of all GSC factor)/100). Human actors- student = 0.65 + (22/100) = 0.87 Non-human actors-Nil This factor affects the whole FP like anything, be very By rules 4-12 and 13-15 candidates for transaction/data particular with this factor. function types with ratings and weight are shown in So now, calculating the Table1. Adjusted FP (AFP) = VAF * Total Unadjusted FP (UAFP) Transactio Transactio No. of No. of Comple Weight/ = 0.87* 24 =20.88, n/ data n/ data DET RET/ xity Value =Rounded to 21 FPs function function FTR Compared with the approaches proposed in the literature, name type these mapping rules have certain advantages. Register EI 3 2FTRs low 3 1. The mapping rules are based on the standard FPA for (Studen defined in the IFPUG Counting Practice Manual. This courses t, widely used measure independent of technology. Schedul 2. The count is based on requirements models, which are e) the first models available in the OOSE life cycle. For Register EO 3 2FTRs low 3 the purpose of effort estimation based on Function for (Studen Points, this is an essential prerequisite. courses t, This approach also has some limitations. Schedul 1. The main limitation is the focus on the Jacobson OOSE e) method. Mapping rules are based on the requirements models of this approach and cannot be applied to Register EQ 4 1FTR low 4 methods that do not develop these models. Also an for (Course advantage this focus on OOSE, that the models are courses Offerin unambiguously defined in the method. g) Student ILF 3 1RET(S low 7 VI. OOFP TOOL chedule The concept of mapping the object oriented software ) models into function Points lead to implement a tool Course ILF 4 1RET(S low 7 called OOFP. This tool is implemented in java language. Offering chedule The inputs for the tool are use case model and analysis class ) (object) model and the output includes the values of UAFP 24 FPs function points, transactional functions, and data functions. The OOFP tool is automated using XMI (xml Table1: Transaction/Data function types with ratings metadata interchange) parser. The XMI parser takes .xmi or and weight. .xml files of use case and analysis class models as input In order to make it adjusted function point, we have to then read and extracts the use cases, actors, entity classes calculate and tabulate the GSC and come out with the VAF from these files. Extracted candidates are then used for as shown in Table2. calculating function points. www.ijmer.com 1927 | P a g e
  • 6. International Journal of Modern Engineering Research (IJMER) www.ijmer.com Vol.2, Issue.4, July-Aug 2012 pp-1923-1928 ISSN: 2249-6645 Screen1: Function Point Calculation Figure: 8 Function Point Counting Tool (OOFP tool). VII. SUMMARY This work demonstrated the applicability of function points as a measure of functional software size to the object- oriented Jacobson approach, OOSE. This work supports that the function point measures independent of the technology used for implementation and that it can be used in the object-oriented paradigm. Future work in the field has to deal with the mapping of Screen 2: Value Adjustment Factor OOSE design model into function points. References [1] A. J. Albrecht. Measuring Application Development Productivity. IBM Applications Development Symposium, Monterey, CA, 1979 [2] Function Point Counting Practices Manual, Release 4.0. Westerville. Ohio, International Function Point Users Group, 1994. [3] Jacobson, I., M. Christerson et al. Object-Oriented Software Engineering. A Use Case driven Approach. Addison-Wesely, 1992. [4] Whitmire, S.A. Applying function points to object-oriented software models, 1992. In Software engineering productivity handbook. J. Keyes, McGraw-Hill, pp.229-244. Screen 3: Function Point Report for a Project [5] Function Point Counting Practices: case Study3- Object- Oriented Analysis. Object-Oriented Analysis. Object- Oriented Design (Draft), International Function Point Users Group, 1995. [6] Karner, G. Resource Estimation for Objectory Projects, Objectory Systems, 1993. [7] ThomasFetcke, Alain Abran and THo- Hau Nguyen.Mapping the OO-Jacobson Approach into Function Point Analysis, 1997.Published in the Proceeding of TOOLS- 23’97. [8] “CostEstimatingWebSite”, http://cost.jsc.nasa.gov/COCOMO.html [9] “Construx Estimate tool”, www.construx.com [10] ”CoStar tool”, www.softstarsystems.com [11] “An introduction (tutorial) to Function Point Analysis”, www.devdaily.com/FunctionPoints. VIII. APPENDIX: Screenshots For OOFP Tool The following screenshots show how function points are calculated using OOFP (Object oriented function point) tool. www.ijmer.com 1928 | P a g e