csce 431 design n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
CSCE 431: Design PowerPoint Presentation
Download Presentation
CSCE 431: Design

Loading in 2 Seconds...

play fullscreen
1 / 54

CSCE 431: Design - PowerPoint PPT Presentation


  • 154 Views
  • Uploaded on

CSCE 431: Design. Some material from B . Meyer, M. Oriol , B. Schoeller at ETH Zürich. Outline. From requirements to design UML class diagrams From analysis classes to implementation classes More of UML. From Requirements to Design. S , D  R S = specification D = domain properties

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 'CSCE 431: Design' - candid


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
csce 431 design

CSCE 431: Design

Some material from B. Meyer, M. Oriol, B. Schoeller at ETH Zürich

outline
Outline
  • From requirements to design
  • UML class diagrams
  • From analysis classes to implementation classes
  • More of UML

CSCE 431 Design

from requirements to design
From Requirements to Design
  • S, DR
    • S= specification
    • D = domain properties
    • R = requirements
  • Come up with a design that satisfies S

CSCE 431 Design

semantic gap
Semantic Gap
  • A requirements specification
    • IEEE Std 830-1998, UML use cases,…

Semantic Gap

  • A complete description of the design

CSCE 431 Design

how to bridge the semantic gap
How to Bridge the Semantic Gap
  • Lots of advice available
  • But hard to give concrete methods or truly endorse most of it
  • Our advice focuses on going from OO analysis to OO design, and then implementation
  • Not all languages are OO, but OO seems to give a usable starting point for understanding systems and designs

CSCE 431 Design

role of object oriented analysis
Role of Object-Oriented Analysis
  • Analysis object model later refines to object model
  • Analysis object and dynamic models basis of system design

CSCE 431 Design

analysis
Analysis
  • Developers formalize requirements specification
    • Examine exceptional cases, boundary conditions
    • Clients engaged
  • OO Analysis
    • Developers build an object model of the application domain
    • Extend model with how actors and system interact with the application domain objects

CSCE 431 Design

trade offs
Trade-Offs
  • Create design that matches requirements as closely as possible?
  • Or reuse existing designs/implementations as much as possible, at expense of less direct match to requirements?
  • Create class hierarchy that closely matches problem domain?
  • Or create class hierarchy that supports extensibility, reuse, etc. and uses abstractions from implementation domain?

CSCE 431 Design

outline1
Outline
  • From requirements to design
  • UML class diagrams
  • From analysis classes to implementation classes
  • More of UML

CSCE 431 Design

basic uml models
Basic UML Models
  • Functional model
    • Functionality of the system from the user’s point of view
    • Use case diagrams
  • Object model
    • Structure of the system
      • objects, attributes, associations, operations
      • analysis object model → system design object model →design object model
  • Dynamic model
    • Describes the behavior of objects (states and state transitions, control and data flow)
    • Interaction diagrams
    • State machines
    • Activity diagrams

CSCE 431 Design

describing static structure of a system
Describing Static Structure of a System
  • What kind of objects are in the system
    • Representing classes
    • Representing relations between classes
  • Many notations exist
    • ER models
      • Purely about entities and their relations
    • UML class diagrams
      • Clear OO flavor, and a mapping to implementation using OO technologies

CSCE 431 Design

er diagrams
ER Diagrams

CSCE 431 Design

using uml class diagrams
Using UML Class Diagrams
  • Used
    • During requirements analysis to model application domain concepts (taxonomies)
    • During system design to model subsystems
    • During object design to specify classes in detail, including their methods and attributes
  • Thus used by both analysts and developers

CSCE 431 Design

object vs class
Object vs. Class
  • An object (instance): exactly one thing
  • Aclass describes a group of objects with similar properties

object diagram a graphical notation for modeling objects and their relationships

class diagram template for describing many instances of data; useful for taxonomies, patterns, and schemata

instance diagram a particular set of objects relating to each other; useful for discussing scenarios, test cases and examples

CSCE 431 Design

uml class diagrams features
UML Class Diagrams: Features
  • Classes: name, attributes, operations
  • Associations
    • navigation arrows
    • multiplicities
    • qualifications
    • roles
  • Association classes
  • Aggregations
  • Inheritance

