Course Introduction Lecture 1

Course Introduction Lecture 1
Object Oriented Analysis and Design Pat Browne Lecture 1

Accounts Your student login is : Username: your name
Password: Student number ( Lower case letter ) Domain: Student. Lecture 1

Course Aims To provide the students with an understanding and appreciation of the role of systems analysis and design, building and testing within an object oriented system development life cycle approach. To teach the different techniques used in object oriented analysis and design. To teach software testing strategies and techniques and the application of testing techniques to object oriented developed systems. Lecture 1

Learning Outcomes On completion of the course the student will:
Understand the different approaches to object oriented software development and methodologies supporting them, Be able to use appropriate methods and techniques and to perform an object oriented analysis and design for a given case study, Know how to develop an appropriate testing strategy, Understand the test process and be able to develop test cases, To appreciate the various tools available to assist with object oriented analysis and design and testing. Lecture 1

General Subject Matter
This module enhances the knowledge of system development approaches developed in SENG1200 – Information Systems. It studies systems analysis and design in the context of object oriented development. On successful completion of the course students are expected to be able to apply object oriented analysis and design techniques. Students are also expected to appreciate and understand the differences between structured and object oriented design. Lecture 1

Syllabus: Review of the software development process: Life cycle models; Development approaches; structure systems development, object oriented development, the strengths and weaknesses of different approaches. Lecture 1

Syllabus: Object Oriented Principles and Concepts: objects, classes, instances, encapsulation, abstraction, generalisation, specialisation, aggregation, inheritance, polymorphism, messaging. Object Oriented Life Cycle: Inception, Elaboration, Construction, Transition, UML, object oriented methodologies. Lecture 1

Syllabus: Analysis and design techniques: Requirements gathering, feasibility studies, functional and non-functional requirements, fact-finding techniques. Techniques for modelling classes and transactions. Notation used. File and database organisations and structure, normalisation, using a database with an object oriented developed system. Lecture 1

Syllabus: Examples of techniques required: class diagrams, class responsibility cards (CRC), business and interface classes, use case diagrams, object sequence diagrams, object collaboration diagrams, state transition diagrams, component deployment diagrams. Lecture 1

Syllabus: Testing: validation and verification, the review process, the testing process, test strategies, V-model of testing, developing test cases, unit testing, integration testing, system testing, debugging, regression testing, the management of testing. Assignments One assignments 30%. Lecture 1

Main Topics Designing Object-Oriented Software
Rational Unified Process. Object Role Modelling. Unified Modeling Language (UML) Rational Rose and other case tools Object Constraint Language (OCL) UML for database design Design by contract A little Java Executable UML Lecture 1

Main Texts Using UML: Software Engineering with Objects and Components by Stevens and Pooley, Addison Wesley, ISBN UML Distilled: Applying the Standard Object Modeling Language by Martin Fowler, Addison Wesley, Lecture 1

Further reading UML for Database Design: Maiburg and Maksimchuk, Addison Wesley, ISBN Object Design: Rebecca Wirfs-Brock and Alan McKean, Addison Wesley, ISBN The Object Constraint Language: Warmer and Kleppe, Addison Wesley, ISBN The CRC Book: Bellin and Suchman Simone, Addison Wesley, ISBN Software Design using Java 2: Lano, Fiadeiro, Andrade, Palgrave Lecture 1

Further reading Information modelling and relational databases: by Terry Halpin, Morgan Kaufman ISBN. Model Driven Architecture with Executable UML: Raistrick, Francis, Wright, Carter, Wilkie. Cambridge University Press. Designing Object-Oriented Software: Wirfs-Broock, Wilkerson and Wiener. Prentice-Hall Lecture 1

Traditional System Lifecycle and Iterative Approaches
Structured methodologies recognise the need to spend sufficient time during the early stages to ensure a clear and comprehensive understanding of the current system, its problems and requirements. This is essentially the task of enabling the analyst to understand the system under consideration from the point of view of the managers, system users, customers and technical support. Analysis begins with the user providing a brief report of the problems and requirements as they see them in their system. The analyst will gather information about the personnel and facts that they provide and build a clear specification of the system, its objectives and its requirements Fact Finding

Traditional Systems Lifecycle
PROJECT DEFINITION SYSTEM STUDY DESIGN PROGRAMMING INSTALLATION POSTINSTALLATION REVIEW

PROJECT DEFINITION: Is there a problem? Can it be solved with a project? Makes a preliminary study to determine why a new system project is required and to state project objectives. The output of this phase is a project plan (or project proposal) SYSTEM STUDY: Analyze problems in existing systems; define objectives evaluate alternatives. Determines requirements for the proposed new system. Using these findings, the study phase performs a cost-benefit analysis to determine if proposed system solutions are feasible. The output of this phase is a detailed system proposal.

DESIGN: Logical & physical specifications for systems solution. Produces the blueprint of specifications for the new system's inputs, outputs, processing, database, procedures and controls. PROGRAMMING: Develop software code. : Translates the design specifications into software for the computer. INSTALLATION: Test the programs, train the staff, convert to new system. Usually includes a systems acceptance test. An acceptance test consists of a set of performance criteria which the system must pass before it is accepted by the user (or organization) e.g. the system must be able to process customer transactions per hour. POSTINSTALLATION REVIEW :The system is operational; users and technical specialists conduct a post-implementation audit. The system is maintained to meet new requirements or processing efficiency On-going evaluation, modifications for improvement to meet new requirements. Did the system produce the expected benefits?

The advantages of using TSL for building information systems are: It is highly structured, well defined steps/roles. It has a rigorous and formal approach to requirements and specifications and tight controls over the system building process. It is appropriate for building large transaction processing and management information systems and for building complex technical systems.

The disadvantages of this method are: It is very costly and time-consuming. It is inflexible and discourages change even though requirements will change during the project due to the long time this method requires. It is ill-suited to decision-oriented applications which can be rather unstructured and for which requirements are difficult to define.

The disadvantages of this method are: It assumes that each stage is completed before the next stage starts, there is no overlap or iteration.

TLC usually uses structure methods
In general the traditional system life cycle structured methods use structured system development, which are top down, step by step, each step builds on previous. Structured Systems Analysis defines system inputs, processes, outputs partitions system into subsystems or modules. It uses logical, graphical model of information flow using data flow diagrams and textual descriptions.

The main tools of Structured Systems Analysis are: DATA FLOW DIAGRAM: Graphical display of component processes, flow of data. Enables users or developers to view proposed system at any level of detail. DATA DICTIONARY: Controlled definitions of descriptions of all data, such as variable names & types of data. DD are often implemented in software, particularly for database development. PROCESS SPECIFICATIONS: Describes logic of processes at module level. These are often textual descriptions Structured Systems Analysis during the analysis phase of the system development life cycle. It is used to build a logical model of the system using the tools described above.

Prototyping can be included in either approach to clarify requirements, however it is more closely integrated in OO approaches. Prototyping is the process of building experimental system to demonstrate, evaluate approach; users refine needs Prototype: preliminary working version of information system for demonstration, evaluation purposes Iterative process. Steps: identify user’s requirements; Develop prototype; Use prototype; Revise & enhance prototype; best for design of end-user interface: can show how end-user interacts with system. Managing prototyping has its own problems, when is prototype complete?

TLC & Structure Methods
Structured methodologies recognise the need to spend sufficient time during the early stages to ensure a clear and comprehensive understanding of the current system, its problems and requirements. This is essentially the task of enabling the analyst to understand the system under consideration from the point of view of the managers, system users, customers and technical support. Analysis begins with the user providing a brief report of the problems and requirements as they see them in their system. The analyst will gather information about the personnel and facts that they provide and build a clear specification of the system, its objectives and its requirements

Lecture 2 Object Concepts I
Object Oriented Analysis and Design K268 SENG2100 Pat Browne 57

Timothy Budd http://web.engr.oregonstate.edu/~budd/
This lecture is based on material from Timothy Budd’s book Understanding Object-Oriented Programming by Timothy Budd

Thinking Object-Oriented
Object-oriented programming (OOP) has become exceedingly popular in the past few years. Software producers rush to release object-oriented versions of their products. Countless books and special issues of academic and trade journals have appeared on the subject. Students strive to list “experience in object-oriented programming“ on their resumes. To judge from this frantic activity, object-oriented programming is being greeted with even more enthusiasm than we saw heralding earlier revolutionary ideas, such as “structured programming" or “expert systems."

Thinking Object-Oriented
OOP is a revolutionary idea, totally unlike anything that has come before in programming. OOP is an evolutionary step, following naturally on the heels of earlier programming abstractions.

1.1 Why Is OOP Popular? paradigm
Any example or model. [from Greek model, or to compare, exhibit.] Kuhn used the term in this form, to describe a set of theories, standards and methods that together represent a way of organizing knowledge; that is, a way of viewing the world. Kuhn's thesis was that revolutions in science occurred when an older paradigm was re-examined, rejected and replaced by another.

