SYSTEM DESIGN

1
COMP 211INTRODUCTION TOSOFTWARE ENGINEERING

• SYSTEM DESIGN

2
SYSTEM DESIGN OUTLINE

• System Design General
• Importance of Design
• Design Goals
• System-wide Issues
• Implementation Environment
• Life Cycle Role
• Artifacts and Workers
• Design Process
• System Design Unified Process
• Design use cases
• Design classes
• Design subsystems

3
SYSTEM DESIGN

• adapts the logical structure of the Analysis
  Model to the implementation environment and
  prepares for implementation by
• considering the impact of nonfunctional
  requirements
• considering system-wide design issues
• considering the implementation environment
• fully specifying each class including all
  attributes and operations
• decomposing implementation work into more
  manageable pieces gt subsystems
• capturing the major interfaces between subsystems
• when to transition to system design?
• when minimal changes will be required to
  transform the Analysis Model into the Design Model

4
IMPORTANCE OF DESIGN

• Why not go straight to implementation?

• we need to consider the impact of nonfunctional
  requirements
• the system must be adapted to the implementation
  environment
• analysis model is not sufficiently formal so we
  need to
• refine analysis classes
• determine operations
• determine how classes should communicate
• we want to validate the analysis results
• How well do the Analysis Model and the
  Requirements Model describe the system? What is
  not yet clear?

5
ANALYSIS MODEL
DESIGN MODEL

• Conceptual model
• Design gt generic
• Less formal
• Less expensive to develop
• Few layers
• Focus on interactions
• Outline of design
• Created by developer meetings
• May not be maintained

• Physical model
• Implementation gt specific
• More formal
• More expensive to develop
• Many layers
• Focus on sequence
• Implementation of design
• Created by software engineering environments
• Maintained throughout life cycle

6
DESIGN GOALS 6.2

• What qualities of the system should the
  developers optimize (focus on)?

• qualities derived mainly from nonfunctional
  requirements
• selected qualities guide the decisions made by
  developers, especially when trade-offs are needed
• usually only a small subset of the nonfunctional
  requirements can be considered simultaneously
• need to prioritize design goals and possibly
  develop trade-offs against each other as well as
  against managerial goalsExamples space vs.
  speed delivery time vs. functionality, etc.

7
DESIGN GOALS SOME DESIRABLE QUALITIES 6.4.2

• performance criteria
• response time
• throughput
• memory
• dependability criteria
• robustness
• reliability
• availability
• fault tolerance
• security
• safety
• end user criteria
• utility
• usability

• maintenance criteria
• extensibility
• modifiability
• adaptability
• portability
• readability
• cost criteria
• development
• deployment
• upgrade
• maintenance
• administration
• traceability

8
SYSTEM-WIDE DESIGN ISSUES 6.4.5 6.4.6 6.4.7
6.4.8

• data management How is persistent data handled?
• files? relational DBMS? object-oriented
  DBMS?
• access control How is access control specified
  and realized?
• global access table? access control list?
  capability?
• control flow How is processing initiated and
  controlled?
• procedure-driven? event-driven? threaded?
• boundary conditions How are system start-up,
  system shutdown and exceptions handled?

• specify system administration use cases for
  start-up, shutdown
• specify an exceptional handling mechanism for
  errors

9
IMPLEMENTATION ENVIRONMENT 6.4.4
Need to consider the technical and managerial
constraints under which the system should be built

• What hardware/software will the system run on?
• hardware (limitations) system software
• distribution
• What programming language will be used?
• OO, non-OO memory management
• What existing software do we need to use?
• DBMS network facilities
• UIMS legacy systems
• What development people/organizations will be
  involved?
• distributed location team competencies

10
IMPLEMENTATION ENVIRONMENT (contd)

• General implementation environment design
  strategylocalize and encapsulate implementation
  environment dependencies

to accomplish this, we create new proxy classes
that represent occurrences of components in the
implementation environment
?
proxy class
FileManager
NT
Unix
Mac-OS

• often need to define additional classes to deal
  with the implementation environment

11
LIFE CYCLE ROLE
Phases
Core Workflows
Requirements
Analysis
Design
Iteration
Implementation
Testing
iter. n
Increments
12
ARTIFACTS WORKERS
responsible for
responsible for
responsible for
13
ARTIFACTS

• design model - describes the physical realization
  of a use case focuses on how functional and
  nonfunctional requirements, together with
  implementation environment constraints, impact
  the system
• deployment model - describes the physical
  distribution of the system in terms of how
  functionality is distributed among computational
  nodes
• architecture description - contains the
  architecturally significant artifacts of the
  design model and all of the deployment model
