Object Oriented Analysis and Design

UNIT - I

IntroductionA class defines the abstract characteristics of a thing (object), including the thing's characteristics (its attributes or properties) and the things it can do (its behaviors or methods or features). For example, the class Dog would consist of traits shared by all dogs, for example breed, fur color, and the ability to bark. Classes provide modularity and structure in an object-oriented computer program. A class should typically be recognizable to a non-programmer familiar with the problem domain, meaning that the characteristics of the class should make sense in context. Also, the code for a class should be relatively self-contained. Collectively, the properties and methods defined by a class are called members.

Object  A particular instance of a class. The class of Dog defines all possible dogs by listing the characteristics that they can have; the object Lassie is one particular dog, with particular versions of the characteristics. A Dog has fur; Lassie has brown-and-white fur. In programmer jargon, the object Lassie is an instance of the Dog class. The set of values of the attributes of a particular object is called its state.

Method  An object's abilities. Lassie, being a Dog, has the ability to bark. So bark() is one of Lassie's methods. She may have other methods as well, for example sit() or eat(). Within the program, using a method should only affect one particular object; all Dogs can bark, but you need one particular dog to do the barking.

Message passing  "The process by which an object sends data to another object or asks the other object to invoke a method."[3]

Inheritance  In some cases, a class will have "subclasses," more specialized versions of a class. For example, the class Dog might have sub-classes called Collie, Chihuahua, and GoldenRetriever. In this case, Lassie would be an instance of the Collie subclass. Subclasses inherit attributes and behaviors from their parent classes, and can introduce their own. Suppose the Dog class defines a method called bark() and a property called furColor. Each of its sub-classes (Collie, Chihuahua, and GoldenRetriever)

will inherit these members, meaning that the programmer only needs to write the code for them once. Each subclass can alter its inherited traits. So, for example, the Collie class might specify that the default furColor for a collie is brown-and-white. The Chihuahua subclass might specify that the bark() method is high-pitched by default. Subclasses can also add new members. The Chihuahua subclass could add a method called tremble(). So an individual chihuahua instance would use a high-pitched bark() from the Chihuahua subclass, which in turn inherited the usual bark() from Dog. The chihuahua object would also have the tremble() method, but Lassie would not, because she is a Collie, not a Chihuahua. In fact, inheritance is an "is-a" relationship: Lassie is a Collie. A Collie is a Dog. Thus, Lassie inherits the members of both Collies and Dogs. When an object or class inherits its traits from more than one ancestor class, and neither of these ancestors is an ancestor of the other, then it's called multiple inheritance. For example, independent classes could define Dogs and Cats, and a Chimera object could be created from these two which inherits all the (multiple) behaviour of cats and dogs. This is not always supported, as it can be hard both to implement and to use well.

Encapsulation  Conceals the exact details of how a particular class works from objects that use its code or send messages to it. So, for example, the Dog class has a bark() method. The code for the bark() method defines exactly how a bark happens (e.g., by inhale() and then exhale(), at a particular pitch and volume). Timmy, Lassie's friend, however, does not need to know exactly how she barks. Encapsulation is achieved by specifying which classes may use the members of an object. The result is that each object exposes to any class a certain interface — those members accessible to that class. The reason for encapsulation is to prevent clients of an interface from depending on those parts of the implementation that are likely to change in future, thereby allowing those changes to be made more easily, that is, without changes to clients. For example, an interface can ensure that puppies can only be added to an object of the class Dog by code in that class. Members are often specified as public, protected and private, determining whether they are available to all classes, sub-classes or only the defining class. Some languages go further: Java uses the package keyword to restrict access also to classes in the same package, C# and VB.NET reserve some members to classes in the same assembly using keywords internal (C#) or Friend (VB.NET), and Eiffel and C++ allows one to specify which classes may access any member.

Abstraction 

Simplifying complex reality by modeling classes appropriate to the problem, and working at the most appropriate level of inheritance for a given aspect of the problem. For example, Lassie the Dog may be treated as a Dog much of the time, a Collie when necessary to access Collie-specific attributes or behaviors, and as an Animal (perhaps the parent class of Dog) when counting Timmy's pets.

Polymorphism  Polymorphism is behavior that varies depending on the class in which the behavior is invoked, that is, two or more classes can react differently to the same message. For example, if a Dog is commanded to speak() this may elicit a Bark; if a Pig is commanded to speak() this may elicit an Oink.

Object BasicsObjectsObject Behavior and MethodsClass HierarchyPolymorphismObject Relationships and AssociationsAdvanced Topics

Object Oriented System Development Life Cycle

Object Oriented MethodologiesRumbaugh et al’s Object Modeling Technique

Booch Methodology

Jacobson et al. Methodologies

PatternsFrameworksUnified Approach

UMLModeling

Object Oriented Analysis and Design Using UML Mark Collins-Cope

PDF version

1. Introduction

You’re proficient in C++, Java or another OO language, you’re designing class hierarchies, using inheritance, and manipulating complex pointer relationships to store the necessary links between your classes. You’ve probably drawn blobs (representing classes in some way) on whiteboards, with connecting lines to indicate the relationships between classes (inheritance or other). Perhaps you’re feeling the need for a more formal notation to express your designs - using something that is language independent, and that enables you to consider the important aspects of design leaving the detail for later.

Alternatively, perhaps you’re a Project Manager, looking to formalise the OO design process a little to make sure you’re getting the most from your move to C++/Java or a similar language.

In this paper, I take a look at the UML (Unified Modelling Language) notation for Object Oriented Analysis and Design - the emerging standard designed by Booch, Rumbaugh and Jacobson, each of whom previously had their own notations published independently.

The starting point is Object Modelling, a technique that enables you to focus on class structure, inheritance, etc., whilst avoiding language specifics such as pointer dereferencing.

2. Object Modelling In UML

Figure 1 - Subset of UML Object Modelling Notation - A Summary

Object Modelling is the central technique in UML. It is a language independent notation allowing the specification of classes, their data or attributes(private) and methods (public), inheritance, and other more general relationships between classes. The notation itself is fairly simple to grasp (see figure 1), however this hides the somewhat more subtle thought processes underlying a good model.

The best way to understand the notation is to look at an example. The following Object Model shows a simple Banking System, containing classes for Head-Office, Branch, Accounts held at that Branch, and the Customers who the Accounts belong to:

