OBJECT ORIENTED ANALYSIS AND DESIGN UNIT-1

1. SYSTEM DEVELOPMENT:
System development is the process of defining, designing, testing and implementing a new software application program. It could include the internal development of customized systems, the creation of database system, or the acquisition of third party developed software. There have been basically 3 approaches in information system development area: processoriented, data-oriented and object-oriented approaches. As information technology (both hardware and software) has been advancing, people have moved from the earliest processoriented approach to data-oriented approach and now begun to adopt the latest objectoriented analysis methodology. Unlike its two predecessors that focus either on process or data, the object-oriented approach combines data and processes (called methods) into single entities called objects. Objects usually correspond to the real things an information system deals with, such as customers, suppliers, contracts, and rental agreements. Object-oriented model is able to thoroughly represent complex relationships and to represent data and data processing with a consistent notation, which allows an easier blending of analysis and design in an evolutionary process. The goal of object-oriented approach is to make system elements more reusable, thus improving system quality and the productivity of systems analysis and design. Though systems analysis is closed associated with design, this paper tries to focus on analysis part of the methodology. Mechanism of Object-oriented Approach The principals of objects, encapsulation, inheritance, and polymorphism are the foundation for object-oriented systems development. To understand and express the essential and interesting features of an application in the complex real world, an object-oriented model is built around objects. An object encapsulates both data and behavior, implying that analysts can use the object-oriented approach for both data modeling and process modeling. Specific objects in a system can inherit characteristics from the global instance of an object. For example, many types of objects may have a name and a creation date. Specific objects can inherit these global characteristics from parent objects that include only global characteristics. Objects can inherit characteristics from more than one parent

object. Inheritance attempts to avoid the redundant definition of similar characteristics that can be embodied at higher levels in the system By a concept called polymorphism, functionality that is conceptually similar among differing objects is extracted to a global level. This process limits the production of parallel functionality and streamlines the information interface. Polymorphism directs the specification writer to understand the functionality of a process and make it available to any object that requires a similar instance of functionality

2. OBJECT BASICS:
In old style programming, you had: Data, which was completely passive. Functions, which could manipulate any data. An object contains both data and methods that manipulate that data. An object is active, not passive; it does things. An object is responsible for its own. But: it can expose that data to other objects An object has state: An object contains both data and methods that manipulate that data.. The data represent the state of the object. Data can also describe the relationships between this object and other objects Example: A CheckingAccount might have A balance (the internal state of the account), An owner (some object representing a person) Every object belongs to (is an instance of) a class: Object may have fields, or variables. The class describes those fields. An object may have methods. The class describes those methods.

3. SYSTEM DEVELOPMENT LIFE CYCLE:

The Systems Development Life Cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project from an initial feasibility study through maintenance of the completed application. Various SDLC methodologies have been developed to guide the processes involved including the waterfall model (the original SDLC method), rapid application development (RAD), joint application development (JAD), the fountain model and the spiral model. Mostly, several models are combined into some sort of hybrid methodology. Documentation is crucial regardless of the type of model chosen or devised

for any application, and is usually done in parallel with the development process. Some methods work better for specific types of projects, but in the final analysis, the most important factor for the success of a project may be how closely particular plan was followed. The image below is the classic Waterfall model methodology, which is the first SDLC method and it describes the various phases involved in development.

Briefly on different Phases: Feasibility The feasibility study is used to determine if the project should get the go-ahead. If the project is to proceed, the feasibility study will produce a project plan and budget estimates for the future stages of development. Requirement Analysis and Design Analysis gathers the requirements for the system. This stage includes a detailed study of the business needs of the organization. Options for changing the business process may be considered. Design focuses on high level design like, what programs are needed and how are they going to interact, low-level design (how the individual programs are going to work), interface design (what are the interfaces going to look like) and data design (what data will be required). During these phases, the software's overall structure is defined. Analysis and Design are very crucial in the whole development cycle. Any glitch in the design phase could be very expensive to solve in the later stage of the software development. Much care is taken during this phase. The logical system of the product is developed in this phase.

Implementation In this phase the designs are translated into code. Computer programs are written using a conventional programming language or an application generator. Programming tools like Compilers, Interpreters, Debuggers are used to generate the code. Different high level programming languages like C, C++, Pascal, Java are used for coding. With respect to the type of application, the right programming language is chosen. Testing In this phase the system is tested. Normally programs are written as a series of individual modules, these subject to separate and detailed test. The system is then tested as a whole. The separate modules are brought together and tested as a complete system. The system is tested to ensure that interfaces between modules work (integration testing), the system works on the intended platform and with the expected volume of data (volume testing) and that the system does what the user requires (acceptance/beta testing). Maintenance Inevitably the system will need maintenance. Software will definitely undergo change once it is delivered to the customer. There are many reasons for the change. Change could happen because of some unexpected input values into the system. In addition, the changes in the system could directly affect the software operations. The software should be developed to accommodate changes that could happen during the post implementation period.

