2008.01.11 00:20
Agile Modling 홈페이지 : http://www.agilemodeling.com/

* 애자일 모델링 : 소프트웨어 기반시스템의 효과적인 모델링과 문서화를 위한 방법론
* 모델링 스타일 가이드라인 : UML2의 다이어그램을 이용하여 이해하기 쉽고 품질좋은 다이어그램을 그리는 방법

Posted by kimgisa.net
2008.01.10 23:38

오브젝트(타입의 인스턴스) --> 타입(오브젝트들의 추상화) --> 클래스(타입을 객체지향언어로 나타낸 것)

클래스화(classification) : 오브젝트와 그 타입간의 관계
예) 백구는 진돗개다. 힌둥이는 진돗개다.

일반화(generalization)
: 서브타입과 슈퍼타입간의 관계
예) 진돗개는 개이다. 삽사리는 개이다. 사과는 과일이다. 배는 과일이다.

사용자 삽입 이미지

Posted by kimgisa.net
2007.12.10 20:34


AXIS 를 이용하여 웹 서비스를 배포할 때 여러 방법이 있지만, WSDD파일을 작성하고
ClientAdmin을 이용하여 AXIS에 등록하는 방법을 사용할 때가 있다.

이 프로그램은 WSDD 파일을 생성해 주는 프로그램이다.

사용자 삽입 이미지



[주요 기능]
- Deployment용 WSDD파일 생성
- Undeployment용 WSDD파일 생성

[사용법]

  1. WSDDWizard.exe 를 실행하면 프로그램이 실행된다.
    (알집으로 자동압축 해제 후 실행을 시켜놓았기 때문에 한번 실행한 경우라면 압축해제된 WSDDWizard 폴더의 WSDDWizard.jar 파일을 실행하면된다.)
  2. WSDD작성에 필요한 요소들을 입력한다.(서비스 이름, 클래스명, 허용메소드)
  3. Generate WSDD를 클릭하면 WSDD 내용이 생성된다.
  4. Save WSDD를 클릭하면 생성된 WSDD파일을 저장할 수 있다.

[실행환경]
- JRE 1.6 이상이 설치된 PC

----------------------
[궁시렁 궁시렁]
  최근 나온 NetBeans 6.0의 GUI 어플리케이션 프로젝트개발환경을 처음으로 이용도 해 볼겸 만들어 보았다. NetBeans의 Java Desktop Application Project 를 사용하여 개발하였는데, 자동생성된 코드를 분석하자니 후덜덜.... 그냥 가끔 빨리 편하게 개발할 때는 유용한 툴인듯 싶으나, 먼가 깔끔하고 가독성있는 GUI 작업을 할때는 영 아닌것 같다.

Posted by kimgisa.net
2007.12.09 17:03

본 내용은 Code Complete 2nd p.136~138에 실린 내용입니다.

복잡성 관리의 중요성
소프트웨어 프로젝트에 대한 보고서에서 프로젝트 실패의 원인을 보고할 때, 프로젝트가 실패하는 주된 요인으로 기술적인 이유를 들고 있는 경우는 거의 없다. 프로젝트의 거의 대부부은 품질이 떨어지는 요구 사항, 계획 수립, 관리 등의 이유로 실패한다. 하지만 프로젝트가 기술적인 이유 때문에 실패한 경우에는 그 원인을 복잡성의 관리 부족에서 찾을 수 있다. 소프트웨어에서는 어느 누구도 무엇이 일어나는지 모를 정도로 복잡성이 증가한다. 프로젝트에서 특정한 영역의 코드를 변경했을 때 다른 부분에 대한 어떤 영향을 미치는지 완벽하게 이해하는 사람이 없을 정도의 시점에 도달하면, 더 이상 발전할 수 없게 된다.

소프트웨어 설계를 구현하는 두 가지 방법이 있다. 한 가지 방법은 어느 누가 봐도 문제가 없을 정도록 간단하게 만드는 것이고, 다른 한 가지 방법은 어느 누구도 문제를 찾을 수 없을 정도로 복잡하게 만드는 것이다.

- C. A. R. Hoare

[Key Point] 복잡성 관리는 소프트웨어 개발에서 가장 중요한 기술적인 주제이다. 개인적으로 소프트웨어의 기본적인 기술적 의무는 복잡성을 관리하는 것이라고 생각한다.

