Heated Planet: Design Descriptions

Project 3

Myoungsoo Jung, TaeHo Kwon, Jungwoo Lee, Gangmin Park, and Seyoung Choi

April 20. 2009

Project Description

Description of logical design (classes, roles)

We have worked on codes which are using a traditional MVC model. The presentation acts as View, the simulation engine is Model and UI component is Control. We make three major changes on Project 2.

At first, we add a DB package to support persistence property. There are several classes and one interface. The PlanetSimXMLBase is interface for two PlanetSimXMLReader and PlanetSimXMLWriter classes. Two classes are used for reading and writing of XML files. The PlanetSimDB class controls overall procedures of persistence.

The second, a Presentation package handles displaying results of Simulations. In project 2, there is no tilt property. So, we added the tilt property using EarthGridDisplay class and SunDisplay class.

The third, the PerformanceMonitor package is added to support measurement in terms of TIME and MEMORY. In project 2, measurement data is only displayed on command out windows. It was so difficult to check results of simulation. So, we made this package. As PerformanceMonitor class is main class, it creates MeasurementFactory class which is an interface class for ResourcePerformance and TimePerformance. The ResourcePerformance class is used for Memory measurement and The TimePerformance class is used for Time measurement.

Additionally, the PlanetSimCalendar class is used for Date's calculation.

Which persistence medium was used?

We selected the XML file as a persistence medium. XML is easy to use and provide a good extensibility. We handle XML files using PlanetSimXMLReader, PlanetSimXMLWriter and PlanetSimFileManger classes. 

What was the format in which the data was stored, and why?

We have stored data in XML individually. Each data is stored as attributes of XML element. The stored information is eccentricity, tilt, simulated time, Data time, latitude and temperature. The reasons of this choice are extensibility and accessibility. If we want to add another type data, we can easily add to XML files without any modification of current XML's structure. Also, if we use one object type including all data types, it is difficult to extract only information of one type from object.

What was the concurrency architecture?

Previously, we have a concurrency problem between the simulation engine and the presentation part. Both parts want to access same results(cell temperature). Because of that, we make a copy of result. So, there is no currency problem in current architecture.

If there is still concurrency in architecture, the performance of program will be down to handle the concurrency.

Reused code

Which code from project 2

Our team can reuse code fragment from project 2 through the package or single class. First we reuse presentation code by using a package. Next, we reuse "Config", "Cell", "Simulator" classes, but it is need to change some attribute and methods since project 3 requirements. However, almost of them is implemented by overriding and overloading for meeting requirements of project 3. Due to this, we can design and implement for our goal without changing legacy methods from project 2 [2].

How was it adopted?

As was mentioned, we can adopt code fragment to this project through the overriding and overload issues. Moreover, we need to some glue code for adopting between new implemented class and legacy classes. In this time, we also just add interface class and extend our methods. Of course, we can provide also, that added interface classes exchange data between new and legacy classes for smooth communications. You can find this code footprint as following class diagram in next sections.

How you chose from among available saved simulation?

We should find the most of helpful available saved simulation for the given condition from user. First we look up the elapsed data on the XML format. If we can find the name in our data then we check that saved starting time is smaller than requested starting time and saved finishing time is grater then requested time. In the contrast, if we cannot find name in our XML then find the candidate the physical factor which has the maximum geographic accuracy plus temporal accuracy until all conditions are same. Finally, we can decide available saved simulation data. Actually it is available not best. We try to find nearest data from the real data by using an interpolation. Due to this, we can pick up the most useful simulation.

Design of Class diagram (with textual descriptions)

We separate our class diagrams by MVC Model design criteria. Due to this, we propose 5 figures about each diagram about Model, View, and Control. First, Model consists of major classes which are "Simulator", "Earth", "Cell" and so on.

Class diagram about Model

<Figure 1, Model related with Earth>

Actually, a "Simulator" class which composites Earth class isn't exactly separated by Control. However, Earth contains "Cell" which manages information about cell and store. Due to this, above classes are responsible for Model's role in MVC concepts.

Data Base family models

Second Model Diagram is related with Data Base. Our Data base model has one interface. This interface provides that user don't know about implementation what we use. Actually, we use XML to store related information. It has several issues. Database is exactly fast to manage any information. However, we should consider that frame works heated planet don't care about how its information is store to storage.

<Figure 2, Model related with Database>

The reason is very simple that we didn't know what is the best to manage our information when we try to design. This is very common issues of software designs since OOP follows spiral software design process [1]. We resolve this problem through DB interface classes for decoupling about storage methods. Moreover we make sure high coherent about functionality.

Control Model

<Figure 3, Control family about simulators>

Control model is little complex because amount of configuration for simulator is grater than any projects. "Config" Class includes all configuration information to manipulate simulator, database, and thread controls. Some design views can think that it is Model's roles. However, it is clear evidence that all configurations are constant value and it is used to configuring each Controller's classes.

Presentation Diagram about Earth and Grid

<Figure 4, Presentation for Earth (and panels)>

"Runnable" interface is generalized by "ThreadPresentation" Class and "Combine Presentation" Class. Two kind of concrete class supports that display information managed by "EarthPannel". Due to this, other models can communicate through the "Runnable" interface. As you known, the reason is similar with Data-base model, but in this control diagram, "Runnable" interface' purpose is explicit to support either display via distributed or serialized. We need to look at "EartGridDisplay" class since it has relation with some another minor class. But their interface is important since "TemperatueGrid" class handles some class related with temperature. And "TemperatureColorPicker" class supports association about appropriate color to "EearthGidDisplay" Class.

<Figure 5, Presentation for EarthGridDisplay (and panels)>

Logical data model for the persistent data

<Figure 6, Logical model for the persistent data>

All persistent data are stored in the XML format. The PlanetSimDBManager class acts as interface for requests related to DB. XML files are handled by PlanetSimXMLReader, PlanetSimXMLWriter and PlanetSimFileManger classes.

Deployment diagrams (Physical architecture).

<Figure 6, Deployment diagram>

