Application Architecture

Application Architecture

As mentioned before, I live mostly in the Application Architecture area. Even within this one area, there are several views of the architecture. I like Rational's Four Plus One views.  Rational has refined the definitions several times since Phillipe Kruchten's original paper, but I stick with Frank Dupont, my first Rational trainer when RUP was still in beta:

Logical View	Allocates classes and responsibilities to packages and subsystems.
Development View	Allocates packages and subsystems to layers and components. Also defines the development structure.
Process View	Allocates components to processes.
Physical View	Allocates processes to processors, nodes, networks.
Use Case View	(The Plus One) Captures requirements used to develop and validate each of the other views.

Application architecture can be considered alone, but it makes most sense as part of the pyramid. Applications spring from needs and requirements coming from the business and information layers. Application architects must work with data and infrastructure designers to get their systems working and deployed to their users. Increasingly, new systems use services of existing systems, so application architects must work together to integrate. While Application Architects are more focused on individual systems than Enterprise Architects, the scope of their interactions and interests are often the same.

By the Way, What is an Application?

Back in mainframe and Client-Server days, we knew what "application" meant. It was a collection of programs, or maybe one gigantic client program, that delivered a set of related business functions to the user. One project team usually built an application from end-to-end in one cohesive effort. In my COBOL days, the company imposed a project code in the name space, so for example we knew that every file and program starting with E0186 was part of the Work In Process application.
Nowadays things are more complex. A solid Enterprise Application Integration architecture allows interoperation between nearly any two platforms. A cohesive set of screens or web pages may still feel like an application to the user, but the back-end may combine parts from different systems, platforms and languages with purchased components and software hosted by business partners. It is becoming less useful to talk about "an application" and more useful to deliver increasingly integrated functionality to end users.
This kind of environment has great management and political challenges - who builds what and how does the next system pay to use it - but it really makes architecture fun.

Application Architecture Goals

Since the earliest days of data processing, coders and their managers have struggled to define programming goodness. We can see this in an arc over the years, from Edsger W. Dijkstra's letter "Go-To Statement Considered Harmful" through structured concepts of coupling, cohesion and information hiding, and object oriented encapsulation and whole books of design principles.
Architecture, thinking in larger terms than code, components or individual systems, has its own vocabulary of goodness. I have a list of about 100 possible measures of quality that I pull out for review before starting a project. An organization should decide which ones it believes are important, and set clear priorities, perhaps as enterprise defaults modified by business needs on a project-by-project basis. Here are just a few:

• Meet business goals by enabling software to reduce costs, increase profits or differentiate the company.
• RASP: Reliability, Availability, Scalability, Performance, 
• Usability.
• Extensibility.
• Freedom from defects.
• Low cost and rapid delivery.
• Layered architectures, wherein ...
• Each layer has a clear, focused purpose (high cohesion)
• Layers are cleanly separated and independent (low coupling)
• Conformance to team, department, company and industry standards.
• Practice reuse.
• Contribute components to future reuse.
• Channel independence - use the same components for Internet, fat-client, voice response units, wireless, etc.
• Consistent data and rules across all channels
• Interoperability between disparate platforms, languages, etc.
• Portability
• And many more ...

The Architect's Job

The Application Architect operates nearly as a peer to the project manager. While the project manager deals with budgets, plans, resources and tracking progress, the architect sets the technical vision for the project, mentors the technical staff, and monitors design and implementation artifacts for quality and compliance to standards.

What is the IBAction and IBOutlet

Apress - Learn Cocoa on the Mac (Feb 2010) (ATTiCA)


You might be wondering just what IBAction and IBOutlet are. Are they part of the Objective-C language?
Nope. They're good old-fashioned C pre-processor macros. If you go into the AppKit.framework and look at the NSNibDeclarations.h header file, you'll see that they're defined like this:

#ifndef IBOutlet
#define IBOutlet
#endif

#ifndef IBAction
#define IBAction void
#endif

Confused? These two keywords do absolutely nothing as far as the compiler is concerned. IBOutlet gets entirely removed from the code before the compiler ever sees it. IBAction resolves to a void return type, which just means that action methods do not return a value. So, what's going on here?
The answer is simple, really: IBOutlet and IBAction are not used by the compiler. They are used by Interface Builder. Interface Builder uses these keywords to parse out the outlets and actions available to it. Interface Builder can only see methods that are prefaced with IBAction and can only see variables or properties that are prefaced with IBOutlet. Also, the presence of these keywords tells other programmers, looking at your code in the future, that the variables and methods in question aren't dealt with entirely in code. They 'll need to delve into the relevant nib file to see how things are hooked up and used.