복잡성은 소프트웨어 개발의 새로운 특징이 아니다. 컴퓨터 분야의 선구자인 Edsger Dijkstra는 컴퓨팅의 한 비트에서부터 수백 메가 바이트(또 다른 표현으로는 1부터 10의 9승)에 이르는 거리를 재는 작업이라고 지적하였다.(dijkstra 1989). 이 엄청난 비율은 정말 어마어마한 것이다. Dijkstra는 이 내용을 "이 의미론적 수준의 숫자와 비교해 볼 때, 보통의 수학 공식은 평범하다. 심오한 개념적인 계층 구조에 대한 필요성을 불러일으킴으로써, 자동 컴퓨터는 우리에게 역사에 없던 새로운 본질적인 문제들을 제시하였다."라고 표현하였다. 물론 소프트웨어는 1989년보다 훨씬 복잡해졌고, Dijkstra가 말한 1부터 10의 9승 비율은 오늘날에는 1부터 10의 15승이 되었다. Dijkstra는 현대적인 컴퓨터 프로그램을 보관할 수 있을 만큼 큰 두뇌를 가진 사람은 아무도 없다고 지적한 바 있다. 이 말은 곧 소프트웨어 개발자인 우리들이 절대로 전체 프로그램을 억지로 한번에 두뇌에 밀어 넣으려고 해서는 안 된다는 것을 의미한다. 최종 목표는 한번에 생각해야 하는 프로그램의 양을 최소화하는 것이다. 마치 곡예에서 공이나 접시를 다루듯이 정신을 다루는 것과 같다. 여러분이 한번에 다루어야 하는 공의 개수가 많아지면 많아질수록 공을 떨어뜨릴 확률도 높아지게 되고, 결국 이는 설계 상에서나 코드 상에서의 오류를 야기한다.

지나친 복잡성에 빠져들었을 때의 한 가지 증상은 확실하게 부적절한 방법을 끈질기게 적용하려는 자신을 발견하는 순간이다. 이는 마치 기계를 다룰 줄 모르는 사람이 자동차가 고장났을 때, 배터리에 물을 붓고 재떨이를 비우는 것과 같다.

- P.J. Plauger

소프트웨어 아키텍처 수준에서는 시스템을 서브시스템으로 나누어 문제의 복잡성을 줄인다. 인간은 복잡한 부분 하나보다 여러 개의 간단한 정보를 더 빠르게 이해한다. 모든 소프트웨어 설계 기술의 목표는 복잡한 문제를 간단한 부분으로 나누는 것이다. 서브시스템이 독립적일수록, 보다 안전하게 한 번에 복잡한 부분의 한 부분을 집중적으로 살펴볼 수 있다. 주의 깊게 정의된 객체는 한 번에 하나의 기능에만 집중할 수 있도록 작업을 분활한다. 패키지도 통합의 상위 수준에서 동일한 장점을 제공한다.

루틴을 짧게 유지하면 머리를 더 적게 쓸 수 있다. 구현 수준에서의 용어보다는 문제 도메인 수준에서의 용어로 프로그램을 작성하고 추상화 수준을 높이면 머리를 더 적게 쓸 수 있다.

결론적으로, 인간의 선천적인 한계를 보완할 줄 아는 프로그래머는 자신뿐만 아니라 다른 사람도 이해하게 쉽고 오류가 적은 코드를 작성한다.


복잡성을 해결하기 위한 방법
비용이 지나치게 많이 드는 비효율적인 설계는 다음과 같은 상황에서 발생한다.

  • 간단한 문제를 복잡하게 해결할 때
  • 복잡한 문제를 간단하고 잘못된 방법으로 해결할 때
  • 복잡한 문제를 부적절하고 복잡하게 해결할 때

Dijkstra가 지적했듯이, 현대적인 소프트웨어는 선천적으로 복잡하며, 아무리 노력해도 결국엔 실제 세계 문제가 내포하고 있는 선천적인 복잡성에 부딪히게 될 것이다. 다음은 복잡성을 관리하기 위한 두 가지 접근 방법이다.

  • 한 번에 처리해야 하는 본질적인 복잡성의 양을 최소화한다.
  • 비본질적인 복잡성이 불필요하게 증가하지 않도록 한다.

일단 소프트웨어에서 다른 기술적인 목표들이 복잡성 관리보다 중요하지 않다는 사실을 이해하게 된다면, 설계 시 고려해야 할 사항들이 간단해진다.

Posted by kimgisa.net
2007.12.09 01:19

AXIS를 이용한 웹 서비스 구축에 관한 좋은 자료가 있어 올립니다.
----------------------
[궁시렁 궁시렁]
  .jws 파일로 등록하는 방법을 첨으로 알게되었는데, 무지 편하군요