Control node includes a Simulator component which depends on configurations. Control node manipulates data flows and controls each instance of components between model and presentations. For example, display manager inquires about data which should be displayed to control classes not directly contact to model classes even if model classes has appropriate data[4]. This is the role of control nodes. Finally presentation is responsible for displaying about proceeded data. This node is generated by project 2, we reuse this via packages.

Postmortem

What we worked well with the design?

We deal with two kinds of major factor. One is how can we satisfy lots of new requirements efficiently. Another is how can we reuse our codes from project 2.

First, a crucial requirement is computation problems about the temperature on the earth. The reason that computations are important is that we should consider lots of newly introduced variable when a simulator computes the temperature. As was mentioned, we can satisfy functional requirements by selecting stored simulator. Moreover, by using XML format, we can manage size of data when our simulator stores computed data and take a more efficiently methods to store data.

In the reusing legacy code from the project 2, we make an effort to preserve maintainability and solve new requirements for project 3 without hurting legacy code by using object oriented mechanisms.

What didn't work well with the design?

We think that XML format's searching complexity is better than database. The reason is that we can decide directly access to data if we make a naming convention rules when data need to be stored and loaded. We know that database's manipulation time is O(nlogn) as well searching time is O(logn). Due to this, we try to resolve managing data through the XML. However, it is not correct. Because file system use a file control block which uses linked lists internally. Therefore, it needs more time for load even if we access directly to file object through the XML format. However, our simulator's I/O performance is reasonable since we manage a little data to store.

Reference

[1] Myougsoo Jung "Object Oriented Programming using C++", Vol 268, 2005. Microsoftware

[2] Myoungsoo Jung "Overloading, Dynamic binding mechanism and correct usage", Vol 283, 2007

[3] Wikipedia, "Model-view-controller". http://en.wikipedia.org/wiki/Model-view-controller, 16, April. 2009

[4] Sun microsystems, "An overview of the MVC Pattern from JAVA"
http://java.sun.com/blueprints/patterns/MVC.html, 16, April. 2009, 2002

Prof. Spencer Rugaber

CS4330/6310 - Spring 2009

Project<2> - HEATED EARTH

Team.3

Myoungsoo, Jung|Chansoo, Kim|Woosung, Kim|Sanghyun, Kim|Eungsuk, Lee

Mar. 11^th, 2009

- DESIGN DESCRIPTION -

◈ Overview

The heated earth simulator is challenging projects in several aspects. First, we should consider some complex system for satisfying different features of modules for simulating such as the Sun and Earth. Although given assumptions simplify many other considerations, the design is still difficult to decide how to implement and optimize at the same time when systems meet the requirements and coordinate between functional requirements and non functional requirements. Our decision is that we more consider scalability and flexibility rather than speed.

- Structure, metaphor, or architecture used overall structure

Due to above considerations, we separate three kinds of functional units and then by implementing the interface in each functional units, we will effort to get a lower coupling and higher cohesion. A more detailed description will be given in UML description sections.

- Roles in the architecture

EarthSim class is in fact a main class for the simulator. It invokes Controller swing component. Controller works as a control in MVC model and receives user inputs and events. It creates both HeatedEarthSimulator and HeatedEarthPresenter. HeatedEarthSimulator inherited from Simulator class which is interface, works as a main simulator component. It is also inherited from PullPipe to pull the results. HeatedEarthPresenter, a main present component for the application, inherited from Presenter class which also is interface. To do the push, it is inherited from PushPipe. Earth class works as a model for the application. It holds all the simulations results and conditions. Actual temperatures are stored in Cell class. It also has its longitude, latitude, 4 of its neighbor cells. EarthPanel shows the results of simulation.

◈ UML class model design diagram

Our design goal is making sure of scalability and flexibility through the separation of each group into functional units. Thus, our heated earth system is divided up in group of three kinds. First, it is composed of classes associated with the simulator. We design simulator to independent modules from user interfaces, so simulator classes are similar to the model in MVC pattern. Due to this, the simulator class is implemented by interface class and there are no private and protected methods, just has only public methods by rule of MVC pattern [1]. Other functional classes are controller classes and buffer classes. In order to communicate with each other as well as meet the requirement of multiple thread usages, our system has some special structures. Two kinds of classes and feature will be described in detail on the major classes sections.

- Major classes

Major classes are as follows. Notify that we represent these functional units through packages or classes group, so you don't confuse between two terminologies.

Simulator package

Buffer package

Controller package

Representer package

First, we will descript classes associated with simulator. As you can see figure 1, the simulator class is designed by interface class. The simulator is used by demo and EarthSim classes through interface. HeatedEarthSimulator generalize the simulator interface, and it manipulates flow Earth by composition instance. You can see the control flow in the sequence diagram.

<Figure 1, classes associated with the simulator interface>

In the Next, we look at the buffer package. Associated with buffer classes consist two kinds of interfaces. It is a matter to communicate between generalized simulator and representer. By designing connector through the interface, each class doesn't consider heterogeneous types in the communication [3].

<Figure 2, classes associated with buffer interfaces>

In figure 2, we find out similar with multiple inheritances. It is very useful to communicate in the difficult situation when we consider that some classes should manipulate two kinds of properties. However, in this case, it is different multiple inheritance with C++ because we just generalize through interfaces [4].

In the control package, each class connects through only composition. In other words, every classes are "has-a" relations not "is-a" relations [2]. In fact, this structure is some complex for considering scalability since the SimResult class and EarthPanel class include result data and sharing information.

<Figure 3, relations with the control >

In the control package, each class connects through only composition. In other words, every classes are "has-a" relations not "is-a" relations [2]. In fact, this structure is some complex for considering scalability since the SimResult class and EarthPanel class include result data and sharing information. As you seen in figure 4, the representer classes are same structure with simulator classes.

<Figure 4, classes associated with the presenter interface>

◈ Interaction Diagrams

- Sequence diagrams & descriptions

First, Figure 5 represents initializing sequence flow. Demo class is most of higher classes, so he creates each simulator, presenter, and controller classes by new operations. If you need each constructor operation then you can see its information in figure 5.

<Figure 5, classes associated with the presenter interface>