Figure 2 - A Simple Banking System Object Model

Examining this Object Model in more detail, we can see the following information about our class structure:

A Head-Office class (containing “bankName” and “address” fields, otherwise known as attributes) “administers” an (unspecified) number of Branch classes; whilst a Branch is “administered-by” exactly one Head-Office (the little black arrows indicates the direction in which the name given to a relationship should be read).On the diagram this relationship is represented by the line from the Head-Office class to the Brach class which is labelled “administers”. The “1” at the Head-Office end of the line shows that exactly one Head-Office is associated with each Branch (as you would expect). The “*” at the Branch end of the line shows that a Head-Office “administers” many Branches - again as you would expect.

Similarly, a Branch class (which contains “manager” and “address” attributes) “holds” many Account classes; whilst each Account class “is-held-by” exactly one Branch. We can also see that we have determined that an Account class has a “CalcCharges” method (also known as operations or member functions) defined. This method, when invoked, will look at the detail stored within the Account object, and apply the appropriate (undoubtedly extortionate) charges to the Account. The second method -“PrintStatement” - will take the details of the Account and print them out.The inheritance “triangle” (labelled “account-type”) shows us that our system knows about three types of Account: the basic account (in this case a

virtual class called Account), and two specialised accounts - the CurrentAccount and SavingsAccount - which are derived from Account. The fact that the “CalcCharges” is shown in both sub-classes indicates that its implementation is re-defined for these classes (in C++ terms it is a virtual function). This is indicative of the fact that charges on a “SavingsAccount” are calculated in a completely different manner to charges on a “CurrentAccount”.Implicit in the decision to use inheritance and redefine methods in sub-classes is the fact that the system, when implemented, will use the polymorphism features of the target language (C++, Java ...) to enable all Accounts to be treated in a single coherent fashion, regardless of the particular charges mechanism involved. This is of course one of the reasons we use an object-oriented development language in the first place.

Each Account “belongs-to” exactly one owner - the Customer class on the diagram. Customers, on the other hand, may have many Accounts.It’s worth noting here that because an Account may “belong-to” a Customer, both CurrentAccounts and SavingsAccounts may also belong to a Customer. In other words, the “belongs-to” relationship between Accounts and Customers is inherited by the CurrentAccount and SavingsAccount classes. This fact simplifies the diagram considerably, removing the need for these relationships to be noted explicitly. This simplification will also be apparent in our final implementation of the system.

Finally, you can see that there are two relationships shown between the Account and the Transaction classes. This is because, in our banking system, each individual transaction (credit, debit, etc.) must have two associated accounts - the Account the money is “debit(ed)-from”, and the Account the money is “credit(ed)-to”. This enables the bank to record exactly where each transaction has come from, and gone to, so to speak.

These last point brings out an interesting feature of what is being shown on an Object Model: clearly it wouldn’t make sense for each Transaction to be “debit(ed)-from” and “credit(ed)-to” the same Account - no money would be transferred! Obviously, although the lines (relationships) are shown to the same Account class, they do not (necessarily) represent links to the same Account object at run-time.

A relationship shown on an Object Model indicates that some kind of run-time link will exist between two instances of the classes shown on the Object Model. Thus the Branch to Accounts relationship should be read as follows:

An instance of the class Branch will be linked to (zero to) many instances of the class Account, whilst an instance of the class Account will be linked to (one and only) one instance of the class Branch.

This can be shown more clearly by the following instance diagram (instance diagrams are used to assist in understanding and clarifying Object Models - they also give quite a hint as to how relationships can be implemented in C++!):

Figure 3 - Instance Diagram Showing Branch and Account objects

By now, you may be beginning to see how Object Models can assist the analysis/design process. They assist in the clarification of the relationships that should be (somehow) represented in a software system. The important point to note hear is that we are first working out what relationships we need to represent in our system (“belongs-to”, etc.), without worrying too much about exactly how they should be stored. Put another way, Object Modelling allows us to focus on exactly what problem we are trying to solve, before we look at the best way of implementing our model in a particular programming language.

3. Implementing Object Models

OK, that’s fine, you may say, but how do Object Models relate to C++ or Java, exactly? Lets take a look at a sub-set of our previous example:

Figure 4 - Subset of Banking Model

Our Object Model shows us that we need four classes: Transaction; Account; Current Account and Savings Account, and that our implementation must enable us to represent the fact that any particular Account has two sets of Transactions associated with it - which will be needed to implement the PrintStatement method. The Account, CurrentAccount and SavingsAccount classes are easily mapped to the C++ (or Java) inheritance mechanisms:

class Account { /* ... data ... */

public:virtual void CalcCharges();void PrintStatement();

};

class SavingsAccount : public Account {/* any additional data */

public:virtual void CalcCharges(); /* re-definition *//* use the base class PrintStatement method */

};

class SavingsAccount : public Account {/* any additional data */

public:virtual void CalcCharges(); /* another re-

definition *//* use the base class PrintStatement method */

};

Figure 5 - Mapping Object Model Inheritance To C++ Inheritance

The Transaction class may be implemented as follows:

class Transaction {long value; /* stored in pence */date_t date; /* date of transaction */

public:/* Access and Update functions */Date(date_t); /* set */date_t Date(); /* get*/Value(long); /* set */long Value(); /* get */

};

Figure 6 - Transaction Class In C++

This leaves us with the “debit-from” and “credit-to” relationships to be implemented. Here we have a number of choices: linked-lists; collection-classes; (dynamically bounded) arrays of pointers; etc. could all be used to represent these relationships.

class TransactionList {TransactionList * next; /* ptr to next element */Transaction * data; /* store the transaction here

*/public:

void Data (Transaction *); /* set */Transaction * Data(); /* get */void NextItem(TransactionList *); /* set next ptr

*/TransactionList * NextItem(); /* get next ptr */

};

Figure 7 - Simple Transaction List Handler Class

For brevity, a linked-list class with a somewhat limited interface is used in this example - although this may not the best choice.

Amending our Account class definition to use this class gives us the following new definition:

class Account {TransactionList * debitedFrom; /* debited from Tx

list*/

TransactionList * creditedTo; /* credited to Tx list */public:

virtual void CalcCharges();void PrintStatement();/* some new methods to manipulate the Transaction

list */DebitTx(Transaction *); /* Add a debit Tx */CreditTx(Transaction *); /* Add a credit Tx */Transaction* NextDebitTx(); /* Iterator:get debit

Tx */Transaction* NextCreditTx(); /* Iterator:get cred

Tx */};