4. OOAD METHODOLOGIES:
OOAD methodologies fall into two basic types. The ternary (or three-pronged) type is the natural evolution of existing structured methods and has three separate notations for data, dynamics, and process. The unary type asserts that because objects combine processes (methods) and data, only one notation is needed. The unary type is considered to be more object-like and easier to learn from scratch, but has the disadvantage of producing output from analysis that may be impossible to review with users. Dynamic modeling is concerned with events and states, and generally uses state transition diagrams. Process modeling or functional modeling is concerned with processes that transform data values, and traditionally uses techniques such as data flow diagrams. n the following sections, I describe the methodologies of Booch, Coad and Yourdon, Fusion, Jacobson, LBMS, Rumbaugh, and Shlaer and Mellor.

3.1 Booch Booch is the chief scientist at Rational Software, which produces Rational Rose. (Now that James Rumbaugh and Ivar Jacobson have joined the company, Rational Software is one of the major forces in the OOAD world.). While the Booch methodology covers requirements analysis and domain analysis, its major strength has been indesign. However, with Rumbaugh and Jacobson entering the fold, the (relative) weaknesses in analysis are disappearing rapidly. I believe that Booch represents one of the better developed OOAD methodologies, andnow that Rational Rose is moving away from its previous tight link with C++ to a more open approach that supports 4GLs such as PowerBuilder, the methodology's popularity should increase rapidly. For systems with complex rules, state diagrams are fine for those with a small number of states, but are not usable for systems with a large number of states. Once a single-state transition diagram has more than eight to10 states, it becomes difficult to manage. For more than 20 states, state transition diagrams become excessively unwieldly. 3.2 Coad and Yourdon: Coad and Yourdon published the first practical and reasonably complete books on OOAD (Object-Oriented Analysis and Object-Oriented Design, Prentice-Hall, 1990 and 1991, respectively). Their methodology focuseson analysis of business problems, and uses a friendlier notation than that of Booch, Shlaer and Mellor, or theothers that focus more on design. In Coad and Yourdon, analysis proceeds in five stages, called SOSAS: Subjects: These are similar to the levels or layers in data-flow diagrams and should contain five to nine objects.* Objects: Object classes must be specified in this stage, but Coad and Yourdon provide few guidelines for howto do this.* Structures: There are two types: classification structures and composition structures. Classification structures correspond to the inheritance relationship between classes. Composition structures define the other types of relationships between classes. Coad and Yourdon do not deal as well as Rumbaugh, Jacobson, and several other methodologies do with these structures.* Attributes: These are handled in a fashion very similar to that in relational analysis.* Services: The identification of what other methodologies call methods or operations In design, these five activities are supplanted by and refined into four components:* problem domain component: classes that deal with the problem domain; for example, Customer classes and Order classes* human interaction component: userinterface classes such as window classes* task management component: systemmanagement classes such as error classes and security classes* data management component: database access method classes and the like Although Coad and Yourdon's methodology is perhaps one of the easiest OO methodologies to learn and get started with, the most common complaint is that it is too simple and not suitable for large projects. However, if you adhere to a premise that you should use those

pieces of a methodology that work, and add other parts from other methodologies as required, Coad and Yourdon's methodology is not as limiting as its critics claim. 3.3 Fusion I have never used Fusion, but everything I read and hear about it places it at or near the head of the pack. In1990, Derek Coleman of Hewlett-Packard led a team in the U.K. to develop a set of requirements for OOAD, and conducted a major survey of methods in use at HP and elsewhere. The chief requirement was a simple methodology with an effective notation.The result was Fusion, which Coleman and others developed by borrowing and adapting ideas from other m e t h o d o l o g i e s . Th e y i n c o r p o r a t e d s o m e m a j o r i d e a s f r o m B o o c h , J a c o b s o n , R u m b a u g h , a n d o t h e r s , a n d explicitly rejected many other ideas from these methodologies. Articles that Fusion practitioners have written have been some of the most pragmatic and useful that I have seen about OOAD, but, unless you conduct a significant research effort, you generally hear much more about other methodologies than about Fusion.Coleman did not use some of the major components of Rumbaugh and Shlaer and Mellor in Fusion, because the components were not found to be useful in practice. Some writers have called this encouraging and remarkable, and consider it indirect proof that excessive emphasis on state models comes from Rumbaugh and Shlaer andMellor's telecommunications and real time system backgrounds. F u s i o n ' s p r a g m a t i c a p p r o a c h s e e m s t o h o l d c o n s i d e r a b l e p o t e n t i a l f o r c l i e n t / s e r v e r a p p l i c a t i o n s , b u t t h i s methodology is not being marketed as aggressively as most of the other methodologies.

3.4 Jacobson: Objectory and OOSE

