Architecture Design

1. Architecture Design Speaker: Kuan-Ta Lu Date: March 31

2. 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

3. (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.

4. (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.

5. (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.

6. (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.

7. (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.

8. 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.

9. 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.

10. 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.

11. (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.).

12. (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.

13. (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".

14. (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

15. (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.

16. (2)An Example of a DFD for a System That Pays Workers DFD of a system that pays workers.

17. (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.

18. (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.

19. 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.

20. Structure Charts (con.) Fig 6.2 - Notation used in structure charts.

21. Structure Charts (con.) Fig 6.3 – Annotations(註解) and data passing in structure charts

22. 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.

23. 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

24. Data Modeling and Data Requirements (con.) Fig 7.2 - Overall Database Design Process

25. 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 Entity-Relationship diagram, which is used to visually represent data objects. • The constructs used in ER model can easily be transformed into relational tables.

26. 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

27. 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

28. 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.

29. 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.

30. 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

31. 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.

32. 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

33. 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.

34. Designing basic model and E-R Diagrams (con.) • E-R diagrams constructs ENTITY TYPE WEAK ENTITY TYPE RELATIONSHIP TYPE ATTRIBUTE KEY ATTRIBUTE

35. 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

36. Designing basic model and E-R Diagrams (con.) Fig. 7.13 E-R Diagram of Library Management System.

37. The End~