ObjectOriented Analysis

1
Object-OrientedAnalysis Design

• Session 5

2
Understanding the Elements of Design

• Design is the process of describing, organizing,
  and structuring the components of a system at
  both the architectural level and at a detailed
  level
• Focused on construction
• Like developing blueprints
• Three questions
• What components require systems design?
• What are the inputs to and outputs of the design
  process?
• How is systems design done?

3
Components Requiring Systems Design
4
Analysis Objectives to Design Objectives
5
Architectural vision

• Two traits common to virtually all successful OO
  projects are
• The existence of a strong architectural vision
• The application of well-managed, iterative and
  incremental lifecycle.
• The architecture should be simple. Common
  behavior achieved through common abstractions and
  common mechanism.

6
Software architecture definition

• Software architecture is concerned with the
  organization of software systems, the selection
  of components from which they are composed, the
  interactions between those components, the
  composition of interacting components into
  progressively larger subsystems, and the overall
  patterns that guide these compositions. It is
  concerned not only with the system structure, but
  also with its functionality, performance, design,
  selection among alternatives, and
  comprehensibility.

7
Attributes of good architectures

• Good architectures are constructed in
  well-defined layers of abstraction
• Each layer represents a coherent abstraction
• Each layer has a well-defined and controlled
  interface
• Each layer is built upon well-defined and
  controlled facilities at lower levels of
  abstraction.
• There is a clear separation between the interface
  and implementation of each layer. Changes to the
  implementation of a layer do not violate
  assumptions made by its clients.

8
Developing the system architecture

• Architecture design deals with risk management
• Good architectures are best determined through
  iterative and incremental development
• A small, experienced architecture team, led by a
  chief architect, should be assigned
  responsibility for
• Defining and maintaining the architectural
  integrity of the system
• Approving all changes to package interfaces
• Assessing project risks
• Proposing the order and content of each iteration.

9
Dimensions of software architecture

• Different perspective for different stakeholders
• End-user, customer, project manager
• System engineer, developer, architect, tester
• Multiple perspectives require multiple views
• Class diagrams do not show how the system maps to
  hardware
• Hardware block diagrams do not depict what part
  of the system are COTS (Commercial Off The Shelf)

10
An architecture requires multiple views

• To completely describe an architecture, four
  views are needed
• The logical view to provide a static picture of
  the primary classes and their relationships.
• The component view to show the code is organized
  into packages and libraries and the use of
  commercial software of the shelf (COTS) software.
• The process view to show the processes and tasks.
• The deployment view to show the processors,
  devices and links in the operational environment.
• Finally, a scenario view explains how the other 4
  views work together.

11
Components Requiring Systems Design
12
Component view

• The component view of architecture is concerned
  with the actual software module organization
  within the development environment.
• Component diagrams are created to show the
  developmental packages and components that make
  up the system under development.
• Shows the allocation of classes to components
• Shows the allocation of components to packages
• The packages are organized in a hierarchy of
  layers where each layer has a well-defined
  interface.

13
What is a component?

• A component is a unit of source code that serves
  as a building block for physical structure of a
  system.
• Stereotypes (with alternate icons) may be used to
  define specific kinds of components.
• Example exe, dll, main programs, headers,
  modules, forms,..
• Group classes in a component that either have a
  co-operative function or that need to be in close
  proximity for implementation efficiency
• Component notation

Component name
14
Component diagrams

• A component diagram shows the allocation of
  classes and objects to implementation components
  as well as their completion dependencies.

Name2
Name1
Name3
Name2
Name1
15
Component diagrams cont..

• A name is required for each component this name
  typically denotes the simple name of the
  corresponding physical file in the development
  workspace.
• The only relationship is compilation dependency,
  represented by a directed dashed line pointing to
  the module upon which the dependency exits.
• In C, a compilation dependency is indicated by
  include directive.
• There may be no cycles within a set of
  compilation dependencies.

16
Packages in the component view

• A package in the component view is a collection
  of components, some of which are visible to other
  packages and others of which are hidden.
• A package groups components that are logically
  related.
• A package in the component view groups components
  in a similar way to that in which a package in
  the logical view groups classes.
• Each component in a system must live in a single
  package or at the top level of the system.
• Notation

PackageName
17
Main component diagrams

• A main component diagram is a family of packages
  connected by directed links that represent
  dependencies.
• Example

