CISD 770

Document Sample
CISD 770 Powered By Docstoc
					DCIS 770

Software Engineering

Lee Leitner, Ph.D.

Software Engineering
      • Cluster 1 Topics
            – Introduction
            – Principles
            – Qualities
            – Development Life Cycles
            – Software Engineering Risks
            – Software Reliability Engineering
            – Reuse
            – Reengineering
            – Patterns
            – Software Architecture

DCIS 770 Lee Leitner                             2
Software Engineering – The State of the Union

    • A state of growing disorder and chaos
    • or
    • improving unification and maturation?

DCIS 770 Lee Leitner                            3
State of the Union
      Chaos and Crisis
          Dramatic industry software failures
          Industry cost-overruns
          Ineffective academic to industry transfer
          Poor research methods
          Inability to join traditional engineering practice
          Too high rate of technology change
          Flawed technology, methodology and foundations
          Years that lack significant progress

DCIS 770 Lee Leitner                                           4
State of the Union
      • Unification and Maturation
            – SWEBOK
            – Licensing
            – Improved technologies and science
            – Better education (undergraduate and graduate
              programs in software engineering)
            – Recognition of research method deficiencies
            – Growing body of knowledge
            – Attempts at research transfer to industry

DCIS 770 Lee Leitner                                         5
State of the Union

      So what does this mean for the
                  software developer?
                  software engineering researcher?
                  Ph.D. student?

DCIS 770 Lee Leitner                                 6
State of the Union

      • Opportunity!

      • But the path is treacherous

DCIS 770 Lee Leitner                  7
State of the Union

                       • So let’s start at the beginning…

DCIS 770 Lee Leitner                                        8
What is Software?

     Source code?
     Image on disk or in RAM?
     Algorithms and Data Structures?


      • Artifacts of the Process and Product
      • Observable Behavior
      • Embodied Knowledge

DCIS 770 Lee Leitner                           10
Artifacts of the Process and Product

      • Requirements documentation
      • Design documents
      • Source programs
      • Executable files
      • Techniques and methods
      • Standards
      • ...

DCIS 770 Lee Leitner                   11
Observable Behavior
      • Computer
            – General purpose device
            – Requires software to operate
            – Software changes its behavior
            – Dynamic changes
            – Hardware “behaving”
                  • ---> software is present

      • Also: behavior can be thought of the human
        processes: development/use

DCIS 770 Lee Leitner                                 12
Embodied Knowledge
      • Knowledge is embodied in capital goods
                       – -Menger

                                     •Wood handle
                                     •Metal Head
                                     •Handle shape/feel
                                     •Hardness of head
                                     •Shape of head
                                     •Human characteristics

DCIS 770 Lee Leitner                                          13
Embodied Knowledge
      • “A boy was constantly employed to open and shut alternately the
        communication between the boiler and cylinder [of a steam engine], according
        as the piston either ascended or descended. One of the boys… observed that, by
        tying a string from the the handle of the valve that opened this communication
        to another part of the machine, the valve would open and shut without
        assistance, and he therefore was free to play.”

            – -- Adam Smith Wealth of Nations 1776

            – Tying the string -- later metal rod
                       – boy’s insight now built into the machine

DCIS 770 Lee Leitner                                                                14
Embodied Knowledge in Software

      • Business processes and data
      • Algorithmic techniques
      • Data management
      • Creative skills of developer
      • Knowledge of domain experts

DCIS 770 Lee Leitner                   15
What is Engineering?

           • “The application of scientific and
             mathematical principles to practical ends
             such as the design, construction, and
             operation of efficient and economical
             structures, equipment and systems”
                 – -- American Heritage Dictionary

                 – …. for the benefit of society...

DCIS 770 Lee Leitner                                     16
Attributes of Engineering

      • High Quality
      • Responsibility and Accountability
      • Application of Methodology
      • Planned
      • Managed
      • Traceable Steps
      • No risk taking

DCIS 770 Lee Leitner                        17
Engineering Evolution

                        Source: Shaw/Garlan

DCIS 770 Lee Leitner                          18
Engineering Codification

                       Source: Shaw/Garlan

DCIS 770 Lee Leitner                         19
Traditional Engineering

      • Civil Engineering
      • Mechanical Engineering
      • Electrical Engineering
      • Chemical Engineering

      • Software Engineering?

DCIS 770 Lee Leitner             20
Software Engineering?
      • Do we usually engineer software?
      • Possible counter examples:
            – Web development
            – Visual BASIC client/server applications
            – Bug fixing and maintenance work
            – Y2K work
            – ….
            – Implications: High risk of failure, high cost, low
              quality and satisfaction!

DCIS 770 Lee Leitner                                               21
Software engineering vs.
      • Programming
            – focuses solely on code construction

      • Systems Analysis
            – focuses on solving organizational problems

      • Software development
            – Close, but concerned more with product than

DCIS 770 Lee Leitner                                        22
Emerging Software Engineering

                       Source: Shaw/Garlan

DCIS 770 Lee Leitner                         23
What Software Engineering can be:

      • Software engineering is the application of
        engineering principles to the creating of
        software systems that meet practical objectives,
        including utility, reliability, and effectiveness.
      • Result: Software development becomes an
        engineering discipline.
      • A craft to engineering practice

DCIS 770 Lee Leitner                                     24
      Software Engineering and
      Systems Integration

       • Software engineering has evolved from
         the development of single integral
         software artifacts to an engineering
         discipline that integrates a broad range of

DCIS 770 Lee Leitner                                   25
COTS Integration

       • Commercial Off The Shelf software
             – Generalize to
                   • commercial software packages
                   • shareware
                   • freeware

       • Software engineering coupled with software

DCIS 770 Lee Leitner                                  26
S/W Engineering and COTS
      • S/W Engineering for Information Systems:
            – New Software Development
            – AND System Integration using COTS

      • Not a new idea:
            – operating systems
            – DBMSs
            – User interfaces
            – Class libraries

DCIS 770 Lee Leitner                               27
      • Advantages
            – Leverage off of expertise of others
            – Faster delivery of solution
            – Possibly lower cost

DCIS 770 Lee Leitner                                28
S/W Engineering and COTS
      • Issues:
            – Licensing
            – Dilution of intangible assets
            – Supportability
            – Functionality
            – Engineering methodology
            – Reliability

DCIS 770 Lee Leitner                          29
COTS Licensing
      • Non-exclusive right to use
      • Constraints
            – hardware
            – software context
            – number of users
            – transferability

      • Perpetual?
      • Irrevocable?

DCIS 770 Lee Leitner                 30
COTS Asset dilution
      • The “in-house” software an organization owns
        is a an asset
            – a machine

      • Software an organization licenses is not
      • An organization’s owned software may have
        little value without the context of its licensed

DCIS 770 Lee Leitner                                       31
COTS Supportability
      • In-house or outside support?
      • No structural tests possible in most cases by the
      • Quality of support provided is an issue

