7 complex models and the origins of uml
Download
1 / 26

7. Complex Models (and the Origins of UML) - PowerPoint PPT Presentation


  • 55 Views
  • Uploaded on

7. Complex Models (and the Origins of UML). Overview 7.1 Issues 7.2 Object Modeling Technique 7.3 Use Case Approach. 7.1 Issues. Complex systems demand superior methods must cover specification & design thoroughly must provide a rich repertoire of concepts and tools

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 ' 7. Complex Models (and the Origins of UML)' - oliver


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
7 complex models and the origins of uml
7. Complex Models (and the Origins of UML)

Overview

  • 7.1 Issues

  • 7.2 Object Modeling Technique

  • 7.3 Use Case Approach


7 1 issues
7.1 Issues

  • Complex systems demand superior methods

    • must cover specification & design thoroughly

    • must provide a rich repertoire of concepts and tools

  • Effective application of such techniques

    • may require specialized training in methodologies

      • and to a lesser extent, tools

    • requires a deep understanding of fundamentals

      • based on a sound computer science and software engineering education

    • entails project by project customization

      • possibly from reusable artifacts

    • expect to acquire expertise gradually

      • continuing education is needed to apply training effectively


7 1 issues continued
7.1 Issues, Continued

  • Multiple models must be integrated formally

    • state transition models

    • class and object models

    • data flow and message flow models

  • Graphical representations not always economical & intuitive

    • Look for representations that best capture models semantics

    • Watch out for superficial (easy) vs. deep (effective) representations

  • Established methods do not always deliver

    • Need extensibility to address new cases not previously considered

    • Some degree of questioning the realism of tools/methods is helpful


7 2 object modeling technique

Object Modeling Technique (OMT)

Rumbaugh et al.

Attempts to integrate several traditional methods with object-oriented analysis

Combined with the (Grady) Booch method, and Jacobsen’s Use Cases, led to UML

Object/class models

application-specific information (structure) is captured in terms of objects having attributes and operations

classes and inheritance are used to generalize objects

links and associations define logical relationships among objects and classes

Dynamic model

the dynamic behavior of objects is captured using state machine models

Functional model

the processing of environmental inputs is captured by means of a dataflow model

7.2 Object Modeling Technique



Objects

An object is characterized by

visible attributes

operations (services) it provides

Objects often are immediately identifiable in the application

E.g., look for nouns in RDD/SRS

Initial definitions may be misleading

may need rethinking (semantics)

may refactor or extend accordingly

What does it do?

What happens in the US?

What happens in Australia?

Objects


Classes and inheritance

Classes provide object generalization

from instances to concepts

Classes and Inheritance


Constraints and associations
Constraints and Associations

  • Established data modeling techniques provide the means for defining semantic constraints existing in the application

  • Such models help analysis

  • Associations and constraints may give rise to new classes

    • E.g., Traffic Simulation’s constraint evaluator



Dynamic model
Dynamic Model



Strengths of omt and successors
Strengths of OMT (and successors)

  • Comprehensive application analysis

  • Powerful object-oriented model

  • Inclusion of relational concepts (semantic constraints)

  • Reliance on established models


Concerns with omt successors
Concerns with OMT (& successors)

  • Complex graphical notation

  • Lack of precise formal definition

    • This has been aided in UML via state charts

  • Weak integration among models

  • Inadequate treatment of the environment

    • Again aided in UML via use cases

  • Use of models whose effectiveness is sometimes questionable (dataflow)

  • Unrealistic expectations regarding direct transition to design

    • Tool support (e.g., code generation) helps, but not completely


7 3 use case approach

Use Case Approach (OOSE) (Jacobson et al) combines object-oriented modeling with a strong emphasis on processing scenarios

RDD (requirements model)

interfaces

domain object model

use case model (scenarios)

SRS (analysis model)

object-oriented model of the functionality

7.3 Use Case Approach


Use case model

Actors

model the environment and the users

initiate activity by providing stimuli

can be primary or secondary

Use cases

are complete courses of action initiated by actors (basic or alternative)

can be extended by (interrupt analogy) or use other use cases (call analogy)

Use Case Model


Analysis model
Analysis Model

  • Objects are divided into three categories

    • interface

    • entity

    • control


Strengths of oo software engineering
Strengths of OO Software Engineering

  • Comprehensive application analysis

  • Emphasis on processing scenarios and scenario composition

  • Reliance on simple forms of established models

  • Powerful object-oriented model

  • Emphasis on the development process


Concerns with oo software engineering
Concerns with OO Software Engineering

  • Complexity and cost associated with developing the domain object model

  • Overly optimistic expectations regarding the transition to design


8 reviews
8. Reviews

Overview

  • 8.1 Rationale

  • 8.2 Technical Objectives


8 1 rationale
8.1 Rationale

  • Early error detection reduces development costs

  • Good requirements are critical to the success of the project

    • correct reflection of evolving customer needs

    • readily understood and maintained by the development team

    • clearly satisfied by the design and realization

  • Reviews play a key role in ensuring the accuracy and quality of the requirements

  • Reviews make sure that the requirements do shape the entire development process

  • Reviews help refine the development process


Technical objectives

Requirements impact technical reviews throughout the development life-cycle

Critical reviews involving requirements are

requirements verification

requirements validation

design verification

Highly specialized reviews relating to requirements include

project planning

testing procedures

performance analysis

error pattern analysis

Technical Objectives


Requirements verification

Requirements verification is a strictly technical review which attempts to establish

soundness

consistency

completeness

These notions must rely on criteria provided by some underlying model

are all inputs used?

are all outputs produced?

is the information needed to carry out each function available?

are interfaces used in a manner inconsistent with the physical reality?

Requirements Verification


Requirements verification1
Requirements Verification which attempts to establish

  • The SRS is the prime target for the requirements verification

  • Informal documents are very difficult to verify but some useful tools do exist

    • check lists

    • standard formats


Requirements validation

Requirements validation is a customer-centered evaluation of the requirements documentation

Its goal is to ensure that the requirements are an accurate reflection of the customer’s needs

as presented originally by the customer in the RDD

as reformulated by the technical team in the SRS

Customer participation is critical

The customer needs access to information but not the ability to read the documentation

specialized presentations

rapid prototypes

expert technical support

Consistency and traceability between RDD and SRS are important in the validation

Requirements Validation


Design verification

The objective behind design verification is to show that the requirements documentation

all functional requirements have been allocated to the design—traceability

all constraints are likely to be satisfied by the realization—design evaluation studies

The top-level design (reflecting all critical design decisions) is checked against the SRS

interface consistency

state mappings

behavior mappings

constraints satisfaction

Design Verification


Reading list
Reading List the requirements documentation

  • Davis, A. M., Software Requirements, Prentice-Hall, 1993.

  • Jacobson, I., et al, Object-Oriented Software Engineering, Addison-Wesley, 1992.

  • Roman, G.-C., "A Taxonomy of Current Issues in Requirements Engineering," Computer 18, No. 4, April 1985, pp. 14-23.

  • Rumbaugh, J., et al, Object-Oriented Modeling and Design, Prentice-Hall, 1991.

  • Sommerville, I., Software Engineering, Addison-Wesley Pub. Co., 1996.


ad