RegistrationUser Interface
MFC
Registration System
18
Correspondence between packages in the logical
and component views

• In general, a package in the logical view can
  correspond directly to a package in the component
  view.
• The logical structure and the physical structure
  may vary for the following reasons
• Packages in the logical view are merged, e.g. to
  keep closely communicating objects together for
  implementation.
• Packages in the component view are added to
  implement low-level functionality not represented
  during analysis.
• The work breakdown structure of the development
  team influences the allocation of packages and
  components in the component view.

19
Process view

• The process view of architecture focuses on
  process decomposition. This view shows the
  allocation of components to processes.
• The component diagram is updated to show the
  allocation of components to processes.
• The process view addresses the systems
  availability, reliability, performance, system
  management, synchronization.

20
Process components

• Executables and linked libraries are represented
  as components in UML
• Package specification (DLL)
• Task specification (EXE)

Task specification (EXE)
Package specification (DLL)
21
Component diagram for a process

• Each component may depend on other components

MyProcess.exe
Name1
Name2
Name1
Name2
22
Deployment view

• The deployment view of architecture maps
  components to processing nodes
• Requirements such as throughput, performance, and
  fault-tolerance are taken into account.
• Deployment diagrams are created to show the
  different nodes (processors and devices) in the
  system.

23
The deployment diagram

• A deployment diagram shows the allocation of
  components to nodes in the deployment view of a
  system. Processors and devices are common
  stereotypes of Node.
• Nodes are connected in a diagram that reflects
  the communication paths between them.
• The essential elements of a deployment diagram
  are nodes and their connections.

24
Notation for deployment diagrams

• A node is a run-time physical object representing
  computational resources.
• A connect indicates communication, usually by
  means of direct hardware coupling.

label
name
connection
node
25
Example registration system deployment diagram

• This diagram shows two nodes and devices with
  which the registration system communicates

Database
Registration System
Dorm ltltdevicegtgt
Library ltltdevicegtgt
Main Building ltltdevicegtgt
26
Processes

• A process is the execution of one thread of
  control of an OO program or system. A large
  system can be broken into multiple processes or
  threads of control.
• Objects are assigned to processes (their
  assignments can be dynamic)
• Processes are assigned to processors (the set of
  processes can be dynamic)
• Notation

Processor name
27
Mapping development packages to executable
processes

• Mapping development packages to executable
  processes involves understanding the system
  topology and system priorities including
• Processor architecture, speed and capacity
• Keeping class associations together to minimize
  inter-process communication (IPC)
• IPC strategy? Client/supplier or other?
• Distributed processing techniques
• Must resolve issues involving multiple hardware
  processors or distributed systems during system
  design.

28
Mapping executable processes to hardware

• Processes must be assigned to a hardware device
  for execution
• Among the considerations are
• Response time and system throughput
• Communication band-width/capacity
• Physical location of hardware required
• Distributed processing needs
• Processor overloading or balance in a distributed
  system
• Fault-tolerance

29
Use-case view

• Use-cases are the drivers for the architecture
  design
• Abstraction of large, complex requirements
• Identification of critical interfaces
• Force designers to focus on concrete issues
• They demonstrate and validate the logical,
  process, development, and deployment views of the
  architecture.

30
How is the architecture documented?

• The architecture is documented in an architecture
  document approximately 100 pages for a large
  system.
• The document includes
• A textual description of the architectural
  philosophy (the views) and the key driving
  requirements
• Tradeoffs made and alternatives considered
• A top-level view of the logical view (key
  packages and classes)
• Architecture-specific scenarios
• Top-level views of the development, process and
  deployment views
• The key mechanism

31
Who develops the software architecture?

• The architecture team does a core group of the
  best, most experienced developers.
• Established early in the project (not later than
  the elaboration phase)
• Most projects of reasonable complexity require an
  architecture team, not just a single architect
• Led by the chief architect who is 100 dedicated
• Includes the lead designers for major and
  critical system functions.

32
Benefits of an architecture team

• Deliverables
• Architecture document
• Parts of lower-level design documents
• Design and programming guidelines
• Elements of release plans
• Design audits of the released system
• The skill and effectiveness of the architecture
  team is critical to a projects success.
• With a good architecture, an average development
  team can succeed. With a weak architecture, even
  the most expert developers will not succeed.

33
Project Coordination

• Project teams
• Project schedule
• CASE Tools
• Team Communication