컴파일, wsdd파일등록 이 불필요하고, 그냥 axis 폴더에 넣어두기만 하면 만사오케이!.
쉬운만큼 다른 제약사항도 존재하겠죠. AXIS 좀더 시간을 가지고 공부해 볼 물건인것 같네요.

  예전에 전공 프로젝트를 하다가 AXIS로 구현한 웹 서비스가 다른 웹서비스를 호출하여 사용하지 못하는 문제가 있었습니다. 그 때 내심 마음에 걸리긴 했지만 차선책으로 대충 구현하고 술한잔에 잊고 살았는데, 오늘 이번학기에 그 전공수업을 듣는 친구가 그 막혔던 부분에 대해 물어보는 바람에 오기발동, 집착가동... 6시간 이상을 끙끙 되다가 드디어 해결하게 되어 기쁘네요. (문제점. 수업교재의 배포위치에 대한 설명이 잘못됨. 본 글의 댓글참조)

좋은 자료를 만들어주신 오지훈 님께 감사드립니다.

Posted by kimgisa.net
2007.12.05 21:48



1. 기본문법
2. Event Handler(이벤트 핸들러)
3. Object(객체)
4. 자주쓰이는 css(stylesheet)
5. 다이나믹 html중 기본적이고 필수적인내용

출처 : source : http://my.dreamwiz.com/jsreference

Posted by kimgisa.net
2007.12.05 05:00
2007.11.13 18:21
소프트웨어 설계 원칙 5
::마소 연재강의::
http://www.zdnet.co.kr/builder/dev/modeling/

Posted by kimgisa.net
2007.11.13 12:51

In this section, we discuss the use of the static keyword to create fields and methods that belong to the class, rather than to an instance of the class.


Class Variables


When a number of objects are created from the same class blueprint, they each have their own distinct copies of instance variables. In the case of the
Bicycle class, the instance variables are cadence, gear, and speed. Each Bicycle object has its own values for these variables, stored in different memory locations.

Sometimes, you want to have variables that are common to all objects. This is accomplished with the static modifier. Fields that have the static modifier in their declaration are called static fields or class variables. They are associated with the class, rather than with any object. Every instance of the class shares a class variable, which is in one fixed location in memory. Any object can change the value of a class variable, but class variables can also be manipulated without creating an instance of the class.

For example, suppose you want to create a number of Bicycle objects and assign each a serial number, beginning with 1 for the first object. This ID number is unique to each object and is therefore an instance variable. At the same time, you need a field to keep track of how many Bicycle objects have been created so that you know what ID to assign to the next one. Such a field is not related to any individual object, but to the class as a whole. For this you need a class variable, numberOfBicycles, as follows:

public class Bicycle{

        

    private int cadence;

    private int gear;

    private int speed;

        

    // add an instance variable for the object ID

    private int id;

   

    // add a class variable for the number of Bicycle objects instantiated

    private static int numberOfBicycles = 0;

         ......

}

Class variables are referenced by the class name itself, as in

    Bicycle.numberOfBicycles

This makes it clear that they are class variables.


Note: You can also refer to static fields with an object reference like

    myBike.numberOfBicycles

but this is discouraged because it does not make it clear that they are class variables.


You can use the Bicycle constructor to set the id instance variable and increment the numberOfBicycles class variable:

public class Bicycle{

        

    private int cadence;

    private int gear;

    private int speed;

    private int id;

    private static int numberOfBicycles = 0;

        

    public Bicycle(int startCadence, int startSpeed, int startGear){

        gear = startGear;

        cadence = startCadence;

        speed = startSpeed;

 

        // increment number of Bicycles and assign ID number

        id = ++numberOfBicycles;

    }

 

    // new method to return the ID instance variable

    public int getID() {

        return id;

    }

         .....

}

Class Methods

The Java programming language supports static methods as well as static variables. Static methods, which have the static modifier in their declarations, should be invoked with the class name, without the need for creating an instance of the class, as in

ClassName.methodName(args)


Note: You can also refer to static methods with an object reference like

    instanceName.methodName(args)

but this is discouraged because it does not make it clear that they are class methods.


A common use for static methods is to access static fields. For example, we could add a static method to the Bicycle class to access the numberOfBicycles static field:

public static int getNumberOfBicycles() {

    return numberOfBicycles;

}

Not all combinations of instance and class variables and methods are allowed:

  • Instance methods can access instance variables and instance methods directly.
  • Instance methods can access class variables and class methods directly.
  • Class methods can access class variables and class methods directly.
  • Class methods cannot access instance variables or instance methods directly—they must use an object reference. Also, class methods cannot use the this keyword as there is no instance for this to refer to.

Constants

The static modifier, in combination with the final modifier, is also used to define constants. The final modifier indicates that the value of this field cannot change.

For example, the following variable declaration defines a constant named PI, whose value is an approximation of pi (the ratio of the circumference of a circle to its diameter):

static final double PI = 3.141592653589793;

