Secure UML Information Flow using FlowUML
Khaled Alghathbar
1
, Duminda Wijesekera
1
, and Csilla Farkas
2†
1
Dept. of Information and Software Engineering and CSIS,
George Mason University, MS 4A4, Fairfax, VA 22030
2
Information Security
Laboratory, Dept. of Computer Science and Engineering,
University of South Carolina, Columbia, SC 29208
Abstract. FlowUML is a logic-based system to validate information flow poli-
cies at the requirements specification phase of UML based designs. It uses
Horn clauses to specify information flow polices that can be checked against
flow information extracted from UML sequence diagrams. FlowUML policies
can be written at a coarse grain level of caller-callee relationships or at a finer
level involving passed attributes.
1 Introduction
As security becomes an important aspect of large software systems, it needs to be
addressed through out the software development life cycle. Considered a non-
functional requirement, security requirements have not been considered during the
early phases of system development; thus resulting in vulnerable software [7]. In
[13,14] Nuseibeh and Easterbrook present the need to formally analyze and validate
security requirements during earlier phases to detect and remove design vulnerabili-
ties Recent work has addressed information flow control security [3,1,12,16]. Infor-
mation flow requirements need to be developed and evaluated during the require-
ments and design stages of the software life cycle, as validating information flow
requirements at an early stage prevents costly fixes mandated during latter stages of
the development life cycle. In this paper we propose a logic-based system
(FlowUML) to validate information flow policies at the requirements specification
phase of UML-based designs [17]. FlowUML uses locally stratified Horn clauses to
enforce user specifiable information flow policies via three processes: 1) Extract
information flows predicates from UML sequence diagram, 2) Derive all inherited
and indirect flows, and 3) Check for compliances with specified policies - specified at
two levels of granularity. At the coarse level, a flow is represented as a directed arc
between components, going from its source to its sink. At the fine level, the flow is
defined based on the semantics of methods, attributes passed between the compo-
nents, and the roles played by the components.
†
Farkas’ work was partially supported by the National Science Foundation under grant number
IIS-0237782.
Alghathbar K., Wijesekera D. and Farkasâ
˘
A
˘
a C. (2005).
Secure UML Information Flow using FlowUML.
In Proceedings of the 3rd International Workshop on Security in Information Systems, pages 229-238
DOI: 10.5220/0002569802290238
Copyright
c
 SciTePress

FlowUML does not assume the existence of a particular meta-policy and can sup-
port a variety of policies. FlowUML advances over existing secure information flow
models by applying a formal framework to the early phases of the software develop-
ment life cycle. Towards that end, Section 2 shows information flow specifications
embedded in UML sequence diagrams. Section 3 provides a running example. Sec-
tion 4 describes our notations and assumptions. Section 5 explains the FlowUML
process. Section 6 has the syntax and semantics of FlowUML. Section 7 shows the
expressibility of FlowUML by means of the running example. Section 8 describes
related work and Section 9 concludes the paper.
2 Flow Specification in UML
The UML is the de-facto design language for large software projects. The UML uses
multiple diagrams (views) to represent requirements and designs. Use Cases support
the specification of usage scenarios between the system and its intended users [17].
Interaction diagrams specify how objects in the use case interact with each other.
Sequence diagrams are specific interaction diagrams that show such interactions as a
sequence of messages exchanged between objects over time. The sequence diagrams
shown in Fig. 1 consists of four objects and two actors, where Actor A initiates the
first flow as a request to read information from Obj3 which then returns the requested
information. Secondly, Actor A writes information to Obj4 and the control object.
The flow to the control object triggers additional flows. FlowUML extracts flows
from the sequence diagrams.
ActorA
Obj3
Obj4
control
Obj5
read
write
call another control
read
write
ActorB
write
write
ActorA
Obj1
Obj2
Read()
write(att1)
Return(att1)
Fig. 1. A sample sequence diagram Fig. 2. The sequence diagram for use
case1
3 Running Example
Our example consists of two use cases. Use case 1 has a simple scenario shown in
Fig.
2, and use case 2 has a more complex scenario shown in Fig. 3. The actor in use
case 1 reads information from object Obj1 returned as an attribute att1 and then
writes it to Obj2. The actor in use case 2 transfers information between two objects
and then calls another object leading to additional information flow.
During the analysis stage of the software development, selected interactions are
specified between objects. These interactions are further refined by specifying the
230