CSCE 431 Design

outline2
Outline
  • From requirements to design
  • UML class diagrams
  • From analysis classes to implementation classes
  • More of UML

CSCE 431 Design

object modeling
Object Modeling
  • One of the motivations of object-orientation is that one can model reality with objects
  • Goal of object modeling: find important abstractions
    • Classes
  • Primarily to understand the system
  • Secondarily to serve as the blueprint of an implementation
    • Analysis class hierarchy does not have to match with the implementation class hierarchy
    • Some classes might be represented as relations, relations as classes, classes as attributes, attributes as classes, etc.
  • Perhaps a useful guideline: implementation should be a refinementof analysis classes

CSCE 431 Design

basic process of class design
Basic Process of Class Design
  • Iterate in some order, until convergence
    • Identify classes
    • Find attributes
    • Find operations
    • Find associations between classes
  • Above too vague
  • Some guidance exists

CSCE 431 Design

some methods
Some Methods
  • Abbott
    • R. Abbott, “Program design by informal English descriptions,” CACM, vol. 26, no. 11, 1983
    • Analyze textual descriptions of flows of events in scenarios and use cases
      • e.g., nouns are candidates for objects/classes
      • e.g., verbs are candidates for operations
  • Booch
    • Data flow analysis, followed by identifying concrete and abstract objects (e.g., from data stores)
  • Coad and Yourdon
    • Look for things or events remembered, devices, roles, sites, and organizational units
  • Shlaer-Mellor
    • Tangible entities, roles, incidents, interactions, and specifications

CSCE 431 Design

example abbott s technique
Example, Abbott’s Technique

The customer enters the

store to buy a toy. It has

to be a toy that his

daughter likes and it must

cost less than 50 euros.

He tries a videogame,

which uses a data glove

and a head-mounted

display. He likes it. An

assistant helps him. The

suitability of the game

depends on the age of the

child. His daughter is 3

years old. The assistant

recommends another type

of toy, a boardgame. The

customer buys the game

and leaves the store.

CSCE 431 Design

example abbott s technique1
Example, Abbott’s Technique

The customer enters the

store to buy a toy. It has

to be a toy that his

daughter likes and it must

cost less than 50 euros.

He tries a videogame,

which uses a data glove

and a head-mounted

display. He likes it. An

assistant helps him. The

suitability of the game

depends on the age of the

child. His daughter is 3

years old. The assistant

recommends another type

of toy, a boardgame. The

customer buys the game

and leaves the store.

CSCE 431 Design

class diagram
Class Diagram

The customer enters the

store to buy a toy. It has

to be a toy that his

daughter likes and it must

cost less than 50 euros.

He tries a videogame,

which uses a data glove

and a head-mounted

display. He likes it. An

assistant helps him. The

suitability of the game

depends on the age of the

child. His daughter is 3

years old. The assistant

recommends another type

of toy, a boardgame. The

customer buys the game

and leaves the store.

CSCE 431 Design

class diagram1
Class Diagram

The customer enters the

store to buy a toy. It has

to be a toy that his

daughter likes and it must

cost less than 50 euros.

He tries a videogame,

which uses a data glove

and a head-mounted

display. He likes it. An

assistant helps him. The

suitability of the game

depends on the age of the

child. His daughter is 3

years old. The assistant

recommends another type

of toy, a boardgame. The

customer buys the game

and leaves the store.

CSCE 431 Design

discussion
Discussion

Is the previous technique useful?

  • At best, use with caution
  • Nouns can
    • Suggest notions that do not yield classes
    • Fail to suggest notions that should yield classes
  • Explicit use of Abbott’s technique seems like a game/toy

CSCE 431 Design

many other criteria for identifying classes
Many Other Criteria for Identifying Classes
  • Existing designs, reuse
  • Domain knowledge and solution knowledge
  • General world knowledge
  • Extensibility, variation points
  • Find key abstract data types

CSCE 431 Design

no fool proof methodology
No Fool-Proof Methodology
  • Must settle for some hints and warnings

CSCE 431 Design

how directly to follow requirements specification
How Directly to Follow Requirements Specification?
  • Not too directly
  • Crucial abstractions may not be directly deducible from the requirements
  • Tends to suggest a specific, non-reusable solution
    • Implies we do not refactor code
  • Remember: good requirements do not prescribe a solution