We will show you how to work simulator, presenter, and controller. It divided into three kinds operation such as start, stop and pause. They are represented by figure 6 and 7. Operations is simple, all most of signal is processed by the controller. The controller sends a message start, pause, and stop to presenter first. After that the controller controls operations of simulator. Of course, all of the above mentioned behavior is achieved through the interfaces.

<Figure 6, Start control behavior between controller, presenter, and simulator>

Next, let's look at how presenter class works. As was mentioned, the presenter is controlled by EarthSim class simulator. The instance of presenter check thread and try to synchronize if take a PresentSyncRun() messages. After that presenter draw the result through EarthPanel.

<Figure 7, control behaviors between controller, presenter, and simulator>

Next, let's look at how presenter class works. As was mentioned, the presenter is controlled by EarthSim class simulator. The instance of presenter check thread and try to synchronize if take a PresentSyncRun() messages. After that presenter draw the result through EarthPanel.

<Figure 8, synchronization control follow>

In the last, let's look at the major calculation behavior through figure 9. In figure 9, HeatedEarthSimulator class takes a calculated data from the Earth interface and then the simulator push a result to PushPipe interfaces.

<Figure 9, circulating and core tasking>

◈ Architecture

We should consider architecture style since system is more complex than heated plate design project 1. In this architecture designing concepts, we have the following considerations reflect.

- Architecture style

We use Implicit Invocation for design. It is more adoptable to our system since we have a data accessed abstractly. Moreover our buffer components such as pipe interfaces are isolated from computation components [4]. Implicit Invocation style has also easy to describe that our buffer component is shared data.

- Components

As was mentioned by class and sequence diagram, components have been divided into three kinds of functional units.

Simulator components are responsible for changing state and coordinating between components. Classes associated with simulating are constituted by Earth, EarthSim, EarthHeatedSimulator, and Controller classes. For communicating with other components, it uses buffer component as interface. Controller components manage message and control follow between the representer components and simulators. It use connectors as interface and manipulate data panel which member of representer components to communicate. Presenter components responsible for display result of calculation, and user simulation iteration. It should communicate with simulator through buffer components by operating push and pull. Buffer components are generic container. Buffer components are responsible for processing a data and coordinating to transfer between other components.

<Figure 10, Implicit Invocation Box and arrow diagram>

- Connectors

Each component is connected by two kinds of connector. One is implicit invocation. Buffer components manage data isolately and abstractly although it coordinates data between presenter and simulator. Another is subprogram call such as message passing through calling the function.

- Configurations

We show that configuration in Figure 10. This architectural style satisfies changing or adding new components since data is accessed abstractly and each connector between components provide decoupling issue.

◈ Deployment diagram

Our deployment diagram is bellow. A computational part consists of simulator and buffer components and presentational part consists of other components. By dividing two device models, we can secure concurrency issues.

<Figure 11, Deployment diagram>

◈ Low-Level Design Consideration

- Algorithms

For each grid cell: 

The range of longitude is from -180° to 180° which represents from west to east. Latitude is from -90°, south to 90° north. 

To calculate the new temperature of each cell is done by the following equation:

The heat obtained from sun is proportional to the surface area of the cell, attenuation due to latitude and degree of the sun. 

Surface of the area is already calculated in construction function of Cell classCooling is done by the following equation:

Like heating, we already have value for surface area, we only need to calculate for cooling is a cool energy. 

Diffusion from neighbors, which is proportional to the length of each cell's boundary with its neighbor, can be obtained:

◈ Non-functional requirements

- Performance and Precision

In this application we've used double type to calculate and store data. It may be more accurate than using float type for temperature simulation. Form the result of project 1, double type is also slightly faster, but memory usage double type may use more.

There is a difference between how many thread application is using. Using more thread may calculate and show the simulation much faster. So separating simulation and presentation may be the best condition for this project. Moreover with the recent multi-core processors, the results will be better. But when the application was simulated in single core machine, separating the simulation and/or presentation may have little improvement.

With small size grid spacing, result will be more accurate, but the execution time will take much longer than large grid size. Also more memory will be used. Memory usage also may be differed by the size of buffer used between simulation and presentation. But using more buffer does not guarantee simulation time.

- Maintenance

As equation will not change, classes related with may be used. UI may be easily changed by just modifying presentation and panel class.

  ◈ GUI design

  ◈ Statechart Diagram

A Statechart is divided into three super-states. Main super-state is thread control, initial start start-state and activate run. This controls computation and invoke each components. And timer super-state support to thread controls.

<Figure 12, Statechart diagram>

◈ Code

Since the computation was changed from the project1, there was not much code reused for computation. Cell class which holds the temperature was able to be reused. Also as plate has been changed from simple plate into earth, UI also was not able to be reused.

◈ Reflection

We have a lot of time to design and analyze requirements of projects before implementation. However, we suffer a lot of trial and error. Moreover, our system has some change in code and algorithms. Specially, we have a major change to control thread. For using a thread, we need some glue code and survey to their connector or protocol. We try to again and again to fix bugs in using a thread. We know that process of OOP is spiral, but overhead cost to change design still there. However, we get well defined software and other component works well as design.

<References>

[1] Wikipedia, "Model-view-controller" http://en.wikipedia.org/wiki/Model-view-controller Feb, 11. 2009. Mar, 9. 2009

[2] Kim, tea kyun, "An OOP story of K professor" Beaumter. 2006

[3] Myoungsoo Jung, "More interface design": Implementation of inheritance, Microsoftware. 2007

[4] Myoungsoo Jung, "Inheritance design": from the concept to design, Microsoftware. 2007.

[5] David Garlan and Mary Shaw, "An introduction to Software Architecture", 1994 CMU Software Engineering Institute Technical Report.

OSGi: Middleware architecture

Authors: Myoung-Soo Jung, Tae-Ho Kwon, Jungwoo Lee, Gang-Min Park

Submitted Dates: Apr. 6^th , 2009

1. Name of technology

   OSGi (Open Service Gateway Initiatives)

    

