Object Oriented Analysis and Design - Lecture 5 - PowerPoint PPT Presentation

Loading...

PPT – Object Oriented Analysis and Design - Lecture 5 PowerPoint presentation | free to download - id: 64e925-ODQzO



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Object Oriented Analysis and Design - Lecture 5

Description:

Title: Object Oriented Analysis and Design - Lecture 5 Author: KIVANCD Description: RLSD 51011 KD Last modified by: KIVANCD Created Date: 9/12/2005 3:51:44 AM – PowerPoint PPT presentation

Number of Views:67
Avg rating:3.0/5.0
Date added: 11 February 2020
Slides: 54
Provided by: KIVA9
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Object Oriented Analysis and Design - Lecture 5


1
Chapter 10 Drawing System Sequence Diagrams
  • In theory, there is no difference between theory
    and practice.
  • But in practice, there is. - Jan L.A. van de
    Snepscheut
  • Objectives
  • Identify system events.
  • Create system sequence diagrams for use case
    scenarios

2
Fig 10.1 Sample UP artifact influence.
An SDD is a fast and easily created artifact that
illustrates i/o events related to systems under
discussion.
3
Iteration 1
  • First real development iteration.
  • The requirement work done during inception phase
    was to decide if the project was worth more
    serious investigation.
  • Before starting iteration 1 design work, further
    investigation of the problem domain is useful
    such as clarification of the input and output
    system events, related to the system.

4
SSD versus Sequence Diagram
  • A System Sequence Diagram (SSD) is an artifact
    that illustrates input and output events related
    to the system under discussion.
  • SSDs are typically associated with use-case
    realization in the logical view of system
    development.
  • System Sequence Diagrams should be done for the
    main success scenario of the use-case, and
    frequent and alternative scenarios.
  • Sequence Diagrams (Not System Sequence Diagrams)
    display object interactions arranged in time
    sequence.
  • Sequence Diagrams depict the temporal order of
    the events.

5
Sequence Diagrams
  • Sequence Diagrams depict the objects and classes
    involved in the scenario and the sequence of
    messages exchanged between the objects needed to
    carry out the functionality of the system.
  • The operations of the system in response to the
    events generated.
  • Sequence diagrams can be used to drive out
    testable user interface requirements.

6
System Sequence Diagrams
  • Use cases describe-
  • How actors interact with system
  • Typical course of events that external actors
    generate, and
  • The order of the events
  • For a particular scenario of use-case an SSD
    shows-
  • The external actors that interact directly with
    the system.
  • The System (as a black box).
  • The system events that the actors generate.
  • Note A software system basically reacts to three
    things
  • External events from actors
  • Timer events
  • Faults or exceptions

7
SSDSystem Behavior
  • is a description of what a system does, w/o
    explaining how it does it.
  • One part of that description is a SDD. Other
    parts include the use cases and system operation
    contracts.
  • System behaves as a Black Box.
  • Interior objects are not shown, as they would be
    on a Sequence Diagram.

8
Notation
  • Object Objects are instances of classes.
  • Object is represented as a rectangle which
    contains the name of the object underlined.
  • Because the system is instantiated, it is shown
    as an object.
  • Actor An Actor is modeled using the ubiquitous
    symbol, the stick figure.

Object1
System
actor1
9
Notation (2)
  • Lifeline The Lifeline identifies the existence
    of the object over time. The notation for a
    Lifeline is a vertical dotted line extending from
    an object.
  • Message Messages, modeled as horizontal arrows
    between Activations, indicate the communications
    between objects.

messageName(argument)
10
Fig 10.2 SSD for A Process Sale Scenario.
Note the events generated by cashier (actor)
below.
What SSD info must be put into Glossary?
11
Constructing a SSD from a Use Case
  • 1. Draw a line representing the system as a
    black box.
  • 2. Identify each actor that directly operates on
    the system. Draw a line for each such actor.
  • 3. From the use case, typical course of events
    text, identify the system (external) events that
    each actor generates. They will correspond to an
    entry in the right hand side of the typical use
    case. Illustrate them on the diagram.
  • 4. Optionally, include the use case text to the
    left of the diagram.