message’s attributes or parameters passed between objects. Therefore, the expres-
siveness and detail in a sequence diagram depends on the analysis stage. For example,
the sequence diagram of use case 2 can be categorized into two views: coarse grain
view shown in Fig. 1 and the fine grain view shown in Fig. 3.
Flow and access control requirements are expressed over the actors and objects of
the sequence diagram. For example, we may specify that information is permitted to
flow from Obj 3 to Obj. 4 but not vice verse. Similarly, we may permit of deny Actor
A to read Obj. 3.
ActorA
Obj3
Obj4
control
Obj5
read(att1)
write(att2)
call(att3)
read(att3')
write(att4)
Return(att2,att3)
Return(att4)
ActorB
write(att6)
write(att5)
Fig. 3. Detailed sequence diagram for use case 2
4 Notations and Assumptions
Objects in sequence diagrams belong to three categories: actors, entities, or control
objects. Actors initiate flows and send/receive information to/from the system as
externals. Every use case has at least one actor. Entity objects are persistent and store
information. Control objects provide coordination and application logic. Generally,
actors and entity objects can be sources or sinks of information flows and control
objects do not store information. However, they may create new information without
storing them. This is a basic axiom of FlowUML.
Axiom 1: Sources and sinks of Information flows are actors and entities.
Information flows in sequence diagrams arise due to attributes passed in method
calls such as read and write. For example, the method read(att1) exchanges informa-
tion between Obj3 and Actor A. FlowUML uses any message as a flow of informa-
tion regardless of its name.
Axiom 2: Any information-carrying message is considered an information flow.
Sequence diagram builds complex messages from simple ones using three kinds of
constructs: creation messages used to create new objects, iteration messages used to
send data multiple times, and conditional messages used to control messages based
satisfying certain conditions. We consider a creation message as an information flow
if the caller passes creation parameters to the callee. We consider an iterated message
as a single information flow. We consider a conditional message to be an information
flow regardless of the truth-value of the condition. We consider a simple message as a
flow if it passes information.
231

4.1 Attribute Dependencies across Objects
We make the following observations about the attributes:
1. Information flowing into an object may flow out unaltered, called exact attribute
flow in FlowUML.
2. Some attributes flowing out of an object may be different in name but always
have the same value as an attribute that flow into the same object. FlowUML re-
quires this information to be in the similar attribute table.
3. Some attributes flowing out of an object may depend upon others that flow into
the same object. FlowUML requires this information to be in the derived attrib-
ute table.
We formalize these observations in the following definitions and axioms.
Definition 1: An exact attribute is one that flows through an object but does not
change its value. An attribute that flows out of an object depends upon a set of attrib-
utes flowing into the same object. We say that the output attribute is derived from the
input attributes.
Axiom 3: Attribute names are unique over a system.
Axiom 4: Pairs of exact attribute s are entered into the exact attribute table and
dependent attributed have an entry in the dependent attribute table.
At the requirements specification stage flow analysis depends on 1) the types of com-
ponents (i.e., actor, entity or control object), 2) the sequence of objects in a flow, and
3) whether the flow is within a use case or between many use cases. For example,
entities or actors may alter information while control objects do not.
5 The Verification Process
FlowUML verify flow policies using five steps using two metadata sources as shown
in Fig. 4. Coarse grain policies require less detail than fine grain policies. Fine grain
policies incorporate attribute values and their dependencies.
232

