Chapter 12 Requirements to Design Iteratively wkchen/courses/ooad/ooad962/chapter12-16.pdf Design Iteratively

  • View
    1

  • Download
    3

Embed Size (px)

Text of Chapter 12 Requirements to Design Iteratively wkchen/courses/ooad/ooad962/chapter12-16.pdf Design...

  • 1

    Chapter 12Chapter 12 Requirements to Requirements to Design Iteratively Design Iteratively

    2

    Iteratively:Iteratively: Do the Right Thing, Do the Right Thing, Do the Thing Right Do the Thing Right

    • The requirements and Object-oriented analysis focus on to do the right thing – Understanding some of the outstanding goals, and related rules

    and constraints.

    • By contrast, design work stress to do the thing right – Skillfully designing a solution to satisfy the requirements for

    this iteration.

    • In iterative development – A transition from primarily requirements/analysis to primarily

    design/implementation occurs in each iteration. – Early iterations will spend more time on analysis activities. – Later iterations it is common that analysis lessens; there's more

    focus on just building the solution.

  • 2

    3

    Provoking Early Change Provoking Early Change • Iterative and evolutionary methods “embrace change”

    – It is natural to discover and change some requirements during the design and implementation work, especially in the early iterations.

    • We try to provoke inevitable change in early iterations so that – We have a more stable goal (and estimate and schedule) for

    the later iterations. – Early programming, tests, and demos help provoke the

    inevitable changes early on. • Over the course of early elaboration iterations

    – The requirements discovery should stabilize by the end of elaboration perhaps 80% of the requirements are reliably defined (as a result of feedback)

    • Rather than speculation, as occurs in a waterfall method

    4

    Didn't All That Analysis and Didn't All That Analysis and Modeling Take Weeks To Do Modeling Take Weeks To Do

    • The duration to do all the actual modeling (use case writing, domain modeling..) that has been explored so far is realistically just a few hours or days. – When one is comfortable with the skills of use case writing,

    domain modeling, etc.

    • Many other activities of project planning, such as proof-of-concept programming, finding resources (people, software, …), planning, setting up the environment could consume a few weeks of preparation.

  • 3

    Chapter 13Chapter 13 Logical Logical

    Architecture and Architecture and UML Package UML Package

    Diagrams Diagrams

    6

    IntroductionIntroduction • The design of a OO system is based on

    several architectural layers – UI layer – Application logic (domain) layer – …

    • This chapter explores a logical layered architecture and related UML notation

  • 4

    7

    Sample UP Artifact Influence Sample UP Artifact Influence

    : Register

    enterItem (itemID, quantity)

    : ProductCatalog

    spec = getProductSpec( itemID )

    Require- ments

    Business Modeling

    Design

    Sample UP Artifact Relationships

    Vision Glossary

    The logical architecture is influenced by the constraints and non-functional requirements captured in the Supp. Spec.

    Domain Model

    * *

    Supplementary Specification

    Use-Case Model

    Register

    ...

    makeNewSale() enterItem(...) ...

    ProductCatalog

    ...

    getProductSpec(...) ...

    1 1class diagrams (a static view)

    interaction diagrams (a dynamic view)

    UIpackage diagramsof the logical architecture (a static view) Domain

    Tech Services

    Design Model

    FURPS+

    Functionality

    Usability

    Reliability

    Performance

    Supportability

    And quality attributes

    8

    POS Example: POS Example: Partial Layered, Partial Layered, Logical ArchitectureLogical Architecture

    Domain

    UI

    Swing not the Java Swing libraries, but our GUI classes based on Swing

    Web

    Sales Payments Taxes

    Technical Services

    Persistence Logging RulesEngine UML package diagram

    dependency

    package

  • 5

    9

    What is the Logical Architecture? What is the Logical Architecture? And Layers? And Layers? 11

    • Logical architecture (LA) – Is the large-scale organization of the software classes into

    packages (or namespaces), subsystems, and layers. – It's logical, because there's no decision about how these

    elements are deployed across different operating system processes or across physical computers in a network (these latter decisions are part of the deployment architecture).

    – A logical architecture is commonly organized in layers.

    • Layer – Is a group of classes, packages, or subsystems that has cohesive

    responsibility. – Higher layers call upon services of lower layers

    10

    What is the Logical Architecture? What is the Logical Architecture? And Layers? And Layers? 22

    • Typically layers in an OO system – User Interface – Application Logic and Domain Objects

    • Representing domain concepts (e.g., Software class sale) that fulfill application requirements, such as calculating a sale total.

    – Technical services • Provide supporting technical services, such as interfacing

    with a database or error logging. These services are usually application-independent and reusable across several systems.

  • 6

    11

    What is the Logical Architecture? What is the Logical Architecture? And Layers And Layers 33

    • Strict layered architecture – A layer only calls upon the services of the layer

    directly below it • Common in Network protocol stacks. • But less common in information systems

    • Relaxed layered architecture – A higher layer calls upon several lower layers

    • What Layers are the Focus in the Case Studies? – OOA/D focuses on the core application logic (or

    "domain") layer

    12

    Software Architecture Software Architecture • A software architecture is

    – the set of significant decisions about the organization of a software system,

    – the selection of the structural elements and their interfaces by which the system is composed

    • Including behavior

    – the composition of these structural and behavioral elements into progressively larger subsystems,

    – the architectural style that guides this organization — these elements and their interfaces, their collaborations, and their composition.

  • 7

    13

    Applying UML: Package Applying UML: Package Diagrams Diagrams 11

    • UML package diagrams – Used to illustrate the logical architecture of a

    system (layers, subsystems, packages) • A layer can be modeled as a UML package; e.g., the UI layer

    modeled as a package named UI.

    – Provides a way to group elements. • Can group anything: classes, other packages, ... • Nesting packages is very common, java::util::Date. • A UML package is a more general concept than simply a java

    package or .NET namespace.

    – Shows dependency (a coupling) between packages • For developers to see the large-scale coupling in the system. • A dashed arrowed line with the arrow pointing towards the

    depended-on package.

    14

    Applying UML: Package Applying UML: Package Diagrams Diagrams 22

    • Package nesting: embedded packages, UML fully- qualified names, and the circle-cross symbol

    Domain::Sales

    UI:: WebUI::Swing

    Sales

    WebSwing

    UI

    Domain

    DomainUI

    Swing SalesWeb

    Fully qualified names

    Embedded package

    Circle-cross symbol

  • 8

    15

    Guideline: Design with LayersGuideline: Design with Layers11 • The essential ideas of using layers

    – Organize the large-scale logical structure of a system into discrete layers of distinct, related responsibilities, with a clean, cohesive separation of concerns

    • The higher layers are more application specific • The lower layers are low-level and general services

    – Collaboration and coupling is from higher to lower layers; lower-to-higher layer coupling is avoided.

    See next page

    16

    Common Layers In An Information Common Layers In An Information System Logical ArchitectureSystem Logical Architecture

    UI (AKA Presentation, View)

    Application (AKA Workflow, Process, Mediation, App Controller)

    Domain (AKA Business,

    Application Logic, Model)

    Technical Services (AKA Technical Infrastructure, High-level Technical Services)

    Foundation (AKA Core Services, Base Services,

    Low- level Technical Services/ Infrastructure)

    width implies range of applicability

    GUI windows reports speech interface HTML, XML, XSLT, JSP, Javascript, ...

    handles presentation layer requests workflow session state window/page transitions consolidation/transformation of disparate data for presentation

    handles application layer requests implementation of domain rules domain services (POS, Inventory) - services may be used by just one application, but there is also the possibility of multi-application services

    (relatively) high-level technical services and frameworks Persistence, Security

    low-level technical services, utilities, and frameworks data structures, threads, math, file, DB, and network I/ O

    more app

    specific

    de pe

    n d en

    cy

    Business Infrastructu