12
Fig 10.3 SSDs are derived from use cases they
show one scenario.
13
Fig 10.4 Choose event and operation names at an
abstract level.
System events should be expressed at the abstract
level of intention rather than in terms of the
physical input device.
14
Fig 10.5 SSD for a Play Monopoly Game scenario.
15
Chapter 11 Operation Contracts
  • When ideas fail, words come in very handy. -
    Johann Wolfgang von Goethe
  • Objectives
  • Define system operations.
  • Create contracts for system operations.

16
Fig 11.1 Sample UP artifact influence.
17
Fig 11.2 SDD. System operations handle input
system events.
Operation contracts may be defined for system
operations operations that the system as a
black box component offers in its public
interface.
18
Fig 13.8 System operations in the SSDs and in
terms of layers.
19
System Operations and the System Interface
  • Contracts may be defined for system operations
    operations that the system as a black box offers
    in its public interface to handle incoming system
    events. System operations can be identified by
    discovering these system events.
  • The entire set of system operations, across all
    use cases, defines the public system interface,
    viewing the system as a single component or
    class.
  • In the UML, the system as a whole can be
    represented as one object of a class named System.

20
Domain Model And Contracts
  • A Domain Model is a visual representation of
    conceptual classes or real-world objects in a
    domain of interest.
  • Contracts describe detailed system behavior in
    terms of state changes to objects in the Domain
    Model, after a system operation has executed.
  • Guideline Keep it Agile
  • In many, or even most software development
    projects, operation contracts may be unnecessary.
    For an agile process, use them only when
    necessary to add additional detail and
    understanding.

21
Example Contract enterItem
  • Contract Template
  • Operation Name Of operation, and
    parameters.
  • Cross References (optional) Use cases this can
    occur within.
  • Preconditions Noteworthy assumptions about the
    state of the system or objects in the Domain
    Model before execution of the operation.
  • Postconditions -The state of objects in the
    Domain Model after completion of the operation.
  • Contract CO2 enterItem
  • Operation enterItem(itemID ItemID,
    quantity integer)
  • Cross References Use Cases Process Sale
  • Preconditions There is a Sale Underway.
  • Postconditions - A SalesLineItem instance sli
    was created (instance creation) - sli was
    associated with the current Sale (association
    formed) - sli.quantity became quantity
    (attribute modification) - sli was associated
    with a ProductSpecification, based on
    itemID match (association formed)

22
Writing Contracts Leads to Domain Model Updates
  • New conceptual classes, attributes, or
    associations in the Domain Model are often
    discovered during contract writing.
  • Enhance the Domain Model as you make new
    discoveries while thinking through the operation
    contracts.

23
Why Contracts
  • Use cases are the primary mechanism in the UP to
    describe system behavior, and are usually
    sufficient.
  • However, sometimes a more detailed description of
    system behavior has value. Contracts for
    operations can help define system behavior.

24
Contracts vs. Use Cases
  • The use cases are the main repository of
    requirements for the project. They may provide
    most or all of the detail necessary to know what
    to do in the design.
  • If the details and complexity of required state
    changes are awkward to capture in use cases, then
    write operation contracts.
  • If developers can understand what to do based on
    the use cases and ongoing (verbal) collaboration
    with a subject matter expert, avoid writing
    contracts.
  • Operation contracts are uncommon. If a team is
    making contracts for every system operation
  • the use cases are poorly done, or
  • there is not enough collaboration or access to a
    subject matter expert, or
  • the team is doing too much unnecessary
    documentation.

25
Postconditions
  • The postconditions describe changes in the state
    of objects in the Domain Model.
  • Domain Model state changes include
  • instances created,
  • associations formed or broken,
  • and attributes changed.
  • Postconditions are not actions to be performed,
    during the operation rather, they are
    declarations about the Domain Model objects that
    are true when the operation has finished.

26
The Spirit of Postconditions The Stage and
Curtain
  • Express postconditions in the past tense, to
    emphasize they are declarations about a state
    change in the past.
  • (better) A SalesLineItem was created.
  • (worse) Create a SalesLineItem.
  • Think about postconditions using the following
    image
  • The system and its objects are presented on a
    theatre stage.
  • Before the operation, take a picture of the
    stage.
  • Close the curtains on the stage, and apply the
    system operation
  • Open the curtains and take a second picture.
  • Compare the before and after pictures, and
    express as postconditions the changes in the
    state of the stage (A SalesLineItem was created).

