Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Software Architecture and Architectural Design

Software Architecture and Architectural Design

Slides from a lecture in Software Architecture I presented in 2003 to a 3rd year undergraduate class in Software Engineering Process and Practice.

The slides were updated slightly and were converted to XeLaTeX/Beamer from Microsoft Powerpoint.

Michael Papasimeon

April 28, 2003
Tweet

More Decks by Michael Papasimeon

Other Decks in Programming

Transcript

  1. ENGINEERING What is Engineering? The application of scientific and mathematical

    principles to practical ends such as the design, manufacture, and operation of efficient and economical structures, machines, processes, and systems. ￿ 2
  2. EXPECTATIONS To learn what is meant by “Software Architecture”, its

    importance in the software development process, and how to recognise the good and bad characteristics of different software architectures. Don't expect you to be world leading software designers at the end of this class; this will come with experience and lots of practice. 3
  3. WHAT IS SOFTWARE ARCHITECTURE? Software architecture refers to the theory

    behind the actual design of computer software. In the same way as a building architect sets the principles and goals of a building project as the basis for the draftsman's plans, so too, a software architect sets out the software architecture as a basis for the actual design specifications. http://www.wikipedia.org/wiki/Software_architecture A Software Design must be documented to exist. A Software Architecture must describe both the STRUCTURE and the BEHAVIOUR of a software system. 4
  4. WHY IS SOFTWARE ARCHITECTURE IMPORTANT? Barry Boehm If a project

    has not achieved a system architecture, including its rationale, the project should not proceed to full-scale system development. Specifying the architecture as a deliverable enables its use throughout the development and maintenance process.￿ Mutual Communication Early Design Decisions Transferable Abstraction of a System 5
  5. WHY DO WE NEED A SOFTWARE ARCHITECTURE? To understand how

    the system is intended to work. To organise software development. To foster reuse. To evolve the system. 7
  6. WHAT INFLUENCES THE SOFTWARE ARCHITECTURE Requirements and Software Patterns Requirements

    and use cases Experience -- previous architectures and architectural patterns Constraints and Enablers System software Middleware (e.g. frameworks) Legacy systems Standards and policies Non functional requirements Distribution needs 8
  7. ARCHITECTURAL DESCRIPTION Architecture should be developed after requirements have been

    gathered and analysed. Architecture should be documented and should remain relatively stable throughout the life of the project. Architecure may be updated, but shouldn’t grow dramatically. Changes may include: Finding new abstract classes and interfaces Adding new functionality to existing sub-systems/modules Upgrading to new versions of re-useable components Re-arranging the process structure. 9
  8. ARCHITECTURAL EXAMPLES Pipeline Transaction Layered Repository Client-server Distributed computing Peer-to-peer

    system Model-View-Controller Monolithic system Three-tier model Structured Component architecture 10
  9. MODULAR SOFTWARE DESIGN Reduces Complexity. Facilitates Change (Easier Maintainability). Easier

    Implementation by encouraging parallel development. Module is the basic unit of software used in a design description. Determined using step-wise refinement (logical parts) Modules, sub-systems, components, packages, and classes are all software elements used for abstraction and information hiding 1. 1Pressman 3rd Edition (Section 10.4 pg 332) 11
  10. LEVELS OF ABSTRACTION Data Structures and Algorithms Classes (data structures

    and many algorithms) Packages/Modules (groups of related, possibly interacting classes through design patterns). Modules/Subsystems (interacting modules each containing many classes, but only the public interfaces interact with other modules/subsystems). Systems (systems interacting with other systems, hardware, software and human). Software architecture tends to be concerned with the last two. 12
  11. MODULE COHESION A measure of how functionally coherent a software

    module is. A software module should have High Cohesion. This means that a software module is concerned with only doing one thing – and doing that thing well. For large modules, their components/classes should be functionally related. 13
  12. TYPES OF COHESION Software Module Cohesion... Coincidental: multiple, completely unrelated

    actions or components Logical: series of related actions or components (e.g. library of IO functions) Temporal: series of actions related in time (e.g. initialisation modules)￿ Procedural: series of actions sharing sequences of steps. Communicational: procedural cohesion but on the same data. Functional: one action or function 14
  13. MODULE COUPLING Coupling is a measure of how inter-related or

    interdependent software modules are. There should be LOW COUPLING between software modules. This means that should be only a few well defined, functionally relevant dependencies between software modules. Highly coupled software is BAD software.￿ (difficult to understand, maintain, debug etc…) 15
  14. TYPES OF COUPLING Software Module Coupling... Content: one module directly

    references the content of another Common: both modules have access to the same global data. Control: One module passes the element of control to another. 16
  15. DESIGN FOR REUSE Reusable Components/Modules are general Reusable Components are

    Loosely Coupled Requires High Cohesion and Published Interface 17
  16. PERFORMANCE CONSTRAINTS Having lots of layers can result in performance

    issues. It is a good idea to generally design your architecture with high cohesion and low coupling and then adapt it to iron out performance issues. 18
  17. STEPS IN CREATING A SOFTWARE ARCHITECTURE Identify major modules (or

    sub-systems) and sub-modules. Identify interactions with external actors and systems. Identify dependencies between modules. Determine the public classes, functions or sub-modules for each module. Identify which public classes from each module will interact with each other. Determine the interaction order between the modules. Determine how two modules will interact using experience and design patterns. Identify the methods (functions) used that will interact with other modules methods (functions). Determine the dynamic interactions (run-time) Prototype the architecture Document it. Review it. Iterate through it a couple of times to make sure it is modular, extensible, satisfies requirements (including performance etc). Compile it... 19
  18. EXAMPLE GAME ARCHITECURE: MODULE DEPENDENCIES Graphics Music Artificial Intelligence Game

    Logic Game Data Event Handling Input Graphics Engine Audio Sound Engine DirectX User Interface Physics Engine Online Help Menu System Config System 20
  19. DETAILED DESIGN: MODULE SPECIFICATION What the function of a module

    is: Description of what the purpose and function of a module is. Inputs and Outputs Dependencies Errors and Exceptional Conditions 24
  20. SOME QUESTIONS FOR THE PRELIMINARY ARCHITECTURAL DESIGN REVIEW Does the

    architecture satisfy the requirements? Is effective modularity achieved? Are interfaces defined for modules and external system elements? Is the structure of the data and it’s organisation consistent with the domain of the requirements? Is the structure of the data consistent with the requirements? Has maintainability been considered? Have quality factors been explicitly assessed? 25
  21. BOOKS ABOUT SOFTWARE DESIGN Design Patterns: Elements of Reusable Object

    Oriented Software (Gamma et. al) Pattern-Oriented Software Architecture, Vol.1: ￿ A System of Patterns (Buschmann et. al) Software Engineering : A Practitioner’s Approach (Pressman) The Unified Software Development Process (Jacobson, Booch, Rumbaugh) Use Case Driven Object Modelling and Design with UML: A Practical Approach (Rosenberg) UML Distilled (Fowler) Analysis Patterns (Fowler) 26
  22. BOOKS ABOUT SOFWARE ARCHITECTURE Applied Software Architecture (Hofmeister) Evaluating Software

    Architectures: Methods and Case Studies (Clements) Design and Use of Software Architecture (Bosch) The Software Architect’s Profession: An Introduction (Sewell et al) Software Architecture: Organizational Principles and Patterns (Dikel) Documenting Software Architectures: Views and Beyond (Clements) Software Fortresses: Modeling Enterprise Architectures (Sessions) Beyond Software Architecture: Creating and Sustaining Winning Solutions (Hohmann) 27