Se Ooad

Object-Oriented Analysis & Design
A Two-Day Seminar
Michael A. Grasso grasso@cs.umbc.edu http://www.cs.umbc.edu/~mikeg
Object Oriented Analysis and Design
CSC, Slide 1
Objectives
Module Objective To provide a brief, hands-on overview of object-oriented analysis and design. Topics covered include analysis, design, complementary procedures, and process improvement. In-Class Exercises Case studies based on small project specifications will be used by participants to develop object-oriented models and identify implementation strategies. Module Completion Requirement Participants will be required to demonstrate that they can apply basic object oriented techniques to create and modify object oriented analysis and design models.
CSC, Slide 2
Page 1
References
Software Engineering Software Engineering, 5th Ed., Ian Sommerville, 1995, chapter 14. Coad/Yourdon OOAD Object Oriented Analysis, 2nd Edition, Peter Coad and Ed Yourdon, 1991. Object Oriented Design, Peter Coad and Ed Yourdon, 1991. Object Oriented Programming, Peter Coad and Jill Nicola, 1993. Booch Object Oriented Design Object Oriented Design and Analysis, 2nd Ed., Grady Booch, 1994. Rumbaugh Object Modeling Technique Object Modeling and Design, James Rumbaugh et al., 1991.
CSC, Slide 3
Outline
Section 1. 2. 3. 4. 5. 6. Topic Introduction to OO Object Oriented Analysis Additional Procedures Object Oriented Design Process Improvement Case Studies Slide 5 27 63 82 108 119
About the Instructor Michael Grasso received a doctorate in Computer Science from the University of Maryland Baltimore County in 1997. His research interests include human computer interaction and medical informatics. He has been the Principal Investigator on several research grants sponsored by NIH and DoD. He received a B.S. in Microbiology in 1983 from the University of Maryland at College Park and an M.S. degree in Computer Science from the American University in Washington, DC in 1986.
Object Oriented Analysis and Design CSC, Slide 4
Page 2
Section 1: Introduction to OO
Object Oriented Model. Comparison of Other Approaches. Object Oriented Abstractions.
CSC, Slide 5
Object Oriented Model

An Object Oriented model is based on entities. Hidden state. Operations on that state. An Object Oriented model uses information hiding. Minimal dependence on global state information. Increases understanding of the design. It views software as a set of interacting objects. Compare to viewing software as a set of functions. It uses various object-oriented abstractions Classification, Inheritance, Aggregation, Polymorphism. OOAD differs from Object Oriented Programming. OOAD is a design strategy. It is not dependent on any specific implementation language.
Page 3
Characteristics of OOAD
Shared data areas are eliminated. Objects communicate by exchanging messages. Reduces the overall system coupling. Objects are independent entities. Changes to implementation of a class should not impact overall system. The separation of external and internal behavior should enhance reuse. Objects can execute either sequentially or in parallel. This is a design decision which can be deferred to later in the design process. For many systems, there is a clear mapping between real-world entities and objects within the system. This improves the understandability of the design.
Classes as the Foundation for a Design

Match the technical representation of a system more closely to the conceptual view of the real world. Relatively stable over time and provide a basis for moving towards reusable analysis results. Avoid shifting the underlying representation of the system as it progresses from analysis to design to implementation. Create building blocks from object and groupings of objects. Not chunks of data or just functions.
CSC, Slide 8
Page 4
Comparison of Analysis Approaches
Functional Decomposition. Structured Analysis. Data Modeling. Object Oriented.
CSC, Slide 9
Functional Decomposition Model

Map the problem domain to a set of functions and sub-functions. Transform concepts into various functions. This is an indirect conversion that is highly volatile and sometimes arbitrary. The original and probably the still the most commonly used approach. Useful to OOA within the context of defining services.
Functional Decomposition main() getSomething() processThis() calculateThat()
CSC, Slide 10
Page 5
Structured Analysis Model

Map the problem domain to flows and transformations. Transform concepts into various flows and transformations. This is an indirect conversion that has a strong function emphasis and is therefore highly volatile and arbitrary. Not useful in systems that do not transform data. Separation between data and function. Analysis results must be transformed into another format for design.
Structured Analysis
CSC, Slide 11
Data Modeling
The mapping of the problems domain into the following. Entities and Attributes. Relationships. Inheritance. Aggregation. This is a partial solution which is missing specific concepts. Services. Messages. Collaborations. Data Modeling
CSC, Slide 12
Page 6
Object Oriented Analysis

Real-world concepts are modeled as classes with corresponding state, behavior, and collaborations. No transformation. OOA directly maps the problem domain directly into a model, instead of mapping them indirectly into functions or data flows. The same model is used throughout the software engineering process during analysis, design and implementation. Minimizes volatility and maximizes resiliency. The focus is on classes, not function and data. Reuse is enhanced. Classification - Classes are relatively stable over time. Encapsulation - Classes with well-defined state and behavior. Inheritance - Specializing classes for specific applications.
Object Oriented Model

With an object oriented approach, there is a direct correspondence between the problem domain and the analysis results. The same concepts found in the problem domain are also found in the analysis results, the design results and the software.
Object Oriented Analysis
class Airplane class Radar class AirTrafficController
CSC, Slide 14
Page 7
An Object Oriented Life-Cycle

Conceptualization Establish core requirements. Analysis Develop a model of the desired external behavior. Design Create an architecture for implementation. Evolution Grow and change the implementation through successive refinement. Maintenance Manage post-delivery evolution.
CSC, Slide 15
Object Oriented Abstractions

Most of what we deal with in the real world is far more complex than we can cope with in one fell swoop. Abstraction helps us understand these concepts by emphasizing certain details while ignoring others. These include: Classification Inheritance Encapsulation Polymorphism Aggregation Association Collaboration
CSC, Slide 16
Page 8
Classification
Classification is used to group entities that share common characteristics into a class over which uniform conditions hold.
Objects/Entities Bill 12 Main St. Joe 688 Sun Ct. Sue 155 First St. Instantiate
Class Person name address
Classify
CSC, Slide 17
Inheritance
A mechanism for expressing similarity among classes. It portrays generalization (What is the same?) and specialization (What is different?), making common attributes and services explicit within a class hierarchy. Person (Generalize) name address
Bill. 12 Main St. 111-22-3333 $35,000 Sue 155 First St. $1,000
Classify Specialize Employee ssn salary Customer creditLimit
CSC, Slide 18
Page 9
Encapsulation
Encapsulation is the mechanism that binds together code and the data it manipulates and keeps both safe from outside interference and misuse. In the following, only the services move() and scale() modify the attributes of Circle. The service draw() performs some computation based on the values of the attributes.
Circle location radius draw move scale

