ooad

5/13/2018 OOAD - slidepdf.com

http://slidepdf.com/reader/full/ooad5571ff9249795991699d91e5 1/41

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 customizedsystems, the creation of database system, or the acquisition of third party developed

software.

There have been basically 3 approaches in information system development area: process-

oriented, data-oriented and object-oriented approaches. As information technology (bothhardware and software) has been advancing, people have moved from the earliest process-

oriented approach to data-oriented approach and now begun to adopt the latest object-

oriented analysis methodology.

Unlike its two predecessors that focus either on process or data, the object-orientedapproach 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 tothoroughly 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 elementsmore reusable, thus improving system quality and the productivity of systems analysis anddesign. 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 analystscan 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. Specificobjects 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 amongdiffering 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 toany 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 representthe 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 mayhave 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 mostimportant 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 howare 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 (whatdata 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 softwaredevelopment. 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 likeCompilers, 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) andthat the system does what the user requires (acceptance/beta testing).

Maintenance

Inevitably the system will need maintenance. Software will definitely undergo change onceit 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 bedeveloped 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 objectscombine 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 generallyuses sta te transition diagrams . Process modeling or functional modeling is concerned

with processes that transform data values, and traditionally uses techniques such as dataflow diagrams. n the following sections, I describe the methodologies of Booch, Coad andYourdon, Fusion, Jacobson, LBMS, Rumbaugh, and Shlaer and Mel lor .



3.1 Booch

Booch is the chief scientist at Rational Software, which produces Rational Rose. (Now thatJames 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, withRumbaugh 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 movingaway 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 bookson OOAD (Object-Oriented Analysis and Object-Oriented Design, Prentice-Hall, 1990

and 1991, respectively). Their methodology focuseson analys is of business problems,

and uses a friendlier notat ion 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 dothis.* Structures: There are two types: classification structures and compositionstructures. 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 asRumbaugh, 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, Cus tomer cla sses and Order classes* human interaction component: user-interface classes such as window classes* task management component: system-

management classes such as error classes and security classes* data management

component: database access method classes and the like Although Coad and Yourdon'smethodology 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 requirementwas a simple methodology with an effective notation.The resul t was Fusion, which

Coleman and others developed by borrowing and adapting ideas from

other methodologies . They incorpora ted some major ideas f rom Booch,

Ja co bso n , Ru mb au gh , an d o th er s, an d explicitly rejected many other ideas fromthese 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, andconsider it indirect proof that excessive emphasis on state models comes from

Rumbaugh and Shlaer andMellor's telecommunications and real time system

backgrounds. Fusion 's pragma t ic approa ch seems to hold consi dera ble pot ent ial for cl i ent /se rve r appl ica t io ns, but thi 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 useit you must buy consulting services and a CASE tool, OrySE, from RationalSoftware), 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 asclient/server applications. Jacobson's Object-Oriented Software Engineering (OOSE) is a

simplified version of Objectory, which Jacobson h im se l f has dec lared inadequat e

f or p roduct i on app l i ca t ions .The major distinguishing feature in Jacobson is the usecase. 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 systemduring 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 captureshow 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 casesto 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 theuse 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 usecases.

3.5 LBMS SEOOSystems 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 nonproprietarymethodologies. 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 itas 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 ndthen adap t ing to OO. A very pos i t ive aspect of th i s i s the heavy focuson da ta ma nagemen t and da ta 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 sharedobjects and other objects , and regards the shared objects as important

interfaces between subsystems. This technique allows a distinction, for

example, be t ween cus t omer behav i o r s ha r ed by a l l ap p l ica t i ons and

cus tom er obj ect beh avi or uni que to a s ing le application.

3.6 Rumbaugh OMTIt offers one of the most complete descriptions yet written of an OO analysismethodology. 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 specif ication 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

transit ion diagrams (STDs) for each class, as well as global event-f low

diagrams* the Functional Model (FM): diagrams very similar to data flow diagramsB e c a u s e R u m b a u g h ' 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

and Mellor) is supported by low-end drawing tools such as Visio, I have

used i t not only for OO analysi s, but for a number of d iagrams inrecent p r op os a l s . For examp l e, I r ecen t ly d r ew a d i ag r am of p r o j ec t

deliverables (in a proposal for a large OO development project) using Visio

and Rumbaugh notation to show the object hierarchy of deliverables which, at the firstlevel 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 newoperator, 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 supportencapsulating more general information. Take the case of a information manager which

manages phone number. Phone numbers have a particular rule on which they get generateddepending 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 aframework 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, withoutexplicitly 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. Thisdetermines 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 theclient 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 timeswith 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 changingthe 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 object s 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 classto 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 classto 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 byimplementing 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 duringapplication development. Can be viewed as the implementation of a system of design

patterns.

Benefits of Frameworks

1. Reusability2. 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 theUML, 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 objectorientation.

8 UML diagrams are

You will model the following 5 diagrams only:

1. Use case diagram

2. Activity diagram3. 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 diagram3. Deployment diagram

Behavior Diagrams are:

1. Sequence diagram2. 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 name2. 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 asystem.

Notations:

Usecase: sequence of actionsUser: 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 usecase. 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 pieceof functionality provided by the system. It has 2Ds,vertical dimensions represents time,

Horizontal dimensions represents different objects and Vertical line is called the object’s

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. Itis 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, wecan 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 towithdraw 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 thesystem 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, inthe 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, anexample of which follows:

The Purpose of Use Cases:

Given the simple definition of “Use Case” and “Actor”, together with the simplevisualisation of Use Cases through the UML model, we could be forgiven for thinking. UseCases 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 diagramis complete, with no holes.

They allow for communication between the customer and developers (since the diagram isso simple, anyone can understand it)

Use Cases guide the development teams through the development process – we shall seethat 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 cardtake 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-of-thumb 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 wouldn’t be the end of theworld if the receipt wasn’t dispensed.

Apply the rule to the other Use Cases, and you’ll 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 usecase!

This approach can feel painful at first, as we are used to performing “functionaldecomposition”, 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 theconstruction 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 beingdeveloped (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 ensuringthat the discussion sticks to the point, and that all the stakeholders are encouraged to put

their views across, and that those views arecaptured. Good facilitators are priceless!

A scribe will also be present, who will ensure that everything is documented. The scribemight 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 non-computer 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 system3) 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 effortb) 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 language3) 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 aconnection among things.

An object uses another external possibly shared object for its own functionalityAn object uses and exclusively owns another for its own functionality

An object delegates some of it’s 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 beused for the purpose of making an indication among the properties.



Relationship diagram

3.1 In UML, there are different types of relationships:

GeneralizationAssociation

AggregationComposition

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 impliesthat 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 andunderstand

• 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

–Class’s 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 (Howto 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, soeach 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 manualchanges 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. Ituses 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 softwarecomponents) 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 system’s built in classes andadd as little as possible to what already is there.

3. CLASS DESIGN:

Introduction:

UML stands for Unified Modeling Language. It represents a unification 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 associatedwith, 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 suchas objects, messages, and finite 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) andrelationships 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. Thisicon 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 andoperation 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 thereturn 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 omittedthe 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 Compositionrelationships 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. Thisarrow head, that looks rather like a slice of pizza, points to the base class. One or morelines 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 manyStyle 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 dashedarrow 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 thecreation and maintenance (access, manipulate, protect and manage) of a collection

of related data.

• The purpose of DBMS is to provide reliable, persistent data storage andmechanisms 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 supportquery 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 possiblewith 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 non-transient 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.



.

ooad

Documents