Docstoc

Software architecture (PowerPoint)

Document Sample
Software architecture (PowerPoint) Powered By Docstoc
					Chapter 2. Software architecture
  • Architecture style
  • OOSE review
  • Software architecture
  • Layered architecture
           Architecture style
• System that share a similar high-level
  structure are said to have a similar
  architecture style
• Approaching reuse without understanding
  architecture style is like starting to construct
  a building without knowing if it will be a
  skyscraper or a garage
• Software of the same architecture style can
  be reused easier than those of different
  architecture styles
           Architecture style
• An architecture style is defined by the type
  of constructs that can be reused to engineer
  a system
• Definition: the architecture style of a system
  is the denotation of the modeling languages
  used when modeling that system
• Example: UML (which is a modeling
  language) defines an architecture style
             OOSE review
• Software reuse in the text book is closely
  related to OOSE of I. Jacobson. Therefore,
  we review the OOSE in the following slides
• Jacobson’s OOSE technique includes the
  following phases: analysis, construction,
  and testing
Example
             Analysis phase
• Purposes of analysis:
  – To capture requirements
  – To represent requirements in models
• Products of the analysis phase
  – Requirement model: to describe system
    functionality
  – Analysis model: to describe objects that
    accomplish system functionality
  Analysis phase – requirement
             model
• The requirement model describes system
  functionality
• The model is composed of use case diagram,
  interface description, and domain objects
  Analysis phase – requirement
             model
• The use case diagram is composed of:
  – Actors
  – Use cases
  – Relationships among use cases
• The interface description describe how the
  user can use the system.
• The domain objects are objects identified in
  the problem domain
Use case diagram
Use case description
  Analysis phase – analysis model
• The analysis model is a robust model to adapt
  to change, which uses interface objects, entity
  objects, and control objects to describe system
  functionality
• Creating analysis model corresponding to
  assigning functionality of use cases to objects
  (see figure in the next slide)
  Analysis phase – analysis model
• The following functionality should be
  allocated to interface objects
  – Those present information to actors or request
    information from actors
  – Those change when actors’ behavior change
  – Those depend on a particular interface type, e.g.,
    changing card types results in changing the input
    device of the ATM machine
Interface objects
  Analysis phase – analysis model
• Entity objects model the information that a
  system will handle over a long time
• Possible entity objects:
  – Those mapped to problem domain objects
  – The information that should be remembered
• Operations of entity objects can be identified
  from use case functionality
Analysis phase – analysis model
• Control objects are used to improve
  robustness of the analysis model
• Behaviors that are sensitive to change can
  be allocated to control objects, e.g.,
  workflow in a MIS
• Behaviors that are not suitable for other
  objects can also be allocated to control
  objects
Analysis phase – analysis model

• Use cases can be described by analysis
  objects as shown in the figure of the next
  slide
         Construction phase
• Two models are developed in the
  construction phase, namely the design
  model and the implementation model
• The implementation model is the program
  code
    Construction phase - design
              model
• The design model is developed based on the
  analysis model; implementation
  environment is taken into consideration
• The considered environment factors
  includes platform, language, DBMS,
  constraints, reusable components, libraries,
  and so on
    Construction phase -design
              model
• Design objects in the design model are
  different from analysis objects
• The design model also models design object
  interactions, design object interface, and
  design object semantics (i.e., algorithms of
  design objects’ operations)
    Construction phase - design
              model
• In the design process, the analysis model is
  first transferred into the initial design model
  (figures in the next slides). Then,
  implementation environment factors are
  incorporated. For example, the “extend”
  relationship should be replaced by “invoke”
  relationship because no OO programming
  language supports the former
Take a deep breath and
 be ready for the other
     presentations
        Software architecture
• Software architecture defines system
  structures, interfaces, and interaction
  patterns
• Example architectures: see the next slides
Call and return architecture
object                 object




 object               object




Object-oriented architecture
        Software architecture
• Definition: software architecture defines the
  static organization of software into
  subsystems interconnected through
  interfaces and defines at a significant level
  how nodes (sites) executing those software
  subsystems interact with each other.
          Software architecture
• A good architecture facilitates controlling
  software complexity and allows large
  organizations to work on parts in parallel
• An architecture should be robust. That is, it can be
  adapted to change (or change should be predicted)
• A good architecture acts as a guide to which
  components should be reused during the
  development of application systems
         Layered architecture
• Before discussing layered architecture, we
  give some definitions below:
  – Software workproduct: a product or sub-
    product produced in a software engineering
    phase. For example, a subsystem of a design
    document can be regarded as a software
    workproduct
  – Asset: high-quality software workproductsthat
    can be reused
         Layered architecture
• Some definitions (cont.)
  – Component: an element of a development
    model (i.e., software) that is loosely coupled
    and promised to be reusable. Under this
    definition, all software workproducts are
    potentially components or sources of
    components.
  – Component system: a set of related components
    that accomplish some function larger than that
    accomplished by a single component. In other
    words, a component system is a larger
    component composed of components or
    component systems. Component systems thus
    facilitate large-scale reuse.
         Layered architecture
• Some definitions (cont.)
  – Facade: an aspect of a component system a
    reuser needs to know when he/she reuses the
    component system. A facade exports only those
    a reuser needed and encapsulates other details
    of a component system. (Take facade in mind,
    it is the primary concept in the text book).
         Layered architecture
• The sense behind the layered architecture:
  – Application systems can be built from
    component systems
  – Component systems may in turn be built from
    components in lower layers
• The sense above results in a layered system
  defined by a layered architecture (see the
  figure in the next slide)
 Middleware

System software
         Layered architecture
• Definition: a layered architecture is a
  software architecture that organizes
  software in layers. Each layer is built on top
  of another more general layer. A layer can
  loosely be defined as a set of (sub)systems
  with the same degree of generality. Upper
  layers are more application specific and
  lower are more general
         Layered architecture
• The number in a layered architecture may
  be varied from situation to situation. For
  example, the business-specific layer (see the
  figure in the slide before the previous slide)
  can be composed of more than one layer
         Layered architecture
• The topmost layer (application systems
  layer) contains application systems offering
  coherent set of use cases to end users. Some
  application systems may possess more than
  one version (or variant)
• The business-specific layer contains a
  number of component systems specific to
  the type of business (i.e., specific to a
  problem domain). Such component systems
  include use case and object components.
  This layer is the focus of my presentation.
        Layered architecture
• The middleware layer offers components
  systems providing utility classes and
  platform-independent services such as
  distributed object computing in
  heterogeneous environments. Examples in
  this layer are GUI builders, DBMS
  interfaces, CORBA broker, and so on. This
  layer is the focus of your presentation
         Layered architecture
• The system software layer contains the
  software for the computing and networking
  infrastructure, such as OS, interfaces to
  specific hardware (i.e., drivers), sockets,
  and so on. Some components in this layer
  are hardware (or platform) dependent

				
DOCUMENT INFO