Polymorphism
Polymorphism is the quality that allows one name to be used for two or more related but technically different purposes. In the following, each graphical object has the same services, although they are implemented differently.
Circle draw move scale

Polygon draw move scale
Line draw move scale

CSC, Slide 20
Page 10
Aggregation
Aggregation is used to treat a collection of objects as a single object. For example, among other things, a car consists of tires and an engine. Note that the opposite of aggregation is decomposition.
Car
Tire
Engine
CSC, Slide 21
Association
An association can be viewed as a weak form of aggregation or as a data-oriented relationship between two entities. For example, the following relationship models the concept that if there is a car, it must be associated with an owner.
Owner
Car
CSC, Slide 22
Page 11
Collaboration
Collaboration between classes is achieved though message passing. This documents dependencies between classes by answering the questions. What help do I need? Who needs my help? At some point, class A sends one or messages to class B.
Collaborations can be extended to show the flow of messages or control.

Collaboration Extensions
Flow of messages What messages can I send? What messages can I receive? Here class A sends the getID message to class B. A getId B
Flow of control In what order will messages be sent? These can be further grouped by scenario. For example, scenario A, steps 1 and 2. A.1 A
A.2 B C
CSC, Slide 24
Page 12
Example: OOA Model

pHContainer
run init display.1:show
pH value init read

pHDisplay display.2:read show
CSC, Slide 25
Section 1 Exercise
Use some other modeling technique to describe the pH example on the previous slide. You can use PDL, data flow diagrams, flow charts, etc. Prepare a list of objects that you would expect each of the following systems to handle. A program to compute and store bowling scores for a bowling league. A telephone answering machine. A catalog store order entry system. Design a class with encapsulated state and behavior for the following. A linked list. A sorted linked list. A telephone. A bank customer.
CSC, Slide 26
Page 13
Section 2: Object Oriented Analysis

Every OOA methodology contains some permutation of these activities to identify the following. Classes. State. Behavior. Collaborations.
These are activities, not sequential steps. However, the activities are introduced in a specific order based on volatility. Services are last, since they are the most volatile. Attributes are next most volatile. Classes and structure are the most stable.
Object Oriented Analysis Activities

Classes - Identify the classes which are part of the system. Consider persons, places, and things in the problem statement. Attempt to personify these concepts. Who am I? Refine classes using inheritance, aggregation and association. What is the same? What is different? What am I a part of? What am I associated with? State - Identify the attributes that of each class. What do I need to know? Behavior - Identify the operations or services needed for each class. To manipulate state and provide needed behavior. What can I do? Collaborations - Identify collaborations between classes. What help do I need? Who needs my help?
Page 14
Possible OO Diagrams/Views
These may be on separate diagrams or part of the same diagram. Class Diagram. A graph which shows the static structure of the model. Includes classes, class structure (attributes and operations), and class relationships (inheritance, aggregation, associations). Object Diagram, A graph of class instances. Includes objects, object states, and object collaborations. May be static and show a snapshot of system state at a point in time. May be dynamic and show how system state changes over a period of time. Other diagrams are covered elsewhere. DFD, ERD, STD, etc.
Activity 1: Classes
Class A description of a group of objects with a uniform set of properties. Classes may be further defined as any of the following. Abstract. A class with no instances, but whose descendants may have instances. Concrete. A class that can be instantiated. A class is assumed to be concrete, unless otherwise stated. Object An object is an instatiated class or an abstraction of something within the problem domain.
CSC, Slide 30
Page 15
Notation
name attributes
name (Abstract) attributes John Doe 12 Main Street 123-456-7890
services
services
Class
Abstract Class
Object
CSC, Slide 31
Naming Classes
Naming alternatives. Singular noun. e.g. Clerk. Adjective and noun. e.g. NewAccountsEmployee. Vocabulary. Choose name using the standard vocabulary for the subject matter. For example, in a library system choose the name Borrow over the name CheckOutEvent. Use readable names. Capitalize the first letter of each word. Do not add prefix or suffix codes.
CSC, Slide 32
Page 16
Finding Classes
Nouns Persons, places, and things in the problem domain. Previous OOA Results. The previous OOA results of similar systems. Structures. Inheritance and aggregation. This is an activity in itself and will be discussed later. Other Systems. Other systems or external entities the system will interact with. Devices. Devices the system will need to interact with. Defer implementation-specific computer components until design.
Finding Classes
Things or Events Remembered. Historical events that must be observed and recorded by the system. Normally and event would just be modeled as a service. event = service Here we are modeling the fact that an event happened at a particular time. event + date = event remembered class Sites. Physical locations the system needs knowledge of. Organizational Units. Organizational units the humans in the system belong to, such as within a company or country.
CSC, Slide 34
Page 17
Finding Classes
Roles Played. The roles played by human beings in the system. Distinct groups of people with specific attributes and services. Notes on human interaction. Since humans can be thought of as interacting with the entire model. Therefore, place these classes in the OOD Human Interaction Component. However, if one desires, this interaction can be placed in the OOA model, although this is not Coad and Yourdon's preference. Operational Procedures. Operational procedures the system has to hold to over time, such as work-flow steps that are not inherent in the problem domain constraints.
CSC, Slide 35
Challenging Potential Classes

Cohesion. Does the class have a single purpose? In 25 words or less, write a description for each class that describes its purpose, behavior, and collaborations with other classes. Needed Remembrance. Is there anything the system must remember about the objects in the class (attributes)? Needed Behavior. Does an object need to provide some behavior (services)? Multiple Attributes. If the class has only one attribute, the class itself maybe should be an attribute of another class.
CSC, Slide 36
Page 18
Challenging Potential Classes