2. Organizational purveyor (vendor or standards organization)

   The OSGi Alliance was founded by Ericsson, IBM, Oracle, Sun Microsystems and others in March 1999 (before incorporating as a nonprofit corporation it was called the Connected Alliance). Among its members are (as of May 2007[update]) more than 35 companies from quite different business areas, for example IONA Technologies, Ericsson, Deutsche Telekom, IBM, Makewave (formerly Gatespace Telematics), Motorola, Nokia, NTT, Oracle, ProSyst, Red Hat, Samsung Electronics, Siemens, SpringSource, and Telefonica.[1]

1. Purpose of technology: that is, what architectural/middleware role does it play in supporting distributed computing

   The OSGi is a simplified character of Open Service Gateway initiatives, It can be a kind of Middleware Framework. Home networking is a major field of recent applied technology of the OSGi. Home networking is mainly separated three fields. These are the status/monitoring of home appliance, machine's remote control, A/V and home solution combination of kitchen appliance. To access to network devices, It need the standardized networking (Ethernet, Bluetooth, wireless LAN, IEEE1394, PLC) and Universal Middleware about its devices. From this reasons, a standard came up such as UPnp, HAVi, JINI. On adopting these standards at the OSGi basic system services, the OSGI has taken the important position as a middleware framework.

   Figure 1 is the OSGi structure composed of several layers.

Figure 1 OSGi architecture

1. Application context: kinds of applications, hardware, software environment for which it is intended

   The OSGi Alliance has designated many services. Java interface is used to specify these services. And these services are separated in the two main services, called system services and protocol services.

   System services are logging, configuration admin, device access, user admin, IO connector and so on. Protocol services are , DMT Admin, UPnP Device Service, HTTP Service and so on. Because of the platforms having the small layer that allows multiple Java™ based components, The OSGi specifications are so broadly adoptable. The OSGi provides an wide security model so that components can run in a shielded environment. However, with the proper permissions, components can reuse and cooperate, unlike other Java application environments. The OSGi Framework provides an extensive array of mechanisms to make this cooperation possible and secure.

1. Protocols: what if any protocols does it provide or require?

   To support remote managements, the OSGi handles the service as bundle units. The OSGi can manage their bundle units from remote location. Its management includes control, update and change operations. Specially, to support managements, It should consider strong points of Java VM that it can upgrade without reboot even if bundle units is running. For this, the OSGi has made a standard protocol. Due to this, users such as developers just use protocol to operate the OSGi. OMA-DM, SNMP, CMSE and Telnet.SSH represent remote management standard protocol of the OSGi. If device and controller which install OSGi used to internet, local network then generally use OMA-DM (i.e., Open Mobile Alliance For Device Management). OMA-DM is new trend of standard protocol for mobile environments and it replace old protocol such like SNMP, Telnet/SSH.

   In other part, the OSGi uses a various protocol. In the physical layer, the OSGi uses a RS-232C, USB. If it supports wireless environments then use a protocol such like GSM, CDMA, IrDA for transferring. In translation layer, the OSGi uses HTTP, WAP, OBEX (Object Exchange). Moreover, the OSGi unifies communication methods by using a SyncML data transport languages.

   In the last, the OSGi manages session of HTTP/WAP as well as encoding and decoding text format of SyncML through Binary Transmission and Session Management [8]

1. Typical use: try to find an actual use of the technology. If your chosen technology has not yet been deployed, then provide a hypothetical scenario describing its intended use

   We give you actual usage in industry. Samsung Electronics manages and supports system air conditioner for university, hospital and enterprise. Getting larger and large their business area, Samsung needs to build environments for remote management system. Because their legacy system has many trouble when update or control from remote location, Samsung develop DMS which supports manage air conditioner system in the all around worlds. DMS system which consists of J2ME, OSGi(SMF), WSDD, DB2e are embedded platform. DMS system gets information of remote located air conditioner and controls it. In the past, typically such like this system develop by using a C++ or C. The OSGi, However, has more high maintenance and salability than RTOS using C/C++ families. Due to this, Samsung use OSGi and they can take a contents update, insert and delete easily. DMS gives Samsung Electronics economic power and make sure that they can overwhelm competitors. [8]

    

    

    

    

    

2. Block diagram depicting its middleware role

Figure 2 OSGi Framework

The OSGi framework works on Java Runtime Environment. So, it is used in various applications. For example, smart phones, PDAs, industrial machines and medical equipments. The applications and components on OSGi framework are installed, updated and removed without a reboot. The OSGi programmers can develop components regardless of Operating System.[1]

1. Available support: APIs, tools

There are two major solutions to support OSGi developments.

• IBM Workplace Client Technology, Micro Edition[4]
  • WSDD (WebSphere Studio Device Developer) : Integrated development Toolkit based on Eclipse
  • DB2 Everyplace Micro Environment
  • WebSphere Everyplace Device Manager

     

• SpringSource Tool Suite (STS)[5]

  A STS offers development environments based on Eclipse program to build enterprise applications. Developers can pack and deploy components using SpringSource dm Server.

   

1. Status and maturity     

   The OSGi technology is still changing to support various systems and application as a middleware. The current of the OSGi specification is 4.1. It was release on May 2007.

   The OSGi is seeing a surge in interest from a wide range of communities from embedded, the traditional domain of the OSGi, to desktop tools and applications to mobile devices and servers such as Eclipse, JBoss, WebSphere, Tomcat, etc. [6] In case of Eclipse, with using the OSGi framework, the most popular IDE in JAVA world provides the runtime environments. The OSGi technology is becoming the foundation of many small, large, simple and complex systems by providing a dynamic component model. [7]

    

