1. Metrics for OO Design Distinct & measurable characteristics of OO design:- Size:-it is defined as – population,volume,length & functionality Population – it’s a static count of OO entities such as classes/operations Volume– dynamically maintained OO entities Length- chain of interconnected design elements Functionality-indirect identification of the value delivered to the customer by OO application Complexity:-examination of OO classes interaction Coupling:-the connection between of OO design Sufficiency:- does the class fully reflect all properties of application domain Completeness:-whether some components can be reusable? Cohesion:- OO component has been designed together and has all operations working to achieve a single component

2. Class oriented metrics The class is the fundamental unit of an OO system;to assess OO design quality measures and metrics of individual class, class hierarchy,class collaboration are observed A class encapsulates data and the function manipulates data,it is “parent” for subclasses that inherit its attributes and operations CK metrics suite – Chidamber and Kemerer have proposed most widely referenced sets of OO s/w metrics (CK metrics suite)- proposed six class based design metrics for OO system(Pg 628) – Weighted method per class(WMC) – Depth of Inheritance Tree(DIT) – No.of Children(NOC) – Coupling between object classes(CBO) – Response for class(RFC) – Lack of Cohesion in methods(LCOM)

3. Use case estimation Use case oriented metrics:-use cases are used for customer level or business domain requirements They imply s/w features and functions Use case is used as a normalization measure just like FP or LOC They describe user visible functions and features that are basic requirements of a system Use cases are independent of programming lang/technology used The number of use cases are directly proportional to the size of application in LOC and to the no.of test cases designed to fully exercise the application No std.size for use case and Researchers have proposed use case pts(UCPs) as a techq. for estimating project effort UCP is a function of the no.of actors and transactions implied by the use case models and its similar to FP

4. Estimation with use cases Use cases provide an insight into s/w scope and requirements to a s/w team Use cases can be problematic for following reasons:- – Use cases described using many diff formats & styles – They represent an external view of s/w – They do not address the complexity of functions and features that described – They describe complex behavior,involves many functions and features Unlike LOC/FP,one person’s use case may require months of effort while another’s may be implemented in a day or two Before use cases can be used for estimation, the level within structural hierarchy is established, the avg.length of each use case is determined, the type of s/w(webApp,scientific/engineering,business,real time or embedded) defined & a rough architecture is considered Empirical(experimental/observed) data may be used to establish the estimated no.of LOC or FP per use case LOC estimate=N*LOCavg + [(Sa/Sh – 1) + (Pa/Ph – 1)] * LOCadjust Where N– no.of actual use cases, LOCavg—avg(observed)LOC per use case LOCadjust—represents an adjustment based on n percent of LOCavg Sa– actual scenarios per use case Sh—avg.scenarios per use case Pa- actual pages per use case Ph- avg.pages per use case Refer http://www.ibm.com/developerworks/rational/library/edge/09/mar09/collaris_dekker/ Refer http://www.ibm.com/developerworks/rational/library/edge/09/mar09/collaris_dekker/

5. OO Tracking programs (like conclusion of the story) Technical milestone:-OO analysis completed – All classes and class hierarchy defined & reviewed – Class attributed and operations associated with a class defined & reviewed – Class relationship have been established & reviewed – Behavioral model created – Reusable classes noted Technical milestone :-OO design completed The set of subsystems have been defined and reviewed Classes are allocated to subsystems and reviewed Task allocation has been done and reviewed Responsibilities and collaborations have been identified Attributes and operations redefined The communication model has been generated Technical milestone :-OO programming completed Each new class implemented in code Extracted classes(from a reuse library) have been implemented Prototype or increment has been built Technical milestones :- OO testing – The correctness and completeness of OO analysis and design – A Class Responsibility Collaboration Network has been developed – Test cases designed – Cluster testing completed – System level tests completed

6. Introduction to CASE System analysis and design process is a complex process. It requires a careful steps and planning. Methodologies and approaches has been developed to systematically improve the efficiency and effectiveness of this process so it can better support and be aligned with the business needs. The emergence of personal computer has enabled the broader adoption of CASE tools which were previously only available on commonly very expensive mainframe. Because of the wide selection available on the market right now, managers of organization need to wisely select the appropriate CASE tool for their organizational need. Although the CASE tools being evaluated is not very extensive, this online paper is intended to give an overview and a initial thought on selecting the a CASE tool. Case Tool Computer-aided software engineering (CASE) tools is defined as software tools that provide automated support for some portion of the systems development process. CASE tool can be categorized into three categories: Upper CASE Middle CASE Lower CASE Because of their similarities, sometimes Upper and Middle CASE are simply referred as Upper CASE. Generally, Upper CASE is a tool for high level view of software development whereas lower CASE is mostly being used as a tool at the programming and testing phase.

7. CASE history in a nutshell Software designers have used diagrammatic representations of their designs since the earliest days of software development. Over time the nature of these design diagrams has changed and so have the tools used to produce them. Much like early word processors replaced typewriters, early CASE tools served as electronic replacements for paper, pencil, and stencil. Many of these early CASE tools became unused "shelfware" because they did not provide significant value to software designers (Iivari, 1996). Later,CASE tools added sophisticated code generation, reverse engineering, and version control features. These features add value via increased automation of some design tasks, for example, converting a design into a source code skeleton.

8. What is CASE (Computer-AidedSoftware Engineering)? Software systems which are intended to provide automated support for software process activities. CASE systems are often used for method support The CASE tools may also include a code generator which automatically generates source code from the system model and some process guidance which gives advice to the software engineer on what to do next. This type of CASE tool, aimed at supporting analysis and design, is sometimes called an upper- CASE tool because it supports early phases of the software process