Additional Metadata for the fine-grain policy
Metadata
propagating
inheritances
transitive
flow policies
Detecti ng
unsafe flow
Unsafe flow is detected
Resolve flows conflicts
Safe Flow
Defining
Flow
structure
Finalizing
Flow
…………...
Fl o w Structure
…………...
Flow Const r aint s
…………...
Similar Attributes
…………...
Derived Attributes
Fig. 4. Steps in FlowUML
Coarse grain policy analysis
In the first step FlowUML extracts flow structure, called the defining flow structure,
from Sequence diagrams and transforms it into basic predicates (see Section 6). The
second step propagates basic predicates using the actor (or role) hierarchy, deriving
implied information flows. The third step derives all transitive flows. The fourth step
complements the third step by filtering results of the third step to those flows that
satisfy properties of interests as specified in the policies. For example, in Fig. 1 the
third step derives a flow from Obj3 to Actor A directly, flow from Obj3 to Obj4
through Actor A, flow from Obj3 to control through Actor A etc. In the fourth step,
predefined policies may only apply to non-transitive flows between only entities and
actors. Thus only flows from Obj3 to Actor A and the one from Actor A to Obj4, but
not the flow from Obj3 to Obj4 may be of relevance. The fifth step detects flows that
violate specified policies. Currently, FlowUML does not attempt to resolve the de-
tected conflicts automatically.
Fine grain policy analysis
Fine grain policies require two kinds of additional information. The first, given in the
similar attribute table, contains name of the attributes that always contain the same
data value. The second, given in the attribute derivation table, lists attribute depend-
encies. This information is useful in controlling the flow of sensitive information. For
example, in Fig. 3, if there is a record in the attribute derivation table stating that att6
is derived from att3 in the control object then FlowUML concludes that there is a
transitive flow from Actor A to Actor B.
6 Syntax and semantics
FlowUML alphabet contains variables or constants over actors (A), objects (Obj), use
cases (UC), attributes (Att), and times (T). Constants are members of the sets A, Obj,
233

UC, Att, and T. Variables are represented as X
a
, X
obj
, X
uc
, X
att
and X
t
, respectively.
FlowUML uses the following predicates:
Basic predicates for supporting the specification of flows, called FlowSup.
1. A unary predicate isEntity(X
obj
) meaning X
obj
is an entity.
2. A unary predicate isActor(X
obj
) meaning X
obj
is an actor.
3. A binary predicate specializedActor(X
a
,X’
a
)meaning X’
a
is a specialized actor of
X
a
.
4. A binary predicate precedes(X
uc
, X’
uc
) meaning use cases X
uc
and X’
uc
are exe-
cuted in that order.
5. A binary predicate sameAtt(X
att
, X’
att
) meaning attributes X
att
and X’
att
have the
same value.
6. A binary predicate derAtt(X
att
, X’
att
, X
obj
) meaning that attribute X’
att
is derived
from attribute X
att
in object X
obj
.
7. A ternary predicate ignoreFlow(X
a
, X
obj
, X’
obj
) meaning to exclude the flow from
object X
obj
to object X’
obj
.
8. A 6-ary predicate ignoreFlows(X
a1
, X
obj1
, X’
obj1
, X
a2
, X
obj2
, X’
obj2
) to exclude the
flow from X
obj1
to X’
obj
and the flow from X
obj2
to X’
obj2
from being detected as a
violation of flow control policies. Two similar predicates ignoreFlows
att
(X
a1
,X
att
,
X
obj1
,X’
obj1
,X
a2
,X
obj2
,X’
obj2
) and ignoreFlow
att
(X
a
, X
att
,X
obj
,X’
obj
) are used in fine
grain policies
Predicates for specifying flow constraints, called ConstSup.
1. A binary predicate dominates(X
obj
,X’
obj
) meaning that the security label of object
X’
obj
dominates or equals the security label of object X
obj
. It is used in multi-level
security policies.
2. A binary predicate ACL(X
obj
,X’
obj
,X
AT
) meaning that object X
obj
is in the access
control list of object X’
obj
. It is used in discretionary access control policies. X
AT
is an operation such as read or write.
3. A binary predicate conflictingActors(X
obj
,X’
obj
) meaning that actors X
obj
and
X’
obj
are in conflict with each other for a specific reason. For example, both ac-
tors can not flow information to the same object or there must not be a flow of
information between them.
4. A binary predicate conflictingEntities(X
obj
,X’
obj
) meaning both entities X
obj
and
X’
obj
are in conflict with each specific reason. For example, each entity belongs
to different competitive company and information must not flow in between.
Predicates for coarse-grain policies
1. A 5-ary predicate Flow(X
a
,X
obj
,X’
obj
,X
t
,X
uc
) meaning there is a simple flow initi-
ated by actor X
a
from object X
obj
to object X’
obj
at time X
t
in use case X
uc
.
2. A 5-ary predicate mayFlow(X
a
,X
obj
,X’
obj
,X
t
,X
uc
) is the transitive closure of the
previous predicate.
3. mayFlow
interUC
(X
a
,X
obj
,X’
obj
,X
t
,X
uc
) is similar to mayFlow but the scope of may-
flow
interUC
is between use cases instead of focusing in one use case.
4. A 4-ary predicate finalFlow(X
a
X
obj
,X’
obj
,X
t
) meaning a finalized flow.
5. finalFlow
interUC
(X
a
,X
obj
,X’
obj
,X
t
) is similar to finalFlow but it covers flows be-
tween use cases.
6. A ternary predicate unsafeFlow(X
a
,X
obj
,X’
obj
) meaning there is an unsafe flow
from X
obj
to X’
obj
initiated by actor X
a
.
234