1.1 Why Is OOP Popular? Object-oriented techniques do facilitate the creation of complex software systems, it is important to remember that OOP is not a panacea. Programming a computer is still one of the most diffcult tasks ever undertaken by humans; becoming proficient in programming requires talent, creativity, intelligence, logic, the ability to build and use abstractions, and experience even when the best of tools are available.

1.1 Why Is OOP Popular? Object-oriented programming is a way of thinking about what it means to compute, about how we can structure information and communicate our intentions both to each other and to the machine. To become proficient in object-oriented techniques requires a complete re- evaluation of traditional software development.

1.2 Language and Thought Edward Sapir (quoted in [Whorf 1956])
Human beings are very much at the mercy of the particular language which has become the medium of expression for their society.

1.2 Language and Thought Edward Sapir (quoted in [Whorf 1956])
It is quite an illusion to imagine that one adjusts to reality essentially without the use of language and that language is merely an incidental means of solving specic problems of communication or reection. The fact of the matter is that the `real world' is to a large extent unconsciously built up on the language habits of the group.... We see and hear and otherwise experience very largely as we do because the language habits of our community predispose certain choices of interpretation.

1.2.1 Eskimos and Snow An almost universally cited example of the phenomenon of language influencing thought, although also perhaps an erroneous one is the “fact" that Eskimo languages have many words to describe various types of snow. This is not surprising. With time and training we could do just as well at differentiating types of snow, however English does not force me into doing so, and so it is not natural to me. Thus, a different language (Eskimo ) can lead one (but does not require one) to view the world in a different fashion.

1.2.1 Eskimos and Snow To make effective use of object-oriented principles requires one to view the world in a new way. But simply using an object- oriented language (such as Java) does not, by itself, force one to become an object-oriented programmer. While the use of an object-oriented language will simplify the development of object- oriented solutions, it is true, as it has been quipped, that “FORTRAN style programs can be written in any language."

1.2.2 An Example from Computer Languages
The relationship we noted between language and thought for natural languages is even more pronounced in articial computer languages. That is, the language in which a programmer thinks a problem will be solved will color and alter, fundamentally, the way in which an algorithm is developed.

1.2.2 An Example from Computer Languages
Consider the task of the analysis of DNA sequences. The DNA is represented as a vector of N integer values, where N is very large (on the order of tens of thousands). The problem was to discover whether any pattern of length M, where M was a fixed and small constant (say five or ten) is ever repeated in the array of values.

The first version of the program used O(M  N2) operations, whereas the sorting solution used approximately O(M  N log(N)) operations.

1.2.3 Church's Conjecture and the Whorf Hypothesis
The Sapir-Whorf hypothesis asserts that it may be possible for an individual working in one language to imagine thoughts or to utter ideas that cannot in any way be translated, cannot even be understood, by individuals operating in a different linguistic framework.

Church's Conjecture: Any computation for which there exists an effective procedure can be realized by a Turing machine. It is interesting to compare the Sapir- Whorf hypothesis with Church's conjecture,which is almost the directly opposite concept. Note, Sapir-Whorf is from a lingusitic perspective while Church is a computer science view.

Object-oriented techniques do not provide any new computational power that permits problems to be solved that cannot, in theory, be solved by other means. But object-oriented techniques do make it easier and more natural to address problems in a fashion that tends to favor the management of large software projects. Thus, for both computer and natural languages the language will direct thoughts but cannot proscribe thoughts.

1.3 A New Paradigm Object-oriented programming is frequently referred to as a new programming paradigm. Other programming paradigms include the imperative-programming paradigm (such as C), the logic programming paradigm (Prolog), and the functional- programming paradigm (ML or Haskell).

1.4 A Way of Viewing the World
Suppose an individual named Chris wishes to send owers to a friend named Robin, who lives in another city. Chris simply walks to a nearby flower shop and initiates a sequence of envents that results in Robin receiving the flowers.

1.4.1 Agents and Communities
The mechanism that was used to solve the flower problem was to find an appropriate agent (florist) and to pass to this agent a message containing a request. It is the responsibility of the florist to satisfy the request. There is some method used by the florist to do this. Chris does not need to know the particular method that the florist will use to satisfy the request; indeed, often the person making a request does not want to know the details. This information is usually hidden from inspection.

An object oriented program is structured as a community of interacting agents, called objects. Each object has a role to play. Each object provides a service, or performs an action, that is used by other members of the community.

1.4.2 Messages and Methods The chain reaction that ultimately resulted in the solution to Chris's problem began with a request given to the florist. This request lead to other requests, which lead to still more requests, until the flowers ultimately reached Chris's friend Robin. We see, therefore, that members of this community interact with each other by making requests. So, our next principle of object-oriented problem solving is the vehicle used to indicate an action to be performed.

1.4.2 Messages and Methods Action is initiated in object-oriented programming by the transmission of a message to an agent (an object) responsible for the action. The message encodes the request for an action and is accompanied by any additional information (arguments) needed to carry out the request. The receiver is the object to whom the message is sent. If the receiver accepts the message, it accepts the responsibility to carry out the indicated action. In response to a message, the receiver will perform some method to satisfy the request.

1.4.2 Messages and Methods Note the important principle of information hiding in regard to message passing that is, the client sending the request need not know the actual means by which the request will be honoured.

1.4.2 Messages and Methods There is another principle that we see is implicit in message passing. If there is a task to perform, the first thought of the client is to find somebody else he or she can ask to do the work. This may be difficult for many programmers with extensive experience in conventional techniques. Frequently, a difficult hurdle to overcome is the idea in the programmer's mind that he or she must write everything and not use the services of others. An important part of object-oriented programming is the development of reusable components, and an important first step in the use of reusable components is a willingness to trust software written by others.

1.4.2 Messages and Methods Messages versus Procedure Calls
Information hiding is also an important aspect of programming in conventional languages. In what sense is a message dierent from, say, a procedure call? In both cases, there is a set of well-dened steps that will be initiated following the request. But, there are two important distinctions.

1.4.2 Messages and Methods Messages versus Procedure Calls(1)
The first is that in a message there is a designated receiver for that message; the receiver is some object to which the message is sent. In a procedure call, there is no designated receiver.

1.4.2 Messages and Methods Messages versus Procedure Calls(2)
The second is that the interpretation of the message (that is, the method used to respond to the message) is determined by the receiver and can vary with different receivers. Chris could give a message to a friend named Elizabeth, for example, and she will understand it and a satisfactory outcome will be produced. However, the method Elizabeth uses to satisfy the request will be different from that used by florist in response to the same request. If Chris were to ask a dentist, to send flowers to Robin. If he understands the request at all, he will probably issue an appropriate error diagnostic.

The distinction between message passing and procedure calling is that, in message passing, there is a designated receiver, and the interpretation, the selection of a method to execute in response to the message, may vary with different receivers.

Usually, the specific receiver for any given message will not be known until run time, so the determination of which method to invoke cannot be made until then. Thus, we say there is late binding between the message (function or procedure name) and the code fragment (method) used to respond to the message. This situation is in contrast to the very early (compile-time or link-time) binding of name to code fragment in conventional procedure calls.

1.4.3 Responsibilities A fundamental concept in object-oriented programming is to describe behavior in terms of responsibilities. Chris's request for action indicates only the desired outcome (flowers sent to Robin). The florist is free to pursue any technique that achieves the desired objective, and in doing so will not be hampered by interference from Chris.

1.4.3 Responsibilities By discussing a problem in terms of responsibilities we increase the level of abstraction. This permits greater independence between objects, a critical factor in solving complex problems. The entire collection of responsibilities associated with an object is often described by the term protocol. Abstraction is the purposeful suppression, or hiding, of some details of a process or artifact, in order to bring out more clearly other aspects, details, or structure.

1.4.3 Responsibilities An object oriented program requests data structures (that is, objects) to perform a service. This difference between viewing software in traditional, structured terms and viewing it from an object-oriented perspective can be summarized by a twist on a well-known quote: Ask not what you can do to your data structures,but rather ask what your data structures can do for you.

1.4.4 Classes and Instances We can use the term Florist to represent the category (or class) of all florists. Let us incorporate these notions into our next principle of object-oriented programming: All objects are instances of a class. The method invoked by an object in response to a message is determined by the class of the receiver. All objects of a given class use the same method in response to similar messages.

1.4.5 Class Hierarchies Inheritance
Chris has more information about the florist (Fred) not necessarily because Fred is a florist but because he is a shopkeeper. Chris knows, for example, that a transfer of money will be part of the transaction, and that in return for payment Fred will offer a receipt. These actions are true of grocers, stationers, and other shopkeepers. Since the category Florist is a more specialized form of the category Shopkeeper, any knowledge Chris has of Shopkeepers is also true of Florists and hence of Fred.

One way to think about how Chris has organized knowledge of Fred is in terms of a hierarchy of categories (see Figure 1.3). Fred is a Florist, but Florist is a specialized form of Shopkeeper. Furthermore, a Shopkeeper is also a Human; so Chris knows, for example, that Fred is probably bipedal. A Human is a Mammal (therefore they nurse their young and have hair), and a Mammal is an Animal (therefore it breathes oxygen), and an Animal is a Material Object (therefore it has mass and weight). Thus, quite a lot of knowledge that Chris has that is applicable to Fred is not directly associated with him, or even with the category Florist.

The principle that knowledge of a more general category is also applicable to a more specific category is called inheritance. We say that the class Florist will inherit attributes of the class Shopkeeper. There is an alternative graphical technique showing classes listed in a hierarchical tree-like structure, with more abstract classes (such as Material Object or Animal) listed near the top.

Classes can be organized into a hierarchical inheritance structure. A child class (or subclass) will inherit attributes from a parent class higher in the tree. An abstract parent class is a class (such as Mammal) for which there are no direct instances; it is used only to create subclasses.

1.4.6 Method Binding and Overriding
To accommodate differences (such as the platypus), we need to find a technique to encode exceptions to a general rule. We do this by decreeing that information contained in a subclass can override information inherited from a parent class. Most often, implementations of this approach takes the form of a method in a subclass having the same name as a method in the parent class, combined with a rule for how the search for a method to match a specific message is conducted.

The search for a method to invoke in response to a given message begins with the class of the receiver. If no appropriate method is found, the search is conducted in the parent class of this class. The search continues up the parent class chain until either a method is found or the parent class chain is exhausted. In the former case the method is executed; in the latter case, an error message is issued. If methods with the same name can be found higher in the class hierarchy, the method executed is said to override the inherited behavior.

The fact that both Elizabeth(a friend) and Fred (the Florist) will react to Chris's messages, but use dierent methods to respond, is one form of polymorphism. As explained, that Chris does not, and need not, know exactly what method Fred will use to honor the request is an example of information hiding.

Polymorphism: Any message to which objects of more than one class can respond is said to be polymorphic or to show polymorphism. Objects from different classes may respond to the same message with different behaviours. They may also respond to the other messages, with identical behaviours. For example the message balance may respond identically to some subclasses of Account, while it may behave differently with other subclasses (e.g. deposit account and current account)

1.4.7 Summary of Object-Oriented Concepts
Alan Kay identified the following characteristics as fundamental to OOP: 1. Everything is an object. 2. Computation is performed by objects communicating with each other, requesting that other objects perform actions. Objects communicate by sending and receiving messages. A message is a request for action bundled with whatever arguments may be necessary to complete the task.

3. Each object has its own memory, which consists of other objects. 4. Every object is an instance of a class. A class simply represents a grouping of similar objects, such as integers or lists. 5. The class is the repository for behavior associated with an object. That is, all objects that are instances of the same class can perform the same actions.

6. Classes are organized into a singly rooted tree structure, called the inheritance hierarchy. Memory and behavior associated with instances of a class are automatically available to any class associated with a descendant in this tree structure

1.5 Computation as Simulation
The traditional model describing the behavior of a computer executing a program is a process-state or pigeon-hole model.

In contrast, in the object-oriented framework we never mention memory addresses, variables, assignments, or any of the conventional programming terms. Instead, we speak of objects, messages, and responsibility for some action. In Dan Ingalls's words: Instead of a bit-grinding processor...plundering data structures, we have a universe of well-behaved objects that courteously ask each other to carry out their various desires.

This view of programming as creating a “universe" is in many ways similar to a style of computer simulation called “discrete event- driven simulation." In brief, in a discrete event- driven simulation the user creates computer models of the various elements of the simulation, describes how they will interact with one another, and sets them moving. This is almost identical to the average object-oriented program, in which the user describes what the various entities in the universe for the program are, and how they will interact with one another, and finally sets them in motion. Thus, in object- oriented programming, we have the view that computation is simulation [Kay 1977].

1.5.1 The Power of Metaphor A benefit of the use of object-oriented techniques is the power of metaphor. When programmers think about problems in terms of behaviors and responsibilities of objects, they bring with them a wealth of intuition, ideas, and understanding from their everyday experience. When envisioned as pigeon holes, mailboxes, or slots containing values, there is little in the programmer's background to provide insight into how problems should be structured.

Ingalls : Instead of a bit-grinding processor
Ingalls : Instead of a bit-grinding processor...plundering data structures, we have a universe of well-behaved objects that courteously ask each other to carry out their various desires. Although anthropomorphic descriptions such as the quote by Ingalls may strike some people as odd, in fact they are a reflection of the great descriptive power of metaphor.

Dictionary definition Metaphor
Metaphor: a figure of speech in which a word or phrase literally denoting one kind of object or idea is used in place of another to suggest a likeness or analogy between them (as in drowning in money); broadly : figurative language

1.5.2 Avoiding infinite Regression
Objects cannot always respond to a message by politely asking another object to perform some action. The result would be an infinite circle of requests, like a bureaucracy of paper pushers, each passing on all papers to some other member of the organization. At some point, at least a few objects need to perform some work besides passing on requests to other agents. This work is accomplished differently in various object-oriented languages. In more purely object-oriented languages, such as Smalltalk, it is accomplished by “primitive" or “native" operations that are provided by the underlying system.

1.6 A Brief History Almost all the major concepts we now associate with object-oriented programs, such as objects, classes, and inheritance hierarchies, were developed in the 1960's as part of a language called Simula, designed by researchers at the Norwegian Computing Center.

1.6 A Brief History In the 1970's Alan Kay organized a research group at Xerox PARC (the Palo Alto Research Center). With great prescience, Kay predicated the coming revolution in personal computing that was to develop nearly a decade later. Kay was concerned with discovering a programming language that would be understandable to non computer professionals, to ordinary people with no prior training in computer use.

1.6 A Brief History Bjarne Stroustrup, a researcher at Bell Laboratories who had learned Simula while completing his doctorate at Cambridge, was developing an extension to the C language that would facilitate the creation of objects and classes. This was to eventually evolve into the language C++ . Java started out as OAK, a language for embedded consumer electronic devices. It was quickly adapted for the WWW.

Java has a very large set of libraries or APIs.
1.6 A Brief History Java can be used as client side applets and server side servlets in WWW applications. Java is compiler into machine independent byte-code which is the run on specific machine through the Java Runtime Environment. At run time a just-in-time compiler complies the byte-code into native machine instructions. Java addresses many security issues, with signed applets and secure communications. Java has a very large set of libraries or APIs.

Lecture 3 Object Concepts II
Object Oriented Analysis and Design K268 SENG2100 Pat Browne 57

Timothy Budd http://web.engr.oregonstate.edu/~budd/
This lecture is based on material from Timothy Budd’s book Understanding Object-Oriented Programming by Timothy Budd

Object-Oriented Design
Working in an object-oriented language (that is, one that supports inheritance, message passing, and classes) is neither a necessary nor suficient condition for doing object-oriented programming. The most important aspect of OOP is the creation of a universe of largely autonomous interacting agents. The technique described in this chapter is termed responsibility-driven design (RDD).

3.1 Responsibility Implies Non-interference
The difference between conventional programming and object-oriented programming is in many ways the difference between actively supervising a child while she performs a task, and delegating to the child responsibility for that performance.

Responsibility-driven design elevates information hiding from a technique to an art. This principle of information hiding becomes vitally important when one moves from programming in the small to programming in the large.

Conventional programming proceeds largely by doing something to something else, modifying a record or updating an array, for example. Thus, one portion of code in a software system is often intimately tied, by control and data connections, to many other sections of the system. Such dependencies can come about through the use of global variables, through use of pointer values, or simply through inappropriate use of and dependence on implementation details of other portions of code. A responsibility-driven design attempts to cut these links, or at least make them as unobtrusive as possible.

One of the major benefits of object-oriented programming occurs when software subsystems are reused from one project to the next. This ability to reuse code implies that the software can have almost no domain- specific components; it must totally delegate responsibility for domain-specic behavior to application- specific portions of the system. The ability to create such reusable code is not one that is easily learned it requires experience, careful examination of case studies (paradigms, in the original sense of the word), and use of a programming language in which such delegation is natural and easy to express.

3.2 Programming in the Small and in the Large
Programming in the small characterizes projects with the following attributes: Code is developed by a single programmer, or perhaps by a very smallcollection of programmers. A single individual can understand all aspects of a project, from top to bottom, beginning to end. The major problem in the software development process is the design and development of algorithms for dealing with the problem at hand.

Programming in the large characterizes software projects with features such as the following: The software system is developed by a large team, often consisting of people with many different skills. No single individual can be considered responsible for the entire project, or even necessarily understands all aspects of the project. The major problem in the software development process is the management of details and the communication of information between diverse portions of the project

The effect of team size on communication Team Size 2 4 6 8 10 12 20 Pairwise Paths 1 6 15 28 45 66 190 Potential Paths 2 28 186 1016 5110 24564 COMBIN(number,number_chosen) Formula = (2^(n-1) - 1) n

3.3 Why Begin with Behaviour?
The simple answer is that the behaviour of a system is usually understood long before any other aspect. Earlier software development methodologies looked at the basic data structures or the overall structure of function calls, often within the creation of a formal specication of the desired application. But structural elements of the application can be identied only after a considerable amount of problem analysis.

A formal specification often ended up as a document understood by neither programmer nor client. But behaviour is something that can be described almost from the moment an idea is conceived, and (often unlike a formal specification) can be described in terms meaningful to both the programmers and the client.

Responsibility-Driven Design (RDD), developed by Rebecca Wirfs-Brock, is an object-oriented design technique that is driven by an emphasis on behavior at all levels of development.

3.4. A CASE STUDY IN RDD The Interactive Intelligent Kitchen Helper (IIKH) is a PC-based application that will replace the index-card system of recipes found in the average kitchen. But more than simply maintaining a database of recipes, the kitchen helper assists in the planning of meals for an extended period, say a week. The browse the database of recipes, and interactively create a series of menus. The IIKH will automatically scale the recipes to any number of servings and will print out menus for the entire week, for a particular day, or for a particular meal. And it will print an integrated grocery list of all the items needed for the recipes for the entire period.

3.4. A CASE STUDY IN RDD 3.4.1 The Interactive Intelligent Kitchen Helper 3.4.2 Working with Components 3.4.3 Identication of Components At this level of development there are just two important characteristics: A component must have a small well- defined set of responsibilities. A component should interact with other components to the minimal extent possible.

3.4. A CASE STUDY IN RDD In order to uncover the fundamental behavior of the system, the design team first creates a number of scenarios. That is, the team acts out the running of the application just as if it already possessed a working system. Assume CRC cards are used see Lecture 4.

3.5 CRC Cards: Recording Responsibility
As the design team walks through the various scenarios they have created, they identify the components that will be performing certain tasks. Every activity that must take place is identied and assigned to some component as a responsibility

3.5.1 Give Components a Physical Representation: While working through scenarios, it is useful to assign CRC cards to dierent members of the design team. The member holding the card representing a component records the responsibilities of the associated software component, and acts as the “surrogate” for the software during the scenario simulation.

3.5.1 Give Components a Physical Representation The physical separation of the cards encourages an intuitive understanding of the importance of the logical separation of the various components, helping to emphasize the cohesion and coupling (see 3.7.3).

3.5.2 The What/Who Cycle Design often this proceeds as a cycle of what/who questions. First, the design team identies what activity needs to be performed next. This is immediately followed by answering the question of who performs the action. In this manner, designing a software system is much like organizing a collection of people, such as a club. Any activity that is to be performed must be assigned as a responsibility to some component.

3.5.2 The What/Who Cycle The secret to good object-oriented design is to first establish an agent for each action.

3.5.3 Documentation Two documents should be essential parts of any software system: the user manual and the system design documentation. Work on both of these can commence even before the first line of code has been written. CRC cards are one aspect of the design documentation, but many other important decisions are not reected in them. Arguments for and against any major design alternatives should be recorded, as well as factors that influenced the final decisions.

3.6 Components and Behaviour
Initially, the team identies just five actions: 1. Casually browse the database of existing recipes, but without reference to any particular meal plan. 2. Add a new recipe to the database. 3. Edit or annotate an existing recipe. 4. Review an existing plan for several meals. 5. Create a new plan of meals.

3.6 Components and Behaviour
The first three activities are associated with the recipe database; the latter two are associated with menu plans. As a result, the team next decides to create components corresponding to these two responsibilities. Continuing with the scenario, the team elects to ignore the meal plan management for the moment and move on to refine the activities of the Recipe Database component. The next Figure shows the initial CRC card representation of the Greeter.

CRC card for the Greeter.

3.6.1 Postponing Decisions There are a number of decisions that must eventually be made concerning how best to let the user browse the database. For example, should the user first be presented with a list of categories. Alternatively, should the user be able to describe keywords to narrow a search, perhaps by providing a list of ingredients, and then see all the recipes that contain those items, or a list of previously inserted keywords ?

3.6.1 Postponing Decisions These are interesting to think about, but the important point is that such decisions do not need to be made at this point (see Section 3.6.2, “Preparing for Change"). Since they affect only a single component, and do not affect the functioning of any other system, all that is necessary to continue the scenario is to assert that by some means the user can select a specific recipe.

3.6.2 Preparing for Change Software designers need to anticipate change and plan accordingly. The primary objective is that changes should afect as few components as possible. Even major changes in the appearance or functioning of an application should be possible with alterations to only one or two sections of code. Try to predict the most likely sources of change and isolate the effects of such changes to as few software components as possible. The most likely sources of change are interfaces, communication formats, and output formats.

3.6.2 Preparing for Change Try to isolate and reduce the dependency of software on hardware. For example, the interface for recipe browsing in our application may depend in part on the hardware on which the system is running. Future releases may be ported to different platforms. A good design will anticipate this change. Reducing coupling between software components will reduce the dependence of one upon another, and increase the likelihood that one can be changed with minimal effect on the other.

3.6.2 Preparing for Change In the design documentation maintain careful records of the design process and the discussions surrounding all major decisions (traceability). It is almost certain that the individuals responsible for maintaining the software and designing future releases will be at least partially different from the team producing the initial release. The design documentation will allow future teams to know the important factors behind a decision and help them avoid spending time discussing issues that have already been resolved.

3.6.3 Continuing the Scenario

3.6.3 Continuing the Scenario
Having walked through the various scenarios, the software design team eventually decides that all activities can be adequately handled by six components (Figure 3.4). The Greeter needs to communicate only with the Plan Manager and the Recipe Database components. The Plan Manager needs to communicate only with the Date component; and the Date agent, only with the Meal component. The Meal component communicates with the Recipe Manager and, through this agent, with individual recipes.

3.6.4 Interaction Diagrams While a description such as that shown in Figure 3.4 may describe the static relationships between components, it is not very good for describing their dynamic interactions during the execution of a scenario. A better tool for this purpose is an interaction diagram. Figure shows the beginning of an interaction diagram or the interactive kitchen helper.

Figure 3.5 Interaction Diagram

3.6.4 Interaction Diagrams In the diagram, time moves forward from the top to the bottom. Each component is represented by a labeled vertical line. A component sending a message to another component is represented by a horizontal arrow from one line to another. Similarly, a component returning control and perhaps a result value back to the caller is represented. The commentary on the right side of the figure explains more fully the interaction taking place.

3.7 Software Components 3.7.1 Behavior and State: One way to view a component is as a pair consisting of behavior and state: The behavior of a component is the set of actions it can perform. The complete description of all the behavior for a component is sometimes called the protocol. For the Recipe component this includes activities such as editing the preparation instructions, displaying the recipe on a terminal screen, or printing a copy of the recipe.

3.7 Software Components 3.7.1 Behavior and State: One way to view a component is as a pair consisting of behavior and state: The state of a component represents all the information held within it at a given point of time. For our Recipe component the state includes the ingredients and preparation instructions. Notice that the state is not static and can change over time. For example, by editing a recipe (a behavior) the user can make changes to the preparation instructions (part of the state).

3.7 Software Components 3.7.2 Instances and Classes
The behaviour of each recipe object is the same; it is only the state:- the individual lists of ingredients and instructions for preparation:- that differs between individual recipes. In the early stages of development our interest is in characterizing the behavior common to all recipes; the details particular to any one recipe are unimportant.

3.7.3 Coupling and Cohesion Two important concepts in the design of software components are coupling and cohesion. Cohesion is the degree to which the responsibilities of a single component form a meaningful unit. High cohesion is achieved by associating in a single component tasks that are related in some manner. Probably the most frequent way in which tasks are related is through the necessity to access a common data value. This is the overriding theme that joins, for example, the various responsibilities of the Recipe component.

3.7.3 Coupling and Cohesion Coupling, on the other hand, describes the relationship between software components. In general, it is desirable to reduce the amount of coupling as much as possible, since connections between software components inhibit ease of development, modication, or reuse.

3.7.4 Interface and Implementation: Parnas's Principles
It is possible for one programmer to know how to use a component developed by another programmer, without needing to know how the component is implemented. The purposeful omission of implementation details behind a simple interface is known as information hiding. We say the component encapsulates the behavior, showing only how the component can be used, not the detailed actions it performs.

This naturally leads to two different views of a software system. The interface view is the face seen by other programmers. It describes what a software component can perform. The implementation view is the face seen by the programmer working on a particular component. It describes how a component goes about completing a task.

The separation of interface and implementation is perhaps the most important concept in software engineering. There is also an increasing emphasis on the reuse of general-purpose software components in multiple projects. For this to be successful, there must be minimal and well-understood interconnections between the various portions of the system.

Both of these ideas were captured by David Parnas in a pair of rules, known as Parnas's principles: The developer of a software component must provide the intended user with all the information needed to make efective use of the services provided by the component, and should provide no other information. The developer of a software component must be provided with all the information necessary to carry out the given responsibilities assigned to the component, and should be provided with no other information.

A consequence of the separation of interface from implementation is that a programmer can experiment with several different implementations of the same structure without affecting other software components.

3.8 Formalize the Interface
The next several steps refine the IIKH components. The first step in this process is to formalize the patterns and channels of communication.

A decision should be made as to the general structure that will be used to implement each component. A component with only one behavior and no internal state may be made into a function. Components with many tasks are probably more easily implemented as classes. Names are given to each of the responsibilities identied on the CRC card for each component, and these will eventually be mapped onto method names. Along with the names, the types of any arguments to be passed to the function are identied.

Next, the information maintained within the component itself should be described. All information must be accounted for. If a component requires some data to perform a specific task, the source of the data, either through argument or global value, or maintained internally by the component, must be clearly identified.

3.8.1 Coming up with Names Names should be internally consistent, meaningful, preferably short, and evocative in the context of the problem.

3.8.1 Coming up with Names The following general guidelines have been suggested: Use pronounceable names. As a rule of thumb, if you cannot read a name out loud, it is not a good one. Use capitalization (or underscores) to mark the beginning of a new word within a name, such as “CardReader” or “Card reader”, rather than the less readable “cardreader”. Examine abbreviations carefully. An abbreviation that is clear to one person may be confusing to the next. Is a “TermProcess" a terminal process, something that terminates processes, or a process associated with a terminal?

3.8.1 Coming up with Names Avoid names with several interpretations. Does the empty function tellwhether something is empty, or empty the values from the object? Avoid digits within a name. They are easy to misread as letters (0 as O,1 as l, 2 as Z, 5 as S).

3.8.1 Coming up with Names Name functions and variables that yield Boolean values so they describe clearly the interpretation of a true or false value. For example, PrinterIsReady clearly indicates that a true value means the printer is working, whereas PrinterStatus is much less precise. Take extra care in the selection of names for operations that are costly and infrequently used. By doing so, errors caused by using the wrong function can be avoided.

3.8.1 Coming up with Names Once names have been developed for each activity, the CRC cards for each component are redrawn, with the name and formal arguments of the function used to elicit each behavior identied. What is not yet specified is how each component will perform the associated tasks. Once more, scenarios or role playing should be carried out at a more detailed level to ensure that all activities are accounted for, and that all necessary information is maintained and made available to the responsible components.

3.9 Designing the Representation
The task now is to transform the description of a component into a software system implementation major portion of this process is designing the data structures that will be used by each subsystem to maintain the state information required to fullfil the assigned responsibilities.

3.9 Designing the Representation
It is here that the classic data structures of computer science come into play. The selection of data structures is an important task, central to the software design process. Once they have been chosen, the code used by a component in the fulfilment of a responsibility is often almost self-evident. But data structures must be carefully matched to the task at hand. A wrong choice can result in complex and inefficient programs, while an intelligent choice can result in just the opposite.

3.10 Implementing Components
The next step is to implement each component's desired behavior. If the previous steps were correctly addressed, each responsibility or behavior will be characterized by a short description. The task at this step is to implement the desired activities in a computer language.

3.10 Implementing Components
An important part of analysis and coding at this point is characterizing and documenting the necessary preconditions a software component requires to complete a task, and verifying that the software component will perform correctly when presented with legal input values.

3.11 Integration of Components
Once software subsystems have been individually designed and tested, they can be integrated into the final product. This is often not a single step, but part of a larger process. Starting from a simple base, elements are slowly added to the system and tested, using stubs: simple dummy routines with no behavior or with very limited behavior: for the as yet unimplemented parts.

3.11 Integration of Components
Testing of an individual component is often referred to as unit testing. Integration testing can be performed until it appears that the system is working as desired. Re-executing previously developed test cases following a change to a software component is sometimes referred to as regression testing.

3.12 Maintenance and Evolution
The term software maintenance describes activities subsequent to the delivery of the initial working version of a software system. A wide variety of activities fall into this category.

Errors, or bugs, can be discovered in the delivered product. These must be corrected, either in updates or corrections to existing releases or in subsequent releases. Requirements may change, perhaps as a result of government regulations or standardization among similar products.

Hardware may change. For example, the system may be moved to dierent platforms, or input devices, such as a pen- based system or a pressure-sensitive touch screen, may become available. Output technology may change: for example, from a text-based system to a graphical window-based arrangement.

User expectations may change. Users may expect greater functionality, lower cost, and easier use. This can occur as a result of competition with similar products. Better documentation may be requested by users.

Chapter Summary Object-oriented design differs from conventional software design in that the driving force is the assignment of responsibilities to different software components. No action will take place without an agent to perform the action, and hence every action must be assigned to some member of the object community. Conversely, the behavior of the members of the community taken together must be sufficient to achieve the desired goal.

Chapter Summary The emphasis on behavior is a hall-mark of object-oriented programming. Behavior can be identied in even the most rudimentary descriptions of a system, long before any other aspect can be clearly discerned. By constantly being driven by behavior, responsibility driven design moves smoothly from problem description to software architecture to code development to nished application.

OO Concepts III This section is based on Chapters 1,2, and 3 of Smalltalk: and Object Orientation, Pub. Springer-Verlag, ISBN , 1997. Free download available at See also chapter 1,2, 3 of Budd in your class directory:

Programming paradigms
Functional Procedural Modular Object oriented

Programming paradigms
Revolution versus evolution History /pedigree of object oriented languages

Fundamentals of object orientation

The four catechism of object orientation
Encapsulation or data hiding. Inheritance. Abstraction. Polymorphism.

Elements of Object Orientation
Class. A class is a definition for a combination of data and procedures which operate on those procedures. Subclass. A subclass is a class which inherits from another class. Superclass. A superclass is the parent of a class. Instance / Object . An instance is an example of a class.

Instance variable. This is the special name given to the data which is held by an object. The “state” of an object at any particular moment relates to the current values held by its instance variables.

Method. Method is the name given to a procedure defined within an object. The name stems from its use in early versions of Smalltalk where it was a method used to get an object to do something or return something.

Message. This is a request from one object to another object requesting some operation or data. It is traditional to say that one object sends a message to another object requesting it to do something. The idea is that objects are polite well behaved entities which carry out functions by sending messages to each other. In other languages it might be consider akin to a procedure call.

self or this . This is a reference to the object within which the method is executin g (see Figure 2.2). This means that it is possible to send messages to this object (i.e. ones’ self). Single/Multiple inheritance. Single and multiple inheritance refer to the number of superclasses that a class can inherit from.

The main benefits of OO Increased code reuse . Languages such as Smalltalk and Java encourage reuse. Every time you specify that one class inherits from another you are involved in reuse. In time most developers start to actively look to see where they can restructure classes to improve the potential for reuse. As long as this is not taken too far, this is an extremely healthy thing to do.

The main benefits of OO Data protection for little effort. Due to the encapsulation facilities provided as part of the language you get your data protected from unscrupulous users.

The main benefits of OO Encapsulation eases integration.
As users of an object cannot access the internals of the object they must go via specified interfaces. As these interfaces can be published in advance of the object being implemented, others can develop to those interfaces knowing that they will be available when the object is implemented.

The main benefits of OO Encapsulation eases maintenance.
As users of an object have been forced to access the object via the specified interfaces, as long as the external behavior of these objects appears to remain the same, the internals of the object can be completely changed. For example, an object could store an item of data in a flat file, read it from a sensor or obtain it from a database. However, external uses of the object need never know.

The main benefits of OO Simplified code - polymorphism. With polymorphism you don’t need to worry about exactly what type of object you will get at run time, only that it must respond to the message (request for a method to be executed) you send it. This means that it is a great deal easier to write reusable, compact code, than in many other languages.

The main benefits of OO More intuitive programming paradigm . It has been argued that object orientation is a more intuitive programming paradigm than approaches such as procedural. This is because we humans tend to perceive the world in terms of objects. We see dials, windows, switches, fuel pumps, automated teller machines (ATMs). These objects respond to our use in specific ways when we interact with them. For example, an ATM will require a card, a PIN number etc. in a particular sequence.

What are the problems/pitfalls?
Lots of confusing terminology Yet another programming paradigm to master Many OO environments can be inefficient Smalltalk environments are not geared up for project development. Many older systems are not based on the OO paradigm.

Lecture 4 Class Responsibility Collaboration Cards
Object Oriented Analysis and Design K268 SENG2100 Pat Browne 57 Lecture 2 Fact Finding

Lecture 2 Fact Finding

CRC Object oriented systems are modeled using objects which initially reflect the abstractions identified in the problem domain. CRC cards capture the object model in terms of classes, responsibilities and collaborations, and the class model in terms of subclass and superclass relationships. CRCs are suited to dynamic team work with particular emphasis on role playing. The team member act out the actions of a particular class. CRCs encourage an antropomorphic view. Fact Finding

Class Responsibility Collaboration cards
A CRC card is a physical index card that is annotated and used in a group setting to represent a class of objects the behaviour and interactions of both class and object. There is a card for each class, on which we write the responsibilities and other classes collaborated with. Role play during “brainstorming session”. Model three dimensions of a problem. Portable and anthropomorphic. Fact Finding

Side 1 Typical Card has: Class name Subclasses Superclasses Responsibilities Collaborators Side 2 has brief textual description of class and its attributes. Fact Finding

As with real-world classification, a class groups together objects that the programmer considers to be similar. The class gives the description of a set of objects with similar characteristics and attributes. One class description serves to describe all instances (members) of that class. The class describes the common protocol followed by the individual members (instances). Fact Finding

Objects of the same class respond to the same set of messages (the instance protocol), have the same attributes and respond in the same way to each message. (in analysis) A class describes the behaviour of a set of objects of the same kind. What are classes in design and programming? Fact Finding

Responsibilities Responsibilities are the information or data that a class maintains and services that it provides. With a bank account these could include to ‘know balance’ or ‘perform credit’ Collaborators A collaborator is is a class whose services are needed to fulfil a responsibility. Fact Finding

Collaborators are listed directly across from the responsibilities that they help fulfil. Collaborators may be listed on more than one card if they help fulfil responsibilities for several classes (1:M). Collaborations only exist to fulfil responsibilities. Collaborations will only be listed when one object actually sends a message to its collaborators . Collaborations are modelled as one way communications from initiator class to collaborator , the response is a message answer. Fact Finding

Creating a classes The Classes can be listed as a group before any cards are used. Alternatively, classes can be encountered and created as part of execution of scenarios. New classes may be discovered at any time during analysis. One person should write the names of classes as they are suggested, not much discussion here. When list is complete remove redundancies. Lecture 2 Fact Finding

Creating a classes Use textual analysis techniques.
How about user-interface design? Filtering Classes: classes examined more closely e.g. Book class could be defined as the set of objects that represent books borrowed from a library. Lecture 2 Fact Finding

Assigning Cards After filtering, classes are assigned to cards.
Each participant takes an index card which they annotate with the class name and check for agreement. Annotate side 2. Lecture 2 Fact Finding

Assigning Subclass/Superclass
Only obvious subclass/superclass relations should be developed at this stage. Lecture 2 Fact Finding

Responsibilities/Attributes
We can now assign behaviours. Attributes can be identified by reading the negotiated statement of requirement. Nouns that are not classes but characteristics of classes are best represented as attributes (e.g. the Book class may have a ‘known due date’ attribute). Lecture 2 Fact Finding

Scenarios Next follows a set of walk-throughs of the relevant scenarios from the application area. Scenarios are detailed examples of functions of the system. They describe what happens in the system from a high level point of view. For example in a library: checking out an item, returning an item, searching for an item. A generic scenario is sometimes called a use case. Lecture 2 Fact Finding

Scenarios The simulation for the scenario should be dynamic and anthropomorphic. The cards on the table are static classes. When the cards are held they represent dynamic objects. While executing a scenario the team should be holding the relevant cards. Raising and lowering cards provides visual clues about execution. Note related scenarios. Lecture 2 Fact Finding

CRC uses CRC used during: Can also be used to:
Analysis: Looking at problem domain. Design: Refining responsibility. Can also be used to: Select core classes Act out class relationships and scenarios Refine project requirement. Assist project management(giving a idea of the number and complexity of the required classes) Serve as a guide to coding (to some degree) Fact Finding

CRC uses Role play during “brainstorming session”.
Model three dimensions of a problem CRC. Analysis: Exploring at problem domain Design: Refining responsibility. Lecture 2 Fact Finding

CRC session The Classes can be listed as a group before any cards are used. Alternatively, classes can be encountered and created as part of execution of scenarios. New classes may be discovered at any time during analysis. One person should write the names of classes as they are suggested, not much discussion here. When list is complete remove redundancies. Use textual analysis as described. Lecture 2 Fact Finding

CRC session Filtering Classes: classes examined more closely e.g. Book class could be defined as the set of objects that set that represent books borrowed from a library After filtering classes are assigned to cards. Each participant takes an index card which they annotate with the class name and check for agreement. Annotate side 2. Lecture 2 Fact Finding

CRC session Only obvious subclass/superclass relations should be developed at this stage. Assigning behaviours. Attributes can be identified by reading the negotiated statement of requirement. Nouns that are not classes but characteristics of classes are best represented as attributes (the Book class may have a ‘known due date’ attribute). Lecture 2 Fact Finding

CRC session Next follows the walk-throughs (scenarios) of the application area. Scenarios are detailed examples of functions of the system. They describe what happens in the system from a high level point of view. For example in a library: checking out an item, returning an item, searching for an item. Lecture 2 Fact Finding

CRC session The simulation for the scenario should be dynamic and anthropomorphic. The cards on the table are static classes. When the cards are held they represent dynamic objects. While executing a scenario the team should be holding the relevant cards. Physically raising and lowering cards provides visual clues about execution. This promotes an anthropomorphic view of classes and objects. Note related scenarios Lecture 2 Fact Finding

A quick look at UML use cases
Use cases describe the behaviour of a system from a user's standpoint by using actions and reactions. They facilitate the definition of the system's boundary, and the relationships between the system and the environment. A use case diagram consists of an actor linked with one or more uses cases. A use case corresponds to a specific kind of system use. It is an image of a system's functionality, which is triggered in response to the stimulation of an external actor. Use cases have good support tools and standard UML notation Use case is well integrated into RUP. Lecture 2 Fact Finding

CRC and use cases. Use cases alone are not sufficient to build systems; · developers may focus use cases losing sight of class structure and architecture. · mistaken design for requirement, user requirement may be improved by design. · missing a requirement, not all requirements can be found by identifying actors. and their associated use case. Lecture 2 Fact Finding

CRC and use cases. The examination of use cases on its own is not a good way to find objects and classes. A class model is also required, techniques such as CRC cards are still useful. For example, a customer may never directly interact with a sales system (say its done by a sales person), however a customer would certainly be a class in a sales system. Also other concepts such as architecture need to be developed. Lecture 2 Fact Finding

CRC and use cases. With the emphasis on interaction and anthropomorphism CRC are more appropriate for team collaboration. CRC can be used to develop both the class diagram (structural model) and the sequence diagram (dynamic model). Use case focus more on the requirements from the actors perspecitve. Lecture 2 Fact Finding

Case study (Requirement)
A bank plans a new to build ATM system using OO methods. The ATM system will interface with the customers through a display screen, numeric and special input keys, a bank card reader, a deposit slot, and a receipt printer. Customers may make deposits, withdrawals, and balance enquiries using the ATM machine but the update of acounts will be handled by an interface to the Accounts system. Customers will be assigned a PIN and a clearance level by the Security system which can be verified prior to transactions. In the future we would also like to allow customers to update routine information such as change of address or phone number using the ATM. Fact Finding

ATM candidate classes ATM Financial Tranasction CashDispencer
Screen Message Display Fact Finding

Lecture 2 Fact Finding

CRC Summary Class A class describes the behaviour of a set of objects of the same kind. The class is essential when acting out scenarios. Responsibilities are the knowledge that a class maintains and services that it provides. Again when acting out scenarios analyst must be able to develop or know the current responsibilities of a class. Collaborators A collaborator is is a class whose services are needed to fulfil a responsibility. Fact Finding

CRC Summary Use of card during development
High level description of role at different stages: 1) Analysis: Exploring at problem domain 2) Design: Refining responsibility. Fact Finding

CRC Summary Use of card during development
Details of usage: Teams can use the CRC technique to accomplish a variety of tasks, including: Initially discovering classes Selecting the core classes Acting out class relationships and scenarios or role play during “brainstorming session”. Refining the project requirements Furthering project management, can be used to estimate the number of classes required. Serving as a guide to the design of code. Fact Finding

CRC on the web For further information see:
Fact Finding

Lecture 5 Responsibility-Driven Design
Object Oriented Analysis and Design K268 SENG2100 Pat Browne 57 Lecture 2 Fact Finding

Object Analysis This lecture is based on “A Brief Tour of Responsibility –Driven Design” by Rebecca J. Wirfs- Brock and Alan McKean, which was resented at OOPSLA 2002: The ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications Last accessed Fact Finding

Object Analysis Candidate Objects Information Essential Behavior
Associations (not strictly part of RDD) Responsibilities Collaborations Fact Finding

Object Design Roles, Responsibilities and Collaborations State Models
Control Architecture Candidate Classes Class Inheritance Hierarchies Design Level Conversations Fact Finding

What Is Responsibility-Driven Design?
A way to design emphasizing behavioral modeling using objects, responsibilities and collaborations employing informal tools and techniques that enhances development processes from XP (eXtreme Programming) to RUP (Rational Unified Process) with responsibility concepts and thinking Described in the book Design of Object Oriented Software (DOOS) by Wirfs-Brock, Wilkerson and Wiener. Fact Finding

R-DD Principles Maximize Abstraction: Hide the distinction between data and behavior. We think of responsibilities for “knowing,” “doing,” and “deciding” Distribute Behavior: Make objects smart— have them behave intelligently, not just hold bundles of data. Objects should not be too lean or too fat Preserve Flexibility: Design objects and collaborations so they can be readily changed Fact Finding

an application = a set of interacting objects
R-DD Constructs an application = a set of interacting objects an object = an implementation of one or more roles a role = a set of related responsibilities a responsibility = an obligation to perform a task or know information a collaboration = an interaction of objects or roles (or both) Fact Finding

Responsibility-Driven Design Process
Fact Finding

RDD Summary Responsibility-Driven Design is a set of tools for thinking, not for documenting (that’s for the UML) Objects behave by knowing, doing and deciding. Behavior first. Data second Responsibility-Driven Design can be used in every development project Responsibility-Driven Design is compatible with all development methods, from the lightest (XP) to the heaviest (RUP) Fact Finding

Identifying Objects/classes
In the initial stages of analysis there are various approaches for identifying objects: Data driven methods focus on the data encapsulated by the object and the operations performed on them. Process driven methods concentrate on the process encapsulated by an object. Fact Finding

Event driven methods focus on states encapsulated by the object and the definitions of the events causing state transitions. An object driven approach focuses on the extraction of the objects existing in the problem domain. Fact Finding

Responsibility driven methods start with identifying the responsibilities the object determined by the role of the object in carrying out the overall purpose of the system. RDD enables us to characterize the objects in ways that help you reason about them and their relationships Fact Finding

A Software ‘Story’ Talk about important ideas:
What is your application supposed to do? How will it support its users? Is it connected to a real world example that you can study or emulate? Is it similar to what you have done before? What will make your application a success? What are the most challenging things to design? Fact Finding

Identifying Objects/Classes
Look for inventions that represent: The work your software performs The things your software affects or is connected to The information that flows through your software Your software’s decision-making, control and coordination activities Ways to structure and manage groups of objects Representations of real world things your software needs to know something about Fact Finding

Look for Objects First, Then Shared Roles
Candidates represent important, vivid abstractions: concepts, machinery and mechanisms Initially we think very concretely: We identify candidate objects that represent things that know and do and perform some work in our application Once we have a few candidates, we can think more abstractly. Looking at candidates, we identify the roles that these objects play and which can be shared by different kinds of objects Fact Finding

Candidate classes: tangible objects; roles; events; organisational units. Fact Finding

When looking a system analysts can ask some initial questions "What processing must this system do?" "What are the objects and classes involved in this system?" "Which objects initiate or are acted upon by operations or actions?" Fact Finding

Naming Candidates Fit a name into some naming scheme
Give service providers “worker” names. Choose a name that suits a role. Choose names that expand an object’s behavior Choose a name that lasts a lifetime Include facts most relevant to its users Eliminate naming conflicts by adding description Fact Finding

Is Requirement Document Enough?
1. Object oriented systems are modeled using the objects and their relationships. The end user functionality is realized by the interaction of these objects. The objects interact by sending messages to each other. Therefore, objects, relationships and messages are important notions which characterize the object oriented systems. It is difficult to directly identify objects from the requirement documents. Objects fall in multiple categories like physical objects, roles, incidents, interactions and specifications. All this may not be easily visible in the requirement document. Fact Finding

2. Object oriented systems manage complexity through abstraction and encapsulation. Objects encapsulate a definite behavior. The requirement documents do not correctly indicate the amount of behavior encapsulated in each objects. 3. Object Oriented systems tend to encourage reuse by factoring out common responsibilities into independent classes. The requirements documents fail to indicate how much factoring is possible. Fact Finding

4. Requirements set in the beginning of the software tend to change. Therefore, the causal analysis based on systems characteristics extracted from initial requirement specification needs to be corrected. For efficient feedback we require characterizations which can be reevaluated consistently throughout the various phases of the software development cycle. Fact Finding

Classes in Specification
The main technique for indentifying classes from a statement of requirement is noun analysis. Appropriate classes are frequently suggested by the nouns or noun phrases that occur within the text of a statement of requirements. Fact Finding

Associations An association is a connection between two objects that is significant for the application area. The relationships between objects are represented as associations between the classes of which the objects are instances. Fact Finding

Associations in Specification
Verbs connect nouns and noun phrases in a statement of requirements. Verbs or verb phrases can be used to suggest likely associations (or links) between classes. For example: The department is staffed by accountants and auditors. Each auditor is assigned one job at a time. Fact Finding

class-association matrix
For many object models of moderate size, a useful approach is to take the classes that have been identified and pair them together and consider whether an association between the two classes is of significance to the application area – does the application area need to record how instances of the two classes are connected. A thorough, but laborious, way of doing this is via a class-association matrix, where classes are paired, one with another. Fact Finding

Responsibilities State responsibilities at a high level:They are for knowing, doing, deciding, calculating… Use strong descriptions:The more explicit the action, the stronger the statement. – Stronger verbs: remove, merge, calculate,credit, activate – Weaker verbs: organize, record, process, maintain, accept Fact Finding

Responsibilities Behavior for Stated at a high level
knowing Doing e.g. calculating deciding Stated at a high level Assigned to appropriate objects Fact Finding

How Do You State Responsibilities?
Don’t express responsibilities as too fine- grained. They are larger than individual attributes or operations. A single responsibility is often realized by several methods. Example: A Customer object has a name which may be comprised of a first name, surname, middle name, maiden name, and there may be aliases or nicknames. The software Customer “knows its name and preferred ways of being addressed.” Fact Finding

Where Do We Find Responsibilities?
Responsibilities come from looking at many different descriptions of system behaviour and then modeling how a community of objects work Use cases (covered in UML) Other requirements Themes and software stories (slide 13) Gaps in these system descriptions Role stereotypes Relationships and dependencies between candidates Candidates’ “life events” Technical aspects of a specific software environment A design perspective on how things should work Fact Finding

Stereotypes in RDD Stereotypes are simplified views that help us characterize object essentials. Use them to characterize the roles objects play in an application Service providers do things: a Mailer Interfacers translate requests and convert from one level of abstraction to another: Presenter and Selector Information holders know things: Letters, Words, Sentences Controllers direct activities: the Guesser Coordinators delegate work: the MessageBuilder Structurers manage object relations: Objects that manage Letters, Words, Sentences and Commands Fact Finding

Assigning Responsibilities
Responsibilities should generally match a role’s stereotype. This makes roles cohesive. Is the responsibility one for “bridging” between neighborhoods or layers? – Use a controller or interfacer Is it an extremely complex behavior? Or is it prone to change? – Use a service-provider that does little else Does it involve complex decision-making? – Use a controller Does it involve many objects of the same type? – Use a structurer Fact Finding

Assigning Responsibilities
Keep behaviour with related information. This makes roles efficient Don’t make any one role too big. This makes roles simple Distribute intelligence. This makes roles smart Keep information about one thing in one place. This makes roles safe Fact Finding

Make Objects Cohesive An object should be the sum of its responsibilities. Everything an object knows or does should contribute directly to its purpose Avoid “doing favours” that unnecessarily tie objects from different areas of the application to each other. Common favours: conversion from one object type to another, formatting, translation If you can imagine one object existing without another, don’t give it any responsibilities that require it to know about the other Fact Finding

Summary Finding and Assigning Responsibilities
Object responsibilities are derived from the application responsibilities expressed in many different requirements documents Responsibilities are distributed among the candidate objects according to the objects’ roles Responsibilities enable you to think about object behaviours without concern for how the objects perform them Responsibilities are higher lever abstractions than object methods. Fact Finding

Collaborations only exist to fulfil responsibilities.
Collaborators A collaborator is is a class whose services are needed to fulfil a responsibility. Collaborations only exist to fulfil responsibilities. Fact Finding

What Drives the Collaborations?
Behaviours described in use cases require object actions and collaborations The steps of a complex algorithms may be performed by different objects, each responsible for a given step Internal Events, such as a timer’s timeout, can start a collaboration External Events from outside devices and programs can set a group of objects into motion Fact Finding

Why Does an Object Collaborate?
That’s not my role! I don’t know enough! It’s my job to direct others! I need help! Why should I do it, too? Fact Finding

Early Collaboration Modeling
Concentrate on control, coordination, and important services Don’t over specify a collaboration Stop designing collaborations when you can show that your small set of roles fulfils its purpose Ignore UI details – Treat the UI as a source of events Decide what the scope of your thinking should be When working at a high level, think about how subsystems collaborate When studying details, limit your thinking to a small group of objects Fact Finding

Lecture 2

Characteristics of Centralized Control
Generally, one object (the controller) makes most of the important decisions. Decisions may be delegated, but most often the controller figures out what to do next. Tendencies with this strategy: Control logic can get overly complex Controllers can become dependent upon information holders’ contents Objects can become coupled indirectly through the actions of their controller The only interesting work is done in the controller Fact Finding

Characteristics of Delegated Control
A delegated control style passes some of the decision making and much of the action off to objects surrounding a control center. Each neighboring object has a significant role to play: Coordinators tend to know about fewer objects than dominating controllers Dialogs are higher-level Changes typically affect a fewer number of objects It is easier to divide design work among team members Fact Finding

Guidelines for Collaborating
Delegate control if possible. Let collaborators be responsible Look for opportunities to ask for services or direct others’ actions more intelligently Develop control centers and collaboration patterns. Look for ways to make similar things work consistently Exploit polymorphism! It eliminates complexity Determine regions where trusted collaborations can occur and where extra precautions must be taken to ensure reliable collaborations Fact Finding

Summary Designing Collaborations
Objects get things done by collaborating A collaborator is a “helper” object Collaborations have identifiable styles Centralized … one controller Delegated … a few coordinators Dispersed … no centers of control Centers of control should be easy to locate Collaborations should follow a consistent style Fact Finding

DOOS Rebecca Wirfs-brock contributed much to Responsibility-driven design approach. It is a simple idea, and it facilitates the transition from design to programming. It predates the Unified Modelling Language (UML). DOOS is a responsibility driven design method for OO development. See DOOS.doc for more detail. Lecture 2

DOOS Lecture 2

. Display Screen Cash Dispenser Deposit Drawer Special Keypad
Cancel Key Normal Pad Printer Bank Card Reader 1 2 3 4 5 6 7 8 9 . Lecture 2

ATM in DOOS An automated teller machine (ATM) is a machine through which bank customers can perform a number of financial transactions. The machine consists of a display screen, a bank card reader, input keys, a money dispenser slot, a deposit slot and a receipt printer. The main menu contains a list of the transactions that can be performed. These transactions include: deposit funds to an account withdraw funds from an account transfer funds from one account to the other query the balance of an account. Lecture 2

ATM class The ATM class represents the teller machine. Its main operations are to create and initiate transactions. This class acts as a client of both the Financial Subsystem and the User Interface Subsystem. Lecture 2

A DOOS ATM collaboration graph
Lecture 2

Financial Subsystem The Financial Subsystem implements the financial aspects of a customer's interaction with the ATM. Its main operations are to execute the following financial transactions; deposit(), withdraw(),transfer(), and balance() on customer accounts. There is one Financial Subsystem contract that must execute all the transactions. This subsystem acts as a client of the User Interface Subsystem. Lecture 2

Financial Subsystem · The User Interface Subsystem implements the interface between the ATM and the bank customer. The User Interface Subsystem has three contracts 1)To get numeric values from users. 2) Get users selection from menu. 3) To display messages and wait for events. This subsystem acts as a server of both the Financial Subsystem and the ATM class. Lecture 2

Lecture 2

DOOS ATM · Subsystems, which represent groups of classes, are described as rectangles with rounded corners while rectangles represent single classes. The arrows indicate client-server relation point to server. Simi-circles represent contracts, when the arrow points to a semi-circles it indicates a contract. Numbers are used to identify the contracts, they are cross referenced in the textual description. The object that makes the request is termed the client, and the object that receives the request (and provides the service in response) is termed the server. Lecture 2

DOOS ATM · The diagram shows that the Financial Subsystem, and the User Interface Subsystem are collaborators for the ATM class i.e. ATM is the client while the other two are the servers. A collaborator is a class whose services are needed to fulfil a responsibility. Collaborators are associated with the responsibilities that they help fulfil (1:M). Lecture 2

DOOS ATM · A collaborator may appear in more than one class if it helps fulfil responsibilities for several classes, so User Interface Subsystem is a collaborator for the other two. To fulfil a particular collaboration, each object takes on a different role. The object that makes the request is termed the client, and the object that receives the request (and provides the service in response) is termed the server, the Financial Subsystem is both a client and a server. Lecture 2

DOOS ATM · The analyst decides that an Account class and a Transaction class are needed within the Financial Subsystem. The analyst decides that the Account class should have one contract. The contract states that the Account class could access and modify the balance. The Transaction class defines the behaviour common to all transactions, including transfer. The following is a collaboration graph representing the Financial Subsystem. Lecture 2

Lecture 2

DOOS ATM · It was stated that the Transaction class represented common behaviour for each type of transaction, so we have subtyping. Nesting is used to show class/subsystem hierarchies. The original contract labelled 8 should still be show, it represents the Financial Subsystem's server role with respect to the ATM class. Lecture 2

DOOS ATM · By convention the internal diagram of a subsystem does not show its client role (the out going arrows), only its contracts are shown (in coming arrows), hence 8 is shown above but not Financial Subsystem's client relationship with the User Interface Subsystem. It does not matter whether one decides on Transaction or the Financial Subsystem to handle user interaction provided that the responsibility is handled by one of them. Lecture 2

DOOS ATM · A class (such as Financial Subsystem) can fulfil its own responsibilities or collaborate with other classes. Collaboration graphs represent classes, subsystems, contracts and collaboration and class hierarchies. The collaboration between objects in DOOS is done in a client-server way: one object (the client) requests a responsibility from another object (the server). A contract is a cohesive set of responsibilities which a client can request. Lecture 2

DOOS ATM · The cohesion between those responsibilities measures how closely those responsibilities are to one another. The contract must be fulfilled by the server. The ATM class (client) expects the Financial Subsystem to carry out a transaction. Within the Financial Subsystem the Transaction class has this responsibility which is inherited by its subclasses. The Account class expects Transaction and its subclass to request the operations. The word contract is not just another name for a responsibility. Lecture 2

DOOS ATM · Client-Server-Contract: The collaboration between objects in DOOS is done in a client- server way: one object (the client) requests a responsibility from another object (the server). A contract is a cohesive set of responsibilities which a client can request. The cohesion between those responsibilities measures how closely those responsibilities are to one another. The contract must be fulfilled by the server. ATM class (client) expects the Financial Subsystem to carry out a transaction. Within the Financial Subsystem the Transaction class has this responsibility which is inherited by its subclasses. Lecture 2

Subsystems · Subsystem: A set of classes (and possibly other subsystems, recursive definition) collaborating to fulfil one or more contracts. Conceptually a subsystem can be treated like a Class on a higher level. Subsystems are conceptual, but can be treated like coarse grain classes. Collaborations graphs are used to show Classes, Subsystems and the Client-Server Collaborations between them. The clients and servers for contracts are denoted. Subsystems, Contracts and Delegations are denoted on Subsystem cards. Lecture 2

Identify Subsystems · Identifying Subsystems starts with drawing a complete Collaborations Graph. The next guidelines have to be applied for identifying Subsystems: · Classes in a Subsystem should collaborate to support a small and cohesive set of Responsibilities. · Classes within a subsystem should be interdependent in some way. High coupling is still to be avoided, but here it is internal to the subsystem and the coupling should still be kept as low as possible between classes in the subsystem. Lecture 2

Identify Subsystems · After identifying the Subsystems the patterns of Collaborations have to be simplified by applying the next guidelines: · Minimize the number of Collaborations a Class has with other Classes or Subsystems · Minimize the number of Classes and Subsystems to which a Subsystem delegates · Minimize the number of different Contracts supported by a Class or Subsystem Lecture 2

Identify Subsystems · Subsystems are denoted on Subsystem cards. The CRC cards have to be modified because Collaborations between Classes have become Collaborations between Classes and Subsystems. The changes in Classes, Collaborations and Contracts have to be recorded both in the Hierarchy Graphs and on the CRC cards. At this stage it is again suggested to perform a 'Walk-through' to check the design. Lecture 2

Identify Subsystems · In summary subsystems can be identified by looking for frequent and complex collaborations between strongly coupled classes Lecture 2

Guidelines for identifying contracts
· Group responsibilities used by the same clients Maximize the cohesiveness of classes Contracts of a class should make sense together Minimize the number of contracts Use inheritance The set of classes all supporting a common contract should inherit the contract from a common superclass Lecture 2

Identifying Contracts
· Applying the Guidelines Start defining contract at the top of the hierarchies Name and number each contract. For each collaboration, determine which contract represents that collaboration Lecture 2

Walk-through · A walk-through takes some coherent piece of behaviour that the system must exhibit – like the transfer of funds between accounts – and explores (or exercises) how this behaviour can be carried out by the object model. A scenario is a description of a sequence of actions that illustrate a piece of interesting behaviour. A ‘use case’ in UML can be considered as a generic scenario. Lecture 2

DOOS ATM · Clients = Balance, Deposit, Withdraw, Transfer, Transaction. Servers = Account, Financial Subsystem (at analysis design stage) Lecture 2

DOOS Diagrms · Rectangles with rounded corners=subsystems
Rectangles = classes Nesting = class/subsystem hierarchies. The arrows indicate client-server relation point to server. Simi-circles = contracts, when the arrow points to a semi-circles it indicates a contract. The numbers are the identity the contracts. They are cross referenced in the textual description. Lecture 2

DOOS Protocol · The protocol of a class is the set of message understood by that class. Protocols include details of the message semantics; Lecture 2

Some comments on DOOS The responsibility driven approach of DOOS does not place a strong empahasis on data modelling. DOOS uses only a simple inheritance graph. The technique focuses on describing the system in terms of responsibility, which is taken on by classes. These responsibilities are used to describe collaborations between classes that are eventually formalized in terms of an architectural view. No behavioral view is used (e.g. not interaction diagrams). The notion of responsibilities is generally accecpted as being useful, and the initial class identification techniques of Wirfs-Brock are still used. Lecture 2

Some comments on DOOS One of the key appeals of the technique is that the hiding of the data structure and the use of responsibilities carries the notion of encapsulation into the analysis and design activity. Other techniques see encapsulation more as a detailed design notion. It may be difficult to effectively describe larger systems without defining a data model. Lecture 2

Lecture 2

Course Introduction Lecture 1

Similar presentations

Presentation on theme: "Course Introduction Lecture 1"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Course Introduction Lecture 1

Similar presentations

Presentation on theme: "Course Introduction Lecture 1"— Presentation transcript:

Similar presentations

About project

Feedback