DCIS 770 Lee Leitner                                   32
COTS Functionality
      • How configurable?
      • What is “left out”?
      • What is invalid?
      • Customizable?

DCIS 770 Lee Leitner          33
COTS Engineering Methodology
      • What engineering methodology did the
        developer employ?
      • Licensee must validate and verify

DCIS 770 Lee Leitner                           34
COTS Tradeoffs (McConnell)
      • COTS won’t meet 100% of user requirements

      • But: negotiation and concessions usually cause
        custom software to not meet all requirements
      • if you deliver 80% of desired functionality, how
        well are doing in comparison with a COTS

DCIS 770 Lee Leitner                                       35
Software Engineering terms
      • The hierarchy
      • Software Technique
            – rules and notation for an activity

      • Software method
            – set of techniques to be followed to complete a specific activity

      • Software methodology
            – study of a set of methods

      • Software paradigm
            – An integrated set of methods
            – Hierarchy or blinders?
DCIS 770 Lee Leitner                                                             36
Software Engineering Principles
      • The big five…
      • Separation of Concerns
      • Abstraction
      • Modularity
      • Encapsulation
      • Information Hiding

DCIS 770 Lee Leitner              37
Separation of Concerns
      • Deal with different elements of a problem separately
      • Break a problem down into smaller, manageable
      • Divide and conquer
      • Reduce complexity
      • Assumption: We solve each piece of the problem,
        assemble the solutions and the whole is solved

DCIS 770 Lee Leitner                                           38
      • Details are subsumed into a greater whole
      • The whole is its own entity, made up of detail
        elements which we choose to currently ignore
      • Examples
            – An intersection of streets
            – Show up on time
            – Virtual machine

DCIS 770 Lee Leitner                                     39
Abstractions in Software
      • Key principles of abstraction in software
            – The abstraction abbreviates or simplifies what we
              are abstracting
                  • -- virtual machine
            – An abstraction characterizes a set of things
                  • -- an object oriented class
            – An abstraction is precisely defined
            – It is complete and accurate
            – It may be a member of a hierarchy

DCIS 770 Lee Leitner                                              40
      • Supports separation of concerns via
            – 1. Separating details of operations into separate
              units (modules)
            – 2. Separating methods of communication and
              relationship among the modules

      • Effects of modularity
            – Reduced complexity: the modular structure compels
              examination in part
            – also: decomposition reduces complexity by
              separation into subproblems

DCIS 770 Lee Leitner                                              41
                       Calculate sales tax

          Retrieve order item,
          locale and amount
                                             Multiply rate times
                          Look up rate
                          using locale

DCIS 770 Lee Leitner                                               42

      • Package operations along with the data the
        operations require
      • Create a cohesive entity -- a “package”
      • Access to the package is via an interface
      • Example: functions, abstract data types, objects

DCIS 770 Lee Leitner                                   43
Information Hiding
      • Use of a software entity is accomplished solely
        through its public interface
      • Implementation details are hidden from the
        interface and therefore from the clients of the
        software entity
      • Interface: A contract between the module and
        its clients
      • Client use depends only on the interface

DCIS 770 Lee Leitner                                      44
Sub-principles of Modularity

      • Cohesion
      • Coupling

            – Deal with structure of modules and how they

DCIS 770 Lee Leitner                                        45
      • Estimate of how closely operations of a routine
        are related
      • Also referred to as “strength”
      • High cohesion proven to reduce defects

DCIS 770 Lee Leitner                                      46
Acceptable Cohesion
      • Functional
            – Do one thing well and completely

      • Time related
            – Sequential
                  • Multiple operations; required sequence; shared data
            – Temporal
                  • Operations that are logically paired
                  • StartUp( ) and ShutDown( )

      • Communicational
            – Shared data

DCIS 770 Lee Leitner                                                      47
Unacceptable Cohesion
      • Procedural
            – Sequential without shared data

      • Logical or Control flow
            – Case statement with switch as parameter

      • Coincidental
            – No apparent basis for routine definition

DCIS 770 Lee Leitner                                     48
      • Connection of a routine to other routines
      • Goal: Low coupling
      • Considerations
            – Number of connections
            – Type of Connections
                  • Parameter, global data, shared file
            – Complexity of connections
                  • Passing structures to get a few pieces
                  • Undefined data puts information hiding at risk

DCIS 770 Lee Leitner                                                 49
Good Couples

       • Simple data
             – Elementary data types
             – Parms and just the parms

       • Data structures
             – Limit to parameters that are needed

DCIS 770 Lee Leitner                                 50
Odd Couples
      • Control switches and flags
            – Requires knowledge of internals
            – See also: Logical cohesion

      • Global data / external files
            – Loss of control
            – Loss of reusability

DCIS 770 Lee Leitner                            51
Quality and Software Engineering
What is Quality?

      • Quality is fitness for use
      • Quality is compliance to a standard
      • Quality is a degree of excellence
      • Quality means performing exactly like the

DCIS 770 Lee Leitner                                53
Definition: Software Quality

      • What is software quality?
      • What are the attributes of quality for

DCIS 770 Lee Leitner                             54
Software Qualities?
      • Stakeholder Visible
            – Satisfaction
                  • Do they like it?
            – Functionality
                  • Does it have the desired features?
            – Uniqueness
                  • Is it different?
            – Usability
                  • Is it easy to use?
            – Correctness
                  • Does it work as designed?

DCIS 770 Lee Leitner                                     55
Software Qualities

      • Stakeholder visible - continued
            – Robustness
                  • Does it handle unusual situations?
            – Reliability
                  • Can it be trusted?
            – Efficiency
                  • Is it fast enough?
            – Understandability
                  • Do they know how to use it?

DCIS 770 Lee Leitner                                     56
Software Qualities?
      • “Under the hood” - Developer visible
            – Reusability
               • Can the software be applied to other domains?
            – Maintainability
               • Can be changed?
            – Portability
               • Can it operate in other h/w, s/w environments
            – Integrity
                • Does it have an cohesive structure?
            – Interoperability
                • Can it communicate with other systems?
            – Testability
               • Can we confirm that is works correctly?
            – …

DCIS 770 Lee Leitner                                             57
Steps to Improve Quality
      • Improve the process
            – Assume that people want to do a quality job
                  • workers stopping assembly lines

      • Measurement
            – Measurement problems / soft data
            – People in the process know the most

      • Shift from inspection to prevention

DCIS 770 Lee Leitner                                        58
QA Techniques – The hit list
      • Formal QA activities
      • Validation and Verification Strategies
      • Software Development Guidelines
      • Technical Reviews
      • External Audits
      • Development Processes
      • Configuration and Change Control

DCIS 770 Lee Leitner                             59
Quality Attribute Tradeoff
      • Conflicts
            – Performance
            – Maintainability
            – Portability
            – Reliability

            – May not be able to optimize any of the above without
              compromising another