/* sample method implementation */Account::DebitTx(Transaction * theTx) {

/* add a new list contained at the beginning of the list */

TransactionList * tmpTxLp = debitedFrom;debitedFrom = new TransactionList;debitedFrom->NextItem(tmpTxLp);

/* new put the transaction data into the list */debitedFrom->Data(theTx);

};

Figure 8 - Account Class amended to use Transaction List

Although this is a somewhat simplistic implementation - it demonstrates the point that the model shown in figure 4 is easily translated into C++. Of course, better implementations of the “debit-from” relationship are possible, but the fact that the Account class interface completely hides the underlying implementation of this relationship means that we can improve on our first cut implementation at a later date with little impact on our overall system code. In other words, use of the Account class interface has limited the impact of the relationship implementation method: something we strive to achieve when writing OO based applications.

A couple of other points are worthy of note at this stage:

The linked list class contains pointers (references in Java) to Transaction objects. This is implicit in our Object Model, and is what the system’s users would expect to see. To see why, consider the case when a new Transaction

value is entered in error. The Transaction is linked to two accounts (“debit-from” and “credit-to”). If the Transaction object is shared, only one object need be modified to rectify the situation. Using two objects would either mean that either the system has to update two objects (equals more coding work), or that the user has to update two Transactions (equals greater potential for mistakes).

Although our Object Model “debit-from” relationship uses a linked list, there are many alternatives to this choice - including the use of a relational database to underpin the system. The point is, however, no matter what mechanism is used, we are actually trying to implement a “many-to-one” relationship between an Account and a Transaction. It is this relationship that exists in the banking problem domain - not a relationship involving linked lists or collection classes. Object Modelling enables us to spot the relationship required by the problem domain, and then choose the best way of implementing it.

So far, we have only implemented the “debit-from” relationship in one direction- from the Account class to the Transaction class. Our model does not (yet) specify in which direction the relationship will be traversed. If we need to traverse the relationship in <em>both</em> directions - getting from the Transaction to the related Account - our implementation will prove insufficient, and some form of double pointer schema may be needed. Much work would have been saved if we had known this fact before we had started writing the code.

Although our Object Model provided a starting point for our implementation, it was not complete, for example new methods have been added to the Account class.

Other factors may also influence our choice of implementation: do we need a direct form of access - for example using a Transaction number to go directly from the Account to the relevant Transaction? If we do, then a linked-list will prove an inefficient choice of implementation. Again, it would be very useful to know this type of information before we start trying to implement the relationship.

From these points we can see that we need to consider the wider requirements of our system before we can come up with the right implementation of our “debit-from” relationship (not to mention the many other classes and relationships that might be required). We can’t produce a good design for a system unless we consider all the required functionality - in detail. Use Cases provide the mechanism for doing this.

4. Use Cases In UML

Use Cases are used to document system requirements. They provide a useful technique which, in conjunction with Object Modelling, help us to clarify exactly what the system is supposed to do. Let’s take a look at the requirements for our banking system:

Figure 9 - Use Cases for Banking System

This Use Case diagram shows us the following:

The required business functions - that is, the type of operation you’d expect to find on the menu of the application once it had been developed. In this case we have identified the following functions:

o Bank managers need to periodically print out a report detailing all the customers who are overdrawn; these appear on the branch printer

o Customers may use the system for balance enquiries o Data processing staff use the system to do basic data entry

(transactions on accounts) o Clerks may periodically request statements on behalf of Customers;

There are four distinct types of user of the system: Bank Managers; Clerks; Data Processing Assistants; and Customers. Each type of user typically has

their own particular set of requirements for a system: hence identify user types assists in identifying all the required system functions.

The Use Case diagramming technique allows us to make a first cut at defining the system requirements, and will help us in presenting these requirements back to the users of the system. It also partitions the system into single atomic business functions, which may be used as a basis for costing the system, or for planning a phased system delivery. In this case each successive phase would deliver further batches of Use Cases.

Further information is still required, however, to tie down the detail of what each businese function does. Use Case Detail provides this information (explanatory notes are shown in bold):

Use Case Detail: Overdrawn Report

Used By:• Bank Manager

Inputs:Details what information flows from the user to the system for this particular Use Case.• theBranchSortCode - The Sort Code of the branch for which the report is required.• theOverdraftPeriod - how long an Account has been overdrawn before it is forms part of the report.

Outputs:Details what information flows from the system to the external environment, in this case the printer!• overdraftReport (to branchPrinter) - structured as follows: customer name; current overdraft; period overdrawn (days);• Printed for all accounts that have been overdrawn for a period greater than theOverdraftPeriod, and which have not already been reported (on another report) in the last 30 days.

Pre-Conditions:What validity checks or constraints apply on the inputs (or the internal system as a whole, in some cases).• theBranchSortCode - must be a branch sort code held within the system.• theOverdraftPeriod - must be a number between 0 and

100 days.

Post-Condition:What changes does the Use Case make to the internal system state.• Updates the reportedOnDate field of overdrawn accounts.

As work progresses on the Use Cases, the requirements of the system become clearer enabling the Object Model to be updated in parallel, helping us make sure our model (and the subsequent implementation in the chosen language) contains all the necessary classes and class inter-links.

Whilst we’re nearer to resolving some of the issues identified at the end of the discussion of implementing Object Models, a number are still outstanding: we still can’t be sure in what direction the relationships must be implemented, whether we have identified all the methods; or what implementation of the links will best suit the use to which they’ll be put. To sort out the remaining issues we’ll need to look in more detail exactly how each Use Case will be implemented, using Sequence Diagrams.

5. Sequence Diagrams

Sequence diagrams, performed on a per Use Case basis, examine the flow of method call calls within a system.

NOTE: Enlarge the diagram below by clicking on the picture.

Figure 10 - Sequence Diagram for Overdrawn Report

Performing a complete analysis requires that each individual Use Case must be examined, although in practise only selected Use Cases may be examined. The Sequence Diagram in figure 10 shows the Overdrawn Report Use Case defined earlier.

The Overdrawn Report Use Case is thus implemented as follows:

The Head-Office object (there is only one of them) has methods which correspond to each Use Case - in this case an OverdrawnReport method (this is a convenience for brevity, normally there would be a single “InitialObject” which the system would know about, and which would provide the entry point into the run-time model for all code).