7. A 6-ary predicate unsafeFlows(X
a1
,X
obj1
,X’
obj1
, X
a2
, X
obj2
, X’
obj2
) meaning there
are two unsafe flow. The first, initiated by actor X
a1
flows from X
obj1
to X’
obj1
.
The second, initiated by actor X
a2
flows from object X
obj2
to object X’
obj2
. They
are unsafe because together they violate a flow constraint.
8. A ternary predicate safeFlow(X
a
,X
obj
,X’
obj
) meaning that the flow initiated by
actor X
a
from object X
obj
to object X’
obj
is safe.
Predicates for fine-grain policies
The predicates used to specify fine grain access control policies are similar to the
ones for coarse grain policy, but include X
att
as an attribute flowing between objects.
The predicates are as follows: flow
att
(X
a
,X
att
,X
obj
,X’
obj
,X
t
,X
uc
), mayFlow
att
(X
a
,X
att
,X
obj
,X’
obj
,X
t
,X
uc
), mayFlow
interUC_att
(X
a
,X
att
,X
obj
,X’
obj
,X
t
,X
uc
), finalFlow-
att
(X
a
,X
att
,X
obj
,X’
obj
,X
t
), finalFlow
interUC_att
(X
a
,X
att,
X
obj
,X’
obj
,X
t
), unsafeFlow-
att
(X
a
,X
att
,X
obj
,X’
obj
), unsafeFlows
att
(X
a1
,X
att1
,X
obj1
,X’
obj1
,X
a2
,X
att2
,X
obj2
,X’
obj2
), safe-
flow
att
(X
a
, X
att1
,X
obj
,X’
obj
).
FlowUML uses a set of predicates, as summarized in Tables 1 and 2 A FlowUML
rule is of the form
L ← L , …L
1 n
where L , L , …L
1 n
are literals satisfying the condi-
tions stated in Tables 1 and 2. Rules constructed according to these specifications
form a locally stratified logic program, and therefore has a unique stable model and
that stable model is also a well-founded model [11].
Table 1. FlowUML’s strata for coarse-grain policies
Table 2. FlowUML’s strata for fine-grain policies
Phase Stratum Predicate Rules defining the predicate
0
FlowSup predicates
ConstSup
predicates
base relations.
base relations.
1
Flow(X
a
, X
obj
, X ’
obj
, X
t
, X
uc
)
body may contain FlowSup predicates.
2
mayFlow(X
a
, X
obj
, X ’
obj
, X
t
, X
uc
)
body may contain literal from strata 0 to 2
3
mayFlow
inter UC
(X
a
, X
obj
, X ’
obj
, X
t
, X
uc
)
body may contain literal from strata 0, 1 and 3
4
finalFlow(X
a
, X
obj
, X ’
obj
, X
t
)
finalFlow
inter UC
(X
a
, X
obj
, X ’
obj
, X
t
)
body may contain literal from strata 0 to 3
Coarse-grain
5
unsafeFlow(X
a
, X
obj
, X ’
obj
)
unsafeFlows(X
a1
, X
obj1
, X ’
obj1
, X
a2
, X
obj2
,
X’
ob
j
2
)
body may contain literal from strata 0 to 4
6
saf eF l ow ( X
a
, X
obj
, X ’
obj
)
body may contain literal from strata 0 to 5
Phase Stratum Predicate Rules defining the predicate
0
FlowSup predicates
ConstSup
predicates
base relations.
base relations.
1
Flow
at t
(X
a
, X
obj
, X ’
obj
, X
t
, X
uc
)
body may contain FlowSup predicates.
2
mayFlow
att
(X
a
, X
obj
, X ’
obj
, X
t
, X
uc
)
body may contain literal from strata 0, 1 and 2
3
mayFlow
inter UC_att
(X
a
, X
obj
, X ’
obj
, X
t
, X
uc
)
body may contain literal from strata 0, 1 and 3
4
finalFlow
at t
(X
a
, X
obj
, X ’
obj
, X
t
)
finalFlow
inter UC_att
(X
a
, X
obj
, X ’
obj
, X
t
)
body may contain literal from strata 0 to 3
Fine-grain
5
unsafeFlow
at t
(X
a
, X
att
, X
obj
, X ’
obj
)
unsafeFlows
att
(X
a1
, X
at t 1
,X
obj1
, X ’
obj1
, X
a2
,
X
at t2
, X
ob
j
2
, X ’
ob
j
2
)
body may contain literal from strata 0 to 4
6
saf eF l ow
att
(X
a
, X
at t1
, X
obj
, X ’
obj
)
body may contain literal from strata 0 to 5
Table 2. FlowUML’s strata for fine grain policies
Table 1. FlowUML’s strata for coarse grain policies
235

