0% found this document useful (0 votes)
28 views

Chapter 1 Introduction

This document provides an introduction to object-oriented analysis and design (OOAD) and the Unified Modeling Language (UML). It outlines the key steps in OOAD, including defining use cases, creating a domain model, assigning object responsibilities, drawing interaction diagrams, and defining design class diagrams. It discusses three perspectives for applying UML - conceptual, specification, and implementation - and how the meaning of "class" differs across these perspectives. Visual modeling with UML helps explore relationships between elements and see the big picture.

Uploaded by

mlkssurvei
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
28 views

Chapter 1 Introduction

This document provides an introduction to object-oriented analysis and design (OOAD) and the Unified Modeling Language (UML). It outlines the key steps in OOAD, including defining use cases, creating a domain model, assigning object responsibilities, drawing interaction diagrams, and defining design class diagrams. It discusses three perspectives for applying UML - conceptual, specification, and implementation - and how the meaning of "class" differs across these perspectives. Visual modeling with UML helps explore relationships between elements and see the big picture.

Uploaded by

mlkssurvei
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 38

INTRODUCTION

What will you learns??


• Topic and skill covered
The most important learning goal?
• A critical ability in OO development is to skillfully assign
responsibilities to software objects
• Nine fundamental principles in object design and reponsibilitiy
assignment are presented and applied
• They are organized in elearning aid called GRASP of principles with
names such as Information Expert and Creator.
What is a Analysis and Design ?
• Analysis emphasizes an investigation of the problem and
requirements, rather than a solution.
• “analysis” is a broad term, best qualified, as in requirements analysis
(an investigation of the requirements) or object- oriented analysis (an
investigation of the domain objects)
• Focus on “What” the system must do
• Can be summarized as “Do the right thing”.
What id Analysis and Design?
• Design emphasizes a conceptual solution (in software and hardware)
that fulfills the requirements, rather than its implementation
• Design ideas often exclude low level or “obvious” details obvious to
intended consumers.
• Ultimately, design can be implemented, and the implementation (such ad
code) expresses the true and complete realized design.
• As with analysis, the term is the best qualified, as in object oriented
design or database design.
• Focus on “how” the system will do it
• Can be summarized as “do the thing right”.
What is Analysis and Design?
• Ca be summarizes as these phases:
• Do the right thing (analysis)
• Do the thing right (design)
What is Object-Oriented Analysis and
Design?
What is object oriented analysis and design?
• During object-oriented analysis there is an emphasis on finding and
describing the objects or concepts in the problem domain.
• For example, in the case of the flight information system, some of the
concepts include Plane, Flight, and Pilot.
hat is Object-Oriented Analysis and Design?
• During object-oriented design (or simply, object design) there is an
emphasis on defining software objects and how they collaborate to
fulfill the requirements.
• object-oriented design For example, a Plane software object may have
a tailNumber attribute and a getFlightHistory method
A sort example
• a simple example, a "dice game" in which software simulates a player
rolling two dice.
• If the total is seven, they win; otherwise, they lose.
Key steps
Define Use Cases
• Requirements analysis may include stories or scenarios of how people
use the application; these can be written as use cases
• Use cases are nor an object – oriented artifact. The are simply written
stories
• Plat a dice game: player request to roll the dice. System presents
result: if the dice face value totals seven, player wins; otherwise,
player loses
Key steps
Define a domain model
• Object-oriented analysis is concerned with creating a description of
the domain from the perspective of objects.
• There is an identification of the concepts, attributes, and associations
that are considered significant.
• The result can be expressed in a domain model that shows the
significant domain concepts or objects.
• For example, a partial domain model is shown in the next slide
Partial domain model of the dice game
• Note that a domain model is not a description of software objects; it
is a visualization of the concepts or mental models of a real-world
domain.
• Thus, it has also been called a conceptual object model.
Key steps
Assign Object Responsibilities and Draw
Interaction Diagrams
• Object-oriented design is concerned with defining software objects,
their responsibilities and collaborations.
• A common notation to illustrate these collaborations is the sequence
diagram (a kind of UML interaction diagram).
• It shows the flow of messages between software objects, and thus
the invocation of methods
Assign Object Responsibilities and Draw
Interaction Diagrams
• For example, the sequence diagram in the next slide illustrates an OO
software design, by sending messages to instances of the DiceGame
and Dice classes.
• Note this illustrates a common real-world way the UML is applied: by
sketching on a whiteboard.
Sequence diagram illustrating messege
between software objects
• Notice that although in the real world a player rolls the dice, in the
software design the DiceGame object "rolls" the dice (that is, sends
messages to Dice objects).
• Software object designs and programs do take some inspiration from
real-world domains, but they are not direct models or simulations of
the real world.
Key steps
Define Design Class Diagrams
• In addition to a dynamic view of collaborating objects shown in
interaction diagrams, a static view of the class definitions is usefully
shown with a design class diagram.
• This illustrates the attributes and methods of the classes.
• For example, in the dice game, an inspection of the sequence diagram
leads to the partial design class diagram shown in the next slide.
• Since a play message is sent to a DiceGame object, the DiceGame
class requires a play method, while class Dice requires a roll and
getFaceValue method.
Partial design class diagram
• In contrast to the domain model showing real- world classes, this
diagram shows software classes.
• Notice that although this design class diagram is not the same as the
domain model, some class names and content are similar.
• In this way, OO designs and languages can support a lower
representational gap between the software components and our
mental models of a domain. That improves comprehension.
What is the UML?
• The Unified Modeling Language is a visual language for specifying,
constructing and documenting the artifacts of systems.
• The word visual in the definition is a key point. The UML is the de
facto standard diagramming notation for drawing or presenting
pictures (with some text) related to software primarily OO software.
• This class doesn't cover all minute aspects of the UML, only a large
body of notation
hree Ways to Apply UML
1. UML as sketch Informal and incomplete diagrams (often hand
sketched on whiteboards) created to explore difficult parts of the
problem or solution space, exploiting the power of visual languages.
2. UML as blueprint Relatively detailed design diagrams used either for
1. reverse engineering to visualize and better understanding existing code in
UML diagrams, or for
2. code generation (forward engineering).
UML as blueprint
• If reverse engineering, a UML tool reads the source or binaries and
generates (typically) UML package, class, and sequence diagrams.
These "blueprints" can help the reader understand the big-picture
elements, structure, and collaborations.
• Before programming, some detailed diagrams can provide guidance
for code generation (e.g., in Java), either manually or automatically
with a tool. It's common that the diagrams are used for some code,
and other code is filled in by a developer while coding (perhaps also
applying UML sketching).
3. UML as programming language
• Complete executable specification of a software system in UML.
• Executable code will be automatically generated, but is not normally
seen or modified by developers; one works only in the UML
"programming language."
• This use of UML requires a practical way to diagram all behavior or
logic (probably using interaction or state diagrams), and is still under
development in terms of theory, tool robustness and usability
Three perspectives to apply UML
• The UML describes raw diagram types, such as class diagrams and
sequence diagrams.
• It does not superimpose a modeling perspective on these.
• For example, the same UML class diagram notation can be used to
draw pictures of concepts in the real world or software classes in Java
Three Perspectives to Apply UML
1. Conceptual perspective the diagrams are interpreted as describing
things in a situation of the real world or domain of interest.
2. Specification (software) perspective the diagrams (using the same
notation as in the conceptual perspective) describe software
abstractions or components with specifications and interfaces, but
no commitment to a particular implementation (for example, not
specifically a class in C# or Java).
3. Implementation (software) perspective the diagrams describe
software implementations in a particular technology (such as Java).
Figure Different Perspective with UML
The meaning of “Class” in Different
Perspectives
• In the raw UML, the rectangular boxes shown in Figure 1.6 are called
classes, but this term encompasses a variety of phenomena physical
things, abstract concepts, software things, events, and so forth.
• A method superimposes alternative terminology on top of the raw UML.
• For example, in the UP, when the UML boxes are drawn in the Domain
Model, they are called domain concepts or conceptual classes; the
Domain Model shows a conceptual perspective.
• In the UP, when UML boxes are drawn in the Design Model, they are
called design classes; the Design Model shows a specification or
implementation perspective, as desired by the modeler.
The Meaning of "Class" in Different
Perspectives
• Conceptual class real-world concept or thing. A conceptual or
essential perspective. The UP Domain Model contains conceptual
classes.
• Software class a class representing a specification or implementation
perspective of a software component, regardless of the process or
method.
• Implementation class a class implemented in a specific OO language
such as Java.
Visual Modeling is a Good Thing
• Diagrams help us see or explore more of the big picture and
relationships between analysis or software elements, while allowing
us to ignore or hide uninteresting details.
• That's the simple and essential value of the UML or any diagramming
language
Recomended Resources
• A very readable and popular summary of essential UML notation is UML Distilled by Martin Fowler. Highly
recommended; Fowler has written many useful books, with a practical and "agile" attitude.
• For a detailed discussion of UML notation, The Unified Modeling Language Reference Manual by Rumbaugh is
worthwhile. Note that this text isn't meant for learning how to do object modeling or OOA/D it's a UML notation
reference.
• For the definitive description of the current version of the UML, see the on-line UML Infrastructure Specification
and UML Superstructure Specification at www.uml.org or www.omg.org. www.uml.orgwww.omg.org
• Visual UML modeling in an agile modeling spirit is described in Agile Modeling by Scott Ambler. See also
www.agilemodeling.com.www.agilemodeling.com
• There is a large collection of links to OOA/D methods at www.cetus-links.org and www.iturls.com (the large English
"Software Engineering" subsection, rather than the Chinese section).www.cetus-links.org www.iturls.com
• There are many books on software patterns, but the seminal classic is Design Patterns by Gamma, Helm, Johnson,
and Vlissides. It is truly required reading for those studying object design. However, it is not an introductory text and
is best read after one is comfortable with the fundamentals of object design and programming. See also
www.hillside.net and www.iturls.com (the English "Software Engineering" subsection) for links to many pattern sites
Reference
• Applying UML and Patterns: An Introduction to Object-Oriented
Analysis and Design and Iterative Development (3rd Edition) by Craig
LarmanCraig Larman
Thank you

You might also like