Constants defined in this way cannot be reassigned, and it is a compile-time error if your program tries to do so. By convention, the name of constant values are spelled in uppercase letters. If the name is composed of more than one word, the words are separated by an underscore (_).


Note: If a primitive type or a string is defined as a constant and the value is known at compile time, the compiler replaces the constant name everywhere in the code with its value. This is called a compile-time constant. If the value of the constant in the outside world changes (for example, if it is legislated that pi actually should be 3.975), you will need to recompile any classes that use this constant to get the current value.


The Bicycle Class

After all the modifications made in this section, the Bicycle class is now:

public class Bicycle{

        

    private int cadence;

    private int gear;

    private int speed;

        

    private int id;

   

    private static int numberOfBicycles = 0;

 

        

    public Bicycle(int startCadence, int startSpeed, int startGear){

        gear = startGear;

        cadence = startCadence;

        speed = startSpeed;

 

        id = ++numberOfBicycles;

    }

 

    public int getID() {

        return id;

    }

 

    public static int getNumberOfBicycles() {

        return numberOfBicycles;

    }

 

    public int getCadence(){

        return cadence;

    }

        

    public void setCadence(int newValue){

        cadence = newValue;

    }

        

    public int getGear(){

    return gear;

    }

        

    public void setGear(int newValue){

        gear = newValue;

    }

        

    public int getspeed(){

        return speed;

    }

        

    public void applyBrake(int decrement){

        speed -= decrement;

    }

        

    public void speedUp(int increment){

        speed += increment;

    }

        

}

 

From. http://java.sun.com/docs/books/tutorial/java/javaOO/classvars.html

Posted by kimgisa.net
2007.11.12 19:44

From. http://netpages.blogspot.com/2007/10/systems-of-graphical-notation-in-oop.html

Systems of Graphical Notation in OOP

One important consideration in visual modeling is what graphical notation to use to represent various aspects of a system. This notation needs to be conveyed to all interested parties or the model will not be very useful. Many people have proposed notations for visual modeling. Some of the popular notations that have strong support are Booch, Object Modeling Technology (OMT), and UML.

Rational Rose supports these three notations; however, UML is a standard that has been adopted by the majority of the industry as well as the standards' governing boards such as ANSI and the Object Management Group (OMG).

Booch Notation

The Booch method is named for its inventor, Grady Booch, at Rational Software Corporation. He has written several books discussing the needs and benefits of visual modeling, and has developed a notation of graphical symbols to represent various aspects of a model. For example, objects in this notation are represented by clouds, illustrating the fact that objects can be almost anything. Booch's notation also includes various arrows to represent the types of relationships between objects. Figure 1.5 is a sampling of the objects and relationships represented in the Booch notation.



Figure 1.5 Examples of symbols in the Booch notation

Object Management Technology (OMT)

The OMT notation comes from Dr. James Rumbaugh, who has written several books about systems analysis and design. In an aptly titled book, Object−Oriented Modeling and Design (Prentice Hall, 1990), Rumbaugh discusses the importance of modeling systems in real−world components called objects. OMT uses simpler graphics than Booch to illustrate systems. A sampling of the objects and relationships represented in the OMT notation follows in Figure 1.6



Figure 1.6 Examples of symbols in the OMT notation

Unified Modeling Language (UML)

UML notation comes from a collaborative effort of Grady Booch, Dr. James Rumbaugh, Ivar Jacobson, Rebecca Wirfs−Brock, Peter Yourdon, and many others. Jacobson is a scholar who has written about capturing system requirements in packages of transactions called use cases. Jacobson also developed a method for system design called Object−Oriented Software
Engineering (OOSE) that focused on analysis. Booch, Rumbaugh, and Jacobson, commonly referred to as the "three amigos," all work at Rational Software Corporation and focus on the standardization and refinement of UML. UML symbols closely match those of the Booch and OMT notations, and also include elements from other notations. Figure 1.7 shows a sample of UML notation.



Figure 1.7 Examples of symbols in UML notation

The consolidation of methods that became UML started in 1993. Each of the three amigos of UML began to incorporate ideas from the other methodologies. Official unification of the methodologies continued until late 1995, when version 0.8 of the Unified Method was introduced. The Unified Method was refined and changed to the Unified Modeling Language in 1996. UML 1.0 was ratified and given to the Object Technology Group in 1997, and many major software development companies began adopting it. In 1997, OMG released UML 1.1 as an industry standard.

Over the past years, UML has evolved to incorporate new ideas such as web−based systems and data modeling. The latest release is UML 1.3, which was ratified in 2000. The specification for UML 1.3 can be found at the Object Management Group's website, http://www.omg.org/. UML 1.3 is the version used in this book.


Author: Wendy, Michael Boggs
 
Posted by kimgisa.net

티스토리 툴바