Although Jacobson's full OOAD methodology, Objectory, is proprietary (to use it you must buy consulting services and a CASE tool, OrySE, from Rational Software), it is probably the most serious attempt by an OOAD tool vendor to support the entire software development life cycle. Jacobson is considered to be one of the most experienced OO experts for applying OO to business problems such as client/server applications. Jacobson's Object-Oriented Software Engineering (OOSE) is a simplified version of Objectory, which Jacobson h i m s e l f h a s d e c l a r e d i n a d e q u a t e f o r p r o d u c t i o n a p p l i c a t i o n s . The major distinguishing feature in Jacobson is the use case. A use-case definition consists of a diagram and a description of a single interaction between an actor and a system; the actor may be an end user or some other object in the system. For example, the use-case description of an order-entry application would contain a detailed description of how the actor (the user) interacts with the system during each step of the order entry, and would include descriptions of all the exception handling that might occur. According to Jacobson, a use case is any description of a single way to use a system or application, or any class of top-level usage scenario, that captures how actors use their black-box applications. An actor is an interface to the system, that is, something with which the system communicates, and may be a person or another program. Jacobson adds that a use case is any behaviorally

related sequence of transactions that a single actor performs in a dialog with a system, in order to provide some measurable value to the actor. Generally, you employ use cases to document user requirements in terms of user dialogs with a system. Usecases appear first in the requirements model, and are then used to generate a domain object model with objects drawn from the entities of the business as mentioned in the use cases. This is then converted into an analysis model by classifying the domain objects into three types: interface objects, entity objects, and control objects. The big danger with OOSE is the assumption that you can express all sequences and business in use cases.

3.5 LBMS SEOO

Systems Engineering OO (SEOO) is a proprietary methodology and toolkit from the U.K.-based company LBMS, which has its U.S. headquarters in Houston. SEOO is tightly integrated with Windows 4GLs such as PowerBuilder, and is perceived to be a very pragmatic and useful tool, but this perception may be due in part to a stronger marketing effort than is often made for nonproprietary methodologies. LBMS focuses on selling CASE tools that support its methodology, and SEOO is the only methodology described in this article that is not documented in a published book. Because SEOO is proprietary, there is not as much detailed information available about it as there is about other methodologies, and it is somewhere between difficult and impossible to try it out just to compare it with the others. The four major components of the SEOO methodology are:* work-breakdown structures and techniques* an object modeling methodology* GUI design techniques* relational database linkages to provide ER modeling and 4GL-specific features Of all the major OOAD approaches, only SEOO gives the feeling of having started with non-OO approaches a n d then adapting to OO. A very positive aspect of this is the heavy focus o n d a t a m a n a g e m e n t a n d d a t a modeling. SEOO is intended to be object oriented while retaining the advantages of traditional data modeling. This makes the methodology well-suited for client/server database applications. SEOO is unique in treating data, triggers, and referential-integrity rules as a set of shared objects in a database. It treats a data model as a view of the shared objects, which also include constraints, rules, and dynamics (state transitions and so on). SEOO draws a clear line between shared objects and other objects, and regards the shared objects as important interfaces between subsystems. This technique allows a distinction, for example, b e t w e e n c u s t o m e r b e h a v i o r s h a r e d b y a l l a p p l i c a t i o n s a n d c u s t o m e r o b j e c t b eh a v i o r u n i q u e t o a s i n g l e application.

3.6 Rumbaugh OMT

It offers one of the most complete descriptions yet written of an OO analysis methodology. Although it is somewhat lacking in OO design and construction, it contains a large number of ideas and approaches that are of significant use to analysts and

designers. Rumbaugh starts by assuming that a requirements specification exists. Analysis consists of building three separate models:* the Object Model (OM): definition of classes, together with attributes and methods; the notation is similar to that of ER modeling with methods (operations) added* the Dynamic Model (DM): state transition diagrams (STDs) for each class, as well as global event-flow diagrams* the Functional Model (FM): diagrams very similar to data flow diagrams B e c a u s e R u m b a u gh ' s n o t a t i o n ( a s w e l l a s t h a t o f B o o c h a n d S h l a e r a n d M e l l o r ) i s s u p p o r t e d b y l o w - e n d drawing tools such as Visio, I have used it not only for OO analysis, but for a number of diagrams in recent p r o p o s a l s . F o r e x a m p l e , I r e c e n t l y d r e w a d i a g r a m o f p r o j e c t d e l i v e r a b l e s ( i n a p r o p o s a l f o r a l a r g e O O development project) using Visio and Rumbaugh notation to show the object hierarchy of deliverables which, at the first level of inheritance, included hardware, software, and printed deliverables.

5. DESIGN PATTERNS:
4.1 Singleton Pattern Motivation Sometimes it's important to have only one instance for a class. For example, in a system there should be only one window manager (or only a file system or only a print spooler). Usually singletons are used for centralized management of internal or external resources and they provide a global point of access to themselves. The singleton pattern is one of the simplest design patterns: it involves only one class which is responsible to instantiate itself, to make sure it creates not more than one instance; in the same time it provides a global point of access to that instance. In this case the same instance can be used from everywhere, being impossible to invoke directly the constructor each time. Intent

Ensure that only one instance of a class is created. Provide a global point of access to the object.