Always-Applicable Attributes and Services. Is there a set of attributes that apply to each object in the class? Is there a set of services that applies to each object in a class? Domain-Based Requirements. Is the class based on those requirements the system must have, regardless of the computer technology used to implement it? Not Merely Derived Results. Is the class based on information that can be derived from other parts of the system? For example, maintaining a person's age in a system that already remembers the person's date of birth. Gathering derived results is a design decision that should be avoided during analysis.
CSC, Slide 37
Inheritance
Inheritance is also called the generalization-specialization, gen-spec, or IsA hierarchy. Note that inheritance is a relationship between classes, not objects. Generalized classes are placed higher in the hierarchy while specialized ones are found below. For example, a Vehicle is a generalized class while TruckVehicle and CarVehicle are more specialized ones. In other words, a TruckVehicle is-a-kind-of Vehicle.
CSC, Slide 38
Page 19
Inheritance Notation
Inheritance hierarchy. The generalized class at the top and the specialized classes below. The specialized class names should reflect the class they were specialized from. For example, ClerkPerson was specialized from Person.
Person
Employee
Customer
CSC, Slide 39
Inheritance Strategy
Consider each class as a generalization and apply the following criteria against specializing it. Is it in the problem domain? Would the new class have relevance? Is it within the system's responsibility? Does the system need to recognize the difference between a specialized and generalized version of the class? Will there be inheritance? Will the specialized class meet the criteria for classes? In a similar fashion, consider each class as a specialization and apply the same criteria against generalizing it.
Page 20
Inheritance Should Reflect Specialization

The inheritance should make sense. Don't introduce inheritance just for the sake of extracting out a common attribute . What would be a more appropriate way to show this? Think of another example that could be modeled as either inheritance or aggregation.
Location
Airport
Aircraft
Shipment Item
CSC, Slide 41
Inheritance Hierarchy
Most inheritance structures take the form of a tree or hierarchy.
Vehicle
CarVehicle
TruckVehicle
TrailerVehicle
CSC, Slide 42
Page 21
Inheritance Lattice
Some inheritance structures take the form of a lattice instead of a hierarchy.
Person
Clerk
Customer
CustomerClerk
CSC, Slide 43
Inheritance Lattice Continued

Person
Clerk
Customer
CustomerClerk
CSC, Slide 44
Page 22
Aggregation
Aggregation is also called whole-part or HasA. For example, an Aircraft contains an Engine or in other words, an Aircraft has an Engine. Note that this relationship can be quantified in one of two ways, depending on how the relationship is viewed. As a relationship between objects. As a relationship between classes. The approach you use will depend on the methodology you choose. Note that inheritance was viewed as a relationship between classes.
CSC, Slide 45
Aggregation Quantified Between Classes

Aggregation as a relationship between classes. This is used by Booch, Rumbaugh, and in E-R models. A ratio is used to quantify the relationship between classes. There is a one-to-many relationship between the Airplane and Engine classes (with many bounded by 4). There is a one-to-many relationship between the Airplane and CargoItem classes.
Aircraft 1 0,4 Engine Aircraft 1 m CargoItem
CSC, Slide 46
Page 23
Aggregation Quantified Between Objects

Aggregation as a relationship between objects. This is used by Coad and Yourdon. The number of connections between objects in the are quantified. An Aircraft object is connected to 0 to 4 Engine objects and many CargoItem objects. Both Engine and CargoItem objects objects are connected to 1 Aircraft object.
Aircraft 0,4 1 Engine Aircraft m 1 CargoItem
CSC, Slide 47
Aggregation as Attributes
Both aggregation and associations can also be modeled using attributes. This is covered in more detail under OOD.
Aircraft Engine[4]
Aircraft CargoItem[m]
CSC, Slide 48
Page 24
Aggregation Strategy
When looking for potential aggregation structures, consider the following. Assembly-Parts. An Aircraft is an assembly with Engine(s) as parts. Container-Contents. An Aircraft is a container with CargoItem(s) as its contents. Collection-Members. An Company is a collection with Employee(s) as its members. Associations or Object Connections. An alternative to the aggregation structure is the association, which is sometimes called a weak has-a.
CSC, Slide 49
Associations
Responsibilities. An association is used to identify that one object needs another in order to fulfill its responsibilities. Associations. Associations reflect associations between objects. Dependencies. You can also view associations as instantiation dependencies. For example, if an object of class A is instantiated, then an object of class B must be instantiated. Weak has-a. It is sometimes called a weak has-a, and can be used in place of aggregation when such a structure does make sense conceptually.
CSC, Slide 50
Page 25
Association Strategy
For each object or class. Identify associations and dependencies within the problem domain and the system's responsibilities. If necessary, the associations can be labeled. Quantify associations, similar to aggregation. A one-to-many association between the Customer and Invoice classes. Customer 1 Purchase m Invoice
A Customer object is associated with many Invoice objects. Customer

Purchase 1 Invoice
CSC, Slide 51
Many-to-Many Associations
Check for many-to-many associations. This may reflect the need for an event remembered class as an intermediary. Unless otherwise specified all quantification is between objects.
Owner
m m
Vehicle
Owner
m 1
Registration
1 m
Vehicle
CSC, Slide 52
Page 26
Multiple Associations
Check for multiple associations between objects. This may reflect the need for an event remembered class.
Register Title
Owner
Vehicle
LegalEvent Owner Date EventType Vehicle
CSC, Slide 53
Example: Small Library Database System

Identify what classes would be appropriate for the following. Include a brief description of each class as well. The Small Library Database System will be used by the Biology Department of a local college to track the borrowing of books and other forms of media, such as video tapes, and software. A secretary will operate the system and will responsible for checking out books to students and faculty members.
CSC, Slide 54
Page 27
Activity 2: State
Object states. An attribute is data for which each object in a class has a value. Attribute manipulation. Attributes are only manipulated by the services of that object. Volatility. Attributes are more likely to change than classes. Atomic concepts. Each attribute should capture an atomic concept - either a single value (such as a social security number) or a tightly related grouping of values (such as a mailing address).
CSC, Slide 55
Attribute Strategy
When identifying attributes, answer the following questions from the perspective of a single object. What do I need to know? What states can I be in? How am I described in general or in the problem domain? Put each attribute in the class which it best describes. Most often this is straight forward. In some instances, an attribute may be shared by more than one class. In this case, attempt to identify which class the attribute is really describing. Make sure each attribute contributes to the single purpose of its class.
CSC, Slide 56
Page 28
Attribute Special Cases