7 Applying FlowUML
This section shows how some sample FlowUML policies and apply them to detect
unsafe flows. Due to space limitation, we only present the basic flow predicates,
propagation policies, and the security verification for discretionary access control.
Basic flow predicates: Examples flow information available in Fig. 2 are given in
rules (1). The rules (2) to (6) are instances of FlowSup predicates of Figs 2 and 3.
Flow
att
(ActorA,att1,Obj1,ActorA,1,uc1)← Flow
att
(ActorA,att1,ActorA,Obj2,2,uc1)←
(1)
isEntity(obj1)← , isActor(actorA)←, precedes(uc1,uc2)←,
(2,3,4)
sameAtt(att3, att3’)←, derAtt(att3, att6, control)←
(5,6)
Propagation policies: The second step applies a policy that propagates flows along
actor hierarchies. In our example, if there is a specialized actor say Actor C of Actor B
then Actor C receives att5 and att6. Policies stating acceptable inheritances can be
stated in example rules such as (7) to (9).
Rule 7 say that every actor that plays a specialized role of an actor that initiates a
flow also initiates an inherited flow. In rules 8 and 9, for every flow from or to an
actor, respectively, rules 8 and 9 add new information flow for every specialized actor
of the actor who sends or receives the information, respectively.
Flow(X’
a
, X
obj
, X’
obj
, X
t
, X
uc
) ← Flow(X
a
, X
obj
, X’
obj
, X
t
, X
uc
), specializedRole(X
a
,
X’
a
)
(7)
Flow(X
a
, X’’
obj
, X’
obj
, X
t
, X
uc
) ← Flow(X
a
,X
obj
,X’
obj
,X
t
,X
uc
) ,isActor(X
obj
), special-
izedActor(X
obj
,X’’
obj
)
(8)
Flow(X
a
, X
obj
, X’’
obj
, X
t
, X
uc
) ← Flow(X
a
,X
obj
,X’
obj
,X
t
,X
uc
) ,isActor(X’
obj
), special-
izedActor(X’
obj
,X’’
obj
)
(9)
Detecting flows unsafe with respect to policies: This section shows FlowUML
specification of known flow control policies, and how to detect information flows
unsafe with respect to them.
Mandatory Access Control (MAC) permits a subjects to read an objects only if the
subject’s security clearance dominates the security classification of the object (2).
Rule 18 specify if information flows from Obj1 to Obj2. If Obj2 does not dominate
or equals the security label of Obj1 then the flow is considered unsafe.
unsafeFlow(X
a
, X
obj1
, X
obj2
)← finalFlow(X
a
, X
obj1
, X
obj2,
X
t
), ¬dominates(X
obj1
, X
obj2
)
(18)
Discretionary access control (DAC) allows subjects to access objects solely based
on the subject’s identity and the authorization rule. Rule 19 specify unauthorized
information flows from an actor to an object and rule 20 specify unauthorized flows
from an object to an actor.
unsafeFlow
att
(X
a
, X
att1
, X
obj1
, X
obj2
)← finalFlow(X
a
, X
att1
, X
obj1
, X
obj2,
X
t
), ¬ACL(X
obj1
, X
obj2
, w)
(19)
unsafeFlow
att
(X
a
, X
att1
, X
obj2
, X
obj1
)← finalFlow(X
a
, X
att1
, X
obj2
, X
obj1,
X
t
), ¬ACL(X
obj1
, X
obj2
, r)
(20)
236