Implementation The implementation involves a static member in the "Singleton" class, a private constructor and a static public method that returns a reference to the static member.

4.2 Factory Pattern

Motivation The Factory Design Pattern is probably the most used design pattern in modern programming languages like Java and C#. It comes in different variants and implementations. GoF patterns: Factory Method and Abstract Factory. Intent

creates objects without exposing the instantiation logic to the client. refers to the newly created object through a common interface

Implementation

The implementation is really simple

The client needs a product, but instead of creating it directly using the new operator, it asks the factory object for a new product, providing the information about the type of object it needs. The factory instantiates a new concrete product and then returns to the client the newly created product (casted to abstract product class). The client uses the products as abstract products without being aware about their concrete implementation.

4.3 Abstract Factory

Motivation Modularization is a big issue in today's programming. Programmers all over the world are trying to avoid the idea of adding code to existing classes in order to make them support encapsulating more general information. Take the case of a information manager which manages phone number. Phone numbers have a particular rule on which they get generated depending on areas and countries. If at some point the application should be changed in order to support adding numbers form a new country, the code of the application would have to be changed and it would become more and more complicated. In order to prevent it, the Abstract Factory design pattern is used. Using this pattern a framework is defined, which produces objects that follow a general pattern and at runtime this factory is paired with any concrete factory to produce objects that follow the pattern of a certain country. In other words, the Abstract Factory is a super-factory which creates other factories (Factory of factories).

Intent

Abstract Factory offers the interface for creating a family of related objects, without explicitly specifying their classes.

The

pattern

basically

works

as

shown

below,

in

the

UML

diagram:

The classes that participate to the Abstract Factory pattern are:

AbstractFactory - declares a interface for operations that create abstract products. ConcreteFactory - implements operations to create concrete products. AbstractProduct - declares an interface for a type of product objects. Product - defines a product to be created by the corresponding ConcreteFactory; it implements the AbstractProduct interface. Client - uses the interfaces declared by the AbstractFactory and AbstractProduct classes.

The AbstractFactory class is the one that determines the actual type of the concrete object and creates it, but it returns an abstract pointer to the concrete object just created. This determines the behavior of the client that asks the factory to create an object of a certain

abstract type and to return the abstract pointer to it, keeping the client from knowing anything about the actual creation of the object. The fact that the factory returns an abstract pointer to the created object means that the client doesn't have knowledge of the object's type. This implies that there is no need for including any class declarations relating to the concrete type, the client dealing at all times with the abstract type. The objects of the concrete type, created by the factory, are accessed by the client only through the abstract interface. The second implication of this way of creating objects is that when the adding new concrete types is needed, all we have to do is modify the client code and make it use a different factory, which is far easier than instantiating a new type, which requires changing the code wherever a new object is created.

4.4 Builder Pattern

Motivation The more complex an application is the complexity of classes and objects used increases. Complex objects are made of parts produced by other objects that need special care when being built. An application might need a mechanism for building complex objects that is independent from the ones that make up the object. If this is the problem you are being confronted with, you might want to try using the Builder (or Adaptive Builder) design pattern. This pattern allows a client object to construct a complex object by specifying only its type and content, being shielded from the details related to the objects representation. This way the construction process can be used to create different representations. The logic of this process is isolated form the actual steps used in creating the complex object, so the process can be used again to create a different object form the same set of simple objects as the first one. Intent

Defines an instance for creating an object but letting subclasses decide which class to instantiate Refers to the newly created object through a common interface

Implementation The Builder design pattern uses the Factory Builder pattern to decide which concrete class to initiate in order to build the desired type of object, as we will see below in the UML diagram:

The participants classes in this pattern are:

The Builder class specifies an abstract interface for creating parts of a Product object. The ConcreteBuilder constructs and puts together parts of the product by implementing the Builder interface. It defines and keeps track of the representation it creates and provides an interface for saving the product. The Director class constructs the complex object using the Builder interface. The Product represents the complex object that is being built.

6. FRAMEWORK:
Way of delivering application development patterns to support best practice sharing during application development. Can be viewed as the implementation of a system of design patterns. Benefits of Frameworks 1. Reusability 2. Modularity 3. Extensibility 4. Inversion of Control

Difference between Patterns and Frameworks

1. Design patterns are more abstract than frameworks. 2. Design patterns are smaller architectural elements than frameworks. 3. Design patterns are less specialized than frameworks

7.

UNIFIED

APPOACH:

The UML is a graphical /standard language for visualizing, specifying, constructing & documenting the artifacts of a software system.

8. UML:
The Unified Modelling Language, or the UML, is a graphical modelling language that provides us with a syntax for describing the major elements (called artifacts in the UML) of software systems. In this course, we will explore the main aspects of the UML, and describe how the UML can be applied to software development projects. Through to its core, UML leans towards object oriented software development, so in this course, we will also explore some of the important principles of object orientation. 8 UML diagrams are You will model the following 5 diagrams only: 1. Use case diagram 2. Activity diagram 3. Sequence diagram 4. Collaboration diagram 5. Class diagram The other UML diagrams that can be modeled in Rose are: 1. State chart diagram 2. Component diagram 3. Deployment diagram Behavior Diagrams are: 1. Sequence diagram 2. Collaboration diagram 3. State chart diagram 4. Activity diagram

