Landing : Athabascau University

COMP 361 - Week 5 Notes

  • Public
By Xing Li May 13, 2019 - 8:27pm

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


These comments are moderated. Your comment will not be visible unless accepted by the content owner.

Only simple HTML formatting is allowed and any hyperlinks will be stripped away. If you need to include a URL then please simply type it so that users can copy and paste it if needed.