chapter 1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Chapter 1 PowerPoint Presentation
Download Presentation
Chapter 1

Loading in 2 Seconds...

play fullscreen
1 / 23

Chapter 1 - PowerPoint PPT Presentation


  • 164 Views
  • Uploaded on

Chapter 1. Object Oriented Analysis and Design. UML, Patterns, and Object-Oriented Analysis and Design. The essential skills for the creation of well-designed, robust and maintainable software systems using object technology: More than just knowing an OOPL or an OO CASE tool;

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Chapter 1' - chuong


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
chapter 1
Chapter 1

Object Oriented Analysis and Design

uml patterns and object oriented analysis and design
UML, Patterns, and Object-Oriented Analysis and Design
  • The essential skills for the creation of well-designed, robust and maintainable software systems using object technology:
    • More than just knowing an OOPL or an OO CASE tool;
    • Must know how to “think in objects”
  • UML : Unified Modeling Language. A very large set of notations (mostly diagrammatic):
    • Useful for expressing and discussing OOA & D decisions
what is ood
What is OOD?
  • OOD is mostly about assigning responsibilities to classes:
    • How should objects interact?
    • What classes should do what?
    • We will use responsibility-driven design to assist with this task
  • To help us improve our designs, we use Design Patterns:
    • They are named problem-solution formulas that codify exemplary design principles
book approach
Book Approach
  • Case Studies show how to apply UML and patterns during OOAD within an agile approach to the Unified Process
  • Requirements analysis will be started using use cases:
    • Trying to discover “what” we must develop
  • There are many potential SWE activities from requirements through to implementation:
    • We will use an agile (light, flexible) version of the Unified Process (UP) : an iterative development process.
    • See Fig 1.1 for range of topics and skills covered.
topics and skills covered

OOA & D

OO Patterns

UML notation

Topics and Skills

Principles and

Requirements

guidelines

analysis

Iterative

development with

an agile Unified

Process

Topics and Skills Covered

Fig 1.1

assigning responsibilities
Assigning Responsibilities
  • Object-oriented analysis and design involves assigning responsibilities to software objects.
    • The link between describing what we want and how it will be realized.
    • Given a responsibility (e.g. which class will handle player’s personal information?) many choices will be available, but not all lead to a good overall design; good responsibility assignment leads to better design.
    • Larman identifies 9 fundamental OOD patterns (GRASP : General Responsibility Assignment Software Patterns or Principles)
    • We will also discuss the GOF (Gang of Four) patterns
what is analysis and design
What is Analysis and Design?

Analysis (or requirements analysis) involves studying the problem to be solved. It identifies what the problem is without addressing how it will be solved.

Design is the creative process that transforms a problem into a solution. It identifies how the problem will be solved. It is a conceptual solution rather than an implementation.

what is ooa d
What is OOA&D?
  • In essence, to consider a problem domain and logical solution from the perspective of objects (things, concepts, or entities)
  • OOA: emphasis on finding and describing the objects in the problem domain
  • OOD: emphasis on defining logical software objects and how they should collaborate (via method calls) to fulfill the requirements
  • OOP: commitment to code.
consider a flight information system
Consider a flight information system:
  • OOA : Finding and defining the objects or concepts:
    • Plane, Flight, Pilot etc;
  • OOD : Assigning responsibilities to those objects and determining how they collaborate:
    • a Plane object must have a tailNumber attribute and a getFlightHistory method;
  • OOP : Implementing the design in code:
    • e.g. a Plane class in Java.
ex cont

2

visualization of

Plane

1

domain concept

domain concept

tailNumber

public class Plane

3

representation in an

{

private String tailNumber

;

object

-

oriented

programming language

public List getFlightHistory

()

{

...

}

}

Ex. (Cont.)

Fig 1.2 Object-orientation revolves around objects.

a short example a dice game
A Short Example: A Dice Game
  • In this dice game: a player rolls two dice, if the total is seven he/she wins; otherwise he/she loses.
  • For this example, we will utilize Four Steps:
  • 1. Defining Use Cases:
  • 2. Defining a Domain Model
  • 3. Defining Interaction Diagrams
  • 4. Defining Design Class Diagrams
1 defining use cases
1.Defining Use Cases:
  • Understanding the requirements includes first understanding the domain processes and the external environment (external actors who participate in processes).
    • Use Case: Play a Game

Actors: Player

Description: Player requests to roll the dice. System presents results. If the dice face value totals seven, player wins; otherwise player loses.

2 defining a domain model
2. Defining a Domain Model
  • A decomposition of the problem domain involves identifying the important concepts, attributes and associations in the domain.
  • The conceptual model is not a description of software components; it represents concepts in the real-world problem domain.
slide14
The Conceptual Model

Fig 1.3 Partial domain model of the dice game.

3 defining interaction diagrams
3. Defining Interaction Diagrams
  • The next step in in OOD is allocating responsibilities to objects and illustrating how they interact via messages, expressed in sequence diagrams.
  • Sequence diagrams show the flow of messages between instances and the invocation of methods.
  • In our EX, a simulation in software of the dice game
  • Fig 1.4 illustrates the essential step of playing by sending messages to instances of the Die class.
  • Note that in the real world a player rolls the dice, in the software design the DiceGame object rolls the dice (ie, sends messages to the Die objects)
4 defining design class diagrams
4. Defining Design Class Diagrams
  • What are the methods of a class?
  • How do objects connect to other objects?
  • Inspect the sequence diagrams (dynamic view) for the necessary connections between objects and the methods that each software class must define
  • Add this information to a design class diagram (a static view).
  • Since a play message is sent to the DiceGame instance, the DiceGame class requires a play method, while the Die class requires a roll and getFaceValue method. See Fig 1.5.
  • Design class diagrams describe software components.
slide18
The Resulting Design Class Diagram

Fig 1.5 Partial design class diagram

slide19
Summary of the Dice Game Example
  • A very simple example : gives an overview of the steps and artifacts in OOA&D
oo vs function oriented a d
OO vs Function-Oriented A&D
  • Prior to OOA&D structured analysis and design was popular : decomposition of a problem by function or process resulting in a hierarchical breakdown of processes rather than by objects
  • OOA&D : emphasis on decomposing a problem space by objects rather than functions
  • The boundary between OOA and OOD is fuzzy (even more so than in traditional SWE):
    • There is a difference between investigation (analysis) and solution (design)
    • During analysis we emphasize understanding the problem while deferring issues related to the solution, performance, and so on to the design.
slide21
The Unified Modeling Language
  • A language for specifying, visualising and constructing the artifacts of software systems
  • A de facto and de jure standard; We focus on diagrams that are used frequently:
    • Refer to the UML 2.0 standard (2003) for the details of the language.
  • Case tool support is excellent.
  • The authors of the UML also defined a preferred development process (the Unified Process) to work with the UML.
slide22
Class and Terminology
  • The term ‘class’ is used a lot, but it can have a precise meaning depending on the context:
    • Within OOA, developing a Domain Model via a domain diagram, classes are called domain concepts or conceptual classes;
    • Within OOD, developing a Design Model via a design diagram, classes are called design classes or software classes;
    • Within OOP, developing an implementation model via code in an OOPL, classes are called implementation classes.
slide23
Conclusion
  • We will learn how to apply OOA&D to a project using the UML and within an agile software development process.
  • Resources:
    • www.omg.org (the Object Management Group)
    • www.uml.org (the Unified Modeling Language)
  • Questions?