Not Signed-In
Which clippings match 'Object-oriented Design' keyword pg.1 of 1
26 MAY 2014

Propel: Object-Relational Mapping (ORM) for SQL-Databases

1

TAGS

2005abstraction layer • Composer (dependency manager) • CRUD (acronym) • data-driven • database schema • database structures • dependency manager • GitHubJSONMITMySQLobject-oriented design • Object-Relational Mapping (ORM) • object-relational mapping toolkit • ORM • PHP • PostgreSQL • Propel (ORM) • query-builder • reverse engineeringsoftware abstractionsoftware engineeringsoftware framework • SQLite • Symfony (PHP framework) • toolkit • web application developer • web application developmentXML • YAML

CONTRIBUTOR

Simon Perkins
21 FEBRUARY 2014

Video Tutorial of OOP Design Patterns

Fig.1 Java Video Tutorial by Derek Banas, 19 August 2012.

1

TAGS

data abstraction • Derek Banas • design patterns • encapsulation • inheritanceJavamodelling language • object class • object-oriented designOOP • OOP concepts • OOP design principles • programming fundamentals • requirements engineeringsoftware code • software design principles • software design problems • software developmentsoftware engineeringsoftware modellingsoftware programmingsoftware requirementssoftware tutorial • subclass • superclass • UML • UML diagram • Unified Modelling Languagevideo tutorial

CONTRIBUTOR

Simon Perkins
04 OCTOBER 2013

Meredith Davis: A Call to Action for Design Educators

"I believe that design education, at the most fundamental level, views complexity as a problem to be overcome through reductivist artifacts, not as an inevitable and pervasive attribute of life in the post–industrial community. So if the future is about an ever–expanding web of connectedness, how are we preparing students for meaningful work in this complex world? I'd like to suggest that we're not. Despite the obvious emotional impact of Glaser's poster, he belongs to a generation in which the goal of design was to make things simple. Negroponte, on the other hand, is a technologist for whom the design goal is to render the complex manageable and to make complicated things meaningful.

Almost everything about today's graphic design education is matched to Glaser's worldview. We structure both curricula and projects in craft–based progressions from simple to complex, from the abstract to the contextualized. In typography classes, for example, we begin with the letter, and then advance to the word, sentence, paragraph, and page. Sequences of typography courses are built on this simple to complex progression, when opening InDesign demands that students address the formal and interpretive issues of publication design simultaneously; how do you defer a discussion of leading, of column width, of the modernist preconceptions of software, of language? The only option is default, and what kind of typographic lesson is that?

The reality is that our strategy for teaching typography is residue from how students could comp type in predigital times; by drawing. It is the organizational structure for every type book since James Craig's 1970 Designing with Type, but it holds less relevance for what students need to know about communication in a digital world. Typography today is a complex relational system that depends on the interplay of formal, technological, linguistic, and cultural variables. Yet we persist in teaching this progression of scale, isolating such variables within their own distinct conceptual frameworks and rules.

The same strategy exists for how students progress in other studies of form. Foundation lessons begin with abstraction: point, line, and plane; color wheels; and paper–folding exercises. We defer discussions of meaning and context until later levels of the curriculum and beginning students learn these abstraction principles only through patterns in what makes their teachers smile. Nothing about these studies resembles what students know about in the real world, and as a colleague recently suggested, what the clients of design see in our work. So what if we begin with the familiar and complex?"

(Meredith Davis, 4 April 2008, AIGA Boston Presentation)

Presentation made at W/Here: Contesting Knowledge in the 21st Century, Emily Carr University of Art+Design, Vancouver, Canada, 7–9 December 2011.

CONTRIBUTOR

Simon Perkins
14 APRIL 2011

UML Sequence Diagrams and detailed Object-Oriented Design

"If you figure that preliminary design is all about discovery of classes (aka object discovery), then detailed design is, by contrast, about allocating behavior (aka behavior allocation) – that is, allocating the software functions you've identified into the set of classes you discovered during preliminary design.