• two views of architecture - design model view and
  deployment model view

14
ARTIFACTS

• use-case realizationdesign - describes how a
  specific use case is realized and performed in
  terms of design classes and their objects
• design class - an abstraction of a class or
  similar construct in the systems implementation
• use programming language to specify a design
  class
• design subsystem - organizes artifacts of the
  design model into more manageable pieces
• interface - specifies the operations provided by
  design classes and subsystems
• separates operations from their implementation

15
WORKERS

• architect - responsible for the integrity and the
  architecture of the design and deployment models
• use-case engineer - responsible for one or more
  use-case realizationsdesign
• makes all textual descriptions and diagrams
  describing the use-case realization readable and
  suited for their purpose
• component engineer - defines and maintains the
  operations, methods, attributes, relationships
  and implementation of one or more design classes
• may also maintain the integrity of one or more
  subsystems

16
UP SYSTEM DESIGN PROCESS
Component Engineer
17
UP SYSTEM DESIGN PROCESS

• Design use cases
• identify design classes and/or subsystems for a
  use case
• distribute use case behaviour to design classes
  and/or subsystems
• specify requirements on operations of design
  classes and/or subsystems and their interfaces
• capture nonfunctional implementation requirements
• Design classes
• create design classes that fulfill all their
  functional and nonfunctional requirements by
  specifying completely their
• attributes, relationships, operations,
  interfaces, dependencies on generic design
  mechanisms, etc.
• Design subsystems
• define dependencies among subsystems
• define interfaces that subsystems provide

18
USE-CASE DESIGN

• Identify the participating design classes
• analysis classes that participate in the use case
• additional classes to handle any special
  requirements of analysis use case (e.g., design
  goals)
• any other classes needed to implement the use
  case(e.g., to accommodate the implementation
  environment)
• preserve traceability use-case
  realizationdesign use-case realizationanalysis
  use case
• Specify
• class diagrams show participating classes
• identify active classesa thread or process
  shown with a thicker border
• implementation requirements collect the
  nonfunctional requirements that will be handled
  during implementation

19
USE-CASE DESIGN ACTIVE CLASSES

• An active class is one that has its own thread of
  control (usually boundary or control classes).
  Active classes can be identified by considering
• the performance, throughput and availability
  requirements of different actors as they interact
  with the system
• e.g., a need for fast response time might be
  managed by a dedicated active object for taking
  input and providing output
• the systems distribution onto nodes active
  objects needed to support distribution onto
  several nodes
• e.g., one active object per node and separate
  active objects to handle node inter-communication
• other requirements
• e.g., system startup and termination, liveness,
  deadlock avoidance, starvation avoidance,
  reconfiguration of nodes, capacity of
  connections, etc.

20
CLASS DESIGN 7.4

• design classes are classes whose specifications
  have been completed to such a degree that they
  can be implemented
• design classes come from two places
• 1. the problem domain
• refine analysis classes by adding implementation
  details
• may require analysis classes to be divided into
  two or more detailed design classes
• 2. the solution domain
• utility class libraries, reusable components,
  component frameworks (DCOM, CORBA, Enterprise
  JavaBeans, etc.)
• provides the technical tools to implement a system

21
CLASS DESIGN SOLUTION DOMAIN

• for boundary classes we need to consider
• specific user interface technologies used
• in Visual Basic need design classes(1)
  stereotyped as ltltformgtgt (2) representing
  controls
• for entity classes we need to consider
• specific data management technologies used
• design classes that map to tables in a relational
  database
• for control classes we need to consider
• distribution issues gt do we need a separate
  design class at each node?
• performance issues gt do we merge with
  boundary/entity class?
• transaction issues gt do we need to incorporate
  transaction management technology?

22
CLASS DESIGN ACTIVITIES 7.4

• complete the specification by identifying/specifyi
  ng 7.4.1-7.4.4
• missing attributes, associations and operations
• not all messages become operations (e.g., actors,
  boundary classes)
• not all operations appear in interaction diagrams
• type signatures and visibility of attributes and
  operations
• constraints on operations gt invariants
  preconditions postconditions
• exceptions gt values that operations should not
  accept

• select reusable components by identifying and
  adapting 7.4.5-7.4.6
• class libraries gt conversion/glue classes and
  operations may be needed
• generic design mechanisms for handling
  nonfunctional requirements
• persistence object distribution security
  transaction management error handling, etc.

23
CLASS DESIGN ACTIVITIES (contd) 7.4

• restructure the design model 7.4.8-7.4.10
• realize associations gt often realized as
  variables that provide references among objects
• refine multiplicities, role names, association
  classes, qualified roles, navigability of
  associations consider programming language
  support