2. Reference
   [1] "OSGi" 06 March. 2009 <http://en.wikipedia.org/wiki/OSGi>
   [2] OSGi Alliance "About the OSGi Service Platform" 07 October 2005
   <http://www.makewave.com/resources/docs/osgi/TechnicalWhitePaper2005osgi-sp-overview.pdf>
   [3] "OSGi Alliance" 06 March. 2009 <http://www.osgi.org/Main/HomePage>
   [4] Sami Salkosuo 06 March. 2009 "IBM Workplace Client Technology, Micro Edition and Open Service Gateway Initiative (OSGi) <http://www.ibm.com/developerworks/websphere/library/techarticles/0606_salkosuo/0606_salkosuo.html>[5] SpringSource 06 March. 2009 "SpringSource Tool Suite"<http://www.springsource.com/products/sts>
   [6] Jeff McAffer and Simon Kaegi January 2007 "Eclipese, Equinox and OSGi"<http://www.theserverside.com/tt/articles/article.tss?l=EclipseEquinoxOSGi>
   [7] Peter Kriens 04 March 2009 "OSGi, the future of Java"<http://www.javapolis.com/confluence/pages/viewpage.action?pageId= 30555>
   [8] Suckwoo Kim July 2007 "Universal middleware framework – OSGi", Microsoft Korea

Architectural style

Architectural style of Java Virtual Machine

Myoungsoo Jung, Jungwoo Lee, Gyuyoung Park, and Yehan Ahn

Mar. 14. 2009

The purpose of the application

Java virtual machine is an interpreter for java programming language developed by James Gosling in Sun Microsystems. Originally, java is for controlling domestic products, but it has been popular on the internet because it is platform-independent so, once written, it can be executed on any machine on which java virtual machine executes. Java virtual machine is not a compiler but an interpreter, so it can execute any java programs on any machines if java virtual machine can run on them. But, for performance, java source codes are compiled to intermediate code called 'java byte code', so it can run faster than other interpreters. Already mentioned above, java source code should be compiled to byte code. So, the input of java virtual machine is java byte code and its output is to execute java programs. Java can be classified into three categories that is, Java Enterprise Edition, Java Standard Edition, Java Micro Edition each for server computing, desktop computing and mobile device. To execute all these kinds of java versions, java virtual machine is core technology.

The non-functional requirements

Platform independence

Programs usually are platform specific; that is, a program developed and compiled for one platform will not automatically run on a different platform. Most of the time, when a program needs to run on different platforms, special versions of the program must be developed and compiled for each environment. JVM is platform independent, however; Java programs are designed to run on different platforms without porting.

Performance

The average performance of Java programs has increased a lot over time, and Java's speed might now be comparable with C or C++. In some cases Java is significantly slower, in others, significantly faster.

Reliability

JVM checks error strictly in compile time, and JVM doesn't support 'Pointer' that makes some critical errors in the system.

Maintainability

Because JVM supports 'runtime-linking', if programmer wants to compile just one class, then he doesn't need to compile all class. Programmer just should compiles one file which includes that class.

Security

Owing to the open nature of the Internet, computers connected to the Internet are all susceptible to attacks from malicious programs in a wide variety of forms. An attacker who manages to break into a computer could access or modify data, eavesdrop on messages including e-mails and online transactions using credit cards, or even cause irrecoverable damage to the software and hardware on the computer. A completely secure but open environment is unattainable. The JVM is designed to prevent potential security breaches while running Java programs.

Safety

JVM supports 'garbage-collection' that releases memory resources which will not use anymore. It prevents 'memory-leak' due to programmer's mistake.

The architectural style

We suppose abstract diagram of JVM Frameworks to explain components, connectors, and configurations. We represent architectural styles through layered architectures. Layered architecture has many benefits to struct system software or platform. Originally, Layered architecture is support to low coupling and high cohesion. If system of layered architecture is well defined protocol or parameter then system designer can change layers without some adjustments. Nevertheless, some weaknesses are exists. It is complexity control. Software entropy is higher then early in developments and maintenances. So a layered architecture is inevitable correction. For example, I/O request packets in windows operating system. JVM or any VM is also similar with IRP example.

< Figure 2, Abstract diagram of Layered Architectural styles of JVM Frame works>

Components

Java Virtual Machine Frameworks is divided by four parts of layers. First a role of layer 1 is loading interface and classes to runtime data of JVM to transfer appropriate information to core layer (Layer 2, 3). Second, execution layer is responsible for executing instructions in classes. Core layers consist of two layers. It is responsible for manage virtualization same like real machines. Due to this, core layer can be devided by several layers or components when they are implemented.

Connectors

First connector is founded between layer 1 and layer 2. Layer 1 is processing input such like loading classes from JAVA class files, after that core layers preserve detail information through its connectors.

Figure 2 provides evidences tha each layer doesn't need to call directly between each other since JVM is not only designed by layered architecture. Every layer in architecture communicates only through connectors.

Configurations

Each layer in JVM, typically, can decide flexibly component and connector configurations. If we have issues that it changes some parameters or protocol then we can do it without any modifying layers in JVM since they are packed via abstract of connectors. Moreover, we can also change configurations of layers. Layered Architecture allows that adds regacy layers, third part layers and other functional layer to JVM.

The Concrete version of selected architecture

Class Loader

Class loader loads class files so that byte codes of classes can be processed by the execution engine of the JVM. All non array reference types, including classes, are loaded either through the bootstrap class loader or through a user-defined class loader.

Class Verification

In class verification, the representation of a class or interface is verified to ensure that its binary representation is structurally valid. Verification may cause additional classes and interfaces to be loaded but need not cause them to be prepared or verified.

Method & Stack Manager

The JVM stack is analogous to the stack of a conventional language such as C. It holds local variables and partial results, and plays a part in method invocation and return. The JVM has a method area that is shared among all Java virtual machine threads. The method area is analogous to the storage area for compiled code of conventional language or analogous to the "text" segment in a UNIX process.

Other architectural styles

The Java virtual machine has another architecture style which is called 'stack based architecture'. Java virtual machine has stacks for each thread and manages each thread by this stack. When a new thread is launched, a new java stack is created. And when a thread invokes a method, a stack frame is created and stored into a java stack. So, there are stack frames for each method in a java stack for each thread. When a method completes and returns, the stack frame of the finished method is discarded. Stack frame consists of three parts. One is local variables which are used by a called method. It is the same as local variables we already knows. Another is operand stack which is used by instructions on java virtual machine. Java virtual machine has its own instruction set. Java virtual machine use stacks instead of registers. The other is frame data which is related to the stack frame.

References

[1] David Reilly, "Inside Java : The Java Virtual Machine" Jun 05, 2006 Mar 3, 2009