27
Guideline Writing Contracts
  • To make contracts
  • Identify system operations from the SSDs.
  • For system operations that are complex and
    perhaps subtle in their own results, or which are
    not clear in the use case, construct a contract.
  • To describe the postconditions, use - instance
    creation and deletion - attribute
    modification - associations formed and broken

28
The Most Common Mistake In Creating Contracts
  • The most common problem in creating contracts is
    forgetting to include the forming of
    associations.
  • Particularly, when new instances are created, it
    is very likely that associations to several
    objects need be established.
  • Dont forget to include all the associations
    formed and broken.

29
Contracts, Operations, and the UML
  • The UML formally defines operations. To quote
  • An operation is a specification of a
    transformation or query that an object may be
    called to execute RJB99
  • An operation is an abstraction, not an
    implementation. By contrast, a method (in the
    UML) is an implementation of an operation.
  • A UML operation has a signature (name and
    parameters), and also an operation specification,
    which describes the effects produced by executing
    the operation the postconditions.
  • A UML operation specification may not show an
    algorithm or solution, but only the state changes
    or effects of the operation.

30
Operation Contracts Within the UP
  • A pre- and postcondition contract is a well-known
    style to specify an operation. In UML, operations
    exist at many levels, from top level classes down
    to fine-grained classes.
  • Operation specification contracts for the top
    level classes are part of the Use-Case Model.
  • Phases
  • Inception Contracts are not needed during
    inception they are too detailed.
  • Elaboration If used at all, most contracts will
    be written during elaboration, when most use
    cases are written. Only write contracts for the
    most complex and subtle system operations.

31
Chapter 12 Requirements to Design - Iteratively
  • Hardware, n. The parts of a computer system
    that can be kicked. - anonymous
  • Objectives
  • Quickly motivate the transition to design
    activities.
  • Contrast the importance of object design skill
    versus UML notation knowledge.

32
Introduction
  • Following the UP guidelines, perhaps 10 of the
    requirements were investigated in inception, and
    a slightly deeper investigation was started in
    this first iteration of elaboration.
  • Now we shift our emphasis toward designing a
    solution for this iteration in terms of
    collaborating software objects.

33
Iteratively Do the Right Thing, Do the Thing
Right
  • The requirements and object-oriented analysis has
    focused on learning to do the right thing that
    is, understanding some of the outstanding goals
    for the Next-Gen POS, and related rules and
    constraints.
  • In iterative development, a transition from
    primarily a requirements focus to primarily a
    design and implementation focus will occur in
    each iteration.

34
Didnt That Take Weeks To Do? No, Not exactly.
  • When one is comfortable with the skills of use
    case writing, domain modeling, and so forth, the
    duration to do all the actual modeling that has
    been explored so far is realistically just a few
    days.
  • However that does not mean that only a few days
    have passed since the start of project. Many
    other activities such as proof-of-concept
    programming finding resources (people,software
    .) planning,setting up the environment could
    consume a few weeks of preparations.

35
On to Object Design
  • During object design, a logical solution based on
    the object-oriented paradigm is developed. The
    heart of this solution is the creation of
    interaction diagrams which illustrates how
    objects collaborate to fulfill the requirements.
  • After-or in parallel with-drawing interaction
    diagrams, (design) class diagrams can be drawn.
  • In practice,the creation of interaction and class
    diagram happens in parallel and synergistically,
    but their introduction in the textbook case study
    is linear for simplicity and clarity.

36
Importance of Object Design Skill vs UML Notation
skill
  • Drawing UML interaction diagrams is the
    reflection of making decisions about the object
    design.
  • The object design skills are what really matter,
    rather than knowing how to draw UML diagrams.
  • Fundamental object design requires knowledge of
  • Principles of responsibility assignment
  • Design patterns

37
Chapter 13 Logical Architecture and UML Package
Diagrams
  • 0x2B 0x2B. - Hamlet
  • Objectives
  • Introduce a logical architecture using layers.
  • Illustrate the logical architecture using UML
    package diagrams.