Check for attributes that are not always applicable. As mentioned earlier, if you find this situation, you probably need to adjust the inheritance structure. Check for class with just one attribute. Although this sometimes occurs, a class with only one attribute is possibly a single attribute that belongs to another class. Check for attributes with repeating values. The attribute with repeating values most likely needs to be promoted to a class. Defer to design the following. Compromises between data redundancy and performance. Data normalization issues such as unique identifiers.
CSC, Slide 57
Activity 3: Behavior
Behaviors of a class are also call functions, operations, or services. Identify the object states. Every change in the attribute values of an object reflects a change in the object's state that, in turn, reflect a change in object behavior. Identify the required behaviors. What is the object suppose to do? Make sure each service contributes to the single purpose of its class. All objects have the following implicit behaviors that are not explicitly shown in the OOA model. create: create a new object. connect: connect/disconnect an object from another. access: get/set the attribute values of an object. release: disconnect and delete an object.
Page 29
Activity 4: Collaborations
Message connections model the processing dependency of an object, indicating a need for services in order to fulfill its responsibilities. The message connection maps one object to another, in which a sender sends a message to a receiver. The receiver performs some processing and returns the results to the sender. Alternatively a message connection is sent to a class to create a new object. Message connections exist solely for the benefit of the services. To identify needed message connections, ask the following of each object. What other objects does it need services from? What other objects need one of its services?
Message Connection Notation

The notation for a message connection is a light or dashed arrow. The message connection may be labeled to document it or numbered to show order of execution, if necessary.
CSC, Slide 60
Page 30
Collaboration Example
In the following, a print queue sends a message to a printer telling it to print a particular print job. The message connections are part of a critical thread of execution, showing their relative order of execution.
m (A.1) 1 PrintJob
PrintQueue state initialize printNextJob buildJob addJob removeJob
(A.2) 1 1
Printer print initialize
CSC, Slide 61
Exercise: Small Library Database System

Use the classes identified earlier to complete the OOA model for the following. The Small Library Database System will be used by the Biology Department of a local college to track the borrowing of books and other forms of media, such as video tapes, and software. A secretary will operate the system and will responsible for checking out books to students and faculty members.
CSC, Slide 62
Page 31
Section 3: Additional Procedures
Subjects. Secondary Models. Complimentary Analysis Approaches. Documentation.
CSC, Slide 63
Subjects
Subjects used give an overview of a larger OOA model. They can be formalized subsystems with their own behavior or informal grouping to increase understanding. Subjects are created by following steps. Collapse the structure by promoting the uppermost class in each structure to a subject item. Make all remaining classes not in structures subject items. Refine the subjects by combining items in related sub-domains. Further refine the subjects by combining objects to minimize interactions between subjects.
CSC, Slide 64
Page 32
Subject Notation
Use one of three notations in the subject layer. Draw a large rectangle around each subject in the OOA diagram, without simplifying the structure. Use a class-like notation to show subjects and the names of the classes in each subject. Show only subject names. All three can be used at the same time to show different subjects in various levels of detail. Subject 1 Subject 1 C1 C2 C3 Class 1 Class 2 Class 3 Subject 1
Subject 2
CSC, Slide 65
Secondary Diagrams
Object Oriented Analysis is a methodology that is based on classes. However, this does not mean other models cannot be used. The difference is that these other models are secondary and that classes are the foundation of the design. Booch, Rumbaugh, Coad, and Yourdon all use secondary models in their respective methodologies. Although, each emphasize these models in different ways. Some common secondary diagrams include the following. State transition diagrams. Data flow diagrams. Service charts. Flow charts.
CSC, Slide 66
Page 33
State Transition Diagram

Temporal relationships can be modeled with state transition diagrams. Note that an alternative for simple systems is to add this information in the object diagram by labeling messages. Such diagrams model the following. Events - a signal that something has happened. States - the context in which events are interpreted. Transitions - a response to an event that causes one state to transition to another. Actions - operations fired in response to an event. A state transition diagram can be developed for each of the following. For each class. States correspond to attribute values for that class. Actions may be services of that class or some other class. For key subsystems. For the entire system.
State Transition Diagram Notation

States correspond to class attribute values. Events and actions correspond to class services.
State Attribute Values
Transition Events/Actions
CSC, Slide 68
Page 34
State Transition Diagram Example

For the PrintQueue class.
state = off initialize state = standby buildJob state = busy removeJob
CSC, Slide 69
Data Flow Diagram

Data flow diagrams are used to specify the details of the behavior of a system. Note that an alternative for simple systems is to add this information in the object diagram by labeling messages. Such diagrams model the following. Processes - a component that transforms data values. Data Flows - values the flow between processes, stores, and actors. Data Stores - passive components that hold data. Actors - external or independent components that produce and consume data. A data flow diagram can be developed for each of the following. For the services of a class or related classes. For key subsystems. For the entire system.
Page 35
Data Flow Diagram Notation

Processes correspond to class services. Data flows correspond to service inputs and outputs. Actors and data stores correspond to classes.
Process
Data Flow
Actor
Data Store
CSC, Slide 71
Data Flow Diagram Example

Data Flow for printNextJob service. request buildJob job PrintJob
User
job
print status status removeJob
CSC, Slide 72
Page 36
Complimentary Analysis Approaches

