speci cation and documentation techniques: graphical notationsse3ra3/2016/ln14-2016.pdf · 2016. 9....

Previous LectureGraphical/diagrammatic notations

Specification and Documentation Techniques:Graphical Notations

CS/SE 3RA3

Ryszard Janicki

Department of Computing and Software, McMaster University, Hamilton,Ontario, Canada

Ryszard Janicki Graphical Notations 1/16


Fit criteria

FIT: A solution completely satisfies the requirement

The requirement itself must be measurable

Length of rope: “suitable size” ⇐ WRONG

Length of rope: “2 cm in diameter, 2 m long” ⇐ RIGHT

Fit criterion: the measurement of the requirement

Axiom, goal: any requirement can be measured ⇐ Is thisrealistic?

Fit criteria for nonfunctional requirements: rationale, scale

Fit criteria for functional requirements: how we will know thatthe product successfully carried out its function



Entity-relationship diagramsUML type entity-relationship diagrams

Use of diagrammatic notations

Conceptual structures: entity-relationship diagrams

Information flows: context diagrams and dataflowdiagrams

System behaviors: state machine diagrams

System operations: use case diagrams

Modeling scenarios: activity diagrams

Everything: UML





They model data

Entities → boxes → physical items (including people) oraggregations of data items

Relationship → diamonds → logical and numerical relationsbetween pairs of entities

Cardinality/multiplicity of relationship: 1− 1, 1−m, m − 1,m −m

one-to-one (every chemical container is tracked by a singlecontainer history)one-to-many (one requester → many requesters)many-to-many (every vendor catalog contains many chemicals,and some chemicals appear in multiple vendor catalogs)

Sometimes m can be replaced by a concrete number as forexample 4 or 9, etc.


Entity-relationship diagram: an example




EE--R DiagramsR Diagrams

Rectangles represent entity sets.ec a g es ep ese e y se s

Diamonds represent relationship sets.

Lines link attributes to entity sets and entity sets to relationship sets.

Ellipses represent attributes

Double ellipses represent multivalued attributes.

Dashed ellipses denote derived attributes Dashed ellipses denote derived attributes.

Underline indicates primary key attributes




Attributes

EE--R Diagram With Composite, Multivalued, and R Diagram With Composite, Multivalued, and Derived AttributesDerived Attributese ed bu ese ed bu es




Roles

RolesRoles

Entity sets of a relationship need not be distinct

The labels “manager” and “worker” are called roles; they specify how employee entities interact via the works-for relationship set.

Roles are indicated in E-R diagrams by labeling the lines that connect diamonds to rectangles.

Role labels are optional, and are used to clarify semantics of the p yrelationship




Cardinality

Cardinality ConstraintsCardinality Constraints

We express cardinality constraints by drawing either a directed line (), signifying “one,” or an undirected line (—), signifying “many,” between the relationship set and the entity set.

E.g.: One-to-one relationship:

A customer is associated with at most one loan via the relationship borrower

A loan is associated with at most one customer via borrower




One-to-many

OneOne--ToTo--Many RelationshipMany Relationship

In the one-to-many relationship a loan is associated with at most one customer via borrower, a customer is associated with several (including 0) loans via borrower( g )




Many-to-one

ManyMany--ToTo--One RelationshipsOne Relationships

In a many-to-one relationship a loan is associated with several (i l di 0) t i b t i i t d (including 0) customers via borrower, a customer is associated with at most one loan via borrower




Many-to-many

ManyMany--ToTo--Many RelationshipMany Relationship

A customer is associated with several (possibly 0) loans A customer is associated with several (possibly 0) loans via borrower

A loan is associated with several (possibly 0) customers i bvia borrower




Alternative notation for cardinality

Alternative Notation for Cardinality Alternative Notation for Cardinality LimitsLimits

Cardinality limits can also express participation constraints




UML version (influenced by UML class diagrams)

Entity-relationship diagram: example

I it ti M tiInvitesinvitedTo

entitybinary relationshiprolespecialization

Participant 1..* 0..*Invitation Meeting

DateLocation Name

Address

InvitesinvitedTo

constraintsFor constraintsFrom 1 *

attribute

Constraints

Address Email

excludedDatesf dD tI t t

Requesting

dateRangewithWhom

1..*

Initiator1..1

preferredDatesImportantParticipant

Preferences Email

NormalParticipant

…

withWhom

attributes ofrelationship

A meeting invites at least 1 up toan arbitrary number of participants




UML version vs standard version


Example (Elevator: Data and Their Structure)

Q3[10]

Marking Scheme：

1) The diagram should contain as many as entities and relationships described in

your Q1.

2) Properties of entities

3) Cardinality constraints (such as 0...m, 1...m, etc.) would be another evaluation of

your ER diagram.

12

speci cation and documentation techniques: graphical notationsse3ra3/2016/ln14-2016.pdf · 2016. 9....

Documents