Software Engineering

Unit-3(2)

Unit-3(2) Notes

Class-Based Modeling, Requirements Modeling Strategies, Flow-Oriented Modeling, Creating a Behavioral Model, Patterns for Requirements Modelling, Requirements Modeling for WebApps.

TEXTBOOK- I: Chapters 6, 7.

3.2.1 Class based modeling:

* CRC = Class-Responsibility-Collaborator is a part of Class based modeling.

* Class-based modeling represents the objects that the system will manipulate, the operations (also called methods or services) that will be applied to the objects to effect the manipulation

* Identifying Analysis Classes: External entities (e.g., other systems, devices, people), Things (e.g., reports, displays, letters, signals), Occurrences or events, Roles (e.g., manager, engineer, salesperson), Organizational units (e.g., division, group, team), Places(e.g., manufacturing floor or loading dock), Structures (e.g., sensors, four-wheeled vehicles, or computers).

* Specifying Attributes: Attributes = define a class = clarify what is meant by the class in the context of the problem space.

Fig: CRC Index Card

* Defining Operations: Manipulate data, perform a computation, inquire about the state of an object, monitor an object for the occurrence of a controlling event.

* Class-Responsibility-Collaborator (CRC) Modeling:

Classes: The taxonomy of class types can be extended by considering the following categories:

1. Entity classes, also called model or business classes, are extracted directly from the statement of the problem. These classes typically represent things that are to be stored in a database and persist throughout the duration of the application (unless they are specifically deleted).

2. Boundary classes are used to create the interface (e.g., interactive screen orprinted reports) that the user sees and interacts with as the software is used. Boundary classes are designed with the responsibility of managing the way entity objects are represented to users.

3 .Controller classes manage a “unit of work” from start to finish. That is, controller classes can be designed to manage

(i) the creation or update of entity objects,

(ii) the instantiation of boundary objects as they obtain information from entity objects,

(iii) complex communication between sets of objects,

(iv) validation of data communicated between objects or between the user and the application. In general, controller classes are not considered until the design activity has begun.

Responsibilities: Five guidelines for allocating responsibilities to classes:

· System intelligence should be distributed across classes

· Each responsibility should be stated as generally as possible.

· Information and the behavior related to it should reside within the same class.

· Information about one thing should be localized with a single class, not distributed across multiple classes.

· Responsibilities should be shared among related classes, when appropriate.

Collaborations:

· Collaborations represent requests from a client to a server in fulfillment of a client responsibility. Collaboration is the embodiment of the contract between the client and the server.

· An object collaborates with another object if, to fulfill a responsibility, it needs to send the other object any messages. A single collaboration flows in one direction—representing a request from the client to the server. From the client’s point of view, each of its collaborations is associated with a particular responsibility implemented by the server.

· In all cases, the collaborator class name is recorded on the CRC model index card next to the responsibility that has spawned the collaboration.

· Therefore, the index card contains a list of responsibilities and the corresponding collaborations that enable the responsibilities to be fulfilled.

· To help in the identification of collaborators, you can examine three different generic relationships between classes:

o the is-part-of relationship

o the has-knowledge-of relationship

o the depends-upon relationship.

All classes that are part of an aggregate class are connected to the aggregate class via an is-part-of relationship.

(3.2.2) Requirements Modeling Strategies:

Structured Analysis: focuses on data objects, transformation as they flow through the system.

Object-oriented analysis: focuses on definition of classes and their collaboration.

(3.2.3)Flow-oriented Modeling:

DFD = Data Flow Diagram --> Level 0, Level 1, Level 2

Terminology of DFD: bubble, primary input and primary output, label arrows and bubbles, refine one bubble at a time.

Fig: Level_0 = single bubble and relations

Fig: Level_1 = basic bubble split into two or more detailed blocks

Fig: Level_2 = each bubble must be the simplest function

(3.2.4) Creating a behavioral model:

1. identify events

2. state representations

3. sequence diagrams

4. build a state diagram for the system

5. review the model to verify accuracy and consistency.