The Head-Office OverdrawnReport method locates the relevant Branch (as determined by the Use Case input: theBranchUseCase) and cascades the request to the Branch by calling its OverdrawnReport method.

The Branch object in turn passes the request on down to each Account it holds (using the Account’s OverdrawnReport method)!

Each Account then: o checks if it has been overdrawn for greater than the period specified

by theOverdraftPeriod, which is passed as an argument to the Account.OverdrawnReport method (the detail of this is not shown - but involves summing up all the Transactions it holds, and checking the date on which it last became overdrawn).

o if appropriate it then calls one of its own methods to print the report (detail not shown), and resets its lastReportDate attribute, again using its own method.

The method calls unwind until the Use Case is complete.

Figure 11 - Updated Banking System Object Model

Reviewing the Object Model (see figure 11), we can see a number of additions as a result of completing this Sequence Diagram:

OverdrawnReport methods have been added to the Branch and Account classes.

A lastReportedDate attribute and associated methods have been added to the Account class, along with a printOverdrawnReport method.

The “administers” relationship between Head-Office and Branch has been qualified to indicate that “direct access” via the Branch’s “sort-code” is required across the link (thus assisting in link design) - note the consequent change in the multiplicity of the relationship from many-to-one to one-to-one.

We have added directionality to many of the links (e.g. see the arrow-head on the Branch to Account link).

Of course, we’ve only looked at one Use Case, so its likely the model will change further as more sequence diagrams are developed.

6. The Overall Process

From the above discussion we can see that Use Cases and Sequence Diagrams both add to integrity and completeness of our Object Model, and that a good Object Model provides a firm foundation for a good design, and hence a good implementation of the system.

Figure 12 - The Overall Process

This approach separates the Problem and Technical Domain aspects of the project:

Problem Domain Analysis is concerned with capturing requirements and producing a first cut Object Model. Typically the Object Model will be incomplete, having only a subset of the class attributes and methods defined.

Problem Domain Design is concerned with finalising the detail of the problem domain parts of the Object Model, and results in an Object Model with a complete set of Problem Domain specific classes, attributes and methods.

User Interface Design is the first step that focuses on the Technical Domain aspects of the problem, and involves taking the Use Cases as defined earlier, and designing a Graphical User Interface appropriate to the Technical Architecture chosen for the project (MS Windows, X/Motif, etc.). Typically you would expect to find one controlling dialog box (which may use other subsidiary dialogs) for each Use Case in the system. Some prototyping may be appropriate at this point in the project. For small projects, prototyping and UI design may be undertaken in parallel with Use Case development.

Technical Domain, High Level Design focuses on adding classes to meet the technical needs of the project, and is driven by the technical architecture of the project. Classes may be GUI related, DBMS (object or relational) related, distribution related (CORBA, DCOM, etc.), external systems related, or may provide an interface to internal system components such as printers. Previous Sequence Diagrams may be updated to confirm the validity of the technical design - in particular you would expect to see GUI classes appearing between the System Boundary and the Problem Domain classes.

Finally, Detailed Technical Design, looks at link implementations, detailed data typing of attributes, full specification of all methods (including parameters), etc. The end result is a complete design of the full system.

The separation between Problem Domain and the Technical Domain aspects of the system is useful in large projects, allowing the focus of those working on the project to be clearly divided, as summarised in figure 13:

Figure 13 - Seperation Of Problem and Technical Domain Components of a System

For smaller projects (one or two persons for a couple of months) the two domains may be merged, if desired.

As mentioned previously, Use Cases may be used in phasing a project; the process shown earlier does not prohibit this. A project with 50 Use Cases could be structured in three phases as shown in figure 14:

NOTE: Enlarge the diagram below by clicking on the picture.

Figure 14 - Evolutionary Phasing Of OO Project

The object-based structure of the application lends itself well to this approach.

7. Summary

This paper has taken a look at the Use Case, Object Modelling, and Sequence Diagramming notations of UML, how Object Modelling maps to OO programming languages, and shown how these notations hang together to complement each other. A number of other UML notations are not covered in this article, however further information can be found on http://www.ratio.co.uk.

I’m sure you can see that OOA/D offers a number of potential benefits in an OO based development environment. These include:

better modelling of the problem domain (equals happier users) better overall software design with a strong focus on class structure more flexible and maintainable systems through better class partitioning good documentation (the notations) - and a single central overall design

notation (the Object Model) a flexible approach to project phasing assistance in tie-ing down requirements, and less work (in the long run)

Uml DiagramsUML class diagramsUse case diagramsUML Dynamic Modeling

Dynamic modelling - state diagrams

Computer systems are built from objects which respond to events. External events arrive at the boundary of the system, say when a mouse button is clicked. Some object picks up the event, responds to it, and perhaps generates some internal event by calling an operation on another object.

In this lesson we examine a way of describing how an individual object responds to events, either internal events triggered by other objects or external events triggered by the outside world.

State diagrams allow you to further explore the operations and attributes that need to be defined for an object. They consist of sets of states which an object is in, and events which take the object from one state to another. Let us go back to our juggling example. A juggling ball starts on the floor, and alternates between being

held and being in the air, until it is dropped and lands on the floor. This can be drawn like this:

Initial states are represented by a black blob. Intermediate states are represented by round-cornered boxes. Final states are represented by bulls-eyes. Events are represented by arrows with labels giving a name. An event usually corresponds to an operation in the object model.

Basically any system which you can reasonably model on a computer jumps from state to state. Even those apparently continuous games are made up of objects which change their state very quickly.

The level of state decomposition must be decided on judgement. Too fine a grained model is inappropriate; say modelling all the possible ages of an employee as individual states. Too gross a decomposition is useless; say modelling an employee as employed or not.

Let us look at the state diagram for Red Riding Hood. One might be:

Where events come from and go to indicate something about the behaviour of the object. The above diagram implies that Red Riding Hood cannot proceed to living happily ever after while she is in the woods. Of course, if she had fallen madly in love with the woodcutter and did not care for the well-being of her grandmother, then the arrow to lives happily ever after might well have originated at a different place.

Of course, not all objects have behaviour worth modelling. Consider our example from the field of object oriented nursery rhymes, the sad story of Humpty Dumpty. Clearly one would not want to model such trivial examples.

