Dashboard > Security Software Engineering project > Home > Pre-workshop Event for SPAQu'07
Log In   View a printable version of the current page.
Pre-workshop Event for SPAQu'07
Added by Nobukazu KAZ Yoshika, last edited by Nobukazu KAZ Yoshika on 11 16, 2007  (view change)
Labels: 
(None)


Date & Time: 30th Nov. 2007 13:30-16:00
Place: Meeting Room 1 on 20th Floor
Speaker: Joseph W. Yoder, The Refactory Inc & Joe Yoder Enterprises
Sponsors: IPSJ SIGSE, SSE Project, TopSE Project

Speech 1: The Adaptive Object-Model Architecture: Giving users control over their business model

Time: 13:30-14:50
Place: Meeting Room 1 on 20th Floor

Abstract:

Architectures that can dynamically adapt to changing requirement are sometimes called reflective or meta architectures. We call a particular kind of reflective architecture an "Adaptive Object-Model (AOM)" architecture. An Adaptive Object-Model is a system that represents classes, attributes, relationships, and behavior as metadata. It is a model based on instances rather than classes. Users change the metadata (object model) to reflect changes to the domain model.

These changes modify the systems behavior. In other word, it stores its Object-Model in XML files or in a database and interprets it. Consequently, the object model is adaptive; when the descriptive information for the object model is changed, the system immediately reflects those changes.

We have noticed that the architects of a system with Adaptive Object-Models often claim this is the best system they have ever created, and they brag about its flexibility, power, and eloquence. At the same time, many developers find them confusing and hard to work with. This is due in part because the developers do not understand the architecture.

This talk will give an overview of the Adaptive Object-Model architectural style and will go through some concrete scenarios to better understand implementation issues related to AOMs.

Speech 2: Refactoring Principles

Time: 14:50-16:00
Place: Meeting Room 1 on 20th Floor

Abstract:

Refactoring code to make it more maintainable and extendable has become a more mainstream practice. Refactoring is the process of changing software without altering its external behavior. It is done
in such as way to improve the structure of the code to allow for later extensions or to make maintenance of the code easier. It is important to refactor your code in a disciplined way to minimize disruptions and
to allow the system to safely evolve. Improving a systems structure and readability through refactoring enhances its comprehensibility, readability, and maintainability.

This talk will talk about code smells, or signs that code needs to be refactored. It will then briefly describe common refactorings as provided by tools such as the Refactoring Browser and Eclipse and
those outlined in Martin Fowlers Refactoring book, teaching you the correct discipline for refactoring your code. Various code examples will be used to illustrate how and when to refactor.

Biography:

Joseph Yoder is a founder and principle of The Refactory, Inc., a company focused on software architecture, design, implementation, consulting and mentoring on all facets of software development. Joseph is an international speaker and pattern author and longstanding member of The Hillside Group, a group dedicated to improving the quality of software development. He is co-author of the Big Ball of Mud pattern, which illuminates many fallacies in the approach to software architecture. Joseph has chaired the Pattern Languages of Programming Conference (PLoP), as well as presented tutorials and talks at conferences such as OOPSLA and ECOOP.

Joe currently resides in Urbana, Illinois where he oversees a team of developers who have constructed an order fulfillment system based on enterprise architecture using the .NET environment. Other recent projects involve working in both the Java and .NET environments deploying Domain-Specific Languages for clients. Joe thinks software is still too hard to change. He wants do something about this and believes that putting the ability to change software into the hands of the people with the domain knowledge seems to be one
promising avenue to solve this problem.

Powered by Atlassian Confluence, the Enterprise Wiki. (Version: 2.3.1 Build:#643 2 03, 2007) - Bug/feature request - Contact Administrators