http://www.javacoffeebreak.com/articles/inside_java/insidejava-jan99.html

[2] Xiaoping Jia, "Object-Oriented Software Development Using Java", Addison Wesley

[3] Garlan-Shaw. (1994). An Introduction to Software Architecture.

[4] Tim Lindholm, Frank Yellin. The Java^TM Virtual Machine Specification Second Edition

What is difference between EDF versus RM?

Paper survey and summary of
"Rate Monotonic vs. EDF: Judgement Day"

Myoungsoo Jung
< CoC of Georgia Institute of Technology >

Background Arts

In various industry application and scientific research equipments, it needs some different operating system to generic operating system. Realtime Operating System (RTOS) which is used by real-trime applications does not necessarily have high throughput. RTOS should guarantee deadline rather than throughput [1]. The kind of deadline in RTOS separate largely two parts. One is soft real-time, another one is hard real-time.

As was mentioned, real-time applications are limited in utilizing data and task dependencies. Therefore, RTOS typicall use scheduling algorithms which are more specialized and optimized to small or static real-time systems than a generic scheduling. In detailed RTOS scheduling requirements, a scheduler should predict and evaluate execution time of some task in real-time environments, before scheduler run it. However it is very difficults since occurs sporadic tasks and unpredicted event from users [2].

Problem statements

The most commonly used scheduling algorithms are two things. One is RM, Rate Monotonic scheduling algorithms. It is published by Liu and Layland [3]. RM didn't consider dynamic change the prioty of tasks. Paper of Liu and Layland, However, is very gorgeous since they suggest schedulability. Note that if a RM or some schedure by using RM doesn't statisfy success, then any algorithms cannot satisfy also [2]. Another one is EDF, Earlist Deadline First scheduling algorithms. EDF uses static and dynamic scheduling. EDF has differenct criteria to priority of RM. EDF give process closest to its deadline highest priority although RM assign heist priority to the task that arises more frequently.

In "Rate Monotinic vs. EDF: Judgement Day", Buttazzo said a difference of the most commonly used scheduling algorithms in sevral aspects. It is as following [4].

• Implementation comlplexity
• Analizing the runtime overhead
• Robustness During Overloads
• Transient Overloads
• Jitter and Latency
• Mischellineous issues
  (such as Resource sharing, Aperiodic Task Handling, and so on)

I do summary and survey above thing to bellow sepreated subitems.

Implementation comlplexity

In danamic scheduling, EDF has a difficulty of implementation. As was mentioned in many conference and industry, mapping deadlines to priority is major problem of EDF since deadline will be changes. In some cases, EDF dynamic mapping is poor appearance even though the kernel allows task priorities to be changed at runtime. For example, assumes that system under EDF has two tasks which are choronigical. If this system occur new task that is postion in the middle of original two tasks then EDF should all current deadlines may need to be remmaped. In EDF case, Moreover, it has many level of priority than RM. Thus, EDF cannot the basic kernel operation in constant time although RM is enable to operate in constant time since RM has priorities under 256

Analizing the runtime overhead

The reason that the most of people believe EDF overhead is more than RM is EDF has every time calculate deadline and update it. This extra computation is needed since deadline has release time which is not predictable. In an extra computation aspect, EDF has more overhead than RM. In real system, RM has runtime overhead than EDF, however. The reason is context switching. When occur preemption, RM has overhead always since processs of lower priority is preempted by a process of higher priority. Moreover, because RM is static priority scheduling, preemption is very frequently. The following graph presents it.

In schedulabilty aspects, if relative deadlines are equal to periods, exact schedulabilty analysis can be performed in O(n) under EDF, whereas is pseudo-polynomial under RM also.

Robustness during Overloads

In paper, the author compares overloads of RM and EDF in two aspects such as permenant and transient. In permanent overloads, both behaviors of RM and EDF are priectable. Deciding which one is better is deponent on application behavior. In transient overloads, the only difference between RM and EDF is that RM ensures that higher priority task is not to miss. However, the author asserts that such a property of RM can be of little use if we do not know a priori which task is going to overrun.

Jitter and Latency

Periodic tasks must start after their release time and complete within their deadline. Jitter means the maximum time variation in the occurrence of a prticular event. The author supposes to support EDF, some terminologies. It is RRJ and ARJ.

RRJ is as following.

It is maximum differences between brevious job and current job. Task in notation are same task, ofcourse. On the other hands, another maximum value is difined also in paper. It is ARJ, Absoulte Response time Jitter as following.

ARJ is some difference to RRJ, but there are similar. It is just differential between maximum and minimum value regardless of task sequences of occurences.

RM reduces the jitter of high priority tasks; EDF treats tasks more evenly, obtaining a significant reduction in the jitter of the tasks with long periods for a small increase in the jitter of tasks with shorter periods.

EDF significantly reduces jitter and also enhaces latency. It is possible since EDF has a fewer preemtion than RM scheduling. Moreover, Under EDF, such a start time delay does not affect the input–output latency because deadlines make a priority not just periods.

Mischellineous issues

In aperiodic task handling, EDF has the most efficient service mechanism in terms of performance/cost ratio although RM has good responsiveness and easy implementation complexity.

In resource sharing, RM can be predictably used and analyzed in the presence of shared resources. However, this is not true, because a number of protocols also exist for accessing shared resources under EDF

Main Idea

Main idea of the athour, exactly Buttazo, is there are many misconceptions of two RTOS scheduling algorithms. Specially, EDF suffer from wrong statements and concepts that RM is easier to analize that EDF, less runtime overhead and more predictable in real-time system.

The author gives a clear evidence to support his assertions. I have been summury and servey of it through servral description already. The real advantage of RM with respect to EDF is its simpler implementation in commercial kernels that do not provide explicit support for timing constraints, such as periods and eadlines. Other properties typically claimed for RM, such as predictability during overload conditions, or better jitter control, only apply for the highest priority task, and do not hold in general. On the other hand, EDF allows a full processor utilization, which implies a more efficient exploitation of computational resources and a much better responsiveness of aperiodic activities. These properties become very important for embedded systems working with limited computational resources, and for multimedia systems, where quality of service is controlled through resource reservation mechanisms that are much more efficient under EDF. In fact, most resource reservation algorithms are implemented using service mechanisms similar to aperiodic servers, which have better performance under EDF [4].

