Architecture Design
Speaker: Kuan-Ta Lu
Date: March 31
Software Engineering Phases – The
Design Phase
• In the design phase the architecture(結構) is
established. This phase starts with the requirement
document delivered by the requirement phase and
maps the requirements into an architecture.
• The architecture defines the
– Components
– interfaces
– behaviors
2
(1)Architecture
• The architecture defines the components(元件),
interfaces, and behaviors of the system.
• The components are composed with other
components using their interfaces.
• An interface forms a common boundary of two
components. The interface is the architectural
surface where independent components meet and
communicate with each other. Over the interface,
components interact and affect each other.
3
(2)Implementation Plan
• The implementation plan establishes the schedule
and needed resources. It defines implementation
details including programming languages, platforms,
programming environments, debuggers, and many
more.
• The implementation(執行) plan could be considered
as part of the design, which is the position taken
here, or it could be considered as the first
accomplishment in the implementation phase.
4
(3)Critical Priority Analysis
• The critical priority analysis generates a list of
critical tasks. It is absolutely necessary to
successfully accomplish a critical(關鍵) task. The
project will succeed or fail based on the outcome of
these tasks. Some projects may have more than one
critical task.
• There are two major categories of critical tasks.
– One category of tasks are associated with the building of
the system.
– The other category of critical tasks are associated with the
system itself.
5
(4)Performance Analysis
• Once given the typical scenarios from the
requirement document, the system can be designed
to meet performance(效能) objectives(目標).
• Different system architectures will yield different
predicted(預測) performance characteristics(特徵)
for each typical scenario.
6
(5)Test Plan
• The test plan defines the testing necessary to
establish quality for the system.
• Ideally, 100 percent test coverage of the entire
system would be nice, but this is seldom achieved.
Creating a test suite that covers 90 percent of the
entire system is usually simple. Getting the last 10
percent requires significant amount of development
time.
• Systems are full of undiscovered bugs. The customer
becomes a logical member of the testing team and
bug fixes are pushed off to the next release.
7
Data Flow Diagrams (DFD)
• Data Flow Diagrams are used for functional modeling.
As the name suggests, it is a diagram depicting the
flow of data through the system.
• DFDs (also called data flow graphs) are commonly
used during problem analysis. DFDs are quite general
and are not limited to problem analysis for software
requirements specification(規範).
• DFDs are very useful in understanding a system and
can be effectively used during analysis.
8
Data Flow Diagrams (DFD) (con.)
• The DFD aims to capture the transformations that
take place within a system to the input data so that
eventually the output data are produced.
• The agent that performs the transformation of data
from one state to another is called a process (or a
bubble). So a DFD shows the movement of data
through the different transformation or process in
the system.
9
Data Flow Diagrams (DFD) (con.)
• DFDs are basically of 2 types:
– Physical DFDs are used in the analysis phase to study the
functioning of the current system.
– Logical DFDs are used in the design phase for depicting the
flow of data in proposed system.
10
(1)Elements of Data Flow Diagrams
• Data Flow Diagrams are composed of the four
basic symbols shown below.
– The External Entity symbol represents sources of data
to the system or destinations of data from the system.
– The Data Flow symbol represents movement of data.
– The Data Store symbol represents data that is not
moving (delayed data at rest).
– The Process symbol represents an activity that
transforms or manipulates the data (combines,
reorders, converts, etc.).
11
(1)Elements of Data Flow Diagrams
(con.)
• External Entities
– External entities determine the system boundary.
– They are external to the system being studied.
– They are often beyond the area of influence of the
developer.
– These can represent another system or subsystem.
– These go on margins/edges of data flow diagram.
12
(1)Elements of Data Flow Diagrams
(con.)
• Data Flow
– Data flow represents the input (or output) of data to (or
from) a process ("data in motion").
– Data flows only data, not control.
– Represent the minimum essential data the process needs.
Using only the minimum essential data reduces the
dependence between processes
– Data flows must begin and/or end at a process.
– Data flows are always named. Name is not to include the
word "data".
13
(1)Elements of Data Flow Diagrams
(con.)
• Data Stores
– Data Stores are repository for data that are temporarily or
permanently recorded within the system.
– It is an "inventory" of data.
– These are common link between data and process models.
Only processes may connect with data stores.
– Data stores are named with an appropriate name, not to
include the word "file”.
OR
14
(1)Elements of Data Flow Diagrams
(con.)
• Processes
– Processes are work or actions performed on incoming data
flows to produce outgoing data flows.
– These show data transformation or change.
– Data coming into a process must be "worked on" or
transformed in some way. Thus, all processes must have
inputs and outputs.
15
(2)An Example of a DFD for a System
That Pays Workers
DFD of a system that pays workers.
16
(3)Conventions(常規) used when
drawing DFD's
• It should be pointed out that a DFD is not a flowchart. A
DFD represents that flow of data, while flow chart shows
the flow of control.
• A DFD does not represent procedural information.
• Following are some suggestion for constructing a data
flow graph
– Klork your way consistently from the inputs to the outputs, or
vice versa(反之亦然). If you get stuck(問題), reverse direction.
Start with a high level data flow graph with few major
transforms describing the entire(整個) transformation from the
inputs to outputs and then refine each transform with more
detailed transformation.
17
(3)Conventions used when drawing
DFD's (con.)
– Never try to show control logic. If you find yourself
thinking in terms of loops and decisions, it is time to stop
and start again.
– Label each arrow with proper data elements. Inputs and
outputs of each transform should be carefully identified.
– Make use of * and + operation and show sufficient detail in
the data flow graph.
– Try drawing alternate data flow graphs before setting on
one.
18
Structure Charts
• In modular programming, the complete system is
coded as small independent interacting modules.
Each module is aimed at doing one specific task.
• The design for these modules is prepared in the form
of structure charts.
• A structure chart is a design tool that pictorially(形象
地) shows the relation between processing modules
in computer software.
• Describes the hierarchy of components modules and
the data are transmitted between them.
19
Structure Charts (con.)
Fig 6.2 - Notation used in structure charts.
20
Structure Charts (con.)
Fig 6.3 – Annotations(註解) and data passing in structure charts
21
Structure Charts (con.)
• Data passing
– When one module calls another, the calling module can
send data to the called module so that it can perform(執行)
the function described in its name.
– Two types of data are transmitted.
• The first, parameter data, are items of data needed in the called
module to perform the necessary work.
• In addition, control information (flag data) is also passed. Its
purpose is to assist(協助) in the control of processing by indicating
the occurrence(發生) of, say, errors or end-of-conditions.
22
Data Modeling and Data
Requirements
• The data model focuses on what data should be
stored in the database while the function model
deals with how the data is processed.
Fig 7.1 - Elements of conceptual design
23
Data Modeling and Data
Requirements (con.)
Fig 7.2 - Overall Database Design Process
24
E-R Data Modeling Technique
• The ER model is a conceptual(概念上) data model
that views the real world as a construct of entities
and associations or relationships between entities.
• A basic component of the model is the EntityRelationship diagram, which is used to visually
represent data objects.
• The constructs used in ER model can easily be
transformed into relational tables.
25
E-R Model concept
• Entities
– An entity is any distinguishable(可區別的) object about
which information is stored.
– Another classification of entities can be independent or
dependent (strong or weak) entity.
• An independent entity is one, which does not rely on another
entity for identification.
• A dependent entity is one that relies on another entity for
identification.
Fig 7.6 - Physical and Abstract Entity
26
E-R Model concept (con.)
• Attributes
– Attributes are basically properties of entity. We can use
attributes for identifying and expressing entities.
Fig 7.7 - Entity and its attributes
Fig 7.8 - Employee entity and its attribute values
27
Types of Attributes
• Key or non-key Attributes
– Identifiers(標籤), more commonly called keys or key
attributes uniquely identify an instance(實例) of an entity.
– A descriptor(敘述) describes a non-unique characteristic of
an entity instance.
– An entity usually has an attribute whose values are distinct
for each individual entity.
– There may be a case when one single attribute is not
sufficient to identify entities. Then a combination of
attributes can solve this purpose.
28
Types of Attributes (con.)
• Required or optional Attributes
– When it's required, we must have a value for it, a value
must be known for each entity occurrence.
– When it‘s optional(可選擇的), we could have a value for it,
a value may be known for each entity occurrence.
29
Types of Attributes (con.)
• Simple and composite Attributes
– Composite(組合) attributes can be divided into smaller
subparts. These subparts represent basic attributes with
independent meanings of their own.
– Attributes that can’t be divided into subparts are called
Simple or Atomic attributes.
Composite Attributes
30
Types of Attributes (con.)
• Single-valued and multi-valued Attributes
– Attributes that can have single value at a particular
instance of time are called single-valued.
– A multi-valued attribute can have more than one value at
one time.
• Stored, coded, or derived Attributes
– The attribute from which another attribute value is derived
is called stored attribute.
– Derived attributes are usually created by a formula or by a
summary operation on other attributes.
– A coded value uses one or more letters or numbers to
represent a fact.
31
Entity Types
• An entity set is a set of entities of the same type that
share the same properties, or attributes.
• Entity sets don’t need to be disjointed.
Fig. 7.10 Two entity types and some of the member entities of each
32
Designing basic model and E-R
Diagrams
• In order to begin constructing the basic model, the
modeler must analyze the information gathered
during the requirement analysis for the purpose of:
and
– classifying data objects as either entities or attributes,
– identifying and defining relationships between entities,
– naming and defining identified entities, attributes, and
relationships,
– documenting this information in the data document.
– Finally draw its ER diagram.
33
Designing basic model and E-R
Diagrams (con.)
• E-R diagrams constructs
ENTITY TYPE
WEAK ENTITY TYPE
RELATIONSHIP TYPE
ATTRIBUTE
KEY ATTRIBUTE
34
Designing basic model and E-R
Diagrams (con.)
MULTIVALUED ATTRIBUTE
DERIVED ATTRIBUTE
TOTAL PARTICIPATION OF E2 IN R
Cardinality Ratio 1:N FOR E1:E2 IN R
Structural Constraint(Min,Max) On
Participation Of E In R
35
Designing basic model and E-R
Diagrams (con.)
Fig. 7.13 E-R Diagram of Library Management System.
36
The End~
37