Escolar Documentos
Profissional Documentos
Cultura Documentos
The intent of object oriented analysis is to define all classes that are relevant to the
problem to be solved. To accomplish this ,a number of tasks must occur.
1.Basic user requirements must be communicated between the customer and the
software engineer
2.Classes must be identified
3. A class hierarchy is defined
Structured Analysis
One view of analysis modeling called structured analysis considers data and the
processes that transform the data as separate entities.Data objects are modeled in a
way that defines their attributes and relationships. processes that manipulate data
are modeled in a manner that shows how they transform data as data objects flow
through the system
.Class based modeling.
.Classes and objects.
• They are the main building blocks on an OOD. During analysis we view an
object as an entity in the problem domain that have clearly defined boundaries
and behavior. Objects represent runtime entities in an OO system. They occupy
space in memory that keeps its state and is operated on by the defined
operations on the object.
A class defines possible set of objects.
A class can be considered a template that specifies the properties for objects of the
class
1.an interface that defines which parts of an object of a class can be accessed from
outside and how.
2.A class body that implements the operations in the interface
3.Instance variables that contain the state of an object of that class.
serve dishes
read
prepare
Bill
Bill
Pay bill
• The main reason for performing dynamic analysis is that scenarios and
sequence diagrams extend the initial design.
• It is easy to cross the boundary line between specifications (what) and design
how).
• The transition from object oriented analysis to object oriented design is more
smoother than the transition in the classical paradigm from analysis phase
to design phase.
• In classical paradigm the initial task of the design phase is to decompose the
product into modules. In contrast the classes , the modules of object oriented
design workflow are extracted during the object oriented analysis workflow
ready for refinement ,during the object oriented design workflow.
• Class Diagrams.
Illuminated ::
Boolean
Communicates
with Communicates with
Elevator class
Detailed design
• Transaction analysis
• In the case of systems where there are many different sets of possible
actions and the actions to be performed depend on the input command
specified .The module splitting the input is called transaction center. one of
the standard ways to convert a data flow diagram into a structure chart is to
have an input module that gets the analyzed transaction and a dispatch
module that invokes the modules for the different transactions.
•
b
T
Transactio
c
n Center
Transaction
Analysis
• User interface classes :define all abstractions that are necessary for human
computer interaction (HCI)
• Business domain classes: They are often refinements of the analysis classes
defined earlier .The classes identify the attributes and services that are
required to implement some element of the business domain
• Process classes implement lower level business abstractions required to fully
manage the business domain classes
• Persistent classes represent data stores that will persist beyond the execution
of the software.
• System classes implement software management and control functions that
enable the system to operate and communicate with the outside world.
• The basic goal here is to promote building of systems that are easily
modifiable as modification and change happen frequently and
• a design that cannot easily accommodate change will result in systems that
will die fast and will not be able to easily adapt to the changing world.
• In the above design the client directly calls the methods on printer object for
printing something. Now if the system has to be enhanced to allow another
printer to be used by the client .under this design to implement this change a
new class printer2 will have to be created and the code of the client class will
have to be changed to allow using object of type printer2 as well.
Design that supports open closed
principle
0..n 0..n
client printer
Printer 1 Printer 2
In the above design using open closed principle we create an abstract class
printer that defines the interface of a printer and specifies all methods a printer
object should support.printer1 is implemented as a specialization of this class.
When printer 2 is added it is added as a subclass of type printer.
• 1.The public interface of a class should only contain the operations defined
on the class. That is the data definitions should not be a part of the public
interface.
• Only the operations that form the interface for a class that is the ones needed
by the users of the class should be the public members of the class
• 3.an instance of a class should not send messages directly to components of
another class.That is if there is a class C defined inside a class B , then objects
of a class A should not directly perform operations on objects of class C
• 4.Each operation defined on a class should be such that it either modifies or
accesses some data defined in the class
• 5.A class should be dependent on as few classes as possible.
• 6.The interaction between two classes should be explicit
• 7.Each subclass should be defined as a specialization of the super class
• 8.The number of arguments and size of methods should be kept small
Coupling in OO Systems
• In OO systems, basic modules are classes, which are richer than fns
• OO Systems have three types of coupling
– Interaction coupling
– Component coupling
– Inheritance coupling
Coupling in OO - Interaction
• Interaction coupling occurs due to methods of a class invoking methods of
other classes
– Like calling of functions
– Worst form if methods directly access internal parts of other methods
– Still bad if methods directly manipulate variables of other classes
– Passing info through tmp vars is also bad
Coupling in OO …
• Least interaction coupling if methods communicate directly with parameters
– With least number of parameters
– With least amount of info being passed
– With only data being passed
• I.e. methods should pass the least amount of data, with least no of parms
Coupling in OO - Component
• Component coupling – when a class A has variables of another class C
– A has instance vars of C
– A has some parms of type C
– A has a method with a local var of type C
• When A is coupled with C, it is coupled with all subclasses of C as well
• Component coupling will generally imply the presence of interaction
coupling also
Coupling in OO - Inheritance
• Inheritance coupling – two classes are coupled if one is a subclass of other
• Worst form – when subclass modifies a signature of a method or deletes a
method
• Coupling is bad even when same signature but a changed implementation
• Least, when subclass only adds instance variables and methods but does not
modify any
Cohesion in OO Systems
• In OO, different types of cohesion is possible as classes are the modules
– Method cohesion
– Class cohesion
– Inheritance cohesion
• Method cohesion – why diff code elts are together in a method
– Like cohesion in functional modules; highest form is if each method
implements a clearly defined function with all elts contributing to
implementing this function
Cohesion in OO…
• Class cohesion – why diff attributes and methods are together in a class
– A class should represent a single concept with all elts contributing
towards it
– Whenever multiple concepts encapsulated, cohesion is not as high
– A symptom of multiple concepts – diff gps of methods accessing diff
subsets of attributes
Cohesion in OO…
• Inheritance cohesion – focuses on why classes are together in a hierarchy
– Two reasons for subclassing – generalization-specialization and reuse
– Cohesion is higher if the hierarchy is for providing generalization-
specialization