Object-Oriented Analysis and Design I

Object-Oriented Analysis and Design

• Objects correspond to the things in the problem
• Behavior and information inherent in the problem are modeled by the objects and interactions between objects.
• Notation used to convey the structure and dynamics of the object-oriented solution is UML (Unified Modeling Language)

Object-Oriented Principles

• Object
• An object is a thing
• Thing that we are simulating can be something tangible or something intangible
• Analysis
• In analysis, these things are found in the problem space
• Analysis is a discovery process
• Design and code
• Objects are collections of data
• Properties of object
• Data
• Behavior
• Operations encapsulate the data
• The way to invoke an operation is to send a message to the object
• Message
• A request for service
• Has a name, parameters, and a result
• Name, parameter types and result type are called the signature of the operation
• Set of operation signatures for an object is called its protocol
• Class
• A template for object instances.
• All of the objects described by a class behave in the same way, and encapsulate the same kind of data.
• Class has the ability to create or construct object instances
• Our goal in object-oriented analysis and object-oriented design is to model classes, not object instances
• Inheritance
• Generalization class is sometimes referred to as the superclass and the specialization as the subclass
• In the Unified Modeling Language, generalization specialization relationships are indicated by a line with a big fat arrow head pointing from the specialization class to the generalization class
• Some of the operations in a generalization class may be abstract
• All of the specialization classes must override these abstract operations
• Polymorphism
• The protocol for sending messages to the object instance that the variable is pointing to is given by the variable type, not by the class of the object instance it is pointing to.

Finding Candidate classes

• Discover what important classes of objects exist in our software system
• These candidate classes are the ones we will use to model the system during analysis
• We will create class diagrams that model the static relationships between the classes
• We will then model the dynamic interactions between the classes using dynamic UML models such as activity diagrams
• Information that we have about the system at this point is the problem statement and the set of requirements
• Objects have state
• Model the objects as state machines without knowing how the data is implemented inside the object
• High cohesion
• Loosely coupled
• Anthropomorphism means treating things like people

CRC Analysis

• Class-Responsibility-Collaborator
• An object has two kinds of responsibilities:
• It can remember things (it has attributes).
• It can do things
• Collaboration: request the services of other objects by sending them messages
• CRC process
• Picking a system operation to study
• Choose the object that will receive the trigger message from the actor
• Repeat the following as long as there are responsibilities that need to be detailed
• Choose a collaborating object
• Negotiate the contract between the client object and the server object

Class and Object Instances

• Unified Modeling Language
• The top part contains the name of the class
• The middle part contains a list of the attributes
• The bottom part contains a list of the operations
• Object instances
• The bottom part consists of a list of its attribute names and their values, separated by equal signs
• Top box: a variable name, followed by a colon, followed by the type of the variable
• The name that appears to the left of the colon represents the reference or pointer to the object instance
• Object instance diagram
• When two object instances are physically connected, we say that they are linked
• A link is a semantic relationship between two object instances.
• Class diagram
• Represent associations by lines drawn between the classes.
• The line is labeled with a name indicating the semantic information contained in the links
• Analysis model
• Links are not directional
• Link is not stored in either object
• Links are not necessarily conduits for the messages
• Links or associations represent information
• When you need to pick a name for an association, the name of the information being stored will give you a clue
• Use a verb or verb phrase

Association Adornments

• Multiplicity
• The symbol indicates the number of instances of the class that may be linked to an instance of the class at the other end of the association
• If the number is arbitrary, put an asterisk at the end of the line.
• If the number is a range of values, use “subrange” (double dot) notation
• Roles
• Annotated on the association line at the end near the object playing the role.
• Comment
• If we put the comment inside curly braces, it is referred to as a property of the modeling element.
• We can also put comments inside dog-eared boxes, and draw a dashed line to the modeling element to which the comment refers.
• Constraint
• A constraint can be a property that restricts the value of an attribute or an association
• Whenever an object instance is constructed, the constraints must be true
• Any operation on an object or link that changes its value must preserve the constraint

Composition

• Composite
• Part-whole relationship
• UML notation for a composition relationship is a line with a solid diamond on the end toward the composite class
• Although it is an association, an association name is not necessary.
• The meaning of the association is “composed of” and is indicated by the diamond.
• The composite is an abstraction that stands in for all its parts.
• The composite object encapsulates the part objects.
• Aggregation
• This relationship is indicated by an open diamond on the end toward the aggregator class.
• An aggregation is simply a collection, but the parts are not necessarily encapsulated within the aggregator.
• Properties shared by both compositions and aggregations
• Transitive
• Anti-symmetric
• Synergism

Generalization/specialization

• Generalization/specialization relationships exist between classes.
• A generalization/specialization relationship will never have a realization in an object instance diagram.
• Rules
• Specializations inherit all properties
• Attributes
• Operations
• Associations
• Constraints
• Specialization may add new properties
• Specialization may override operations
• In generalization
• You accumulate properties as you go down the hierarchy
• Messages sent to an object instance may be executed by one of its super-classes
• In aggregations and compositions:
• You accumulate properties as you go up the hierarchy.
• Messages sent to an object may be delegated to one of its parts
• Abstract class
• An abstract class cannot have any direct object instances of its own.
• An abstract class may have abstract operations as well as concrete operations.
• An abstract operation in an abstract class is simply a specification of an operation.
• Interface
• In UML a class that has all abstract operations and no attributes is a special kind of classifier
• An interface specifies an abstract protocol to be “realized” by either a class or a subsystem
• If the interface is realized by a class, we use the triangle with a dashed line between the interface and the class.
• If the interface is realized by a package, the relationship is shown using the ball and socket notation.
• Classifier scope
• Attributes that are stored in the class rather than object instances are referred to as classifier scope variables.
• Classifier scope is indicated with underline font.
• Operations that are executed by the class rather than an object instance are called classifier scope operations.