A number of additional activities can be used which are complimentary to object-oriented analysis and design methodologies. Domain Analysis. Identify classes which are common to all applications in this domain. Scenario Planning or Use-Case Analysis. Identify operations patterns by users initiating some sequence of interrelated events. CRC Cards. Class-Responsibility-Collaboration cards. Informal English. Identify key concepts from textual description of the problem.
CSC, Slide 73
Domain Analysis
Domain analysis seeks to identify the classes and objects that are common to all applications of a given domain. For example: all accounting systems have certain classes in common. Domain analysis works well, because there are very few truly unique kinds of software systems. Try to compare the system you are developing to a generalized class of systems. When starting to design a system. Survey the architecture of existing systems in that domain. Define key abstractions and mechanisms. Evaluate which can be used in the new system. A domain expert may be required to assist in this effort.
CSC, Slide 74
Page 37
Use-Case Analysis
Use-case analysis was first formalized by Jacobson [I. Jacobson, et al. 1992. Object-Oriented Software Engineering., Addison-Wesley]. A use case is a scenario that begins with some user of the system initiating some transaction or sequence of interrelated events. Scenario planning of this type is employed by many other OO methodologies, including Coad/Yourdon, Jacobson, and Wirfs-Brock. A basic scenario planning approach is introduced under human interaction in the section on design. Basic goal is to group the primary function points of the system by related behavior or hierarchy. This technique is similar to storyboarding. A common in the television and movie industry. In it's simplest form, it consists of post-its, magic markers, and a white board.
Use-Case Analysis Activities

For each interesting set of function points, storyboard a scenario to identify the following. Actors that participate. Actors are classes or categories of users, with a specific role. Their responsibilities. How they collaborate with each other. Modify the scenarios as necessary. Expand the initial scenarios to identify secondary scenarios. Create a generalized scenario from several related scenarios. Update the list of classes, responsibilities, and behaviors that result for this effort.
CSC, Slide 76
Page 38
CRC Cards
CRC cards were first proposed by Beck and Cunningham [K. Beck, W. Cunningham. October 1989. A Laboratory for Teaching ObjectOriented Thinking, SIGPLAN Notices, 24(10)]. CRC stands for Class - Responsibility - Collaboration. They are simple 3x5 index cards with the class name along the top and two columns below for responsibilities and collaborations. They provide a simple tool for team development tasks, such as storyboarding. They can be used during storyboarding sessions to keep track of the classes for each scenario. They can be easily grouped and organized.
CSC, Slide 77
Informal English
An alternative is to write an English language description of the problem, or part of the problem. [R. Abbot. November 1983. Program Design by Informal English Descriptions. Communications of the ACM, 26(11)] Take the natural language description and underline the nouns and verbs to identify candidate classes and operations, respectively. This is by no means a rigorous approach. Natural language is to imprecise and ambiguous. Any noun can be verbed, and any verb can be nouned. However, since natural language is often used for system descriptions and requirements documents, it may provide some useful insight.
CSC, Slide 78
Page 39
Service Documentation
Document the services within each class. Identify the following for each service: parameters, external input, external output, additional constraints, and notes. Services can be further documented using PDL, an object state diagram, a service chart, a flow chart, data flow, state-transition diagram, etc. Critical threads of execution spanning one or more classes can also be documented by numbering the corresponding message connections and adding additional annotations or diagrams. Don't hesitate using functionally-oriented notations to document services. In this limited context they can be very useful. You just don't want to use this approach to drive the OOA model.
CSC, Slide 79
OOA Documentation
Along with the OOAD model, additional documentation includes the class specification template. Class specification template Class Name and description Object state diagram Attributes Name, type, and description Services Name and prototype PDL, flowchart, dataflow diagram or service chart External inputs and outputs Additional constraints Pre- and post-conditions, invariants, axioms Other documentation, as needed
Page 40

Add appropriate documentation and secondary diagrams to the following. The Small Library Database System will be used by the Biology Department of a local college to track the borrowing of books and other forms of media, such as video tapes, and software. A secretary will operate the system and will responsible for checking out books to students and faculty members.
CSC, Slide 81
Section 4: Object Oriented Design
Introduction to Design Problem Domain Component Human Interaction Component
CSC, Slide 82
Page 41
Object Oriented Design

As stated earlier, analysis is the practice of studying a problem domain, leading to a specification of externally observable behavior. Building on this, design is the practice of taking a specification of externally observable behavior and adding details needed for actual computer system implementation. Analysis is the what or the problem phase. Design is the how or the solution phase. OOD consists mainly of expanding the requirements model to account for the complexities introduced in selecting a particular implementation. Human interaction. Data management. Other implementation areas.
CSC, Slide 83
No Transition into Design

The same methodology is used during design as was during analysis. This provides a common notation with no transition as you progress from analysis to design to programming. With some methodologies, the design phase is significantly different than analysis. For example, Data Flow and Entity Relationship Diagrams during analysis and Structure Charts during design. Instead the same approach is used in both analysis and design, except that design focuses on different aspects of the problem. By using the same notation, you won't be able to point to the shape of a data flow bubble and say, "I'm doing analysis" or "I'm doing design." Many times the opposite is going on anyway.
CSC, Slide 84
Page 42
Analysis versus Design

Object Oriented Analysis Identify Classes Who am I? What is the same/different? What do I contain? Who am I associated with? Attributes What do I need to know? Behaviors What can I do? Collaborations What help do I need? Who needs my help? Object Oriented Design Decide how to implement Classes State Behavior Collaborations
Add Implementation-Specific Components Human interaction Data management Other implementation areas
CSC, Slide 85
OOD Design Strategy

Problem Domain Component. The OOA results are placed here directly. Certain modifications are made base on implementation-specific criteria. Human Interaction Component. The actual displays and inputs needed for human interaction. The classes will vary somewhat depending upon the type of user interface. Example classes would include specializations of Menu, Screen, and Display. Data Management Component. Deals with the access and management of persistent data, using a flat file, relational, or object-oriented database.
CSC, Slide 86
Page 43
Problem Domain Component

The Problem Domain Component (PDC) is developed using the following strategy. Start with the OOA results. Modify the OOA results based on changing requirements or an increased understanding of the problem. Add to the OOA results based on implementation-specific criteria. Reuse Classification Aggregation and association Attributes Services Data management & lower-level detail
CSC, Slide 87
Implementation Specifics - Reuse

Some object-oriented languages come with predefined classes: Borland C++ container classes and Object Windows. Microsoft Visual C++ has the Microsoft Foundation Classes. Smalltalk has a lot of windowing constructs and container classes (arrays, sets, stacks, queues, etc.). Other sources: Purchase off-the-shelf classes and development tools. Internally developed reusable class libraries tailored to your environment.
CSC, Slide 88
Page 44
Implementation Specifics - Classification