Critics

I agree with assertion of Buttazzo. As was mantioned by the author, EDF has more powerful than RM such as lower runtime overloads, reducing jitter and so on.

However, mentioned examples are not respresent that EDF algorithms are better than RM. Although the analysis of Buttazo is very reliable, a mentioned scenario is too specific to some user's behavior. Also, the author assumes that not only the jitter can be tolerated but also it does not degrade the performance of the system under real-time applications. The jitter will be trouble, in some alpplications.

For example, in storage system, tasks are grately devided in two kinds. One is a reciever task and another is I/O operation task. A receiver task has hard constraints and it must be done within response time [5]. A receiver is indeed shorter than an I/O operation task. Thus, in some case, a reciever task needs to meet "ARJ = 0". EDF is clearly reducing jitter, but it doesn't satisfy some applications which have issue that Absolute Response time Jitter (ARJ) is zero. Follwing example daigram is very simple cases in storage system. In storage system, Its behavior is more complex.

In runtime overloads apspects, moreover, there are applications which have a few numbers of static tasks since static real-time system is very spread in industry area. In above example, the number of threads equals the number of channel or functional layer. Typically, all most of storage system has statically tasks. Moreover amounts of thread are very small. I think that the number of preemption doesn't arise, In this case.

Although my assumption for EDF vs RM is wrong, comparing EDF and RM is very interesting to me in several aspects. I like to study and survey best optimized scheduling methods based on EDF and RM in some appilications such as NAND based storage system.

References

[1] Wikipedia, "Real-time operating system" Feb, 19. 2009.
"http://en.wikipedia.org/wiki/Real-time_operating_system"

[5] sata-io.org, "Serial ATA 2.6 Specification" Feb 2007
"https://www.sata-io.org/secure/spec_download.asp"

Heated Plate Design Description

Myoungsoo Jung, Changmook Lim, Kyuyoung Park, Dosuk Park, and Sohye Kim

Feb. 12^th, 2009

Overview

Structure, metaphor, or architecture used

Overall structure

This program simulates that heat spreads through a two-dimensional plate. It receive inputs such as dimension, four temperatures for left, right, top and bottom from users through GUI. And it displays the change status of plates' temperatures when each plate has an influence on its neighbors. This program includes the main three parts. They are Simulator, Plate and Lattice.

<Figure 0, Major parts of a simulator>

Simulator receives configuration from GUI and run simulation until lack of change is lower than max lack of change and prints out on GUI. Plate holds data (like array) and do common actions such as update temperature and get plate temperature. Lattice represents each cell and holds temperature, points to its neighbors.

Most troubling aspect / Possible approaches/ Approach taken / reason

How does the program come up with the final state?

There were three matters we had to concern with. Most of all, all we needed to do is remove most time consuming instructions as many as possible. Moreover, we have found out for several continuous operations with the same condition. Finally, Interval between each step that is for printing on GUI also matters since it cost much time than actual computing. For these three affect, we have come up with several possible solutions for each three. For the first, we came up with not to put any 'new' in computing method to create data on Heap, and not to use variable to variable copying operation unnecessarily. We adopted all of them to our program be fast. For the next matter, indeed we found there are many operations with the same condition. It is even too many as dimension goes up. Furthermore, there is always an axis of symmetry on the plate temperature array and if we find this axis, the computing time will be reduced in half. Nevertheless, we concluded that this is too specific and this feature is likely to change as program evolves. We did not adopt this. For the final matter, at first, we came up with just showing final result because, if number of iteration is large, the program spent too much time on printing. However, we figured out that after some number of iteration, color on GUI does not seem to change, so we set some number to print out on GUI according to dimension. Then set a progress bar, so that user can wait longer time.

Program characteristics

This table describes characteristics of this program.

<Table 1, characteristics>

Lines of code

The number of lines of code means lines of code excluding empty lines, comment lines and empty comment lines among total number of lines.

A software tool, Line Counter 1.03 was used for measurement. [4]

Class file size

A class file size means an actual file size of .class file returned by Windows OS.

Number of classes

Class means an object declared as a class keyword in Java source files. The number of classes includes the number of interfaces declared as an interface keyword in Java source files.

Average number of operations per class

The average number of operations per class means an arithmetic mean between numbers of operations and numbers of classes.

Average number of attributes per class

The average number of operations per class means an arithmetic mean between numbers of attributes and numbers of classes.

Average number of inter-class dependencies

This average number means an arithmetic mean between numbers of dependencies and numbers of classes. The test classes above table were major classes among all classes.

Static description

Major classes used

<Table 2, characteristics>

Roles in the architecture

Major classes do actions such as getting plate temperature and updating temperature by using inputs from users.

Dependency table

This table shows dependencies between major classes in program 5, guiPlate.

<Table 3, characteristics>

A <bind> above table means "A binding of template parameters to actual values to create a

nonparameterized element". [5]

A <interface> means that classes implement interfaces.

A <uses as parameter> means "Source class contains operation with parameter of target class". [6]

Class-model design diagram

Our class-models are divided into four kinds of large class diagrams as followings.

1. A Diagram of a simulator. (Figure 1)
2. A Diagram of pate data structures. (Figure 2)
3. A Diagram of lattice data structures. (Figure 3)
4. A Diagram of converter (Figure 4)

Each class diagram is explained in detail in the following consideration.

Major classes

Our goal in design of major classes is portability. First, each class is classified according to the feature and we consider how to communicate to each other. It is solved by defining interface classes in our designs. Also, Interface designs give us benefits that our classes more have decoupling and it is flexible when we get an additional data type or view. So we define major class as followings [3]

1. "Simluator"
2. "Plate"
3. "DoubleArrayConverter"
4. "PrintPlate"

