System Level Design Languages:UML 2.0 Diagrams

By -
UML 2.0 Diagrams

A UML model consists of several elements, or their objects which are instantiated, form these elements. UML models contain three major categories of elements.

• Classifiers that describe a set of objects such as components and classes

• Events that describe a set of possible occurrences in the system such as transitions

• Behaviors that describe a set of algorithm performances such as use-cases

UML is a graphical language for modeling and consists of a set of diagrams. Each diagram includes a set of classifiers, events, and behaviors. These diagrams demonstrate the relationship between these elements. Each diagram (or set of diagrams) is suitable for a specific kind of system. For example, an activity diagram may describe the model of a system more clearly than a state diagram. Different diagrams can be used to model different aspects of a system. Another important point in modeling with UML diagrams is that they are useful for a design if the design consists of different modules (parts) which have communication between themselves. A design with only one part (or element) is not suitable to be modeled with UML.

In the following, we will briefly describe 13 UML 2.0 diagrams. These diagrams are divided into two general categories, structural and behavioral modeling diagrams. The former shows the static architecture of a model, while the latter represents the behavior of the model as it is executed over the time. Package, class, object, composite structure, component, and deployment diagrams are structural modeling diagrams. In contrast, use-case, activity, state machine, communication, sequence, timing, and interaction overview diagrams are behavioral modeling diagrams.

Use-Case Diagram

The use-case diagram shows the system requirements from a user’s point of view. It gives an overall view of the system’s functionality. This diagram consists of two elements: actors and use-cases.

An actor is an external entity for the system. It can either be a person (the user of the system, the operator, or the system administrator) or another system. In a use-case diagram, an actor can either be represented as a stick-man figure with its name above or under it, or as a rectangle with the ((actor)) stereotype as shown in Figure 86.5. Actors can have generalizations; this implies that an actor can be a special case of a more general actor.

A use-case is a simple unit of a meaningful task in a system. In our SSimBoard system, loading a circuit model into the board can be considered as a use-case. A use-case that has a name and a description can also have other use-cases inside it.

A use-case has a functional specification and usually the flow of events in textual mode. It can also have constraints which include preconditions, postconditions, and invariant conditions. Preconditions, like that of StartSimulation in Figure 86.6, are the conditions that must be true before entering

System Level Design Languages-0202

a use-case, while postconditions must be true after a use-case is executed. Invariant conditions are the conditions that must be true during all the time of a use-case execution. In our first element categorization, use-cases can be considered as behaviors. In UML, each use-case is shown by an ellipse.

The relation between an actor and a use-case or two use-cases is shown by an arrow. There are two different kinds of relationships between two use-cases:

• extend: the extend relationship occurs between two use-cases (from the extending use-case to the extended use-case). It means that the behavior of the extending use-case can be extended by the behavior of the extended use-case under specific conditions and points. These specific points are named extension points and are defined in the extended use-case. The conditions can be added to the arrows between these use-cases. An extending relationship is defined by the ((extend)) stereotype in the diagram.

• include: the include relationship occurs between two use-cases (from the including use-case to the included use-case). It means that the including use-case contains the behavior of the included use-case. The including relationship is defined by the ((include)) stereotype in the diagram.

In use-case diagrams, the use-cases are usually separated from the actor with a boundary. This is to show that the actors are out of the system while the use-cases are inside the system. Figure 86.6 shows a simple use-case diagram for SSimBoard system.

Comments

Post a Comment

Popular posts from this blog

SRAM:Decoder and Word-Line Decoding Circuit [10–13].

By -
Image
Decoder and Word-Line Decoding Circuit [10–13] Two kinds of decoders are used in SRAM: the row decoder and the column decoder. Row decoders are needed to select one row of word-lines out of a set of rows in the array. A fast decoder can be implemented by using AND/NAND and OR/NOR gates. Figure 52.7 shows the schematic diagrams of static and dynamic AND gate decoders. The static NAND-type structure is chosen due to its low power consumption, that is, only the decoded row transitions. The dynamic structure is chosen due to its speed and power improvement over conventional static NAND gates. From a low-voltage operation standpoint, a dynamic NOR-base decoding would provide lower delay times through the decoder due to the limited amount of stacking of devices. Figure 52.8 shows circuit diagrams of dynamic NOR gates. The dynamic CMOS gate as shown in Figure 52.8(a) consists of input- NMOSs whose drain nodes are precharged to a high level by a PMOS when a clock signal Φ is at a low lev...
Read more

ASIC and Custom IC Cell Information Representation:GDS2

By -
Image
GDS2 The Graphical Design System (GDS) format is a binary format developed by Calma Company in 1971 to convey IC layout information between IC designers and fabricators. Calma presented GDS2 format, the improved version of GDS, in 1978. Finally in 1991, when Cadence acquired Calma, GDS2 rights were transferred to it. In the design process, after the completion of routing and placement, design rule check (DRC) and layout versus schematic (LVS) are performed to verify the final layout. Then the verified layout, dumped in a GDS2 file, is transferred to IC foundries for fabrication. GDS2 File Format GDS2 is a standard mask layout intermediate format containing a single cell or a library of cells each of which includes a number of geometrical objects such as boundaries, paths, boxes, etc. These objects correspond to different layers of a cell where each layer is specified by a layer number and data type [3]. The file format of GDS2 is in binary. A GDS2 file contains a number of variable...
Read more

Timing Description Languages:SDF

By -
Image
SDF Standard Delay Format (SDF) is an ASCII format used to convey timing information between EDA tools. SDF was first developed by Cadence in 1990. Open Verilog International (OVI) approved SDF version 2 in 1993 and SDF version 2.1 and 3 in the following years. Improving SDF version 3 features, resulted in IEEE Standard 1497 [1]. Role of SDF in Design Process SDF can be used in different levels of a design process to annotate timing specifications, including timing data and constraints. Timing constraints are used during the forward-annotation process while timing data are applied during the back-annotation process. Forward-annotation process deals with porting timing constraints to synthesis, floorplanner, layout, and routing tools to meet the required constraints. During the design process, timing data can be back-annotated to analysis tools (including simulators, static timing analysis tools, etc.) to provide more accurate timing representations. SDF Structure An SDF f...
Read more