8 Related Work
Secure information flow models have been studied by several researchers. Most of
these develop richer flow control models. For example, Samarati et al. develops a
DAC based model that prevents information leakage by Trojans [16]. Bertino et al.
[3] present a logic based workflow model. Although important, these papers do not
address flow policies for software design life cycle models.
Myers [12] presents JFlow, an extension to Java that adds statically checkable flow
constraints. However, JFlow can be used during the implementation phase while
FlowUML is to be used during the requirements, design and analysis phases of the
software development life cycle. . Lodderstedt et al. [18] present a language to anno-
tate UML-based models representing authorization constraints. Jurjens [19] proposes
to extend UML, allowing to represent security information within UML diagrams.
To the best of our knowledge, none of the existing works address the design and
verification processes supported by FlowUML. However, some published work
shares some of FlowUML’s objectives. In the area of logic-based checking of policy
violations during the requirement engineering, Alghathbar et al. [1] developed
AuthUML, a logic program based framework for that analyzing access control re-
quirements during the requirements engineering phase to ensure consistency, com-
pleteness and conflict-freedom. AuthUML is the access control analog of FlowUML.
FlexFlow of Chen et al. [6] is a logic-based flexible flow control framework to
specify data-flow, workflow and transaction systems. Although FlowUML and Flex-
Flow analyze and prevent unauthorized flows, FlowUML is different from FlexFlow
in many aspects such as FlexFlow is an abstract model while FlowUML is tightly
integrated with UML diagrams.
9 Conclusions
FlowUML is a logic programming based framework to specify and validate informa-
tion flow policies in UML based designs at the early phases of the software develop-
ment life cycle. We demonstrated the expressiveness of FlowUML by validating
existing example policies.
References
1. K. Alghathbar, D. Wijesekera. “authUML: A Three-phased framework to analyze access
control specifications in Use Cases”. In proc. of the Workshop on Formal Methods in Secu-
rity Engineering (FMSE), Washington, DC. October 2003. ACM Press.
2. D. Bell and L. LaPadula. “Secure computer system: United exposition and Multics interpre-
tation”. Technical Report, ESD-TR-75-306, MITRE Corp. MTR-2997. Bedford, MA, 1975.
3. E. Bertino and V. Atluri. “The specification and enforcement of authorization constraints in
workflow management”. ACM transactions on Information Systems Security, February
1999.
4. B. Boehm. Software engineering economics. Englewood Cliffs, NJ: Prentice-Hall. (1981)
237

