Appreciation of Different Paradigms in Software Engineering and Using Microsoft Visio and Visual Paradigm

Registration Numbers 2000330056 2000330082 2000330096 2000330107 2000330104 2000330088 Course Code: ECS 331

Course Instructor Mr. C M M Wahid Dept. of CSE SUST

1

Appreciation of different paradigms in Software Engineering and using Microsoft Vision and Visual Paradigm Introduction Developing software is a tremendous job with a greater level of complexity. It requires to gather and analysis various information, determine a roadmap how the development process proceed, developing some models describing various features and services of the system at different level of abstraction, analyze the models, refining and gradually developing a working version. Each of these jobs has a specific technical synonym. The goal of this assignment is to become familiar with the uses of these jargons as well as different development and analysis tools. We represent here two systems. One of them is Safe Home Security System and the other is Conveyer Line Sorting System. The tools used are Microsoft Visio and Visual Paradigm. The models and diagrams are presented below. System Context Diagram

The SCD for CLSS is shown in this figure. The diagram is divided into five major segments. The top segment represents user interface processing, and the left and right segments depict input and output processing, respectively. The central segment contains process and control functions, and the bottom segment focuses on maintenance and selftests. Each box shown in this figure represents an external entity- that is, a producer or customer of system information. For example the barcode reader produces information 2

that is input to the CLSS system. The symbol for the entire system is a rectangle with rounded concerns. Hence CLSS is represented in the processing and control region at the center of the SCD. The leveled arrow shown in the SCD represents information (data & control) as it moves from the external environment into the CLSS system. The external entity bar-code reader produces input information that is leveled bar code. In essence, the SCD places any system into the context of its external environment. The Analysis Model as a Bridge between the System Description and the Design Model

The analysis model must achieve three objectives: (1) to describe what the customer requires, (2) to establish a basis for the creation of a software design, and (3) to define a set of requirements that can be validated once the software is built. The analysis model bridges the gap between a system-level description that describes overall system functionality as it is achieved by applying software, hardware, data, human and other system elements and a software design that describes the softwares application architecture, user interface and component level structure.

Building an SFD Hierarchy

The initial system flow diagram becomes the top node of a hierarchy of SFDs. Each rounded rectangle in the original SFD can be expanded into another architecture template dedicated solely to it. This process is illustrated schematically in the figure. Each of the SFDs for the system can be used as a starting point for subsequent engineering steps for the subsystem that has been described. Deployment Diagram for CLSS Hardware

In this figure, CLSS hardware has been modeled at the system level using deployment diagram. Each 3-D box depicts a hardware element that is part of the physical architecture of the system. In some cases, hardware elements will have to be designed and built as a part of the project. In many cases, however, hardware elements can be acquired off-the-shelf. The challenge for the engineering team is to properly interface the hardware elements. It should be noticed that the tree structure doesnt mean that a macro entity is subdivided in a lower level; rather each system is connected with its subsystems. Input and Output for Domain Analysis

The role of domain analysis is to discover and define reusable analysis pattern, analysis classes and related information that may be used by many people working on similar but not necessarily the same applications. This figure illustrates key inputs and outputs for

the domain analysis process. Sources of domain knowledge are surveyed in an attempt to identify objects that can be reused across the domain. Elements of the Analysis Model

Analysis modeling leads to the derivation of each of the modeling elements shown in figure 8.3.However, the specific content of each element (i.e., the diagrams that are used to construct the element and the model) may differ from project to project. Context-level DFD for the SafeHome Security Function

A data flow diagram actually represents how different data objects in a software system are created, signified, processed and preceded (output). The rectangles show the source and destination of data. The precisely labeled arrows tell actually what types of data go by. The bubbles are the processes which processes the data. In respect of abstraction, a DFD can be drawn at different levels. The zero labels indicate the total system with single bubble. As the label increases, the bubble(s) are detailed into more bubbles describing the processes that deal with data. Two higher level DFD is given below.

Level 1 DFD for SafeHome Security Function

Level 2 DFD That Refines the Monitor Sensors Process

State Diagram for SafeHome Security Function

