UNIT 3 SPECIFICATION OF SYSTEM COMPONENTS Flashcards
Briefly describe what systems and components are and their relationship.
A system represents an interaction context that is distinct from its environment, which, in turn, consists of other interaction contexts. A specification need not necessarily describe the planned software system in its entirety. Only certain parts of the system may be relevant, depending on the individual project.
With this in mind, complex software systems are broken down into components. Each component is an independent software unit that can be combined with other components
via agreed interfaces to create a software system. In an object-oriented system, classes are the smallest system components. Typically, multiple classes that interact to
perform very specific functions are combined to create components.
Conceptual requirements engineering defines the boundary between the system as a whole and its environment, i.e., the system context. It also determines which elements must be included in the specification, in other words, where the specification “begins” and “ends.” A component is the smallest system unit that can be specified. Software
requirements specification (SRS) specifies externally visible behavior and structures, while the component’s internal structure remains hidden. The software architect or development team decides on the component’s internal structure and implementation of the required functions.
What does a component do and what does it represent?
A component is a part of a modular system whose content remains hidden from the user. A component may, in turn, be made up of other components.
Components deliver functions via an interface. While the functionality of classes is achieved via their methods, components are addressed via interfaces. A component’s interface description clearly defines its external functionality. One component may be replaced by another, provided it implements the same interfaces.
Object orientation is a way of viewing complex systems as an interaction between cooperating objects. Within the context of industrial software systems, this perspective can also be generalized for components. One requirement of industrial information systems is that they break internal elements down into several parts (components), each of which is responsible for one very specific function, and the correlations between individual components.
Define system, component and class.
A system must comprise at least one component, while a component may contain various sub-components. Classes are the smallest possible structural elements in an object-oriented system. Larger components often operate as independent applications.
The consistent use of components is a comparatively easy way of achieving the quality goals of a software system that is:
* readily extendible,
* easier to test, and
* easier to maintain.
Because industrial information systems are so complex, they can usually only be controlled by breaking them down into individual components.
When may specification specify technical components?
Specification identifies and delimits conceptual components from other conceptual components (e.g., shopping basket, item, and customer). Depending on the nature of the project, technical components may also be specified, particularly if the internal system architecture is already known, or if it is only necessary to specify parts of the system rather than the whole system in a project.
The first step is to specify the component’s internal behavior—for example, extend the term of the contract or calculate the total.
The second step must clearly define the operations and logical structure of messages exchanged at component interfaces.
What is the UML component diagram (COD)?
It’s used to specify the components in a system, their sub-components, and the interface relationships to one another.
How is UML Component Diagram visually represented?
UML component diagrams have two main elements with different types of representation: components and interfaces.
A frame is drawn around the component diagram, and the diagram type (cod) and name are written in the top-left corner. The diagram should be named after the system being refined in the component diagram. If a component is broken down into its constituent parts, the diagram should be labeled with the name of the component.
What are the main UML Component Diagram notations and interfaces?
- Box: box with a small icon in the top right, is a component
- «component»: box with label (equivalent to icon), is a component.
- «subsystem»: box with label (equivalent to icon), component that is part of a component.
- «interface»: box with label, identified as an interface.
- «component» –> «interface»
«component» –o «interface»: component makes interface available, other components can access the functions of the component via this interface. - «component» “uses” «interface»
«component» –( «interface»: component accesses the functions offered by the interface. - «component» –(o– «component»
interface : two components are linked via the interface. - «component» with ports: two ports, XML and GUI, modeled as boxes on the boundaries of the component. Individual interfaces are assigned to specific ports.
UML Component Diagrams describe operations and data objects. True or false?
False. Because the component diagram is a structural diagram, modeling focuses on the internal layout and elements of a system. When modeling functional components, their inter-relationships are conceptual dependencies that would exist even without the support of information technology (IT) systems. For example, specifying technical components allows software architects to define the system’s actual components and their interfaces.
Operations and actual data objects are not usually represented in component diagrams.
How can the behavior of an individual component be modeled in UML?
Just as with complete systems, the behavior of an individual component can also be modeled in a UML Use Case Diagram (UCD). Here, the system boundary represents the component boundary. As with the use case representation of systems, use case diagrams for components indicate the required user interfaces, as well as the technical system interfaces.
The Activity Diagram (ACD) allows the component’s internal operations to be specified in greater detail, generally using the same notation elements as conceptual requirements engineering. Partitions (“swimlanes”) are used to specify and denote responsibility for functions and functional decision-making. Using partitions allows you to define precisely which actor is specifically responsible for which function. The specific requirements placed on interfaces are derived from these responsibilities. Decision-making responsibilities can also be modeled in the activity diagram (ACD) with partitions.
How can one Model with Business Rules?
A business rule is a statement that defines or constrains a functional aspect. Business rules can be used to give assurances regarding the structure of business objects and influence the behavior of business processes. As well as structural requirements (e.g., “A contract must always be assigned to a policyholder”), business rules can be used to specify operational requirements (e.g., “Damages in excess of €500,000 must always be assessed by two administrators”). In practice, business rules are specified in text form.
Operational business rules influence the control flow of business processes. The “Inventory management” component procedure contains two decisions, at which point a rule is used to determine what happens next. As well as controlling operations, business rules are used to control how business objects are handled. Business rules must have a context, one or more conditions, and one or more actions that are executed depending on the condition being met.
Typical elements may be:
* Context: Link to a function or situation
* Condition (IF): In which circumstances can changes be made to
business objects?
* Action(s) (THEN/ELSE): Which changes must be implemented?
It is vital to ensure the completeness and consistency of business rules, particularly when business logic is responsible for evaluating business rules and implementing actions.
What are the characteristics of the modeling with business rules?
- Completeness: A business rule is complete when it covers every possible combination of the values in its conditions and provides a corresponding action for each condition. With complex sets of rules, there may be very large numbers of possible combinations.
- Consistency: Evaluating the set of rules at a given point in time must always produce precisely one outcome. In other words, precisely one action or group of actions must always be defined. The decision in favor of one particular action from the group of business rules must always be unequivocal. Exhaustive consistency checks can be very time-consuming, particularly if there are large numbers of rules. For this reason, it is important to carefully check the completeness and consistency of business rules as they are written.
How can one Model with Decision Tables?
Decision tables are another technique for specifying component behavior and documenting complex business rules. A decision table distinguishes between four different aspects:
1. Definition of conditions
2. Definition of actions to be implemented
3. Combination of results after evaluating conditions
4. Allocation of evaluation results to specific actions.
The table below illustrates an example of a decision table setting out all the decisions for admissible payment options in an online shop. All relevant conditions which may influence the decision are shown in the top-left. All possible and relevant combinations of rule evaluations are shown in the top-right. The bottom-left of the decision table shows all relevant actions. Finally, the bottom-right specifies the decisions themselves, i.e., which payment options are offered for which combination of evaluation results. The decision table is useful for illustrating complex correlations between large numbers of business rules and checking them for completeness.
How can one Model with State Transition Tables?
State transition tables are another option for specifying component behavior. State transition tables can be used to specify potential actions or functions depending on the current state of business objects, components, or processes. A state transition table contains three different areas:
1. List of all potential states
2. List of all potential actions
3. Deciding which actions are possible in which states
State transition tables can be derived directly from any UML state diagram. However, a state diagram cannot be prepared because the achieved target state has not yet been documented in the “admissible actions” column. Tables can show a similar state transition table where the relevant target states have been documented and could therefore be converted into a UML state diagram. The type of rendering chosen depends on the project’s current communication situation. A state diagram supports the graphical illustration of complex correlations, while a state transition table allows the user to see at a glance which actions are inadmissible in which states.
