Describing Use-Case Relationships with Sequence Diagrams
J ESU′S M.A LMENDROS-J IME′NEZ*AND L UIS I RIBARNE Departamento de Lenguajes y Computacio′n,Information Systems Group,University of Almeria,
04120Almeria,Spain
*Corresponding author:jalmen@ual.es
One of the key tools of the uni?ed modelling language for behaviour modelling is the use-case model.The behaviour of a use case can be described by means of interaction diagrams(sequence and collaboration diagrams),activity charts and state diagrams or by pre-conditions and post-conditions,as well as natural language text,where appropriate.This article explains a technique to describe use cases by means of sequence diagrams.It compares sequence diagrams in order to de?ne sequence-diagram relationships for identifying and de?ning use-case relationships.This article uses an automatic teller machine system case study to illustrate our proposal.
Keywords:UML,uses cases,activity diagrams,software modeling
Received16December2005;revised24July2006
1.INTRODUCTION
The uni?ed modelling language(UML)[1]provides system architects working on analysis and design with one consistent language for specifying,visualizing,constructing and docu-menting the artefacts of software systems,as well as for business modelling.
In UML,one of the key tools for behaviour modelling is the use-case model,caused by OOSE[2].Use cases are a way of specifying required usages of a system.Typically,they are used to capture the requirements of a system,that is,what a system is supposed to do.The key concepts associated with the use-case model are actors and use cases.The users and any other systems that may interact with the system are rep-resented as actors.Actors always model entities that are outside the system.The required behaviour of the system is speci?ed by one or more use cases,which are de?ned accord-ing to the actors’needs.Each use case speci?es some beha-viour,possibly including variants,which the system can perform in collaboration with one or more actors.
Use cases de?ne the offered behaviour of the system without reference to its internal structure.These behaviours, involving interactions between the actor and the system, may result due to the changes of the state of the system and communications with their environment.A use case can include possible variations of its basic behaviour, including exceptional behaviour and error handling.Each use case speci?es a unit of useful functionality that the system provides its users,i.e.a speci?c way of interacting with the system.
The behaviour of a use case can be described by means of interaction diagrams(sequence and collaboration diagrams), activity charts and state diagrams or by pre-conditions and post-conditions,as well as natural language text,where appro-priate.Which of these techniques to use will depend on the nature of the use-case behaviour as well as the intended reader. From a pragmatic point of view,use cases can be used for the speci?cation of the(external)requirements of an entity and for the speci?cation of the functionality offered by an (already realized)entity.Moreover,the use cases also indirectly state the requirements that the speci?ed entity poses to its users,i.e.how they should interact so that the entity can perform its services.
One actor can communicate with several use cases of an entity,i.e.the actor may request several services of the entity,or one use case may communicate with one or several actors when providing its service.If subsystems are used to model the system’s containment hierarchy,the system can be speci?ed with use cases at all levels,and use cases can be used to specify subsystems and classes.In addition,actors representing potential users describe the particular system view of each user and inheritance between actors is used to specify a common view of the developed system.
One of the most controversial elements of the use-case model along the UML development has been the use-case
#The Author2006.Published by Oxford University Press on behalf of The British Computer Society.All rights reserved.
For Permissions,please email:journals.permissions@https://www.doczj.com/doc/2d14434802.html,
doi:10.1093/comjnl/bxl053 The Computer Journal Advance Access published September 20, 2006
relationships called inclusion,generalization and extension, introduced by Jacobson[3].These relations have some unstable semantics along the UML development.They have received several interpretations[3–18],re?ecting a great deal of confusion among developers.
This article explains a technique to describe use cases by means of sequence diagrams.It compares sequence diagrams in order to de?ne sequence-diagram relationships for identify-ing and de?ning use-case relationships.
Sequence-diagram relationships are de?ned according to the most accepted semantics for use-case relationships.In fact,we believe that our proposal could be useful for a better understanding of the cited semantics.We believe that one of the contributions of our work is to provide a semantics of use-case relationships by means of sequence diagrams.So far,most of the works concerning use cases and their relation-ships have used the UML metamodel or pseudocode to describe the semantics.However,for practical reasons,and in order to ful?l the UML philosophy,use-case modelling should be integrated into other UML models to support the detection of mistakes and missing details in use cases and to facilitate the proper formulation of their relationships.In addition,we also present a discussion on how the development process and,in general,the developer decisions affect both use-case modelling and sequence-diagram modelling,in par-ticular,in the identi?cation of use-case relationships.
Our proposal involves that each use case is described by means of a sequence diagram.However,it is well known that use cases can be speci?ed or re?ned in several ways: with some other UML models,pre–post conditions or natural language.In addition,some use cases may not rep-resent sequences of interaction steps in the developed system but represent human tasks,services required to existent software and so on.Therefore,our proposal could seem to require a sort of tight coupling between use-cases modelling and sequence-diagram modelling.However,this is not our aim,instead we describe a speci?c method for specifying use cases by means of sequence diagrams which can be adopted in some other parts of the developed system.In summary,the developer is still free to use the use-case model for the other cited purposes.
However,the requirement analysis technique presented in our proposal may still be used for other parts of the system. In our opinion,similar relationships could be de?ned for other notations such as activity diagrams and statecharts.As future work,we might consider the study of such relationships for other notations.
This work is organized as follows.In Section2,we present the most accepted semantics of use cases and their relations. Section3describes our technique:how to describe use cases by means of sequence diagrams and how to make the corre-spondence between the inclusion,extension and generalization relationships and the sequence-diagram relationships.Finally, Section4discusses some conclusions and future https://www.doczj.com/doc/2d14434802.html,E CASES AND USE-CASE RELATIONSHIPS
In spite of many attempts to clarify the use-case relationships, there are many objections against how the UML development has de?ned the semantics of use cases and their relationships. Some authors[3,13]and the UML reference manual[1] agree that a use case is a high-level description of what the system is supposed to do,whose aim is to capture the system requirements.However,use cases have to be speci?ed, that is,many particular cases of a use case can be described.In other words,if a use case represents a user interaction,many variants of this user interaction can be described.
The variants of a use case can correspond to alternative courses or fragments of behaviour[7,8,14]inserted in the main behaviour,describing additional behaviour for particu-lar cases or exception handling.In this respect,there are two kinds of use cases[3,6–10].The?rst one consists of the so-called abstract use cases,which are fragments of beha-viour of another use case(called base use case)and are sep-arately speci?ed.Their aim is to factor out common?ows of use cases[3],but they cannot be instantiated,that is,they do not completely do an operation,and they cannot be run indi-vidually[8].It is supposed that these abstract use cases are inserted in the running of the base use case at a certain position.
In addition,some authors[3,13]agree that an‘include’relationship is not functional decomposition,i.e.inclusion should not be used for decomposing the behaviour of a use case in steps.Some other authors[3,8,13]claim that inclusion corresponds to fragments of interaction steps which are inserted in the base use case.Therefore,included use cases are abstract use cases,whereas base use cases are concrete use cases.In other words,whenever a use case includes another use case,the included use case is inserted into the main use case description.The second kind of use cases is the concrete use cases,which has a complete behaviour and is separately runnable.
In addition,some authors[7,8]claim that the fragment of interaction,represented by an included use case,should be encapsulated and that inclusion does not have interleaving semantics.Interleaving means the access from the base use case to the abstract use-case space(attributes,methods and so on)and/or from the abstract to the base use case. However,throughout the UML development,the generaliz-ation relationship has been confused with the‘extend’relationship.However,most experts on UML[3,5]agree that generalization is a way of describing particular cases of use cases.In other words,generalization/specialization is related to the concept of substitution or replacement of a use case by another with at least the same behaviour. According to this,some authors[6–8]have found out that the UML semantics(expressed in the UML metamodel)is confusing regarding the‘extend’relationships.It is clari?ed in Metz et al.[14,15],assuming that‘extend’should be
Page2of13J.M.A LMENDROS-J IME′NEZ AND L.I RIBARNE
used for expressing alternative courses:variants of the same behaviour,exception handling and so on.
With regard to the difference between‘inclusion’and ‘extension’relationships,some authors[6]stated that exten-sion is conditioned to the occurrence of a boolean condition, something like‘if this condition occurs then’,but inclusion is not conditioned,that is,an inclusion is something like‘if true then’.But,the problem is the direction of the arrow repre-senting both inclusion and extension,a problem found by some authors[6–8].
The arrow of inclusion is supposed to go from the base use
case to the included use case.But in the extension relation-ships,the arrow goes in the opposite direction.It can be explained as follows:an included use case is a piece of beha-viour of the base use case,and therefore,the base use case depends on the included use case.However,in the extension relationships,the base use case does not need the extension, that is,it is completely de?ned and the extension adds new behaviour in some speci?c point;in fact,the extension needs the base use case for it to make sense and therefore it depends on the base use case.
Finally,some authors[14,15]have deeply studied the extension points of extended use cases.Moreover,they have introduced a new concept called rejoint point,which de?nes the point on which an alternative course can rejoin to the base use case.
This interpretation can be considered as the most accepted one for use cases and use-case relationships.The proposed technique will use these intended properties and will clarify some of these concepts by means of sequence diagrams. Sequence diagrams describe use cases,and use-case relation-ships are extracted from them.
3.DESCRIBING USE CASES BY MEANS OF
SEQUENCE DIAGRAMS
This section explains a technique to describe use cases by means of sequence diagrams.In fact,we will compare sequence diagrams in order to de?ne sequence-diagram relationships,which will be used for identifying and de?ning use-case relationships.
Regarding the model-driven development,we also show a discussion on how the development process and,in general, the developer decisions affect both use-case modelling and sequence-diagram modelling,in particular,the identi?cation of use-case relationships.
Our technique can be summarized as follows.
(i)A use-case model is built and the actors are connected
to use cases.Each use case represents a task in which
the actor participates.
(ii)For each use case,a sequence diagram is built.Each sequence diagram speci?es the main interaction
steps to be achieved for each task(https://www.doczj.com/doc/2d14434802.html,e case).
Some of the interaction steps in a sequence diagram
can be deployed in another sequence diagram(or
subdiagram).
(iii)From the sequence diagrams,use-case relationships are identi?ed.Sequence subdiagrams are identi?ed
with new use cases.Then,the inclusion relationships
are identi?ed between the use cases speci?ed and
the new use cases.
(iv)The sequence diagrams are re?ned:some interaction steps are added as extensions to the original sequence
diagrams.These extensions are represented as new
sequence(sub)diagrams.These new subdiagrams are
identi?ed with new use cases.Sometimes,new
abstract use cases can be de?ned representing
generic sequence diagrams,and particular cases of
abstract use cases are identi?ed in which interaction
steps are added or rewritten.
(v)From the re?ned sequence diagrams,new use-case relationships are discovered:new generalization/
specialization and extension relationships.Generali-
zation/specialization relationships between abstract
and particular use cases are identi?ed.Extension
relationships are identi?ed between old use cases
and their extending use cases.
(vi)Some of the previous steps might be applied incre-mentally in the development process.
Next sections take as a running example the description of an automatic teller machine(ATM)system.During the expla-nation,we will focus on some speci?c parts of the ATM system.A complete version of the modelling technique applied to this ATM system is available at http://indalog.ual. es/mdd.
https://www.doczj.com/doc/2d14434802.html,e cases
We assume that a use-case diagram is a high-level description of actor interactions with the system to be developed.Figure1 shows an initial description of the use-cases diagram of the ATM system,in which we have considered three actors and four use cases.
The actors are:(a)the Manager who achieves the Startup and Shutdown of the ATM;(b)the Client who is
registered FIGURE1.Main use-case diagram of the ATM system.
U SE-C ASE R ELATIONSHIPS WITH S EQUENCE D IAGRAMS Page3of13
(i.e.Register use case)in the ATM and can Make Trans-actions once registered;(c)?nally,the Bank,an external
system that interacts with the ATM in order to carry out the bank operations.
Now,in our technique,each use case is described by means of a unique sequence of behaviour in which the developers can decide whether they includes all the steps and variants.That is,pieces of behaviour could separately be described by means of another sequence diagram.Here,a sequence should be understood as a juxtaposition of steps which can be con-ditioned,that is,the sequence can include steps such as ‘if something happens then’or even repetition structures such as ‘for each element do’.
In UML 2.0,there exist constructors to specify these kinds of ‘programming ?ow structures’such as opt and loop .Given that a use case has a unique speci?cation,speci?cations (i.e.sequence diagrams)are identi?ed with use cases.In other words,use cases are speci?ed by several scenarios
described
FIGURE 2.A sequence diagram of the Register use case.
Page 4of 13J.M.A LMENDROS -J IME
′NEZ AND
L.I RIBARNE
in a single diagram.Included use cases,use-case extensions and generalizations can thus uniformly be handled.This will be explained later on.
In Figure2,the Register use case is speci?ed by means of a sequence diagram in which a successful behaviour is described,that is,both the card number and the pin are valid.It is supposed that the developer has decided to include both validations in order to describe the basic beha-viour.However,whenever the card is not valid or the pin is incorrect,the alternative course should be separately described from other use cases,in particular,they will correspond to extensions of this base use case.
Alternatively,the developer could include all the alternative courses in a unique sequence diagram handling the invalid card and invalid pin cases inside the opt constructor.This depends on the number of alternative branches and also whether the system designer is still in a step of development, which will be re?ned later.
3.2.Associations between use cases and actors
Now,an association between a use case and an actor means that an actor participates in the behaviour described by the use case.This participation involves interaction:an observable result by the actor.In addition,if a use case includes another one,the actor necessarily interacts with the included use case.The same happens with use-case extensions and use-case specializations.
In Figure3,the Client actor interacts with the Make Transactions use case.As we can see,this includes two other use cases,Withdraw Cash and Recharge Phone-Card.Although there is no association directly connecting the actors(Client and Bank)and the included use cases, the actors can observe and therefore interact with the system to withdraw cash or recharge a phone card. However,the Mobile actor interacts only in the Recharge PhoneCard use case,given that it is directly connected to this use case.
One of the reasons why the actor interaction with the use case is required is to prevent the inclusion from corresponding to functional decomposition referring to internal processing. The use-case model shows an external view of the system [3],and therefore,each use case should interact with the actors representing the system boundaries.
3.3.Included use cases
An included use case speci?es a fragment of the base use-case behaviour.In this fragment,the actor connected to the base use case participates.The included use case is inserted in the spe-ci?cation of the base use-case behaviour.In fact,the name of the included use case is inserted as one of the sequence steps of the base.
The included use case can be either mandatory or optional, occurring in sentences such as‘if this condition occurs then ,name of use case.’or‘for each element do,name of the use case.’.The included use case is encapsulated and there is no interleaving with the base use case.
The base use case cannot access the included use case, except for the retrieval of the observable result by the actor. Therefore,included use cases are encapsulated by means of ‘methods’which can specify the data input as parameters and the data output as a return parameter.In addition,the actor connected to the base use case also interacts with the included use-case speci?cation.
Figure4shows the behaviour description of the Make Transactions use case by means of a sequence diagram. The Withdraw Cash and Recharge PhoneCard use cases have been introduced in the base sequence diagram(the base use case)using the UML 2.0notation.Both the inclusions are conditioned if in,the?rst case,the user option is‘withdraw’,and in the second case,the user option is‘recharge’.Let us remark that included use cases can be out of‘opt’boxes when the running of included use cases is mandatory.
Included use cases are used for the following two main reasons.
(i)The base use case is too big,and it is speci?ed by
means of fragments of speci?cation,that is,the beha-
viour is decomposed into several steps.However,the
speci?cation of the base use case describes how these
steps are combined in order to obtain a unique
behaviour.
(ii)A use case was speci?ed in a previous step of the development process and now it is reused.The
reuse of speci?cations is a good practice in
software FIGURE3.Deployment of the interactions for the Client actor into the ATM system.
U SE-C ASE R ELATIONSHIPS WITH S EQUENCE D IAGRAMS Page5of13
development.The developer can reuse the pre-viously speci?ed processes in a new version of the
system or a new system.In fact,the developer might work with a library of use-case speci?cations for reusing.
The inclusion is not used for functional decomposition because of the following.
(i)The actors always interact with use cases,and there-fore,internal processing is removed from the use-case diagram.
(ii)The included use case is supposed to describe a frag-ment of behaviour extracted from the base use case.
However,an extensive extraction causes too big use-case diagrams with many included use cases of small size (https://www.doczj.com/doc/2d14434802.html,e cases with few steps of execution).In addition,the use-case model is supposed to be used in the early steps of system analysis,where little information about system components is available,and therefore decomposition is useless.
In summary,the use of inclusion for functional decompo-sition is not practical,and another kind of diagrams (in our case,sequence diagrams)will be used instead.Finally,given that the base use case depends on the included use case to be runnable,the arrow will go from the base use case up to the included use
case.
FIGURE 4.Sequence diagram of Make Transactions .
Page 6of 13J.M.A LMENDROS -J IME
′NEZ AND
L.I RIBARNE
3.4.Generalization
A specialization of a use case is a use case whose sequence of steps have been specialized.There are two cases in our technique.
(i)The specialized use case replaces some steps by
specialized steps.
(ii)The specialized use case introduces new steps of
execution but without interleaving.
For instance,in Figure 3,all ATM transactions that a client can make have been generalized.The Transaction use case is a general or abstract use case and each speci?c type of trans-action is a particular case.The behaviour of the abstract use case (Transaction )is described by means of a general sequence diagram (Figure 5).The specialized Withdraw Cash use case (Figure 6)replaces some steps of the Trans-action sequence diagram and modi?es the general name of the methods.For instance,the operation()method in
the
FIGURE 5.A generalized sequence diagram of the Transaction use case.
U SE -C ASE R ELATIONSHIPS
WITH
S EQUENCE D IAGRAMS Page 7of 13
abstract sequence diagram has been rewritten by the with-draw()method in the specialized sequence.Methods 2,7
and 8have also been modi?ed to implement Withdrawing cash .Besides,method 11has been rewritten as an optional operation to deliver cash when the transaction has been successful.
However,Figure 7shows the specialized sequence to recharge a phone card.The specialization replaces some steps of the generalization,and it also introduces a new and last step of execution to send an SMS to the client’s mobile notifying the result of the recharge transaction.
The idea is that specialized use cases correspond to the concept of inheritance of object-oriented programming.That is,assuming that the designers have a use case previously speci?ed,they would like to have a new and complete use case with some slight modi?cations which consist of adding new interaction steps (conditioned or not)or modifying some existent ones.However,interaction steps can only be modi?ed when they specialize the old version.In other words,the specialized use case adds new steps and rewrites the existing ones.
In general,methods can be replaced whenever the developer knows they represent similar operations.Boolean conditions can also be replaced by more restrictive ones,and ?nally,new interactions can be introduced.However,in order to avoid interleaving semantics,the introduced interactions
can
FIGURE 6.A transaction specialization sequence to Withdraw Cash .
Page 8of 13J.M.A LMENDROS -J IME
′NEZ AND
L.I RIBARNE
only be inserted at the beginning and at the end of the original sequence.Finally,generalization /specialization can be con-sidered not only for ‘abstract’1use cases (for instance,Transaction )but also for regular use cases.
The differences regarding inclusion are clear.The inclusion is a fragment of a use case.The specialization is a new and complete version of a use case which is completely speci?ed and the similarity is annotated in the use-case diagram.However,whenever the base use case has an included use case and is specialized,the particular use case inherits the included use case,except when the included use case is
rewritten.In fact,whenever the included use case is rewritten in the specialization,a inheritance relation should be included between the two included use cases.
3.5.Extend relationships
An extension of a use case is a use case which introduces an alternative course not speci?ed in the base use case.The actor connected to the base use case participates in the extending version.
In our technique,we can consider extensions as counter-parts of the inclusion relationships.That is,once the included use case has been speci?ed separately,the name of
the
FIGURE 7.A transaction specialization sequence to Recharge PhoneCard .
1
Here,the term abstract has the meaning of not runnable use cases intro-duced in UML.
U SE -C ASE R ELATIONSHIPS
WITH
S EQUENCE D IAGRAMS Page 9of 13
included use case is inserted in the speci?cation of the base use
case,and then,we know where the included use case is inserted.
However,the extension is omitted from the speci?cation of the base use case,and now,an alternative course is speci?ed at some point of the base use case (called extension point)repre-senting the extension.In addition,a rejoint point is speci?ed.The reason why the developers may use inclusions and extensions is because the sequence diagram of the base use case is too big and they would like to specify it with several sequence diagrams.Thus,the developer uses the inclusion to specify alternative courses or exception handling,except when some alternative courses require to break the main sequence and require to abuse of ‘optional’branches in the sequence diagram.In the latter case,the use of extensions seems to be more suitable,once the alternative courses and exception handling have separately been speci?ed.
In addition,following Metz et al.[14,15],in our technique,we have considered the extension and rejoint points establish-ing at which point the main sequence is broken and where the extension point rejoins the main sequence.We
have
FIGURE 8.A more detailed use-case description of the ATM system.
Page 10of 13J.M.A LMENDROS -J IME
′NEZ AND
L.I RIBARNE
distinguished four kinds of extensions,which will be dis-cussed later.
According to the UML semantics and Jacobson[3],the arrow goes from the extending use case up to the base use case,because the base use case de?nes a complete sequence of behaviour,but the extension cannot be runnable without the base use case.Let us remark that this is the opposite case of the inclusion in which the base use case contains in its speci?cation the included use case and therefore is not runnable without the included use case.
Finally,there exists an additional reason for using exten-sions.Let us suppose that we have a general use case in which we would like to use the specialization in order to de?ne a new use case,but the new use case should modify the main sequence by adding new branches.We have con-sidered that specialization can add new interactions but without modifying the main sequence.However,we can use the extension over an abstract-specialized use case in which the extension inserts the new interactions.
Let us now pay attention to Figure8to illustrate the extend relationship.
Figure8shows a more detailed description of the use cases of the ATM system.We have used again the UML2.0notation to describe the,,extend..relationship between two use cases.An extension is complemented by a UML note.The note introduces a boolean condition and an extension point where the fragment of behaviour extends the base use case. The extension points are de?ned by means of a tuple: ,after,before..For instance,a tuple,4,9.means that the extension point where the extending use case is inserted in the base use case is after the method4and rejoins in method9.
Using tuples for extensions points,we can consider the fol-lowing four kinds of extensions.
(i)‘Same point’.Whenever after=before,that is,the
extension and rejoint points are the same.In other
words,the extension breaks the main sequence but it
returns to the same point.It can be considered as an
invocation.
(ii)‘After that’.Whenever after,before,that is,the main sequence is broken and some interactions are
removed from the main sequence.It can be considered
as a bifurcation.
(iii)‘Before that’.Whenever after.before,that is,the main sequence is broken and the extension returns to a
previous step in the main sequence.It can be con-
sidered as a loop.
(iv)‘No return’.Whenever before=no return,that is, the main sequence is broken,but the extension never
returns to the main sequence.It is used for exception
handling.
For example,the Withdraw Cash use case has an’after that’extension point when the connection with the bank is not possible and the ATM system operates with the amount available in stock(Withdraw in stock).
The extended behaviour is described by the Withdraw in stock sequence diagram shown in Figure9a.As we can see in the use-case model,the extended use case has an extension point when the condition(status is not connected) occurs.If it happens,the behaviour sequence of the With-draw in stock use case,shown in Figure9a,is run between methods4and9in the base sequence diagram (Figure6).
Figure9d and b shows two sequence examples of the before that and no return extension points,respectively.
(i)In the?rst one,if the amount is out of the required
limits,then an exception,modelled by a before
that extension point occurs.A before that exten-
sion point is similar to a loop sequence.
(ii)In the second one,if the card is not valid,the ATM de?nitively rejects the ATM operation and the main
sequence is broken.Thus,this is the case of a no
return extension point.
Finally,we have a case of the same point extension in Figure9c,when the clients request their account movements before the new transaction is achieved.
Extensions are encapsulated,that is,the base use case cannot access the extending use case.This does not make sense given that the base use case does not include the exten-sion in its speci?cation.
3.6.Abstract and concrete use cases
Base use cases and specializations are concrete use cases. Included use cases and extensions are abstract use cases, except when they are connected to an actor.
For instance,in our running example,there is an included use case which is connected to an actor.In Figure8,the actor Mobile is connected to the Recharge PhoneCard use case, which is included in the Make Transactions use case.Sup-posing that an actor is connected to the included use case,it de?nes a concrete use case instead of an abstract one.
4.CONCLUSIONS AND FUTURE WORK
In this article,we have suggested a technique for describing use cases by means of sequence diagrams,according to the most accepted semantics of use cases and use-case relation-ships.The use-case diagrams help the developer to identify the requirements of the system to be developed.Sequence dia-grams allow the developer to discover behavioural details of the system or to better describe the already existing ones.
In this article,we have shown that a direct correspondence between the requirements identi?ed in the use cases with UML sequence diagrams is feasible.
U SE-C ASE R ELATIONSHIPS WITH S EQUENCE D IAGRAMS Page11of13
As a future work,we would ?rstly like to provide a frame-work for specifying pattern design,once generalization /
specialization can be combined with inclusions and exten-sions in order to de?ne generic patterns of components,tasks and so on.Secondly,we could study the same kind of relationships in other notations such as activity diagrams and statecharts.Thirdly,we plan to extend our proposal to deal with automated code generation and component-based development,by parsing and translating use cases,relation-ships and speci?cations into a class diagram and code.Finally,we would like to incorporate all these ideas into a CASE tool and integrate our technique into the whole devel-opment process,especially into our previous works about use cases and activity diagrams [18]and use cases and graphical user interfaces design [17].
ACKNOWLEDGEMENTS
The authors would like to thank the anonymous referees for their insightful comments and suggestions,which greatly helped them improve the contents and readability of the article.This work has been partially supported by the EU (FEDER)and the Spanish MEC under grants TIN2005-09207-C03-02and TIN2006-06698.REFERENCES
[1]UML 2.(2005)Uni?ed modeling language speci?cation .Object
Management Group,Needham,USA.
[2]Jacobson,I.,Jonsson,P.,Christerson,M.and O
¨vergaard,G.(1992)Object-Oriented Software Engineering:A Use Case Driven Approach .Addison-Wesley,MA,
USA.
FIGURE 9.The four kinds of use-case extensions.
Page 12of 13J.M.A LMENDROS -J IME
′NEZ AND
L.I RIBARNE
[3]Jacobson,I.(2004)Use cases—yesterday,today,and tomorrow.
Software Syst.Model.,3,210–220.
[4]Simons,A.and Graham,I.(1999)30things that go wrong in
object modelling with UML1.3.In Kilov,H.,Rumpe,B.
and Simmonds,I.(eds),Behavioral Speci?cations of Businesses and Systems.Kluwer Academic Publishers, Norwell,MA,USA.
[5]O¨vergaard,G.and Palmkvist,K.(1999)A formal approach to
use cases and their relationships.Proc.UML’98:Beyond the Notation,Mulhouse,France,June3–4,pp.406–418.LNCS 1618,Springer-Verlag,London,UK.
[6]Ge′nova,G.,Llorens,J.and Quintana,V.(2002)Digging into
use case relationships.Proc.UML’2002,Dresden,Germany, September30–October4,pp.115–127.LNCS2460, Springer-Verlag,London,UK.
[7]Simons,A.J.H.(1999)Use cases considered harmful.Proc.
TOOLS/Europe’99,Nancy,France,June7–10,pp.194–203.
IEEE Computer Society,Washington,DC,USA.
[8]Metz,P.(2001)Against use case interleaving.Proc.UML’2001,
Toronto,Ontario,Canada,October1–5,pp.472–486.LNCS 2185,Springer-Verlag,London,UK.
[9]Isoda,S.(2005)On UML2.0’s abandonment of the
actors-call-use-cases conjecture.J.Object Technol.,4,69–80.
[10]Isoda,S.(2003)A critique of UML’s de?nition of the use-case
class.Proc.UML2003,San Francisco,CA,USA,October20–24,pp.280–294.LNCS2863,Springer-Verlag,London,UK.[11]Williams,C.,Kaplan,M.,Klinger,T.and Paradkar,A.(2005)
Toward engineered,useful use cases.J.Object Technol.,4, 45–57.
[12]Ge′nova,G.and Llorens,J.(2005)The emperor’s new use case.
J.Object Technol.,4,81–94.
[13]Genilloud,G.and Frank,W.F.(2005)Use case concepts using a
clear,consistent,concise ontology.J.Object Technol.,4,95–107.
[14]Metz,P.,O’Brien,J.and Weber,W.(2003)Specifying use case
interaction:types of alternative courses.J.Object Technol.,2, 111–131.
[15]Metz,P.,O’Brien,J.and Weber,W.(2004)Specifying use case
interaction:clarifying extension points and rejoin points.
J.Object Technol.,3,87–102.
[16]Wegmann,A.and Genilloud,G.(2000)The role of‘Roles’
in use case diagrams.Proc.UML’2000,York,UK, October2–6,pp.210–224.LNCS1939,Springer-Verlag, London,UK.
[17]Almendros-Jime′nez,J.M.and Iribarne,L.(2005)Designing
GUI components for UML use cases.Proc.ECBS’05, Greenbelt,Maryland,USA,April4–5,pp.210–217.IEEE Computer Society Press,Washington,DC,USA.
[18]Almendros-Jime′nez,J.M.and Iribarne,L.(2005)Describing
use cases with activity diagrams.Proc.MIS’04,Salzburg, Austria,September15–18,pp.141–159.LNCS3511, Springer-Verlag,London,UK.
U SE-C ASE R ELATIONSHIPS WITH S EQUENCE D IAGRAMS Page13of13
2.4 构件截面估算 构件截面尺寸的预估建立在大量实践经验基础之上，属于概念设计的部分内容，侧重于对构造的要求。 2.4.1 板厚估算 前述：由于建筑使用功能的不同，结构平面布置总呈现出一定的不规则性，实际工程中的楼面板（屋面板）布置常常是若干块单向板和若干块双向板的有机组合。 楼面板（屋面板）厚度的选用应根据使用环境、受力情况、荷载与跨度等条件综合考虑，满足承载力、挠度和裂缝控制等各方面要求；满足使用要求（包括防火要求）、施工要求及经济要求。 现浇板的厚度一般为10mm 的倍数，常用板厚为80～160mm ，特殊情况下(如结构转换层)可达800～1000mm 、或者更厚。 由于楼面板（屋面板）混凝土用量占整个楼盖（屋盖）混凝土用量的50%以上，因此在满足设计要求的前提下，板厚尽可能薄些。 （1）满足板的最小厚度要求 钢筋混凝土现浇板的最小厚度由其耐久性要求和施工要求决定，按照《混凝土规范》10.1.1确定，设计时可参考表2.4.1。 表2.4.1 现浇钢筋混凝土板的最小厚度 （2）满足板的最小高跨比要求 板的厚度除满足表2.4.1中规定的最小厚度外，还应满足表2.4.2中板厚h 与板计算跨 度L 0的最小比值要求（L 0为板短边方向的计算跨度，取值方法详3.2.1所述），旨在有效地控制板的挠度和裂缝，满足刚度设计要求。 表2.4.2 现浇钢筋混凝土板的最小高跨比
（3）单向板厚度的经验选用 根据设计经验，现浇单向板的厚度也可以由板承受的活荷载标准值、板的计算跨度大小，直接查表2.4.3确定。 表2.4.3按照荷载和跨度确定的单向板厚度 2.4.2 梁截面估算 梁截面根据不同的要求，可以选择不同的形式。 在现浇钢筋混凝土结构中，为方便施工，梁的截面形式常采用矩形、T形和倒L形，详图2.4.1所示。 图2.4.1 梁截面形式示意图 （1）梁截面尺寸的一般要求 要求，确定梁的高度h；再由一般情况下梁截面尺寸预估的步骤：先由梁的高跨比h/L 梁的高宽比h/b要求，确定梁的宽度b（b为矩形截面梁的宽度或T形、I形截面梁的腹板宽度；L 为梁的计算跨度，取值方法详3.2.2.1所述）；并满足模数要求。 ①满足梁的高跨比要求 表2.4.4列出了梁的高跨比（h/L ）下限值要求，该值可以满足一般梁在正常使用情况 下的变形要求,但对变形要求较高的梁，尚应进行挠度验算。 ②满足梁的高宽比要求 梁截面尺寸的高宽比h/b要求：对矩形截面，可选2.0～3.5； 对T形截面，可选2.5～4.0。 ③满足模数要求 梁高的模数要求：当梁高h≤800mm时，h为50mm的倍数，如250mm、300mm、400mm等；
空心板结构构件检验 1、 检验准备 对空心板构件实物进行检验前，构件混凝土的实际强度应不低于设计等级的90％；也不高于110％。如不符合上述要求时应通过分析对检验结果加以调整。 构件检验前记录构件的几何尺寸、外观缺陷、原始裂缝与预应力张拉情况。外观检查后，可在板底表面涂刷一薄层石灰浆（水灰比1：5），然后打上适当的方格，并将所有原始缺陷及裂缝在构件上标出。 构件检验时，采用经标定的砖加荷。砖垛之间应保持50～100毫米的间隙。构件的支座作成一端滚动，另端铰接，各支座支点距构件端部的长度，取。 2、 仪表布置与加荷 根据检验要求，选用百分表进行变形的量测。 根据检验要求，为了取得可作比较的量测结果，相同点的仪表宜布置两处以上。当荷载加至标准荷载的1.25倍时，所有机械仪表均应拆除。 构件变形量测仪表的布置原则如下： 构件检验前，应以不低于20％的标准荷载进行预压。以便对整个加荷系统与仪表工作情况进行检查，预压正常时即可进行卸荷，并待构件变形恢复后；通常不少于15分钟，开始记录仪表初读数，并准备正式加荷。 加荷时应按构件实际荷载增长情况划分加荷等级，但在标准荷载前不应少于四级。如难以按实际情况划分加荷等级时，一般以标准荷载的20％作为一级，第一级荷载中应计入构件与加荷设施的重量。当荷载加至计算开裂荷载的90％时，应以标准荷载的10％，逐级加荷至裂缝出现；当荷载加至计算破坏荷载的90％时，为避免构件破坏时的冲击，应以标准荷载的5％，逐级加荷至构件破坏。 构件加荷中应尽量缩短加荷时间，每级加荷不宜超过30分钟，荷载加完后应恒载10分钟，再行测读仪表并进行观察，观测时间一般不超过15分钟。钢筋混凝土及预应力钢筋混凝土构件加荷至标准荷载时，恒载时间应延长为30分钟； 3、 构件强度检验 进行强度检验的构件在加荷过程中出现下列情况之一时，即认为该构件已处于破坏状 态，此时所对应的荷载（包括自重与加荷设施重量）称为构件检验的破坏荷载； 可按构件的实测挠度达到或超过1/50跨度作为屈服的标志； 钢筋混凝土或预应力钢筋混凝土构件中的受拉钢筋被拉断或从锚固区滑移拔出； 钢筋混凝土或预应力钢筋混凝土构件上最大垂直裂缝，在受力主筋的最大宽度达到如下数值时， )(0005.02 1max f f p f l l +=δ
(三) 预估截面 结构布置结束后，需对构件截面作初步估算。主要是梁柱和支撑等的断面形状与尺寸的假定。 钢梁可选择槽钢、轧制或焊接H型钢截面等。根据荷载与支座情况，其截面高度通常在跨度的1/20~1/50之间选择。翼缘宽度根据梁间侧向支撑的间距按l/b限值确定时，可回避钢梁的整体稳定的复杂计算，这种方法很受欢迎。确定了截面高度和翼缘宽度后，其板件厚度可按规范中局部稳定的构造规定预估。 柱截面按长细比预估. 通常50~150, 简单选择值在80附近。根据轴心受压、双向受弯或单向受弯的不同,可选择钢管或H型钢截面等. 对应不同的结构，规范对截面的构造要求有很大的不同，如钢结构所特有的组成构件的板件的局部稳定问题，在普钢规范和轻钢规范中的限值有很大的区别。 除此之外，构件截面形式的选择没有固定的要求，结构工程师应该根据构件的受力情况，合理的选择安全经济美观的截面。 【焊接组合梁设计】 组合梁的型式多采用焊接工字形截面。对于这种梁的截面设计与型钢梁设计不同，对型钢梁只要确定型钢的型号即可。对组合梁则需要确定腹板的高度及厚度、翼缘的宽度及厚度等几个尺寸，而谢谢尺寸又是互相联系的。总的设计原则是既要保证梁的强度、稳定性、刚度等要求，又要使钢材用量经济合理。因此，需要根据各方面要求综合分析计算。具体方法是先根据各方面要求逐项选择截面每一个尺寸，然后进行验算。 一、梁截面选择 ㈠、梁截面高度确定 确定梁的截面高度应根据建筑设计要求（确定最大允许高度hmax）、刚度要求（确定梁最小高度hmin），且使钢材用量最小（经济高度he）等条件确定。 ㈡、腹板高度hw 腹板高度hw的确定与梁高h尺寸有关。由于上下翼缘厚度一般较小，所以腹板高度hw可略小于梁高，并按钢板规格尺寸取50mm的倍数。 ㈢、腹板厚度tw 腹板的主要作用是抗剪，在腹板高度hw确定后可根据抗剪强度公式计算腹板厚度tw。为简化计算，可近似假定最大剪应力为腹板平均剪应力的1.2倍。 以上确定的腹板高度及厚度两尺寸，还关系到腹板本身的局部稳定及梁的总用钢量。为满足梁的刚度及抗弯等要求，所确定的腹板高度一般都比较大，此时腹板厚度如取值太小（如按抗剪要求计算的厚度就很小），腹板本身很薄，会引起局部失去稳定，为此，要考虑配置纵横加劲肋。此外，厚度太小，容易由于锈蚀而降低承载能力，在制造过程中也易发生较大变形。而腹板厚度取值过大，又会使用钢量迅速增加。因此应全面考虑上述因素。腹板厚度tw应符合钢板现有规格，最小尺寸6~8mm。 ㈣、翼缘尺寸b、t 根据截面对x轴的惯性矩公式及截面对x轴的抵抗矩公式，反解出一个翼缘的截面面积（近似取h≈h1≈hw），则翼缘面积A1为： A1＝Wx/hw－（tw×hw）/b 当已知腹板尺寸hw及tw时，可根据上式求出需要的翼缘面积A1；A1＝b×t，可先选定翼缘板宽度b，后确定厚度t。 确定翼缘尺寸b及t值，关系到以下几方面：宽度b太小，对梁的整体稳定不利。宽度b
钢结构工程量快速估算方法探讨 摘要对平常的门式刚架厂房方案图阶段，在打算职员给出主钢架重量及抗风柱截面尺寸的景况下，参考门式刚架轻型衡宇钢机关技能规程。议定对常日工程量谋略阅历的总结及参考相关模范，在没有动工蓝图有景况下，参考方案图对工程的主钢机关、次钢机关、檩条、高强螺栓、平凡螺栓、屋面彩钢板、墙面彩钢板、门面积、窗的面积等的工程量实行快速的前期估算。 要害词：门式刚架厂房，方案阶段，工程量，快速估算 目录 第1章媒介 (1) 第2章门式刚架厂房工程量估算办法的分类及优缺点 (1) 2.1门式刚架厂房工程量谋略办法的种类 (1) 2.2各类工程量估算办法的优缺点 (1) 2.3门刚规程中值得参考的几个方面 (2) 第3章钢机关工程量的快速谋略及谋略原则 (2) 3.1门式刚架厂房钢机关工程量的分类 (2) 3.2种种用钢量的快速估算 (3) 第4章围护编制工程量的快速谋略及谋略法则 (5) 4.1围护编制工程量的主要分类 (5) 4.2围护编制工程量的估算 (5) 第5章排水编制工程量的快速估算 (6) 5.1天沟工程量的快速估算 (6) 5.2落水督工程量的快速估算 (6) 第6章实例应用 (7) 6.1主钢机关的谋略 (8)
6.2次钢机关的谋略 (8) 6.3檩条的谋略 (8) 6.4高强螺栓的谋略 (9) 6.5平凡螺栓的谋略 (9) 6.6地脚螺栓的谋略 (9) 6.7围护编制工程量的谋略 (9) 6.8另外阐明 (10) 6.9谋略完结列表 (10) 第7章编程应用 (10) 第8章结论 (11) 参考文献 (12) 致谢 (13) 第1章媒介 随着我国经济的快速成长及科技的前进，门式刚架机关在各行各业的应用越来越普遍。随着钢机关的打算、制作、动工的技能、阅历的老练，也使得门式刚架机关应用于各行各业。另一方面，也使得钢机关制作、动工企业，也许从打算、制作、安设全面完成业主的要求。同时，钢机关工程量的谋略的快慢及准确与否，在另一侧面影响到业务承接的胜利概率。 本篇文章，以门式刚架厂房为主，议定对职业中的实践应用和阅历的总结，陈说在无完好的动工图只有方案图的景况下，其工程量的快速估算的或者性。期盼议定总结也许对企业及关系职员的职业起到一个指导的作用。 第2章门式刚架厂房工程量估算办法的分类及优缺点 现在就钢机关行业来说，平常的门式刚架厂房东要用于产业厂房及货仓，其机关型式斗劲容易，构件的种类及规格斗劲简单团结，通常不会有太大的转变，这就为工程量的快速估算提供了一个优异的基本。 2.1、门式刚架厂房工程量谋略办法的种类。
结构布置一般原则 截面宽度不宜小于200mm 。 截面高宽比不宜大于4。 净跨与截面高度之比不宜小于4。 梁的截面尺寸取决于构件的跨度、荷载大小、支承条件以及建筑设计要求等因素， 根据工程经验，为了满足正常使用极限状态等的要求（比如梁的扰度不能过大的限制）对于多跨连续主次梁取值范围如下： h （1/14?1/8）1; （l为框架梁跨度） 框架梁截面高度宜取 框架梁截面宽度宜取 b （1/3?1/2）h； 次梁截面高度宜取h （1/18?1/12）1; （I为次梁跨度） 次梁截面宽度宜取b （1/3?1/2）h； mm ,屋面板板厚不小于60 mm，双向板板厚不小于80 mm。 二、三级且超 ① 截面的宽度和高度，四级或不超过2层时不宜小于300mm， 过2 层时不宜小于400mm ，圆柱的直径，四级或不超过2 层时不宜小于350mm， 二、三级且超过2层时不宜小于450mm。 ② 剪跨比宜大于2。 ③ 截面长边与短边的边长比不宜大于3。 现浇混凝土梁、板、柱截面尺寸估算 本设计在2轴?20轴布置横向框架梁跨度为m、m，根据所学知识跨度不一致，则 经验估算梁截面高度也会导致不一样，但是为了使结构在施工中，不因截面高度导致底部钢筋的通长 布置，否则在截面突变外锚固在柱内钢筋过多，影响柱混凝土浇筑质量， 故横向框架梁取最大值进行截面估算。 框架梁截面高度应满足h （1/14?1/8）l （1/14 ?1 /8）8400 （600 ?1050）mm 700mm ，截面宽度应满足b （1/3?1/2）h （1/3?1/2）700 （233?350）mm ，取300mm 。 本设计在A轴、C轴、D轴、E轴上布置纵向框架连系梁，以最大跨度m进行截面估 算。 （600 ?1050）纵向框架连系梁截面高度应满足h （1/14 ?1/8）l （1 /14 ?1/8）8400 mm，取h 650mm，截面宽度应满足b （1/3 ?1/2）h （1/3~ 1/2）650 （216?325）mm
2-5 钢结构计算 2-5-1 钢结构计算用表 为保证承重结构的承载能力和防止在一定条件下出现脆性破坏，应根据结构的重要性、荷载特征、结构形式、应力状态、连接方法、钢材厚度和工作环境等因素综合考虑，选用合适的钢材牌号和材性。 承重结构的钢材宜采用Q235钢、Q345钢、Q390钢和Q420钢，其质量应分别符合现行国家标准《碳素结构钢》GB/T 700和《低合金高强度结构钢》GB/T 1591的规定。当采用其他牌号的钢材时，尚应符合相应有关标准的规定和要求。对Q235钢宜选用镇静钢或半镇静钢。 承重结构的钢材应具有抗拉强度、伸长率、屈服强度和硫、磷含量的合格保证，对焊接结构尚应具有碳含量的合格保证。 焊接承重结构以及重要的非焊接承重结构的钢材还应具有冷弯试验的合格保证。 对于需要验算疲劳的焊接结构的钢材，应具有常温冲击韧性的合格保证。当结构工作温度等于或低于0℃但高于-20℃时，Q235钢和Q345钢应具有0℃C冲击韧性的合格保证；对Q390钢和Q420钢应具有-20℃冲击韧性的合格保证。当结构工作温度等于或低于-20℃时，对Q235钢和Q345钢应具有-20℃冲击韧性的合格保证；对Q390钢和Q420钢应具有-40℃冲击韧性的合格保证。 对于需要验算疲劳的非焊接结构的钢材亦应具有常温冲击韧性的合格保证，当结构工作温度等于或低于-20℃时，对Q235钢和Q345钢应具有0℃冲击韧性的合格保证；对Q390钢和Q420钢应具有-20℃冲击韧性的合格保证。 当焊接承重结构为防止钢材的层状撕裂而采用Z向钢时，其材质应符合现行国家标准《厚度方向性能钢板》GB/T 5313的规定。 钢材的强度设计值（材料强度的标准值除以抗力分项系数），应根据钢材厚度或直径按表2-77采用。钢铸件的强度设计值应按表2-78采用。连接的强度设计值应按表2-79至表2-81采用。 钢材的强度设计值（N/mm2）表2-77 钢材抗拉、抗压和抗弯抗剪端面承压（刨平顶紧）
1、某现浇多层钢筋混凝土框架结构，地层中柱按轴心受压构件计算，柱高H=6.4m ，承受轴向压力设计值N=2450kN,采用C30级混凝土，HRB335级钢筋，求柱截面尺寸（设配筋率 '0.01,1ρ?==），并试计算需配置的纵向受力钢筋。 （已知： 2 14.3N/mm c f =， 2 1.43/t f N mm =， '2 300/y y f f N mm ==） 附表：钢筋混凝土轴心受压构件的稳定系数? 设配筋率'0.01,1ρ?==，由公式知 32 ''2450101573540.9()0.9 1.0(14.30.01300) c y N A mm f f ?ρ?===+??+? 正方形截面边长396.7b mm ==，取b=400mm 。 （2）求稳定系数 柱计算长度0 1.0l H =，06400 16 400l b ==，查表得0.87?=。 （3）计算配筋 由公式知 32 '2'24501014.34000.90.90.872803.3300 c s y N f A mm f ??--??=== 2、某梁截面尺寸b×h=250mm×500mm ，M=2.0×108N·mm ，受压区预先已经配好HRB335级受压钢筋2φ20（ ' s A =628mm 2 ），若受拉钢筋也采用HRB335级钢筋配筋，混凝土的强度等级 为C30，求截面所需配置的受拉钢筋截面面积 s A 。 （已知： 2 14.3N/mm c f =， 2 1.43/t f N mm =， '2 300/y y f f N mm ==， 1 1.0 α=， ,max 0.55,0.399 b s ξα==） 解：(1)求受压区高度x 假定受拉钢筋和受压钢筋按一排布置，则 '35mm s s a a ==
第六章受压构件正截面承截力 一、选择题 1．轴心受压构件在受力过程中钢筋和砼的应力重分布均（） A ．存在；B. 不存在。 2．轴心压力对构件抗剪承载力的影响是（） A ．凡有轴向压力都可提高构件的抗剪承载力，抗剪承载力随着轴向压力的提高而提高； B ．轴向压力对构件的抗剪承载力有提高作用，但是轴向压力太大时，构件将发生偏压破坏； C ．无影响。 3．大偏心受压构件的破坏特征是：（） A ．靠近纵向力作用一侧的钢筋和砼应力不定，而另一侧受拉钢筋拉屈； B ．远离纵向力作用一侧的钢筋首先被拉屈，随后另一侧钢筋压屈、砼亦被压碎； C ．远离纵向力作用一侧的钢筋应力不定，而另一侧钢筋压屈，砼亦压碎。 4．钢筋砼柱发生小偏压破坏的条件是：（） A ．偏心距较大，且受拉钢筋配置不多； B ．受拉钢筋配置过少； C ．偏心距较大，但受压钢筋配置过多； D ．偏心距较小，或偏心距较大，但受拉钢筋配置过多。 5．大小偏压破坏的主要区别是：（） A ．偏心距的大小； B ．受压一侧砼是否达到极限压应变； C ．截面破坏时受压钢筋是否屈服； D ．截面破坏时受拉钢筋是否屈服。 6．在设计双筋梁、大偏压和大偏拉构件中要求2s x a '≥的条件是为了：（） A ．防止受压钢筋压屈； B ．保证受压钢筋在构件破坏时能达到设计屈服强度y f '； C ．避免y f '> 400N/mm 2。 7．对称配筋的矩形截面偏心受压构件（C20，HRB335级钢），若经计算，0.3,0.65i o e h ηξ>=，则应按（ ）构件计算。
A ．小偏压； B. 大偏压； C. 界限破坏。 8．对b ×h o ，f c ，f y ，y f '均相同的大偏心受压截面，若已知M 2>M 1，N 2>N 1，则在下面四组内力中要求配筋最多的一组内力是（） A ．(M 1，N 2)； B.（M 2，N 1）； C. ( M 2，N 2)； D. (M 1，N 1)。 9．当2s x a '<，在矩形截面大偏心受压构件的计算中求A s 的作法是:（） A.对s A '的形心位置取矩(取2s x a '=)求得； B. 除计算出A s 外,尚应按s A '=0求解As ，取两者中的较大值； C ．按B 法计算，但取两者中较小值； D ．按C 法取值，并应满足最小配筋率等条件。 10．钢筋砼柱发生大偏压破坏的条件是（） A ．偏心距较大； B.偏心距较大，且受拉钢筋配置较多； C ．偏心距较大，且受压钢筋配置不过多； D ．偏心距较大且受拉钢筋配置不过多。 11. 指出下列哪些说法是错误的（） A ．受压构件破坏时，受压钢筋总是受压屈服的； B. 大偏心受压构件破坏时，受拉钢筋已经屈服； C. 小偏心受压构件破坏时，受拉钢筋可能受压，也可能受拉。 二、是非题 1．在钢筋砼大偏心受压构件承载力计算时，若2s x a '<，则在构件破坏时s A '不能充分利用。 2．偏压构件，若ηe i >0.3 h o ，则一定为大偏压构件。 3．不论大、小偏压破坏时，s A '总能达到y f '。 4．螺旋箍筋仅用在轴向荷载很大且截面尺寸受限制的轴心受压短柱中。 5．配螺旋箍筋的轴心受压柱中的砼抗压强度大于f c 。 6．若轴压柱承受不变的荷载，则不论经过多长时间，钢筋及砼压应力都不随时间的变化。 7．在对称配筋偏心受压构件中，M 相同时，N 越小越安全。 三、思考题 1. 为什么要引入附加偏心距e a ，如何计算附加偏心距？ 2. 什么是结构的二阶效应？《混凝土结构设计规范》GB50010-2002中如何考虑结构的二阶效应？
框架柱截面的一般估算方法 框架柱截面的一般估算方法 框架结构是多次超静定结构,只有确定了构件截面尺寸后才能进行精确的分析计算。 框架柱截面怎么估算： 框架柱截面的高与宽一般可取（1/10~1/15）层高。并可按下列方法初步确定。 1。按轴压比要求 又轴压比初步确定框架柱截面尺寸时，可按下式计算： μN = N/Acfc 式中μN ----- 框架柱的轴压比 Ac -------框架柱的截面面积 f c--------柱混凝土抗压强度设计值 N---------柱轴向压力设计值 柱轴向压力设计值可初步按下式估算: N = γgQSNα1α2β 式中: γg -----竖向荷载分项系数 Q---------每个楼层上单位面积的竖向荷载,可取 q=12~14KN/m2 S--------柱一层的荷载面积 N---------柱荷载楼层数 α1------考虑水平力产生的附加系数,风荷载或四级抗震时 α1=1.05,三~一级抗震时α1=1.05~1.15 α2------边角柱轴向力增大系数,边柱α2 =1.1,角柱 α2 =1.2 β------柱由框架梁与剪力墙连接时,柱轴力折减系数,可取为0.7~0.8 框架柱轴压比μN 的限值宜满足下列规定: 抗震等级为一级时, 轴压比限值0.7 抗震等级为二级时, 轴压比限值0.8 抗震等级为三级时, 轴压比限值0.9 抗震等级为四级及非抗震时, 轴压比限值 1.0 Ⅳ类场地上较高的高层建筑框架柱,其轴压比限值应适当加严,柱净高与截面长边尺寸之比小于4时,其轴压比限值按上述相应数值减小0.05。 2。按柱截面最小尺寸 高层建筑框架柱的最小尺寸hc不宜小于400mm,柱截面宽度bc不宜小于350mm,柱净高与截面长边尺寸之比宜大于4。 当然，结构做多了凭经验估计应该差不了多少
根据构造要求及经验初步确定以下主要构件的截面尺寸如下： 3.2.1.1 板厚尺寸的估算 根据《混凝土结构设计规范》（GB50010-2002）知：现浇钢筋混凝土双向板的厚度要满足一下几点： ①一般情况，现浇钢筋混凝土双向板的最小厚度为80mm ； ②现浇钢筋混凝土框架结构的楼板板厚不宜小于100mm ，且要求双向板的板厚不小于跨度的1/45（简支），1/50（连续）；单向板的板厚不小于跨度的1/35（简支），1/40（连续）。 由于本方案中双向板的最大跨度为3900mm ，计算得板的厚度不小于100mm ，所以根据板的厚度确定的一般原则，结合该建筑物各板的受力情况，取板厚均为100mm ，但由于走廊、楼梯、卫生间处的恒载相对较大，所以将走廊的楼板厚取为110mm ，将楼梯、卫生间的楼板厚取为120mm 。 3.2.1.2 主梁尺寸的估算 根据《高层建筑混凝土结构设计规范》6.3.1框架结构的主梁截面高度h 可按（1/10～1/18）l 确定，l 为主梁的计算跨度；梁净跨与截面高度之比不宜小于4。且根据《建筑抗震设计规范》第6.3.1条和6.3.6条规定：梁的截面宽度不宜小于200mm ，梁截面的高宽比不宜大于4。所以框架梁截面高度一般取h=(1/18~1/10) l ，l 为框架梁的跨度。框架梁的宽度取b=（1/3~1/2）h。 故截面选择如下： 例如：HK 跨横向框架梁：L=5700mm 11()317570,5501810 h L mm mm h mm =~=~=取 11(250167,25023 b h mm mm b mm =~=~=取 250500b h mm mm ?=?取： 3.2.1.3 次梁尺寸的估算 根据《混凝土结构设计规范》可按梁的高度为（1/12～1/18）l 确定，l 为次梁的计算跨度；梁净跨与截面高度之比不宜小于4，梁的截面宽度不宜小于200mm，梁截面的高宽比不宜大于4。所以框架梁截面高度一般取h=(1/18~1/12) l ，l 为次梁的跨度。次梁的宽度取b=（1/3~1/2）h。 故截面选择如下： ①一级次梁（梁下有窗的情况）：3900L mm = 11()217325,6001812 h L mm mm h mm =~=~=取 11()217325,6001812 h L mm mm h mm =~=~=取（注：将一级次梁的高度取直600mm，主要是考虑了窗的高度，将梁高取至窗顶便于施工方便） 200600b h mm mm ?=?取： ②二级次梁（梁下无窗的情况）：3900L mm =
第四章 结构构件抗力的统计分析 4.1 主要因素分析 结构构件抗力 ：结构构件承受作用效应的能力． 结构构件承载能力，结构构件抵抗 变形的能力 背景： Z=R-S 结构构件抗力不定性：构成结构构件抗力的因素的变异 性、不确定性(模糊性、随机性) 结构构件抗力不定性的主要构成因素： 1．结构构件抗力固有的随机变异性，如构构件材料性能及几何参数的变异性．采用先进的生产和质量控制方法可降低此类不定性，但生产成本可能增加。 2．知识不足引起的不定性．如结构构件抗力计算模式的不定性．通过进一步研究与完善结构构件抗力计算模型可降低此类不定性． 3．统计不定性．系指对结构构件抗力的概率分布及 统计参数的估计偏差。通过增加试验量以及加强观测可降低统计不定性． 本章主要讨论结构构件抗力固有随机变异性及因知识不 足而引起的不定 性，即主要讨论结构构件材料性能的变异性，结构构件几何参数的变异性以及结构构件计算模式的不定性，在本章讨论中，将不考虑结构构件抗力随时间变化的问题，故三者均被视作随机变量． 4.1.1结构构件材料性能的不定性 材料性能：材料的物理性能、力学性能 。构件材料性能的不定性： 由于材质、工艺、加荷方式、环境、尺寸等因素变异产生的结 构构件材料性能的变异性。 不定性的数学描述： 分别为结构构件的材料性能值及标准试件材料性能 值。 标准试件的材料性能标准值。 K s s c K c m f f f f f f K . ==-s c f f ,-K f
令： 可得： 反映了结构构件材料性能与标准试件材料性能的差异，是随机变量 则反映标准试件材料性能的不定性，也是随机变量 统计参数： m K μ m K V 确定方法：假定 相互统计独立，采用概率论中确定随机变量函数均值、方差的线性化法则。 计算公式： 0K K K f m μμμ= 、f K V 可通过采用标准试验方法进行标准试件试验求 得， 可通过进行标准试件材料性能与实际结构构件材 料性能的对比试验再辅以工程经验判断求得． f K s s c K f f K f f ==,0f m K K K ?=00K f K m K f K K ,02 20 f m K K K V V V +=?0 0,K K V μf K μ
结构构件截面尺寸确定 一.结构布置 1。柱网选择： 1）与建筑配合确定柱网尺寸，适宜柱距。 2）平面对齐，立面连续。 2。截面选择： 1）柱：最小截面尺寸及截面高宽比，轴压比，框架梁纵筋锚固，长细比，结构位移 框架柱截面估算： 高与宽一般可取（1/10~1/15）层高。并可按下列方法初步确定。 1。按轴压比要求 又轴压比初步确定框架柱截面尺寸时，可按下式计算： µN = N/Acfc 式中 µN ----- 框架柱的轴压比 Ac -------框架柱的截面面积 f c--------柱混凝土抗压强度设计值 N---------柱轴向压力设计值 柱轴向压力设计值可初步按下式估算: N = γgQSNα1α2β ` 式中: γg -----竖向荷载分项系数 Q---------每个楼层上单位面积的竖向荷载,可取(框架：q=12~14KN/m2；砖混教室：q=16Kn/m2; 砖混住宅：q=15kn/m2; 框剪：q=13~14kn/m2; 纯筒体： q=14~16kn/m2) S--------柱一层的荷载面积 N---------柱荷载楼层数 α1------考虑水平力产生的附加系数,风荷载或四级抗震时α1=1.05,三~一级抗震时α1=1.05~1.15 α2------边角柱轴向力增大系数,边柱α2 =1.1,角柱α2 =1.2 β------柱由框架梁与剪力墙连接时,柱轴力折减系数,可取为0.7~0.8 以上计算方法结果偏大！ 框架柱轴压比 µN 的限值宜满足下列规定: 抗震等级为一级时, 轴压比限值 0.7 抗震等级为二级时, 轴压比限值 0.8 抗震等级为三级时, 轴压比限值 0.9 抗震等级为四级及非抗震时, 轴压比限值 1.0 Ⅳ类场地上较高的高层建筑框架柱,其轴压比限值应适当加严,柱净高与截面长边尺寸之比小于4时,其轴压比限值按上述相应数值减小0.05。 此外，高层建筑框架柱的最小尺寸hc不宜小于400mm,柱截面宽度bc不宜小于350mm,柱净高与截面长边尺寸之比宜大于4。 一般的估柱截面的方法： A=（受荷面积*层数*12~15）/（fc*轴压比） 轴压比一般取0.8(框架) 0.5(异框) f c--------柱混凝土抗压强度设计值
柱截面尺寸 柱截面尺寸初选，要同时满足最小截面、侧移限值和轴压比等诸多因素影响。 一般可通过满足轴压比限值惊醒截面估计。 由《建筑抗震规范》（GB50011-2001第637条和表637知，当抗震等级为三级时框架柱的轴压比最大限值［卩N为0.9。 由《混凝土结构设计》教材第281页（4-11和式（4-12估算框架柱的截面尺寸： 式（4-12 N = P FgEn其中 N—地震作用组合下柱的轴向压力设计值； B—考虑地震作用组合后柱的轴向压力增大系数，边柱取1.3,等跨内柱取1.2; F—按简支状态计算的柱的负载面积。 本设计柱网尺寸大部分为7.5m >7.5m,部分8.4m 84m。 gE—折算在单位建筑面积上的重力荷载代表值，可近似取12-15KN/ m2 ;在此取gE =12 KN/ m2。 n—演算截面以上楼层层数。 由式（4-11 N/（fcAc < [ MN]Ac > N/[卩N] X fc 由《抗规》知，框架柱按二级抗震等级设计时，其混凝土强度等级不应低于 C20。在本设计中框架梁和柱的混凝土强度等级均采用 C30。 由《建筑抗震设计》教材第四章第七节知矩形截面框架柱的截面尺寸宜符合以下两点要求:截面的宽度和高度均不宜小于300mm ;
截面长边与短边的边长比不宜大于3。 为此对于首层选用800mm< 800mm部分采用900mm< 900mm。 对于其他层，考虑到施工方便，柱截面不宜变化太多。通过初步估算以及PKPM 验算,最终确定框架的截面尺寸为： 首层-八层:选用800mm<800mm部分采用900mm< 900mm。 梁截面尺寸 框架梁(主梁截面尺寸: 主梁截面高度:h =(1/10~1/12 L =(1/10~1/12 8400=(840~700mm,取h =800mm; 主梁截面宽度:b =(1/2~1/3 h =(1/2~1/3 800=(400~267mm,取 b =400mm。次梁截面 尺寸 (1大部分房间次梁布置形式采用一字形，则次梁的跨度与主梁相同，L =7500mm。同理，取次梁高度h =600mm ;次梁宽度b =300mm。 (2在五层学术报告厅抽柱处采用井字形楼盖，相邻次梁间距为2500mm和2800mm (井字梁间距一般在2米左右。 井字梁截面高度:h =L/16=7500/16=469mm,取h =600mm; 井字梁截面宽度:b =(1/2~1/3 h =(1/2~1/3 600=>(300~200mm,取h =300mm。 4.1.3板厚 板厚根据板的跨度而定，次梁布置方式不同，板的跨度也不同，从而板的厚度也不同。混凝土结构设计规范中规定了确定板厚的方法 简支单向板h/L > 1/35两端连续单向板h/L > 1/40简支双向板h/L > 1/45多跨连续
第三节框架结构的计算简图 4.3.1 梁、柱截面尺寸 框架梁、柱截面尺寸应根据承载力、刚度及延性等要求确定。初步设计时，通常由经验或估算先选定截面尺寸，以后进行承载力、变形等验算，检查所选尺寸是否合适。 1、梁截面尺寸确定 2、柱截面尺寸 柱截面尺寸可直接凭经验确定，也可先根据其所受轴力按轴心受压构件估算，再乘以适当的放大系数以考虑弯矩的影响。即
框架柱的截面宽度和高度均不宜小于300mm，圆柱截面直经不宜小于350mm，柱截面高宽比不宜大于3。为避免柱产生剪切破坏，柱净高与截面长边之比宜大于4，或柱的剪跨比宜大于2。 3、梁截面惯性矩 在结构内力与位移计算中，与梁一起现浇的楼板可作为框架梁的翼缘，每一侧翼缘的有效宽度可取至板厚的6倍；装配整体式楼面视其整体性可取等于或小于6倍；无现浇面层的装配式楼面，楼板的作用不予考虑。设计中，为简化计算，也可按下式近似确定梁截面惯性矩I： 4.3.2 框架结构的计算简图 1、计算单元 框架结构房屋是空间结构体系，一般应按三维空间结构进行分析。但对于平面布置较规则的框架结构房屋，为了简化计算，通常将实际的空间结构简化为若干个横向或纵向平面框架进行分析，每榀平面框架为一计算单元。 就承受竖向荷载而言，当横向（纵向）框架承重，且在截取横向（纵向）框架计算时，全部竖向荷载由横向（纵向）框架承担，不考虑纵向（横向）框架的作用。当纵、横向框架混合承重时，应根据结构的不同特点进行分析，并对竖向荷载按楼盖的实际支承情况进行传递，这时竖向荷载通常由纵、横向框架共用承担。
2、计算简图 在框架结构的计算简图中，梁、柱用其轴线表示，梁与柱之间的连接用节点表示，梁或柱的长度用节点间的距离表示，框架柱轴线之间的距离即为框架梁的计算跨度；框架柱的计算高度应为各横梁形心轴线间的距离，当各层梁截面尺寸相同时，除底层外，柱的计算高度即为各层层高。对于梁、柱、板均为现浇的情况，梁截面的形心线可近似取至板底。对于底层柱的下端，一般取至基础顶面；当设有整体刚度很大的地下室；且地下室结构的楼层侧向刚度不小于相邻上部结构楼层侧向刚度的2倍时，可取至地下室结构的顶板处。
钢筋混凝土框架结构构件截面尺寸选择 1、梁的截面尺寸 (1) 梁的一般要求 在设计钢筋混凝土梁时，首先要确定梁的截面尺寸。其一般步骤是：先由梁的高跨比h/l0确定梁的高度h，再由梁的高宽比h/b确定梁的宽度b（b为矩形截面梁的宽度或T形、I形截面梁的腹板宽度），并将其模数化。对变形和裂缝宽度要求严格的梁，尚应按规定进行扰度验算及裂缝宽度验算。 ①梁的高跨比 下表列出了梁的高跨比下限值，该值可以满足一般正常使用下的变形要求。但对变形要求高的梁，尚应进行扰度验算。 梁的高跨比下限值 构件类型/支承情形简支一端连续两端连续悬臂 1/12 1/3.5 1/15 1/6 独立梁及整体肋形梁的 主梁 整体肋形梁的次梁1/16 1/8.5 1/20 1/8 注：1. 表中数值适用于普通混凝土和fy<=400N/mm2的普通钢筋； 2. 当梁的跨度超过9m时，表中系数宜乘1.2； 3. 对比重γ为15~20kN/m3的轻质混凝土结构，表中系数宜乘以（1.65-0.03γ）且不小于1的系数。 ②梁截面的高宽比 梁截面的高宽比h/b对矩形截面，可选2.0~3.5；对T形截面，可选2.5~4.0。 ③模数要求 当梁高h<=800mm时，h为50mm的倍数；当h>800mm时，h为100mm的倍数。当梁宽b>=200mm时，梁的宽度为50mm的倍数；200mm以下宽度的梁，有b=100mm、150mm、180mm三种。 ④主、次梁的截面尺寸关系 在现浇混凝土结构中，主梁的宽度不应小于200mm，通常为250mm及以上；次梁宽度不应小于150mm。主梁的高度应至少比次梁高50mm或100mm（当主梁下部可能为双排钢筋时）。 (2) 框架梁的截面尺寸 除满足梁的一般要求外，框架梁的截面高度h一般在（1/12~1/8）l0间，截面宽度b可取（1/2~1/4）h；截面宽度b不宜小于200mm；截面高度和截面宽度之比不宜大于4，梁净跨度ln与截面高度之比不宜小于4。 为了确定框架梁的截面尺寸是否选择合适，可在截面尺寸选择后作简单验算：将初步估算的竖向荷载设计值的0.8倍，作用于相应简支梁，进行受弯受剪计算，若其配筋适中，则截面选择合理；配筋过大或过小时，均宜调整截面尺寸。 2、框架柱的截面尺寸 (1) 截面尺寸的一般规定 在抗震设计中，框架柱的截面宽度和高度均不宜小于300mm，圆柱的截面直径不宜小于350mm；柱的截面高度与宽度的比值不宜大于3；柱的剪跨比宜大于2。 柱截面宽度一般不小于框架主梁截面宽度+100mm，通常在（1/15~1/20）H
混凝土梁板柱截面尺寸估算 3.2 结构布置 3.2.1 结构布置一般原则 3.2.1.1 现浇混凝土梁结构布置原则 3.2.1.1.1 框架梁截面基本要求 根据《建筑抗震设计规范》GB50011-2010第6.3.1条规定:梁的截面尺寸应满足框架的基本抗震构造措施，宜符合下列各项要求: mm? 截面宽度不宜小于200。 ? 截面高宽比不宜大于4。 ? 净跨与截面高度之比不宜小于4。 3.2.1.1.2 主次梁截面确定基本要求 梁的截面尺寸取决于构件的跨度、荷载大小、支承条件以及建筑设计要求等因素，根据工程经验，为了满足正常使用极限状态等的要求(比如梁的扰度不能过大的限制)，对于多跨连续主次梁取值范围如下: 框架梁截面高度宜取 h,(1/14~1/8)l;(l为框架梁跨度) 框架梁截面宽度宜取b,(1/3~1/2)h; 次梁截面高度宜取 h,(1/18~1/12)l;(l为次梁跨度) b,(1/3~1/2)h;次梁截面宽度宜取 3.2.1.2 现浇混凝土板结构布置原则 根据《混凝土结构设计规范》GB50010-2010第9.1.2条规定:现浇混凝土板的尺寸是根据板的跨厚比确定:钢筋混凝土单向板不大于30，双向板不大于40，且现浇钢筋混凝土板的厚度不应小于《混凝土结构设计规范》GB50010-2010表9.1.2规定:单向板板厚不
小于60mm，屋面板板厚不小于60mm，双向板板厚不小于80mm。 3.2.1.3 框架柱结构布置原则 根据《建筑抗震设计规范》GB50011-2010第6.3.5条规定:柱的截面尺寸，宜符合下列各项要求: mmmm? 截面的宽度和高度，四级或不超过2层时不宜小于300，一、二、三级且超过2层时不宜小于400，圆柱的直径，四级 mmmm或不超过2层时不宜小于350，一、二、三级且超过2层时不宜小于450。 ? 剪跨比宜大于2。 ? 截面长边与短边的边长比不宜大于3。 3.2.2 现浇混凝土梁、板、柱截面尺寸估算 3.2.2.1 现浇混凝土梁截面尺寸估算 3.2.2.1.1 横向框架梁截面尺寸估算 mm本设计在2轴,20轴布置横向框架梁跨度为8.9、6.5，根据所学知识跨度不一致，则经验估算梁截面高度也会导致不一样，但是为了使结构在施工中，不因截面高度导致底部钢筋的通长布置，否则在截面突变外锚固在柱内钢筋过多，影响柱混凝土浇筑质量，故横向框架梁取最大值进行截面估算。 框架梁截面高度应满足，取，截面宽度应满足 h,(1/14~1/8)l,(1/14~1/8)8400,(600~1050)mmh,700mm ，取。 b,(1/3~1/2)h,(1/3~1/2)700,(233~350)mmb,300mm 3.2.2.1.2 纵向框架连系梁截面尺寸估算 m本设计在A轴、C轴、D轴、E轴上布置纵向框架连系梁，以最大跨度8.4进行截面估算。 纵向框架连系梁截面高度应满足h,(1/14~1/8)l,(1/14~1/8)8400,(600~1050)
￡定义。 混凝土无损检测是指在不破坏混凝土结构构件的条件下，在混凝土结构构件原位上对混凝土强度和缺陷进行直接定量检测的技术。一般还包括局部破损的检测方法。 试块实测值只能被认为是混凝土在特定条件下的性能反应，而不能确砌代表结构物原位混凝土的质量状况。 混凝土无损检测的目的 1检测结构构件混凝土强度值 2检测结构构件混凝土内部缺陷 3检测几何构件尺寸 4混凝土强度质量的匀质性 5建筑热工隔声防水的物理特性 ￡回弹法检测混凝土强度 一检测原理， 定义:采用回弹仪检测混凝土抗压强度的方法 二原理: 混凝土 (密实度)， 表层硬度 (特征) 能量损失 (核心) 弹簧回弹能量值 (技术手段) 混凝土抗压强度 (目的) 三回弹法检测混凝土强度的影响因素 1原材料及配合比胶材、细骨料、粗骨料－品种用量、水胶比 2外加剂品种及ph值
非引气型外加剂仍可行（混凝土密实度及碱度） 3成型方法离心法真空法压浆法喷射法和混凝土表层经过各种物理化学方法成型的混凝土，请慎重使用，必须经试验验证后，方可进行。 4养护方法和湿度蒸汽养护、标准养护，自然养护，湿度对低强度的混凝土影响较大5碳化和龄期， 三年内不同强度混凝土，回弹值随着碳化深度增大而增大，碳化深度超过6mm后影响基本不变 6模版 7其他 回弹仪检定周期为半年。 3.2.1当回弹仪具有下列情况之一时，应由法定计量检定机构进行检定 ★3.2.2回弹仪的率定实验应符合下列规定 3回弹值应向下弹击三次的稳定回弹结果的平均值 4率定实验应分四个方向进行且每个方向弹击前弹机杆应旋转90度，每个方向的回弹平均值均为80 2 3.3.1当回弹仪存在下列情况时，应进行保养 一回弹仪弹击超过2000次二在钢砧上率定值不合格三对检测值有怀疑 4检测技术 4.1一般规定 4.1.3混凝土强度，可按单个构件或按批量进行检测并应符合下列规定 1单个构件的检测应符合本规程的规定 2对于混凝土生产工艺、强度等级相同，原材料、配合比养护条件基本一致且龄期相近的一批同类构件的检测应采用批量检测。批量进行检测时并随机抽取构件，抽检数量不少于同批构件总数的30%且不宜少于10件。当检验批受检构件数量大于30个时，抽检构件数量可适当调整。并不得少于国家现行有关标准规定的最小抽样数量。 4.1.4单个构件的检测应符合下列规定 1、对于一般构件检测区测区数不宜少于10个。当受检构件数量大于30个且不需提供单个构件推定强度或受检构件一方向尺寸不大于4.5m且另一方向尺寸不大于0.3m 时，每个构件的测区数量可适当减少，但不应少于五个 2、相邻2测区的间距不应大于2m，测区离构件端部和施工缝边缘的距离不应大于0.5m，且不宜小于0.2m。 3、测区宜选在能使回弹仪处于水平方向的混凝土浇筑侧面
一．框架结构是多次超静定结构,只有确定了构件截面尺寸后才能进行精确的分 析计算。 框架柱截面怎么估算： 框架柱截面的高与宽一般可取（1/10~1/15）层高。并可按下列方法初步确 定。 1。按轴压比要求 又轴压比初步确定框架柱截面尺寸时，可按下式计算： μN = N/Acfc 式中μN ----- 框架柱的轴压比 Ac -------框架柱的截面面积 f c--------柱混凝土抗压强度设计值 N---------柱轴向压力设计值 柱轴向压力设计值可初步按下式估算: N = γGqSnα1α2β 式中: γG -----竖向荷载分项系数 q---------每个楼层上单位面积的竖向荷载,可取q=12~14KN/m2 S--------柱一层的荷载面积 n---------柱荷载楼层数 α1------考虑水平力产生的附加系数,风荷载或四级抗震时α1=1.05,三 ~一级抗震时α1=1.05~1.15 α2------边角柱轴向力增大系数,边柱α2 =1.1,角柱α2 =1.2 β------柱由框架梁与剪力墙连接时,柱轴力折减系数,可取为0.7~0.8 框架柱轴压比μN的限值宜满足下列规定: 抗震等级为一级时, 轴压比限值 0.7 抗震等级为二级时, 轴压比限值 0.8 抗震等级为三级时, 轴压比限值 0.9 抗震等级为四级及非抗震时, 轴压比限值 1.0 Ⅳ类场地上较高的高层建筑框架柱,其轴压比限值应适当加严,柱净高与截面长边尺寸之比小于4时,其轴压比限值按上述相应数值减小0.05。 2。按柱截面最小尺寸 高层建筑框架柱的最小尺寸hc不宜小于400mm,柱截面宽度bc不宜小于350mm, 柱净高与截面长边尺寸之比宜大于4。 二．柱截面的确定，在高层的情况下，往往是由轴压比控制，而多层不见得是。层数越少，越可能不是轴压比控制。这是个概念问题，首先应当明确。对高层（或者层数较多的多层），在柱截面估算时，应当先明确几点：混凝土的强度等级、结构的抗震等级、轴压比限值。只有知道这几点，估算轴力才可能确定截面。柱轴力的估算，首先确定每层柱受荷的面积。此部分的面积，可简单的取柱左右（上下）两个跨度之和的一半进行计算。再根据结构型式及活荷载的情况，确定每层的自重。这个自重是个经验值，在各种手册上都有相关的介绍。一般是框架结构14~16KN/m^2，剪力墙结构15~18KN/m^2。值得提醒的是，这里的自重是标准值，而在算柱轴压比时应当采用设计值。最后，对每层的受荷载面积累加并乘以结构的自重，可算出柱轴力，柱轴力除以轴压比限值可得出柱截面面积。 以上情况，仅是对柱截面的估算。最后应当整体的计算结果进行调整。 框架柱截面的估算