Container Classes. Add container classes to manage and group related classes. Root Classes. Add root classes and use inheritance from this class to group problem-domain-specific classes together. Generalized Protocol. Add a generalized class to support a common protocol that a number of specialized classes require. Support Inheritance. Adjust the inheritance structures to remove multiple or single inheritance if this is not supported by your programming language. Improve Speed. Modify PDC classes to improve performance.
Implementation Specifics - Connections

Add attributes to support aggregation and association connections. You may choose to annotate these attributes with a [d] next to them, to show they were added during design. For each object involved in a connection, we ask (usually in order to send messages): Does the object need to know about the association? Example: Owner and Vehicle Does the Owner need to know which Vehicle(s) he/she owns? Does the Vehicle need to know who owns it.
CSC, Slide 90
Page 45
Implementation Specifics - Attributes

Add data types and default values to attributes. Break up attributes into atomic values. For example, during analysis there might have been an attribute called address. During design, this can be decomposed into street, city, state, and zip. Add implicit attributes. Unique identifier for each class. Attributes to model aggregation and associations.
CSC, Slide 91
Implementation Specifics - Services

Add arguments and return types to each service. int checkOut(String borrowerName, String bookName) Clarify documentation for simple services using functionally-oriented techniques. PDL (program design language). Flowcharts. Dataflow diagrams. Add implicit services (create, connect, access, release) that are necessary to enhance your understanding the design. Break down complex services into separate modules.
CSC, Slide 92
Page 46
Human Interaction Component

The HIC captures how a human will command the system and how the system will present information to the user. In general, the HIC models all external entities (most likely humans) that will act upon the PDC. Human interaction could have been added to PDC classes based on roles played by people. However, the cleaner approach is to see human interaction spanning the entire system by adding a separate human interaction component. Although prototyping should be done throughout the analysis and design phases, it is most important when designing the HIC. Their may be standards in place for look-and-feel that the HIC will need to adhere to. Also, the HIC will need to be specialized for the type of display (GUI, character-based) and available libraries.
CSC, Slide 93
HIC Strategy
Classify humans and describe their task scenarios. Identify the types of humans who will use the system. Describe their needs and what they need the system to do for them. This approach is similar to Use-Case Scenarios. Design the command hierarchy for human interaction. Menu screens or bars. A series of icons. A command line. Design the HIC Classes. Create the classes necessary to support human interaction. Types include menu, input, and display classes. Prototyping the human interface Allow user community to experience, play with, and refine the proposed human interface.
Page 47
A Simple TTY HIC

The easiest approach to human interaction would be to have a menu class along with a class for each input and display task. All interaction is based on a TTY approach. Notice that the names CustMenu and NewCustScreen imply that the classes were specialized from Menu and Screen.
CustMenu items selection display() getSelection() dispatch()
execute new customer selection
NewCustScreen items selection getCustInfo() saveCustInfo()
make new customer object
Customer customerId name creditLevel store() retrieve()
CSC, Slide 95
Windows-Based HIC Classes

HIC classes under an Windows-based system might look like this. This organization should be adjusted to support user interface technology and available libraries - Motif Widgets, Microsoft Windows SDK, Borland Object Windows, Microsoft Foundation Classes, etc. Window
0,m 1 Field
0,m 1 DisplayBox
0,m 1 Menu
CSC, Slide 96
Page 48
Windows-Based HIC Class Specializations

Specialize the HIC window for each human interaction task, such as adding a new customer or deleting an existing customer.
Window
NewCustWindow
DeleteCustWindow
CSC, Slide 97
Data Management Component

The DMC provides the infrastructure for the storage and retrieval of objects from a data management system. In general, we will use this task to identify management approaches for persistent and nonpersistent data. The Data Management Component is developed using the following strategy. Select a data management approach. Normalize the data. Design the data layout. Design the corresponding services. Design an approach for the management on non-persistent data.
CSC, Slide 98
Page 49
Select a Data Management Approach

Flat File Management. Examples: Fixed length, tokenized, or comma delimited. The operating system provides file handling and sorting. Your objects need to have the ability to manage resources at the file level, position the file to the right record, and transform data from objects to flat file. Relational DBMS. Examples: Oracle, Sybase, Ingress, or DB2. The system provides a table metaphor with rows and columns. Your objects need to know which tables and rows to access and how to transform data from objects to table format. Object-Oriented DBMS. Examples: Ontologic or Versant. The database provides necessary services to store/retrieve objects.
Normalize the Data

Normalization Strategy. Objects should have a unique identifier or primary key. This may be based on one or more attributes. The primary key will replace the implicit id attribute from OOA. Any foreign keys will replace the implicit cid attributes from OOA. Attribute values must be atomic and have with no repeating values. Each non-key attribute should be identifiable by and depend only on the key. With an OODBMS, there may be no need to normalize the data. Normalization reflects a trade-off between performance and data consistency.
Page 50
Design the DMC

Design the Data Layout. Identify files or tables along with their keys, fields, performance needs, and storage requirements. There should be a file or table for each class being stored. Object attributes become fields or columns. Design the Corresponding Services. Add services to each class that needs to know how to store() and retrieve() itself. Services are implemented using the access language (e.g., embedded SQL). Some of this behavior may be generalized into an abstract database class.
CSC, Slide 101
Example: Data Management

Data Management Approach. An SQL-based relational database, such as Oracle or Sybase. Normalize Data. Add a customerId attribute as the primary key. Design the Data Layout SQL data definition statements. Design the Corresponding Services. Add store() and retrieve() services written in embedded SQL. create table customer ( customerId int, name char(40), creditLevel float, primary key (customerId), unique (name));
Customer customerId name creditLevel store() retrieve()
CSC, Slide 102
Page 51
Non-Persistent Data Management

Extend Approach to Non-Persistent Data. A data management approach may also be adopted for data that will not be stored in a data management system. For example, a linked list class may be included to manage a set of customer objects in memory.
LinkedList
n
0,1
Customer
CSC, Slide 103
Summary of OOD Tasks

Problem Domain Component Start with the OOA results. Modify based on an increased understanding. Modify based on implementation-specifics. Human Interaction Component Classifying human interaction Designing the command hierarchy Creating human interaction classes Data Management Component Selecting a data management approach Normalizing the data Adding DMC classes and services Develop any necessary database files
CSC, Slide 104
Page 52
Programming Object Oriented Concepts