38
Fig 13.1 Sample UP artifact influence.
39
Example
Fig 13.2 Layers shown with UML package diagram
notation.
40
Definition Architecture
  • In software development, architecture is thought
    of as both noun and a verb.
  • As a noun, the architecture includes the
    organization and structure of the major elements
    of the system.
  • As a verb, architecture is part investigation and
    part design work.
  • Architectural investigation involves functional
    and non-functional requirements that have impact
    on system design.
  • Some of these are market trends, performance,
    cost and points of evolution.
  • Architectural Design is the resolution of these
    requirements in the design of software.

41
Definition Software Architecture
  • There are various forms of it. But the common
    theme is that it has to do with large scale-the
    Big Ideas in the forces, organization, styles,
    patterns, responsibilities, collaborations,
    connections and motivations of a system and major
    subsystems.

42
Architectural Dimension and Views in UP
  • The common dimensions are
  • The logical architecture, describes the system in
    terms of its conceptual organization in layers,
    packages, classes, interfaces and subsystems.
  • The deployment architecture, describes the system
    in terms of the allocation of process to
    processing unit and network configurations.
  • Architectural Layers are a logical view of the
    architecture
  • They are not a deployment view of elements to
    process.
  • Depending on platform, all layers could be
    deployed within the same process on same node OR
    across many computers.

43
Architectural Patterns and Pattern Categories
  • Architectural patterns Relates to large-scale
    design and typically applied during the early
    iterations (in elaboration phase).
  • Design patterns Relates to small and
    medium-scale design of objects and frameworks.
  • Idioms Relates to language or implementation-orie
    nted low-level design solutions.

44
Architectural Pattern Layers
  • A layer is a coarse grained grouping of classes
    packages or subsystems that has cohesive
    responsibility for a major aspect of the system.
  • Higher layers call upon the services of lower
    layers.
  • Strict layered vs. relaxed layered architectures
  • Idea behind Layer patterns
  • Organize the large-scale logical structure of a
    system into discrete layers of distinct, related
    responsibilities with a clean, cohesive
    separation of concerns such that the lower
    layers are low-level and general services, and
    the higher layers are more application specific.
  • Collaboration and coupling is from higher to
    lower layers.

45
UML Package Diagrams
  • UML Package Diagrams are often used to show the
    contents of components, which are often packages
    in the Java sense.
  • Each package represents a namespace.
  • Packages, as components, can be nested inside
    other packages.

Fig 13.3 Alternate UML approaches to show
package nesting.
Embedded packages
Circle cross symbol
UML fully-qualified names
46
Terminology Tier, Layers, and Partitions
  • Tier relates to physical processing node or
    clusters of node, such as client tier.
  • Layers of an architecture represent the vertical
    slices.
  • Partitions represents a horizontal division of
    relatively parallel subsystems of a layer.

Fig 13.6 Layers and partitions.
47
The Model-View Separation Principle
  • The principle states that
  • model (domain) objects should not have direct
    knowledge of view (presentation) objects.
  • the domain classes should encapsulate the
    information and behavior related to application
    logic.
  • Why?
  • To support cohesive model definitions that focus
    on the domain process, rather than on interfaces.
  • To allow separate development of the model and
    user interface layers.
  • To minimize the impact of requirements changes in
    the interface upon the domain layer.
  • To allow new views to be easily connected to an
    existing domain layer, without affecting the
    domain layer.
  • To allow multiple simultaneous views on the same
    model object.
  • To allow execution of the model layer independent
    of the user interface layer.
  • To allow easy porting of the model layer to
    another user interface framework.

48
Information Systems
  • In IS layered architecture was known as
    three-tier architecture.
  • A three-tier architecture has interface,
    application logic and a storage.
  • The singular quality of 3-tier architecture is
  • Separation of the application logic into distinct
    logical middle tier of software.
  • The interface tier is relatively free of
    application processing.
  • The middle tier communicates with the back-end
    storage layer.

49
Example
50
Fig 13.4 Common layers in an information system
logical architecture.
51
Fig 13.7 Mixing views of the architecture.
52
Domain Layer and Domain Model
  • These are not the same thing. Domain model shows
    the real world, while the Domain layer shows the
    software architecture.
  • But the Domain model inspires the Domain layer,
    and is the source of many of the concept,
    especially class names.
  • We could create one class and put all logic in
    it, but that violates the whole spirit of object
    orientation.
  • Do not confuse the problem with the solution.

53
Fig 13.5 Domain layer and domain model
relationship.
About PowerShow.com