Behv Model1: State diagram, Behv Model2: Sequence diagram

Fig: State diagram

Fig: Sequence diagram

(3.2.5) Patterns for Requirements Modeling:

* Software pattern = mech(cap domain knowledge); This can be reapplied to a new problem.

* domain knowledge applied to a problem in same domain

* domain knowledge captured by a pattern, applied to a completely different application domain.

So, Behavioral models = (i) State Diagram (ii) Sequence diagram in UML

(a) Discovering Analysis Patterns=> The requirements model is comprised of a wide variety of elements: scenario-based (use cases), data-oriented (the data model), class-based, flow-oriented, and behavioral.

(b) Requirements Pattern Example: Actuator-Sensor

Pattern Name: Actuator-Sensor

Intent: Specify various kinds of sensors and actuators in an embedded system.

Motivation: Embedded systems usually have various kinds of sensors and actuators.

Constraints: Each passive sensor, each active sensor, each actuator duty/ duties are to be mentioned. duty = function/ task

Applicability: Useful in any system in which multiple sensors and actuators are present.

Structure:

Behavior:

Participants:

• PassiveSensor abstract: Defines an interface for passive sensors.

• PassiveBooleanSensor: Defines passive Boolean sensors.

• PassiveIntegerSensor: Defines passive integer sensors.

• PassiveRealSensor: Defines passive real sensors.

• ActiveSensor abstract: Defines an interface for active sensors.

• ActiveBooleanSensor: Defines active Boolean sensors.

• ActiveIntegerSensor: Defines active integer sensors.

• ActiveRealSensor: Defines active real sensors.

• Actuator abstract: Defines an interface for actuators.

• BooleanActuator: Defines Boolean actuators.

• IntegerActuator: Defines integer actuators.

• RealActuator: Defines real actuators.

• ComputingComponent: The central part of the controller; it gets the data from the sensors and computes the required response for the actuators.

• ActiveComplexSensor: Complex active sensors have the basic functionality of the abstract ActiveSensor class, but additional, more elaborate, methods and attributes need to be specified.

• PassiveComplexSensor: Complex passive sensors have the basic functionality of the abstract PassiveSensor class, but additional, more elaborate, methods and attributes need to be specified.

• ComplexActuator: Complex actuators also have the base functionality of the abstract Actuator class, but additional, more elaborate methods and attributes need to be specified.

Collaborations: objects and classes interact with one another and how each carries out its responsibilities.

ComputingComponent <----->---> PassiveSensor

ComputingComponent <---<-----> ActiveSensor (They send a life tick at least once during a specified time frame)

ComputingComponent <-------->-----> actuator

ComputingComponent <-----query, set the operation state of the sensors and actuators

Ex: operation state =zero, then the error is sent to the FaultHandler (a class that contains methods for handling error messages) like recovery mechanism or a backup device. If recovery fails then last known value for the sensor or the default value used.

• The ActiveSensors offer methods to add or remove the addresses or address ranges of the components that want to receive the messages in case of a value change.

Consequences:

* Sensor and actuator classes have a common interface.

* Class decides whether or not to accept the message.

Ex: if a value of an actuator is set above a maximum value, then the actuator class may not accept the message, or it might use a default maximum value.

* The complexity of the system is potentially reduced because of the uniformity of interfaces for actuators and sensors.

(3.2.6) Requirements Modeling for WebApps:

1. How much analysis enough? i.e., number of stake-holders, degree to which stakeholders worked, WebApp (size, its success effecting Org). '

2. Requirements modeling input: PASSWORD=maximum and minimum length, VIDEO= Resolution, Alarm, Pan and Zoom, GEO-Tag,

Natural language description, rough outlines, sketches, and other formal representations.

3. Requirements modeling output:

Content model: (text, graphics (image, video, audio....))

Interaction model: manner in which users can interact with the WebApp

Functional model: operations that wll be applied to WebApp

Navigation model: navigation strategy of WebApp

Configuration model: environment in which WebApp resides

Google Sites

Report abuse