When you draw sequence diagrams, you're taking another sweep through the preliminary design, adding in detail.

With preliminary design, you made some informal first guesses at how the classes will interact with each other. Now it's time to make those statements very precise, to turn them into a detailed design that works within the Technical Architecture that you've defined.

You use sequence diagrams to drive the detailed design. But note that we advocate drawing your sequence diagrams in a minimal, quite specific format (which we describe fully in this chapter). There's a direct link between each use case, its robustness diagram, and the sequence diagrams. Just as you drew one robustness diagram per use case, you'll also draw one sequence diagram per use case.

DON'T TRY TO DRAW FLOWCHARTS ON SEQUENCE DIAGRAMS (FOCUS ON BEHAVIOR ALLOCATION INSTEAD)

UML 2.0 allows you to draw full–blown flowcharts on your sequence diagrams. However, even though the notation supports it, we consider the practice of drawing flowcharts on sequence diagrams to be inadvisable, because it puts emphasis on the wrong part of the problem.

In large part this is because drawing flowcharts simply misses the point of what you should be thinking about when you draw a sequence diagram. If you're trying to drive a software design from use cases, it's vitally important to get the allocation of operations to classes correct. This allocation of operations to classes tends to be a make–or–break design issue.

In the ICONIX Process, the primary purpose of the sequence diagram is to make this behavior allocation visible so that you get it right. If your mind is on drawing a flowchart, it's not going to be focused on this critically important set of behavior allocation decisions.

Once you've finished all the sequence diagrams for the use cases you're working on in the current release and updated your static model (class diagrams), you need to perform a Critical Design Review (CDR). The CDR forms something of a reality check for your design. We illustrate how to perform effective design reviews in our Use Case Driven book. Once the CDR is done, the implementation stage (coding and unit testing) begins."

(Doug Rosenberg and Matt Stephens, 2007)

Doug Rosenberg and Matt Stephens (2007) 'Use Case Driven Object Modeling with UML – Theory and Practice', Apress

Fig.1 sequence diagram notation.

1

TAGS

activity diagrams • agile modellingarchitectureblueprintchart • collaboration diagrams • design • detailed design • diagram • Doug Rosenberg • dynamic behaviour • dynamic view • enterprise architect • eXtreme Programming • Grady Booch • ICONIX • information design • Ivar Jacobson • James Rumbaugh • Matt Stephens • MDG • model driven generation technologies • modelling languagenotation • Object Management Group • object oriented analysis • object-oriented design • object-oriented software • OML • OMT • OOAOOD • OOSE • preliminary design • product designrequirements • sequence diagram • softwaresoftware architecture • static view • structural view • technical architecturetechnologyUMLUnified Modelling Languageusage scenariosuse casesvisual languagevisualisation

CONTRIBUTOR

Simon Perkins
25 JUNE 2005

Learning Objects: Independent Elements Organised Through Instructional Models

"Wiley's definition of learning objects [can be defined] as "any digital resource that can be reused to support learning". The idea behind learning objects is clearly grounded in the object–oriented paradigm: independent pieces of instruction that may be reused in multiple learning contexts and that fulfil the principles of encapsulation, abstraction and inheritance. Therefore, they have been historically described as Lego pieces, because as Legos do, learning objects can be assembled into lager instructional structures and reused for building other structures. But there is a substantial difference, learning objects are not at all combinable to any other learning object. It is very likely that assembling learning objects without any instructional model will hardly be educationally useful."

(Baltasar Fernandez–Manjon and Pilar Sancho, Universidad Complutense de Madrid)

1

TAGS

Baltasar Fernandez-ManjonDavid Wiley • instructional model • learning objectsLEGOobject-oriented design • OO • pedagogyPilar Sanchoreuse
Sign-In

Sign-In to Folksonomy

Can't access your account?

New to Folksonomy?

Sign-Up or learn more.