1. CLASS DIAGRAM: Class is a set of objects that share the same attributes, operations &relationships. It represented by a compartmentalized rectangle. 3 compartments are: 1. Top: shows class name 2. Middle shows class attributes 3. Bottom shows class operation Eg:

2. USE CASE DIAGRAM: It shows a set of use cases and actors and their relationships.Address the static view of a system. Notations: Usecase: sequence of actions User: someone /something outside the system that interacts with the system. it is represented by a stickman.

Eg:

3. ACTIVITY DIAGRAM: Activity Diagram shows the flow of events with our system & what is going on inside a use case. We draw the activity diagram for each & every use case. Login (use case) (e.g.) ATM. It is showing flow of control from activity to activity. Notations: it represents the performance of a task within the work flow. Activity is represented by a lozenge(horizontal top and bottom with convex sides) Start state shows the beginning of a workflow on an activity diagram. There is only one start state.

Eg:

4.SEQUENCE DIAGRAM: Sequence Diagram shows step by step what must happen to accomplish a piece of functionality provided by the system. It has 2Ds,vertical dimensions represents time, Horizontal dimensions represents different objects and Vertical line is called the objects life line. Notations: Life line the existence object at a particular time. Objects are shown at the top. The object role is shown as a vertical dashed line, the life line. A message is the communication between 2 objects that triggers an event. It is represented by a labeled arrow. Each message is represented by an arrow between the life lines of 2objects.

Eg:

5. COLLABORATION DIAGRAM: It displays objects and their links to one other. It is also known as an interaction diagram. It is also generated using sequence diagram. Eg:

6. STATE CHART DIAGRAM: It shows the sequence of states. A state is represented as a rounded box, which may contain one or more compartments. Name compartment holds the name of the state. Internal transition, compartment list of actions / activities, Start & end states. Eg:

7. COMPONENT DIAGRAM: It shows relationship between the components in the system. A component may be a software component [for (e.g.) a .h file in C++ (or) a .java file in Java], a runtime component [for (e.g.) a.DLL file]. Eg:

8. DEPLOYMENT: It shows the configuration of runtime processing elements & the software components, processes &objects that live in them.It shows the nodes in the system &the connections between them. Eg:

UNIT-2 1. USE CASE MODELLING:

A very powerful UML tool is the Use Case. A Use Case is simply a description of a set of interactions between a user and the system. By building up a collection of Use Cases, we can describe the entire system we are planning to create, in a very clear andconcise manner. Use cases are usually described using verb/noun combinations for example, Pay Bills, Update Payroll, or Create Account. For example, if we were writing a missile control system, typical Use Cases for the system might be Fire Missiles, or Issue Countermeasures. Along with the name of the use case, we will provide a full textual description of the interactions that will occur between the user and the system. These textual descriptions will generally become quite complicated, but the UML provides an astoundingly simple notation to represent a Use Case, as follows:

Withdraw money -Use Case Notation Actors A Use Case cannot initiate actions on its own. An actor is someone who can initiate a Use Case. For example, if we were developing a banking system, and we have a Use Case called withdraw money, then we would identify that we require customers to be able to withdraw money, and hence a customer would become one of our actors. Again, the notation for an actor is simple:

Going further, actors can be more than just people. An actor can be anything external to the system that initiates a Use Case, such as another computer system. An actor could also possibly be a more abstract concept such as time, or a specific date. For example, we may have a use case called Purge Old Orders in an order processing system, and the initiating actor could be Last Working Day.As we have noted, actors are related to Use Cases, in the sense that it is an actor that will initiate a particular use case. We can represent this on a Use Case diagram by connecting the actor to the use case:

Figure 25 - an Actor's relationship to a Use Case Clearly, for most systems, a single actor can interact with many use cases, and a single use case can be initiated by many different actors. This leads to the full use case diagram, an example of which follows: The Purpose of Use Cases: Given the simple definition of Use Case and Actor, together with the simple visualisation of Use Cases through the UML model, we could be forgiven for thinking. Use Cases define the scope of the System. They enable us to visualise size and scope of the entire development. Use Cases are very similar to requirements, but whilst requirements tend to bevague, confusing, ambiguous and poorly written, the tighter structure of Use Cases tend to make them far more focused