• increase reuse by use of inheritance/delegation

• optimize the design model 7.4.11-7.4.13
• revise access paths to speed up access gt add new
  associations
• collapse classes gt classes with few attributes
  and little behavior
• cache expensive computations gt use derived
  attributes
• delay expensive computations gt e.g., image
  display

• describe using the syntax of the programming
  language

24
WELL-FORMED DESIGN CLASSES

• completeness and sufficiency
• a class should do what users of the class expect
  no more and no less
• primitiveness
• a class should always make available the simplest
  and smallest possible set of operations
• high cohesion
• a class should model a single abstract concept
  and should have operations that support the
  intent of the class
• low coupling
• a class should be associated with just enough
  other classes to allow it to realize its
  responsibilities

25
GENERIC DESIGN MECHANISMS 7.4.6 Appendix A

• Well-tried ways to handle common requirements

• design pattern a named, well-understood
  solution to a common problem in context
• help novices to learn by example to behave more
  like experts
• pattern catalog documents particular designs that
  are useful in a certain context
• framework a reusable chunk of architecture
• describes how a collection of objects work
  together to implement the structural part of a
  design pattern
• usually define generic classes that describe the
  collaborations between the objects and which will
  be sub-classed (specialized) when the framework
  is applied to a problem

What
How
26
DESIGN PATTERN PERSISTENT (DBMS) DATA

• issues to consider for a relational DBMS
• object structure ? table structure
• type system mismatches (programming language ?
  DBMS)
• operations gt where will they be stored?
• inheritance gt usually not supported in a
  relational DBMS

27
DESIGN PATTERN OBJECTS INTO TABLES

• each class becomes a table

• each (primitive) attribute becomes a table column
• How to handle complex attributes?
• primary key column will be object id gt not
  visible to user
• each object is a row in the table
• each association between classes
• 11 or 1N gt a column in the table representing
  the N side
• NM or has an association class gt a separate
  table
• inheritance
• 1. place all subclass attributes in superclass
  table
• 2. place all superclass attributes into each
  subclass table
• 3. create a separate table for superclass and
  relate to subclass tables

28
FRAMEWORK PERSISTENT OBJECT
framework of abstract objects
encapsulates the DBMS
sub-classed actual objects
29
FRAMEWORK PERSISTENT OBJECT

• subsystem PersistentObject a collection of
  abstract classes with mainly abstract operations
• has the persistence functionality common to all
  persistent objects
• is inherited by all objects that must be
  persistent (in the database)
• is specialized for each particular object that
  must be persistent
• DBRuntimeObjectState separates database data from
  non-database data
• the classes in PersistentObject are not
  independent, but have a well-defined protocol
  that handles the persistence mechanism
• PersistentObject specifies interfaces, but no
  actual implementation
• subsystem RDBPort responsible for the actual
  interface to the RDBMS (e.g., SQL statements to
  the DBMS are generated by this subsystem)
• RDBPort encapsulates the DBMS

30
FRAMEWORK PERSISTENT OBJECT
abstract object
actual object
31
FRAMEWORK PERSISTENT OBJECT
attributes of Object to be stored in the database
in type system of PL
attributes of Course to be stored in the database
in type system of PL
32
FRAMEWORK PERSISTENT OBJECT
attributes of Object in type system of DBMS
attributes of Course in type system of DBMS
33
FRAMEWORK PERSISTENT OBJECT
converts DBRuntime- ObjectState into
DBPersistent- ObjectState (abstract operations)
converts DBRuntime- CourseState into
DBPersistent- CourseState (actual operations)
34
FRAMEWORK PERSISTENT OBJECT
Whenever Course is updated, so is RuntimeCourseSta
te
update
update
update
35
FRAMEWORK PERSISTENT OBJECT
1. Course tells PersistentCourse- Manager to
store its information in the database
store(DBRuntimeCourseState)
36
FRAMEWORK PERSISTENT OBJECT
2. PersistentCourse- Manager converts the
information in DBRuntime-CourseState into
DBPersistent- CourseState
set...
get...
37
FRAMEWORK PERSISTENT OBJECT
store(TableCourse, DBPersistentCourseState)
3. PersistentCourse- Manager stores DBPersistent
- CourseState in the database via RDBPort
38
ASU Course Registration Class Diagram
Design Select Courses to Teach
39
ASU CLASS DIAGRAM SELECT COURSES TO TEACH
40
SUBSYSTEM DESIGN 6.3.1
a mechanism used to organize artifacts of the
design model into more manageable pieces

• can contain
• design classes use-case realizations
• other subsystems interfaces
• use case can be designed as a collaboration of
  subsystems rather than classes
