COMS W4156: Advanced Software Engineering - PowerPoint PPT Presentation

Loading...

PPT – COMS W4156: Advanced Software Engineering PowerPoint presentation | free to download - id: 69afef-NmU5M



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

COMS W4156: Advanced Software Engineering

Description:

Prof. Gail Kaiser Kaiser+4156_at_cs.columbia.edu http://bank.cs.columbia.edu/classes/cs4156/ – PowerPoint PPT presentation

Number of Views:7
Avg rating:3.0/5.0
Slides: 99
Provided by: pslCsColu3
Category:

less

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

Title: COMS W4156: Advanced Software Engineering


1
COMS W4156 Advanced Software Engineering
  • Prof. Gail Kaiser
  • Kaiser4156_at_cs.columbia.edu
  • http//bank.cs.columbia.edu/classes/cs4156/

2
Topics covered in this lecture
  • Introduction to software design
  • Architectural styles
  • Distributed architectures

3
Software Design
4
What is Design?
  • From Merriam-Webster Online Dictionary
    (http//www.m-w.com/dictionary/design)
  • Main Entry 1design Pronunciation
    di-'zIn Function verb Etymology Middle English,
    to outline, indicate, mean, from Anglo-French
    Medieval Latin Anglo-French designer to
    designate, from Medieval Latin designare, from
    Latin, to mark out, from de- signare to mark --
    more at SIGN
  • transitive verb 1 to create, fashion, execute,
    or construct according to plan DEVISE,
    CONTRIVE 2 a to conceive and plan out in the
    mind lthe designed the perfect crimegt b to have
    as a purpose INTEND ltshe designed to excel in
    her studiesgt c to devise for a specific
    function or end lta book designed primarily as a
    college textbookgt 3 archaic to indicate with a
    distinctive mark, sign, or name 4 a to make a
    drawing, pattern, or sketch of b to draw the
    plans for ltdesign a buildinggt
  • intransitive verb 1 to conceive or execute a
    plan 2 to draw, lay out, or prepare a design -
    designedly /-'zI-nd-lE/ adverb

5
What is Design?
  • The realization of an imagined state
  • To work out a solution in ones mind
  • The specification that guides production
  • The transition from possible solutions to a
    specific one
  • To devise a solution to a perceived problem

6
Design
C conceivable F feasible D desirable SP
still possible
design space
C
C
C
D
F
D
SP
outcome space
designer
project
customer
A design product is a point in the design
space that represents a set of decisions that
together delineate a set of possible outcomes in
the outcome space
7
Design
8
Software Design
  • Concerned with making major decisions, often of a
    structural nature
  • Shares with programming a concern for abstracting
    information representation and processing
    sequences, but at different level
  • Builds coherent, well-planned representations of
    programs that concentrate on
  • the interrelationships of parts at the higher
    levels
  • the logical operations at the lower levels

9
Software Design
  • Architectural design - How does it all fit
    together?
  • High-level partitioning of a software system into
    separate modules (components)
  • Focus on the interactions among parts
    (connections)
  • Focus on structural properties (configuration)
  • Modular design - How does it work?
  • Detailed design of a component (unit, class,
    file)
  • Focus on the internals of a component and
    computational properties (data structures,
    algorithms)

10
Example
Architectural design
Provided Interface
Modular design
Compressor
Encoder
Reader
Required Interface
11
Compare to Building Architecture
  • Overall shape of the physical structure
  • Manner in which the various components of the
    building are integrated to form a whole
  • The way in which the building fits into its
    environment and meshes with other buildings in
    its vicinity
  • Degree to which the building meets its stated
    purpose and satisfies the needs of its owner

12
Building Architecture Has Many Levels
13
Architectural Design
  • Elements
  • Floors
  • Walls
  • Rooms
  • Types
  • Office building
  • Villa
  • Aircraft hanger
  • Elements
  • Components
  • Interfaces
  • Messages
  • Types
  • Office automation
  • Game
  • Space shuttle control

Buildings
Software
14
Architectural Design
  • Styles
  • Colonial
  • Cape Cod
  • Ranch
  • Rules and regulations
  • Electrical
  • Structural
  • Styles
  • Pipe and filter
  • Layered
  • Implicit invocation
  • Rules and regulations
  • Use of interfaces
  • Conforms to Component Model

Buildings
Software
15
Software Architecture
  • A high-level model of a (non-physical) thing
  • Describes critical aspects of the thing
  • Understandable to many stakeholders
  • Allows evaluation of the things properties
    before it is built
  • Provides well understood tools and techniques for
    constructing the thing from its blueprint
  • A representation that enables a software engineer
    to
  • Analyze the effectiveness of the design in
    meeting its stated requirements
  • Consider architectural alternatives at a stage
    when making design changes is still relatively
    easy
  • Reduce the risks associated with the construction
    of the software

16
What is the Problem?
This is a simple software system!
17
Design Abstraction
18
Architectural Abstraction
19
Software Architecture Essentials
  • Components
  • What are the main parts?
  • What aspects of the requirements do they
    correspond to?
  • Both processing elements and data elements
  • Can be simple or composite
  • Examples abstract data types, filters,
    databases, GUIs, servers
  • Connections
  • How do components communicate?
  • Model interactions among components and rules
    that govern those interactions
  • Dont forget initialization/finalization
    dependencies
  • Examples shared variables, procedure calls,
    messages, multicast, pipes

20
Software Architecture Essentials
  • Configurations
  • What is the topology?
  • Connected graph of components and connectors that
    describes architectural structure
  • Defines proper connectivity, concurrent and
    distributed properties, adherence to
    architectural style
  • Constraints on change (load bearing walls)
  • Architectural erosion due to violations of the
    architecture increases brittleness
  • Architectural drift due to insensitivity to the
    architecture leads to inadaptability then
    disasters

21
Comparison to Programming (of Modules)
  • Architecture Modules
  • interaction among parts implementation of
    parts
  • structural properties computational
    properties
  • system-level performance algorithmic
    performance
  • outside module boundary inside module boundary

22
Comparison to Hardware Architecture
  • Two important characteristics of hardware
  • Relatively small number of design elements.
  • Scale is achieved by replication of these design
    elements.
  • Similarity between Software and Hardware
    Architectures
  • Analogies to organization and configuration
  • Differences between Software and Hardware
    Architectures
  • Software requires large number of design
    elements.
  • Scale is achieved (in many cases) by adding more
    distinct elements.

23
Comparison to Network Architecture
  • Nodes and Connections act as the design elements.
  • Features
  • Two components Nodes and Connections.
  • Only a few topologies are considered (star, ring,
    grid).
  • In software architecture,
  • Two components Processes and Interprocess
    communication.
  • Large number of possible topologies, many without
    any proper names.

24
We Can Do Anything
Provided Interface
Provided Interface
Tiny Component
Big Component
Required Interface
Required Interface
Provided Interface
B Component
Required Interface
Provided Interface
Provided Interface
A Component
Mr. Component
Required Interface
Provided Interface
Required Interface
Some Component
Required Interface
Provided Interface
Ms. Component
Required Interface
Provided Interface
Provided Interface
One Component
Yet Another Component
Required Interface
Required Interface
25
But Style Has Proven to Help
  • Architectural styles restrict the way in which
    components can be connected
  • Prescribe patterns of interaction
  • Promote fundamental principles
  • Rigor, separation of concerns, anticipation of
    change, generality, incrementality
  • Low coupling among elements
  • High cohesion within elements
  • Architectural styles are based on success stories
  • Almost all compilers are built as
    pipe-and-filter
  • Almost all network protocols are built as layers

26
Architectural Styles
27
Architectural styles
  • The architectural model of a system may conform
    to a generic architectural style.
  • An awareness of these styles can simplify the
    problem of defining system architectures.
  • However, many large systems are heterogeneous and
    do not follow a single architectural style.

28
System organization
  • Reflects the basic strategy that is used to
    structure a system.
  • Three organizational styles are widely used
  • A shared data repository style
  • A shared services and servers style
  • An abstract machine or layered style.

29
Repository model
  • Sub-systems must exchange data. This may be done
    in two ways
  • Shared data is held in a central database (or
    other kind of repository) and may be accessed by
    all sub-systems
  • Each sub-system maintains its own database and
    passes data explicitly to other sub-systems.
  • When large amounts of data are to be shared, the
    repository model of sharing is most commonly used.

30
IDE toolset architecture
31
Repository model advantages
  • Efficient way to share large amounts of data.
  • Sub-systems need not be concerned with how data
    is produced.
  • Centralized management, e.g., backup, user
    authentication, etc.
  • Sharing model is published as the repository
    schema.

32
Repository model disadvantages
  • Sub-systems must agree on a repository data model
    - inevitably a compromise.
  • Data evolution is difficult and expensive.
  • No provision for specific local policies.
  • Difficult to distribute efficiently.

33
Client-server model
  • Distributed system model that dictates how data
    and processing services are distributed across a
    range of components.
  • Set of clients that call on these services.
  • Network that allows clients to access servers.

34
Film and picture library
35
Client-server advantages
  • Distribution of data is straightforward.
  • Makes effective use of networked systems.
  • May allow cheaper hardware (particularly when
    different services are provided by different
    servers, as opposed to a single all-in-one
    server).
  • Easy to add new servers or upgrade existing
    servers.

36
Client-server disadvantages
  • No shared data model so sub-systems use different
    data organization - data interchange may be
    inefficient.
  • Redundant management in each server.
  • Not necessarily any central register of names and
    services - it may be hard to find out what
    servers and services are available.

37
Abstract machine (layered) model
  • Used to model the interfacing of sub-systems.
  • Organizes the system into a set of layers (or
    abstract machines), each of which provides a set
    of services.
  • Supports the incremental development of
    sub-systems in different layers When a layer
    interface changes, only the adjacent layer is
    affected.
  • However, sometimes artificial to structure
    systems in this way.

38
Version management system
39
Modular decomposition styles
  • Concerned with decomposing sub-systems into
    modules.
  • No rigid distinction between system organization
    and modular decomposition.

40
Sub-systems and modules
  • A sub-system is a system in its own right whose
    operation is independent of the services provided
    by other sub-systems.
  • A module is a system component that provides
    services to other components but would not
    normally be considered as a separate system.

41
Modular decomposition
  • Another structural level where sub-systems are
    decomposed into modules.
  • Two major modular decomposition models
  • An object model where the system is decomposed
    into interacting objects
  • A pipeline or data-flow model where the system is
    decomposed into functional modules that transform
    inputs to outputs.
  • If possible, decisions about concurrency should
    be delayed until modules are implemented.

42
Object models
  • Structure the system into a set of loosely
    coupled objects with well-defined interfaces.
  • Object-oriented decomposition is concerned with
    identifying object classes, their attributes and
    operations.
  • When implemented, objects are created from these
    classes and some control model is used to
    coordinate object operations.

43
Invoice processing system
44
Object model characteristics
  • Objects are loosely coupled so their
    implementations can be modified without affecting
    other objects.
  • The objects may reflect real-world entities.
  • OO implementation languages are widely used.
  • However, object interface changes may cause
    problems, and complex entities may be hard to
    represent as objects.

45
Function-oriented pipelining
  • Functional transformations process their inputs
    to produce outputs.
  • Often referred to as a pipe-and-filter model (as
    in UNIX shell).
  • When transformations are sequential, this is a
    batch sequential model - which is extensively
    used in data processing systems.
  • May not be suitable for interactive systems.

46
Invoice processing system
47
Pipeline model characteristics
  • Supports transformation reuse.
  • Intuitive organization for stakeholder
    communication.
  • Easy to add new transformations.
  • Relatively simple to implement as either a
    concurrent or sequential system.
  • However, requires a common format for data
    transfer along the pipeline and its difficult to
    support event-based interaction.

48
Control styles
  • Concerned with the control flow between
    sub-systems (distinct from the system
    decomposition model).
  • Centralized control
  • One sub-system has overall responsibility for
    control, and starts and stops other sub-systems.
  • Event-based control
  • Each sub-system can respond to externally
    generated events from other sub-systems or the
    systems environment.

49
Centralized control
  • A control sub-system takes responsibility for
    managing the execution of other sub-systems.
  • Call-return model
  • Top-down subroutine model where control starts at
    the top of a subroutine hierarchy and moves
    downwards. Applicable to sequential systems.
  • Manager model
  • One system component controls the stopping,
    starting and coordination of other system
    processes. Applicable to concurrent systems. Can
    also be implemented in sequential systems as a
    case statement.

50
Call-return model
51
Real-time system control
52
Event-driven systems
  • Driven by externally generated events where the
    timing of each event is outside the control of
    the sub-systems that process the event.
  • Two principal event-driven models
  • Broadcast models - An event is broadcast to all
    sub-systems. Any sub-system that can handle the
    event may do so.
  • Interrupt-driven models - Used in real-time
    systems (and at OS device driver level) where
    interrupts are detected by an interrupt handler
    and passed to some other component for
    processing.
  • Other event-driven models include spreadsheets
    and rule-based production systems.

53
Broadcast model
  • Effective in integrating sub-systems on different
    computers in a network.
  • Sub-systems register an interest in specific
    events. When these occur, control is transferred
    to the sub-system that can handle the event.
  • Control policy is not embedded in the event and
    message handler sub-systems decide on events of
    interest to them.
  • However, sub-systems dont know if or when an
    event (outside their interest) will be handled.

54
Selective broadcasting
55
Interrupt-driven systems
  • Used in real-time systems where fast response to
    an event is essential.
  • There are known interrupt types with a handler
    defined for each type.
  • Each type is associated with a memory location
    and a hardware switch causes transfer to its
    handler.
  • Allows fast response but complex to program and
    difficult to validate.

56
Interrupt-driven control
57
  • Distributed Systems Architectures

58
System types
  • Personal systems that are not distributed and
    that are designed to run on a personal computer
    or workstation.
  • Embedded systems that run on a single processor
    or on an integrated group of processors.
  • Distributed systems where the system software
    runs on a loosely integrated group of cooperating
    processors linked by a network.

59
Distributed systems
  • Virtually all large software-based systems are
    now distributed systems.
  • Information processing is distributed over
    several computers rather than confined to a
    single machine.

60
Distributed system characteristics
  • Resource sharing
  • Sharing of hardware and software resources.
  • Openness
  • Use of equipment and software from different
    vendors.
  • Concurrency
  • Concurrent processing to enhance performance.
  • Scalability
  • Increased throughput by adding new resources.
  • Fault tolerance
  • The ability to continue in operation after a
    fault has occurred.

61
Distributed system disadvantages
  • Complexity
  • Distributed systems are typically more complex
    than centralized systems.
  • Security
  • More susceptible to external attack.
  • Manageability
  • More effort required for system management.
  • Unpredictability
  • Unpredictable responses depending on the system
    organization and network load.

62
Distributed systems architectures
  • Client-server architectures
  • Distributed services that are called on by
    clients. Servers that provide services are
    treated differently from clients that use
    services.
  • Distributed object (peer to peer) architectures
  • No distinction between clients and servers. Any
    object on the system may provide and use services
    from other objects.

63
Middleware
  • Software that manages and supports the different
    components of a distributed system. In essence,
    it sits in the middle of the system.
  • Middleware is usually off-the-shelf rather than
    specially written software.
  • Component model frameworks are designed to
    provide standard middleware for a wide range of
    software systems.

64
Multiprocessor architectures
  • Simplest distributed system model.
  • System composed of multiple processes, which may
    (but need not) execute on different processors.
  • Distribution of process to processor may be
    pre-ordered or may be under the control of a
    dispatcher.

65
A multiprocessor traffic control system
66
Client-server architectures
  • The application is modelled as a set of services
    that are provided by servers and a set of clients
    that use these services.
  • Clients know of servers but servers need not know
    of clients.
  • Clients and servers are logical processes.
  • The mapping of processors to processes is not
    necessarily 1 1.

67
A client-server system
68
Computers in a C/S network
69
Layered application architecture
  • Presentation layer
  • Concerned with presenting the results of a
    computation to system users and with collecting
    user inputs.
  • Application processing layer
  • Concerned with providing application specific
    functionality, e.g., in a banking system, banking
    functions such as open account, close account,
    etc.
  • Data management layer
  • Concerned with managing the system databases or
    other repositories.

70
Application layers
71
Thin and fat clients
  • Thin-client model
  • In a thin-client model, all of the application
    processing and data management is carried out on
    the server. The client is simply responsible for
    running the presentation software.
  • Fat-client model
  • In this model, the server is only responsible for
    data management. The software on the client
    implements the application logic and the
    interactions with the system user.

72
Thin and fat clients
73
Thin client model
  • Often used when legacy systems are migrated to
    client-server architectures.
  • The legacy system acts as a server in its own
    right with a graphical interface implemented on a
    client.
  • Recently used for web-based applications.
  • A major disadvantage is that it places a heavy
    processing load on both the server and the
    network.

74
Fat client model
  • More processing is delegated to the client as the
    application processing is locally executed.
  • Most suitable for new C/S systems where the
    capabilities of the client system are known in
    advance.
  • More complex than a thin client model, especially
    for management. New versions of the application
    have to be installed on all clients.

75
A client-server ATM system
76
Three-tier architectures
  • In a three-tier architecture, each of the
    application architecture layers may execute on a
    separate processor.
  • Allows for better performance than a thin-client
    approach and is simpler to manage than a
    fat-client approach.
  • A more scalable architecture - as demands
    increase, extra servers can be added.

77
A 3-tier C/S architecture
78
An Internet banking system

79
Distributed object architectures
  • There is no distinction in a distributed object
    architecture between clients and servers.
  • Each distributable entity is an object that
    provides services to other objects and receives
    services from other objects.
  • Object communication through a middleware system,
    often called an object request broker (ORB).
  • Distributed object architectures are generally
    more complex to design than C/S systems.

80
Distributed object architecture
81
Advantages of distributed object architectures
  • Allows the system designer to delay decisions on
    where and how services should be provided.
  • A very open system architecture that allows new
    resources to be added as required.
  • Flexible and scaleable.
  • It is possible to reconfigure the system
    dynamically with objects migrating across the
    network as required.

82
Uses of distributed object architectures
  • As a logical model that allows you to structure
    and organize the system. In this case, you think
    about how to provide application functionality
    solely in terms of services and combinations of
    services.
  • As a flexible approach to the implementation of
    client-server systems. The logical model of the
    system is client-server, but both clients and
    servers are realized as distributed objects
    communicating through a common communication
    framework.

83
A data mining system
84
Data mining system
  • Allows the number of databases that are accessed
    to be increased without disrupting the system.
  • Allows new types of relationships to be mined by
    adding new integrator objects.

85
CORBA
  • CORBA (Common Object Request Broker Architecture)
    is an international standard for an Object
    Request Broker - middleware to manage
    communications between distributed objects.
  • Middleware for distributed computing is required
    at two levels
  • At the logical communication level, the
    middleware allows objects on different computers
    to exchange data and control information.
  • At the component level, the middleware provides a
    basis for developing compatible components. CORBA
    component standards have been defined.

86
CORBA application structure
87
Application structure
  • Application objects.
  • Standard objects, defined by the OMG (Object
    Management Group), for a specific domain, e.g.,
    insurance.
  • Fundamental CORBA services such as directories
    and security management.
  • Horizontal (i.e., cutting across applications)
    facilities such as user interface.

88
CORBA standards
  • An object model for application objects.
  • A CORBA object is an encapsulation of state with
    a well-defined, language-neutral interface
    defined in an IDL (Interface Definition
    Language).
  • An object request broker that manages requests
    for object services.
  • A set of general object services of use to many
    distributed applications.
  • A set of common components built on top of these
    services.

89
CORBA objects
  • CORBA objects are comparable, in principle, to
    objects in C and Java.
  • They MUST have a separate interface definition
    that is expressed using a common language (IDL)
    similar to C notation.
  • There is a mapping from this IDL to programming
    languages (C, Java, etc.).
  • Therefore, objects written in different languages
    can communicate with each other.

90
Object request broker (ORB)
  • The ORB handles object communications. It knows
    of all objects in the system and their
    interfaces.
  • Using an ORB, the calling object binds an IDL
    stub that defines the interface of the called
    object.
  • Calling this stub results in calls to the ORB,
    which then calls the required object through a
    published IDL skeleton that links the interface
    to the service implementation.

91
ORB-based object communications
92
Inter-ORB communications
  • ORBs are not usually separate programs but are a
    set of objects in a library that are linked with
    an application when it is developed.
  • ORBs handle communications between objects
    executing on the same machine.
  • Several ORBs may be available and each computer
    in a distributed system will have its own ORB.
  • Inter-ORB communications are used for distributed
    object calls.

93
Inter-ORB communications
94
CORBA services
  • Naming and trading services
  • Allow objects to discover and refer to other
    objects on the network.
  • Notification services
  • Allow objects to notify other objects that an
    event has occurred.
  • Transaction services
  • Support atomic transactions and rollback on
    failure.

95
  • Final Notes

96
Teams Announcement
  • Teams will be posted on the website team page
  • If you already formed a full team - and informed
    us before the deadline broadcast by email -
    assume youre good to go
  • Otherwise, please wait for post.
  • Start thinking about the Project Concept

97
Upcoming Deadlines
  • Team project concept due September 29th
  • Project concept feedback by October 6th
  • First iteration begins October 6th

98
COMS W4156 Advanced Software Engineering
  • Prof. Gail Kaiser
  • Kaiser4156_at_cs.columbia.edu
  • http//bank.cs.columbia.edu/classes/cs4156/
About PowerShow.com