The sum of the use cases is the whole system. That means that anything not covered by a use case is outside the boundary of the system we are developing. So the Use Case diagram is complete, with no holes. They allow for communication between the customer and developers (since the diagram is so simple, anyone can understand it) Use Cases guide the development teams through the development process we shall see that Use Cases are the backbone of our development, and we refer to them in everything we do It can be difficult to decide upon the granularity of use cases in a particular scenario, should each user-system interaction be a use case, or should the use case encapsulate all of the interactions? For example, let us consider the example of the ATM machine. We need to build the ATM system to allow a user to withdraw money. We might have the following series of common interactions in this scenario: enter card enter pin number select amount required confirm amount required remove card take receipt To handle the complexity of even very large systems, we need to keep the Use Cases at a fairly high level. The best way to approach a Use Case is to keep the following rule-ofthumb in mind: A Use Case should satisfy a goal for the actor Applying this simple rule to our example above, we can ask the question Is take receipt, for example, the goal for our customer? Well, not really. It wouldnt be the end of the world if the receipt wasnt dispensed. Apply the rule to the other Use Cases, and youll find that really, none of them describe the goal of the user. The goal of the user is to withdraw money, and that should be the use case! This approach can feel painful at first, as we are used to performing functional decomposition, where complex tasks are broken down into smaller and smaller tasks. Use Case Descriptions Each Use Case contains a full set of textual details about the interactions and scenarios contained within it. We shall use the following.

template: Use Case: Short Description: Pre-Conditions: Post-Conditions : Main Flow: UML Applied - Object Oriented Analysis and Design using the UML Alternate Flow(s): Exception Flow(s): Use Case Name A Brief Description of the Use Case A description of the conditions that must be satisfied before the use case is invoked A description of what has happened at the end of the use case A list of the system interactions that take place under the most common scenario. For example, for withdraw money, this would be enter card, enter pin, etc... A description of possible alternative interactions. A description of possible scenarios where unexpected or unpredicted events have taken place Use Cases at the Elaboration Phase: Our main job at the elaboration phase is to identify as many of the potential Use Cases as possible. Bearing in mind the mile wide and inch deep principle, our aim is to provide sketchy details of as many Use Cases as possible but without the need to provide the full detail of each Use Case. This will help us to avoid complexity overload. At this stage, a Use Case diagram (with actors and Use Cases), plus a brief description of each Use Case, will suffice. We can revisit the full details of the Use Cases during the construction phase. Once we have identified the use cases, we can cross reference Use Cases to requirements and ensure that we have caught all of the requirements. If we identify some very risky Use Cases at this phase, however, it will be necessary to explore the details of the risky Use Cases. The production of prototypes at this stage will help mitigate the risks.

Finding Use Cases One approach to finding Use Cases is via interviews with the potential users of the system. This is a difficult task, given that two people are likely to give two completely different views on what the system should do (even if they work for the same company)! Certainly, most developments will involve some degree of direct one-to-one user communication. However, given the difficulty of gaining a consistent view of what the system will need to do, another approach is becoming more popular the workshop. Joint Requirements Planning Workshops (JRP) The workshop approach pulls together a group of people interested in the system being developed (the stakeholders). Everyone in the group is invited to give their view of what the system needs to do. Key to the success of these workshops is the facilitator. They lead the group by ensuring that the discussion sticks to the point, and that all the stakeholders are encouraged to put their views across, and that those views are captured. Good facilitators are priceless! A scribe will also be present, who will ensure that everything is documented. The scribe might work from paper, but a better method is to connect a CASE tool or drawing tool to a projector and capture the diagrams live. The simplicity of the use case diagram is critical here all stake holders, even noncomputer literate stakeholders, should be able to grasp the concept of the diagram with ease.

2. OBJECT ANALYSIS:
1) a discovery process 2) clarifies and documents the requirements of a system 3) focuses on understanding the problem domain 4) discovers and documents the key problem domain classes 5) concerned with developing an object-oriented model of the problem domain. 6) identified objects reflect the entities that are associated with the problem to be solved

Definition

Object Oriented Analysis (OOA) is concerned with developing requirements and specifications expressed as an object model (population of interacting objects) of a system, as opposed to the traditional data or functional views. Benefits 1) Maintainability: simplified mapping to the real world a) less analysis effort b) less complexity in system design c) easier verification by the user 2) Reusability: reuse of the artifacts that are independent of the analysis method or programming language 3) Productivity: direct mapping to the features implemented in Object Oriented Programming Languages

3. OBJECT RELATIONS:
Classes and objects do not exist in isolation from one another. A relationship represents a connection among things. An object uses another external possibly shared object for its own functionality An object uses and exclusively owns another for its own functionality An object delegates some of its responsibilities to another An object in simply in relation with another (may not need its services) Static: Relations existing over a long time. Objects know about each other existence Dynamic: Relations which two objects communicate with each other Object sending stimuli to other, stimuli - events, messages Cardinalities Cardinalities are essentially the relational portions of the multiplicities, and they can be used for the purpose of making an indication among the properties.

Relationship diagram 3.1 In UML, there are different types of relationships: Generalization Association Aggregation Composition a) Generalization Relationship: Generalization relates two classes when the concept represented by one class is more general than that represented by the other. For example, Person is a generalization of Student, and conversely, Student is a specialization of Person. The more general class participating in a generalization relationship is also called the super class or parent, while the more specialized class is called subclass or child. The child always inherits the structure and behavior of the parent. However, the child may also add new structure and behavior, or may modify the behavior of the parent.

