3/22/03 – Intro to Software Eng – Lecture Notes

 

System Construction

-          Big?:  How do you resolve references to external entities

o        Statically – linking machine

§         Compile time (ADA)

§         Link time (C, C++)

o        Dynamically – at reference time (Multics)

-          Systems build:

o        Too large a job for compiler

o        Separate linking mechanism

o        Separate build facility/mechanism

o        Still really people intensive, even with tools and systems to aid

Build Process

-          Create a dependency graph (makefile)

-          Determine what in the system has changed (interfaces)

-          Determine what depends on changed components (what uses those interfaces)

-          Recompile dependencies

-          Link components

-          Check for incompatibilities

-          Remove compatibilities – change components

-          Repeat until all incompatibilities are eliminated

Roles – Build

-          Build owner – coordinates

-          Developer (source of all problems)

-          Build admin – actually does build, according to a procedure (guidebook)

-          Build assistants – problem hackers (Naperville?  Why Naperville?)

Two Critical Things

-          tool support (intensive)

-          human support (intensive)

Reality

-          large systems – can take days and weeks

-          large number of builds – sequential (problems), parallel (different uses)

-          large amount of time spent eliminating problems

o        isolate faults

o        determining who’s responsible

o        negotiate resolution

-          often lack sufficient resources

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Middleware - virtual machine (connector, interface)

  • Indirection -
    • Logically – (name, link) with link to component
  • OMG CORBA – Common Object Request Broker Architecture – straightforward idea
    • Extends build and link problem to address issues
      • Components are build in different languages
      • Run on different platforms
      • Distributed systems

ΰ      How to do the wiring?  Standard connector

    • Goal of CORBA – open connection, fluid flexible dynamically- workable architecture
      • High-level standard protocols
      • CORBA compliance to standards
      • Costly, not as efficient as binary connector (COM)
      • A lot more flexible than COM
    • 3 Parts of CORBA
      • Set of invocation interfaces – “late binding” (indirection) – nameΰreferents(objects)
      • Object request broker
      • Set of object adapters

 

IDL –

Interface

Definition

Language

 

      • Location transparency
      • Registration

 

    • Beyond Basic Wiring…
      • Naming – unique, like white pages
      • Security – not yet supported
      • Object trader services
      • Transactions – OTS
      • Fine-grain services (change management, concurrency service with locks, event notification, externalization, licensing, persistence, queries, etc)

 

  • COM- OLE + ActiveX
    • Binary standard
    • Functionality – an interface
      • Interface node ΰ Table of procedure variables
    • Double indirection (like pointing two guns at your own head) – two conduits for defeating yourself
      • Methods need notion of “self” or “this”
      • Can have multiple interfaces implemented by the same set of objects
      • Query interface ΰ UID
      • Two forms of composition
        • Containment
        • Aggregation
      • Polymorphism (not truly polymorphism)
        • Actually overloading

 

    • Beyond Basic Wiring
      • Categories – catIDs
      • Versioning
      • Distrbution
      • Proxies and stubs
      • Services
        • Uniform data transfer
        • Dispatch interface
        • Outgoing interface and connected objects

 

 

 

DEPLOYMENT

Requirements

  • operate in a variety of environments
  • describe site and software system configuration information
  • manage, access, and reason about site configuration
  • manage, access, and reason about software configuration
    • dependencies
    • constraints
  • monitor deployed systems (are they doing well, are they crashing)
  • adapt to changes in the environment (OS upgrades, etc)
  • enable customers to maintain their installed configuration easily
    • little human intervention
  • new deployment technology – integral with system

 

Software Dock (analogous to a hardware dock)

  • interrogate local environment for properties
  • adapt software system to the environment
    • mutual adaptability is important because of mobility of software, interconnectivity of networks
  • SW Dock is a loosely coupled set of cooperating distributed components held together by WAN (wide-area network) messaging and event system
    • Field Dock – maintain site specific info
    • Release Dock – manages configuration and release info
    • Agents – automate deployment
    • Conceptual namespace –
    • Federated SW deployment registry
    • Events from operations propagated to interested agents
  • OLLA
    • Media content – audio, video, etc
      • 45 MB, 1700 files
      • Disco
      • Harvest
    • Installation info
      • HW/SW platform
      • HTTP server
      • Disk space
    • Startup
      • Indexing content
    • Maintenance
      • Updates – M, A, V harvest
      • Changes in environment
  • Software Dock Architecture
    • Field Dock (figure 1 of Software Dock paper)
    • Release Dock (figure 1)