A more complicated example from the world of object-oriented aviation is:

Careful consideration of a state can often uncover more complicated behaviour. Consequently we have a notation to describe substates. The aggregation notation can be used to illustrate this.

What do we learn from this modelling? Firstly, the states need to be recorded in the attributes of an object. For example, we may need an attribute ("is flying", say) which is true or false to indicate whether an aeroplane is flying or not. Also, we recognise the need for operations to cause the state transitions. For example, we may need a "take off" operation to enable the object to move from "at airport" to "flying". The transition diagram also indicates some of the things the operation must do, such as change the attributes which determine the state.

Basically you need to construct a state transition diagram for every object with significant behaviour. You need not construct one for anything with trivial behaviour. The reason for doing this is to identify further operations and attributes, to check the logical consistency of the object, and to more clearly specify its behaviour.

All the best notations can be used to describe the process they facilitate. Now we have the basic ideas of object models and dynamic models, our approach to analysis and design (so far) can be summarised as:

We shall shortly be adding functional modelling to our portfolio of tools, which is another way of discovering attributes, operations and relations for our object model.

UML Extensibility

Object Oriented Analysis process: Identifying use casesUse case ModelDeveloping Effective Communication

Object AnalysisClassification TheoryApproaches for Identifying classessNoun phrase ApproachCommon class Patterns ApproachUse case driven approachClasses, Responsibilities and collaborators

Identifying object Relationships, attributes and MethodsAssociationsSuper-Sub class RelationshipsA-part-of Relationships- AggregationClass ResponsibilityObject Responsibility methods and messages

UNIT III OBJECT ORIENTED DESIGN PROCESS AND DESIGN AXIOMS

Introduction

- The objects discovered during analysis can serve as the framework for

design

- The class’s attributes, methods and associations identified during analysis

must be designed for implementation.

OOD PROCESS

- OOA must be revisited and new classes or attributes and methods must be

added for implementation purposes and UI.

OOD Process consists of the following activities:

Apply design axioms to design classes, their attributes, methods,

associations, structures and protocols.

Design the access layer

Design the view layer classes

Iterate and refine the whole design.

Reapply the design axioms and if needed repeat the preceding steps.

(Incremental approaches such as UA can be used for Software Development

incrementally).

OOD AXIOMS :

- An “Axiom” is a fundamental truth that always is observed to be valid and

for which there is no counter example or exception. [Hypothesized form a

large no. of observations]

- A “Theorem” is a proposition that may not be self-evident but can be

proven from accepted axioms (= law or principle)

- A “Corollary” is a proposition that follows from an axiom or another

proposition that has been proven.

- Two different axioms that can be used in OOD (based on Suh’s design

axioms)

* Axiom 1: The independence axiom: Maintain the independence of

components.

* Axiom 2: The information axiom: Minimize the information content of

the design. It deals with relationships between system components (classes,

requirements, …). It deals with the complexity of the design.

COROLLARIES :

- From the two design axioms, many corollaries may be derived as a direct

consequence of the axioms.

- Useful in making specific design decisions, since they can be applied to

actual situations (called as “design rules”).

- Types of corollaries

* Uncouples design with less information content: to maximize object

cohesiveness among objects and software components in order to improve

coupling because only a minimal amount of essential information need be passed

between components.

* Single purpose: each class must have a purpose; should be defined

clearly and necessary in the context of achieving goal.

* Large number of simpler classes, reusability: keeping the classes

simple allows reusability.

* Strong mapping: there must be a strong association between the

physical system (analysis’s object) and logical design (design’s object)

* Standardisation: promote standardisation by designing

interchangeable components.

* Design with inheritance: common behavior (methods) must be moved

to super classes. The super class – subclass structure must make logical sense.

DESIGNING CLASSES

- Specifications of the classes designed and the interaction between a class

with other classes.

Process Steps: consists of the following activities:

apply design axioms to design classes, their attributes, methods,

associations, structures and protocols

refine and complete the static UML class diagram by adding details to that

diagram.

refine attributes.

Design methods and the protocols

Refine the associations between classes

Refine the class hierarchy and design with inheritance.

iterate and define.

CLASS VISIBILITY: Designing well-defined Public, Private and

Protected protocols

- two problems in designing methods or attributes for classes:

Protocol: interface to the class operations and its visibility.

Implementation of the same.

Protocols can be classified into three:

Private protocol: the class’s protocol or the messages that a class

understands (on the other hand) can be hidden from other objects.

Public protocol: the above (messages) can be made available to other objects

Protected protocol: subclasses can be used the method in addition to the

class itself.

- to summarize the above protocols:

public protocols define the functionality and external messages of an object

private protocols define the implementation of an object.

- private and protected protocol layers internal will define the implementation

of the object (what attributes, instance variables, methods, etc.,)

- public protocol layer – external will define th4e functionality of the object.

DESIGNING CLASSES: Refining Attributes

- the name of the attribute was sufficient in the analysis phase.

- The detailed information must be added to the model in the design phase.

- Goal of this activity: refine existing attributes or add attributes that can

evaluate the system into implementation.

Attribute types: there are three basic types.

single – value attribute: has only on value or state (Eg: name, address,

salary,etc.,)

multiplicity or multivalue attribute: can have a collection of many values at

any point in time. (Eg: employees working in a department of an

organization)

instance connection: (Reference to another object) required to provide the

mapping needed by an object to fulfil its responsibilities (Eg: one person

accessing more than one web sites at an instance)

UML Attribute Presentation: attribute presentation suggested by UML:

visibility name: type-expression = initial-value

where …

visibility is one of the following:

+ public (accessibility to all classes)

# protected (accessibility to subclass and operations of class)

- private (accessibility only to operations of the class)

type-expression : language dependent specifications of the implementation type

of an attribute

initial-value : is a language-independent expression for the initial value of a

newly created object

(Ex: +size: length = 100)

- multiplicity may be indicated by placing a multiplicity indicator [array] in

brackets after attribute name.

(Ex: names[10]:string)

DESIGNING METHODS AND PROTOCOLS

- used to specify the algorithm for methods identified so for (in OOA).

- A class can provide several types of methods:

constructor: creates instances of the class

destructor: destroys instances

Conversion method: converts a value from one unit of measure to another.

Copy method: copies the contents of one instance to another instance

Attribute set: sets the values of one or more attributes.

Attribute get: returns the values of one or more attributes.