DCIS 770 Lee Leitner                                            60
Software Quality
      • What aspects of software make it particularly
        hard to achieve high quality?

      • Complexity
      • Conformity
      • Changeability

DCIS 770 Lee Leitner                                    61
      • Software is one of the most complex human
            – Fewer repeated elements
            – Many more states
            – Non-linear complexity growth

      • Resulting problems
            – Communicating
            – Understanding

DCIS 770 Lee Leitner                                62
      • Arbitrary complexity
            – Confluence of people, institutions, laws, etc.
            – Not based on unifying laws

      • An effect focused on software
            – Software embodies the system interface
            – Software as malleable

DCIS 770 Lee Leitner                                           63
      • “All successful software gets changed”
      • Much more change than for tangible objects
      • Why?
            – Perception that change is easy
            – It’s designed to be changed
            – Software must change responsively to its

DCIS 770 Lee Leitner                                     64
Development Life Cycles

Software Development Life Cycle
      •      Defines the concrete strategy to engineer
          some software artifact
      •      SDLC is separated into phases (steps,
          stages) “Phase Model”
      •      SLDC also determines the order of the
          phases, and the criteria for transitioning from
          phase to phase the “Phase Transition Model”

DCIS 770 Lee Leitner                                        66
Software Development Life Cycle
      • Or…
            – Is a model based upon empirical studies of industry
              software projects
                  • Common practices and processes
                  • A logical description of how software development is

DCIS 770 Lee Leitner                                                       67
      • Classical phase organization
            – “meta phases”

            – 1. Requirements analysis
            – 2. Design
            – 3. Implementation

      • Post SDLC phases
            – 4. Maintenance
            – 5. Retirement

DCIS 770 Lee Leitner                     68
SDLC Meta-Phases
      • Requirements Definition
            – Determine detailed needs of the project stakeholders.
              Document those needs. Verify that your understanding is
              complete and correct

      • Design
            – Synthesize a design to meet the requirements. Create a model
              or prototype. Verify the design meets requirements

      • Implementation
            – Make the design manifest. Create software artifacts based
              upon the design. Verify the work. Install the work in the
              stakeholder’s context. Ensure the users can properly apply the

DCIS 770 Lee Leitner                                                      69
SDLC Common Variations
      • The pre-requirements analysis phases
            – Preliminary investigation
                  • Bound the scope of the project
                  • Define the problem precisely
                  • Determine feasibility

      • Requirements definition to design transition
            – Specification Phase
                  • Determine the characteristics a software solution must
                    have to meet the requirements. What behaviors will
                    be necessary?

DCIS 770 Lee Leitner                                                    70
SDLC Common Variations
      • Design to Implementation phase
            – Prototyping phase
                  • Demonstrate design rather than describe it
                       – “Show Me”

      • Implementation phase breakdown
            – Implementation - coding
            – Testing
            – Installation

DCIS 770 Lee Leitner                                             71
SDLC Concrete Phase Model
      • Elements of a Phase
            – Activity definition
                  • What is the software engineer’s activity in this phase?
                  • A phase should deal with one engineering issue only -
                    - “high phase cohesion”
            – Required Inputs
                  • What is necessary to begin this phase?
                  • The necessary inputs can be outputs of other
                    phase(s) or the completion of a phase

DCIS 770 Lee Leitner                                                      72
SDLC Concrete Phase Model
      • Elements continued
            – Outputs
                  • a.k.a. Deliverables, Phase Products
                  • What is the output of this phase?
                  • All phases should have tangible well defined
            – Name
                  • What should we call this phase?

DCIS 770 Lee Leitner                                               73
SDLC Phase Transition Model
      • What are the rules for proceeding from phase to
            – What is/are the next phase(s)?
            – What is a required phase order?
            – What phases can/must be done concurrently?

DCIS 770 Lee Leitner                                       74
SDLC Phase Transition Models
      • Categories of PTMs that reflect real-world
        project experience

                  • Build and fix
                  • Waterfall
                  • Rapid prototyping
                  • Incremental
                  • Spiral Model

DCIS 770 Lee Leitner                                 75
Build and fix models
      • Getting it running and see what happens
      • Expectation is that fixing is possible
      • What about risk?
      • Elimination of detailed requirements
      • Quick transition from design into implementation

DCIS 770 Lee Leitner                                  76
Build and Fix Models

DCIS 770 Lee Leitner   77
Waterfall models
      • Linear sequence of phases
      • Each phase must be completed before next one
        is attempted
      • Precise definition of phase deliverables
      • Backtracking or iteration to prior phases
        possible, if indicated in the concrete model for
        the project

DCIS 770 Lee Leitner                                       78
      Waterfall model

DCIS 770 Lee Leitner    79
Rapid Prototyping
      • Prototype first: Once requirements are
        understood, develop an example of the
        essential requirements
      • Then proceed in a waterfall style to construct
        the actual product
      • Assumes throwaway prototype
            – Prototype may be evolutionary

DCIS 770 Lee Leitner                                     80
Rapid Prototyping

DCIS 770 Lee Leitner   81
Incremental Model
      • Deliver elements of the product in stages
      • Each delivery adds functionality not previously
      • Each delivery is an improvement to the
        previous delivery
      • Each delivery must leverage off of existing work
        without removing or destroying it
      • a.k.a. evolutionary model

DCIS 770 Lee Leitner                                      82
Incremental model

DCIS 770 Lee Leitner   83
Spiral Model
      • Boehm (1988)
            – Incremental model with risk assessment
            – Risk driven rather than document driven
            – Spiral through
                  • planning
                  • risk analysis
                  • engineering
                  • customer evaluation

DCIS 770 Lee Leitner                                    84
Spiral Model Simplified

DCIS 770 Lee Leitner      85
Spiral Model - Boehm

DCIS 770 Lee Leitner   86
SDLC Variations
      • Rapid Application Development
            – Prototype centered
                  • Prototype -> critique -> refine until done
            – Timebox oriented
                  • Fixed time to reach “done”
            – High degree of user involvement
            – Evolutionary prototypes
                  • prototype becomes production version
            – Throwaway prototype
                  • After “done” final product is built

DCIS 770 Lee Leitner                                             87
SLDC Variations
      • Joint Application Development (IBM)
            – User/workshop centered approach
            – Workshops to
                  • Glean requirements
                  • Develop prototype examples
                  • Finalize design
            – Users direct effort via leader
                  • Systems analysts observe

DCIS 770 Lee Leitner                             88
SLDC variations
      • Whirlpooling
            – Repeat a set of phases to narrow and focus into
              wringing out a set of requirements



DCIS 770 Lee Leitner                                            89
Rational Unified Process

DCIS 770 Lee Leitner       90
Rational Unified Process
      • Inception phase
            – focus on understanding requirements and determining scope

      • Elaboration phase
            – Focus on requirements, and prototype architecture, trying
              solutions to reduce risk, and using tools

      • Construction phase
            – Design and implementation

      • Transition phase
            – Focus on ensuring quality is present, training, and refinement