CSCE 431 Design

what classes to reject
What Classes to Reject?
  • Abstract data types that are not semantically rich enough
    • Know the business domain and what is relevant to it
  • We concretize by observing shortcomings of grammar-based techniques:

The elevator will close its door before it moves to another floor.

  • Should door be a class?
  • Might just be a Boolean member of an elevator class
  • Might be important enough to warrant its own class
  • Clear that grammar games next to useless –question to ask:

Is door a separate data type with its own clearly identified operations, or are all the operations on doors already covered by operations on other data types, such as elevator?

CSCE 431 Design

what classes to reject1
What Classes to Reject?

The elevator will close its door before it moves to another floor.

  • Should floor be a class?
  • Likely integers is a sufficiently close abstraction
  • Possible reasons for a proper floor class
    • properties, such as floor access rights
    • integers support too many operations (what operations do not make sense?
      • What would it mean to add or multiply to floors?

CSCE 431 Design

what classes to accept
What Classes to Accept?

A database record must be created every time the elevator moves from one floor to another.

  • Important class move easily missed with grammar-based method

class move {

initial, final: floor // or int

record (database& d) { . . . }

}

CSCE 431 Design

what classes to reject2
What Classes to Reject?
  • Mixed abstractions
    • E.g., MFC’s coordinate functions tied to DCs
    • Should be split into several classes, one per abstraction
  • Premature classification
    • “taxomania”
    • Use “ADT view”: a new class should add or modify a feature, or strengthen the invariant
  • Known examples of bad/poor class choices for the specific domain
    • Antipatterns – commonly used, but ineffective patterns

CSCE 431 Design

other danger signals
Other Danger Signals
  • Class with a verb name (infinitive or imperative)
    • Perhaps better modeled as a routine
  • Class described as “performing something”
    • May not be a proper data abstraction
  • Class with a single public routine
    • Maybe again better modeled as a routine
    • Using objects as lambdas useful, but such classes not likely to appear during analysis
  • Class with no routines
    • Maybe some routines missing, or maybe not an ADT at all

CSCE 431 Design

class elicitation principle
Class Elicitation Principle
  • Class elicitation is a dual process:
    • class suggestion
    • class rejection

CSCE 431 Design

meyer s ideal class typical properties
Meyer’s “Ideal Class” Typical Properties
  • Clearly associated abstraction, which can be described as a data abstraction (or abstract machine)
  • Class name is a noun or adjective, adequately characterizing the abstraction
  • Class represents set of possible run-time objects - its instances (some classes have only one instance during an execution)
  • Several queries available for instance properties
  • Several commands available to change instance state (in some cases, instead of commands there are functions producing objects of the same type, e.g. integer operations)
  • Abstract properties can be stated, (preferably formally, describing: how the results of the various queries relate to each other (this will yield the invariant); under what conditions features are applicable (preconditions); how command execution affects query results (postconditions).

CSCE 431 Design

what to consider
What to Consider?
  • Analysis classes
    • Belong to the problem space
    • Describe data abstractions directly drawn from the domain model
  • Design classes
    • Belong to the solution space
    • Describe architectural choices
  • Implementation classes
    • Belong to the solution space
    • Describe data abstractions introduced for the internal needs of the algorithms

CSCE 431 Design

finding the design classes
Finding the Design Classes
  • Understand the importance of reuse: beware of the NIH (Not Invented Here) syndrome
  • Reuse previous known designs in the same domain
    • Avoid bugs!
  • Know standard design patterns
    • Avoid reinvention!
  • Consider describing abstractions as “machines” rather than “objects”

CSCE 431 Design

finding the implementation classes
Finding the Implementation Classes
  • Reuse!
    • Know and use the classical data structures and algorithms
    • Know and use existing libraries of your language
      • Standard libraries
      • Company/group libraries
  • A waste to write your own string, array, tree, … class

CSCE 431 Design

different kinds of objects
Different Kinds of Objects
  • Often the following categories can be identified
    • Suggested in: Jacobson, Booch, Rumbaugh: The Unified Software Development Process. Addison-Wesley, 1999
  • Entity objects
    • Represent the persistent information tracked by the system
    • Application domain objects, also called “Business objects”
  • Boundary objects
    • Represent the interaction between the user and the system
  • Control objects
    • Represent the control tasks performed by the system
  • Somewhat related to a model-view-controller architecture

CSCE 431 Design

object kinds in digital watch
Object Kinds in Digital Watch

Year

Button

Entity Objects Control Objects Boundary Objects

ChangeDate

Month

LCDDisplay

Day

CSCE 431 Design

identifying entity objects
Identifying Entity Objects
  • Recurring nouns in requirements
  • Real-world entities that system must track
  • Real-world processes that system must track
  • Data sources or sinks

CSCE 431 Design

identifying boundary objects
Identifying Boundary Objects
  • Boundary objects collect information from user
  • Boundary objects translate information into format for entity and control objects
  • User interface controls to initiate actions
  • Forms to enter data
  • Messages the system uses to respond

CSCE 431 Design

identifying control objects
Identifying Control Objects
  • Control objects coordinate boundary and entity objects
  • Control objects do not have a concrete counterpart in the real world
  • Identify one control object per business task

CSCE 431 Design

outline3
Outline
  • From requirements to design
  • UML class diagrams
  • From analysis classes to implementation classes
  • More of UML

CSCE 431 Design

sequence diagrams
Sequence Diagrams
  • Ties use cases with objects
  • Shows how behavior of use case distributed among its participating objects
  • More concise (and possibly more precise) than textual use case descriptions

CSCE 431 Design

sequence diagrams notation
Sequence Diagrams: Notation
  • Each column represents an object
  • Horizontal arrows are messages or stimuli
  • Vertical rectangle is an activation of an operation
    • Length represents time of being active
    • Triggered by a message
    • Messages can originate from operations
  • Time proceeds from top to bottom
  • Lifetime also depicted
    • Objects on top row exist from start
    • Other objects created with «create» messages
    • Vertical dashed line expresses object’s life time
      • Time span an object can receive messages
    • Cross depicts destruction

CSCE 431 Design

sequence diagram conventions
Sequence Diagram Conventions
  • First column: initiating actor
  • Second column: boundary object
  • Third column: control object managing the rest of the use case
  • Control objects created by boundary objects
  • Boundary objects created by control objects
  • Entity objects accessed by control and boundary objects
  • Entity objects never access control or boundary objects
    • Entity objects stay reusable across use cases

CSCE 431 Design

example
Example

CSCE 431 Design

example cont
Example (cont.)

CSCE 431 Design

state machine diagrams
State Machine Diagrams
  • State machines represent a system’s behavior from a single object’s perspective
  • (Sequence diagrams represent a system’s behavior from a single use case’s perspective)
  • Cross-checking (which actions trigger which transitions) between both views useful
    • Can reveal new use cases
    • Can reveal missing states
    • Can reveal ambiguities, incoherencies

CSCE 431 Design

state machine diagrams notation
State Machine Diagrams: Notation
  • Largely based on Harel’sstatecharts(1987)
  • Exactly like finite state machines, but features added to keep presentation manageable
  • Not all states need to be shown simultaneously
  • Can focus on one aspect of state independent of others
  • Notation for nesting states and state machines (OR states)
  • Orthogonal regions (AND states)
  • Notation for triggers and actions
  • Entry and exit actions
  • Internal transitions

CSCE 431 Design

example1
Example

CSCE 431 Design

statechart usage
Statechart Usage
  • Understanding
    • What is the sequence of states for a particular sequence of events?
  • Model checking
    • Is it possible for the machine to get into an erroneous state?
    • This is answered by exhaustively exploring all possible paths from a start state

CSCE 431 Design

more uml to learn
More UML to Learn
  • More on statecharts
    • Guard conditions and actions
  • Object diagrams
    • Like class diagrams, but snapshots of objects
  • Collaboration diagrams
    • Like sequence diagrams, but emphasis on structure instead of timing
  • Activity diagrams
    • Show flow of data and control in system
    • Arrows represent data between activities (boxes)
  • Component diagrams
    • Show system organization and dependencies
  • Deployment diagram
    • Show how components map to processing nodes
  • Extending UML
    • Stereotypes

CSCE 431 Design