3. Objectives
• Compare and contrast analysis and design
• Define object-oriented analysis and design
(OOA/D)
• Illustration of some brief example
4. Applying UML and patterns in OOA/D
• Object oriented approach will be used for creation of well-
designed, robust, and maintainable software using object
technologies and languages such as Java,C++, Smalltalk,
and C#.
• Knowing some object-oriented language is not enough,
thinking in objects is critical and necessary.
• Here in this class, we will apply Unified Modeling
Language(UML), patterns and Unified Process for OOA/D.
– Such as how to assign responsibilities to objects,
– Knowing frequently used UML notation,
– and common design patterns
• UML is not a OOA/D method, it is simply a notation in the
service of doing OOA/D.
5. Applying patterns and assigning
responsibilities
• What we will learn in this course while applying UML
is:
– How should responsibilities be allocated to classes of
objects?
– How should objects interact?
– What classes should do what?
– how to apply patterns, supports quicker learning and
skillful use of these fundamental object design.
• OOA/D (and all software design) is strongly related to
the prerequisite activity of requirements analysis,
which includes writing use cases.
6. Cont…
• You will be capable of learning:
– Apply principles and patterns to create better
object designs.
– Follow a set of common activities in analysis and
design, based on the Unified Process as an
example.
– Create frequently used diagrams in the UML
notation.
8. Assigning Responsibilities
• A critical, fundamental ability in OOA/D is to
skillfully assign responsibilities to software
components.
– It influences the robustness, maintainability, and
reusability of software components.
• Nine fundamental principles in object design
and responsibility assignment are presented
and applied using GRASP patterns.
9. What is Analysis and Design
• Analysis:
– It emphasizes an investigation of the problem and
requirements, rather than a solution.
– Requirements analysis
• An investigation of the requirements
– Object analysis
• An investigation of the domain objects.
• Design:
– It emphasizes a conceptual solution that fulfills the
requirements, rather than its implementation.
• do the right thing (analysis), and do the thing right
(design).
10. Object-oriented Analysis
• It emphasizes on finding and describing the
objects—or concepts—in the problem
domain.
• Example:
– Considering the example of Library Information
System, some of the concepts are Book, Library
and Patron.
11. Object-Oriented Design
• OOD emphasizes on defining software objects
and how they collaborate to fulfill the
requirements.
• Example:
– In the library system, a Book software object may
have a title attribute and a getChapter method.
• During implementation or object-oriented
programming, design objects are
implemented, such as a Book class in Java.
13. Example
• A simple example is used to present and discuss
some of the key steps and diagrams.
• Dice game:
– A player rolls two die. If the total is seven, they win;
otherwise, they lose.
• Using this example we will
– Define Use Cases
– Define a Domain Model
– Define Interaction Diagram
– Define Design Class Diagram
14. Define Use Cases
• Requirements analysis may include a description of
related domain processes; these can be written as use
cases.
• Use cases are not an object-oriented artifact, they are
simply written stories.
• It is a very popular tool of requirement analysis and is
an important part of unified process. That is why we
will first define Use cases.
• Play a Dice Game :
A player picks up and rolls the dice. If the dice face
value total seven, they win; otherwise, they lose.
The above is a brief version of a use case.
15. Define a Domain Model
• Object-oriented analysis is concerned with creating a
description of the domain from the perspective of
classification by objects.
• Domain Model involves
– identification of the concepts,
– attributes,
– and associations.
• Domain model is illustrated in a set of diagrams that
show domain concepts or objects.
• domain model is not a description of software objects;
it is a visualization of concepts in the real-world
domain
16. Domain Model for Dice game
• The above figure is showing partial domain model of the
dice game.
17. Define Interaction Diagrams
• Object-oriented design is concerned with defining
software objects and their collaborations.
• A common notation to illustrate these
collaborations is the interaction diagram.
• It shows the flow of messages between software
objects, and thus the invocation of methods.
• It shows the dynamic view of collaborating
objects.
18. Interaction diagram illustrating
messages between software objects
• It illustrates the essential step of playing, by sending
messages to instances of the DiceGame and Die classes
19. Cont…
• In the figure(on the previous slide)a play
message is sent to a DiceGame object.
• The DiceGame class requires a play method,
while class Die requires a roll and
getFaceValue method.
20. Define Design Class Diagram
• Design Class Diagram is useful for creating static
view of the class definitions.
• This illustrates the attributes and methods of
the classes.
• For example, in the dice game, an inspection of
the interaction diagram leads to the partial
design class diagram shown in Figure below.
21. Cont…
• In contrast to the domain model, this diagram
does not illustrate real-world concepts; rather,
it shows software classes.
22. The UML
• The Unified Modeling Language (UML) is a
language for specifying, visualizing,
constructing, and documenting the artifacts of
software systems, as well as for business
modeling and other non-software systems.
• The UML has emerged as the de facto and de
jure standard diagramming notation for
object-oriented modeling.