I/O methods: provide or receive data to or from a device.

Domain specific: specific to the application.

- designing methods and protocols must minimize the complexity of message

connections and keep as low as possible the number of messages sent and

received by an object.

- Goal should be to maximize cohesiveness among objects and software

components to improve coupling.

Design issues

(i) avoiding design pitfalls:

- use large number of simple classes than a few large, complex classes.

- Apply the design axioms and corollaries then critique about the proposal.

- Maximize reuse of avoiding creating new classes as much as possible.

(ii) UML operation presentation

- the operation syntax in UML is:

visibility name : Parameter-list : return-type-expression

where…

visibility is one of the following:

+ public visibility (accessed by all classes)

# protected visibility (accessed subclass and operations of class)

- private visibility (accessed only to operations of class)

name is the name of the operation

parameter-list is a list of parameters, separated by commas, each specified

by

name : type-expression = default-name

where …

name : name of the parameter

type-expression : language-dependent specification of an implementation

type

default-value : optional value

return-type-expression : a language independent specification of the

implementation of the value returned by method.

Ex: +getaccountnumber(account:type):accountnumber

OBJECT STORAGE AND OBJECT INTEROPERABILITY

- object storage refers tot he storage, access and retrieval of object (data)

- persistence determines the life time of data

- object life times can be:

short – as for local objects

long – as for objects stored indefinitely in database.

- life time of data is categorized into:

transient results to the evaluation of expression

variables involved in procedure activation

global variables and variables that are dynamically allocated

data that exist between the execution of program

data that exist between versions of the program]

data that outlive a program

- the first three in the above are called as “transient data” – data that cease to

exist beyond the life time of the creating process

- the rest of the above are called “Non – transient” or “Persistent Data”.

- the programming languages provide excellent, integrated

support for the first three categories of transient data. The other

three categories can be supported by a DBMS or a file system

DATA BASE MANAGEMENT SYSTEMS [DBMS]

- A DBMS is a set of programs that enable the creation and maintenance

of a collection of related data. A fundamental characteristic of the data base

approach is that the DBMS contains not only the data but a complete

definition of the data formats it manages. This description is known as the

Schema or meta-data.

Database views

The DBMS provides the database users with a conceptual representation

that is independent of the low-level details (Physical view) of how the data

are stored.

Database models

A database model is a collection of logical constructs used to represent

the data structure and data relationships within the database.

Hierarchical model: the hierarchical model represents data as a single-rooted

tree. Each node in the tree represents a data object and the connections represent a

parent-child relationship.

Network model: Unlike the hierarchical model, a network model’s record can

have more than one parent.

Relational model: The primary concept in this database model is the relation,

which can be thought of as a table. The columns of each table are attributes that

define the data or value domain for entries in that column. The rows of each table

are tuples representing individual data objects being stored.

[Definitions like Primary key, foreign key, secondary key … to be included here]

Database Interface

The interface on a database must include a Data Definition Language

(DDL), a query (SQL) and Data Manipulation Language (DML). One is to

embed a database language, such as Structured Query Language (SQL), in

the host programming language.

Database Schema and DDL

To represent information in a database, a mechanism must exist to describe

or specify to the database the entities of interest.

A data definition language is the language used to describe the structure of

and relationships between objects stored in a database.

This structure of information is termed the database schema.

DML and query capabilities

A query usually is expressed through a query language.

A data manipulation language is the language that allows users to access

and manipulate data organization.

The structured query language is the standard DML for RDBMSs. The

query usually specifies:

The domain of the discourse over which to ask the query.

The elements of general interest

The conditions or constraints that apply

The ordering, sorting, or grouping of elements

The constraints that apply to the ordering or grouping

LOGICAL AND PHYSICAL ORGANIZATION OF DATABASE

Logical database organization: refers to the conceptual view of database

structure and the relationships within the database.

Physical database organization: refers to how the logical components of the

database are represented in a physical form (by O. S constructs like files)

Shareability and transactions:

- Data and objects in the database often need to be accessed and shared by

different applications.

- The database must detect and mediate the conflicts and promote the greatest

amount of sharing possible without sacrificing the integrity of data, when

multiple applications having access to the object concurrently.

- A transaction is a unit of change in which many individual modifications are

aggregated into a single modification that occurs in its whole or not at all.

- A transaction is said to commit if all changes can be made successfully to the

database.

- A transaction is said to abort if canceled because all changes to the database

cannot be made successfully.

- This ability to transactions ensures atomicity of change that maintains the

database in a consistent state.

Concurrency polity: The concurrency control mechanism is established to

mediate the conflicts (read / write the same object simultaneously) by

making policies that dictate how they will be handled.

DISTRIBUTED DATA BASE AND CLIENT – SERVER COMPUTING

- Distributed database implies that portions of the database reside on

different nodes and disk drives in the network.

- Each portion of the database is managed by a server, a process responsible

for controlling access and retrieval of data from the database portion.

- Client / Server Computing: Client is a process (program) that sends a

message to a server process (program) requesting that the server perform a

task (service).

- Connectivity allows applications to communicate transparently with other

programs or processes, regardless of their locations.

- The key element of connectivity is the Network Operating System (NOS),

also known as Middleware.

- A typical C / S application consists of the following components:

User Interface: Interacts with users, screens, windows, keyboard & mouse.

Business processing: uses the user interface data to perform business tasks.

Database processing: manipulates data within the application using DML.

DISTRIBUTED OBJECT COMPUTING (DOC)

- distributed object computing has the following characteristics:

it utilizes reusable software components that can roam anywhere on

networks

run on different platforms

communicate with legacy applications by means of object wrappers

there are several DOC standards like

CORBA (by Object Management Group)

- Common Object Request Broker Architecture – a standard proposed as a

means to integrate distributed heterogeneous business applications and data.

- The CORBA Interface Definition Language (IDL) allows developers to

specify language-neutral, object-oriented interfaces for application and

system components.

- CORBA Object request brokers (ORBs) implement a communication

channel through which applications can access object interfaces and request

data and services.

- The CORBA Common object environment (COE) provides system-level

services such as life cycle management for objects accessed through

CORBA.

ActiveX / DCOM (by Microsoft)

- Component Object Model (COM) and Distributed Component Object Model

(DCOM) are Microsoft’s alternatives to OMG’s distributed object

architecture CORBA.

