week 4 summary
gergo.pinter@uni-corvinus.hu
unified modeling language
- UML 2.0 released in 2005
- latest revision in 2017
- ISO/IEC 19501 standard
- designed to be a complete language of software modelling
- UML 2 has 14 diagrams in two categories: structure and behavior
most software developer do not use UML (in a formal way), but hand drawn sketches which often include UML elements [1]
use case diagram
- depicts the interactions between system users (actors) and the system itself
- used to specify the functional requirements
- provides a high-level view
- helping stakeholders to understand the system’s functionality
- it’s purpose is similar to the user story
class diagram
- describes the structure of a system by its classes
- their attributes, methods, and the relationships among them
- main building block of the object-oriented modeling
object diagram
- special case of a class diagram
- graphical representation of the objects and their
relationships
at a specific moment in time - provides a snapshot of the system’s structure
- does not show anything architecturally different to class diagram
component diagram
- depicts the component structure and relations
- highlighting the interfaces
state diagram
- a visual representation of the states a system or an object can be in also the transitions between those states
- models the dynamic behavior of the system, capturing how it responds to different events over time
- shows the system’s life cycle
activity diagram
- graphical representations of workflows
- similar to flowcharts
- but uses UML notation
- and can visualize parallel processing
- has more features
sequence diagram
- shows process interactions arranged in time sequence
- depicts the processes and objects involved and the sequence of messages exchanged
- instead of the inner parts of a system, message exchange between software systems can be depicted
what is the issue with UML?
- closely connected with OOP
- propagates object-oriented modelling
- however the design should not consider the implementation
level 1: system context diagram
- shows how the software fits into the world
- who use it
- what other software does it interacts
- high level diagram
- technologies, protocols and other low-level details are not important
- similar to use case diagram
- understandable for non-technical people
other possible users:
administrator, course planner
level 2: container diagram
- zooms into the software system
- shows the containers that make up that software system
- applications, data stores, microservices, etc.
- technology decisions are also a key part of this diagram
- what database management system to use, e.g., PostgreSQL
- what e-mail service to use, e.g., Mailchimp
- what language to use
- what UI framework to use
level 3: component diagram
- decomposition of each container to identify the major structural building blocks and their interactions
- shows how a container is made up of a number of “components”
- what these components are,
- what they are responsibilities for, and
- what also shows technology / implementation details
- roughly equivalent with the UML component diagram
level 4: code
- optional level of detail
- ideally this diagram would be automatically generated
- if you really want or need to, you can zoom into an individual
component
- but show only those attributes and methods that really needed for the storytelling
- UML class diagram can be used
