Docstoc

CISD 770

Document Sample
CISD 770 Powered By Docstoc
					DCIS 770

Software Engineering


Lee Leitner, Ph.D.
leitnerl@nova.edu




      1
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      http://www.swebok.org
            – 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?
     Bits?
     Algorithms and Data Structures?




                           9
Software


      • 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


                                   •Hammer
                                     •Wood handle
                                     •Metal Head
                                     •Handle shape/feel
                                     •Hardness of head
                                     •Shape of head
                                     •Hook
                                     •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
        (users/stakeholders)


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
              process




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
         artifacts




DCIS 770 Lee Leitner                                   25
COTS Integration

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



       • Software engineering coupled with software
         integration




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
COTS
      • 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
        software




DCIS 770 Lee Leitner                                       31
COTS Supportability
      • In-house or outside support?
      • No structural tests possible in most cases by the
        licensee
      • 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
        either
      • if you deliver 80% of desired functionality, how
        well are doing in comparison with a COTS
        solution?


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
        elements
      • 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
Abstraction
      • 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
Modularity
      • 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
Modularity
                       Calculate sales tax


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




DCIS 770 Lee Leitner                                               42
Encapsulation


      • 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
              communicate




DCIS 770 Lee Leitner                                        45
Cohesion
      • 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
Coupling
      • 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
        requirement




DCIS 770 Lee Leitner                                53
Definition: Software Quality


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




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
Complexity
      • Software is one of the most complex human
        endeavors
            – Fewer repeated elements
            – Many more states
            – Non-linear complexity growth

      • Resulting problems
            – Communicating
            – Understanding



DCIS 770 Lee Leitner                                62
Conformity
      • 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
Changeability
      • “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
              environment




DCIS 770 Lee Leitner                                     64
Development Life Cycles




        65
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
                    done




DCIS 770 Lee Leitner                                                       67
SDLC
      • 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
              software.


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
                    deliverables
            – 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
        phase?
            – 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
        investigation
      • 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
        provided
      • 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


                       Req



                                    Design



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)




     93
      • 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


      • http://www.agilemanifesto.org




DCIS 770 Lee Leitner                                            94
Agile Processes
      • Principles behind the Agile Manifesto (www.agilemanifesto.org)
      • 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
        agility.
      • Simplicity--the art of maximizing the amount of work not done--is
        essential.
      • 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
  XP
   •                   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
XP
      • What XP attempts to address
      •           Risks
      • schedule slippage, high defects, ignorant
        developers, needs changes, gold-plating…




DCIS 770 Lee Leitner                                99
XP
      • 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
          functionality
      •       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
XP
      • 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
XP
      • Scope
      •           Highly variable
      •           Difficult for stakeholders to define
      •                 most have only a vague idea about what they
                        want
      •      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
XP
      • 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
XP

      • 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
XP
      • Basic Principles
      •           Rapid feedback
      •                 Feed new knowledge back into the system
                        asap
      •           Assume simplicity
      •                 Work on an extremely simply way to handle a
                        problem
      •           Incremental change always
      •           Embrace change - don't fight it
      •           Do quality work

DCIS 770 Lee Leitner                                              105
XP
      • Four Development Activities


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

DCIS 770 Lee Leitner                         106
XP
•   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
XP
      • 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
XP
      • Facilities
      •           Open workspace
      •           No barriers
      •           Chairs with wheels
      •           Lots of horizontal surfaces
      •        Room for two persons to work side by side at each
          station




DCIS 770 Lee Leitner                                               109
XP
      • XP Planning
      •           Write a story
      •                   Something the system needs to do
      •                           may use story cards
      •                   Development estimates how long story will take to
                          implement
      •                   "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
• 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
XP
      • What makes XP hard
      •           Difficulty of simplification
      •           Scalability
      •       Organizations that do not work well with incremental
          planning
      •           Communication
      •           Egalitarian approach




DCIS 770 Lee Leitner                                                 112
XP
      • 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




     114
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
        changed




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
Dorner
      • 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




               131
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
SRE
      • Focuses on
      •           Devoting resources to critical functions
      •                those having greatest value
      •                those having greatest impact during
          failure


      •           Make testing comprehensive and realistic


DCIS 770 Lee Leitner                                         133
SRE

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

  •           Develop operational profiles
                                                          Design and
  •           Prepare for test                            Implementation

                                                          Test
  •           Execute test
  •           Apply failure data to guide decisions




DCIS 770 Lee Leitner                                                         134
SRE
   • 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
       sequenced
   •                      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
       requirements
   •
   •         Do not have an objective of zero defects, but rather a balance of
       reliability, delivery date and cost
DCIS 770 Lee Leitner                                                                   135
SRE
      • Software reliability Defined
      •           A measure of confidence in design
      •           Compared to hardware reliability
      •                 Wear-out failures overwhelm design defect
                        failures


      • Failure
      •           A behavior that does not meet requirements
      • Fault
      •           A cause for that behavior
DCIS 770 Lee Leitner                                                136
SRE
      • 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
SRE
      • 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
SRE
      • 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
SRE
      • Applying failure data:
      •           determine failure intensity
      •           compare to failure intensity objectives




DCIS 770 Lee Leitner                                        140
SRE
      • SRE Summary
      •      Build-in reliability rather than filter out
          unreliability
      •           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
        situations
      • 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
        candidates
      • 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
                         second




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
Reengineering




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


            – Usually no changes to functionality




DCIS 770 Lee Leitner                                158
Reengineering




                       •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
        classes


      • 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
        applications”
                       » 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




               167
      Patterns




168
Patterns
      • Origin
      •      Architecture -- Christopher Alexander
          (~1977):
      •        “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
          twice.”
      •           Examples
      •                promenade            interchange
      •                row houses           common land
      •                raised walk          small parking lots
DCIS 770 Lee Leitner                                                     169
Patterns
      •   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
    Idioms


•        1993 Hillside Group formed for pattern exploration, PLoP
    conferences


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


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


      •           Antipatterns

DCIS 770 Lee Leitner                               172
Patterns
         • 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
Patterns
  • 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
Patterns
      • 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
          within
      •           Lexicon of patterns
      •       Generative -- can create new "sentences" from the pattern
          vocabulary
DCIS 770 Lee Leitner                                                            175
Patterns
      •   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
              interfaces.


      •   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
Patterns
      • 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
Patterns
•           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
Patterns
      • Analysis Patterns (Fowler 1997)


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


DCIS 770 Lee Leitner                               179
AntiPatterns
      •    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
Antipatterns
      • 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
              industry

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



DCIS 770 Lee Leitner                 182
Antipatterns


          Solution              Alterations


                                Problem
                                              Refactor

                                               Solution
                       Antipattern




DCIS 770 Lee Leitner                                      183
Antipatterns
      •   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
          employed.
      •   Refactored solution name: black box reuse
      •   Technique: replace clear box reuse with black box reuse



DCIS 770 Lee Leitner                                                                               184
Antipatterns
      •   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
          assurances
      •           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
Objects
      • 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
        event
            – Network example: inetd process starts processes to
              handle tcp/ip connection requests on various port
              numbers




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




                                              •Source: Shaw/Garlan

DCIS 770 Lee Leitner                                                 201
Repositories
      • “Database or environment clients simultaneously
          update/access




                                         •Source: Shaw/Garlan


DCIS 770 Lee Leitner                                            202
Interpreter
      • 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
          framework
      •       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

				
DOCUMENT INFO