A simulator class is control class and a document class is plate and lattice. Especially we plan that by using generics of JAVA, implements document classes. Generics are friendlier with OO than C++, because they do not damage to OO environments such as polymorphism and dynamic binding [2]. According to MVC [1] model, we design also view class that is a "PrintPlate" interface derived from "VisualPrintPlate" Every class without a "Demo" class and "Lattice" class is derived by above major interface classes. Each interface class in detail behavior will be mentioned by dynamic description including data flows.

<Figure 1, a class diagram that represents a simulator and relevant classes>

<Figure 2, a class diagram which is documents classes consist of lattices and interface >

<Figure 3, a class diagram that represents a doubleArrayConveter interface and specializing classes>

<Figure 4, a class diagram that represents plate interface and specializing classes>

Dynamic description

Behavior description

Our heated plate simulator considers the behavior of the big two. First parts are computing parts and another is communication part between computing core class and Classes that represent GUI or User Interfaces.

Control flows

"Demo" class is singleton. It has interface of simulator and initiate simulator using a start methods of simulator. Their structure is represented by class diagram of <figure 1>. A "Demo" class can access the same way to simulator although a simulator of each five programs is different since we design it by using a polymorphism. It gives our application what we control that a simulator can have consistency although it uses various data types. [3] After that, a simulator creates a "Plate" based on input value of user. Therefore a simulator sends a message that does compute changing temperature to a "Plate" class. A simulator can do converting data if above message passing will be normally done. In the next stage, a simulator display data to user by using an interface of a "PrintPlate". We define appropriate class to do it on the class diagram. You can see simulator and relevant classes in <figure 1> and interfaces of "Plate" and "Converter"also through class diagram of <figure 3> and <figure 4>.

Data flows

Data flows have two major issues. One is data casting when the simulator has computed. Another is display when a simulator commands to user interface such as GUI. Look at the first case, the simulator send messages that is an "updateTemp()" to a plate instance. A plate class is documents class to store data. When a plate receives messages that is "updateTemp", it computes changing a value such as temperature. A simulator stores results by sending a message through "commitUpdate" to a lattice class. <Figure 6> show that above process.

In the display parts, the simulator transfers data from list of array returned by a plate class to array of double using a converter interface if computing does well normally. After that, the simulator commands to interface of "PrintPlate" to display of results after above converting process. You can see this process via the <figure 6>. It is sequence diagram that represents computing.

Sequence diagram

Execution of float programs

<Figure 5, a sequence diagram of a float simulator>

Execution of the GUI

<Figure 6, a sequence diagram of a display part in a GUI simulator>

<Figure 7, a sequence diagram of a computing part in a GUI simulator>

Low-Level Design Consideration

Algorithms

Basic concept of major algorithm is the same as the pseudo code we were given. However, we modified it, so that it is more memory efficient and relative faster. First of all, we did not use same size data array but used [2] x [dimension] size array to reduce memory usage. We write the result on source array itself. Through this, we do not need to copy updated temperature from result array to source array. Meanwhile, we need some way to get previous temperature of left and top cell since we just write on the source array, so we create 2 columns array. This array holds temperature of previous line and current line. With this, the program can calculate properly. Also, we enabled [0][dimension] and [1][dimension] to save either previous or current line. This will save the operations copying [1][dimension]'s temperature to [0][dimension]. Moreover, to prevent printing on GUI operation makes computation slow, we didn't print result on GUI when color change is trivial since we do not see any difference on GUI, but for the final result, the program keeps computing, so that we can get result on GUI.

Data structures

Non-functional requirements

Obviously, performance and precision were the major things we had to deal with. In addition, we also considered evolvability.

Performance and Precision

To improve performance, we first set limit for several inputs, that is, temperature; from 0 to 100, dimension; from 5 to 500, loop limit; from 0 to 10,000. This prevents spending too much time from computing large amount of data. Furthermore, we do not printing out on GUI for every step since it significantly decreases performance. This will increase performance, but will decrease precision on the other hand because the program does not represent subtle change of each step after certain iteration.

Evolvability

To improve this, we considered which part may change, and may require different feature. First of all, between program 1-4 and program 5, the way of receiving input and representing output is different. For this reason, we split both of them from the main program part and linked them with main through interfaces. In this way, it is possible input and output to do different behavior as long as classes have methods the interfaces ask. In addition, we separated data with actual simulator so that even data structure the program uses change, simulator can still simulate with minimum modification.

GUI design

Program receives 4 temperatures, we considered jSlider for them, but it is somehow difficult to set exact value, for that reason, we used jSpinner instead, so that user set input values with both typing and clicking. Moreover, unit temperature is 0.01 so that user can get more precise result. For similar reason, many other values are received by jSpinner. So, when user clicks simulation button, values inside those components will be stored in variables, and with these variables, computation is done. Besides, GUI represents computing progress as well as result. Using graphic representation is more intuitive than text one, so we used graphic one, and the reason why we put progress bar is that user tolerate computing time more than the time without progress bar.

Reflection

Many of what we have designed works. For instance, the main algorithm for computing temperature, separating each works into modules, and GUI design are the ones that work properly. However, we didn't expect printing result will take too much time, alternative was required. In addition, it took time to compute and in the meantime, it was not possible to receive any input from user, so thread is also added, so that user can do on GUI like canceling the computation that currently executing. To sum up, several features are additionally implemented to overcome slowness in computation. However, other features work well.

References

[1] Wikipedia, "Model-view-controller" http://en.wikipedia.org/wiki/Model-view-controller Feb, 11. 2009. Feb, 12. 2009

[2] Kim, tea kyun, "An OOP story of K professor" Beaumter. 2006

[3] Myoungsoo Jung, "C++ Interface": abstraction class versus generics of JAVA, Microsoftware. 2006.

[4] Line Counter 1.03 can be downloaded under http://www.sharewareplaza.com/Line-Counter-download_15719.html.

[5] UML Class Diagrams,

http://www.cc.gatech.edu/classes/AY2009/cs6310_spring/slides/classDiagrams.pdf,

Accessed: 2009.02.12

[6] Project 1 Heated Plate Design Study,

http://www.cc.gatech.edu/classes/AY2009/cs6310_spring/projects/project1/project1.html, Accessed: 2009.02.12