DCIS 770 Lee Leitner                                                       91
Synchronize and Stabilize

DCIS 770 Lee Leitner        92
Development Life Cycles
   Agile Software Development
    Extreme Programming (XP)

      • Agile Manifesto
      • Values:
      • Individuals and interactions over processes and tools
        Working software over comprehensive documentation
        Customer collaboration over contract negotiation
        Responding to change over following a plan


DCIS 770 Lee Leitner                                            94
Agile Processes
      • Principles behind the Agile Manifesto (
      • Our highest priority is to satisfy the customer through early and
        continuous delivery of valuable software.
      • Welcome changing requirements, even late in development. Agile
        processes harness change for the customer's competitive advantage.
      • Deliver working software frequently, from a couple of weeks to a couple
        of months, with a preference to the shorter timescale.
      • Business people and developers must work together daily throughout
        the project.
      • Build projects around motivated individuals. Give them the environment
        and support they need, and trust them to get the job done.
      • The most efficient and effective method of conveying information to and
        within a development team is face-to-face conversation.

DCIS 770 Lee Leitner                                                          95
Agile Processes
      • (Continued)
      • Working software is the primary measure of progress.
      • Agile processes promote sustainable development.
        The sponsors, developers, and users should be able
        to maintain a constant pace indefinitely.
      • Continuous attention to technical excellence and good design enhances
      • Simplicity--the art of maximizing the amount of work not done--is
      • The best architectures, requirements, and designs emerge from self-
        organizing teams.
      • At regular intervals, the team reflects on how to become more effective,
        then tunes and adjusts its behavior accordingly.

DCIS 770 Lee Leitner                                                           96
Extreme Programming (XP)
      • Kent Beck

      •       "Extreme Programming turns the conventional
          software process sideways. Rather than planning,
          analyzing, and designing for the far-flung future, XP
          programmers do all of these activities a little at a
          time throughout development."
      •                IEEE Computer October 1999

      •           also XP Book Series from AW

DCIS 770 Lee Leitner                                         97
   •                   Methodology is lightweight
        •              Oriented to smaller teams
        •              Supports vague requirements
        •              Emphasis
        •                     code reviews
        •                     testing
        •                     design and redesign
        •                     kis s
        •                     architecture
        •                     integration testing often
        •                     iterate with short iterations
        •                     code oriented
        •                     fun oriented

DCIS 770 Lee Leitner                                          98
      • What XP attempts to address
      •           Risks
      • schedule slippage, high defects, ignorant
        developers, needs changes, gold-plating…

DCIS 770 Lee Leitner                                99
      • Some key XP features
      •           Work in pairs
      •           Develop to make tests cases run
      •              When you can't think of more test cases and
          the ones you have run, you have added the
      •       Pairs also look at the meta level to evolve greater
          design -- point is to add value
      •      Follow development immediately with integration
          and integration testing

DCIS 770 Lee Leitner                                                100
      • Control Variables
      •           Cost
      •                     Too little or too much money can jeopardize a project
      •           Time
      •                     Too little development time -- damages quality, reduces scope

      •                     Too much development time -- delays production use feedback

      •           Quality
      •                     Sacrificing quality improves schedule at a severe cost
      •           Scope
      •                     With less scope, better quality can be delivered if stakeholder
                            satisfaction with the objectives is present

DCIS 770 Lee Leitner                                                                          101
      • Scope
      •           Highly variable
      •           Difficult for stakeholders to define
      •                 most have only a vague idea about what they
      •      Stakeholders redefine what they want based upon
          what they have gotten so far

      •           XP -- shape scope and keep scope small

DCIS 770 Lee Leitner                                             102
      • Shared values
      •           Communication
      •                  Build in practices that foster communication
      •                        pair programming
      •                        unit testing
      •                        estimation
      •           Simplicity
      •                Bet that it is better to do a simple thing today and
          pay a little more to change it tomorrow (if needed) than to do
          a more complicated thing today that may never be needed

DCIS 770 Lee Leitner                                                     103

      • Share values
      •           Feedback
      •                From the system itself - concrete feedback
      •                State of test cases
      •           Courage
      •                Make the effort
      •                Throw away what doesn't work
      •                Try new things

DCIS 770 Lee Leitner                                                104
      • Basic Principles
      •           Rapid feedback
      •                 Feed new knowledge back into the system
      •           Assume simplicity
      •                 Work on an extremely simply way to handle a
      •           Incremental change always
      •           Embrace change - don't fight it
      •           Do quality work

DCIS 770 Lee Leitner                                              105
      • Four Development Activities

      •           Coding
      •           Testing
      •           Listening & Observing
      •           Designing
      •                … put this last ?!?

DCIS 770 Lee Leitner                         106
•   Basic XP practices
•           Planning
•                      Determine scope of next release quickly
•           Small releases
•                      Put small versions into place and evolve with short cycles
•           Simple design
•                      Use simplest design you can conceive
•           Testing
•                    Always write unit tests that must run. Unit tests demonstrate that
    the feature is finished (or not). Determining unit tests comes first
•           Refactoring
•                      Restructure to simplify
•           Pair programming
•                      Two programmers on one computer

DCIS 770 Lee Leitner                                                                      107
      • Collective ownership
      •                  All code is accessible by anyone
      •           Continuous Integration
      •                  Build every time a task is completed
      •           40 hour week
      •                  Don't overwork
      •           On-site customer
      •                  Customer always available
      •           Coding standards
      •                  Emphasis communication

DCIS 770 Lee Leitner                                            108
      • Facilities
      •           Open workspace
      •           No barriers
      •           Chairs with wheels
      •           Lots of horizontal surfaces
      •        Room for two persons to work side by side at each

DCIS 770 Lee Leitner                                               109
      • XP Planning
      •           Write a story
      •                   Something the system needs to do
      •                           may use story cards
      •                   Development estimates how long story will take to
      •                   "Business" determines when they need the story done
      •                           Development commits
                                         this becomes an iteration
      •           Create tasks
      •                   Tasks implement stories
      •                           Task card
      •                   Programmer accepts task and finds partner
DCIS 770 Lee Leitner                                                            110
• XP Development
•           Task based
•                      Determine unit test cases needed
•                      Design and write code to run the test cases
•                      Make sure all unit tests cases work
•                      Add new unit tests as determined
•                      Simplify and refine the design!
•           Story & System Based
•                      Simplify and refine the overall design
•                      Determine integration tests
•                      Integrate and build

DCIS 770 Lee Leitner                                                 111
      • What makes XP hard
      •           Difficulty of simplification
      •           Scalability
      •       Organizations that do not work well with incremental
      •           Communication
      •           Egalitarian approach

DCIS 770 Lee Leitner                                                 112
      • Is the XP philosophy sound?

      • Beck: "We can drive ourselves crazy with expectation. But
        by preparing for every eventuality we can think of, we leave
        ourselves vulnerable to the eventualities we cannot imagine.
      •       There is another way. The team can be perfectly
          prepared at any moment to go in whatever direction the
          business or the system demands. By giving up explicit
          preparation for change, paradoxically they become entirely
          prepared for change. They expect nothing. They can no
          longer be surprised.

DCIS 770 Lee Leitner                                               113
Software Engineering Risks

What is a risk?
      • The possibility of meeting danger, suffering
        harm or loss, or exposure to harm or loss
      • There is uncertainty 0 < p < 1
      • Loss is possible
      • It is manageable -- its form and degree can be

DCIS 770 Lee Leitner                                     115
Project vs. Risk management
      • Project management: Control pervasive risks
        via systematic procedures

      • Risk management: Identify and manage the
        unique aspects of a specific project that might
        endanger its success

DCIS 770 Lee Leitner                                      116
Jones: 10 greatest software risks
      •   Inaccurate metrics
            –   tracking systems inaccurate
      •   Inadequate measurement
            –   tracking systems insufficient
      •   Excessive schedule pressure
            –   heroic measures need to complete according to schedule
      •   Management malpractice
            –   professional engineering management not employed
      •   Inaccurate cost estimating
            –   base costs not known well enough
      •   Silver bullet syndrome
            –   “we have the answer!”
      •   Creeping user requirements
            –   scope cannot be contained
      •   Low quality
            –   products has errors
      •   Low productivity
            –   slow progress
      •   Canceled projects
            –   large projects are more likely to be cancelled

DCIS 770 Lee Leitner                                                     117
Common Schedule Risks (McConnell)
            – Feature creep
            – Requirements or developer “gold-plating”
            – Shortchanged quality
            – Overly optimistic schedules
            – Inadequate design
            – Silver-bullet syndrome
            – Research-oriented development
            – Weak personnel
            – Contractor failure
            – Friction among developers and customers

DCIS 770 Lee Leitner                                     118
Runaway projects: Glass (1998)

      • Runaway project: “A project that goes out of
        control primarily because of the difficulty of
        building the software needed by the system.”

DCIS 770 Lee Leitner                                     119
Characteristics of runaway projects

      • Huge scope
      • Several contributing causes
      • Employment of leading edge technology,
        functionality or methodology
      • Stringent performance requirements
      • No risk management

DCIS 770 Lee Leitner                             120
Dorner: Logic of Failure (1989)
      •   Complexity
      •   Dynamic systems
      •   Intransparence: important issues are not visible
      •   ignorance
      •   mistaken hypotheses
      •   “Repair service” behavior
      •   Failure to recognize systemic issues
      •   Decomposition: Failure to see the whole
      •   Tendency to economize
      •   Tendency to make “ballistic decisions”

DCIS 770 Lee Leitner                                         121
      • Methodism
            – Do what we have done before
            – Act in a ritualized way
            – Don’t “start from scratch”

            – Limits range of possible action
            – Conservative
            – Fail to “break out” of established patterns

DCIS 770 Lee Leitner                                        122
Risk Management: Levels
      •   Crisis Management
            – fire fighting
      •   Fix on Failure
            – detect and react post facto
      •   Risk Mitigation
            – plan to cover risks when they occur
      •   Risk Prevention
            – Execute plan in a project to identify and prevent risks
      •   Elimination of root causes
            – prevent factors that make it possible for risks to occur
      •   (Source: McConnell 1996)

DCIS 770 Lee Leitner                                                     123
Risk Management Hierarchy (Boehm)

DCIS 770 Lee Leitner                124
Risk Assessment Evaluation (McConnell)

DCIS 770 Lee Leitner                     125
Mitigating Common Risks
      • Creeping Requirements
            – Smaller projects
            – Increase requirements, increase cost
            – Documented requirements

      • Schedule pressure/long schedules and
        excessive time to market
            – Smaller projects
            – Reusable modules

DCIS 770 Lee Leitner                                 126
Mitigating Common Risks
      • Cost Overruns
            – Experience
            – Improved cost estimation

      • Low quality/error prone modules
            – Defect prevention methods
            – Validation and verification

      • High maintenance costs
            – Reengineer error-prone modules
            – Simplify applications

DCIS 770 Lee Leitner                           127
Risks difficult to control

      • Excessive communication
      • Inadequate user documentation
      • Low user satisfaction
      • Friction between clients and contractors
      • Legal concerns

DCIS 770 Lee Leitner                               128
General strategies: Dorner
      • State goals clearly
      • Anticipate side effects
      • Adapt information gathering to the problem at hand
      • Avoid excessive abstraction
      • Avoid knee-jerk methodism
      • Do not act simply to prove you can act

      • Know when to stop gathering information

DCIS 770 Lee Leitner                                         129
General strategies: McConnell
      • Avoid
      • Transfer the risk to a less risky aspect of the system
      • Investigate it
      • Eliminate the root cause of the risk
      • Assume the risk
      • Publicize the risk
      • Control the risk
      • Remember it

DCIS 770 Lee Leitner                                             130
Software Reliability Engineering

Software Reliability Engineering (SRE)
      • Musa (1999)
      •           Attempt to address plagues of software development
      •                   Unreliability of production product
      •                   Missed schedules
      •                   Cost overruns
      •           Goals
      •                   Ensure product reliability meets requirements
      •                   Get product to market faster
      •                   Reduce product cost
      •                   Improve customer satisfaction
DCIS 770 Lee Leitner                                                      132
      • Focuses on
      •           Devoting resources to critical functions
      •                those having greatest value
      •                those having greatest impact during

      •           Make testing comprehensive and realistic

DCIS 770 Lee Leitner                                         133

                                                      SDLC Phase
  • Process
                                                      Requirements and
  •           Define necessary reliability            architectural definition

  •           Develop operational profiles
                                                          Design and
  •           Prepare for test                            Implementation

  •           Execute test
  •           Apply failure data to guide decisions

DCIS 770 Lee Leitner                                                         134
   • SRE Concepts
   •           Software failures are random
   •                      We are looking at actual behavior given typical user usage
   •       Testing is more scenario based, with the scenarios randomly
   •                      work with typical usage that will be encountered, not
       artificial tests
   •           Reliability is truly not improved by avoiding flaws
   •               user avoidance of weak features is actually redefining
   •         Do not have an objective of zero defects, but rather a balance of
       reliability, delivery date and cost
DCIS 770 Lee Leitner                                                                   135
      • Software reliability Defined
      •           A measure of confidence in design
      •           Compared to hardware reliability
      •                 Wear-out failures overwhelm design defect

      • Failure
      •           A behavior that does not meet requirements
      • Fault
      •           A cause for that behavior
DCIS 770 Lee Leitner                                                136
      • Defining Necessary reliability
      •           Determine classes of severity for the product
      •                   cost based (cost impact)
      •                   availability based
      •                   feature based (specific features fail)
      •           Define failure for each severity class
      •           Choose a common measure for all related systems
      •           Set a failure intensity objective for each system
      •                   failures per natural unit
      •                            natural unit -- transactions, pages of output,
          updates, etc.

DCIS 770 Lee Leitner                                                                137
      • Operational Profiles

      •           Determine different modes of operation
      •           Determine the operation initiators
      •           Create an operations list
      •           Figure the occurrence rates per hour of individual operations
      •       Determine the occurrence probabilities (divide individual
          occurrence rates by total occurrence rates)

DCIS 770 Lee Leitner                                                              138
      • Preparing for test
      •           Estimate number of test cases needed
      •                   Based on practical development considerations
      •           Allocate test cases among systems and operations
      •           Specifying new test cases
      •           Add new test cases

      • Execute test
      •           Analyze test output for deviations
      •           Determine deviations that are failures
      •           Assign to failure severity classes

DCIS 770 Lee Leitner                                                      139
      • Applying failure data:
      •           determine failure intensity
      •           compare to failure intensity objectives

DCIS 770 Lee Leitner                                        140
      • SRE Summary
      •      Build-in reliability rather than filter out
      •           Cousin to clean-room engineering

DCIS 770 Lee Leitner                                       141
                       Software Reuse

DCIS 770 Lee Leitner                    142
What is Software Reuse
      • Planned application of existing software in new
      • Repeated application of software artifacts in
        new situations
      • Accidental and Deliberate Reuse
            – Accidental - “Oh, we can reuse this piece!”

DCIS 770 Lee Leitner                                        143
Reuse outside of software
      • Engineering
      • Mass production
            – Parts and Components
                  • Nuts and Bolts
                       –   Sizing
                       –   Threading
                       –   Slotting
                       –   Embodied knowledge

DCIS 770 Lee Leitner                            144
Reuse in Software Engineering
      • Requirement Specification
      • Design
      • Patterns
      • Documentation
      • Code
      • Software Process

DCIS 770 Lee Leitner                145
Why Reuse?
      • Leverage
            – “Don’t reinvent the wheel”
            – Reduce labor cost

      • Programming
            – The problem of repetition in code
            – Success with accidental reuse

      • History of industry success

DCIS 770 Lee Leitner                              146
Benefits of Reuse

            – Cost savings
            – Time savings
            – Time-to-market improvement
            – Improved qualities
            – Uniformity
            – Reduced maintenance costs

DCIS 770 Lee Leitner                       147
Reuse Costs
      • Upfront expenses
      • Return on investment?
      • Process involvement
            – Design for reuse
            – Measure success by reuse

DCIS 770 Lee Leitner                     148
Kinds of Reuse
      • Producer Reuse
            – Create reusable components
                  • Intra-organizational
                  • Software vendors

      • Consumer Reuse
            – Use the components in systems
                  • Leverage off of existing knowledge

DCIS 770 Lee Leitner                                     149
Black-box reuse
      • Black-box Reuse
            – Use the reusable component without modification
                  • Microsoft Foundation Class Library
                  • PHIGS
                  • Prestored procedures
                  • Sort libraries

DCIS 770 Lee Leitner                                            150
Clear-box reuse
      • Modify the component for reuse
            – Code modifications
            – Configuration

      • Issue: Easy to write your own vs. modifying?
            – Central issue of build or “buy” decision!

DCIS 770 Lee Leitner                                      151
Reuse Composition and Generation
      • Composition
            – Components
                  • Operating system, DBMS, network
                       – functions and subroutines
                       – C is a case in point functions: printf …
                  • Class libraries
                  • Component repositories

      • Generation
            – Patterns
            – Templates
            – Application generators

DCIS 770 Lee Leitner                                                152
Reuse Steps
      • Collect
      • Store
      • Recall
      • Comprehend
      • Alter
      • Aggregate

DCIS 770 Lee Leitner   153
Reuse Engineering
      • Measurable reuse
      • Resolve reuse conflicts
      • Fund reuse
      • Distributed reuse costs/time over projects
      • Determine problem domains that are reuse
      • Integrate reuse into development process

DCIS 770 Lee Leitner                                 154
Domain Analysis
      • Domain - problem space for a family of
        applications having similar requirements
            – Subdomain
                  • contains related common assets or components
            – In domain analysis we can start with the problem first
                       – Then define applications and application commonality

DCIS 770 Lee Leitner                                                            155
Domain Engineering
            – Domain engineering - construction of design
              framework identified by domain requirements
                  • Identifies common reusable assets
                  • application engineering may reuse these assets

            – Domain analysis and engineering tools
                  • Structured analysis and design
                  • Object oriented modeling

DCIS 770 Lee Leitner                                                 156

      • Reconstruct systems to improve
            – maintainability
            – reliability
            – modifiability
            – portability

            – Usually no changes to functionality

DCIS 770 Lee Leitner                                158

                       •Source: Pressman

DCIS 770 Lee Leitner                       159
Inventory Analysis
      • Application identification
      • Chronology
      • System context
      • Databases
      • Business value
      • Technology employed
      • Business criticality

DCIS 770 Lee Leitner                 160
Document Restructuring
      • Determine what quality level of documentation
        is needed in the reengineered product
            – as is
            – updated
            – redone
                  • new document technology

DCIS 770 Lee Leitner                                    161
Reverse Engineering
      • Design Recovery
            – What was the original design?
            – Increase abstraction level from the code
            – Remove programming language dependencies

            – Requires
                  • Separation of code and data or
                  • Reconstruction of class interactions

DCIS 770 Lee Leitner                                       162
Code Restructuring
      • Improve modularity
      • Remove “obsolete” constructs
      • Object oriented: Refactoring == reorganize

      • Resulting code must be reverified

DCIS 770 Lee Leitner                                 163
Data Restructuring
      • Data within the program and data in a database
      • Program variables
            – Naming
            – Structures
            – Abstract data types

      • Databases
            – Relational design
            – Removal of obsolete attributes and relationships

DCIS 770 Lee Leitner                                             164
Forward Engineering
      • Renovate the program before the requirement
        to do so exists

      • Preventive maintenance approach
      • “Application of today’s methodologies to
        yesterday’s systems to support tomorrow’s
                       » Miller

DCIS 770 Lee Leitner                                  165
Cost Benefit Analysis Model
      •   P1 = current annual maintenance cost
      •   P2 = current annual operation cost
      •   P3 = current annual business value
      •   P4 = predicted annual maintenance cost after reengineering
      •   P5 = predicted annual operations cost after reengineering
      •   P6 = predicted annual business value after
      •   P7 = estimated reengineering costs
      •   P8 = estimated reengineering calendar time
      •   P9 = reengineering risk factor P9= 1.0 nominal
      •   L = expected life of system in years
      •   Cmaint = [P3 - (P1+P2)] * L
      •   Creeng = [P6-(P4+P5) * (L - P8) - (P7 * P9)]
      •   Cost benefit = Creeng - Cmaint\\

DCIS 770 Lee Leitner                                                   166
Patterns and Software Architecture


      • Origin
      •      Architecture -- Christopher Alexander
      •        “Each pattern describes a problem which occurs over and
          over again in our environment, and then describes the core of the
          solution to that problem, in such a way that you can use the
          solution a million times over, without ever doing it the same way
      •           Examples
      •                promenade            interchange
      •                row houses           common land
      •                raised walk          small parking lots
DCIS 770 Lee Leitner                                                     169
      •   Alexander's Paradigm
      •           The Quality (without a name)
            • The essence of things that are useful and living that gives us satisfaction,
              pleasure and ultimately improves the human condition. It is a collection of
              qualities including harmony, completeness, adaptability and freedom.

      •           The Gate
            • The mechanism we use to reach the quality. A common language of
              patterns to create multi-form designs that fulfill multifacted needs. The gate
              is the conduit to the quality.

            • The Way (The Timeless Way)
            •     Using the way, patterns from the gate are applied by evolving
                differentiations from an initial architecture through a live design having the
                quality. It is a process of unfolding. By following the way, one may pass
                through the gate to reach the quality.

DCIS 770 Lee Leitner                                                                             170
Introduction to Patterns
• Early work:
•        1987 Ward Cunningham and Kent Beck OOPSLA '87 paper on
    patterns for object oriented programs

•        1991 Jim Coplien book Advanced C++ Programming Styles and

•        1993 Hillside Group formed for pattern exploration, PLoP

•        1995 Design Patterns: Elements of Reusable Object-Oriented
•                      Gamma, Helm, Johnson, Vlissides (a.k.a. “Gang of four”)
•                             Developed pattern set for object oriented design
DCIS 770 Lee Leitner                                                             171
      • Later work

      •           Extensions of patterns to
      •                 project management
      •                 configuration management
      •                 organizations
      •                 requirements definition

      •           Antipatterns

DCIS 770 Lee Leitner                               172
         • What is a Pattern?
         • A pattern is an idea that has been useful in one
           practical context and will probably be useful in others
         • Value of a pattern: Degree of usefulness
         • Important characteristics of a pattern
         • It solves a problem
         • It is a proven concept
         • The solution isn't obvious
         • It describes relationships
         • The pattern has a significant human component

DCIS 770 Lee Leitner                                                 173
  • Elements of a pattern
        – Pattern name
              • Adds to design vocabulary
              • Increases abstraction level
        – Problem
              • Describes when to apply the pattern
              • Problem and context
              • Prerequisites
        – Solution
              • Elements that make up the design
                       – template oriented

        – Consequences
              • results and tradeoffs

DCIS 770 Lee Leitner                                  174
      • Pattern Languages
      •           A collection of of patterns
      •           A shared objective
      •           Pattern -> recurring solution
      •                   Pattern language -> collective of related solutions
      •           Rules to combine patterns into an architectural style
      •           Solution framework
      •        Balances "forces" to create an architecture that is durable,
          functional and pleasing
      •        Rules and guidelines explaining how and when to apply patterns
      •           Lexicon of patterns
      •       Generative -- can create new "sentences" from the pattern
DCIS 770 Lee Leitner                                                            175
      •   Gang of Four Examples

      •   Abstract Factory
            – Provide an interface for creating families of related or dependent objects
              without specifying their concrete classes.
      •   Adapter
            – Convert the interface of a class into another interface clients expect. Adapter
              lets classes work together that couldn't otherwise because of incompatible

      •   Builder
      •   Separate the construction of a complex object from its representation so that the
          same construction process can create different representations.
      •   Chain of Responsibility
            – Avoid coupling the sender of a request to its receiver by giving more than
              one object a chance to handle the request. Chain the receiving objects and
              pass the request along the chain until an object handles it.
DCIS 770 Lee Leitner                                                                       176
      • Gang of Five
      •           3 levels of patterns

            – Architectural patterns
                  • Fundamental organization schemas for software

            – Design patterns
                  • Commonly recurring structure of communicating components that
                    solve a general design problem

            – Idioms
                  • Low level patterns specific to a programming language

DCIS 770 Lee Leitner                                                           177
•           Gang of Five
•            Architectural Patterns: Organizational schema
•                      Examples
•                                 Layers
      –                           Pipes and filters
      –                           Blackboard
      –                           Distributed systems
      – Design Patterns: Software Design
      –                Examples
      –                           Whole-part (structural decomposition)
      –                           Master-slave (work organization)
      –                           Proxy (access control)
      –                           Command processor (Management)

      – Idioms: Idioms are language specific
      –     With a set of idioms, a coherent programming style emerges
      –                Example
      –                           Idented control flow
DCIS 770 Lee Leitner                                                      178
      • Analysis Patterns (Fowler 1997)

      • Models for wide range of problem domains
            – Focuses on
                  • trading
                  • measurement
                  • accounting
                  • organizational relationships
                  • communication

DCIS 770 Lee Leitner                               179
      •    Pattern: Best practice
      •    Antipattern: Lesson Learned (Koenig 1995)
      •           Two varieties
      •                 1. describe a bad solution to a problem which
           resulted in a bad situation
      •                2. describe how to get out of a bad situation and how
           to proceed from there to a good solution.

      •    Brown et al. (1998, 1999, 2000)
            – Identification via patterns of software, project and software
              configuration management in trouble
            –                     Refactoring: Altering the structure of the software
                                  without changing its functionality

DCIS 770 Lee Leitner                                                                    180
      • Objectives of Antipatterns

            – Efficiently map a general situation to a specific class
              of solutions
            – Pragmatic approach to real world situations,
              supplying a detailed remedy
            – Common problem vocabulary
            – Holistic resolution of conflicts, facilitating
              communication among stakeholders
            – “Stress relief” for common “misery” in the software

DCIS 770 Lee Leitner                                                181
      • Address problems caused by
            – haste
            – apathy
            – narrow-mindedness
            – sloth
            – greed
            – ignorance
            – pride

DCIS 770 Lee Leitner                 182

          Solution              Alterations



DCIS 770 Lee Leitner                                      183
      •   Examples from Brown, 1998

      •   Name: The Blob
      •   a.k.a. Winnebago, God Class
      •   Evidence: One class monopolizes processing. One class is the “heart” of the system
      •   Refactored Solution Name: Refactoring of responsibilities
      •   Technique: Separate responsibilities according to contracts. Collect common contracts.
          Find homes for these contracts

      •   Name: Cut and Paste Programming
      •   a.k.a. clipboard programming
      •   Evidence: Thought bug was fixed, but error keeps recurring. Clear box reuse was
      •   Refactored solution name: black box reuse
      •   Technique: replace clear box reuse with black box reuse

DCIS 770 Lee Leitner                                                                               184
      •   Name: Nil Desperandum (No cause for despair, then)
      •   Also Known as: Relax, Don't do it; Don't Worry, Be Happy
      •   Most Applicable Scale: System
      •   Refactored Solution Name: No Pain, No Gain
      •   Refactored Solution Type: Process
      •   Root Causes: Haste, Narrow-Mindedness, Sloth
      •   Anecdotal Evidence:
      •           Tell us what you want and we'll code it.
      •           We don't need to design
      •           there is no visible or disjoint software process
      •   Consequences
      •           Cost overruns, technical failure, premature termination
      •   Refactored Solution
      •           Assess hidden successful processes
      •           Map a new successful end-to-end process

DCIS 770 Lee Leitner                                                        185
Patterns and Antipatterns
      • Further Extensions
      •           Software architectural styles (Shaw/Garlan)

      • Question
      •       What do patterns (and antipatterns) contribute to the
          research and practice of software engineering?

DCIS 770 Lee Leitner                                                  186
                       • Software Architecture

DCIS 770 Lee Leitner                             187
Software Architecture
      • What is software architecture
      •           What is architecture?
      •           From Webster's:
      •         1 : the art or science of building; specifically : the art or practice of
          designing and building structures and especially habitable ones
          2 a : formation or construction as or as if as the result of conscious act
          <the architecture of the garden> b : a unifying or coherent form or
          structure <the novel lacks architecture>
          3 : architectural product or work
          4 : a method or style of building
          5 : the manner in which the components of a computer or computer
          system are organized and integrated

DCIS 770 Lee Leitner                                                                    188
Software Architecture
  • "The software architecture of a program or computing system is the
    structure or structures of the system, that comprise software
    components, the externally visible properties of those components, and
    the relationships among them.
  •                    Bass, Clements & Kazman (1998)

  •           Other views
  •                    high level design
  •                    overall structure
  •                    components and interaction over time
  •                    components, connectors and constraints
  •                            and rationale

DCIS 770 Lee Leitner                                                         189
Software Architecture
      • Other important term
      •           Architectural Style
      •              Description of component types and a
          pattern of their runtime control and/or data transfer or
      •              a family of systems defined in terms of a
          pattern of structural organization

      •                 defines a class of architecture
      •                 abstraction for a set of architectures
DCIS 770 Lee Leitner                                                 190
Software Architecture
      •   Problems with our ideas about software architecture
      •           informal descriptions
      •                    (although there is work on Architectural Description Languages)
      •           incomplete
      •           lack detail
      •           do not allow reasoning about qualities of the system
      •           not easily comparable
      •           not easily tested for consistency with the implementation
      •           much implicit knowledge assumed

DCIS 770 Lee Leitner                                                                     191
Software Architecture
      • Why architecture?
      •           We want a system having certain properties
      •       A pre-existing architecture that is reused provides some
      •           An architecture imposes order
      •           An architecture provides a framework for desired qualities

DCIS 770 Lee Leitner                                                           192
Software Architecture
•   Where do software architectures come from?
•           Influences:
•                      Business
•                                  Organizational needs -> system requirements
•                                  Organizational structure
•                                  Organizational goals
•                                  Stakeholder objectives
•                      Technical
•                                  Computational models
•                                  Data models
•                                  Available technologies
•                                  Understood technologies
•                      Social
•                                  Communication with the architect and among all parties
•                                  Informal organizational structure
•                                  Experience of the architect

DCIS 770 Lee Leitner                                                                        193
Software Architecture
      • Architecture Recovery
      •           can you reconstruct the architecture from the implementation?
      •           Elements (Jazayeri, Ran, Linden, 2000)
      •                   Domain independent properties
      •                      System structure, system control, data
          communications and dynamic structure
      •                   Domain dependent properties
      •                           required qualities, including functionality
      •                   Product family properties
      •                           Configuration controls
      •                           Reused components

DCIS 770 Lee Leitner                                                              194
Software Architecture
•   Several current models (Zachman, ODP, Domain Analysis, Rational)

•   Reference Model Open Distributed Processing (OSI)
•           Five viewpoint
•                      Enterprise
•                              Business purpose, scope, policies
•                      Information
•                              meaning of information and information processing
•                      Computational
•                              modules and interfaces enabling distribution
•                      Engineering
•                              mechanisms of distribution
•                      Technology
•                              choice of technology and component details

DCIS 770 Lee Leitner                                                               195
Software Architecture
      • Architectural Style (Shaw & Garlan)
            – Family of systems defined in terms of a pattern of
              structural organization
                  • Design vocabulary
                  • allowable structural patterns
                  • underlying computational models
                  • essential elements (invariants) of the style
                  • common examples
                  • advantages/disadvantages
                  • common specializations

DCIS 770 Lee Leitner                                               196
Underlying Architectural Styles
          •    Dataflow systems
          •            Pipes and filters
          •    Call and Return systems
          •            Subroutines
          •            Objects
          •            Layering
          •    Independent Components
          •            Implicit Invocation
          •    Data Centered Systems
          •            Repositories
          •            Databases
          •            Blackboards
          •    Virtual Machines
          •            Interpreters
          •            Rule based systems
DCIS 770 Lee Leitner                         197
Pipes and Filters
      • Components have input/output sets
      • Components are connected
      • Local input transformations (filtering)

                                                  Source: Shaw/Garlan

DCIS 770 Lee Leitner                                                    198
      • Encapsulated data and operations
      • Communication between objects

                                     Source: Shaw/Garlan

DCIS 770 Lee Leitner                                       199
Implicit Invocation
      • Component broadcasts an event
            – does not invoke a procedure

      • System invokes procedures that “handle” the
            – Network example: inetd process starts processes to
              handle tcp/ip connection requests on various port

DCIS 770 Lee Leitner                                           200
      • Each software component provides a service
      • Communicates in a hierarchy with layers above and below

                                              •Source: Shaw/Garlan

DCIS 770 Lee Leitner                                                 201
      • “Database or environment clients simultaneously

                                         •Source: Shaw/Garlan

DCIS 770 Lee Leitner                                            202
      • Input is treated as a language
      • Program processes the grammar syntax and semantics

                                          •Source: Shaw/Garlan

DCIS 770 Lee Leitner                                             203
Software architecture

      • The link between architectural styles and patterns

      •       Software architectural styles can be seen to be
          composed of patterns that are repeated within the
          context of each engineering effort.

DCIS 770 Lee Leitner                                            204
Software Architecture
      • Contribution of Software Architecture
      •           A high-level design step
      •       A method to integrate user requirements with a
      •       An attempt to gain the advantages we perceive
          architectural designers have in other disciplines
      •           A useful abstraction layer

DCIS 770 Lee Leitner                                           205
Software Engineering
      • Cluster 1 Topics
            – Introduction
            – Principles
            – Qualities
            – Development Life Cycles
            – Software Engineering Risks
            – Software Reliability Engineering
            – Reuse
            – Reengineering
            – Patterns
            – Software Architecture

DCIS 770 Lee Leitner                             206