(net time: 190 min)

Section 3 Domain Modeling

functional requirements: use case + problem domain of system users

problem domain: the specific area (or domain) of the user’s business need (or problem) that is within the scope of the new system

things: domain class in UML and data entity in traditional database analysis?

                brainstorming technique: user/use cases->things with information->scan all types->all users/stakeholders->merge distinct list

noun technique (similar to things, more programmable way) : identify all nouns conceptually->identify from documents->refine->list of include/exclude/research->review

attributes: descriptive

identifier/key: attribute with 1-to-1 relation

compound attribute: concatenation

association: relationship

                unary/binary/n-ary: number of entities involved

multiplicity: cardinality; constraints 0..n = minimum 0 maximum more

entity relation diagram (ERD): data entity + attributes + relationship (p99, F4-7) -> semantic net

UML domain model class diagram: class+ attributes+ association; (p102, F4-13)

association, generalization/specialization(super/sub, abstract=italics/concrete), whole/part(aggregation, composition=cannot split+ diamond filled in)

Section 4 More models

Use case

brief/fully developed use case description: use case name/several scenarios/related use cases, actors/stakeholders, trigger/precondition/postcondition/exception, brief description/flow of activities

UML activity diagram

UML system sequence diagram: sequence of message between actor and system

                =stick figure of actor+ box of object :system + dashed line of lifeline + arrow of message

                =identify input->message notation->add condition->add output

                loop frame or *[true/false condition], service := verb-noun message ( parameters or input data)

                opt frame: if

                alt frame: if else

domain class

                UML state machine diagram

                                object state: condition when it satisfies criteria, performs action or waits for event (describing), oval-rectangle

                                transition: short and can’t be interrupted, arrow, transition-name (parameters, ...) [guard-condition] / action-expression – all optional

                                path: sequential set of connected states and transition

                                composite state: containing path

true/false vs guard: sending side vs receiving side

Relationship: (P143 F5-20)

Q21: When considering requirements, states and state transitions are important for understanding which other diagram?

Not 100% sure: may be SSD?