b) Association Relationship: An association is a structural relationship which represents a binary relationship between objects.

c) Aggregation Relationship: This is the Has-a or Whole/part relationship, where one object is the whole, and the other (one of) the part(s).

d) Composition Relationship: It is a special case of the aggregation relationship. A composition relationship implies strong ownership of the part by the whole. Also implies that if the whole is removed from the model, so is the part. For example, the relationship between a person and her head is a composition relationship, and so is the relationship between a car and its engine. In a composition relationship, the whole is responsible for the disposition of its parts, i.e. the composite must manage the creation and destruction of its parts.

4. ATTRIBUTES:
Attributes are the instance and class data members Class data members (underlined) are shared between all instances (objects) of a given class. Data types shown after ":" Visibility shown as: +public - private #protected

syntax: visibility name : type

5. METHODS: Operations are the class methods with their argument and return types. Public (+) operations define the class interface Class methods (underlined) have only access to class data members, no need for a class instance. syntax: visibility name : type

6. CLASS AND OBJECT RESPONSIBILITIES: It makes sense to distribute responsibility evenly among classes. For external classes, this means simpler, more robust classes to define and understand For system classes, this means: No class is unduly complex; Easier to develop, to test and maintain classes; Resilient to change in the requirements of a class; A class that it relatively small and self-contained has much greater potential for reuse. A nice way to capture class (object) responsibilities is in terms of Class-Responsibility-Collaboration (CRC) cards. CRC cards can be used in several different phases of software development. For now, we use them to capture interactions between objects and actors.

UNIT-3 1. DESIGN PROCESSES:

Analysis Phase Classs attributes, methods and associations are identified Physical entities, players and their cooperation are identified Objects can be individuals, organizations or machines Design Phase Using Implementation language appropriate data types are assigned Elevate the model into logical entities (user interfaces) Focus is on the view and access classes (How to maintain information or best way to interact with a user)

1. Concept - Change the corporate logo on all company software products. 2. Analysis - The corporate logo is a penguin of standard shape and color. Different products need different size images and each product has many windows of various size, so each product has its own image files. There are 120 different image files altogether. The 120 master copies reside on 5 servers in two cities. A single design master is in marketing. Any image changes must be manually made to each file. A problem is all those manual changes are fraught with risk. (A potential improvement has been identified, part of any good analysis.) 3. Design - We choose to solve the manual change problem once and for all, by designing a program which, given the design master, updates all 120 other masters automatically. It uses reference data in a single text file to determine master copy location and image size. The program is so easy to write that's all the design we need, other than a sample of the text file format, which will be used to test a dummy product first.

4. Implementation - A dummy product is created and the text file is written for it. Using that for testing, the program is written and debugged. The complete text file is written.

2. DESIGN AXIOMS:
An axiom is a fundamental truth that always is observed to be valid and for which there is no counter example or exception. They can not be proven or derived but they can be invalidated by counter examples or exceptions. A theorem is a proposition that may not be self-evident but can be proved from accepted axioms. A corollary is a proposition that follows from an axiom or another proposition that has been proven. o The axiom 1 of object-oriented design deals with relationships between system components (such as classes, requirements and software components) and axiom 2 deals with the complexity of design. o Axiom 1. The independence axiom. Maintain the independence of components. According to axiom 1,each component must satisfy its requirements without affecting other requirements. Eg. Let us design are frigerator door which can provide access to food and the energy lost should be minimized when the door is opened and closed. Opening the door should be independent of losing energy. o Axiom 2. The information axiom. Minimize the information content of the design. It is concerned with simplicity. In object-oriented system, to minimize complexity use inheritance and the systems built in classes and add as little as possible to what already is there.

3. CLASS DESIGN:
Introduction: UML stands for Unied Modeling Language. It represents a unication of the concepts and notations presented by the three amigos in their respective books1. The goal is for UML to become a common language for creating models of object oriented computer software. In its current form UML is comprised of two major components: a Meta-model and a notation. In the future, some form of method or process may also be added to; or associated with, UML. The Meta-model UML is unique in that it has a standard data representation. This representation is called the meta-model. The meta-model is a description of UML in UML. It describes the objects, attributes, and relationships necessary to represent the concepts of UML within a software

application. This provides CASE manufacturers with a standard and unambiguous way to represent UML models. Hopefully it will allow for easy transport of UML models between tools. It may also models. The Notation The UML notation is rich and full bodied. It is comprised of two major subdivisions. There is a notation for modeling the static elements of a design such as classes, attributes, and relationships. There is also a notation for modeling the dynamic elements of a design such as objects, messages, and nite state machines. In this article we will present some of the aspects of the static modeling notation. Static models are presented in diagrams called: Class Diagrams. Class Diagrams: The purpose of a class diagram is to depict the classes within a model. In an object oriented application, classes have attributes (member variables), operations (member functions) and relationships with other classes. The UML class diagram can depict all these things quite easily. The fundamental element of the class diagram is an icon the represents a class. This icon is shown in Figure 1.

