Transcript
Design and Software Architecture
Outline• What is design • How can a system be decomposed into modules • What is a module’s interface• What are the main relationships among modules• Prominent software design techniques and information
hiding• The UML collection of design notations• Design of concurrent and distributed software • Design patterns• Architectural styles• Component based software engineering
What is design?
• Provides structure to any artifact
• Decomposes system into parts, assigns responsibilities, ensures that parts fit together to achieve a global goal
• Design refers to both an activity and the result of the activity
Two meanings of "design“ activity in our context
• Activity that acts as a bridge between requirements and the implementation of the software
• Activity that gives a structure to the artifact – e.g., a requirements specification document
must be designed• must be given a structure that makes it easy to
understand and evolve
The sw design activity
• Defined as system decomposition into modules
• Produces a Software Design Document– describes system decomposition into modules
• Often a software architecture is produced prior to a software design
Software architecture
• Shows gross structure and organization of the system to be defined
• Its description includes description of – main components of a system– relationships among those components– Basis for decomposition into its components– constraints that must be respected by any design
of the components
• Guides the development of the design
Two important goals
• Design for change– designers tend to concentrate on current
needs– special effort needed to anticipate likely
changes
• Product families– think of the current system under design as a
member of a program family
Sample likely changes? (1)
• Algorithms– e.g., replace inefficient sorting algorithm with a more
efficient one• Change of data representation
– e.g., array vs linked list 17% of maintenance costs attributed to data
representation changes (Lientz and Swanson, 1980)– Thereby changes in methods that handles the data– Faculty profile example
Sample likely changes? (2)
• Change of underlying abstract machine– new release of operating system– new optimizing compiler– new version of DBMS– …
• Change of peripheral devices• Change of "social" environment
– new tax regime– EURO vs national currency in EU
• Change due to development process (transform prototype into product)
Product families• In some cases, changes consists of building new versions.• Set of these versions constitutes a family • Newer version supersedes older one (removes erros, add new
features)• Reason for treating diff. versions of a s/w product as one family
– They have much common, only partially diff.– Share same architecture– Common architecture should be designed
• Different versions of the same system– e.g. a family of mobile phones
• members of the family may differ in network standards, end-user interaction languages, …
– e.g. a facility reservation system• for hotels: reserve rooms, restaurant, conference space, …, equipment
(video beamers, overhead projectors, …)• for a university
– many functionalities are similar, some are different (e.g., facilities may be free of charge or not)
Design goal for family
• Design the whole family as one system, not each individual member of the family separately
Sequential completion: the wrong way
• Design first member of product family
• Modify existing software to get next member products
Sequential completion:a graphical view
Requirements
1
2
3
Version 1
Version 1
Version 25
Requirements
1
2
3
4 6
7 Version 3
4
Requirements
1
2
3
Version 2 5
Version 1
4
intermediate design
finalproduct
How to do better
• Anticipate definition of all family members
• Identify what is common to all family members, delay decisions that differentiate among different members
• We will learn how to manage change in design
Module
• A well-defined component of a software system
• A part of a system that provides a set of services to other modules– Services are computational elements that
other modules may use
Questions
• How to define the structure of a modular system?
• What are the desirable properties of that structure?
TDN & GDN
• Illustrate how a notation may help in documenting design
• Illustrate what a generic notation may look like
• Are representative of many proposed notations
• TDN inherits from modern languages, like Java, Ada, …
An example
module X uses Y, Z exports var A : integer;
type B : array (1. .10) of real; procedure C ( D: in out B; E: in integer; F: in real); Here is an optional natural-language description of what A, B, and C actually are, along with possible constraints or properties that clients need to know; for example, we might specify that objects of type B sent to procedure C should be initialized by the client and should never contain all zeroes.
implementation If needed, here are general comments about the rationale of the modularization, hints on the implementation, etc. is composed of R, T
end X
Comments in TDN
• May be used to specify the protocol to be followed by the clients so that exported services are correctly provided– e.g., a certain operation which does the
initialization of the module should be called before any other operation
– e.g., an insert operation cannot be called if the table is full
Example (cont.)module R uses Y exports var K : record . . . end;
type B : array (1. .10) of real;procedure C (D: in out B; E: in integer; F: in real);
implementation...
end R
module T uses Y, Z, R exports var A : integer;implementation
.
.
.
end T
Benefits
• Notation helps describe a design precisely
• Design can be assessed for consistency– having defined module X, modules R and T
must be defined eventually• if not incompleteness
– R, T replace X either one or both must use Y, Z
Example: a compilermodule COMPILERexports procedure MINI (PROG: in file of char;
CODE: out file of char);MINI is called to compile the program stored in PROG and produce the object code in file CODE
implementationA conventional compiler implementation. ANALYZER performs both lexical and syntactic analysis and produces an abstract tree, as well as entries in the symbol table; CODE_GENERATOR generates code starting from the abstract tree and information stored in the symbol table. MAIN acts as a job coordinator.
is composed of ANALYZER, SYMBOL_TABLE,ABSTRACT_TREE_HANDLER, CODE_GENERATOR, MAIN
end COMPILER
Other modulesmodule MAINuses ANALYZER, CODE_GENERATORexports procedure MINI (PROG: in file of char;
CODE: out file of char);…end MAIN
module ANALYZERuses SYMBOL_TABLE, ABSTRACT_TREE_HANDLERexports procedure ANALYZE (SOURCE: in file of char);
SOURCE is analyzed; an abstract tree is produced by using the services provided by the tree handler, and recognized entities, with their attributes, are stored in the symbol table....
end ANALYZER
Other modules
module CODE_GENERATORuses SYMBOL_TABLE, ABSTRACT_TREE_HANDLERexports procedure CODE (OBJECT: out file of char);
The abstract tree is traversed by using the operations exported by the ABSTRACT_TREE_HANDLER and accessing the information stored in the symbol table in order to generate code in the output file.…
end CODE_GENERATOR
GDN description of module X
X
Y
Z A B
R T Module Module
Module
Module
Module
C
X's decomposition
X
Y
Z B C
R T Module Module
Module
Module
Module
A
K
Categories of modules
• Functional modules– traditional form of modularization– provide a procedural abstraction– encapsulate an algorithm
• e.g. sorting module, fast Fourier transform module, …
Categories of modules (cont.)
• Libraries– a group of related procedural abstractions
• e.g., mathematical libraries– implemented by routines of programming languages
• Common pools of data– data shared by different modules
• e.g., configuration constants– the COMMON FORTRAN construct
Categories of modules (cont.)• Abstract objects
– Objects manipulated via interface functions– Data structure hidden to clients
• Abstract data types– Many instances of abstract objects may be
generated
Abstract data types (ADTs)
• A stack ADT
module STACK_HANDLER exports
type STACK = ?; This is an abstract data-type module; the data structure is a secret hidden in the implementation part. procedure PUSH (S: in out STACK ; VAL: in integer); procedure POP (S: in out STACK ; VAL: out integer); function EMPTY (S: in STACK) : BOOLEAN; . . .
end STACK_HANDLER
indicates that details of thedata structure are hidden to clients
ADTs
• Correspond to Java and C++ classes• Concept may also be implemented by Ada
private types and Modula-2 opaque types• May add notational details to specify if certain
built-in operations are available by default on instance objects of the ADT– e.g., type A_TYPE: ? (:=, =) indicates that assignment
and equality check are available
An example:simulation of a gas station
module FIFO_CARSuses CARSexports
type QUEUE : ?; procedure ENQUEUE (Q: in out QUEUE ; C: in CARS);procedure DEQUEUE (Q: in out QUEUE ; C: out CARS);function IS_EMPTY (Q: in QUEUE) : BOOLEAN;function LENGTH (Q: in QUEUE) : NATURAL;procedure MERGE (Q1, Q2 : in QUEUE ; Q : out QUEUE);This is an abstract data-type module representing queues of cars, handled in a strict FIFO way; queues are not assignable or checkable for equality, since “:=” and “=” are not exported.…
end FIFO_CARS
Generic modules (templates)
• They are parametric wrt a type
generic module GENERIC_STACK_2. . .
exportsprocedure PUSH (VAL : in T);procedure POP_2 (VAL1, VAL2 : out T);…
end GENERIC_STACK_2
Instantiation
• Possible syntax:– module INTEGER_STACK_2 is
GENERIC_STACK_2 (INTEGER)
More on genericity
• How to specify that besides a type also an operation must be provided as a parameter
generic module M (T) with OP(T)uses ...
...end M
• Instantiationmodule M_A_TYPE is M(A_TYPE) PROC(M_A_TYPE)
Specific techniques for design for change
• Use of configuration constants– factoring constant values into symbolic
constants is a common implementation practice
• e.g., #define in C
#define MaxSpeed 5600;
Specific techniques for design for change (cont.)
• Conditional compilation...source fragment common to all versions...
# ifdef hardware-1...source fragment for hardware 1 ...# endif#ifdef hardware-2...source fragment for hardware 2 ...# endif
• Software generation– e.g., compiler compilers (yacc,
interface prototyping tools)
Stepwise refinement
• A systematic, iterative program design technique that unfortunately may lead to software that is hard to evolve
• At each step, problem P decomposed into– sequence of subproblems: P1; P2; …Pn– a selection: if (cond) then P1 else P2– an iteration: while (cond) do_something
Decomposition tree
• Stepwise refinement process may be depicted by a decomposition tree (DT)– root labeled by name of top problem– subproblem nodes labeled as children of
parent node corresponding to problem– children from left to right represent
sequential order of execution– if and while nodes denoted by suitable
decoration
Top-down vs. bottom-up• Information hiding proceeds bottom-up• Iterated application of
IS_COMPOSED_OF proceeds top-down– stepwise refinement is intrinsically top-down
• Which one is best?– in practice, people proceed in both directions
• yo-yo design
– organizing documentation as a top-down flow may be useful for reading purposes, even if the process followed was not top-down
oop
• Generalization and specialization– Is a – Has a
Object-oriented design
• One kind of module, ADT, called class
• A class exports operations (procedures) to manipulate instance objects– often called methods
• Instance objects accessible via references
Syntactic changes in TDN
• No need to export opaque types– class name used to declare objects
• If a is a reference to an object– a.op (params);
A further relation: inheritance
• ADTs may be organized in a hierarchy
• Class B may specialize class A– B inherits from A
conversely, A generalizes B
• A is a superclass of B
• B is a subclass of A
An exampleclass EMPLOYEE exports
function FIRST_NAME(): string_of_char; function LAST_NAME(): string_of_char; function AGE(): natural; function WHERE(): SITE; function SALARY: MONEY; procedure HIRE (FIRST_N: string_of_char;
LAST_N: string_of_char; INIT_SALARY: MONEY);
Initializes a new EMPLOYEE, assigning a new identifier. procedure FIRE(); procedure ASSIGN (S: SITE); An employee cannot be assigned to a SITE if already assigned to it (i.e., WHERE must be different from S). It is the client’s responsibility to ensure this. The effect is to delete the employee from those in WHERE, add the employee to those in S, generate a new id card with security code to access the site overnight, and update WHERE.
end EMPLOYEE
class ADMINISTRATIVE_STAFF inherits EMPLOYEE exports
procedure DO_THIS (F: FOLDER); This is an additional operation that is specific to administrators; other operations may also be added.
end ADMINISTRATIVE_STAFF class TECHNICAL_STAFF inherits EMPLOYEE exports
function GET_SKILL(): SKILL; procedure DEF_SKILL (SK: SKILL); These are additional operations that are specific to technicians; other operations may also be added.
end TECHNICAL_STAFF
Inheritance
• A way of building software incrementally• A subclass defines a subtype
– subtype is substitutable for parent type
• Polymorphism– a variable referring to type A can refer to an
object of type B if B is a subclass of A
• Dynamic binding – the method invoked through a reference
depends on the type of the object associated with the reference at runtime
How can inheritance be represented?
• We start introducing the UML notation
• UML (Unified Modeling Language) is a widely adopted standard notation for representing OO designs
• We introduce the UML class diagram– classes are described by boxes
UML representation of inheritance
EMPLOYEE
TECHNICAL_STAFF ADMINISTRATIVE_STAFF
UML associations
• Associations are relations that the implementation is required to support
• Can have multiplicity constraints
TECHNICAL
_STAFF
MANAGER
PROJECT * 1 project_member
1
1..* manages
Aggregation
• Defines a PART_OF relationDiffers from IS_COMPOSED_OF
Here TRANGLE has its own methods
It implicitly uses POINT to define
its data attributes
TRIANGLE
POINT
1
3
More on UML
• Representation of IS_COMPONENT_OF via the package notation
package_name
Class 1
Class 2
Class 3
Software architecture
• Describes overall system organization and structure in terms of its major constituents and their interactions
• Standard architectures can be identified– pipeline– blackboard– event based (publish-subscribe)
Standard architectures
Pipeline
Sub-sys processing elements
event based
Event detection by sensor or mesg arrival
Blackboard
comm. Between several Sub-sys
The software production process
Questions
• What is the life cycle of a software product?
• Why do we need software process models?
• What are the goals of a software process and what makes it different from other industrial processes?
Outline• Traditional answer: "waterfall" lifecycles• Flexible, incremental processes• Case studies
– "synchronize-and-stabilize" (Microsoft)– the "open source" development model
• Organizing the process– software methodologies– the "Unified Process"
• Organizing artifacts: configuration management• Standards
Life cycle
• The life cycle of a software product– from inception of an idea for a product
through• requirements gathering and analysis• architecture design and specification• coding and testing• delivery and deployment• maintenance and evolution• retirement
Software process model
• Attempt to organize the software life cycle by
• defining activities involved in software production• order of activities and their relationships
• Goals of a software process– standardization, predictability, productivity,
high product quality, ability to plan time and budget requirements
Code&Fix
The earliest approach • No distinction between end user & programmer.• End user – scientist or engineer• s/w development activity - Write code• Model – code & fix• Fix it to eliminate any errors that have been detected,
to enhance existing functionality, or to add new features
• Source of difficulties and deficiencies– impossible to predict– impossible to manage
• Consequences of growth in h/w capacity • Separation between s/w developer & user. E.g. sales
agent or personnel admin.• Economic, organizational, physiological issues.
– Black berry torch ex.• Intolerance of end user.
– High quality, reliable s/w• Fields where system failure have sever consequences.• Code & fix was inadequate due to
– Increased size, difficult to manage– Frequent discovery
Models are needed
• Symptoms of inadequacy: the software crisis– scheduled time and cost exceeded– user expectations not met– poor quality
• The size and economic value of software applications required appropriate "process models“– Cost benefit analysis.
Process model goals (B. Boehm 1988)
"determine the order of stages involved in software development and evolution, and to establish the transition criteria for progressing from one stage to the next. These include completion criteria for the current stage plus choice criteria and entrance criteria for the next stage. Thus a process model addresses the following software project questions:
What shall we do next?How long shall we continue to do it?"
Process as a "black box"
Product
Process
Informal Requirements
Problems
• The assumption is that requirements can be fully understood prior to development
• Interaction with the customer occurs only at the beginning (requirements) and end (after delivery)
• Unfortunately the assumption almost never holds
Process as a "white box"
Product
Process
Informal Requirements
feedback
Advantages
• Reduce risks by improving visibility
• Allow project changes as the project progresses– based on feedback from the customer
The main activities
• They must be performed independently of the model
• The model simply affects the flow among activities
Feasibility study
• Why a new project?– cost/benefits tradeoffs– buy vs make
• Requires to perform preliminary requirements analysis
• Produces a Feasibility Study Document1. Definition of the problem2. Alternative solutions and their expected benefits3. Required resources, costs, and delivery dates in each
proposed alternative solution
Requirements engineering activities
Requirements engineering
• Involves – eliciting– understanding– analyzing– specifying
• Focus on– what qualities are needed, NOT on– how to achieve them
What is needed
• Understand interface between the application and the external world
• Understand the application domain• Identify the main stakeholders and
understand expectations– different stakeholders have different
viewpoints– software engineer must integrate and
reconcile them
The requirements specification document (1)
• Provides a specification for the interface between the application and the external world– defines the qualities to be met
• Has its own qualities– understandable, precise, complete,
consistent, unambiguous, easily modifiable
The requirements specification document (2)
• Must be analyzed and confirmed by the stakeholders– may even include version 0 of user manual
• May be accompanied by the system test plan document
The requirements specification document (3)
• As any large document, it must be modular– "vertical" modularity
• the usual decomposition, which may be hierarchical
– "horizontal" modularity• different viewpoints
• Defines both functional and non functional requirements
A case study railway automation
• Who are the stakeholders?– management of the train company– train drivers and their unions– passengers (customers)– contractors
• Each has different goals
Case studyhow to classify requirements
• Safety requirements– the probability of accidents should be less
than 10-9 per year
• Utility requirements– level of usefulness of the system as perceived
by the various stakeholders
Case studythe produced document
• Introduction: the “mission” of the system• Architecture: the main structure of the system• Specific requirements associated with each
subsystem– discussion of how the subsystems’ requirements
guarantee that the overall goals are indeed achieved
Software architecture and detailed design activity
• The result of this activity is a Design Specification Document
• Usually follows a company standard, which may include a standard notation, such as UML
Coding and module testing activity
• Company wide standards often followed for coding style
• Module testing– based on black box/white box criteria
Integration and system test activity
• These activities may be integrated with coding and module testing
• Integration may be done incrementally through subsystems– top down vs. bottom up
• The last step is system test– may be followed by alpha testing
Delivery, deployment, and maintenance activities
• Delivery– real delivery may be preceded by beta testing
• Deployment– components allocated on physical
architecture
• Maintenance– corrective, adaptive, perfective
Maintenance
• Requirements errors are main cause of maintenance activities
• Late discovery of requirements errors causes increased costs
Other software activities
• Documentation
• Verification
• Management
They can be considered as parts of any kind of software related activity
Overview of software process models
Waterfall models (1)
• Invented in the late 1950s for large air defense systems, popularized in the 1970s
• They organize activities in a sequential flow
• Exist in many variants, all sharing sequential flow style
Feasibility study
Requirements
Design
Coding and module testing
Integration and system testing
Delivery, deployment, and maintenance
A waterfall model
Waterfall models (2)
• Organizations adopting them standardize the outputs of the various phases (deliverables)
• May also prescribe methods to follow in each phase– organization of methods in frameworks
often called methodology
• Example: Military Standard (MIL-STD-2167)
Critical evaluation of the waterfall model
+ sw process subject to discipline, planning, and management
+ postpone implementation to after understanding objectives
– linear, rigid, monolithicno feedbackno parallelisma single delivery date
Feasibility study
Requirements
Design
Coding and module testing
Integration and system testing
Delivery, deployment, and maintenance
Waterfall with feedback
Problems with waterfall
• Estimates made when limited knowledge available
• Difficult to gather all requirements once and for all– users may not know what they want– requirements cannot be frozen
Evolutionary models
• Many variants available• Product development evolves through
increments– "do it twice" (F. Brooks, 1995)– evolutionary prototype
• Evolutionary process model (B. Boehm, 1988)"model whose stages consist of expanding
increments of an operational software product, with the direction of evolution being determined by operational experience"
Incremental delivery
• Identify self-contained functional units that may be delivered to customers
• To get early feedback– According to T. Gilb, 1988:
• Deliver something to the real user• Measure the added value to the user in all critical
dimensions• Adjust design and objectives
Transformation model
• Guided by formal methods
• Specifications transformed into implementations via transformations
• Still a theoretical reference model
Requirements analysis and specification
OptimizationRequirements
Formal specifications
Verification Tuning
Lower level specifications
Recording of developmental history
Reusable components
Decisions & rationale
Transformation model
Spiral modelB. Boehm, 1989
• Evolution of process models
• Waterfall – documentation driven
• Evolutionary – increment driven
• Transformation – specification driven
A final model assessment(1)
• Waterfall– document driven
• Transformational– specification driven
• Spiral– risk driven
A final model assessment(2)
• Flexibility needed to reduce risks– misunderstandings in requirements– unacceptable time to market
• Waterfall may be useful as a reference structure for documentation– describes the "rationale" a posteriori (Parnas
and Clements, 1989)
The process
• Planning phase– vision of the product, specification, schedule
• Development – team composed of 2 groups
• developers and testers (continuous testing)
– process prescribes• daily synchronization• product stabilization
top related