5. G. Booch, J. Rumbaugh, and I. Jacobson. The Unified Modeling Language User Guide.
Addison-Wesley, Reading, MA, 1999.
6. S.Chen, D. Wijesekera, S. Jajodia. “FlexFlow: A Flexible Flow Control Policy Specifica-
tion Framework”. In proceedings of the 17th Annual IFIP WG 11.3 Working Conference
on Database and Applications Security. Estes Park, Colorado. August 2003.
7. L. Chung, B. Nixon, E. Yu, J. Mylopoulos. Non-Functional Requirements in Software
Engineering. Kluwer Academic Publishers (2000).
8. P. T. Devanbu and S. Stubblebine. “Software engineering for security:A roadmap”. In A.
Finkelstein, editor, The Future of Software Engineering. ACM Press, 2000.
9. D. Gabbay and A. Hunter, “Making Inconsistency Respectable: A Logical Framework for
Inconsistency in Reasoning, Phase1 - A Position Paper”, Proceedings of Fundamentals of
Artificial Intelligence Research '91, 19-32, Springer-Verlag.
10. D. Gabbay and A. Hunter, “Making Inconsistency Respectable: A Logical Framework for
Inconsistency in Reasoning, Phase2”, In Symbolic and Quantitative Approaches to Reason-
ing and Uncertainty, 129-136, LNCS, Springer-Verlag, 1992.
11. M. Gelfond, V. Lifschitz. 1988. “The stable model semantics for logic programming”. In
Proceedings, 5th International Conference and Symposium on Logic Programming. Seat-
tle, Wash. pp. 1070–1080.
12. A. Myers. “JFlow: Practical mostly-static information flow control”. In Proc. 26th ACM
Symp. on Principles of Programming Languages (POPL), pages 228--241, San Antonio,
TX, January 1999.
13. B. Nuseibeh, S. Easterbrook and A. Russo, “Making Respectable in Software Develop-
ment”, Journal of Systems and Software, 56(11), November 2001, Elsevier Science Pub-
lishers
14. B. Nuseibeh and S. Easterbrook. “Requirements engineering: A roadmap”. In A. Finkel-
stein, editor, The Future of Software Engineering. ACM Press, 2000.
15. Rational Rose. http://www.rational.com.
16. P. Samarati, E. Bertino, A. Ciampichetti, and S. Jajodia. “Information flow control in ob-
ject-oriented systems. IEEE Transactions on Knowledge and Data Engineering”, 9(4):524–
538, July-Aug. 1997.
17. The Unified Modeling Language version 1.5. http://www.omg.org/uml/. Accessed in Sep-
tember 2003.
18. T. Lodderstedt, D. Basin, and J. Doser. “SecureUML: A UML-Based Modeling Language
for Model-Driven Security,” in
Proceedings of the 5th International Conference on The
Unified Modeling Language
, pp. 426-441, 2002.
19. J. Jurjens. “UMLsec: Extending UML for Secure Systems Development,” in
Proceedings of
the 5th International Conference on the Unified Modeling Language, pp. 412-425, 2002.
238