- DCOM is an internet and component strategy where ActiveX (formerly

known as OLE) plays the role of DCOM object

- DCOM also is backed by a very efficient web browser, MS – Internet

Explorer.

OBJECT ORIENTED DATA BASE MANAGEMENT SYSTEM (OODBMS)

- The Object-Oriented Database Management System is a marriage of object –

oriented programming and database technology.

- The “Object Oriented Database System Manifesto” [by Malcom Atkinson et

al] described the necessary characteristics that a system must satisfy to be

considered an object-oriented database.

- This consists of object-oriented language characteristics and database

requirements.

The following are the rules that make it an object-oriented system:

the system must support complex objects: provision of creating complex

objects from basic objects (integers, characters, etc.,)

Object identity must be supported: a data object must have an identity and

existence independent of its values.

Objects must be encapsulated: encapsulate both a program and its data.

The system must support types or classes: support either the type concept

(embodied by C++) or the class concept (embodied by Smalltalk)

The system must support inheritance: class hierarchy should be followed to

share code and interfaces.

The system must avoid premature binding (also known as late binding or

dynamic binding): the same method name can be used in different classes.

The system must be computationally complete: allowing expression of any

type of operation by DML.

The system must be extensible: possibility to create new user-defined types

equivalent to system-defined types

The following are the rules that make it a DBMS

It must be persistent, able to remember an object state: the system must

allow the programmer to have data survive beyond the execution of the

creating process for it to be reused in another process.

Able to manage very large databases: managing efficiency of accessing to

the secondary storage and provide performance features (indexing,

clustering, etc.,)

Accept concurrent users: allow multiple concurrent users and support the

notions of atomic, serializable transactions

Able to recover from hardware and software failures and recover to a

coherent state.

Data query must be simple: provision of high-level mechanism for ad-hoc

browsing of the database.

OBJECT-RELATIONAL SYSTEMS (ORS)

The main process in relational and object integration is defining the

relationships between the table structures (represented as Schemata) in the

relational database with classes (representing classes) in the object model.

creating a relational schema from an existing object model often is referred

to as forward engineering

Creating an object model from an existing relational database layout

(schema) often is referred to as reverse engineering.

MULTI DATABASE SYSTEMS (MDBS)

- A multidatabase system (MDBS) is a database system that resides

unobtrusively on top of existing relational and object databases and file

systems (called local database systems) and presents a single database

illusion to its users.

- MDBS maintains only the global schema, and the local database systems

actually maintain all user data.

- The global schema is constructed by integrating the schemata of the local

databases

- The schematic differences among them are handled by neutralization (also

called as homogenization), the process of integrating the local schemata.

A Schematic diagram of Multidatabase System

- The MDBS translates the global queries and updates for dispatch to the

appropriate local database system for actual processing, merges the results

from them and generates the final result for the user.

- Open Database Connectivity (ODBC) is an application programming

interface that provides solutions to the multidatabase programming problem.

- ODBC and the other APIs provide standard database access through a

common client-side interface.

- Functions of ODBC:

The application interacts with the ODBC driver manager

The ODBC driver sends the application calls (SQL Statements) to the

DB.

Applicatio

Virtual

OODBM DBMS DBMS OODBM

The driver manager loads and unloads drivers, performs status checks

and manages multiple connections between applications and data

sources.

designing access layer classes

- to create a set of classes that know how to communicate with the place(s)

where the data actually resides (file, DB, RDB, internet, via ORDB, etc.,)

- the access classes must be able to translate any data-related requests from

the business layer into the appropriate protocol for data access

- the access layer performs the following tasks:

Translate the request

Translate the results

- Advantages of access layer classes:

the design is not tied to any database engine or distributed object technology

(like CORBA or DCOM)

provide easy migration to emerging distributed object technology (CORBA,

DCOM)

These classes should be able to address the needs of two-tier Client / Server

architecture as well as peer-to-peer distributed object architectures.

PROCESS STEPS IN C++ (specific): for every business class identified:

determine if the class has persistent data

mirror the business class package (class to class database)

define relationships

simplify classes and relationships

redundant classes to be eliminated

method classes to be checked for further refinement

iterate and refine

<< The End of Unit – III >>

UNIT IV USER INTERFACE DESIGN

Introduction

- user interface (UI) layer consists of objects with which the user interacts

- responsibilities of the layer:

responding to UI (Click, menu selection ) – equivalent to the input

displaying business objects – equivalent to the output

Goal: to display and obtain needed information in an accessible, efficient manner

- a Graphical User Interface (GUI) uses:

icons – to represent objects

a pointing device – to select operations

graphic imagery – to represent relationships

USER – INTERFACE DESIGN AS A CREATIVE PROCESS

- creative thinking has various dimensions, doing by various people like:

the artist sketches painting

the journalist promotes an idea

the teacher encourages student development

the programmer develops / enhance a software system

the manager implements a new strategy etc.,

- the creative process (in view of UI design) is a combination of the following:

a curious and imaginative mind

a broad background and fundamental knowledge of existing tools and

methods

being able to deal with uncertainty

able to discover solutions once a problem has been defined

curious and imaginative mind

a broad background and fundamental knowledge of existing tools and

methods

being able to deal with uncertainty

able to discover solutions once a problem has been defined

DESIGNING VIEW LAYER CLASSES

- view layer classes (interface objects) – objects that represent the set of

operations in the business that users must perform to complete their tasks

- the process of designing view layer classes is divided into four major

activities:

the macro level UI design process: identifying view layer objects:

Identify classes that interact with human actors by analyzing the use cases

developed in the analysis phase

micro level UI design activities:

Designing the view layer objects by applying design axioms and

corollaries

Prototyping the view layer interface

testing usability and user satisfaction

refining and iterating the design

Micro level process

- The design of the view layer objects must be “user driven” or “user

centered” to replicate the user’s view of doing things by providing the

outcomes users expect for any action. (Ex.: a paper process to computer

automation)

- process steps in designing view (interface) object:

Apply micro level UI design rules and corollaries to develop the UI

Iterate and refine

UI design rules based on the design axioms and corollaries

Rule 1 > Making the interface simple

- user interface must be so simple that users are unaware of the tools and

mechanisms that make the application work

- each UI class must have a single, clearly defined purpose

- documentation should describe the purpose of the UI class with few

sentences

- apply KISS (Keep It Simple and Straightforward – Maria Capucciati)