This figure depicts a preliminary state diagram for the level 1 control flow model for safe home. This diagram indicates how the system responds to events as it traverses the four states defined at this level. State Diagram for the Control-panel Class

This figure illustrates a state diagram for the Control-panel class in the SafeHome security function. Each arrow show here represents a transition from one active state of a class to another. The labels shown for each arrow represent the event that triggers the transition.

Sequence Diagram for the SafeHome Security Function

This figure illustrates a partial sequence diagram for the SafeHome security function. Each of the arrows represents an event and indicates how the event channels behavior between SafeHome objects. Time is measured vertically (downward), and the narrow vertical rectangles represent time spent in processing an activity. Use-case Diagram for CLSS Operator

Use-case diagrams generally describe the scenarios under which an actor acts upon the system. The ovals tell about the use cases. The human symbol is the actor. An actor may

10

be a human user, application program or some other hardware module which gives input of takes output. Some other Use-case diagrams follow here. Use-case Diagram for SafeHome Home Security Function

Preliminary Use-case Diagram for the SafeHome System

Activity Diagram for CLSS 11

This diagram represents a CLSS system.

Activity Diagrams for Eliciting Requirements

12

This diagram represents the elicitation step of requirement engineering. The first function is there conducting a meeting with the customers. Then the second step is to make lists of the required function on the basis of that meeting. Making lists of constraints is the third function. If all these functions are competed, then we should use a QFD (Quantity Flow Diagram) of the prioritized requirements. Else we can go for informally prioritized requirements. Then we should create the use-case diagram of that.

Activity Diagram for Access Camera Surveillance-Display Camera Views Function

13

This diagram represents the access camera surveillance-display camera views function for the Safe home security system. Especially this activity diagram implies the flow of activity of password checking and selecting camera view step of Safe home system. At

14

the first action it receives a password from the actor and verifies it. After receiving a valid password it provides an option to select specific camera to the actor to view. Swim lane Diagram for Access Camera Surveillance-Display Camera Views Function

The UML swim lane diagram is a useful version of the activity diagram and allows the modeler to represent the flow of activities described by the use-case and at the same time indicate which actor (if there are multiple actors involved in a specific function) or analysis class has responsibility for the action described by an activity rectangle. Responsibilities are represented as parallel segment that divide the diagram vertically, like the lanes in a swimming pool. The homeowner, Interface, and Camera classes have direct or indirect responsibilities in the context of the activity diagram represented here. The previous activity diagram of access camera surveillance-display camera views function for the Safe home security system is rearranged here so that activities associated with a particular analysis class fall inside the swim lane of that class.

UML Class Diagram for Box Class

15

For the CLSS system, candidate classes may be Box, ConveyorLine, BarCodeReader, ShuntController, OperatorRequest etc. Among them A UML Class Diagram for the Box is shown in above figure. Class Diagram for the System Class

16

For the SafeHome Security System at first we identified some potential classes. Among them we selected some candidate classes based on six selection characteristics. Among them System Class Diagram is shown in above figure. Class Diagram for FloorPlan

This is another class of the SafeHome Security System. In this diagram we also showed that how FloorPlan class is associated with two other classes Wall and Camera and also Wall class is associated with WallSegment, Window and Door classes. The texts beside the arrows indicated how are the classes are associated with each other.

17

A CRC Model Index Card

Class-Relationship-Modeling (CRC) provides a simple means for identifying & organizing the classes that are relevant to system or product requirements in reality the CRC model may make use of actual or virtual index cards. In CRC model responsibilities are the attributes & operation that are relevant for the class. Collaborators are those classes that are require to provide are class with the information needed to complete a responsibility. A simple CRC index card for the Floor Plan class is lustrated in above figure. The list of responsibilities show on the CRC card is preliminary and subject to additions or modifications. The class wall and camera are noted next to responsibility that will require the collaboration. Multiplicity

18

We discussed earlier that by the Class Diagram, we can show the association between classes. With the above figure we also indicate the Multiplicity between the classes i.e. how many classes can one class contains. For example in the above figure one wall contains one or more WallSegment classes but a Wall class contains zero or more Window classes. ********************************

19