• class diagram of subsystems
• subsystems can be used on interaction diagrams
• allows hierarchical decomposition

• can be refinements of packages or be directly
  identified in the design workflow (if there is no
  analysis model)

41
SUBSYSTEM DESIGN LAYERS AND PARTITIONS 6.3.4

• recursively dividing subsystems into smaller and
  simpler subsystems leads to a hierarchy of
  subsystems/layers

• each layer (subsystem) provides higher-level
  services and uses services of lower-level layers
  (subsystems)
• subsystem layer architecture
• closed layered architecture each layer can only
  depend on the layer immediately below it gt lower
  coupling (more overhead)
• open layered architecture each layer can depend
  on any layer below it gt higher coupling (less
  overhead)
• subsystem partitions
• divide services in one layer into different
  subsystems
• results in peer to peer services within a layer
• usually 3 to 5 layers in practice

42
SUBSYSTEM DESIGN LAYERS AND PARTITIONS
Application-specific layer
Application-general layer
Middleware layer
System-software layer
43
SUBSYSTEM DESIGN LAYERS AND PARTITIONS

• application subsystems come mainly from
  decomposing the analysis packages
• application-specific the part of the system that
  is not shared by other subsystems
• application-general the part of the system that
  is reusable within a business or application
  domain
• middleware subsystems reusable building blocks
  for utility frameworks and services that are
  platform-independent
• generic design mechanisms, object request
  brokers, GUI toolkits
• system-software subsystems software for
  computing and network infrastructure that is
  platform dependent
• O.S., hardware interfaces, communication software
• encapsulate middleware and system-software

44
ASU Course Registration Subsystems
45
ASU SUBSYSTEMS DEPENDENCIES
Application-specific layer
Application-general layer
46
SUBSYSTEM INTERFACES 6.3.2

• the set of operations of a subsystem that are
  accessible from outside the subsystem to other
  subsystems
• also called the application programmer
  interface (API)
• interface specification includes
• operation names return values (if any)
• parameters and their type
• the interface implementation is provided by
  classes or other subsystems within the subsystem
• if a subsystem has a dependency directed toward
  it,it is likely that it needs to provide an
  interface
• any client using an interface is independent of
  the implementation of the subsystem

47
ASU Course Registration Interfaces
48
ASU SOME INTERFACES
49
ASU SOME INTERFACES
Port
50
ASU SOME INTERFACES
51
ASU SOME INTERFACES
52
ASU SOME INTERFACES
53
DEPLOYMENT MODEL 6.3.6
node name
describes how the functionality of the system is
physically distributed to processing nodes

• deployment diagram shows
• nodes computational resources (e.g., processors)
• relationships means of communication among nodes
  (e.g., network)
• common distributed configurations use a
  three-tier architecture
• clients (user interactions)
• database functionality
• business/application logic
• client/server gt special case of three-tier
  architecture where business/application logic is
  relocatedto one of the other two tiers

54
DEPLOYMENT MODEL DESIGN ISSUES

• Which nodes are involved, and what are their
  capacities in terms of processing power and
  memory size?
• What types of connections are between the nodes,
  and what communication protocols will be used?
• What are the characteristics of the connections
  and communication protocols ( e.g., bandwidth,
  availability, quality, etc.)?
• Is there any need for redundant processing
  capacity, fail-over nodes, process migration,
  keeping backup data, etc.?

55
ASU Course Registration Deployment Model
56
ASU DEPLOYMENT MODEL
Database server
Registrar
Interfaces and SystemSecurity subsystems are
deployed to all nodes
Dorm
Main Building
Library
57
CHECKING THE DESIGN HOMOGENIZATION

• in a large project, use cases/scenarios will be
  developed independently by different team
  members/groups
• different names/designs for the same concept
  very likely

• may need to
• combine classes, operations gt pick name most
  meaningful to users
• split classes, operations gt follow golden rule
  of OO
• eliminate classes gt not used no structure or
  behavior
• check for consistency gt static view ? dynamic
  view
• trace events gt sending/receiving operation for
  messages
• do scenario walk-throughs gt best way to check
  the model
• review documentation gt for everything!
• this is an ongoing process throughout the
  project!

58
SUMMARY SYSTEM DESIGN

• Design Model contains
• subsystems, their dependencies and their
  interfaces
• implemented by implementation subsystems
  containingsource code, scripts, binaries,
  executables, etc.
• design classes, their operations, attributes,
  relationships and implementation requirements
• implemented by files containing source code
• use-case realizationsdesign
• used to construct builds during implementation
• Deployment Model
• architectural view of the Design Model