Classes Mindmap
Classes Mindmap
Definition: Definition: External device ↔ Device I/O Boundary Object. Systems/Devices OUTSIDE your system that Coordinate overall system behavior and manage
Persistent, data-intensive objects that store Interface objects that connect the system to External timer ↔ Software Timer Class. communicate with your system through boundary object interactions.
and provide controlled access to information. the external environment. classes
Usually stored on the secondary storage. (Boundary classes are WITHIN your system An «external system» class is needed when the
that enables it to communicate with external
ASSOCIATIONS: system interfaces to other systems, to either send
Features: classes) Inputs to, Outputs to, Communicates with, data or receive data.
Often persistent, meaning data remains intact Interacts with For a real-time embedded system, it is desirable
after shutdown. to identify low-level external classes that
May access/update other entity objects for correspond to the physical I/O devices to which Business Logic Service Logic
encapsulated information. the software system must interface.
Common in both information systems and
real-time/distributed systems. Encapsulate (hide) business rules. An object that provides a service for other objects
Separate the business rules from the entity data Usually provided in service-oriented architectures
Examples: that they operate on, because the business rules and applications
Banking system: Accounts, Transactions. can change independently. Client objects can request a service from the
Sensor Monitoring: SensorData class Coordinator Objects Timer Objects It resembles a coordinator object. However, unlike service object, which the service object will
(Attributes: Sensor Name, Value, Limits, Alarm User Interaction Device I/O a coordinator object, whose main responsibility is respond to.
Status). Input Device External System to supervise other objects, the prime A service object never initiates a request;
Manage sequencing of related objects during a Triggered by external timers to initiate periodic responsibility of a business logic object is to however, in response to a service request it might
Interact with human users via standard I/O Provide software interfaces to hardware I/O use case. activities or events. encapsulate and execute the business rules. seek the assistance of other service objects.
devices. devices. Not state-dependent; rely solely on input Example: A ReportTimer object activates based
A device that only provides input to the system An external system that communicates with our
Standard: Keypad, display, mouse, ..etc. Handle non-standard application-specific devices messages. on external clock input.
(if the device is nonstandard [Application like sensors and actuators.
For Example: a sensor system.
specific] we use a DEVICE I/O boundary class Standard devices are usually managed by the OS.
Could range from simple command-line interfaces Algorithm Logic
(CLIs) to complex Graphical User interfaces
(GUIs) State-Dependent Control Objects
Composite objects may handle multiple user Encapsulates an algorithm used in the problem
interactions. External User domain.
Output Device More prevalent in real-time, scientific, and
Behavior varies depending on current state.
engineering domains.
Defined using finite state machines (FSM).
Proxy Used when there is a substantial algorithm used
A device that only receives output from the An External User that Communicates with our Inputs trigger state transitions; outputs depend on
in the problem domain that can change
system system. input and current state.
independently of the other objects
For Example: an actuator It resembles a coordinator object. Unlike a
Interface with external systems, abstracting coordinator object, however, whose main
communication details. responsibility is to supervise other objects, the
Example: Pick-and-place robot proxy handles prime responsibility of an algorithm object is to
commands sent to external systems. encapsulate and execute the algorithm.
STATIC MODELLING
Information-intensive systems will have several They have physical characteristics (tangible/ Why? .. It is very important to understand the
entity classes, which is why static modeling is so can be seen and touched). scope of a computer system – what is to be
vital for these systems. They include physical devices (which are often included inside the system and what is to be left
Conceptual data-intensive classes that are often part of the problem domain in embedded outside the system.
persistent (long-living and usually saved on applications in which there are several physical
secondary storage) but in real-time systems, devices such as sensors & actuators), users, Context modelling explicitly identifies what is
entity objects are often stored in main memory. external systems, and timers. inside the system and what is outside. Context
They are particularly prevalent in information The physical entities represent classes in the modeling can be done at the total system
systems. problem domain for which we need conceptual (hardware and software) level or at the software
Store data and provide limited access to that representation in the software system. system (software only) level.
data via the operations they provide (ex: setters, System Context Diagram; A diagram that
getters) explicitly shows the border between the
An entity object might need to access another system (hardware and software), which is
entity object to update the information it treated as a black box, and the external
encapsulates. environment.
During static modelling of the problem domain, Software System Context Diagram; A
the COMET emphasis is on 1) entity classes that diagram that explicitly shows the border
are defined in the problem, 2) their attributes, between the software system, also treated as
and 3) their relationships. a black box, and the external environment
Specifying operations is deferred until design (which now includes the hardware).
modelling. In class structuring, the COMET method
advocates categorizing classes in order to group
together classes with similar characteristics.
In UML, stereotypes are used to distinguish
among the various kinds of classes.