CTIS 359 PRINCIPLES SOFTWARE ENGINEERING

1
CTIS 359 PRINCIPLES SOFTWARE ENGINEERING

• WEEK 9
• ARCHITECTURAL DESIGN

2
OBJECTIVES

• To introduce architectural design and to discuss
  its importance
• To explain the architectural design decisions
  that have to be made
• To introduce three architectural styles covering
  organization, decomposition, and control

3
SOFTWARE DESIGN

• The essence of software design is making
  decisions about the logical organization of the
  software.
• Software design is a creative process.
• There is no right ot wrong way to design
  software.
• There is no recipe for software design.
• You learn how to design by looking at examples of
  existing designs and by discussing your design
  with others.

4
ARCHITECTURAL DESIGN

• Large systems are always decomposed into
  sub-systems that provide some related set of
  services.
• The initial design process of identifying these
  sub-systems and establishing a framework for
  sub-system control and communication is called
  architectural design.
• Architectural design represents a critical link
  between the design and requirements engineering
  processes.

5
ARCHITECTURAL DESIGN

• Forces software designers to consider key design
  aspects.
• Serves as a design plan that is used for
  structuring discussions with customers,
  developers, and managers.
• Often carried out in parallel with specification
  activities.
• Affects the performance, robustness, and
  distributability.
• Depends on non-functional requirements.

6
ARCHITECTURAL DESIGN

• Performance Component communications should be
  reduced.
• Security Layered structure should be used.
  Security validation should be used.
• Availability Redundant components should be
  used so that no matter what system can continue
  its operation.

7
SUB-SYSTEM DESIGN

• Deciding how to decompose a system into
  sub-systems is difficult.
• The system requirements are a major factor.
• Try to create a design where there is a close
  match between requirements and sub-systems.

8
ROBOT SYSTEM ARCHITECTURE
9
SUB-SYSTEM DESIGN

• Sub-system design is the decomposition of a
  system, each of which maybe substantial system.
• Block diagrams are often used to describe
  sub-system design where each box represents a
  sub-system.
• Arrows mean that data are passed from sub-system
  to sub-system in the direction of the arrows.
• Some people think block diagrams are not useful
  from the software perspective. Still, it is
  effective for communication between stakeholdes
  and for project planning (For example, creation
  of WBS)

10
ARCHITECTURAL DESIGN DECISIONS

• Establishes a system organization that will
  satisfy the functional and non-functional system
  requirements.
• Decisions such as use of generic application
  architecture, system distribution across multiple
  processors or computers, and strategy to control
  the operation have to be made.

11
SYSTEM ORGANIZATION

• Repository model - subsystems making up a system
  must exchange information so that they can work
  together.
• Client-Server model system is organized as a
  set of services.
• Layered model system is organized into layers,
  each of which provide a set of services.

12
REPOSITORY MODEL

• Two ways to do it
• All shared data is held in a central database
  that can be accessed by all subsystems.
• Each sub-system maintains its own database. Data
  is interchanged with other sub-systems by passing
  messages to them.

13
REPOSITORY MODEL
14
CLIENT-SERVER MODEL

• The major components are
• Set of servers offer services to other
  sub-systems (clients). Examples are print servers
  that offer printing services, file servers that
  offer file management services.
• Set of clients call on the services offered by
  servers. There may be several instances of a
  client program executing concurrently.
• Network Not strictly necassary as both clients
  and servers could run on a single machine. In
  practice, most client-server systems are
  implemented as distributed systems.

15
CLIENT-SERVER MODEL
16
LAYERED MODEL
17
LAYERED MODEL

• Configuration Management layer manages versions
  of objects and provides general configuration
  management facilities.
• Object Management layer provides information
  storage and management services.
• Database layer provides data storage and services
  such as transaction management and access
  control.
• Operation system layer provides system filestore
  facilities.

18
MODULAR DECOMPOSITION STYLES

• Approach to be used in decomposing sub-systems
  into modules.
• There is not a rigid distinction between system
  organization and modular decomposition.
• However, the components in modules are usually
  smaller than sub-systems.
• Sub-systems are composed of modules and defined
  interfaces which are used for communication with
  other sub-systems.
• Module is a system component that provides one or
  more services to other modules.

19
MODULAR DECOMPOSITION STYLES

• There are two main decomposing strategies used
  when decomposing a sub-system into modules
• Object-Oriented Decomposition decomposition of
  a sub-system into modules.
• Function-Oriented Pipelining decomposition of a
  sub-system into functional modules that accept
  input data and transforms it into output data.

20
OBJECT-ORIENTED DECOMPOSITION

• Structures the system into a set of objects with
  well defined interfaces.
• Objects call on the services offered by other
  objects.
• Identifies object classes, their attributes and
  operations.
• When implemented, objects are created from these
  classes and some control model used to coordinate
  object operations.

21
OBJECT-ORIENTED DECOMPOSITION
22
OBJECT-ORIENTED DECOMPOSITION

• Object classes have names and a set of associated
  attributes.
• Operations if any are defined in the lower part
  of the rectangle.
• Dashed arrows indicate that an object uses the
  attributes or services provided by another object.

23
FUNCTION-ORIENTED PIPELINING

• Functional transformations process their inputs
  and produce outputs.
• Data flows from one to another and is transformed
  as it moves.
• The transformation may execute sequentially or in
  parallel.

24
FUNCTION-ORIENTED PIPELINING
25
CONTROL STYLES

• Sub-systems must be controlled so that their
  services are delivered to the right place at the
  right time.
• There are two generic control styles that are
  used in software systems
• Centralized control One sub-system has overall
  responsibility for control and starts and stops
  other subsystems.
• Event-based control Each sub-system can respond
  to externally generated events.

26
CENTRALIZED CONTROL

• There are two classes depending on whether the
  controlled sub-systems execute sequentially or in
  parallel.
• The call-return model Control starts at the top
  of the suproutine passes to lower level, and then
  returns. (Embedded programming like C)
• The manager model (event-loop model) Control
  decisions are usually determined by the value of
  some system state variables (internal event). One
  system component controls components. (Usually
  implemented as case statements)

27
CALL-RETURN MODEL
28
MANAGER MODEL
29
EVENT-BASED CONTROL

• Driven by externally generated events.
• There are two event-driven control models
• Broadcast model An event is broadcast to all
  sub-systems. Any sub-system that has been
  broadcast to handle that event can respond to it.
• Interrupt-driven model Used in real-time
  systems where external interrupts are detected by
  an interrupt handler. They are then passed to
  other component for processing.

30
BROADCAST MODEL
31
INTERRUPT-DRIVEN MODEL
32
KEY POINTS

• The software architecture is the fundamental
  framework for structuring the system.
• Architectural design decisions include decisions
  on the application architecture, the distribution
  and the architectural styles to be used.
• Different architectural models such as a
  structural model, a control model and a
  decomposition model may be developed.