OOAD Class Object Inheritance C struct variable none C (files) separate file none none C++ class variable Java class variable
derived class subclass nested class pointer reference reference
Aggregation nested struct none Association Attribute Service Message pointer none
data member static data external function external function
data member data member member function member function
function call function call function call function call
CSC, Slide 105
Stack Example in C and C++

C Example // stack.h - external interface void push(char); char pop(); const int stack_size = 100; //////////////////////////////////////// // stack.c - internal representation #include "stack.h" static char v[stack_size] static char* p = v; void push(char c) { // code for push } char pop() { // code for pop }
C++ Example class Stack { char *v; int sz; public: Stack(int size); ~Stack(); void push(char c); char pop(); }; main() { Stack s1(10); Stack s2(25); ... }
Page 53

Convert the OOA model into an OOD model by adding appropriate design components. The Small Library Database System will be used by the Biology Department of a local college to track the borrowing of books and other forms of media, such as video tapes, and software. A secretary will operate the system and will responsible for checking out books to students and faculty members.
CSC, Slide 107
Section 5: Process Improvement
Software Crisis. Process Maturity. Implementing OO. OO Vendors, Methodologies, and Tools. Refer to IEEE Computer Special Issue on Managing Object-Oriented Software Development, 29(9), September, 1996, for more information.
CSC, Slide 108
Page 54
A Software Crisis
A 1979 GAO report (FGMSD-80-4, 11/79) evaluated 7 million dollars worth of software development projects and discovered that as a percentage of cost: 47% were never used 29% were never delivered 19% required extensive reworking or were abandoned 3% required additional modifications 2% met its requirements Tom DeMarco pointed out in 1982 that 25 percent of large system development projects never finish. (Controlling Software Projects, Prentice Hall, 1982) Capers Jones documented in 1991 the gloomy statistic that the average MIS development project is one year late and 100 percent over budget. (American Programmer, 6/91)
Problem vs. Solution

Analysis is the process of extracting the needs of a system - what the system should do, not how the system will be implemented. It is the problem-oriented (not the solution-oriented) phase in the software engineering process. Although we have a natural affinity toward results-oriented tasks (e.g., design), we need to focus more on the problem to avoid treating merely the symptoms and to provide an unbiased view of the situation. (George Wedberg, But First, Understand the Problem, ASM Journal of Systems Management, page 22-28, 6/90) The risk of mortality ... increases when treatment is begun before a specific diagnosis has been reached. (The Merck Manual, 13th Edition, page 765, 1977)
CSC, Slide 110
Page 55
Analysis Challenges
Problem Domain Understanding To design an accounting system, an analyst needs to become an expert in accounting systems, and will probably need to understand these systems better than the average user will. Person-To-Person Communication It is very difficult for people from different perspectives to share ideas with each other. For example, an analyst and a user, or a manager and a worker. Continual Change Requirements will change. Your designs need to account for change and should attempt to minimize their effect. Reuse Reuse of code as well as design and analysis results.
Factors Influencing Software Development

Walston and Felix compared several development efforts to identify those factors having the greatest impact on that process as a function of the number of lines of code written per month. 1. Low User Interface Complexity. 500 lines vs. 124 lines. 2. User Plays a Limited Role in Requirements Definition. 491 lines vs. 205 lines. 3. Experienced Programming Team. 410 lines vs. 132 lines. Other factor such as design and programming methodologies had a positive effect, but not as great. IBM Systems Journal, 1977, 16(1).
CSC, Slide 112
Page 56
Process Maturity and OOAD

The Capability Maturity Model (CMM) for Software is a framework that describes the key elements of an effective software process. The Capability Maturity Model (CMM) was developed after realizing that the fundamental problem of software development is the inability to manage the software process. Once basic project management controls are in place, an OO approach can be adopted as part of an organizations standard software process (OSSP).
CSC, Slide 113
Project Management
Your first OO application will take longer. Expect at least 25% longer. There is a learning curve associated with adopting OO. More of the total effort will be spent in analysis and design. Expect about 60% of the total effort. Class design is an iterative process. Spiral approach. Radical waterfall approach. Evolutionary approach.
CSC, Slide 114
Page 57
Moving to OO Software Development

Establish basic project management controls. Requirements management. Project planning. Software quality assurance. Software configuration management. Invest in technology. Commitment from management. Training. Purchase tools; purchase or build reusable components. Adjust development practices (and thinking). An OO project team should have the following characteristics. Not rigid and willing to take risks. Able to work under uncertainty. Committed to new technology. Peer and chief-programmer team structure.
More on Moving to OO
Selecting the First Project. A new system with clean interfaces and little legacy code. Large enough to be meaningful, but small enough to handle. Support from senior management. Why OO Projects Fail. Expect OO technology to solve preexisting problems within a groups development process or culture. Not sure how to manage transition to new technology. Project management defering to programming team on management issues, because of new technology.
CSC, Slide 116
Page 58
OO Advantages and Disadvantages

Advantages. Enhanced modularity. Unified approach. Reuse and extendibility through ... Inheritance. Polymorphism. Encapsulation. Incremental life cycle useful when requirements are not well understood. Disadvantages. Immaturity of techniques and tools. Lack of standard notation. Commitments required for maximizing reuse. Inheritance complicates testing. Incremental life cycle poses management challenges.
OO Vendors, Methodologies, and Tools

Object International, Inc. Methodology. Coad and Yourdon. Tools. Together C++. Playground. Rational Software Corporation. Methodology. Booch. Rumbaugh. UML. Tools. Rational Rose. Rational CRC. http://www.oi.com/
http://www.rational.com/
CSC, Slide 118
Page 59
Section 6: Case Studies

The following case studies will be used throughout this class for participants develop real designs and adapt them for use with object oriented languages such as C++ or Java, and with non object oriented languages such as C. Widget Retail Sales System. Two-Dimensional Graphics Library. OOA Model.
CSC, Slide 119
Widget Retail Sales System