methodology to identify the essential choices or fields to include (labels, text

…)

Rule 2 > Making the interface transparent and natural

- the UI should be so intuitive and natural that users can anticipate to do next

level of action / operation without a computer

- there should be a strong mapping between the user’s view of doing things

and UI classes

- using metaphor or analogy to represent the other (a question mark to label a

help button)

Rule 3 > Allowing users to be in control of the software

- the users always should feel in control of the software, rather than feeling

controlled by the software. Following are the implications:

actions are started by the users, not by the computer

users must be able to customize aspects of the interface (setting colors, fonts,

…)

the software should be as interactive and responsive as possible (dialog)

Some of the ways to put users in control are:

make the interface forgiving: users actions must be easily reversed (undo

operations)

Makes the interface visual: users can see, rather than recall, how to

proceed. (select from a list of items)

provide immediate feedback: users should never press a key or select an

action without receiving immediate visual or audible feedback or both (color

change)

Avoid modes (“a mode is a state that excludes general interaction or

otherwise limits the user to specific interactions”) [Ex.: confirmation alert to

delete something, before deletion]. Some of the modes that can be used in

the UI:

modal dialog: action errors to continue their actions (saving a file)

Visual cue: color boundary for the dialog box.

spring – loaded modes: resume in same action (dragging a text with a

mouse)

Visual cue: highlight / blinking text

Tool – driven mode: changes occurred in mouse pointer when selecting a

tool.

Visual cue: pencil or paint brush for drawing.

Make the interfaces consistent: user interface must be consistent

throughout the applications.

THE PURPOSE OF A VIEW LAYER INTERFACE

forms and data entry windows

dialog boxes

application windows

[Sessions 12.6.1 to 12.6.6 left as self-study].

UNIT V SOFTWARE QUALITY ASSURANCE

Introduction

- the essence of software quality is customer satisfaction

- QA testing looks for potential problems in a proposed design

- Usability testing tests how well the interface fits user needs and expectations

QUALITY ASSURANCE TESTS

- “Debugging” is the process of finding out where something went wrong and

connecting the code to eliminate the errors or bugs that cause unexpected

results

- kinds of errors when run a program:

Language (syntax) errors

Run time errors

Logic errors

- QA testing can be divided into two categories:

Error – based testing: technique searches a given class’s method for

particular clues of interests, then describe how these clues should be

tested. (also known as “Testing the boundary conditions”)

Scenario – based testing: concentrates on what the user does, not what

the product does.

TESTING STRATEGIES

- does the “best” job of finding defects in a product within the

given constraints.

- various strategies:

Black box testing

- inside working of a system are not available for inspection

- test for various input and the resulting output

- nothing is mentioned about the process

White box testing

- specific logic is important and must be tested to guarantee

- an error – based testing method

- one form of WBT is “Path Testing”

“Makes certain that each path is a object’s method is executed at least once

during testing”. Two types of path testing:

Statement testing coverage: test every statement in the object’s

method by executing it at least once.

Branch testing coverage: ensures every branch alternative has

been executed at least once.

Top-down testing

- the main logic or object interactions and systems messages of the application

need more testing than an individual object’s methods.

- Testing interface navigation

Bottom-up testing

- starts with the details of the system and proceed to higher levels until they

collectively fit the requirements for the system

- used in testing the individual objects in a system

TEST CASES

- the test must cover all methods or a good majority of them

- to test a system, construct some test input cases then describe how the output

will look

- perform the tests and compare the outcome

[Guidelines for developing QA test cases – self study]

TEST PLAN

- a test plan is developed to detect and identify potential problems before

delivering the software to its users

- steps required to create a test plan:

objective of the test

development of a test case (data, input, output)

test analysis (examine output, documentation)

[Guidelines: self- study]

CONTINUOUS TESTING

- software is tested

to determine whether it conforms to the specifications of requirements

test for potential problems in a proposed design

compare the various designs to determine which is better

- steps lead for successful testing:

understand and communicate the business case – for improved testing

develop an internal infrastructure – to support continuous testing

look for leaders – who will commit to and own the process

measure and document your findings – in a defect recording system

publicise improvements – to be known by the public what they are doing

better

DEBUGGING PRINCIPLES [Suggested by Myer]

bug location principles

think

sleep on reading an impasse (means: deadlock)

describe the problem to someone, if the impasse remains

use debugging tools

last, do the experimentation

debugging principles

one bug may have successive bugs

fix the error, rather than its symptom

probability of the solution being correct drops as the size of the

program increases

error correction may correct a new error

SYSTEM USABILITY AND MEASURING USER SATISFACTION

- quality refers to the “ability of products to meet the users” need and

expectations

- two main issues in software quality:

validation: user satisfaction

verification: quality assurance (QA)

USABILITY TESTING

- usability is defined as: [defined by ISO]

“Effectiveness, efficiency and satisfaction with which a specified set of users

can achieve a specified set of tasks in particular environments”

- the above definition requires:

defining tasks: what are the tasks?

Defining users: who are the users?

A means of measuring effectiveness, efficiency and satisfaction: how

do we measure usability?

- usability testing measures the ease of use as well as the degree of comfort

and satisfaction users have with the software

- usability test cases begin with the identification of use cases that can specify

the target audience, tasks and test goals

[Guidelines for developing usability testing and recording the usability test –

self study]

USER SATISFACTION TEST (UST)

- the process of quantifying the usability test with some measurable attributes

of the test (functionality, cost, ..)

PRINCIPAL OBJECTIVES OF THE USER SATISFACTION:

as a common vehicle between designers, and between users and designers

to detect and evaluate changes during design process

to provide a periodic indication of divergence of opinion about the current

design

to enable pinpointing specific areas of dissatisfaction for remedy

to provide a clear understanding of just how the completed design is to be

evaluated

[Guidelines for developing a user satisfaction test: self-study]

A TOOL FOR ANALYZING USER SATISFACTION (Commercial Off-

The-Shelf (COTS) is a software tool for analyzing and conducting

UST)

USER SATISFACTION CYCLE ACTIVITIES: [defined by: Gause &

Weinberg]

create a user satisfaction test for your own project

conduct the test regularly and frequently

read the comments carefully (don’t omit the strong feelings – like results of

interview)

use the information from UST usability test, reactions to prototypes,

interview recorded and other comments to improve the product

<< The End of Unit – V and the Syllabus >>