A class icon is simply a rectangle divided into three compartments. The topmost compartment contains the name of the class. The middle compartment contains a list of attributes (member variables), and the bottom compartment contains a list of operations (member functions). In many diagrams, the bottom two compartments are omitted. Even when they are present, they typically do not show every attribute and operations. The goal is to show only those attributes and operations that are useful for the particular diagram. This ability to abbreviate an icon is one of the hallmarks of UML. Each diagram has a particular purpose. That purpose may be to highlight on particular part of the system, or it may be to illuminate the system in general. The class icons in such diagrams are abbreviated as necessary. There is typically never a need to show every attribute and operation of a class on any diagram. Figure 2 shows a typical UML description of a class that represents a circle.

Fig 2:

Notice that each member variable is followed by a colon and by the type of the variable. If the type is redundant, or otherwise unnecessary, it can be omitted. Notice also that the return values follow the member functions in a similar fashion. Again, these can be omitted. Finally, notice that the member function arguments are just types. I could have named them too, and used colons to separate them from their types; or I could have omitted the arguments altogether. Composition Relationships Each instance of type Circle seems to contain an instance of type Point. This is a relationship known as composition. It can be depicted in UML using a class relationship. Figure 3 shows the composition relationship. The black diamond represents composition. It is placed on the Circle class because it is the Circle that is composed of a Point. The arrow head on the other end of the relationship denotes that the relationship is navigable in only one direction. That is, Point does not know about Circle. In UML relationships are presumed to be bidirectional Composition relationships are a strong form of containment or aggregation. Aggregation is a whole/part relationship. In this case, Circle is the whole, and Point is part of Circle. How-ever, composition is more than just aggregation

Fig 3:

. Inheritance The inheritance relationship in UML is depicted by a peculiar triangular arrowhead. This arrow head, that looks rather like a slice of pizza, points to the base class. One or more lines proceed from the base of the arrowhead connecting it to the derived classes. Figure 4 shows the form of the inheritance relationship. In this diagram we see that Circle and Square both derive from Shape.

Fig 4:

Aggregation/ Association: The weak form of aggregation is denoted with an open diamond. This relationship denotes that the aggregate class (the class with the white diamond touching it) is in some way the whole, andt he other class in the relationship is somehow part of that whole. Fig 5

Figure 5 shows an aggregation relationship. In this case, the polygon class contains many Style instances. In UML the ends of a relationship are referred to as its roles. Notice that the role at the Shape end of the aggregation is marked with a *. This indicates that the polygon contains many Style instances. There are other forms of containment that do not have whole / part implications. For example, Each polygon refers back to its parent point.

This is not aggregation since it is not reasonable to depict, we use association relationship for this. Dependency Sometimes the relationship between a two classes is very weak. Figure 6 shows a dashed arrow between the Shape class and the color class. This is the dependency relationship. In Booch94 this was called a using relationship. Fig 6:

Interfaces There are classes that have nothing but pure virtual functions. In Java such entities are not classes at all; they are a special language element called an interface. UML has followed the Java example and has created some special syntactic elements for such entities. Fig 7:

The primary icon for an interface is just like a class except that it has a special denotation called a stereotype.

4. OBJECT STORAGE AND OBJECT INTEROPERABILITY:

A Date Base Management System (DBMS) is a set of programs that enables the creation and maintenance (access, manipulate, protect and manage) of a collection of related data. The purpose of DBMS is to provide reliable, persistent data storage and mechanisms for efficient, convenient data access and retrieval. Persistence refers to the ability of some objects to outlive the programs that created them. Object lifetimes can be short for local objects(called transient objects) or long for objects stored indefinitely in a database (called persistent objects).

Persistent stores Most object-oriented languages do not support serialization or object persistence, which is the process of writing or reading an object to and from a persistence storage medium, such as disk file. Unlike object oriented DBMS systems, the persistent object stores do not support query or interactive user interface facilities. Controlling concurrent access by users, providing ad-hoc query capability and allowing independent control over the physical location of data are not possible with persistent objects.

Object store and persistence Atkinson describe 6 broad categories for the lifetime of a data. Transient results to the evaluation of expressions Variables involved in procedure activation Global variables and variables that are dynamically allocated Data that exist between the execution of a program Data that exist between the versions of a program Data that outlive a program. The first 3 are transient data, data that cease to exist beyond the lifetime of the creating process. The other 3are non transient, or persistent data. The programming languages provide excellent support for transient data. The nontransient data are well supported by DBMS or a file system.

Data Base Management Systems Similarly objects have a lifetime. An object can exist for a period of time (application session). An object can also persist beyond application session boundaries, during which the object is stored in a file or a database.

Essential elements in providing a persistent store are : Identification of persistent objects (object ID) Properties of objects and their interconnection. Scale of the object store. The object store should ideally provide infinite store. The system should be able to recover from unexpected failures and return the system to a recent self-consistent state.