A certain company maintains an inventory of widgets, which it sells to the general public. Widgets are identified by size, color and the number currently in inventory. The system should also maintain information on the name, address, phone number and credit limit of customers and the name, address, phone number, social security number, salary, and job title of employees. For each sale, the system should keep track of the widgets purchased. A sale may include a number of line items. For example, a customer may purchase 5 big blue widgets and 3 little red widgets. The system should compute a subtotal for each line item, tax, and a final total. In addition we want to know the customer and employee involved in the sale. The system also keeps tack of purchase orders from widget suppliers. A list of suppliers is maintained that includes name, address, phone number, and that supplier's wholesale price for the various widgets it carries.
Page 60
Two-Dimensional Graphics Library

Develop an OOA model for a two-dimensional graphics library that can be incorporated in applications which require graphics. The system should support points, rectangles, circles. The system should support color as well as drawing, rotation, moving, and scaling those objects for which these services are appropriate. Hint: Use an abstract class to define a generalized graphical object. Hint: A location is a position. A point is a graphical object. Hint: Dont use a line graphical object as an intermediate class. Continue with OOD by adding the necessary classes to the OOA results to create an implimentation-specific problem domain component. Show how the graphics system could support at least two output devices: a plotter and a monitor.
OOA Model
Use the basic class/state/behavior/collaboration OOA notation to describe the OOA notation itself. This might be necessary, for example, if you were to develop a case tool that supported this approach. Hints: Start out by listing every concept in the notation, such as attributes and whole-part structures. Build structures from these concepts. For example, a class has attributes. Add support for secondary models and documentation, such as subjects and data flow diagrams.
CSC, Slide 122
Page 61
Small Library Database System

BorrowScreen borrowerName mediaTitle run enterBorrowerName enterMediaTitle ReturnScreen mediaTitle run enterMediaTitle LibraryContainer run execute selection LibraryMenu 1 execute selection create, checkOut, store 1 run displayMenu getUserSelection executeUserSelection
...
m 1 connect Media id title subject store retrieve Not shown are whole-part connections from LibraryContainer to all other classes.
retrieve, checkIn, store Borrow id checkOutDate checkInDate borrowerId mediaId checkOutMedia checkInMedia store retrieve
Borrower id name office officePhone type store retrieve
m connect
type is faculty or student checkOutMedia(borrowerName, mediaTitle) send getBorrowerId message to borrower send getMediaId message to media set checkOutDate to system date checkInMedia() set checkInDate to system date Borrow::retrieve(borrowerName, mediaTitle) Borrow::retrieve(id) retrieve borrow from database based on id or name and title
Book author publisher
VideoTape format rating
Software format computer
CSC, Slide 123
Widget Retail Sales

Person (Abs) legalName address
Employee userName authorization
(A.1)
0,m (A.2)
Customer phone creditLevel
SalesTransaction date total subTotal tax calculateTotal calculateTax calculateSubTotal 1 m (A.3)
WidgetOffer offerPrice 1 m 1 m Supplier companyName address
1 WidgetDescription SalesTransactionItem name m quantity size 1 actualCost color (A.4) cost calculateCost amountInStock updateWidget amountOnOrder reorderLevel adjustInventory reorder makePO
CSC, Slide 124
Page 62
Graphics Library
ShapeContainer paint 0,m 1 paint 1 GraphicDevice (Abs) xLen yLen init [abs] restore [abs] drawPoint [abs] drawRectangle [abs] drawCircle [abs]
1 Shape (Abs) color draw [abs] move 1 0,1 Location x y Point draw Circle radius draw scale
draw
Rectangle length heigth degreesRotated draw rotate scale
CharGraphicDevice init restore drawPoint drawRectangle drawCircle
CSC, Slide 125
OOA Model
Subject name desc connect_type = inheritance, aggregation, association, message class_type = concrete, abstract data_type = integer, string, etc. diagram_type = dfd, erd, std, etc.
m m Class name desc class_type m m 1 Service name desc prototype m Diagram name desc diagram_type m m m
Connection name desc connect_type
parent
child
1 Attribute name desc data_type
CSC, Slide 126
Page 63

Se Ooad

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Se Ooad

Hochgeladen von

Copyright:

Verfügbare Formate

Object-Oriented Analysis & Design

Object Oriented Analysis and Design

Object Oriented Analysis and Design

Object Oriented Analysis and Design

Object Oriented Model. Comparison of Other Approaches. Object Oriented Abstractions.

Object Oriented Analysis and Design

Object Oriented Model

Classes as the Foundation for a Design

Object Oriented Analysis and Design

Comparison of Analysis Approaches

Functional Decomposition. Structured Analysis. Data Modeling. Object Oriented.

Object Oriented Analysis and Design

Functional Decomposition Model

Object Oriented Analysis and Design

Structured Analysis Model

Object Oriented Analysis and Design

Object Oriented Analysis and Design

Object Oriented Analysis

Object Oriented Model

Object Oriented Analysis

class Airplane class Radar class AirTrafficController

Object Oriented Analysis and Design

An Object Oriented Life-Cycle

Object Oriented Analysis and Design

Object Oriented Abstractions

Object Oriented Analysis and Design

Class Person name address

Object Oriented Analysis and Design

Classify Specialize Employee ssn salary Customer creditLimit

Object Oriented Analysis and Design

Circle location radius draw move scale

Circle draw move scale

Polygon draw move scale

Line draw move scale

Object Oriented Analysis and Design

Object Oriented Analysis and Design

Collaborations can be extended to show the flow of messages or control.

Example: OOA Model

run init display.1:show

pH value init read

pHDisplay display.2:read show

Object Oriented Analysis and Design

Section 2: Object Oriented Analysis

Object Oriented Analysis Activities

Object Oriented Analysis and Design

name (Abstract) attributes John Doe 12 Main Street 123-456-7890

Object Oriented Analysis and Design

Object Oriented Analysis and Design

Object Oriented Analysis and Design

Object Oriented Analysis and Design

Challenging Potential Classes

Object Oriented Analysis and Design

Challenging Potential Classes

Object Oriented Analysis and Design

Object Oriented Analysis and Design

Object Oriented Analysis and Design

Inheritance Should Reflect Specialization

Object Oriented Analysis and Design

Object Oriented Analysis and Design

Object Oriented Analysis and Design

Inheritance Lattice Continued

Object Oriented Analysis and Design